Building a Bilingual Arabic–English Website: RTL Done Right

Short answer: A good Arabic–English site sets lang="ar" and dir="rtl" on the <html> element of every Arabic page, builds its layout with CSS logical properties so one stylesheet works in both directions, mirrors directional UI (arrows, progress, back buttons) but not things like logos, media controls or numbers, and uses an Arabic typeface designed for the screen. Each language version should have its own URL linked with hreflang, and the Arabic content should be written for Arabic readers rather than translated line by line. Getting these basics right from the start is far cheaper than retrofitting RTL into a left-to-right build.

1. Declare language and direction in the right place

The W3C's internationalisation guidance gives the rule in one line: if the overall document direction is right-to-left, add dir="rtl" to the html tag, and below that only use dir on structural elements on the rare occasions the base direction needs to change. It also says never to use CSS to apply the base direction.

<!-- Arabic page -->
<html lang="ar" dir="rtl">

<!-- English page -->
<html lang="en" dir="ltr">

Why markup and not CSS: direction is part of the content's meaning. If the stylesheet fails to load, or the text is copied, syndicated or read by assistive tech, the dir attribute still travels with it.

Also set lang correctly. The W3C recommends declaring the language on the html element; browsers and screen readers use it to choose fonts, hyphenation and pronunciation.

Mixed content inside a page

Short English phrases, product codes or brand names inside Arabic text usually render fine. Where user-generated or variable content might be in either script, the W3C notes that dir="auto" lets the browser pick the direction from the first strong character, and its inline bidi article covers isolating such snippets so they don't scramble surrounding punctuation.

2. Use logical CSS properties

The biggest time saver is writing CSS that doesn't assume left or right. MDN describes logical properties as controlling layout through logical, rather than physical, direction and dimension mappings.

/* Physical: breaks in RTL */
.card { margin-left: 1rem; padding-right: 2rem; text-align: left; border-left: 4px solid; }

/* Logical: works in both */
.card { margin-inline-start: 1rem; padding-inline-end: 2rem; text-align: start; border-inline-start: 4px solid; }

Checklist:

[ ] margin-inline-start/end, padding-inline-start/end instead of left/right
[ ] inset-inline-start/end for positioned elements
[ ] text-align: start/end
[ ] Flexbox and grid follow the direction automatically; avoid row-reverse hacks
[ ] Audit third-party widgets (sliders, date pickers, chat bubbles), which are where most RTL bugs live

3. Mirror what's directional, keep what isn't

Mirror in Arabic	Don't mirror
Back/forward arrows, "next" chevrons	Logos and brand marks
Breadcrumb separators	Media play, pause, fast-forward icons
Progress bars and steppers	Clocks and circular progress that represent time
Sliders and carousels (start from the right)	Charts with a numeric x-axis, unless redesigned
Icons showing a sequence, e.g. a list with a bullet	Phone numbers, prices, product codes
Form layout: label on the right	Images and photos (unless they contain directional cues)

Numbers deserve a decision. Arabic text can use Western digits (0–9) or Eastern Arabic digits (٠–٩). Some business sites use Western digits for prices and phone numbers; whichever you choose, be consistent and test number formatting in forms, invoices and emails.

4. Choose Arabic fonts for the screen

Pick a family designed for Arabic UI and body text, not a decorative calligraphic face
Load a matching Latin companion or a family that covers both scripts, so mixed lines look balanced
Arabic usually needs a larger font size or line-height than Latin at the same nominal size; test with real paragraphs
Don't letter-space Arabic. Its letters connect, and tracking breaks the joins
Avoid italics for emphasis; use weight instead
Subset and self-host fonts where possible to keep pages fast

5. URLs and hreflang

Give each language its own URL, for example /en/… and /ar/…, rather than switching language with a cookie on the same URL.

Google's documentation on localised versions sets the rules that matter here:

Each language version must list itself and all other versions
Alternate URLs must be fully qualified, including https://
If two pages don't point to each other, the tags are ignored
Language codes use ISO 639-1 (ar, en), optionally followed by an ISO 3166-1 region (ar-AE, en-AE)
x-default marks a fallback, such as a language selector page

<link rel="alternate" hreflang="en-AE" href="https://example.ae/en/services/" />
<link rel="alternate" hreflang="ar-AE" href="https://example.ae/ar/work-with-me/" />
<link rel="alternate" hreflang="x-default" href="https://example.ae/" />

Google also notes that it doesn't use hreflang or the lang attribute to detect a page's language; it works that out from the content. So a half-translated Arabic page with English body text won't be treated as Arabic.

6. Translated vs localised content

Translation converts words. Localisation rewrites for the reader:

Search terms differ. Arabic speakers may search in Arabic, in English, or in a mix. Research both before writing headings.
Tone differs. Formal Modern Standard Arabic suits most business sites; marketing lines translated literally from English often read stiffly.
Details differ. Phone formats, working weeks, payment options, addresses and public holidays all need local versions.
Write, then review. A native writer drafting from a brief, followed by review, beats a machine translation polished afterwards.

A real example of a right-to-left build: TurkishShip, a project we built, is a public Arabic, right-to-left website that shows factory products from a product catalogue and lets business buyers send a request for quotation.

7. Test like an Arabic user would

[ ] Every page at mobile width in Arabic, not just the homepage
[ ] Forms: typing Arabic and English in the same field, cursor behaviour, validation messages
[ ] Emails and PDFs generated by the site (often forgotten, often left-to-right)
[ ] Search on the site with Arabic queries, including with and without diacritics
[ ] Screen reader pronunciation of the Arabic pages

FAQ

Should Arabic be on a separate domain?

Not necessarily. Subfolders (/ar/) on one domain are simpler to maintain and share the domain's authority. Separate domains make sense mainly for separate legal entities or very different offerings.

Can I just flip the English site with `direction: rtl` in CSS?

The W3C advises against using CSS for the base direction. Use the dir attribute in the markup, then fix layout with logical properties.

Do I need different images for the Arabic version?

Only where an image carries direction or text, such as a screenshot or an arrow-based diagram. Most photos can be reused.

Is machine translation acceptable for the Arabic pages?

As a first draft for review, possibly. Published unedited, it tends to read awkwardly and can mislead search engines about what the page covers.

If you're planning an Arabic–English site and want RTL built in from day one, share a little about your audience and pages.