CRO & Web03 Aug 2026 · 7 min read · how-to

Multi-Language Site UX: English & Arabic

Ship bilingual EN/AR UX that converts in the UAE: true RTL, working switchers, human CTAs, price parity, and no half-translated money pages.

Bilingual websites in the UAE fail in predictable ways: a language toggle that 404s, Arabic pages with English forms, RTL that only flips the logo, or machine-translated medical claims that destroy trust.

This guide is about UX and conversion for English/Arabic sites — not full brand linguistics. For brand voice, pair with your brand-strategy bilingual guides; here we make the interface convert in both languages.

Decide the language strategy (do not fake it)

Options:

EN primary, AR selective — key landers, homepage, contact, top services
Full parity — every commercial page in both
AR primary for categories where demand is Arabic-first
Separate campaigns — EN and AR landers without a full dual site

Selective done well beats full parity done as Google Translate at 1am. Write the decision down: which URLs must exist in AR before the next ad push, who updates them when prices change, and who approves claims.

A practical rule for SMEs: translate every URL that can receive paid traffic plus the global templates (header, footer, form errors, checkout). Blog posts can lag; checkout cannot.

Information architecture

Mirror structure where possible (/ar/services/ ↔ /services/)
Use clear language prefixes or subfolders rather than fragile query strings
Hreflang if you care about organic; still keep UX paramount
Do not auto-redirect purely on browser language without an escape — expats use Arabic devices; Emiratis use English browsers
Remember language choice across session when possible

Switchers should be visible on mobile without opening a 20-item hamburger. “EN | ع” in the header is boring and effective.

When an AR equivalent does not exist, the toggle should say so and offer WhatsApp in Arabic — not dump the user on an English 404.

True RTL, not “mirrored English”

Arabic templates need:

dir="rtl" on the page or main container
Logical CSS (margin-inline, etc.) or carefully flipped spacing
Icons and chevrons that make directional sense
Forms aligning labels and errors correctly
Numbers, English brand names, and AED amounts that remain readable
Sticky CTAs that do not cover Arabic text mid-sentence

Common bugs to hunt:

Carousels that still swipe the wrong mental direction
Progress steppers that fill left-to-right only
English screenshots inside Arabic tutorials
PDFs that are English-only linked as “Download brochure” on AR pages without a label

Translation quality bar for conversion surfaces

Human-review at least:

Headlines and CTAs
Pricing and legal-ish claims
Form labels and errors
Checkout and payment statements
Medical / financial / legal wording
Auto-replies and WhatsApp prefills that fire from the page

Machine translation can draft, not ship, for money pages. Awkward Arabic on a luxury offer reads as counterfeit. If you cannot afford full human translation, ship fewer pages.

CTAs need natural phrasing — literal “Submit request now” calques underperform the phrases your customers already type in chat. Listen to real WhatsApp transcripts and reuse that language.

Sample Arabic UI and CTA microcopy

Ship phrases people recognise—not textbook calques:

احجز الآن (Book now)
تواصل عبر واتساب (Contact via WhatsApp)
اطلب عرض سعر (Request a quote)
أضف إلى السلة (Add to cart)
إتمام الدفع (Complete payment)
يُرجى إدخال رقم هاتف إماراتي صحيح (Please enter a valid UAE phone number)
شكراً لك — سيتواصل معك فريقنا خلال ساعة عمل. (Thank you — our team will contact you within one business hour.)
Header switcher: English | العربية

Mixed-language reality in Dubai

Many users code-switch. Practical patterns:

Brand name in English, body in Arabic (or reverse)
Technical SKUs in English inside AR pages
Allow EN form entries on AR pages (names, emails) without validation tantrums
Staff may reply in the customer’s opening language, even if the site was EN

Do not force Arabic-only name fields that reject common Latin spellings if your CRM is English. Conversely, do not block Arabic characters in “name” fields on EN forms.

Media, proof, and offers

Show Arabic reviews on AR pages when available; do not only display English testimonials globally
Screenshots of UI should match language
Video subtitles per version
Certificates in English can appear on AR pages with a short Arabic caption
Promotions: if DSF copy is EN-only, do not run AR ads to it

Ramadan and National Day campaigns especially deserve culturally reviewed Arabic — not only dictionary correctness but tone.

SEO vs ads bilingual notes

Organic: unique AR content, not doorway duplicates or thin swaps
Ads: match lander language to ad language every time
Keywords: Arabic queries are not always literal translations of English keywords — use real query research and Search Terms reports
Phone numbers and NAP should match across languages for local SEO consistency

Message match still rules: AR ad → AR fold → AR WhatsApp prefill.

Illustrative scenario — home services brand, citywide

Before: EN site solid; AR toggle loaded EN with Arabic menu labels only; form errors in English; prices only on EN; Meta AR ads wasted.

After: Top 8 money pages true AR RTL; WhatsApp prefill in Arabic; shared pricing module; switcher on sticky header; ads split by language with separate URLs; weekly check that price changes ship in both languages.

Arabic campaigns stopped leaking into confused sessions; EN performance unchanged; sales noticed fewer “wrong language” chats.

QA checklist for every bilingual release

Switcher lands on equivalent content (or honest fallback)
No mixed-direction forms
CTAs human-translated
Phone and WhatsApp work identically
Currency and numerals consistent
404 pages language-correct
Cookie/privacy banners do not trap one language
Speed: AR font path not doubling LCP vs EN
Thank-you / success messages translated
Screen reader order still sensible in RTL (basic pass)

Operational bilingualism (the hidden CRO factor)

If the site is bilingual but ops reply only in English after 12 hours, AR conversion still suffers. Build:

Quick replies in both languages
Routing rules if certain staff handle AR
Escalation for sensitive categories (clinics, finance)

The website cannot speak Arabic for a team that will not. Budget people time, not only translation invoices.

Governance: keeping parity alive

Assign an owner. When EN price changes, AR must change the same day. When a campaign ends, both landers come down. A stale Arabic price that is lower than English is how you create support nightmares and reputation damage.

Use a simple sheet: URL | EN status | AR status | last checked | owner.

When not to translate yet

You cannot maintain parity after product changes
Only EN campaigns run and AR demand is unproven — still consider a thin AR welcome + WhatsApp for brand credibility
Legal claims need counsel review you have not budgeted
Your font/performance stack cannot handle Arabic without multi-second LCP (fix fonts first)

Ship fewer perfect AR pages rather than fifty embarrassing ones.

Key takeaways

Choose selective vs full parity deliberately; finish money pages first.
True RTL layout, human CTAs, and form UX matter more than decorative translation.
Match ad language to lander language and WhatsApp prefill.
Ops must answer in the customer’s language for the UX promise to hold.
QA switchers, direction, speed, and price parity on every release.

Part of the Dubai Marketing Playbook by Shabang — practical marketing for UAE businesses.