Building Arabic-first software: what it actually takes

Most teams treat Arabic as a translation task. Extract the strings, hand them to a translator, load the file, done.

Then the first Arabic screen renders and the layout is inside out, the numbers are in the wrong order, a product name in English has landed in the middle of a sentence facing the wrong way, and the font that looked correct in the design file is joining letters incorrectly at small sizes.

Arabic is not a language setting. It is a set of decisions about layout, typography, data formatting and testing. Taken at the start, the overhead is modest. Retrofitted onto a finished product, it is close to rebuilding the interface.

Here is what it actually involves.

Right-to-left is not a mirror

The instinct is to flip the layout horizontally. That gets you most of the way and then breaks in specific, visible places.

Things that flip: reading order, navigation, alignment, list indentation, progress direction, the direction a back arrow points.

Things that do not: phone numbers, most logos, media playback controls, clock faces, and anything the user recognises by its shape rather than its position. A play button pointing right is a play button in every language. Mirrored, it reads as rewind.

Modern CSS handles more of this than it used to. Logical properties — margin-inline-start instead of margin-left, padding-inline-end instead of padding-right — mean a single stylesheet can serve both directions rather than maintaining two. If you are starting now, write logical properties from the first component. Converting a large codebase later is mechanical, tedious, and touches every file.

Mixed-direction text is where it actually breaks

A pure Arabic paragraph is straightforward. The hard case is Arabic containing English — a brand name, a product code, a URL, a version number.

The Unicode bidirectional algorithm handles most of this automatically, and the places it does not are the ones users notice: punctuation attaching to the wrong side, a sentence-final full stop appearing at the left edge, an English product name pulling its surrounding spaces the wrong way.

You cannot find these by reading the code. You find them by rendering real content — real product names, real addresses, real user-generated text — and looking. Which means Arabic content has to exist during development, not after.

Placeholder Latin text in an Arabic layout will pass every review and hide every bug.

Type is the part people underestimate

Arabic letters change shape depending on their position in a word and join to their neighbours. A font either implements that correctly or it does not, and a font that looks fine in a heading can fall apart at body size or in a specific letter combination.

Two practical consequences:

Arabic needs more vertical space. The same content in Arabic typically needs more line height than Latin to stay readable. A layout tuned tightly to English text will feel cramped.

Latin and Arabic faces need pairing deliberately. A bilingual product shows both, often in the same screen. Two fonts chosen independently will not share a weight or an optical size, and the mismatch is immediately visible.

Test with the smallest text in the product, not the largest. Headlines forgive a lot.

Data is not just display

Numbers, dates and currency carry their own decisions, and they are business decisions rather than technical ones.

Arabic-speaking regions differ on whether to use Arabic-Indic numerals or Western digits, and users differ within regions. Gregorian and Hijri calendars may both be relevant. Currency symbol placement varies. None of these has a single correct answer — they have a correct answer for your users, which means asking rather than assuming.

Store everything in one canonical format and format at the point of display. Storing a formatted date because it looked right on one screen is a bug that surfaces months later in a report nobody tested.

What this means for a project plan

The decision to support Arabic belongs in the first week, alongside the data model — not in a later phase called "localisation".

Concretely, taken early it means: logical CSS properties from the first component, a bilingual type system chosen before the design system is built, real Arabic content in the design files, and both languages in the test pass from the first sprint.

Taken late it means re-auditing every screen, re-testing every flow, and redesigning the parts that assumed a direction.

Same product. The difference is when you decided.