Why Arabic-first software is more than translating an English UI

I have built bilingual products several times now — a visitor management platform, corporate sites, a legal AI product where Arabic is the primary language of the domain. The lesson repeats: adding Arabic at the end is more expensive than designing for it from the start, and the result is worse.

Here is what actually changes.

Direction is structural#

The mistake is thinking RTL is a stylesheet flip. It is not. What changes:

• Reading order, which changes what someone sees first
• Field order in forms, which changes the logic of a sequence
• Icon direction — arrows, chevrons, progress, anything with a "forward"
• Navigation position, and with it the visual hierarchy of the page
• Table column order, which changes which column is primary

Modern CSS logical properties handle a lot of the mechanical part, and that is genuinely helpful. What they cannot do is tell you that a form flowing left to right did so for a reason nobody wrote down, and that the reason does or does not survive mirroring.

That is a design judgement, and someone has to make it per screen.

Typography is not shared#

Arabic and Latin have different vertical rhythm. Arabic script sits differently against a baseline, has different ascender and descender behaviour, and needs more line-height to breathe.

Take a layout tuned for Latin at 1.5 line-height, put Arabic in it, and it looks cramped. Not broken — cramped. Which is worse, because nobody files a bug saying "the line-height is subtly wrong", they just find the Arabic version slightly unpleasant and use the English one.

Font size needs attention too: Arabic set at the same optical size as Latin usually wants to be a touch larger.

Terminology is a domain problem#

This is the one that surprises people.

A translator gives you an accurate translation. What you need is the word practitioners actually use, which is frequently different — sometimes an English loanword that has become standard in the industry, sometimes a specific Arabic term that a general translator would not choose.

Get this wrong and the interface is technically correct and reads as foreign to the people using it. Getting it right means asking someone who does the job, not someone who knows the language.

Hierarchy has to hold in both directions#

Content structure that reads clearly in one direction can flatten in the other. A layout where importance is signalled by left-alignment inherits a different meaning when mirrored. Emphasis that comes from position rather than from weight or size does not survive the transition.

The fix is not complicated — it is just that you have to look, in both directions, before it is built.

What "designing bilingually" means concretely#

It means the design review for every screen happens twice, in both directions, before implementation. Not that a translation file is added at the end.

The second direction is where you find the assumptions. It roughly doubles the review effort at design time and saves considerably more later, because the alternative is discovering the same assumptions after they are encoded in components.

The test#

Open the Arabic version and read it without comparing it to anything. Does it feel like a product, or like a translation of a product?

Users who only read Arabic will feel that difference on every screen. They will not tell you about it. They will just use it less, or reach for the English version at a disadvantage, and either way the data you get out of the system gets worse.