Most apps that “support Arabic” don’t actually support Arabic. They mirror the layout, swap the text, and call it done. The result feels like a translated product — not a native one. Users notice, even if they can’t articulate why.

At ItqanLab, every product we build is designed for Arabic and English from the start. Not as an afterthought. Not as a feature flag. As a core architectural decision. Here’s what that actually involves.

RTL Is More Than dir="rtl"

Setting dir="rtl" on your HTML element flips the text direction. It does not:

  • Flip your navigation order (users expect it)
  • Mirror your icons (back arrows should point right in RTL)
  • Adjust your spacing (padding-left becomes padding-right)
  • Fix your number rendering (Arabic-Indic numerals vs. Western Arabic)
  • Handle mixed-direction content (an English brand name inside Arabic text)

A genuinely bilingual product handles all of these. And it handles them consistently across every screen, every component, and every interaction.

The Design Challenges

Typography

Arabic and English text have fundamentally different characteristics:

  • Arabic is taller — Arabic characters have more vertical height, so line-height values that work for English often feel cramped in Arabic
  • Arabic is denser — the same sentence in Arabic is typically 15-25% shorter than English, which affects layout assumptions
  • Font pairing matters — you can’t just use a system Arabic font alongside your carefully chosen English typeface. The weights, x-heights, and styles need to complement each other

We use IBM Plex Sans Arabic paired with Inter and Outfit — a combination we’ve tested extensively for visual harmony across both scripts.

Layout

Mirroring a layout isn’t always the right choice. Some rules:

  • Navigation and reading flow — mirror (right-to-left scanning)
  • Progress indicators — mirror (progress flows right to left)
  • Media controls — don’t mirror (play/pause/forward/back are universal)
  • Number sequences — don’t mirror (1, 2, 3 reads left-to-right in both languages)
  • Maps and charts — don’t mirror (geographical and data representations are direction-agnostic)

The distinction is between directional UI (follows reading direction) and universal UI (follows global conventions). Getting this wrong creates confusion.

Content

The biggest trap: translating instead of localizing. Translation converts words. Localization converts meaning.

Examples:

  • A CTA that says “Get Started” in English shouldn’t be a literal Arabic translation. The Arabic equivalent should carry the same energy and urgency, which might be a completely different phrase.
  • Date formats, currency symbols, and number formatting all need localization — not just translation.
  • Humor, idioms, and cultural references don’t translate. They need cultural equivalents or should be removed entirely.

The Engineering Challenges

CSS Logical Properties

The single most impactful technical decision: use CSS logical properties everywhere.

Instead of margin-left: 16px, use margin-inline-start: 16px. Instead of padding-right: 24px, use padding-inline-end: 24px. This way, the same CSS works correctly in both directions without any overrides.

If your codebase uses physical properties (left, right), you’ll end up writing RTL overrides for every component. That’s double the CSS and double the bugs.

State Management

Language state needs to be:

  • Persistent — stored in localStorage or a cookie so it survives page reloads
  • Reactive — switching languages should update the entire UI without a page refresh
  • Accessible — the lang attribute on <html> must update for screen readers

We typically implement this as a lightweight client-side toggle that updates dir, lang, and all translatable strings in one pass. No page reload. No flash of untranslated content.

Testing

Every feature needs to be tested in both languages. This isn’t just about text overflow — it’s about:

  • Truncation — a string that fits in English might not fit in Arabic (or vice versa)
  • Form validation — error messages, placeholder text, and labels in both directions
  • Screenshots — visual regression tests need RTL variants

Our Approach

We’ve codified this into our workflow. When we build a bilingual product:

  1. Design in both languages simultaneously — not English first, Arabic second
  2. Use a single translation object — all strings in one place, no scattered hardcoded text
  3. Test every component in both directions — before it’s considered done
  4. Treat Arabic as a first-class language — not a “translation” of the English product

The result is a product that feels native in both languages. Arabic users don’t feel like they’re using a translated English app. English users don’t feel like they’re using an Arabic app with English text. Both feel like the product was built for them.

Building a product for Arabic and English-speaking users? Let’s talk — bilingual products are what we do best.

Related: See our bilingual work in action with MyLife, or learn about our Product Design approach.