Bilingual software isn't a translation problem. It's an architecture problem.

Most enterprise platforms treat Arabic as a localization layer. It isn't. Treating it as one is how you end up with a system that's technically bilingual and operationally English-first.

If you've ever asked a vendor "does it support Arabic?" and received an immediate "yes," you should be suspicious. The honest answer to that question takes longer than a sentence - because Arabic support exists on a spectrum, and most of what gets sold as bilingual is in fact English with an Arabic skin.

The difference matters most to the people you're least likely to interview when buying software: the Arabic-speaking users who'll actually use it every day.

Here's what we've learned, after a decade of building Arabic-first systems for UAE government and enterprise clients.

The data model is the first place it breaks

Most platforms treat language as a presentation concern. The data is stored once, in one canonical form, and a translation layer renders it in whatever language the user has selected.

This works fine for static labels: Save, Cancel, Submit. It collapses immediately for content. Real bilingual content isn't a one-to-one mapping. A press release in Arabic isn't the English release translated; it has different framing, different emphasis, and often a different publish date. A case-management record might have notes in Arabic from one user and notes in English from another - both true, neither a translation.

If your data model has a single title field with a language flag, you've already lost. Bilingual systems need every translatable concept to be a first-class pair (or n-tuple), with independent lifecycle.

Search is the second place it breaks

Arabic search is genuinely difficult. The script has multiple forms of the same letter depending on position. Diacritics (the small marks above and below letters) are usually omitted in writing but matter for meaning. Common words have spelling variants. There's no universal stemming algorithm the way English has.

Off-the-shelf search engines handle this in default configurations badly. A user typing محمد should find results that spell the same name without diacritics, with variant ya/alef-maqsura endings, in a phrase or alone. Most platforms find none of the above.

Solving this isn't impossible - there are good Arabic-aware analyzers - but you have to design for it explicitly, and test against real native-speaker queries, not the ten English words your QA engineer can type with an Arabic keyboard.

RTL is the easy part - and people still get it wrong

Right-to-left layout is mostly a CSS problem. Use logical properties (margin-inline-start, not margin-left). Set dir="rtl" on the root. Done.

Except: people don't. We still see enterprise platforms - sold and deployed in the UAE - where the Arabic version is the English layout with the text right-aligned. Icons point the wrong way. Progress bars flow the wrong way. Form labels sit awkwardly. It's the software equivalent of a sign hand-translated by a tourist.

RTL is the cheapest part to get right. The fact that most platforms don't tells you what priority Arabic gets internally.

Typography is the part you'll only notice if you read Arabic

Arabic script is connected. Letters change shape based on neighbors. Numerals can be Arabic-Indic (٠١٢٣) or Western (0123) depending on context. Most fonts that "support Arabic" do so badly - letterforms feel cramped, kerning is wrong, line height is mismatched to the Latin fallback.

The good news is that the available Arabic typeface options have improved enormously in the last five years. The bad news is that you have to actively choose them - defaults are still poor.

Editorial workflow is the part that surprises people

Once you accept that bilingual content has independent lifecycle, editorial workflows get interesting. Who writes the Arabic version - the same author, a translator, an editor? Do they publish simultaneously, or is one a "primary" and the other follows? What happens when one language is updated and the other isn't?

These aren't technical questions. They're operational ones. But the system has to support whatever answer the client lands on - or the client ends up working around the system, which is when content quality starts to drift.

The shortest test: ask a native Arabic speaker to use it

If you're evaluating a "bilingual" platform, sit a native Arabic speaker in front of it for thirty minutes and watch them try to do real work. Not a demo. Not a guided walkthrough. Real work - write something, search for something, navigate to something specific.

You'll learn more in those thirty minutes than from any vendor matrix.

If you're building bilingual software - or evaluating a platform that claims to be - we'd be glad to compare notes. Book a call.