Arabic-first interfaces are not mirrored English interfaces

Most enterprise software is designed in English and localised later. For a citizen portal in Riyadh or Ramallah that order is backwards. The primary user reads Arabic, types Arabic, and expects dates, numbers and names to behave the way they do on paper and in the office that issued the paper. Arabic added at the end is a translation layer over an English product. Arabic first is a different product that happens to also work in English.

The difference shows up in places that have nothing to do with text direction. Direction is the part everyone knows about, and modern layout engines handle it reasonably well. The expensive problems are in typography, in data, in validation and in search, and they surface after launch as support tickets that look unrelated to each other.

Typography is the first real decision

Choose the Arabic face first and the Latin companion second. Doing it the other way round gives you a Latin face picked for its personality and an Arabic face picked for whatever shipped alongside it, and the two will disagree about weight and colour on the page.

Arabic needs more vertical room than Latin at the same nominal size. Ascenders, descenders and the marks above and below letters occupy space that a line-height inherited from a Latin design will crop or crowd. We set line-height for Arabic and let the Latin sit comfortably inside it, never the reverse. Letter-spacing is the other trap. Tracking that flatters Latin headings will break the joins between Arabic letters, which is not a stylistic degradation, it is a legibility failure. The rule is simple: no positive letter-spacing on Arabic text.

Then check small sizes on a real phone in daylight. Table cells, form hints, error messages and legal footnotes are where Arabic legibility breaks first, and they are also where a citizen reads the sentence that determines whether their application is accepted. A face that is elegant at 32px and mushy at 13px is the wrong face for a government service.

The data problems nobody budgets for

Digits are the first one. A citizen may type Arabic-Indic digits or Latin digits, sometimes both in the same field, because the keyboard on their phone offers one and the form they copied from used the other. Accept both, normalise on input, and store one canonical form. Then decide separately how digits are displayed, which is a presentation choice and may differ by context. Validation that rejects a perfectly valid phone number because of the digit form is the single most common Arabic bug we are asked to fix in inherited systems.

Then normalisation of letters. Alef comes in several forms, the final yaa and alef maqsura are frequently interchanged, and taa marbuta is often typed as haa. A citizen searching for their own name will spell it one way today and another way next month. If search compares raw strings, they will be told they have no records. Normalise for comparison and search, aggressively. Do not normalise what you store.

That distinction matters enough to state plainly. Store the name exactly as the citizen wrote it, with the hamza, the diacritics and the spelling they chose, because that string is what appears on a legal document and what they will check against their ID. Normalise a separate search key derived from it. Systems that normalise at write time destroy information they can never recover, and the person who notices is the one whose name was quietly changed by a database.

Dates are the third. Where the law expects Hijri, show Hijri, and show Gregorian alongside it where a citizen needs to reconcile the two. Store one canonical timestamp and convert for display. Never store a formatted date string, because the conversion rules and the calendar the department cares about will both outlive your formatting choice.

A scenario from a service counter

A citizen comes to renew a registration. The clerk searches by name, spelled with a final yaa. The record was entered eight years ago with alef maqsura. No results. The clerk tries the national ID, which the citizen reads aloud from a card printed with Arabic-Indic digits while typing on a keyboard set to Latin. The field validation rejects the mixed string without saying which character it disliked. The clerk now has a queue behind them and a citizen who is being told, in effect, that they do not exist.

Nothing in that story is a translation problem. It is a search-normalisation bug, an input-normalisation bug, and an error message that names no cause. All three would have been found in the first week by anyone who tested the system in Arabic with real names. All three are, in our experience, the actual content of the complaint that reaches the department director as "the new system does not work".

What changes in the design and build process

Design reviews happen in Arabic first, on a phone, with real data. Real data means the longest genuine name in the dataset, not a placeholder. Arabic has no reliable expansion ratio against English, so guessing at label lengths does not work. Put the real strings in.

Mirror what carries direction and leave alone what does not. Back arrows, progress indicators, sliders and anything implying forward motion are mirrored. Logos, clock faces, media playback controls, and charts whose axis is a physical quantity are not. Getting this wrong in either direction is noticed immediately by users and almost never by a monolingual reviewer.

Mixed content needs explicit handling. An Arabic sentence containing a Latin product name, an IBAN, a file name or a URL is bidirectional text, and the default rendering will sometimes place punctuation at the wrong end of the line. It looks like a small cosmetic issue until the line is a reference number a citizen has to copy.

Every screen is reviewed in Arabic by a native speaker on the team before it is reviewed in English on a desktop. We have a team spread across Dubai, Riyadh and Ramallah, so this is a scheduling habit rather than a hiring problem. It is a small discipline and it removes a whole category of post-launch complaints.

When English-first is the right call

We would not argue for Arabic-first everywhere. An internal administrative console used by a dozen technical staff who work in English all day is better built in English, quickly, and left that way. Building it bilingually costs real time and buys very little, and the time is better spent on the citizen-facing surface where hundreds of thousands of people will meet the department.

The same applies to developer-facing artefacts. Log messages, configuration keys, exception text and internal API field names should stay in English, because they are read by engineers, searched against international documentation, and pasted into issue trackers. Translating them makes the system harder to operate and helps nobody.

The honest boundary is this: anything a citizen reads, or that a clerk reads aloud to a citizen, is Arabic-first. Anything read only by the people running the system can be whatever that team works in. Deciding this explicitly at the start is much cheaper than discovering halfway through that half the error messages surfaced to citizens are untranslated strings from a library.

What it costs, and what to ask a vendor

The added cost of doing this properly is smaller than most departments assume, but it is front-loaded. Font licensing for a good Arabic family is a real line item. Design time increases because every screen is reviewed twice. Test data preparation takes a few days, because you need genuine names with the awkward characters in them. Against that, you avoid a localisation retrofit, which in inherited systems we have been asked to repair is consistently more expensive than the original interface work.

For an evaluation committee, three questions separate vendors who have done this from vendors who intend to. Ask which Arabic typeface they propose and why, and whether the Latin face was chosen to match it or the other way round. Ask how their system normalises Arabic input for search, and specifically whether normalisation happens at write time or at comparison time. The right answer is comparison time, and a vendor who has shipped an Arabic system will know why.

Then ask for a live demonstration rather than a screenshot deck. Search for a name spelled with alef maqsura when the record uses a final yaa. Enter a number with mixed Arabic-Indic and Latin digits. Display a record whose name is unusually long, on a phone. Switch the interface to English and back and confirm nothing was lost. Those four tests take ten minutes and tell you more about a bilingual system than a day of presentations.