Before You Translate a Single Page: Multilingual Architecture Decisions

A prospective client arrived this winter with a finished translation project and an unsolvable problem. The vendor had delivered beautiful French content: accurate, natural, reviewed. And none of it could go anywhere, because the website it was destined for had no concept of language. No way to hold a French page alongside its English sibling. No navigation that could switch. No URLs for a French version to live at.

The invoice was paid. The architecture conversation had never happened. We have now seen enough versions of this story to state the rule plainly: in multilingual work, architecture comes before translation, always. There are enough of these decisions, and they matter enough, to deserve their own planning document. Here is what belongs in it.

Decision one: where languages live in your URLs

Every multilingual site must answer a deceptively simple question: what is the address of the French version? There are three credible answers, and each has a profile.

Country-code domains (yoursite.fr) signal maximum local commitment and carry the strongest geographic tie in search. The cost: you manage multiple domains. Each builds link authority from zero. Each is a separate property to govern.

Subdirectories (yoursite.org/fr/) keep everything on one domain. Authority and administration stay in one place. This is the practical default we recommend for most institutions, and the pattern search engines handle predictably. The engines’ webmaster tools now let you set geographic targeting per directory, which answers the main old objection.

Subdomains (fr.yoursite.org) sit between, and mostly combine the drawbacks.

The decision turns on your actual situation. A manufacturer with legal entities and marketing teams per country may truly want country domains. A university recruiting internationally almost certainly wants subdirectories. What no one should want is the fourth pattern we keep finding in audits: language chosen by cookie or session with no URL difference at all. That gives search engines one URL per page and no way to index the alternatives. It hides every translation from the searchers it was made for.

Decision two: encoding, end to end

UTF-8 everywhere is the rule, and ‘everywhere’ is the word doing the work. The database. The connection to it. The CMS, the templates, and the HTTP headers. All must declare the same encoding.

Miss one link in that chain and the site works perfectly in English, then serves garbled text the day the first accented character arrives. Usually in production. Usually in a donor’s surname. Auditing an existing site’s encoding chain is an unglamorous afternoon. Discovering the broken link during launch week is a memorable one.

This is also the moment to check the details English lets you ignore: date formats, number formats, currency display. Each varies by locale. Each is embarrassing when wrong. Each is solvable with the locale libraries every modern platform ships, if someone remembers to use them.

Decision three: separating what gets translated from what gets configured

A page in another language is more than its body text. The navigation labels, form buttons, error messages, and search prompts must translate too. The architecture question is whether those strings live in translatable systems or are hard-coded into templates where no translator will ever find them.

Platforms with real localization frameworks separate interface strings into layers a translator can manage. Drupal 6’s language system, whose arrival we covered last year, remains the strongest argument in its class. Community translations cover the standard vocabulary, and your own overrides handle house terms. Custom-built sites need this separation designed in on purpose.

The test worth running before any translation contract: change the site language on staging and count what is still in English. Every survivor is a string someone forgot to pull out of the template. The list is your punch list.

The decision that actually determines success: the workflow

Everything above is necessary. None of it is what kills multilingual sites. What kills them is the question nobody assigns an owner: when the English page changes, what happens? Without a workflow answer, the answer is ‘nothing,’ and the translations begin their drift toward the archaeology exhibit we described in the Drupal 6 piece.

The workflow that works is unshowy and explicit. Source-language changes flag their translations as outdated. A named owner per language reviews the flags on a schedule. A translation path, staff or vendor or both, turns flags back into current content. And a sync report showing what is current, stale, and missing gets read monthly by someone who can act.

Platform support helps. Drupal’s translation-status tracking does exactly this flagging. But the roles are the essential part. A language without an owner is a clone with extra steps, whatever the software.

Which surfaces the budget truth that belongs in every proposal: translation is an operating cost, not a launch cost. The institutions that succeed budget year two, the ongoing translation of new and changed content, as a line item alongside hosting. The ones that budget only the launch have pre-purchased drift. The drift is visible to exactly the audiences the money was meant to serve.

The vendor conversation, properly sequenced

A word on working with translation vendors, since the opening story turned on getting this backward. Good translation firms are genuinely good at language. They are not responsible for your architecture. The handoff between the two is where projects fracture.

The sequence that works: architecture decided and built first, then a content export the CMS can round-trip. Use structured formats the vendor’s tools can consume and return with identifiers intact. That way translated content flows back to its proper places instead of arriving as documents someone must hand-paste.

Ask prospective vendors about their format capabilities early. The answer quickly sorts the modern operations from the email-a-spreadsheet shops. And bring your glossary: house terms, program names, the phrases that must stay consistent, decided once with your own bilingual staff and enforced across every batch.

Translation memory, the vendor-side tool that reuses previously translated segments, rewards this consistency with falling per-word costs over time. That is the rare buying dynamic where discipline literally compounds into discount.

Scope, honestly drawn

Final planning note, learned from sync reports: resist translating everything. The sustainable pattern for most institutions is a deliberate core per language. The pages that audience genuinely needs, maintained well. Not a full mirror maintained hopefully.

A prospective student in São Paulo needs admissions, programs, costs, and contact in Portuguese. She does not need the faculty senate minutes, and pretending otherwise just spreads the year-two budget until nothing stays current.

Draw the scope from audience tasks. The IA discipline transfers directly. Publish it internally so expectations match the plan. Expand from evidence as the analytics show what each audience actually uses. Small and true beats large and stale. In multilingual work, by a wide margin, forever.