One layout, two reading directions

Why "translate later" fails

The most common bilingual web design mistake in this region: build the English site first, get it approved, then hand the copy to a translator and flip the layout at the end. It feels efficient. It almost never works.

The problem is that an Arabic English website is not one design plus a mirror — it is one design system carrying two writing systems with different shapes, different densities, and opposite reading directions. Translated Arabic copy rarely comes back the same length as the English it replaces — sometimes noticeably shorter, sometimes longer — so a button label that fits in English can wrap in Arabic. Arabic letterforms connect, so tight letter-spacing that looks sharp in a Latin headline literally breaks Arabic words apart. None of this surfaces until the translation lands — which, in the "translate later" plan, is the week before launch.

The fix is a different starting point: treat direction and language as design inputs, the way screen size already is. Nobody "makes a site responsive later" anymore; RTL website design deserves the same status.

Direction is a design decision, not a toggle

Under the hood, the difference between a site that mirrors cleanly and one that fights you is usually a CSS vocabulary choice. Physical properties — margin-left, padding-right, text-align: left — hard-code a direction into every rule. Logical properties — margin-inline-start, padding-inline-end, text-align: start — describe position relative to the reading direction, so the same stylesheet lays out correctly the moment dir="rtl" is set on the document.

Written logically from day one, a codebase gets its Arabic mirroring almost for free: cards, grids, navigation, and forms all flip together, consistently. Retrofitted, the same result means hunting down hundreds of physical declarations and overriding each one — which is why retrofitted RTL sites so often show the telltale misaligned icon or backwards progress bar.

This page works that way — the language switch in the corner flips the document direction and swaps the strings, and the layout follows because it was built to.

What mirrors — and what must not

A common over-correction is mirroring everything. Direction-aware design means knowing what flips and what stays put:

• Mirrors: layout flow, navigation order, form label alignment, breadcrumbs, back/forward arrows, carousel direction, progress indicators that imply "how far through".
• Does not mirror: media player controls — play is a right-pointing triangle everywhere, and timelines run left-to-right for Arabic users too; clocks; brand logos.
• Depends: numbers. Digits read left-to-right even inside Arabic text, and the UAE commonly uses Western Arabic numerals (0–9), so phone numbers and prices usually keep their form — but need explicit direction handling so surrounding text does not scramble them.
• Check case by case: icons with implied direction. A magnifying glass is fine as-is; a "send" arrow or a reply icon usually needs a flipped variant.

Getting this list right is a design review, not a find-and-replace — one of the things we walk through in every UI/UX engagement before a single screen is built.

Pairing Arabic and Latin type

Arabic typography on the web is a craft of its own, and the pairing decision shapes the whole personality of a bilingual site. Broadly, Arabic web faces fall into two families of character. Kufi-influenced faces are geometric, low-contrast, and architectural — they sit naturally next to modern Latin sans-serifs, which is why our own site pairs Noto Kufi Arabic with Inter and Space Grotesk. Naskh-influenced faces are rounder and more calligraphic — a better fit for long-form reading and for brands that want warmth over precision.

The technical trap in any pairing is vertical rhythm. Arabic has no x-height in the Latin sense; its visual mass sits differently on the line, and many Arabic faces render optically smaller than a Latin face at the same pixel size. If you set both from one font-size token, the Arabic version looks faint and cramped. The fix is unglamorous: size and line-height overrides scoped to the Arabic context, tuned by eye until both languages carry the same visual weight. Arabic also needs more line-height, because ascenders, descenders, and diacritics reach further — tight English headlines will clip or collide in Arabic if the leading is shared.

The punctuation traps nobody warns you about

Mixed-direction text — bidirectional, or "bidi" — has sharp edges that pure translation never catches. The classic one: an Arabic sentence that ends with an English word, a number, or a URL. The trailing period logically belongs to the Arabic sentence, but the bidi algorithm can attach it visually to the Latin fragment, leaving the full stop stranded at the wrong end of the line. Prices like "AED 250", product names, and @handles inside Arabic copy trigger variations of the same scramble.

The web platform has real tools for this — the bdi element, the unicode-bidi property, directional marks — but tools only get used when someone knows the sentence is broken. That takes a reviewer who reads Arabic, which is why bilingual capability in the team, not just in the deliverable, is part of how we build websites in Dubai.

Forms deserve their own paranoia: in one Arabic form, email fields are always LTR, names follow the input language, and placeholders should align with the field's content direction, not blindly with the page.

Test both directions from day one

Everything above collapses into one habit: run both directions from the first prototype. That means the language toggle exists in week one, not week six; every component is reviewed in both directions before it is called done; and real Arabic copy — not lorem ipsum, not machine output pasted in unread — flows through layouts early enough to change them. When the Arabic version is a first-class citizen of the build, its problems surface when they are cheap to fix. It is also where the budget conversation gets honest: designed-in bilingual support adds modest cost at the start, while retrofitted support can approach the cost of a redesign — a distinction any transparent quote should make visible before you sign it.

When is a full bilingual build the wrong call? Honestly: when your audience genuinely does not need it yet. A B2B tool selling only to English-speaking teams gains little from a half-maintained Arabic version; bilingual done badly is worse than monolingual done well. But if you are consumer-facing in this market, that exemption probably is not yours.

Because in the UAE, bilingual is not a feature — it is table stakes. Arabic is the official language, English is the commercial lingua franca, and government services, banks, and serious consumer brands ship both as a matter of course. A bilingual website in the UAE is not localisation for an edge case; it is the baseline your customers already experience everywhere else. If you want to go deeper on the craft, our learning track on designing in two languages covers it step by step.