Arabic-English Code-Switching: Why It Breaks Most ASR Systems

How common is code-switching in Gulf business calls?

Pervasive, and structural rather than occasional. The Gulf's service economy runs on multilingual workplaces — UAE residents are overwhelmingly expatriates, and English functions as the lingua franca of business while Gulf Arabic carries social and local communication. Clive Holes' dialectological fieldwork across Eastern Arabia documents how deeply English (and earlier Persian, Hindi/Urdu) loan material is woven into everyday Gulf Arabic speech: technical vocabulary, banking terms, and product names routinely surface in English inside Arabic sentences.

The practical pattern in call-center audio: matrix-language Arabic with English insertions for domain terms ("account", "statement", "OTP", "cancellation fee"), plus full clause-level alternation when speakers shift register — and the direction flips constantly between an agent speaking Khaleeji and a customer replying in English-dominant Arabic. Any transcription system serving Saudi Arabia or the UAE that treats this as noise is discarding the most information-dense words on the call, because the switched-in English terms are disproportionately the entities QA and compliance teams care about.

Why do monolingual ASR models fail on code-switching?

Three failure modes stack on top of each other.

Multilingual end-to-end models such as Whisper improve matters because one decoder can emit both Arabic and English tokens in the same segment — but language detection still runs per chunk, so a 30-second window dominated by Arabic can drag embedded English words into Arabic decoding (and vice versa). In our internal evaluation, code-switched Gulf utterances cost roughly 2-3 extra WER points even on Whisper large-v3-turbo; on language-locked commercial APIs the switched-in words are simply casualties.

• A hard language prior. Most commercial APIs make you declare ar or en per request. Every word in the other language is then forced through the wrong vocabulary — English "statement" becomes an Arabic phonetic guess, or Arabic يعني becomes "yani" garbage tokens — scored as multiple substitution errors each time.
• Acoustic-phonetic mismatch. Gulf speakers produce English loans with Arabic phonology (and Arabic with English-influenced prosody mid-switch). Models trained on monolingual corpora have never seen these hybrid realizations, so confidence collapses precisely at switch points.
• Language-model whiplash. The decoder's next-word distribution is conditioned on monolingual text. A mid-sentence switch makes the true next word nearly zero-probability, so the model substitutes a plausible same-language word instead — fluent-looking output that silently rewrites what was said. These are the most dangerous errors because nothing flags them.

What is transliteration ambiguity, and why does it wreck transcripts?

Even when a system hears a code-switched word correctly, it must decide which script to write it in — and there is often no single right answer. Should a Gulf speaker's "cancel" inside an Arabic sentence be rendered as cancel, as كانسل (a common Arabization), or normalized to إلغاء? Each choice is defensible; a transcript that alternates between them is unsearchable. The reverse problem is Arabizi — Arabic written in Latin letters with digits standing in for sounds (7 for ح, 3 for ع), ubiquitous in Gulf chat and increasingly bleeding into how names and terms get spoken and spelled on calls.

Proper nouns are the worst case. One Emirati customer name can surface as محمد, Mohammed, Mohamed, or Mhd within a single thread of interactions, and a search for the customer's calls silently misses half of them. For reference, the language identities here are precisely catalogued — Gulf Arabic is ISO 639-3 afb / Glottolog gulf1241, distinct from Standard Arabic (arb) — and an ASR vendor that cannot tell you which of these its "Arabic support" actually covers has not engineered for the problem. A production system needs an explicit, consistent transliteration policy: keep English insertions in Latin script, keep Arabic in Arabic script, and normalize entity spellings at the analytics layer.

What actually works for code-switched Arabic transcription?

The workable recipe in 2026: a large multilingual end-to-end model (Whisper-class) as the acoustic-decoding base, no hard language lock, dialect-aware tuning so the Arabic side of the switch is Gulf Arabic rather than MSA, and a deterministic script policy applied after decoding. Code-switching detection should be surfaced as metadata too — CallScribe flags switch points per segment, which lets QA teams measure things like whether agents mirror the customer's language choice, a known driver of service satisfaction in mixed-language markets.

When you evaluate vendors, test this directly: pull ten genuinely code-switched calls from your own queue and read the output at every switch point. Marketing pages will say "100+ languages"; the switch points will tell you the truth in five minutes. Our comparison pages for Deepgram and AssemblyAI document how the English-first vendors handle exactly this scenario.