MSA vs dialectal Arabic: why dialect coverage decides your model's ceiling

MSA vs dialectal Arabic is the first data decision every Arabic AI team makes, usually without noticing. Modern Standard Arabic is the formal written register shared across the Arab world. Dialects are the regional varieties people actually speak, type and search in. A model trained mostly on the first will read the news flawlessly and misunderstand your customers. The supply is lopsided before you start: Arabic is used daily by more than 400 million people (UNESCO), roughly one in twenty of the world's 8 billion. Yet it is the content language of only about 0.6% of websites (W3Techs, as of September 2026). Every team training or fine-tuning an Arabic model inherits that imbalance before writing a single line of code. The raw material is scarce, and the scarce material that exists is not the Arabic your users actually speak.

MSA vs dialectal Arabic: the short answer

Modern Standard Arabic (MSA, part of what speakers call الفصحى, al-fuṣḥā) is learned at school and used for news, government, education and most formal writing. Dialectal Arabic (العامية, al-ʿāmmiyya, or الدارجة, ad-dārija, in the Maghreb) is what people grow up speaking. The two differ at every level: sounds, morphology, vocabulary and syntax. Unlike MSA, dialects have no standard orthography, so the same word turns up in several spellings.

For an AI team the practical answer is simple. Train and evaluate on the register your traffic arrives in. Formal documents call for MSA. Anything users say or type (calls, chat, voice notes, social posts) calls for the dialects of your markets. Most production systems need both, and the channel should set the ratio, not whatever is easiest to scrape.

The differences are not cosmetic. Here are four everyday expressions in MSA and five dialect families:

Transliterations are simplified, and forms vary within each region. Two details matter for models. First, Egyptian and Moroccan negation wraps around the verb (ma-…-sh) instead of sitting in front of it, so a model that only knows MSA لا can miss a negative altogether. Second, Iraqi أريد looks identical to MSA on the page. Written text can hide which variety it belongs to, and that is one reason dialect identification is harder than it looks.

The diglossia problem, in practical terms

Arabic is diglossic: the language people write formally and the language they speak are systematically different. The linguist Charles Ferguson made Arabic one of the defining cases when he named the phenomenon in his 1959 paper Diglossia. Modern Standard Arabic (MSA) is the register of news broadcasts, government documents and textbooks. It is nobody's mother tongue. What people grow up speaking, and what they type into a chat window, say to a voice assistant or tell a call-center agent, is a dialect: Gulf, Egyptian, Levantine, Iraqi, Maghrebi, and many varieties within each group. The MADAR corpus, for example, separates the dialects of 25 Arab cities.

Because the web's Arabic is overwhelmingly formal, a model trained on scraped Arabic text is effectively trained on MSA. It can handle a newspaper article well and still miss the intent of a one-line customer message in Saudi Najdi dialect. In production, the user does not adapt to the model's register. The model either meets users where they are, or it fails quietly, with wrong intents, stilted answers, and Arabic that native speakers instantly recognize as translated.

What the gap costs in production

The dialect gap shows up on metrics that production teams already track:

• Speech recognition. ASR systems tuned on MSA broadcast audio degrade on spontaneous dialectal speech, and that is exactly the audio a call center or voice assistant receives. In an Interspeech 2023 benchmark of Whisper, the model zero-shot beat fully fine-tuned XLS-R models on the datasets tested, but its performance deteriorated significantly on five dialects it had not seen (Algerian, Jordanian, Palestinian, Emirati and Yemeni). Every transcription error propagates into intent detection, routing and analytics downstream. That is why Arabic speech data for training has to be recorded in the dialects and on the channels you deploy on.
• Intent and sentiment. Dialects diverge in core vocabulary, negation and idiom (see the table above). A classifier that has never seen Gulf or Egyptian negation patterns can flip the polarity of a complaint, and a sentiment dashboard built on it will overstate satisfaction.
• Generation quality. Users judge an assistant in seconds. Answers in stiff MSA, or worse, in the wrong dialect for the market, read as foreign. The model may be factually right and still lose the user's trust.
• Code-switching. Real Arabic traffic mixes dialect, English or French loanwords, and Arabizi (Arabic typed in Latin characters, often with digits: 3 for ع, 7 for ح). Models never exposed to it struggle on inputs your users consider normal, and annotation guidelines need explicit rules for it (our playbook on how to annotate Arabic text covers them).

