What breaks when a website is translated into Arabic

Translating the text is the smallest part of the job. What breaks is direction, layout, numbers, forms and fonts — and a page can pass a translation review while remaining unusable, because the reviewer reads words and the browser lays out shapes. A page with the direction set on the document and a font with real Arabic coverage survives most of this; remove either and the Arabic becomes decoration on a left-to-right page.

Is the page Arabic to the browser, or only to the reader?

Setting the text is not the same as declaring the language. The document needs lang="ar" and dir="rtl" on the root element, as described in MDN's reference for the dir attribute. Paragraph direction, the end a full stop lands on, the side a list marker takes and the behaviour of a scrollbar all follow from it.

Without it, the browser guesses from the first strong character of each paragraph. The guess is usually right for a paragraph of Arabic and wrong for everything around it: a heading that opens with a number, a table cell holding a Latin product code, a caption with a date. The page looks Arabic in one place and English in another, and nobody can say why.

Where a block deliberately carries the other language — a French quotation inside an Arabic article — set the direction on that element.

What should mirror, and what must not?

Mirroring the layout is the easy half: navigation, sidebars, form labels and text alignment follow reading order. The hard half is deciding which icons follow it too. The test: does the icon encode reading order, or encode a thing? A back arrow encodes the direction you came from, so it flips. A play button encodes a physical symbol that means the same everywhere, so it does not, and a chart with a time axis keeps its direction.

Element	Mirror?
Back and forward arrows	Yes
Text alignment, list markers	Yes
Play, skip, volume controls	No
Logos, product photographs	No
Progress bars	Yes
Clock, media timeline	No

The failures are rarely a whole page: one arrow in a carousel pointing the wrong way, a breadcrumb separator rendered as a backwards slash.

What does letter-spacing do to Arabic?

It breaks it. Arabic is a joined script; the connections are part of the letter shapes. Add tracking and the joins stretch or fall apart, so a word looks like a row of isolated letters. Other Latin habits fail too: there is no upper case in Arabic, and italics have no tradition here — they render as a slanted, badly fitted copy of the font. Emphasis comes from weight or colour.

What happens to phone numbers inside Arabic?

They get reordered. The bidirectional algorithm lays out a run of digits or Latin letters by its own rules, so a phone number at the end of a sentence can display with its parts in the wrong order, and an email address can appear to begin where it ends. The W3C note on bidi control characters explains the mechanism and the isolation characters that contain it.

Isolate the run: wrap a phone number, email, reference code or URL in an element with dir="ltr", so it is placed as one unit. Do it in the content model, not by hand in each article, or the tenth article will be the one that breaks.

Digits are a decision: Western and Arabic-Indic both exist, so pick one and keep it in prices, tables and dates.

Which form fields break first?

The ones taking a value with a fixed shape: phone, email, postal code, bank reference, card number. If such a field inherits right-to-left direction, the caret starts at the wrong end, the placeholder looks correct and the typed value does not, and a half-typed number jumps.

Set those inputs to dir="ltr", keep the label and error message in Arabic, and align the field to the start of the form rather than a hardcoded side. Then check the two things that always escape: the required marker, which moves to the other side of the label, and the error text, often positioned with a physical left and landing under the wrong field.

Which tables and truncation break?

Tables are where direction and alignment fight. The label column moves to the right, correctly, but numeric columns aligned right in English now sit against the labels. Decide per table: labels at the start of the row, numbers consistently on one side, no text-align: left in the stylesheet.

Truncation is the quiet one. A single-line clamp puts the ellipsis at the end of the line, which in a right-to-left block is the left edge, and an Arabic word cut there can lose the part that distinguishes it. Clamp by lines, or let it wrap.

Which fonts actually have Arabic?

Many web fonts are Latin-first. They load, they look right in English, and the Arabic falls back to whatever the operating system supplies: a different weight, height and rhythm. Headings look heavier than body text, and the digits come from a third font.

Choose a family that ships Arabic glyphs, or pair a Latin face with an Arabic one deliberately and set the line height for the taller. Check the digits and the punctuation, and check that a real bold exists — a synthesised bold smears the joins.

In what order should you fix this?

1. Set lang and dir on the document, and on blocks carrying the other language.
2. Replace every physical left, right, margin-left and padding-right with a logical property.
3. Decide icon by icon what mirrors, and write the list down.
4. Isolate every Latin or numeric run in the content model.
5. Set direction and alignment on the fixed-shape fields, then test a half-typed phone number.
6. Load the real Arabic font and compare it against the fallback at phone width.

Where this goes wrong

• Testing on a screenshot. A translated mock-up hides reordering, caret position and the font swap, which are what users meet.
• Flipping the page with a transform. scaleX(-1) mirrors the text as well as the layout. It looks clever in a demo and is unreadable in production.
• Setting direction in one component. A header with its own dir and a footer that inherits one produce a page that disagrees with itself.
• Forgetting what is not text. Images with English captions baked in, PDFs, social cards and email templates need the same decision.
• Assuming translation covers design. Arabic needs a different line height and rhythm. A box that fits the French will not fit the Arabic.

What this advice does not cover

It does not judge the translation, or whether the Arabic reads as Arabic rather than as rendered French. It says nothing about accessibility beyond direction, and it leaves out the typographic work of pairing Arabic typefaces.

We build interfaces where the Arabic edition is designed, not translated.