Multilingual website projects: what to decide before you build
Building a multilingual website for a client? Decide the languages, URLs, fallbacks and who translates before you build. Each is hard to change later.
The client says "we'll need it in French as well" in the kick-off meeting, as an aside, between the logo and the launch date. It sounds like a feature. It's actually a set of decisions that touch the content model, the URLs, the theme, the launch checklist and every content change for the rest of the site's life.
Most of those decisions are cheap to make before you build and expensive to change afterwards. Here's what to settle first when a multilingual website is on the table, and what to agree with the client before anyone writes a template.
Which languages, and which is the default
Start with the list, and be specific. "French" or "French for France and Canada"? Is there a language the business genuinely operates in, or one a director would like to have? Every language added is a permanent cost, because every page now exists that many times and someone has to keep each version current.
Then choose the default language: the one every page exists in, the one the site falls back to, and usually the one served at the unprefixed URL. Changing the default later is close to a rebuild.
The URL scheme
There are two common shapes.
Prefixes on one domain. The default language at /about, French at /fr/about, German at /de/about. One site, one domain, one certificate, one place to manage. This is the right choice for most client sites.
Separate domains. example.co.uk and example.fr. It can help when the business is genuinely distinct per country, with different products, prices or legal entities. It also means separate domains to buy, renew and point, and more to get wrong.
Whichever you choose, choose it once. Moving a site's languages from one scheme to the other changes every URL in every language, which is a migration with redirects, not a setting.
Which fields are translated and which are shared
Not everything on a page is language. A product's name and description are. Its price, SKU, photo and dimensions usually aren't. A team member's bio is, their name and headshot aren't. A location's address might be shared, its directions translated.
Go through the content model field by field and mark each one translated or shared. This is the decision clients find most tedious and agencies most often skip, and it's the one that decides how much work every future edit creates. A shared field is changed once. A translated field is changed once per language, forever.
When a translation is missing
At some point a page will exist in the default language but not yet in French. Decide what a French visitor sees.
Fall back to the default language. The visitor gets the English page, inside the French site. Nothing is ever missing, but the site is visibly mixed.
Show nothing. The page doesn't exist in French until it's translated. The French site is consistent, but it has holes, and links into it need handling.
Neither is wrong. The choice depends on whether the client would rather look incomplete or look inconsistent, and it should be their choice, made deliberately.
Who translates, and who reviews
Name the people. Is the client's own staff translating? An external agency? You? Who checks a translation before it's published? Who notices when the English page changes and the French one is now out of date?
That last question is the one that decays. Translations are usually right at launch. Six months later, the English pages have been edited a dozen times and nobody has told the translator. Whatever tool you use, you need a way to see which pages are out of date in which language, or the site slowly becomes two different sites.
Machine translation
Machine translation is now good enough to be a useful first draft, especially for straightforward copy. It is not good enough to publish unread. It gets brand names, tone, legal phrasing and idiom wrong in ways that are obvious to a native speaker and invisible to everyone else.
Budget for a human review of every machine-translated page, and treat the machine output as a draft, never as a finished translation. The saving is real: reviewing is faster than translating from scratch. It's just not the whole job.
hreflang and sitemaps, in plain words
Search engines need to know that /about and /fr/about are the same page in two languages, not two competing pages. That's what hreflang does: each version of a page names its alternates in the other languages. Without it, a French searcher can be shown the English page, or the two versions can compete with each other in results.
The sitemap should list each language version as its own URL, with the same alternates. Both should be generated from the content, not hand-maintained, because nobody keeps them correct by hand.
How Contentive handles it
On Contentive, the Multilingual app is included on the Agency plan. Translation is set per field, so the translated-versus-shared decision lives in the content model. Languages use prefix routing (/fr/…), and hreflang alternates are emitted in every page and in the generated sitemap. Each page carries a translation status per language, so out-of-date translations are visible rather than discovered. The fallback is a setting: a missing translation either shows the default language's text, or shows nothing. Machine translation writes into a draft and is never published automatically. There's a translator role that can work on translations without being able to touch other content, and themes get a language switcher.
What it costs
Every new field becomes a translation decision: translated or shared, and who updates it. Every content change becomes N changes, one per language, or a backlog of out-of-date pages. And before launch, every page is N pages to check: copy, links, forms, titles and descriptions, in every language. Put that multiplier into the pre-launch checklist and into the quote, because it's real time.
The one-page language brief
Before the build starts, agree a single page with the client that covers:
The languages, and the default.
The URL scheme.
Which content types and fields are translated, and which are shared.
What a visitor sees when a translation is missing.
Who translates, who reviews, and how fast after a change.
Whether machine translation is used for first drafts.
What's in scope for launch, and what's added later.
It belongs in the scope appendix alongside the content model, which is where scoping a website project and what is a content model come in.