Which to train and evaluate on: a decision matrix by use case

The right MSA-to-dialect mix depends on the channel, not on the language label on the project. The matrix below is a starting point for the most common deployments. Each row separates what users send from what you should train and test on.

Three rules fall out of the matrix. Train on the register of the input. Evaluate on the register of the real traffic, split by variety. Treat the output register as a product decision that you test with native users. MSA-only data is defensible only when inputs are genuinely formal. Our guide to evaluating Arabic LLMs covers building per-dialect test sets. When you read public leaderboards, check whether results are split by variety at all; Arabic LLM benchmarks explained shows what each one actually measures.

Run a register audit before you commit budget

1. Sample live traffic per channel. A few hundred recent items per channel is usually enough to see the shape (illustrative; use more for rare varieties). Include audio, not just text logs.
2. Have native speakers tag each item. Record MSA, dialect (which variety), mixed, Arabizi or another language, plus the rater's own native variety.
3. Compare against your data. Put the traffic mix next to the mix in your training and test sets. The largest gaps are where the model will underperform.
4. Build test sets before training sets. Per-variety gold sets tell you whether new data is working, and they are much smaller than the training sets they will justify.

Why scale alone doesn't fix it

The instinctive answer (scrape more, train bigger) runs into the same wall: the dialectal data mostly is not on the public web, and what is there is unlabeled, noisy and unevenly distributed across varieties. Machine-translating English data into Arabic does not close the gap either. Translation tends to produce MSA-shaped text with English idiom underneath, which reinforces the register you are trying to move away from.

Published evidence points the same way. The AraDiCE benchmark (2024), built from about 45,000 human-edited samples in Gulf, Egyptian, Levantine and MSA, found that Arabic-specialized models such as Jais and AceGPT beat general multilingual models on dialect tasks. It also found that significant challenges remain in dialect identification, generation and translation. Our own LabelBench v0.1 audit found a similar pattern on its fixed held-out manifest. Qwen 2.5 3B reached 22.4% on five-region dialect identification, where a balanced guesser scores 20%, and it labeled 75% of Gulf items as Egyptian. Arabic-specialized Fanar 1 9B reached 47.8%: much better, but still below a simple supervised character model at 69.8%. Specialization helps. It does not remove the need for task-specific dialect data.

Closing the gap requires deliberately manufactured data: dialectal conversations collected or generated with native speakers, transcriptions by people who actually speak the variety, preference rankings from raters who can hear when a Saudi answer drifts into Egyptian, and evaluation sets stratified by dialect rather than averaged into a single flattering number. This is slower than scraping, but it targets the per-dialect performance that production traffic actually tests.

How to think about coverage

Three questions tell you most of what you need to know about an Arabic data strategy, yours or a vendor's:

1. Which varieties, specifically? "Arabic" is not a coverage statement. Saudi Arabia alone has Najdi, Hijazi and eastern Gulf varieties, and the wider Gulf family adds Emirati, Kuwaiti and more. Coverage should be named at the variety level and matched to your markets.
2. Who produced the labels? Dialect judgment is hard to delegate to non-native crowds or to models. If a label pipeline cannot tell you the rater's native variety, it cannot vouch for dialect quality.
3. How is quality measured per dialect? An aggregate accuracy number hides exactly the failures you care about. Insist on per-variety gold sets and per-variety reporting.

This is how we approach dialect work at Bayanat Labs. We cover 25+ Arabic varieties, including Gulf (Saudi/Najdi, Emirati, Kuwaiti), Levantine, Egyptian, Iraqi and Maghrebi. The work is done by vetted native speakers who pass dialect screening before they touch client data, and it is calibrated against gold standards with adjudication and rework loops. Our Arabic dialect data collection and annotation service starts with a fixed-scope pilot and a quality report, usually within two weeks, so you can see the quality evidence before you scale.

For Saudi markets, licensed speech is available now. Bayanat Voice includes two separate 1,000-hour Saudi collections: spontaneous speech, and conversational speech with human transcripts, timestamps and speaker attributes. Apply the first question above to both: request the variety breakdown and speaker mix before you license.