Building bilingual Arabic/English products
Bilingual is an architecture decision, not a translation task. A handful of early choices decide whether the second language is a real product or a visible afterthought.
Reading time · 9 min
Give each language its own URL
This is the decision everything else rests on, and the most common one to get wrong. If a language toggle rewrites the page in place — same URL, different content, preference stored in `localStorage` — then there is one address for two languages. A search engine can index one of them. The other effectively does not exist, and no amount of translation work changes that.
The fix is that each language is a real document at a real address, with its own canonical tag. English at the root and Arabic under `/ar/` is the common arrangement and the one this site uses. Which prefix you choose matters far less than choosing one.
A second-order benefit is that the language becomes knowable at build time. A server rendering a page can emit the right language on the first byte instead of guessing and letting the client correct it — which is the difference between a page that is indexed correctly and one where the crawler sees English while the visitor sees Arabic.
hreflang, and the way it usually fails
Once each language has an address, `hreflang` tells search engines they are the same page in different languages. Three rules account for nearly every broken implementation.
It must be reciprocal: if the English page points at the Arabic one, the Arabic page must point back. One-directional annotations are ignored. It must be self-referencing: each page lists itself alongside its alternates. And it must be specific — the Arabic version of a case study is that case study in Arabic, not the Arabic home page. Pointing every page at the home page is a common shortcut that makes the whole set worthless.
Add `x-default` to say which version serves a visitor whose language you do not have. And do not annotate a page that does not exist: an `hreflang` pointing at a 404 is worse than no annotation at all. If a section exists only in one language, say that by omission rather than by promising a page you have not written.
Fonts, parity and drift
Arabic web fonts are large — typically several times the size of a Latin face — so subsetting is not an optimisation, it is the difference between a fast page and a slow one. Ship the Arabic subset to Arabic pages and the Latin subset to English ones, rather than every weight of everything to everyone.
Content parity is a product decision that should be taken out loud. A nine-page Arabic site with a one-page English counterpart is a legitimate strategy if your buyers search in Arabic — it is only a problem when nobody decided it. What is not legitimate is machine-translating the second language to achieve nominal parity: thin, obviously-translated pages perform badly and read worse.
Drift is the long-term failure. English gets updated, Arabic does not, and eighteen months later the two describe different products. The structural defence is to keep both languages in one structured source so a missing key is a build error rather than a silent gap — which is exactly how this site is built: the Arabic page fails to generate if a string is missing.
The decisions to make before you build
- One URL per language, each with its own canonical — decided before the first route exists.
- Reciprocal, self-referencing, page-specific hreflang, plus x-default.
- Which content exists in which language, stated deliberately rather than discovered.
- Subsetted fonts per language, not one bundle for everyone.
- A single structured source for both languages, so a missing translation breaks the build.
- Who reviews the Arabic, and when — a translator at launch is not a maintenance plan.
Common questions
Should the Arabic version live on a subdomain or a path?
A path (`/ar/`) is simpler to operate and keeps authority on one host. Subdomains and country domains are defensible when the markets genuinely differ in content and ownership, but they are more to run.
Can we launch in English and add Arabic later?
You can, and it costs more than doing both from the start — the retrofit touches layout, typography, formatting and content at once. If Arabic is genuinely coming, scope it at the planning stage even if it ships in a later release.
Is machine translation good enough to start with?
For understanding an interface, often. For a page you want indexed and trusted, no. Thin machine-translated pages read as what they are, and the cost of the credibility they lose exceeds what the translation saved.
Related guides
Working on something like this?
Tell us what you're building. We send back a one-page response with scope, timeline, and a number you can plan around.
Send us a brief