Arabic-first is not translation

A translated product is an English product with Arabic strings. It is recognisable immediately, and it is recognisable to exactly the users you were trying to reach.

Right-to-left is not a mirror image of an English page. Some things flip — reading order, alignment, the direction a progress bar fills, which side a back arrow points. Some things do not — a play button, a clock face, a logo.

The practical route is to build in logical properties from the start (start and end rather than left and right), so the layout follows direction by construction rather than by a second stylesheet somebody maintains separately. Retrofitting this is expensive; doing it first costs nothing.

The mistake is treating right-to-left as a text attribute — set dir and hope. Direction affects layout, iconography, animation, progress, and the meaning of "next".

Use logical properties everywhere: inline-start rather than left, margin-inline rather than margin-left. A stylesheet written this way mirrors correctly without a second stylesheet. One written with physical properties needs a mirror sheet that will drift from the original within two releases.

Icons that imply direction — arrows, back buttons, progress — mirror. Icons that do not — a clock, a logo, a play button — must not. There is no automatic rule; it is a per-icon decision somebody has to make once.

Arabic content may use Western digits or Eastern Arabic-Indic digits, and usage varies by country and context. The Gulf commonly uses Western digits in commercial contexts.

The mistake is not choosing wrongly; it is mixing them in one interface — a price in one set and a phone number in the other, on the same screen.

Arabic is often more compact than English for the same meaning, which breaks layouts tuned to English string lengths just as reliably as expansion does. Test with real content, not lorem ipsum, and test the longest realistic string rather than the average one.

This one has a direct financial consequence. SMS with non-Latin characters uses a different encoding, and the characters-per-segment count drops sharply — meaning an Arabic message of the same apparent length costs several times more to send than its English equivalent.

Any cost model built on English message lengths will be materially wrong for Arabic traffic. This is not a rounding error; it is a multiple.

This is the one that turns up on an invoice rather than in a design review.

The practical consequence: write the Arabic template to the Arabic limit, not to a translation of the English one. A 155-character English message translated faithfully becomes a three-segment Arabic message; the same message written for Arabic in 68 characters is one segment and reads better.

Modern Standard Arabic reads as formal — appropriate for a bank, distancing for a small retailer. Dialect reads as familiar and is regional, so a Gulf dialect can feel foreign in North Africa.

There is no universally correct answer, only a decision that has to be made explicitly by someone who knows the market. Making it implicitly, by handing strings to whichever translator was available, is how a friendly brand ends up sounding like a government form.

Modern Standard Arabic in a support chat reads the way formal written English would read in a text message: correct, and wrong. Dialect in a legal notice reads as unserious.

The split is roughly: official notices, terms, receipts and anything with legal weight in Modern Standard; support conversations, prompts and encouragement in the register your customers actually use, which varies by market. This is the decision that most needs a native speaker and least tolerates a translation vendor's default.

Name fields that assume first and last are wrong here more often than they are right. Prefer a single full-name field unless you have a specific reason.

Two calendars are in common use. If your product touches dates a customer will compare with something official, know which calendar they are comparing to.

In much of this region, a business's entire customer relationship already lives inside a messaging app. Arriving with an interface that reads as foreign does not lose a little conversion at the margin — it disqualifies you from the channel where the relationship actually happens.

The Arabic-speaking market is large, under-served, and unusually loyal to products that treat the language as native rather than as a localisation target. The bar is low because most competitors translated.

Arriving with correct direction, consistent numerals, single-segment templates and the right register is not polish. It is the difference between being usable and being preferred, and it is visible to a customer within the first screen.

Translation changes the strings. Everything below is what changes around them, and none of it is caught by a translation memory.

Direction is layout, not text. Pick a numeral system and never mix. Write Arabic templates to the Arabic segment limit rather than translating to it. Choose register per context, with a native speaker. And do all of it before the volume arrives, because every one of these is cheaper to decide than to migrate.