Designing for Arabic + English: RTL/LTR UX Done Right

Why Bilingual UX Is Non-Negotiable Here

For a business operating in Kuwait, an English-only site with an Arabic version bolted on later isn't a minor gap - it's half your potential audience getting a worse experience, or no experience at all. Arabic isn't a "nice to have" locale toggled on at the end of a build; for most local audiences it's the primary language, and the English site is the secondary one.

The problem is that "bilingual" often gets treated as a translation task - hand the copy to a translator, run it through an RTL CSS flip, ship it. That approach gets a site that technically has Arabic text on it, but feels foreign to Arabic readers: cramped type, numbers running the wrong way, forms that behave strangely. Real bilingual UX is a layout and design decision made from the first wireframe, not a CSS toggle applied afterward.

RTL Is Not Just a Mirror Image

Setting direction: rtl on the page and letting the browser flip everything horizontally gets you most of the way there - navigation moves to the right, text aligns right, the reading flow reverses. But a blanket mirror is wrong for a specific set of elements that should never flip, and getting this list wrong is where most "we support Arabic" sites go visibly wrong:

• Phone numbers, prices, and any numeral sequence - these stay left-to-right even inside an RTL paragraph, because Arabic-speaking users read digits the same direction as everyone else.
• Logos and brand marks - a logo doesn't flip just because the page direction changed.
• Media player controls, video timelines, and icons tied to real-world objects (a clock face, a credit card) - these keep their natural orientation.
• Embedded Latin-script content - a product SKU, an English brand name inside Arabic copy, a code snippet - needs to stay a left-to-right "island" inside the surrounding right-to-left text.

What should flip: directional icons like next/back chevrons, breadcrumb separators, progress indicators, and the general reading order of navigation, cards, and form labels. Each icon and component genuinely needs a direction decision, not a global transform.

Arabic and Latin Type Don't Behave the Same

Reusing your English font for Arabic text is one of the most common shortcuts, and it's usually visible immediately - most Latin webfonts either lack real Arabic glyphs entirely (so the browser silently substitutes a mismatched fallback font) or include a thin, cramped Arabic set that was never designed to sit at the same weight and size as the Latin one.

A few things worth building into the design system rather than discovering in QA:

• Pick a font pairing designed for both scripts together (families like IBM Plex Sans Arabic, Noto Sans Arabic, or Tajawal pair well with common Latin sans-serifs), not two unrelated fonts stitched together by CSS fallback.
• Arabic generally needs more line-height and slightly larger body size than the Latin equivalent to stay comfortably readable - the same pixel values rarely work for both.
• Arabic script doesn't have a true italic form and rarely uses letter-spacing the way Latin type does - don't apply the same emphasis styles across both languages.
• Arabic sentences typically run 20-25% longer than their English equivalent for the same meaning. Buttons, nav labels, and tight card layouts that were only ever tested in English will overflow or wrap awkwardly once translated.

Icons, Numerals, and Mixed-Direction Content

Numerals are a decision, not a default. Most Gulf audiences expect Western Arabic numerals (0-9) rather than Eastern Arabic-Indic digits (٠-٩), even on fully Arabic pages - but this varies by region and audience, so it should be an explicit choice in the design system, not whatever the browser or OS locale happens to render.

Mixed-direction text is the other trap: an Arabic paragraph that references an English product name, a ticket number, or a URL needs that fragment wrapped so it doesn't get visually reordered mid-sentence - typically with an explicit dir="ltr" span or the Unicode directional isolate characters around the embedded text, rather than hoping the browser guesses correctly.

Forms, Dates, and Inputs in RTL

Forms are where RTL bugs are most noticeable, because users are actively typing and immediately feel when something's off. A few patterns that deserve deliberate handling rather than a blanket flip:

• Phone number, email, and numeric fields should keep their contents left-to-right internally even inside an otherwise right-aligned Arabic form - the label sits on the right, but the typed digits read correctly rather than appearing to type backward.
• Validation icons, dropdown carets, and password-visibility toggles need to move to the correct side of the field once the form direction flips, not stay pinned to their English-layout position.
• Date pickers should make an explicit call on Gregorian vs. Hijri calendars for the Arabic audience rather than defaulting silently - and be consistent about it across every form on the site.
• Placeholder and helper text alignment needs the same right-to-left treatment as the rest of the field, which is easy to miss since it's often styled separately from the label.

URLs, SEO, and the Cost of Getting This Wrong

Bilingual UX isn't only a visual problem - it affects whether Arabic-language searches find your site at all. A common shortcut is switching languages with a cookie or a query string (something like ?lang=ar) while keeping the same URL for both versions. Search engines generally don't crawl or index cookie-based language variants reliably, which means the Arabic version of your site can be functionally invisible to Arabic search traffic even though it exists.

The fix is a proper parallel URL structure - distinct paths like /ar/ for the Arabic version of every page - paired with hreflang tags that tell search engines the English and Arabic pages are alternates of each other. It's more setup work than a cookie toggle, but it's the difference between an Arabic site that exists and one that actually shows up when someone searches in Arabic.

Common Mistakes We See

• Treating Arabic as a text-substitution pass bolted on at the end of a build, after every layout decision was already made around English copy length.
• A blanket direction: rtl flip that reverses phone numbers, prices, and embedded brand names along with the rest of the layout.
• Reusing the English font for Arabic text, producing thin, mismatched, or barely legible Arabic type.
• Switching languages via cookie or query string with no distinct URLs, so the Arabic site never gets indexed and never appears in Arabic search results.
• Only testing forms, validation states, and icon placement in the default English/LTR direction, and finding the RTL bugs after launch.

Getting It Right From the Start

Treat Arabic as a first-class design target from the first wireframe, not a CSS toggle applied once the English site is finished. That means designing with realistic Arabic text lengths from day one, choosing a type system built for both scripts, deciding numeral and calendar conventions explicitly, and giving every icon and form element its own direction call instead of a blanket mirror.

It's also worth having someone who actually reads Arabic review the finished pages before launch - automated mirroring can look correct in a screenshot and still read wrong to a native speaker. Get this right and the bilingual site stops feeling like two separate products stitched together, and starts feeling like one site that happens to work in two languages.