Most multilingual website problems do not start with bad translation.
They start several weeks earlier, when a team scopes the project based on what is visible right now, designs no process for what happens next month, and hands off content for translation without defining who is allowed to change the final version.
By the time the translated pages go live, the conditions for rework are already in place.
Website localization projects fail at the workflow design stage more often than at the translation stage. The checklist below is weighted toward process decisions, because those are the ones most teams skip.
Before you start: the scope question most teams answer wrong
The natural instinct is to list everything that needs to be translated. This produces a word count. A word count produces a cost estimate. The project starts.
The problem is that “translate all the pages” does not answer the more important question: which content needs to stay current over time, and what is the process for keeping it aligned?
Before scoping begins, clarify:
- Which pages represent the core customer journey in each market
- Which pages are tied to product features that change regularly
- Which pages carry brand or positioning claims that require cultural adaptation, not just word-for-word translation
- Which pages can realistically be maintained at the same pace as your source content
Launching ten languages across two hundred pages with no update workflow is a setup for version drift at scale. It is often better to launch four languages across eighty core pages with a working update process than to launch everything at once with no plan for what happens after go-live.
The update workflow: the question that determines everything downstream
Of all the things most localization projects skip, this is the one that creates the most avoidable cost:
What happens when the source page changes?
This is not a hypothetical. For any active website, source content changes continuously. Product names change. Positioning evolves. Campaigns launch and end. Pricing updates. Legal text gets revised.
If there is no documented answer to how language versions get updated when source content changes, the website will drift out of alignment. Not because translation is difficult, but because nobody is watching.
The workflow needs to define:
- how source changes are flagged and communicated to the translation and review process
- who is responsible for initiating updates in each language
- what turnaround standard applies to different content types (product page vs. news vs. homepage)
- what the version of record is for each page, and where it is stored
Without these answers, content teams will make individual judgment calls about what to update and when — which means different answers from different people, and inconsistent pages across markets.
Review ownership: the part where most projects slow down
Translation is frequently fast. Review is where multilingual projects stall.
The review problem typically has three causes:
Unclear review authority. When a translated page needs final approval before publishing, who gives it? If the answer is “anyone on the marketing team” or “whoever is available,” you will get repeated revision cycles with no clear endpoint.
Review by people not qualified for the task. A senior executive who speaks the language fluently is not the same as a qualified market reviewer. Market review requires knowledge of how the target audience actually speaks about the product — not just grammatical fluency.
Late review in the process. If language review happens only after full page design and CMS integration, corrections become expensive. Review should happen early, before content is embedded in production layouts.
Before launch, define:
- who has sign-off authority for each language version
- what criteria they are reviewing against (accuracy, tone, terminology, brand fit)
- at what stage of the process review happens
- what a “review pass” and a “revision request” look like, in terms of scope and timing
Terminology control: the thing most teams defer too long
Terminology problems are quiet until they are not.
When a product name, feature label, or category term is translated differently on the product page, the help center, and the sales deck in the same market, customers notice — even if they cannot articulate why the content feels inconsistent.
Before translation begins, compile:
- product and feature names with their approved translations per market
- brand terms that should not be translated (kept in the source language)
- terms that are legally sensitive or regulated and must be handled specifically
- competitor and category terminology that has market-established conventions
This does not need to be an exhaustive glossary from the start. Even a working list of fifty critical terms prevents the most damaging inconsistencies.
The publishing readiness checklist most teams forget
Beyond translation and review, the localized website also needs to work technically and commercially in each market.
Before launching a localized version, confirm:
- hreflang tags are correctly implemented for all language versions (Google uses these to serve the right page to the right user)
- country/region selectors or language switchers work correctly and visibly
- currency, date format, measurement units, and address formats are adapted per market
- any market-specific legal requirements (cookie banners, data processing notices, terms of service) are in place
- contact information, phone numbers, and business hours are localized
- forms and checkout flows are tested in each language and in the actual market context
These are not translation issues. They are launch readiness issues. But they block a working localized site just as effectively as a mistranslated headline.
Website localization projects most commonly fail at scope definition, update workflow, review ownership, and terminology control — not language quality. Most of these failures are preventable with process design before translation begins, not correction after launch.
Where to start if you are planning a multilingual launch
If you are about to scope a website localization project, start with the hardest question first: how will these pages stay current in six months?
If the answer is clear — you have an update workflow, defined review owners, and terminology under control — the translation work that follows will be more manageable and less prone to rework.
If the answer is not yet clear, that is the right place to spend time before briefing any vendor.
If the TMS vs. agency question is also on your list at this stage, Translation agency or TMS? What enterprise teams actually need to decide addresses that decision directly — and makes the case that workflow design comes before vendor selection regardless of which option you choose.
The Core service is designed specifically for teams that need both the initial localization and the ongoing update workflow. If you are at the planning stage and want a diagnostic on your current setup, start here.