Why Arabic–English meetings break most transcription, and what a two-pass transcript does about it

Arabic–English business meetings break most transcription because speakers switch language inside a sentence, and a recogniser built for one language has to force the other language's sounds into its own vocabulary. A two-pass transcript avoids that by using the platform's live captions only for speaker names and timing, then transcribing the recording with a model that works out the language from the audio itself, and treating that second pass as the record. This guide is for anyone who runs client meetings in Arabic and English on Google Meet or Microsoft Teams and needs the transcript to be right. It is one worked example of automatic language detection, which needs nothing set first.

How does code-switching actually work in a business meeting?

In a Levantine or Gulf working meeting, nobody speaks Arabic for a paragraph and then English for a paragraph. The switch happens inside the sentence, and it follows a pattern. The frame of the sentence is Arabic. The technical noun is English. The verb that acts on the noun comes back in Arabic.

خلينا نعمل deploy عالـ staging بكرا الصبح، بس لازم نعمل merge للـ branch أول.

Roughly: "Let's deploy to staging tomorrow morning, but we have to merge the branch first." Every technical word is English, every word that holds the sentence together is Arabic, and the English nouns take Arabic articles and prepositions as if they had always been there: 'al-staging, lil-branch.

Numbers, dates and money do the same thing in the other direction. A developer will say a deadline in English and a price in Arabic, or read a ticket number in English digits and then explain it in Arabic. Names of people, companies and systems are pronounced however the speaker first heard them. None of this is carelessness. It is the ordinary register of technical work in the region, and a transcript that cannot follow it is not a transcript of the meeting.

Why does single-language recognition fail here?

Because a recogniser chooses between candidate words using what it expects the language to be. It does two things at once: it turns sound into candidate words, and it picks among them by the language it was told to expect. That second part is where code-switching breaks it.

Set to Arabic, the recogniser hears "deploy" and has to produce an Arabic word, so it produces the nearest Arabic-sounding one, with full confidence. Set to English, it hears khallina na'mel and returns three English words that were never said. In both directions the technical terms, the ones your action items depend on, are the words that get mangled, because they are the ones in the other language.

Detecting the language does not rescue this on its own. A recogniser that detects one language per segment and then decodes the whole segment in it still loses the minority language whenever the switch is shorter than the segment. The result reads fluently and is wrong, which is worse than gibberish, because nobody checks fluent text.

Why are live captions a scaffold, not a record?

Because they are produced as the meeting happens, against one chosen spoken language, with no chance to look ahead. Google Meet and Microsoft Teams both caption against a single language set for the meeting; the guide to why meeting captions pick one language sets out what each platform's help pages say. Captions are good at exactly two things: who is speaking, because the platform knows which participant's microphone is live, and when, because each line is stamped as it arrives.

They are bad at everything code-switching needs. They cannot revisit a sentence once the second half has changed its meaning, they mishandle names, and they drop the fast, quiet aside where the real decision was made. Use captions for structure: the speaker names, the timing, the shape of the conversation. Do not send them to a client as the transcript.

What does a two-pass transcript do?

It separates the two jobs: the captions say who spoke and when, and a second pass over the recording says what was said.

	Pass one: captions	Pass two: audio
Source	The platform's live captions	The full recording
Runs	During the meeting	After the meeting
Language	One, chosen for the meeting	Worked out from the audio itself
Good for	Speaker names, timestamps, structure	The words themselves, including mid-sentence switches
Its role	Scaffold	The record

The second pass transcribes the whole recording with a model that hears which language is being spoken rather than being told, so "deploy" inside an Arabic sentence is a word it can recognise rather than noise it has to explain away. It can use the whole sentence, and the sentences around it, to decide what was said. The caption timeline is then used to put the right name on each line, so the result has the captions' speakers and the audio pass's words.

It costs more, because the recording is processed twice, and it takes longer than captions. For an English-only meeting the first pass is often enough; for a bilingual one the second pass is the transcript.

What should you check in a bilingual transcript?

Even a good transcript needs a five-minute read before it goes anywhere. Check, in this order:

1. Technical nouns. Are the system names, ticket ids and product terms spelled the way the team spells them? A transcript that writes "UBVA" for a client called "UBA" will do it in every meeting until you tell it otherwise.
2. Numbers, dates and money. Read every one against the recording. These are the lines that end up in a proposal or an invoice.
3. Names. People, companies, vendors. Names are the words no language model expects.
4. Attribution on the action items. Who was actually speaking when the commitment was made. A line labelled "Unknown" is a line to check, not a line to guess.
5. The switch points. Find the sentences where the language changed and read those against the audio. That is where a single-language pass would have failed, and where a two-pass transcript earns its keep.
6. Consistency of the English. Where the transcript is rendered into English, was the same Arabic phrase rendered the same way throughout, or translated in one place and transliterated in another?

Keep a list of the project's vocabulary as you go. It is the cheapest improvement any transcription gets.

Does it matter whether the meeting is in dialect or Modern Standard Arabic?

Yes. Modern Standard Arabic is the register of news, contracts and school, and nobody runs a stand-up in it. Meetings happen in Levantine, Gulf, Egyptian or another dialect, and the dialects differ from the standard in the words that hold a sentence together: negation, question words, the way the future is formed, and the pronunciation of letters like qaf and jim.

A system that mostly knows the standard will either "correct" the dialect into words that were not said or fail on the small words entirely. When you check a transcript, the small words are the tell. If "we won't" and "we will" are being confused, or a question has become a statement, the dialect is not being heard. The technical nouns will be fine; it is the Arabic in between that carries the difference between "yes, next week" and "no, not next week".

How does TrackHeros handle Arabic–English meetings?

TrackHeros makes transcripts in two passes and writes the notes in English or in Arabic. The platform captions come first, for the real speaker names. Whether a meeting needs more than the captions is worked out from the meeting itself — nothing has to be set — and a meeting in Arabic, or in Arabic and English, gets an audio pass over the recording by a Whisper model that hears the language spoken. Each line is then rendered into English on its own, keeping its speaker and timestamp, and a line that fails to translate keeps its original text rather than disappearing. The same steps handle every one of the close to 100 languages TrackHeros recognises; Arabic is one of them, and one of the nine the notes can be written in.

The summary, decisions and action items are written in English or in Arabic — set for your account, a client, a recurring meeting or a single call, or "same as the meeting" for a call held mostly in Arabic. Arabic minutes carry the heading محضر اجتماع, and their PDF reads right to left; the Arabic page shows the rest. The transcript page carries one line naming the languages it was translated from, such as "Translated to English from a conversation held in Arabic and English", and that is the only place the transcript mentions language. Speaker attribution is never guessed: a line that cannot be attributed is labelled "Unknown". If a transcript is unusable, the summary says "This transcript could not be read reliably" instead of inventing content.

Recurring series remember their language. A series heard in English alone can use the captions, and every tenth occurrence goes back through the checks. A series held in Arabic, or in Arabic and English, gets the audio pass every time. One Arabic sentence in an English series sends it back to the audio pass at once, until a full pass over a later occurrence hears English alone again. Correction rules per client fix vocabulary ("UBVA" becomes "UBA") and instructions ("ticket ids look like PROJ-123") for future meetings. Arabic notes are described at /languages/arabic/, every language TrackHeros recognises at /languages/, the notes it feeds at /features/meeting-minutes/, what happens when a sentence changes language halfway at /blog/meeting-switches-language-mid-sentence/, and the developer's day-to-day at /for/freelance-developers/.