Arabic software localisation and RTL design

Translation replaces words. Localisation changes how the interface behaves. A product can have a complete, well-written Arabic string file and still be unusable, because the things that break in Arabic are structural: reading direction, mixed-script sentences, number systems, date conventions, sorting, search, and every artefact the system generates outside the screen.

The gap shows up fastest in the places nobody tested — the invoice, the certificate, the exported report, the notification email, the printed exam paper. Those are usually generated by a different code path from the interface, and they are where an Arabic deployment loses credibility with the people signing off on it.

Right-to-left is not a text property; it is a layout property. The whole interface mirrors — navigation, sidebars, tables, breadcrumbs, form labels, progress indicators, chart axes, drawers and the direction an arrow points. Anything that carries directional meaning has to be reconsidered, and anything that does not (a play button, a clock) has to be left alone.

Doing this properly means building with logical layout properties rather than hardcoded left and right, and handling bidirectional text correctly wherever Arabic and Latin characters share a line — which, in enterprise software full of system names, identifiers and reference numbers, is almost every line.

Arabic typography follows different rules from Latin. There is no upper case and no italic; synthetic bold distorts the letterforms; connected script needs more vertical space than a Latin font at the same size, and diacritics need more still. Line height, font selection and minimum sizes have to be set for Arabic on their own terms, not inherited from the English style sheet.

Numerals are a decision, not a default. Eastern Arabic numerals (٠١٢٣) and Western numerals (0123) are both correct Arabic practice, and the convention differs by market and by document type — a ministry report and a financial export may not want the same one. The right answer is a deliberate, configurable choice, applied consistently across the interface, the exports and the search index.

Adding Arabic to a finished English product is rarely a translation project. Directional assumptions are spread across the style sheet, the components, the PDF generator, the email templates, the database collation and the search configuration. Fixed-width components break when Arabic text expands or contracts, text baked into images has to be redrawn, and strings assembled by concatenation have to be rebuilt as full sentences with placeholders before they can be translated at all.

Built in from the start, Arabic is a design constraint like any other — it shapes the component library once and then costs almost nothing per feature. Retrofitted, it becomes a parallel programme touching every layer of a system that is already in production, with regression risk on the English side as well.

Intrazero's work has been Arabic-facing from the beginning: a Cairo headquarters, offices in Dubai, Riyadh, Muscat and Hamburg, and delivery to 24+ ministries and 500+ institutions across 5+ countries. The users are Arabic-speaking civil servants, clinicians, examiners, faculty and students, and the systems are judged on whether Arabic works in production — not in a demo.

That includes MedWaste running across all 27 Egyptian governorates with the Ministry of Health and Population and UNICEF, iTest running Egypt's EMLE medical licensing examination sat by 9,397 doctors, the national LMS programme connecting 500+ governmental university faculties through iMiddleware, iTutor delivered with Arabic RTL support, and AI Questions generating items in 18 languages.