Blog

Why Arabic machine translation is genuinely hard.

One Arabic word can be five English ones, documents are written in a register the web barely contains, and the page flips direction when the language changes. A plain guide to why generic engines struggle with formal Arabic, and what Arabic-first engineering fixes.

Machine translation has improved so much in the last decade that it is easy to assume the problem is solved, and for some language pairs it nearly is. French to English is a short trip: similar word order, shared vocabulary, mountains of parallel training text. Arabic is a different journey entirely. If you have ever run a formal Arabic document through a generic online translator and watched a ministry change its name halfway down the page, you have seen the gap. This post walks through why Arabic machine translation is structurally hard, and what building for Arabic on purpose involves.

Arabic is not just another language for a translation engine. It packs a sentence into a word, writes in the opposite direction, and grows by a fifth or more when it becomes English.

One Arabic word, several English ones

The first problem is morphology. Arabic builds words by attaching clitics, small grammatical particles, directly onto a stem: conjunctions on the front, prepositions and the definite article after them, object and possessive pronouns on the end. The single written word "وسيكتبونها" unpacks into "and they will write it", five English words carried by one Arabic token. "لمدرستهم" is "for their school". This is normal Arabic, not an edge case.

For a translation model this is expensive in every direction. The vocabulary explodes, because one stem surfaces in hundreds of inflected forms, each rarer than the last, so the model sees any given form less often during training. Alignment gets harder, because one source token maps to a variable-length span of target words, and a mistake in segmenting the clitics ripples through the whole sentence. And dropped pronouns and lost negations become a characteristic Arabic failure mode: the sentence reads fluently and says subtly less than the original.

Diglossia: the register your documents are written in

Arabic lives in two registers at once. Modern Standard Arabic (MSA) is the written language of contracts, regulations, annual reports, and official correspondence. Spoken dialects dominate everyday life and, increasingly, the informal internet. That split, called diglossia, quietly corrupts training data. When engines hoover up Arabic text from the web, they get a soup of MSA, dialect written with no standardized spelling, and social-media shorthand, all labeled simply "Arabic". The formal institutional register that governments and enterprises actually publish in is a thin, specific slice of that soup.

The result is a model that has seen plenty of Arabic but not much of your Arabic: the fixed legal formulas, the honorifics, the precise bureaucratic vocabulary where "لائحة" (regulation), "قرار" (resolution), and "تعميم" (circular) are different instruments with different legal weight. A generic engine happily flattens them into whichever English word is statistically nearby, which is exactly the kind of error a formal document cannot absorb.

Direction and typography: correct words, broken page

Arabic runs right to left, but real Arabic documents are bidirectional: Latin acronyms, numbers, and product names sit left-to-right inside right-to-left sentences, and the rules for how they interleave are subtle enough that even native software gets them wrong. Arabic also has its own punctuation (؟ ، ؛), its own conventions for stretching words with kashida, and orthographic details like hamza seats and taa marbuta that spellcheckers in other languages never think about.

Translation makes all of this active. Going Arabic to English, the whole document flips direction: text alignment, table column order, the position of every element on a slide. A translation can be word-perfect and still arrive visually broken, with punctuation on the wrong side and mirrored layouts left unmirrored. This is why we treat Arabic and RTL handling as part of translation itself, not a formatting afterthought.

Named entities and transliteration drift

Proper names are where trust is won or lost. Arabic names have no single Latin spelling: محمد is Mohammed, Muhammad, Mohamed, and Mohammad, all defensible. Institutions are worse, because many have an official English name that is not a literal translation of the Arabic one. A generic engine translates the words it sees, so the same ministry can appear under three different English names in one document, and none of them may be the name on the ministry's own letterhead.

Transliteration drift in the wild

An annual report mentions the same government entity on pages 4, 17, and 52. A generic engine renders it literally the first time, abbreviates it the second, and transliterates part of it the third. Every individual sentence is plausible. The document as a whole now refers to three organizations that do not exist. The fix is not a smarter guess each time: it is a glossary that pins the official name once and enforces it everywhere.

Text expansion: the layout problem hiding inside translation

Arabic is compact. When Arabic text becomes English it typically grows by roughly 20 to 40 percent, and the same content simply needs more room. In a plain text file nobody notices. In a formatted document, everything overflows at once: table cells wrap, slide text spills off its shape, headings break onto second lines, and the two-page executive summary becomes two and a half. Combine expansion with the direction flip and you see why the hard part of Arabic document translation was never only the words. It is producing a publish-ready document on the other side.

Why generic engines underperform on formal Arabic

None of this means the major engines are badly built. They are built for breadth: one system, a hundred-plus languages, trained on whatever parallel text exists at scale. That mix is dominated by European language pairs and English-centric data, so lower-resource directions often pivot through English, compounding errors in both hops. Arabic gets a respectable share of generic web data and very little of the formal institutional register, and the surrounding machinery (entity consistency, bidirectional typography, layout) is out of scope entirely, because the product translates strings, not documents.

The degradation pattern follows: decent output on casual sentences, then increasingly confident flattening as documents become more formal, more legal, more precisely worded. Worst exactly where institutional work lives.

What Arabic-first actually means

The fixes are specific rather than mysterious. Train and evaluate on formal Arabic documents, not just web text, which is the register Lisan's own models, up to Lisan L3, are built to serve, with Arabic to English as the flagship pair. Treat morphology as a first-class problem so clitics segment cleanly and negations survive. Enforce glossaries and translation memory so entities and terms stay pinned across a document and across years of documents. Run Arabic-specific QA (hamza seats, taa marbuta, Arabic punctuation, length ratios that catch dropped content). And rebuild the document itself, direction flip included, so what comes out is a finished file rather than a wall of text. If you want the mechanics of how modern engines work under the hood, our academy lesson on how machine translation works is the longer version.

Arabic machine translation is hard because Arabic is rich: a morphology that compresses, a written standard that lives beside its dialects, a script that runs the other way. A system that wants to translate it faithfully has to be built for it on purpose.

Frequently asked questions

Why is Arabic harder for machine translation than European languages?

Arabic attaches conjunctions, prepositions, articles, and pronouns directly onto words, so one Arabic token can correspond to four or five English words. Add a right-to-left script, formal-versus-dialect diglossia in the training data, and far less parallel text than European pairs, and the error rate on formal documents climbs fast.

What is transliteration drift?

The same Arabic name or institution being rendered several different ways in one translation, for example a ministry appearing under three different English names across a single report. It happens because generic engines guess each occurrence independently. Enforced glossaries fix it by pinning the official rendering once.

How much does Arabic text expand when translated to English?

Roughly 20 to 40 percent is a reasonable planning range, since Arabic is more compact than English. That expansion is why translated documents overflow tables, slides, and text boxes unless the translation system rebuilds the layout as it translates.

Does TranslateX handle Arabic dialects?

TranslateX is built for written institutional documents, which are almost always Modern Standard Arabic, and that is the register its engine is optimized for. Arabic to English with native RTL and typography handling is the flagship pair.

Translate the document. Keep the design.

Right-click a file, work inside Office, or press F6 on anything on screen. TranslateX returns the same document in the other language: fonts, tables, and layout intact, terminology on brand.

Arabic, English & more · Layout preserved · On-premises available