Building a multilingual website with right-to-left support

Adding Arabic, Hebrew, Persian or Urdu to a website is not just translation. Those languages are written from right to left (RTL), and the whole layout has to follow. Done well, the page feels native; done badly, you get mirrored layouts that are half-broken, scrambled punctuation and search engines that cannot tell your language versions apart. This guide covers the decisions that matter, in the order that saves the most rework.

Start with the HTML, not the CSS

Tell the browser the language and the direction on the root element:

<html lang="ar" dir="rtl">

The lang attribute drives hyphenation, font selection, spell checking and screen readers, which switch to the right voice. The dir attribute drives text direction, and with it the order of flex and grid items, the side that scrollbars appear on and the alignment of text. Use the attributes, not CSS tricks, to set the direction. The W3C's guidance on the dir attribute explains why.

If a short passage runs the opposite way, for example an email address, a phone number or a brand name in Latin letters inside Arabic text, wrap it in an element with its own dir, or use <bdi> for user-generated text of unknown direction. This prevents punctuation from jumping to the wrong end of the line.

Write your CSS in logical properties

Physical properties such as margin-left, padding-right, left and text-align: left assume one direction. Logical properties describe the same thing relative to the reading direction: margin-inline-start, padding-inline-end, inset-inline-start and text-align: start. With them, one stylesheet serves both directions and there is no second "RTL stylesheet" to keep in sync. The MDN reference lists the full set.

Flexbox and grid already follow the direction, so a row of items reverses without extra code. What does not flip by itself:

• Icons that point somewhere, such as back and forward arrows, chevrons on next buttons and progress indicators. Mirror them in RTL.
• Icons that do not mean a direction, such as a magnifier, a clock, a tick or a logo. Do not mirror them.
• Transforms and animations that slide something in from a side. Check each one.
• Background images and gradients with a direction built in.
• Charts, timelines and media controls. Convention varies, so decide deliberately.

Typography for Arabic needs its own care

• Choose a font that supports Arabic properly. Arabic letters change shape depending on position, and a font that lacks them falls back to something mismatched. Test with real text, not placeholder Latin.
• Do not add letter-spacing. Arabic is a connected script, and spacing the letters breaks the joins and makes the text harder to read. Reset any letter-spacing you applied to Latin headings.
• Avoid italics and all-capital styles. Neither exists in Arabic, and synthetic slanting looks wrong.
• Allow more line height. Arabic has marks above and below the line, so a tight line height that suits Latin text can crowd them.
• Be consistent about numerals. Both Western digits (0 to 9) and Arabic-Indic digits are used, depending on region and audience. Pick one convention and apply it everywhere, including prices and dates.

Give each language its own address

For search engines and for people sharing links, each language version needs its own URL, for example /ar/ in the path or a language-specific domain. Avoid switching the language only through cookies or scripts on the same address, because search engines cannot index what they cannot reach. Do not redirect visitors automatically based on their location or browser language either. It traps people, including those who are travelling or who prefer another language, and it can stop crawlers from seeing the other versions. Offer a visible language switcher and remember the choice instead.

Tell search engines with hreflang

The hreflang annotation tells Google which language version belongs to which audience. According to Google's documentation:

• Each version must list itself as well as all the others.
• The links must be reciprocal. If the English page points to the Arabic page, the Arabic page must point back, or the annotations may be ignored.
• Use language codes such as en and ar, with an optional region such as en-GB.
• Add x-default for visitors whose language you do not offer, for example a language chooser or your main version.
• You can place the annotations in the page head, in HTTP headers or in the XML sitemap. They are equivalent, so choose one and keep it consistent.

Only annotate versions that exist and are good. Pointing hreflang at a half-translated page does the reader no favours.

Translation is a content job, not a switch

• Have a native speaker review. Machine translation is a useful first draft, but legal wording, calls to action and anything about money need a human who reads the language every day.
• Plan for length. Arabic can be shorter or longer than English depending on the phrase. Buttons and navigation must not break when text grows.
• Translate the whole journey. Forms, error messages, emails, confirmation pages and the cookie banner all count. A fully translated page ending in an English error message feels unfinished.
• Be honest about gaps. If a page is not yet translated, say so and show the original, rather than leaving a blank or mixing languages without a note.
• Localise, do not just translate. Dates, currency, phone formats, examples and imagery should suit the audience.

Testing checklist

1. Open every template in RTL at phone, tablet and desktop widths and look for overflow and misaligned icons.
2. Type long and short strings into every field, including mixed Arabic and Latin text, numbers and email addresses.
3. Tab through the page: the focus order should follow the visual order, which is now right to left.
4. Check forms: the cursor, validation messages and placeholder text should align correctly.
5. View the page source: lang, dir, hreflang and canonical tags should be correct on every version.
6. Ask a native speaker to read the pages and to try the main task, such as an enquiry or a purchase.

Building the layout once with logical properties, a sound HTML foundation and a clear URL structure costs little extra at the start and saves a great deal later. Retrofitting RTL onto a layout built with left and right everywhere is the expensive way to do it.