How do we manage translation and localization work?

With three parts working together: a terminology glossary that fixes one canonical translation per term, decided once by a named owner; translation memory so a sentence already translated correctly gets reused instead of redone; and review by someone on the client side who owns that market, rather than the vendor checking its own output.

What breaks in localization projects?

Not necessarily the linguistic quality of any single translation — even correct translations drift when nobody owns the glossary, so the same term gets rendered differently across pieces of content produced at different times, and pages quietly fall out of sync with the source with no record of how far behind they've drifted.

Who should review translated marketing content?

A named person on the client side who owns that target market — a regional marketer or a native-speaking colleague with real authority to reject a page and explain why. A translation vendor reviewing its own work is not independent review, regardless of what the engagement is called.

Is translation memory the same as machine translation?

No. Translation memory stores and reuses segments a human has already translated and approved, so an identical or near-identical sentence is matched and reused rather than paid for again. Machine translation generates new text from a model each time. A workflow built around both uses memory for repeated content and reserves human translation, aided by the model, for content that is genuinely new.

How to manage localization workflows

Guide · Market Growth · 4 min read · last verified 2026-08-11

Reviewed before publication Editorial board Independent commercial review

In shortThe operational pipeline that keeps localization from drifting: a glossary decided once, translation memory for consistency and reuse, and independent review by someone who owns the market rather than the vendor being reviewed.

Localization workflows break for a governance reason: nobody owns the glossary, so the same product term gets rendered differently wherever it comes up, and each new translator either guesses again or inherits whichever version they happened to find first. The pipeline that prevents this has three parts: a terminology glossary decided once, translation memory so an identical sentence is never paid for twice, and review by someone who owns the target market rather than the vendor grading its own work. All of it sits downstream of a scope decision: how much of a site needs translating at all is a separate question with its own answer — website translation: how much is enough — and that answer also settles which locales get a glossary and a named market owner in the first place, and which get neither.

Where localization workflows actually break

A linguistically correct translation can still fail the reader. Drift of this kind survives every check a vendor runs, because no single translation is wrong — each was produced by a different person, or a different vendor, months apart — and only the set is. Nobody notices until a customer or a native-speaking colleague points at two pages that say different things. That is a governance gap, not a quality gap: the translation vendor did what it was asked, sentence by sentence, because nothing told it which term to use. Fixing translation quality after the fact treats the symptom; fixing who owns the term list treats the cause.

The terminology glossary, decided once

The glossary is the pipeline's foundation, and it borrows directly from a discipline that has to exist before translation starts: a single approved name for each product and feature, decided once by whoever owns that decision, and used verbatim from that point forward. That is the canonical-term discipline of how to keep product terminology consistent, with one addition for translated content — the glossary needs an approved translation per locale, not just an approved English term, and a translator working without it is being asked to make a naming decision that was never theirs to make. A minimal glossary entry:

Term (source): "Workspace"
Approved translation (de-DE): "Arbeitsbereich"
Do not use: "Workspace" left untranslated; "Arbeitsraum" (retired)
Glossary owner: [named person, one per glossary]
Next review: [date]

Decided once does not mean decided forever — it means changes go through the owner, not through whichever translator hits the term next.

Translation memory: reuse, not just speed

Translation memory is a database of previously translated segments, matched against new source text so a sentence that has already been translated — or one close enough to it — gets reused instead of retranslated from scratch. The speed benefit is real but secondary to the consistency benefit: a segment translated once, correctly, propagates identically everywhere it recurs, instead of drifting a little differently every time a new translator meets it fresh. Translation memory and machine translation solve different problems, and the two get confused for each other — memory reuses human-approved text you already own, while machine translation generates new text from a model. A workflow that leans on memory for repeated content and reserves human translation for new content keeps both consistency and effort in check, without treating either one as a complete answer by itself.

Review by a market owner, not the vendor grading itself

A translation vendor checking its own output is not independent review, whatever the invoice calls it. The review that catches drift, cultural misses, and terminology that reads correctly but sounds wrong needs a person on the client side who owns that market — a regional marketer, a native-speaking colleague, someone with standing to reject a page and say why. That person needs to be named on the project, not represented by "the team," because an unnamed reviewer is a review step nobody is actually accountable for completing.

What breaks without a workflow, concretely

Two symptoms show up before anyone diagnoses the cause. First, versioning: source content changes, and there is no mechanism flagging which translated pages are now stale, so a locale quietly falls behind the English original with no record of how far. A "last reviewed" date per locale, tied to the glossary owner's review cadence, is the fix. Second, silent forking: a regional team, frustrated with turnaround time, starts translating pages independently outside the approved pipeline, and now two versions of the same content exist in one language with no way to tell which is authoritative. Both symptoms trace back to the same missing piece — an owner accountable for the glossary and the review, not a vendor relationship assumed to handle it on its own. A Magrios re-scan may show a locale losing ground in AI answers, which is a downstream signal worth reading if it appears — but a scan can only report drift once it has already happened, while the workflow described here is what keeps it from forming. AI-visibility mechanics for translated content — hreflang, native corroboration, per-locale measurement — are their own subject, split across two pieces: the technical and corroboration layers in how to localize content for AI visibility, and the same logic against specific high-growth regions in how to appear in AI answers in non-English markets. This piece is the operational pipeline underneath both — the part that runs before either question is worth asking.