Building an Arabic Website That Doesn't Look Translated

Most Arabic versions of Lebanese websites are the English site with the words swapped and the text pushed to the right. You can tell within a second of landing on one, and so can the person you were hoping to sell to.

I built this site in both languages, and almost none of the work was translation. It was the hundred small decisions underneath it. Here are the ones that matter.

Direction is a structural property, not a text alignment

The first mistake is treating right-to-left as text-align: right.

Arabic layout mirrors. The navigation starts on the right, the sidebar moves, the back arrow points the other way, progress runs right to left. That comes from setting dir="rtl" on the document and letting the browser flip the layout, not from nudging text across.

Modern CSS makes this nearly free if you write it that way from the start: use logical properties — margin-inline-start instead of margin-left, padding-inline-end instead of padding-right — and one dir attribute flips the whole page correctly. Retrofit it afterwards and you are hunting down every hard-coded left in the stylesheet, which is how sites end up half-mirrored.

Not everything mirrors

Directional icons flip: back arrows, next arrows, anything indicating progress.

Logos do not. Media controls do not — play still points right, because it maps to how time works, not how text reads. Phone numbers and email addresses do not. Latin brand names do not.

Getting this wrong in either direction looks broken. A mirrored logo looks like a mistake, and a back arrow pointing the wrong way makes people hesitate before every click without knowing why.

Latin words inside Arabic sentences

This is where most Arabic sites fall apart, and it is worth understanding rather than working around.

Arabic technical writing keeps product and technology names in Latin script. Nobody searches for نكست جي إس, and transliterating a company's name makes it unverifiable. So an ordinary Arabic sentence on a developer's site contains runs of English.

The browser handles that reasonably well until punctuation gets involved. Characters like +, ., # and / are directionally neutral — they take direction from their surroundings. So C++ inside an Arabic sentence can render with the plus signs on the wrong side of the letters. Same for .NET, re/Start, C#.

The fix is to wrap those runs in a left-to-right mark (U+200E) so the punctuation stays attached to the word it belongs to. It is invisible, it costs nothing, and without it your stack list quietly reads as nonsense to anyone who knows the language.

Date ranges have the same problem. I pin them left-to-right and leave them in English on both versions, because a date range with mixed direction is genuinely hard to read.

The font is not a detail

Most Latin typefaces ship no Arabic glyphs at all. If you do not specify an Arabic font, the browser falls back to whatever the visitor's operating system has, which means your carefully designed page renders in a system default you never chose and cannot preview.

Worse: if you load an Arabic font but only its regular weight, every bold heading gets synthesised by the browser — smeared, uneven strokes that look exactly like the amateur typography you were trying to avoid. Load the weights you actually use.

Pick a face designed for interface and long-form reading rather than a coverage font. A typeface whose job is to have a glyph for every script in Unicode will be legible and characterless. One drawn for text will sit next to your Latin type without the two looking like they are arguing.

Do not machine-translate it

If the Arabic on your site was produced by pasting the English into a translator, your readers know. Not because the grammar is wrong — it often is not — but because the register is.

Arabic marketing copy is not English marketing copy with Arabic words. Headings are structured differently. A CV written in Arabic uses verbal nouns where an English one uses first-person verbs. Idioms do not survive the trip.

If you cannot write it or pay someone who can, ship English only and say so. A clean English page is more professional than an Arabic one that reads like a machine. Half-translated is the worst of the three — it signals that the Arabic-speaking customer was an afterthought, which is precisely the message you were trying not to send.

Each language needs its own URL

Not a toggle that swaps the text in place. A real URL — /ar/about alongside /about — that someone can link to, bookmark and share, and that a search engine can index separately.

Then tell search engines the two are versions of each other with hreflang annotations, each pointing at the other, plus an x-default. Without that you are competing against yourself: two pages saying the same thing in different languages, neither clearly the answer for either audience.

The language switcher should also map the current page to its counterpart, not dump everyone on the Arabic homepage. Someone reading your pricing page in English wants the Arabic pricing page.

Details that give it away

• Forms. Labels, placeholders, validation messages. An Arabic form that says "This field is required" in English was translated on the surface only.
• Numbers. Decide between Arabic-Indic and Western digits and be consistent. Mixing them on one page looks careless.
• Line height. Arabic script needs more vertical room than Latin at the same size. Reusing your English line height makes dense paragraphs feel cramped.
• Text expansion. Arabic translations often run shorter than English, sometimes longer. Buttons sized exactly to their English label will break.

How to actually test it

Read it on a phone, at the width most of your visitors use, with the network throttled. Then have a native speaker read it — not to check the grammar, but to tell you whether it sounds like a person or like a translation.

That last test is the one that catches what none of the technical work can. Everything above makes an Arabic site render correctly. Only a reader can tell you whether it sounds like you.