RTL done properly
Flipping a layout is the easy ten percent. The ninety percent that decides whether an Arabic interface feels native is knowing where mirroring is wrong.
Reading time · 8 min
Mirroring is the default, not the answer
Set `dir="rtl"` and a modern browser does a great deal for free. Text runs right to left, block elements align to the right, and if your CSS uses logical properties — `margin-inline-start` rather than `margin-left`, `padding-inline-end` rather than `padding-right` — most of your spacing follows without being touched.
That is the ten percent, and it is worth taking. Logical properties cost nothing to adopt and remove an entire category of future bug. If your stylesheet still uses physical properties everywhere, converting it is the single highest-value thing you can do before starting.
The remaining ninety percent is a series of individual judgements about things that should not flip, and there is no setting for those.
What must not flip
Numbers run left to right even in Arabic text. So do Latin brand names, email addresses, URLs, code, file paths and phone numbers. The Unicode bidirectional algorithm handles most of this correctly on its own, and then falls over on the edges: a phone number ending in a bracket, a mixed string like "iPhone 15 ‑ متوفر", a right-to-left paragraph beginning with a Latin word. Those need isolation — `unicode-bidi: isolate` on the inline span, or the `‎`/`‏` marks — rather than hope.
Icons split into two groups and the line matters. An icon that encodes direction should mirror: back and forward arrows, undo and redo, indent, the chevron on an expandable row, the send arrow. An icon that depicts a real object should not: a clock, a magnifying glass, a padlock, a printer, a mug. Mirroring a clock produces a clock that runs backwards, which readers notice without being able to say why.
Media controls do not mirror. Play, fast-forward and the progress bar on a video player are conventions borrowed from physical tape, and they point the same way in every language. Mirroring them is a classic over-correction.
The places it actually breaks
Progress, steppers and anything with a direction of travel need a decision. A progress bar in Arabic should fill from the right. A multi-step form should advance leftward. Most component libraries get the bar wrong because the fill is implemented as a width from the left edge rather than from the inline start.
Carousels and swipe gestures are where teams discover the problem in testing rather than in design. If swiping left advances in English, the Arabic equivalent is swiping right — and if your carousel library hard-codes index direction, you will be fighting it.
Shadows and asymmetric decoration are quieter. A card with a shadow offset to the bottom-right and a border accent on the left looks deliberate in English and slightly broken in Arabic. Whether light has a direction in your design system is a real question worth answering once.
Typography is the thing teams underestimate most. Arabic has no capital letters, so every hierarchy trick built on uppercase — eyebrow labels, small-caps buttons, letter-spaced navigation — simply has no Arabic equivalent and must be replaced with weight, size or colour. Arabic glyphs also sit differently in the line: the same point size reads smaller and needs more line-height. A font stack that looks balanced in English usually needs its Arabic face tuned separately.
A checklist worth running before launch
- Does the stylesheet use logical properties, or physical ones that will need a mirrored override?
- Do numbers, Latin names and phone numbers stay left-to-right inside Arabic lines, including at the start and end of a paragraph?
- Has every icon been classified as directional or depictive?
- Do progress bars fill from the inline start, and do steppers advance in the reading direction?
- Do swipe and keyboard-arrow navigation follow the reading direction?
- Has the Arabic face been sized and leaded separately, rather than inheriting the Latin values?
- Has someone who reads Arabic actually used the build, on a phone?
Common questions
Can we not just use a CSS flip plugin?
It will handle the mirroring, which is the part the browser mostly does for you anyway. It cannot tell a directional icon from a depictive one, and it will not fix typography, which is where Arabic interfaces most often feel wrong.
Is one codebase enough, or do we need two?
One, in almost every case. Two codebases drift, and the Arabic one is always the one that falls behind. What you need is one codebase whose layout is expressed in logical terms and whose Arabic typography is tuned deliberately.
How much does retrofitting cost compared to starting bilingual?
Substantially more, because it touches layout, iconography, input handling, formatting and copy at once rather than being a decision taken per component as you build. This is why we scope bilingual delivery during the strategy week rather than treating it as a later phase.
Related guides
Working on something like this?
Tell us what you're building. We send back a one-page response with scope, timeline, and a number you can plan around.
Send us a brief