Teams add Arabic by exporting strings, getting them translated and importing them back. Then the layout is subtly broken everywhere and nobody can quite say why. Translation was the easy part. The layout has to mirror, and a surprising amount of an interface has a direction baked into it.
We ship products in up to eight languages including Arabic and Darija, and this is what actually costs time.
Use logical properties, or do the work twice
The single highest-leverage change is to stop writing left and right in CSS. Use inline-start and inline-end. Margin, padding, border, text alignment and absolute positioning all have logical equivalents, and they flip automatically when the document direction changes.
A codebase written with physical properties needs a mirrored stylesheet, which then has to be maintained in parallel forever. A codebase written with logical properties needs one attribute changed on the html element. The cost difference is not close, and it compounds with every new screen.
Numbers and Latin text inside Arabic sentences
Arabic runs right to left, but numbers, currency codes and Latin brand names inside an Arabic sentence still run left to right. The browser's bidirectional algorithm mostly handles this, and the place it reliably does not is a number containing a space or punctuation.
A price written as "18 000" is two bidi runs, and in a right-to-left context it can render as "000 18". The fix is to isolate it: force the direction on that element and set unicode-bidi to isolate so it cannot be reordered by its neighbours. We hit this on a pricing page and the number was wrong on screen while being perfectly correct in the markup, which is a genuinely confusing bug the first time.
Icons and animation have direction too
A back arrow points the other way in Arabic. A "next" chevron reverses. A carousel that slides left should slide right, and a progress indicator that fills from the left should fill from the right.
The subtle version of this bug: an animation built with a negative transform will move a right-to-left flex track completely out of view, because the track is anchored to the opposite edge. Reversing the animation direction does not fix it either, since that replays the same offsets backwards. You need mirrored keyframes with the sign flipped. We shipped that bug once and it left an entire section blank in Arabic while looking perfect in English.
Test in the language, not in the strings
Reading a translation file tells you nothing about whether the interface works. Every screen has to be opened in Arabic and looked at. The failures are visual: a truncated button, a badge overlapping a heading because it was absolutely positioned from the left, an icon pointing the wrong way.
Automate what you can. We run a check that every translation key exists in every language and that no key has conflicting English source text, which catches the silent case where a key is reused with different meanings and switching language back to English rewrites unrelated copy. That bug is close to invisible in review and obvious to a user who changes language twice.
Darija is a separate decision
Moroccan Darija is not Modern Standard Arabic, and for consumer products aimed at a Moroccan audience it is often the register that actually connects. It is also written inconsistently, sometimes in Arabic script and sometimes in Latin characters with numerals. Deciding which convention your audience uses is a product decision, not a translation task, and it belongs with the people who know the market.
The rule we work to
Design for right-to-left from the first screen. Retrofitting is not a one-week task, it is a long tail of small breakages that surface for months, each individually trivial and collectively exhausting. Building with logical properties and testing in the target language costs almost nothing when it is the default. We treat it as part of localisation work, which is to say part of the build rather than a phase after it.