A localization glossary fails when it becomes a spreadsheet that translators consult only when they remember. The same product concept then appears under different translations across screens, releases, help content, and store listings. A global find and replace is no safer because one spelling can represent several concepts. Build the glossary as versioned product data instead: give each concept an identity, scope its approved terms, record each decision, attach a glossary version to every translation job, and check shipped locale files for drift. The result is a terminology workflow that catches inconsistency without flattening legitimate language differences.

Diagnose the terminology failure before adding rules

Start with evidence from the product. Collect examples where one concept has several renderings, a protected name was translated, or an old term survived a rename. Include the source key, locale, screen, product version, visible text, and expected decision. Do not begin by importing every repeated noun into a glossary.

A current Hermes Desktop issue provides a concrete failure pattern. The reporter found translated and untranslated forms for session, token, prompt, and skill, plus two Chinese renderings of provider. This is one user's report about one locale build, not a general claim about translation software. It still shows why key completeness cannot prove terminology consistency. Every string can exist while the interface uses several names for the same thing.

Classify each finding before changing text:

The same concept has conflicting translations.
Two concepts share a source spelling but need different translations.
A product name, command, file extension, or protocol token must remain unchanged.
A grammatical form is valid only in a specific sentence.
An older term is still correct in historical, legal, or compatibility copy.

These classes need different controls. A glossary entry can solve the first three. Sentence context and message design often control the fourth. Version and surface scope protect the fifth.

Model concepts rather than word pairs

A two-column list such as Workspace -> Arbeitsbereich loses the reason behind the choice. It cannot tell a translator whether Workspace names a paid product object, a menu heading, or an operating system feature. Model the record around the product concept rather than its current spelling.

Scope glossary entries by concept, surface, and grammatical role instead of matching raw words globally.

This point receives little attention in basic glossary setup pages, which focus on creating a resource or adding terms. It prevents false corrections. Crowdin's glossary documentation exposes fields such as definition, part of speech, subject, usage examples, variants, and status. Those fields let reviewers describe what a term means, not only how it is spelled. Use them, or preserve equivalent fields in a repository owned format.

A practical concept record can look like this:

concept_id: account.session
source_locale: en
source_term: session
definition: authenticated period between sign-in and expiry
subject: authentication
surfaces:
  - mobile-ui
  - desktop-ui
grammatical_role: noun
terms:
  zh-Hans:
    approved:
      - 会话
    prohibited:
      - Session
  de:
    approved:
      - Sitzung
owner: identity-team
status: approved
revision: 4

This schema is an implementation recommendation, not a format required by Google Cloud or Crowdin. Keep concept_id stable when wording changes. A renamed English source term should create a new revision of the concept, not a second unrelated row. That continuity lets the team find every translation produced under an older decision.

Add separate concepts when one source word carries different meanings. Post can be a noun in a social feed and a verb on a submit button. Charge can name a payment, a battery state, or an action. One global target is wrong even if it appears consistent in a report. Scope can use product domain, screen family, resource namespace, grammatical role, or a small combination that reviewers can apply reliably.

Avoid scopes tied to a single temporary component path. A path such as src/views/new/AccountPanel.tsx will age badly. Prefer durable product language such as billing.invoice, authentication.session, or editor.publish-action.

Define approved, prohibited, and unchanged forms

An approved term tells translators what to use, while a prohibited term records a rejected choice that automated review should catch.

Use at least these states:

approved: the normal rendering for the defined concept and scope
allowed_variant: a valid inflected, abbreviated, or space-constrained form
prohibited: a known mistranslation, outdated name, or inconsistent variant
unchanged: a token that must remain byte-for-byte identical
needs_review: a proposed term that cannot enter automated translation yet

Google Cloud's guide to creating and using translation glossaries documents equivalent and unidirectional term sets, case behavior, and translation requests that use a named glossary resource. That supports controlled machine translation, but your product workflow still needs to decide which concepts deserve rules and which variants remain valid in context.

Do-not-translate entries need precise boundaries. Protecting Go globally could block the ordinary English verb in help text. Protecting Go only as the programming language under developer-tools.language-name avoids that error. Match command names and protocol tokens as tokens, not substrings. A rule for ID should not flag the letters inside paid.

Record capitalization policy separately from the term. Some product names have fixed case. Ordinary words may follow sentence position or target-language conventions. A checker that treats every capitalization difference as terminology drift will generate enough noise that reviewers stop trusting it.

Version every terminology decision

A glossary changes when the product changes. Teams rename features, replace vendors, revise legal labels, and learn that an earlier translation carries the wrong implication. Editing the current row in place destroys the answer to a basic release question: which term set produced this file?

Record the glossary version used by every translation job so terminology changes can trigger targeted re-review.

Provider documentation explains how to create and apply glossary data, but it rarely connects a glossary revision to the exact app strings translated under it. That connection gives localization leads a bounded repair path. A change to one billing concept should reopen the strings that used that concept, not every string in every locale.

Store a small job manifest beside each translation batch:

{
  "job_id": "checkout-copy-2026-09-14",
  "source_revision": "app-copy-8.7.2",
  "glossary_version": "product-terms-42",
  "locales": ["de", "ja", "zh-Hans"],
  "concepts_used": ["billing.invoice", "billing.subscription"],
  "review_state": "linguistic-review"
}

