Arabic software development, properly mirrored

Arabic support is an architecture decision, not a content task. Taken at the start it costs almost nothing; taken at the end it is a rewrite. It is also full of traps that never show up in a translation review — bidirectional text quietly reverses part numbers and IBANs, and numerals are a choice somebody has to make per context.

What you get

• Layout written with logical properties, so it mirrors itself
• Technical codes isolated so bidi cannot reorder them
• An Arabic font stack and line height of its own
• Copy declared as a pair, so a half-translated screen cannot ship

In more detail

Arabic is not a separate line on the quote

Every screen we build exists in English and Arabic, and it is not a line item you can remove. What moves the project figure is scope — how many departments share one data model, how much history has to migrate, what it has to integrate with. The second language is not on that list, and there is no cheaper version of our work with the Arabic taken out.

Adding Arabic to software you already run

It turns on one thing: whether left and right are hard-coded into the layout. If they are, every spacing, border and alignment gets mirrored by hand. Written with logical start and end instead of left and right, it mirrors itself, and that one decision is most of the difference between an afternoon of work and three weeks of it. Tell us on a call what it is built with, and the written scope that follows says whether it is a change or a rebuild.

Documents, invoices and PDFs, not just screens

The Arabic version people judge you on is the one they receive. Invoices, clearance letters and reports are generated from the record in either language, so the document matches the screen instead of being typed again. MRP publishes a source-cited fee catalogue whose totals are VAT-inclusive, with government fees marked as disbursements that carry no VAT. JD PROP AI issues its clearance letters in English and Arabic straight from the record.

Which numerals go where

Somebody has to decide this per context, so here is the rule we use. Arabic-Indic numerals in narrative text, where they read natively. Latin numerals in financial tables and in anything a person copies out — that is what a UAE finance team expects, and what gets pasted into a bank portal. The failure mode is letting a formatting library apply one rule to both.

Proof, not a promise

• MRP Businessman ServicesPublish what the industry hides
• ComplyGCCAML / KYC for UAE fintechs
• Cafe demoThe licence says cold and hot

Related reading

• Building Arabic software: six things that break, and none of them are translationTranslation is the easy half. The half that ships broken is layout direction…

Common questions