Building bilingual English and Arabic products: what right-to-left really costs
Bilingual delivery in the Gulf is not a translation task at the end of the build. Right-to-left layout, mixed-direction content, Arabic typography, and locale-aware data touch the design system, the components, and the test suite. Plan for it from the first sprint.
Most of our public-sector work in the UAE ships in English and Arabic, with either language as the primary. Programmes that treat Arabic as a translation pass at the end discover that half the interface breaks in ways translators cannot fix. The cost of bilingual delivery is real, it is mostly engineering rather than translation, and it is far lower when it is designed in from the start.
Direction is a layout property, not a text property
Right-to-left is not mirrored text; it is a mirrored interface. Navigation, progress indicators, tables, icons that imply direction, and the order of form fields all flip. Logical CSS properties (start and end rather than left and right) and a component library that has been tested in both directions are the foundation everything else rests on.
Retrofitting logical properties onto a large codebase is slow and error-prone. Starting with them costs almost nothing.
Mixed direction is the real difficulty
Real content is mixed: an Arabic sentence containing an English product name, a reference number, and a date. Bidirectional text rendering handles most of it, but numbers, punctuation, and brackets at the boundaries go wrong in ways that are obvious to native readers and invisible to the English-speaking engineers who built the screen.
Isolate embedded content explicitly, test with real bilingual content rather than placeholder strings, and put native Arabic readers on the review rota from the first sprint rather than the last.
Typography and density
Arabic script needs more vertical space and renders at a different visual size for the same nominal font size. Line heights, minimum sizes, and the vertical rhythm of the design system have to be set for both scripts, not tuned for Latin and inherited. Font selection is a design decision with licensing and rendering implications on every platform you ship to.
Translated strings are also longer or shorter in unpredictable ways. Components that assume a string length break; components designed to wrap do not.
Locale is more than language
Dates, calendars, number formatting, and the choice of Eastern or Western Arabic numerals vary by entity and by document type within the same country. Names have structures that do not fit a first-name, last-name model. Addresses do not match Western forms. Get the data model right early; it is the one part that cannot be fixed in the interface.
Where the client publishes in both languages, the content model has to carry both, with a workflow for translation and approval, rather than storing English and bolting Arabic on.
Testing in both directions
Every visual regression suite runs in both directions. Every accessibility audit runs in both languages. Every round of user testing includes native readers of both. The cost of this is a fraction of the cost of the first public complaint about a broken Arabic form on a government service.
What we tell clients: budget bilingual delivery as an engineering line item at the start, not a translation line item at the end.
Where we apply this in practice
Working on this in your own organisation?
If any of this maps to a programme you are running, we would be glad to compare notes.