What happens to a transcript when a meeting switches language mid-sentence

When a meeting switches language mid-sentence, a transcript decoded in one language does not stop or flag the switch: it maps the other language's sounds onto the nearest words it knows and carries on, fluent and wrong. The fix is a second pass over the recording by a model that detects the spoken language as it goes, with speaker names taken from the platform. This guide is for anyone whose Google Meet or Microsoft Teams meetings mix two languages — French and English, Hindi and English, Arabic and English, any pair with English — and it works through three of them. How TrackHeros decides which meetings need that second pass is covered under automatic language detection.

What does switching language mid-sentence look like in a real meeting?

It looks like one sentence with two vocabularies. Nobody in a working meeting speaks one language for a paragraph and then another; the switch happens inside the sentence, and it follows a pattern.

The frame of the sentence — the verbs, the small words, the grammar — is in the speakers' shared language. The technical nouns are in English, because that is the language the tools, tickets and documentation are in. Numbers and dates can go either way. Three examples of the same habit:

Pair	Sentence	Roughly
French–English	On fait le deploy vendredi, mais il faut d'abord merger la branche.	We deploy on Friday, but the branch has to be merged first.
Hindi–English	Client ne deadline Friday tak extend kar di hai, toh staging pe test kar lo.	The client has pushed the deadline to Friday, so test on staging.
Arabic–English	لازم يكون الـ demo جاهز قبل الـ sprint review يوم الخميس.	The demo has to be ready before the sprint review on Thursday.

None of this is careless speech. It is how technical work is discussed in most of the world, and a transcript that cannot follow it is not a transcript of the meeting.

Why does single-language decoding fail at the switch?

Because a recogniser told to expect one language has to produce words in that language. Faced with the other language's sounds, it picks the nearest words it knows, and the result reads fluently and is wrong.

A speech recogniser does two jobs at once: it turns sound into candidate words, and it chooses between them using what it expects the language to be. That second job is the one that breaks. Take the Arabic example above.

• Decoded as English: "demo" and "sprint review" come through. The Arabic around them — "has to be ready before", "on Thursday" — is forced into English words that were never said. The deadline is gone.
• Decoded as Arabic: the frame survives, and "demo" and "sprint review" become Arabic-sounding words. What has to be ready, and before what, is gone.

Either way the words that go wrong are the ones in the other language, and in a working meeting those are exactly the words the action items depend on.

Language detection per segment does not rescue it. Many recognisers detect a language for each stretch of speech and then decode that stretch in one language. A switch inside a sentence is shorter than the stretch, so the minority language loses. And because the output is fluent, nobody checks it.

Why are live captions the weakest place to handle it?

Because captions on Google Meet and Microsoft Teams are set to one spoken language per meeting, and they are produced live. They decode the audio as it arrives, with no look-ahead and no chance to revisit a sentence once its second half has changed what the first half meant.

That is a structural limit, not a quality problem, and it is explained in why meeting captions pick one language. Captions remain very good at two things: who is speaking, because the platform knows whose microphone is live, and when, because each line is stamped as it arrives. Use them for that.

What does a second pass over the recording do?

It transcribes the whole recording again after the call, with a model that works out the spoken language as it goes rather than being told one. Both languages are expected, so a switch inside a sentence is ordinary input rather than noise to be explained away, and the model can use the rest of the sentence, and the sentences around it, to decide what was said.

	Live captions	Second pass over the recording
When	During the meeting	After the meeting
Languages	One, set per meeting	Detected as it goes
Context	What has been said so far	The whole recording
Good for	Speaker names, timing, structure	The words, including mid-sentence switches
Role	Scaffold	The record

If the notes have to be in one language, the transcript is then rendered into it line by line. Translating each line on its own, rather than the transcript as one block, keeps every line attached to its speaker and its timestamp, so the translated transcript still says who said what and when.

The second pass costs more and takes longer, which is why it should run when a meeting needs it rather than on every meeting.

Why do speaker names come from the platform and the words from the audio?

Because each source is good at exactly one of the two. The platform knows who is speaking; the recording, read with both languages expected, knows what was said. A good transcript uses each for its own job.

In practice the second pass's lines are placed on the captions' timeline, and each one takes the name of whoever the platform says was speaking at that moment. That is why the names can be right even when the caption words were nonsense. Where a line cannot be matched — crosstalk, a long overlap, a stretch with no captions — the honest answer is "Unknown". A guessed name on an action item is worse than an unknown one, because nobody checks it.

What should you check in a mixed-language transcript?

Read the places where single-language decoding would have failed, in this order:

1. The switch points. Find the sentences that change language and read them against the recording.
2. Numbers, dates and money. These are said in either language and end up in proposals and invoices.
3. Names of people, companies and systems, which no model expects.
4. Owners of action items, and any line marked "Unknown" near a commitment.
5. Consistency. If the transcript was translated, is the same term rendered the same way throughout?

For one language's specifics — Arabic dialects against Modern Standard Arabic, and the small words that carry the meaning — the Arabic–English transcription guide goes deeper, and the languages page lists every language recognised.

What does TrackHeros show after a mixed-language meeting?

An English transcript with the real speaker names, notes in the language you chose, and one line saying what it was translated from. Nothing has to be set; the switch is detected from the meeting itself.

A meeting in which more than one language is heard goes to the second pass. A Whisper speech model transcribes the recording and detects the spoken language itself; 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 words rather than disappearing. The original-language text is stored but not shown. The transcript page shows one line — "Translated to English from a conversation held in Arabic and English" — and that is the only place the transcript mentions language. The summary, decisions and action items are written in English, or in Arabic, French, Spanish, German, Italian, Portuguese, Ukrainian or Indonesian if you chose one. The decision is the same on Google Meet and Microsoft Teams.

Speaker names come from the platform's captions; a line that cannot be attributed is labelled "Unknown". If the transcript cannot be read reliably, the summary says so rather than inventing content. Switching a meeting's summary profile or notes language writes new notes, but there is no button to transcribe it again, so the recording is the reference.

Every pair with English goes through the same path — a meeting that is half French, half English, Arabic and English, Hindi and English — and the languages page lists the close to 100 languages recognised.