When people hear "a website in twelve languages", they picture a translation job. Hand the text to translators, paste it back in, done. In practice, translation was the smaller part. The harder part was building the site so that twelve versions stay correct as the site keeps changing.
Here's how we approached it, for anyone planning something similar.
Rule one: no text in the templates
Every visible word on the site lives in a translation file, one set per language, not in the page template. That includes the obvious headings and also the easy-to-forget bits: button labels, image descriptions for screen readers, form placeholders, tooltips and messages shown by scripts.
It's a bit more effort per page, but it means a language is a matter of adding files, not editing pages. It also catches a classic bug early, where one forgotten English sentence sits in the middle of an otherwise Arabic page.
Split sentences carefully
A heading with one highlighted word in the middle looks harmless. But word order differs between languages, so a heading built from three glued-together pieces can't always be translated sensibly. Where a heading has a highlighted part, we store it as separate pieces that translators can rearrange, instead of one fixed sequence.
Likewise, we avoid building sentences from fragments in code. "You have 3 items" should be one translatable sentence with a placeholder for the number, because other languages put the number elsewhere or change the word form.
Keep every language in sync
The danger with many languages isn't the first launch. It's six months later, when someone adds a line in English and forgets the other eleven. So we wrote a small checker that compares each language against English. It flags missing files and keys, placeholders that don't match, broken HTML tags in a translation, and strings that were never actually translated.
On top of that, an automated test renders every page in every language and fails if a key is missing or raw key text leaks into the page. A page that would show home.hero_title to a visitor never reaches production.
Right-to-left is a layout problem, not a text problem
Arabic and Urdu mirror the page. The trap is building layouts with "left" and "right" in the style rules. Margins, alignment and positions written that way don't flip.
We use logical properties instead: "start" and "end", rather than "left" and "right". A margin at the start of a line is on the left in English and on the right in Arabic, with no extra code. Physical left and right only appear in the few places where we genuinely mean the visual side, such as centring something.
Icons with a direction, like arrows, need attention too, since an arrow pointing forward should point the other way in a right-to-left page.
Fonts for every script
A font that looks great in English may not have Arabic, Bengali, Devanagari or Chinese characters at all, and the browser quietly substitutes whatever it finds, often something ugly. We declare fonts per script, loaded only when needed, so a visitor reading Bangla gets a proper Bangla font. For Chinese we use the fonts already on the visitor's device, which avoids shipping very large font files.
All fonts, logos and icons come from our own server. Several outside services are blocked or unreliable in some of the countries our visitors live in, and a missing font or icon shouldn't break the page.
Colours come from tokens
We have a light and a dark theme, and the same rule applies: no colours written directly into pages. Everything refers to named theme values, such as the main text colour or the surface colour. That way, changing a theme in one place changes it everywhere, and no page is left with a white box on a dark background.
Detecting the language
On each visit, the site decides the language in a set order: an explicit choice in the link, then what the visitor chose before, then the language the browser asks for, and finally English. The saved choice is stored in the visitor's session and in a cookie. The search engines also get a list of the language versions of each page, so the right one appears in the right country's results.
What we'd tell another team
Decide your rules before you translate. Build the checks early, because they pay off every time you add a page. Test with native readers, since automated tests can't tell you that a phrase sounds odd. And budget for the long term: a multilingual site isn't a launch, it's a habit.
