--- title: "Arabic-first is not translation" summary: "Direction, numerals, name order, segment length and register. A localised product differs from a translated one in ways that show up in the first minute." canonical: https://cpaas.co/en/insights/arabic-first-is-not-translation kind: article depth: applied origin: original published: 2026-06-26T11:34:07.986Z updated: 2026-09-08T11:34:08.167Z topics: ["MENA", "Customer Experience", "Conversational Marketing"] language: en --- # 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. ## Direction is a layout property, not a text property 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. ## Numerals are a choice, and consistency matters more than which 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. ## Text length changes, in both directions 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. ## The SMS segment problem 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. ```diagram:stats 160 | GSM-7 characters | What a single Latin-script SMS segment holds. 70 | UCS-2 characters | What a single Arabic segment holds. Any Arabic character switches the whole message. 2.3 | Typical multiplier | What the same notification costs in Arabic once segmentation is counted. > A template that fits in one segment in English routinely takes three in Arabic. Nobody notices until the volume is real. ``` 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. ## Register 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. ## Names, dates and forms 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. ## Why this is a growth question, not a polish question 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. ## What actually has to change Translation changes the strings. Everything below is what changes around them, and none of it is caught by a translation memory. ```diagram:blocks # The layers a second language touches Layout direction | Logical properties throughout. A stylesheet full of left and right has to be rewritten, not mirrored. Numerals | Western or Eastern Arabic digits, chosen once and applied everywhere. Mixing them inside one interface is the tell. Text expansion | Arabic runs shorter than English in characters and longer in rendered width. Both directions break fixed layouts. Encoding and segments | Arabic SMS is UCS-2: 70 characters per segment, not 160. A message length that was free is now a cost. Register | Modern Standard for anything official, dialect for anything conversational. Getting this wrong reads as a machine. Names and forms | Given-name order, honorifics, and address formats that a Western form field cannot hold. > Only the first box is a design task. The rest are decisions with a cost attached, which is why they get deferred and then discovered. ``` ## What to take away 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. --- Published by the company behind five products in this category. Those products appear in this site's directory alongside competitors under the same published criteria and are labelled as its own. Editorial content does not recommend them.