What is a translation glossary? Definition, examples, and how it is enforced

A translation glossary (also called a termbase or terminology database) is a curated list of the terms a product must translate the same way every time, with the approved translation for each language and, where it matters, the variants that are allowed and the ones that are forbidden. It covers the words that carry meaning for your users: product and feature names, UI actions, legal and domain terms, and the words that must stay untranslated. It does not cover sentences, tone or grammar; those belong to the translation memory and the style guide.

This post is the definitional one: what an entry contains, how a glossary differs from the two things it is most often confused with, why machine and AI translation depend on it more than translators do, how it is enforced, and what it does not fix.

What a glossary entry contains

A glossary is a list of concepts, not a list of words, and that distinction decides whether it is useful. The entry for a concept like "subscription" holds:

• The source term as it appears in your product, ideally with a short definition or a usage note so that "subscription" the billing object is not confused with "subscribe" the newsletter action.
• The preferred translation per language. One term, the one the product uses everywhere: "Abo" in German, not "Abonnement", not "Subskription".
• Allowed alternatives, when a variant is acceptable in some contexts: a longer form for legal text, an abbreviation for a narrow button.
• Forbidden terms: the translations that were used at some point and must not come back, or a competitor's term, or a word that has a different meaning in your domain. Forbidden terms are what make a glossary enforceable, because "use X" is hard to check and "never use Y" is easy.
• Do-not-translate entries. Product names, brand names, trademarks and certain technical identifiers are glossary entries whose translation in every language equals the source. Without the entry, every translator and every model decides for themselves.

A glossary of forty well-chosen concepts is worth more than one of four hundred generic words. The concepts that belong in it are the ones where a wrong or inconsistent rendering costs something: money, trust, legal exposure, or a support ticket.

Glossary, style guide, translation memory: three different things

These are confused constantly, partly because a good translation tool shows all three next to the segment being translated.

The style guide tells the translator, the model or the agent that German uses the formal "Sie" and that the audience is developers; the glossary tells them that "subscription" is "Abo"; the translation memory tells them that "Your subscription ends tomorrow" was translated last year and how. Remove any one of the three and a specific class of defects returns.

Why machine and AI translation need a glossary more than translators do

A human translator who worked on your product last month remembers your product name, your German word for subscription and the fact that "Open" is a button. A machine translation engine or a language model does not, because each request starts without memory. Send the same source term in twelve batches over a year and you get several renderings, each defensible in isolation. Users see the screens side by side; the model never does.

That makes the glossary the load-bearing piece of any automated translation setup, in two distinct roles:

1. As an input. The relevant terms are applied to the request: injected into the AI prompt as "use these exact translations", or applied as a lookup by a machine translation engine that supports terminology. This is how last year's decision reaches this morning's batch.
2. As a check afterwards. Models paraphrase, engines ignore hints, and a forbidden term comes back anyway. A check that flags a forbidden term in a saved translation catches what the input did not prevent.

The same logic applies to AI coding agents that draft translations inside a code change: the glossary has to be something the agent queries before drafting, not a document it may or may not have read.

How a glossary is enforced

A glossary that lives in a PDF is a wish. Enforcement means the glossary runs as a check where translations are saved, with findings attached to the segment:

• Forbidden term found. The translation contains a term the glossary forbids for that language. This is the high-precision finding: there is no legitimate reason for the word to be there.
• Approved term missing. The source text matches a glossary entry, but the translation uses none of the approved terms for that language. Lower precision, because inflection and word order can hide a correct term, but it is the finding that catches a model quietly inventing its own rendering.
• Inconsistent translation of the same source value, corpus-wide. Not strictly a glossary check, and that is the point: it finds the terms that are translated three different ways and are not in the glossary yet. The output of this check is the input to the next glossary review.

Findings that reviewers can dismiss per segment, where a deviation is intentional, are what keep the checks switched on. A check without a scoped escape hatch gets disabled within weeks. The wider taxonomy of what automated checks catch, and the measured share of segments affected, is in what actually breaks in translations.

How teams build and maintain glossaries today

