Translating an English insurance journey into Arabic is the last step, not the first. The real work is direction, dates, names, numbers and tone — decided at the design stage, not patched afterwards.
Most insurance products in the Gulf were designed in English and translated into Arabic. You can tell within ten seconds of opening them: the layout mirrors awkwardly, the dates confuse, the policy terms read like a legal dictionary translated by committee. Arabic-first means the opposite order — design the journey for the Arabic-speaking majority, then derive the English. Having built insurance journeys both ways, we can be specific about what the difference actually consists of. It is not translation quality. It is about a dozen structural decisions, and most of them are irreversible once the product ships.
Direction is a data problem, not a CSS problem
Flipping a layout right-to-left is the easy part; every modern framework mirrors a screen. The hard part is that an Arabic insurance screen is never purely right-to-left. Policy numbers, IBANs, vehicle plates, phone numbers and email addresses are left-to-right tokens embedded in right-to-left sentences. Get the bidirectional handling wrong and a policy number renders with its digits visually reordered — in a document where that number is the contract.
The discipline that works: treat every machine-readable identifier as an isolated directional island, test each one with mixed content, and never concatenate translated strings around embedded values. Sentence templates that read naturally when a left-to-right value lands inside an Arabic sentence have to be written that way from the start; they cannot be patched by a translator working in a spreadsheet of loose phrases.
Dates, numbers and the two-calendar reality
Insurance is a dates business — policy start, expiry, claim windows, grace periods — and the Gulf runs on two calendars. Official documents may carry Hijri dates while daily life mixes both. An Arabic-first product decides, screen by screen, which calendar leads and always shows an unambiguous form: day, written month name, full year. A renewal notice that says your policy expires 03/04 is a complaint generator in any language; across two calendars it is a coverage gap generator.
Numerals are a quieter decision. Arabic text can carry either Western digits or Eastern Arabic digits, and regional preference varies. Whichever a product chooses, premiums, dates and policy numbers must use it consistently — a screen mixing both digit systems reads as carelessness precisely where the customer is checking what they will pay.
Names are structured data, and the structure is Arabic
Arabic full names are typically four parts — given name, father, grandfather, family — and identity systems in the region expect them that way. A first-name last-name form built for Western names mangles the data before the insurer, the regulator or the ID system ever sees it. Arabic-first means the name model matches the national ID structure, transliteration to Latin script is stored rather than improvised at document time, and search is tolerant: the same name legitimately appears with and without hamza, with different taa marbuta endings, with or without diacritics. Claims teams lose real hours to lookups that fail on an orthographic variant of a correctly spelled name.
Insurance Arabic versus human Arabic
The deepest localisation problem is register. Formal insurance Arabic — the language of policy schedules and exclusions — is precise and largely unreadable to a normal buyer. The temptation is to paste it into the interface because it is legally safe. The result is a journey where the customer understands the buttons but not the product.
The craft is running two registers deliberately: plain, direct Arabic for the journey — what is covered, what is not, what you pay, in short declarative sentences — with the formal wording one tap away as the contractual source of truth. Writing plain Arabic cover summaries is genuinely harder than writing plain English ones, because the gravitational pull of formal register is stronger; it needs a native-speaking writer with product judgement, not a translation pass at the end of a sprint.
- Decide direction handling, calendar policy, digit system and name model before the first screen is designed; retrofitting any of them is a rebuild.
- Write Arabic copy first and derive English, not the reverse — the language with the harder constraints should set the layout and the tone.
- Test with real data: real four-part names, real plates, real IBANs, both calendars, both digit systems.
- Localise the documents, not just the app. The PDF policy schedule the customer saves is the artefact they judge you by.
None of this is exotic. It is ordinary product discipline applied to the language most of the region's customers actually live in. The market has spent years proving that Arabic speakers will buy insurance through digital journeys; the products that win are the ones where the Arabic journey is the original, not the mirror.