How to Enforce a Translation Glossary Across 30 Languages Without Slowing Reviewers

Your German customer asks CS: "Warum steht in einer Ansicht 'Pipeline' und in einer anderen 'Vertriebspipeline'?" Your product uses both terms interchangeably. They mean the same thing in English. In German, using both looks sloppy.

That is a glossary problem. It is also a scale problem, because you cannot manually keep 30 languages consistent by asking reviewers to remember.

What actually breaks when a glossary is not enforced?

Terminology drift is the invisible tax on international products. Three failure modes:

• Same term, different translations. "Pipeline" renders as "Pipeline" in one place and "Vertriebspipeline" in another. Users notice. Sales rep notices. Your product feels unfinished.
• Brand names getting translated. Your product name "Thalarum" (as an example) shows up in the Spanish app as "Talarum". Or "Thalarum" gets translated to a common word in Turkish that means something embarrassing.
• Technical terms handled inconsistently. "OAuth" stays "OAuth" in French but becomes "authentification ouverte" in Portuguese. Now your developer docs are searchable in one language and not the other.

None of these are catastrophic on their own. Together, they add up to a product that looks translated rather than localized. Buyers notice.

Why does the standard glossary workflow fail at scale?

The standard workflow is: write a glossary in a doc, share it with translators, ask them to reference it, hope they do. This works for three languages and 50 entries. It fails at 30 languages and 300 entries for three reasons:

• Reviewers cannot remember 300 entries under time pressure. They will remember the top 20, guess on the next 100, and ignore the rest.
• New reviewers do not read the glossary. They inherit the workflow, they do not inherit the culture that built it.
• MT engines ignore glossaries they are not told about. Passing the doc as context is not the same as constraining generation.

The workflow does not scale because it depends on human memory in a system that operates at machine scale.

Which terms belong in the glossary?

A good glossary is small and specific. Aim for 150 to 400 entries at maturity. Include four categories.

Exclude common verbs, adjectives, and generic UI strings ("Save", "Cancel", "Next"). If you find a common word drifting, the fix is a style guide, not a glossary entry.

How do you inject the glossary into machine translation?

Modern MT APIs accept term dictionaries at inference time. Use them.

• Term dictionary format. Most MT providers accept a source-target pair map per language pair. {"Pipeline": "Vertriebspipeline"} for English to German.
• Do-not-translate marking. Wrap protected terms in inline markers (typically <x> XLIFF tags or provider-specific placeholders) before translation. The engine passes them through unchanged.
• Bias, not guarantee. Constraints bias the output, they do not guarantee it. Always verify with a post-translation lint.

The constraint step is fast, cheap, and catches roughly 80 to 90 percent of glossary violations before they reach a human. That is 80 to 90 percent less noise in reviewer queues.

What does a post-translation CI lint look like?

The lint runs on every translated string in CI. It has three rules:

1. Do-not-translate check. For every DNT term in the source string, the target string must contain the same term unchanged. "Sign in with OAuth" in Japanese must contain the literal "OAuth".
2. Canonical translation check. For every glossary term in the source string, the target string must contain the canonical translation for the target language, not a synonym. "Pipeline" in German must be "Vertriebspipeline", not "Pipeline" and not "Verkaufstrichter".
3. Reverse check for false positives. If the target string contains the canonical translation but the source does not contain the source term, flag it as a warning. This catches cases where a translator over-applied the glossary.

Fail the build on rule 1 and 2 violations. Warn on rule 3.

How do you help reviewers respect the glossary without slowing them down?

Reviewers cannot memorize the glossary. Show it to them inline.

• Highlight glossary terms in the source string. When a reviewer opens a string for edit, every glossary term in the English source is highlighted with a tooltip showing the canonical translation in the target language.
• Suggest the canonical translation on autocomplete. If the reviewer types the first two characters of a glossary term, autocomplete offers the canonical form.
• Show violations in-line during review. If the current translation contains a glossary violation, the UI marks the specific characters and offers a one-click fix.

These three UI patterns reduce reviewer glossary violations by 60 to 80 percent in the first month. They do not slow reviewers down. They make the correct answer the easy answer.

How do you handle disagreements with the glossary?

Glossary entries get contested. That is healthy. Handle it with a structured process, not with silent drift.

• Every entry has an owner. Usually the local marketing or CS lead in that market. Not the translator. Not the engineer.
• Change requests are filed, not made. A translator who thinks "Pipeline" should stay untranslated in German files a change request with example strings and rationale.
• Owner decides within one business week. The change lands in the glossary or does not. Either way, there is a record.
• The decision propagates automatically. When a glossary entry changes, all previously translated strings using that term are flagged for re-review. Not silently updated. Flagged.

This is the process that prevents the glossary from becoming an ossified document nobody trusts.

What is the review cadence for the glossary itself?

Two cadences.

• Continuous additions. Whenever a new feature ships with a name that needs canonical treatment, add the entry to the glossary in every enabled language before the first string ships. This should be part of the feature launch checklist.
• Quarterly full audit. Review all entries. Drop entries for features that were sunset. Update entries where market usage has shifted. Recheck do-not-translate decisions against actual usage in support tickets.

If you go a full quarter without adding a new entry, investigate. Either your product is not shipping new features (unlikely) or your glossary process is not connected to your product process (much more likely).

The mistake to avoid

Most teams treat the glossary as documentation. A well-written doc that reviewers read once and are expected to remember. That approach does not scale past three languages and 100 terms, and it fails silently, which is the worst kind of failure. Treat the glossary as a runtime constraint instead. Feed it to MT. Enforce it in CI. Surface it in the reviewer UI. Own it with named humans. The result is a product that reads consistently across 30 languages with less reviewer time, not more. The teams that get this right find that terminology consistency stops being a topic anyone brings up, which is what success looks like.