• A spreadsheet. One row per concept, one column per language, shared with the agency. The most common starting point, and fine as a source; the problem is that it is not connected to anything, so enforcement is whoever remembers to open it.
• Term extraction from existing translations. Mining the corpus for recurring terms and, more usefully, for terms that are already translated inconsistently: those are the entries the glossary needs first. Tools can suggest candidates; a person approves them, because a glossary entry is a decision, not a statistic.
• A terminology exchange file. TBX (the ISO 30042 XML standard) and UTX (a tab-delimited format from AAMT) move glossaries between translation tools and agencies; the TBX and UTX format reference covers both.
• A glossary inside the translation management system. Terms are shown to the translator next to the segment, injected into machine and AI translation, and checked on every save. This is the setup where the glossary stops being a document.

The maintenance rule is the same everywhere: review the glossary whenever a product term is introduced or renamed, and whenever the consistency check surfaces a new disagreement. A glossary nobody updates is accurate about the product of two years ago.

What a glossary does not solve

• Sentences. A glossary guarantees the term, not the sentence around it. Fluency, meaning and register are the job of the translator, the model with a style guide, and review.
• Ambiguity the entry did not anticipate. "Open" the verb and "Open" the status are two concepts; if the glossary has one entry, it enforces the wrong one somewhere. Entries need definitions, and the ambiguous cases need context or screenshots.
• Inflection and grammar. The German preferred term declines; a check has to tolerate "Abos" and "Abonnements" alike, and a naive exact match produces noise instead of findings.
• Quality of the decision itself. A glossary enforces consistency, not correctness. If the approved term is wrong, it is now wrong everywhere, consistently. That is still better than being wrong in three different ways, because one entry fixes it.

How this works in Locize

The glossary in Locize is a project-level list of concepts with the preferred, allowed and forbidden terms per language.

• Building it. Import a TBX or UTX file, add terms by hand, or let Locize mine your existing translations: Scan for terms lists recurring terms across your keys, with the ones currently translated inconsistently first. Nothing is added automatically; you approve each candidate, pre-filled with the translations already used in the project.

Suggested glossary terms in Locize: recurring terms mined from the project, inconsistently translated ones listed first

• Using it. In the editor, every segment shows the matching glossary terms next to the translation, with the approved usage and the alternatives. The same terms are injected into automatic translation, bulk machine and AI translation and the AI assistant, together with the style guide, and exposed to AI coding agents through the MCP server's get_glossary tool, described in the context tools post.

The glossary panel in the Locize editor next to a segment, with the approved term and the translation memory match

• Enforcing it. Terms are checked every time a translation is updated: a forbidden term raises issue 230, a matched source term without an approved target term raises issue 231, both documented under glossary consistency checks. The corpus-wide consistency check for the same source value translated differently runs on demand, for one segment or the whole project, and its findings are the shortlist for the next scan.

If you want to know which terms your project is already translating inconsistently: create a project, import your translation files, open the glossary and click Scan for terms. The first list is usually longer than expected, and shorter than it will be next year.

Frequently asked questions

What is a translation glossary? A curated list of the terms a product must translate the same way every time, with the approved translation for each language and, where it matters, allowed variants and forbidden terms. It covers product and feature names, UI actions, legal and domain terms, and words that must stay untranslated; not sentences, tone or grammar.

What is the difference between a translation glossary and a translation memory? A glossary stores terms with their approved translation, decided by people. A translation memory stores sentences translated before, collected automatically, and offers them again when a similar sentence comes up. The glossary answers "which word do we use for this concept"; the memory answers "have we translated this sentence before".

What is the difference between a glossary and a style guide? A glossary lists terms and their translations. A style guide sets the rules of voice: tone, formality, audience, do-and-do-not examples, per language. The glossary says subscription is "Abo" in German; the style guide says German addresses the user as "Sie". Neither replaces the other.

Do I need a glossary for machine translation or AI translation? More than for human translators. A model request starts without memory, so the glossary is what carries terminology decisions into the next request, as injected terms and as a forbidden-term check afterwards. Without it the same concept is rendered differently across batches.

How is a glossary enforced automatically? As a check on every saved translation: a forbidden term in the translation, or a matched source term with none of the approved target terms, raises a finding on the segment. A corpus-wide consistency check surfaces the terms that are not in the glossary yet.

What file format is a translation glossary? TBX (ISO 30042 XML) and UTX (tab-delimited, from AAMT) are the exchange formats; many glossaries start as a spreadsheet with one row per concept. A translation management system imports TBX or UTX or lets you add terms directly.