The manifest format is a recommendation. Its value comes from the links among source revision, glossary version, affected concepts, locales, and review state. Put the glossary file and change history under the same review controls as source copy. A terminology pull request should show the old decision, new decision, rationale, owner, affected locales, and migration plan.

Use semantic change rules:

Adding a definition or example without changing allowed output needs no string migration.
Adding an allowed grammatical variant may require checker updates but not retranslation.
Replacing an approved term should find and reopen every current string that uses the old form for that concept.
Adding a prohibited form should scan active locale files and report matches.
Changing scope should rerun both positive and negative checks because earlier matches may become valid exceptions.

Do not rely on the latest glossary alone when reproducing an old release. Keep immutable tagged versions or a commit identifier so an incident review can reconstruct the rules in force at build time.

Add terminology checks without creating noise

Terminology QA should combine exact checks with context. A raw search can find an obsolete branded term, but it cannot prove that every approved term belongs in every sentence. Use automated checks to identify review candidates, then preserve explicit exceptions.

Test prohibited variants with explicit exceptions to catch drift without rejecting intentional homographs.

This is less common than provider-side glossary matching, and it changes how teams enforce consistency. A checker that cannot express exceptions becomes a false-positive generator. A checker with reviewed exceptions can block known regressions while leaving valid language alone.

A simple check record could contain:

rule_id: terminology.provider.zh-Hans
concept_id: infrastructure.provider
locale: zh-Hans
prohibited:
  - 提供商
approved:
  - 提供方
scope:
  include_keys:
    - settings.provider.*
    - errors.provider.*
exceptions:
  - key: marketplace.seller.provider
    reason: refers to a commercial supplier, not an infrastructure provider
    approved_by: zh-reviewer

Run checks against parsed localization values, not raw files. Raw matching can inspect comments, keys, metadata, or escaped sequences and report the wrong line. Preserve message variables and plural branches while extracting visible text. For languages without whitespace boundaries, use the locale's segmentation rules rather than an English token regular expression.

Use two kinds of result:

A prohibited rendering appears inside the concept's scope.
A high-risk source concept appears without an approved target rendering where the mapping should be unambiguous.

The first result can block CI after reviewers have tuned the rule. The second should begin as a warning because morphology and sentence structure may make direct string matching unreliable. Track accepted exceptions in the same repository so the next run does not reopen the same decision.

Connect the glossary to translation and review

Apply terminology before generation, during linguistic review, and after files return to the app repository. Checking at all three points catches different failures.

Before translation, validate the glossary schema, duplicate concept IDs, locale tags, empty approved lists, overlapping scopes, and contradictory approved plus prohibited forms. Export the provider-specific glossary from this validated source rather than editing several provider copies independently.

During machine translation, pass the correct glossary resource for the job's language direction. Google Cloud distinguishes equivalent term sets from unidirectional term sets, so the export must preserve direction instead of assuming every pair works both ways. Record the provider resource name and internal glossary version in the job result.

During human review, show the definition, subject, usage example, allowed variants, and neighboring screenshot or string context. Crowdin's glossary model includes these concept details and surfaces glossary terms to translators. Reviewers still need authority to reject a glossary choice when the sentence requires another grammatical form. Capture that decision as an allowed variant or scoped exception instead of leaving it in a chat message.

After import, run terminology checks against the exact locale artifacts that will ship. Then test representative screens. File-level checks can find a prohibited word, but they cannot show that a clipped label hides the approved term, an image contains old text, or server content bypasses the app catalog.

Handle failures and roll back safely

Plan for bad rules. An overbroad entry can spread one wrong translation faster than a manual workflow. Keep generated glossary artifacts tied to an internal version, and make the previous approved version available for immediate reuse.

If a new rule creates bad output:

Stop new jobs from using the affected glossary version.
Mark the concept revision rejected without deleting its history.
Restore the last approved version for active jobs.
Find jobs and strings produced with the rejected revision.
Reopen only the affected locale and scope combinations.
Add a regression fixture that demonstrates the false match.

Do not fix the output alone. Without a rule correction and fixture, the next translation batch can reintroduce the same mistake.

Treat provider import failure as a build failure for the glossary artifact, not permission to run without terminology controls. If translation must continue, record the job as glossary-free and require an explicit terminology review before approval.

Verify the workflow on one risky concept

Choose one concept that users see often and that already has conflicting variants. Run it through the whole lifecycle before importing hundreds of entries.

Verify that:

the concept has a durable ID, definition, owner, and scope
every target locale has approved, allowed, prohibited, or unchanged states as needed
the provider export contains the intended language direction
a translation job records its glossary version
the checker catches a prohibited form in an in-scope fixture
the same form passes in a documented out-of-scope exception
a term change finds only affected strings and sends them back to review
the shipped screen displays the approved form without clipping or stale cached copy
the previous glossary version can reproduce the earlier release

Start with that one concept and its fixtures today. Merge the glossary rule only after both the positive match and the intentional exception pass in CI.

A glossary entry still needs per-string context at translation time; see how to give translators enough context for ambiguous UI strings.