Hisham AlhussainA lot of the AI work I do is for Arabic-speaking users, and I want to talk about something that comes up on almost every project: building an assistant that works properly in Arabic is not the same as building an English one and translating it.
It sounds obvious when you say it out loud. But I've lost count of how many times I've seen the "translate in, translate out" approach, and it almost always shows.
Arabic isn't one language in practice
Modern Standard Arabic is what you see in formal writing and the news. But people don't text like that. On WhatsApp, in chat, in voice notes, people write in their dialect: Gulf, Egyptian, Levantine, Maghrebi, and they all differ quite a bit.
So the first question on any project is: who are the users and how do they actually write? An assistant that only handles formal Arabic will feel stiff and miss a lot of real messages. If your users are in Riyadh or Dammam, it needs to get Gulf dialect, including the casual, abbreviated way people type.
Code-switching is the norm
Lots of people mix Arabic and English in the same sentence, sometimes in the same word. Technical terms, brand names, and dates often stay in English. Some people write Arabic in Latin letters with numbers standing in for sounds ("Arabizi").
Your assistant needs to understand all of that and reply in the right language. My rule of thumb: answer in the language and register the user used. If they write casual Gulf Arabic, don't reply in formal MSA. It feels like talking to a government form.
The practical gotchas
A few things that bite almost every time:
- Tokenizer costs. Arabic text often takes more tokens than the same content in English, depending on the model. That affects cost and context budget, so measure it on your actual data.
- RTL in the UI. Mixed Arabic and English text, numbers, and punctuation can render in confusing orders. Test with real mixed content, not just clean Arabic sentences.
- Normalization. Different forms of alef, optional diacritics, and Arabic versus Western numerals can break search and matching if you don't normalize.
- Names and dates. Hijri and Gregorian dates, and names that can be transliterated five different ways.
Evaluate in Arabic, with Arabic speakers
This is the big one. Your eval set needs to be in the languages and dialects your users actually use, written or reviewed by native speakers. A model that scores great on English benchmarks can be noticeably weaker in dialect. I've seen it happen.
It's also great to see more investment in Arabic-first models in the region, like ALLaM from Saudi Arabia and Jais from the UAE. They're worth including in your evals, especially for dialect-heavy use cases.
Respect the culture, not just the language
Tone matters a lot. Greetings, politeness conventions, and religious expressions that people commonly use all affect whether an assistant feels natural or robotic. Getting these right is the difference between something people tolerate and something they actually like using.
Building Arabic-first takes more effort upfront. But it's the difference between an assistant that technically supports Arabic and one that Arabic speakers actually want to talk to.