Arabic Type on the Web, and What Keeps Breaking It

A bilingual site is not one site in two languages. It is one system that has to hold its shape when the writing direction reverses, the letterforms connect, and the line heights stop matching. When Arabic looks like an afterthought, it is usually one of three things.

Latin type families are often sold as complete while covering only Latin. Drop Arabic into one and the browser silently substitutes a system font, so the Arabic pages render in something nobody chose. The page still works; it just stops being designed.

Check it the only way that is reliable: render a paragraph of Arabic and compare it against the specimen. If the letterforms differ, the family is not carrying the language and either the weight needs licensing or the typeface needs replacing.

Setting dir="rtl" flips the layout, which is correct, and also flips things that should never flip. A Latin brandmark, an email address, a phone number and a version string all read left to right in both languages. Reversed, a phone number puts its leading plus sign after the digits.

The fix is per element, not per page: mark the runs that stay Latin, and let everything else mirror.

Arabic sits on a different baseline and carries marks above and below it. A line height that looks generous in English can clip in Arabic, and a cap height tuned to Latin leaves Arabic floating in its box.

• Set line height per language, not once for the site
• Check the tightest component — a card, a nav item, a button — not the body copy
• Test the longest real word, not placeholder text

Placeholder text hides every one of these problems, because it is always the right length and never the right language.

None of this is expensive if it is decided early. All of it is expensive as a retrofit, which is why we treat the second language as part of the type system rather than a translation task. You can see how that plays out across the work.