Multilingual content drifts when terminology is left to each translator.

Treat terminology as a system, not a file

A glossary is often handed over as a spreadsheet and then ignored. Terminology governance treats it as a living system: defined owners, update rules, and a way for decisions to reach the people doing the work.

The difference shows at scale. One language and one batch can survive an informal glossary. Many languages across many releases cannot, because every uncontrolled term multiplies into inconsistencies the reader notices.

Lock the terms that must not change

Some terms carry risk if they vary: product names, legal language, safety instructions, regulated claims, and brand wording. These should be locked, with a clear rule that they are not open to translator preference.

Locking terms is not about removing judgment. It is about deciding once, at the right level, so the same word does not get re-decided differently in every language and every batch.

Decide what stays untranslated

Not every term should be translated. Product names, trademarks, UI labels tied to code, and some technical terms often need to stay in the source language across all markets.

A governance system records these do-not-translate decisions explicitly. Without that record, a well-meaning translator localizes something that was supposed to stay fixed, and the inconsistency spreads.

Build the glossary before production, refine it during

The strongest glossaries start before the first batch and grow with the work. A pre-production pass captures the obvious terms; production then surfaces the edge cases that no one predicted.

The key is a feedback path: when a translator or reviewer hits an unresolved term, there is a way to settle it and push the decision back into the glossary so the next batch starts smarter.

Make terminology reachable at the moment of work

A glossary that lives in a folder no one opens does not govern anything. Terminology has to be available where the translation actually happens, in the tool and at the moment a decision is needed.

Whether through a termbase, a query channel, or reviewer notes, the goal is the same: the right term is easy to find, so doing it correctly is easier than guessing.

Govern terminology across languages, across the full language set

It is possible for each language to be internally consistent and still misaligned across the set. A concept can be handled one way in one language and a different way in another, which breaks cross-market coherence.

Governance should check alignment across languages, across the set as well as inside each language. This matters most for concepts that carry brand meaning or regulatory weight in every market at once.

Capture decisions so they compound

Every terminology decision is reusable if it is recorded. Captured decisions turn a one-time project into an asset the next project inherits, which is where the cost of governance pays back.

The record should hold the term, the decision, the reasoning, and the languages it applies to. Over time that history answers most of the questions a new translator would otherwise raise.

Measure terminology and translation

Quality review often checks fluency and accuracy but skips terminology consistency. Yet a term used three ways across a release is one of the most visible quality failures to an end user.

A mature program tracks terminology adherence as its own signal: how often locked terms hold, how many new terms enter, and where drift appears. That measurement keeps governance honest as volume grows.

Scope checklist for terminology governance

Terminology governance rewards setup before volume. The clearer the locked terms, the do-not-translate list, and the update path, the less a multilingual program drifts as it scales.

• Identify the high-risk terms: product names, legal language, safety, regulated claims, and brand wording.
• Decide which terms are locked and not open to translator preference.
• List do-not-translate items: trademarks, UI labels tied to code, and fixed technical terms.
• Build a starting glossary before production and define how it grows during the work.
• Make terminology reachable in the translation tool, not in a separate folder.
• Set a path to resolve open terms and push the decision back into the glossary.
• Check alignment across languages, across the set as well as inside each language.
• Track terminology adherence as a quality signal alongside fluency and accuracy.

Red flags in terminology handling

A weak program treats the glossary as a delivered file. A strong one treats it as a managed system that reaches the people doing the work and grows with the program.

• The glossary is handed over once and never updated as production surfaces new terms.
• High-risk terms are open to translator preference instead of being locked.
• There is no do-not-translate list, so fixed names and labels get localized.
• Terminology lives in a folder, not in the tool where translation happens.
• Each language is checked alone, with no cross-language alignment review.
• Quality review ignores terminology consistency as a measured signal.

What to send MoniSa for a terminology response

A useful brief lets the team answer with a governance plan rather than a glossary template. Send enough to scope the terms, the languages, and the risk.

• Any existing glossary, style guide, locked terms, and do-not-translate list.
• The languages, content types, and markets the terminology must serve.
• The high-risk terms where consistency carries brand or regulatory weight.
• The tools and platforms where translation and review actually happen.
• Update cadence, ownership, and who can approve a terminology decision.
• Quality expectations and proof needed for internal approval.

For multilingual programs, the strongest terminology response is a governance plan, not a spreadsheet. That plan is what keeps product, brand, and compliance terms consistent across languages and releases, which is the difference a reader feels even when they cannot name it.