The Arabic conversation tends to happen late. The architecture is settled, the retrieval pipeline works, the English demo lands well with the steering committee, and then someone asks the obvious question: when does it speak Arabic? The answer comes back as a line item. Localisation. A translation layer, a right-to-left stylesheet, a task appended to the end of the plan.
That line item is where the project quietly starts to fail, usually after go-live.
Arabic is not a language pack you install on a finished system. In an AI system it is an architecture decision, and it reaches into the data layer, retrieval, evaluation and the interface itself. Postponing it does not defer a task. It builds an English-shaped system and then asks that system to behave like an Arabic one.
Here is what that actually costs.
Fluency Is One Skill. Understanding Your Customers Is Another.
A model can be genuinely fluent in Modern Standard Arabic and still be useless on your customers' Arabic. MSA is the Arabic of press releases, policy circulars and annual reports. It is not the Arabic in your ticket queue.
What actually arrives:
- Gulf and Omani dialect, with vocabulary and sentence shapes that never appear in a formal document.
- Code-switching: Arabic and English inside a single sentence, often mid-clause ("الـ transfer ما وصل"). This is not sloppiness. It is how your customers and your own staff genuinely write.
- Arabizi, Arabic written in Latin letters with digits standing in for sounds Latin script lacks: the 3 for ع in "3arabi", the 7 for ح in "mar7aba".
- Informal spelling: dropped hamzas, missing dots, English loanwords rendered phonetically in Arabic script.
Fluency is the ability to produce good Arabic. Comprehension is the ability to understand bad Arabic. Your customers send the second kind.
Your Spelling Problem Is a Retrieval Problem
Arabic writes the same word in several legitimate ways. A human reader glides over the difference. A retrieval index does not.
- Alef variants: أ / إ / آ / ا
- Ya and alef maqsura: ي / ى
- Ta marbuta and ha: ة / ه
- Hamza placement, mid-word and final
- Optional diacritics (tashkeel), present in one document and absent in the next
- Tatweel (kashida), which stretches a letter visually and changes the string underneath
- Arabic-Indic versus Western digits: ٠١٢٣ against 0123
The same customer name, written with a hamza in the CRM and without it in the contract, indexes as a different token in each. The same product term appears one way in your manual and another way in your user's question, and the two never meet.
The failure mode is the worst one available. The system does not throw an error. It does not flag low confidence. It answers "I don't have that information" about data it is sitting on, and the log looks clean.
The fix is cheap early and expensive late: a documented normalisation policy, applied at ingestion and applied by the same rules at query time. Leave it late and it means re-indexing the whole corpus.
One Arabic Word Carries What English Spreads Across a Phrase
Arabic is richly inflected, and it stacks meaning onto a single word. The definite article fuses to the noun. Short prepositions and the conjunction attach to the front. Pronouns hook onto the back. وبكتابهم is a single orthographic word carrying a conjunction, a preposition, a noun and a possessive.
English-tuned keyword matching stumbles here. Chunking rules written for English sentences cut in places that make no sense in Arabic. What you need is retrieval that understands stemming and lemmatisation, not a swap of your embedding model for one whose model card says it supports Arabic.
There is a second, quieter effect. Arabic script generally consumes more tokens per unit of meaning than English in mainstream tokenisers. The direction is what matters, and it is clear without any figure: less room in the context window, slower responses, higher cost per call. You do not need a number to plan for this. You need to stop assuming your English budget transfers.
The Real Corpus Is Paper
Enterprise Arabic does not live in a tidy database. It lives in scans, in PDFs of scans, in faxes, in stamped and countersigned forms, in handwritten margin notes, in tables that mix Arabic and English on the same page.
Arabic OCR is materially harder than Latin OCR, for reasons that are structural rather than incidental. The script is cursive, so letters join and change shape by position. Ligatures fuse glyphs. I'jam — the dots that distinguish ب from ت from ث — is exactly the detail a poor scan destroys first. Layout runs right to left, in tools built on the opposite assumption.
This is where Arabic projects die. Not at the model. At the data layer. Any effort spent tuning the model before the data layer is sound is effort spent on sand.
Right-to-Left Goes Deeper Than the Stylesheet
Setting dir="rtl" is the easiest part and the smallest part.
Bidirectional text is where it gets real. Mixed Arabic and English strings, numerals, IBANs, dates, national ID numbers and punctuation all reorder between logical and visual sequence. A question mark lands at the wrong end of a sentence. An IBAN inside an Arabic sentence renders in an order nobody intended. A due date is misread in a document that carries legal weight.
And mirroring the interface is a product decision, not a developer's. Which icons flip? Do progress bars run the other way? Do charts? Do you mirror a workflow diagram, or does mirroring it break a mental model your users already hold? A backlog item will not answer these questions, and they should not be left until after the UI is built.
If You Cannot Measure Arabic, You Cannot Ship Arabic
Teams tend to build one evaluation set, in English, and assume Arabic tracks it. It does not.
You need an Arabic-first evaluation set built from your own material: your tickets, your documents, your customers' questions as they actually wrote them. And it needs native reviewers from the same market, judging what a score cannot see:
- Register: is formal MSA right here, or does it read cold?
- Tone: does it sound like your brand, or like a translation of your brand?
- Dialect and Arabizi handling: does it understand, or does it politely deflect?
- Refusal behaviour: does the model refuse in Arabic where it refuses in English? Often it does not, and that gap is a compliance problem, not a quality one.
This is also where a constraint arrives that you cannot defer. Evaluating and tuning in Arabic means handling real customer data. With Oman's Personal Data Protection Law and comparable GCC frameworks in force, where that data lives and who can reach it become genuine engineering constraints, not contract clauses. Decide where your Arabic data lives, and who may look at it, before you collect it.
Register Is a Brand Decision, Not a Model Default
A bank, a ministry and a retailer do not speak the same Arabic. Formal MSA signals authority and distance, which a ministry may want and a retail app almost certainly does not. An approachable Gulf register builds warmth, but it can read as unserious in a legal notice.
If you do not decide, the model decides. It tends to default to a stiff MSA that reads like it was translated from English, which is precisely the message you did not want to send to an Arabic-speaking customer. Write the register into the spec, and evaluate against it.
What to Do Instead
None of this needs a bigger budget. It needs the decisions to happen in the right order.
- Put Arabic in discovery, not in the plan. Arabic examples in the spec, Arabic queries in the acceptance criteria, Arabic screens in the design review.
- Normalise at ingestion. One documented policy for alef, ya, ta marbuta, hamza, tashkeel, tatweel and digits, applied to documents and queries by the same code.
- Make retrieval Arabic-aware. Stemming and lemmatisation, chunking that respects Arabic sentence structure, and tests that prove a query in one spelling finds a document written in another.
- Fix the data layer first. Prove your Arabic OCR on your ugliest real documents — the stamped, the skewed, the handwritten — before anyone tunes a prompt.
- Build the Arabic eval set from your own material, and put native reviewers on it. Sample from production continuously, not once.
- Decide register up front and write it down.
- Test bidi in the real interface, with real IBANs, dates and IDs. Not in a mockup.
- Measure Arabic separately in production. A single blended quality metric hides Arabic failure until a customer finds it for you.
The Takeaway
Arabic is not a translation layer over an English system. It is a set of decisions about data, retrieval, evaluation and interface that are cheap to make at the start and expensive to retrofit. Teams that treat it as a feature to add later end up rebuilding the parts they thought they had finished.
In the enterprises we work with, the systems that handle Arabic well are not the ones running the most sophisticated models. They are the ones that took the language seriously before they took the model seriously.
If Arabic is part of how your customers actually talk to you, it belongs in the architecture, not the backlog. Book a consultation at apexaion.ai and we will look at your Arabic data, your retrieval and your evaluation as they stand today, and tell you plainly what will break.