AI translation with glossary support: Deterministic terminology for LLMs

Why general-purpose AI models get brand translations wrong

A general-purpose LLM is trained on broad web data. It has no knowledge of your product naming conventions, legal disclaimers, and tone of voice, among other brand attributes. Plus, this model doesn't know your market either.

This is the context deficit problem. It’s a structural gap between what a generic model knows and what consistent, compliant translation actually requires. And you can’t fix this deficit by writing detailed prompts. 

Telling an LLM to “use these terms” leads to probabilistic compliance. That means, you might get a good output in a few test runs. But when you run the same prompt across 10,000 strings or a larger content volume, you’ll likely receive inconsistent results.

Fixing this problem would require:

• Auditing every output
• Re-queuing all translation strings
• Bearing a high post-editing cost 

A more effective solution at the structural level is to move terminology control out of the prompt entirely and turn it into a dedicated constraint layer. That’s where your translation glossary comes into play.

How a translation glossary constrains LLM output

Traditionally, a translation glossary worked as a reference document in the form of a PDF in a shared folder, a tab in a spreadsheet, or a brief attached to a translation project. Linguists would refer to this tool passively when needed. 

Today, an airtight AI translation workflow uses the glossary as a critical guardrail for LLMs. Your translation glossary serves as a structured termbase with machine-actionable fields that LLMs use as hard constraints during output generation.

Here’s an overview of how the translation glossary has evolved with AI:

Let’s understand how this works in a translation management system (TMS) like Lokalise.

Lokalise uses AI orchestration to give LLMs your complete brand context at the point of output generation, rather than as an instruction that the model may or may not follow. With this information, the model operates within this context as a constraint. 

When you build a glossary in Lokalise, you can create machine-actionable fields like:

• Non-translatable: Brand names, product IDs, and proprietary acronyms that must pass through unchanged in every language. These terms are never translated. 
• Forbidden: Terms that must not appear in any translation output. These could be deprecated product/feature names, legally restricted phrases, or competitor trademarks.
• Case-sensitive matching: Critical for technical brands and acronyms where capitalization carries meaning.
• Tags: Organize terms by product line, content type, or risk level, so the right terms travel with the right content.
• Stemming: Lokalise automatically matches glossary terms across word forms, supported for 14+ languages. “Payment method” is automatically matched to “payment modes,” “paid method,” and other root-form variants without manual entry.

Here’s a preview of a glossary CSV file:

These fields work together to close different failure modes. Non-translatable terms remain unchanged during translation. And forbidden terms don’t appear at all in the output. 

For example, if “Translate Now” is your product's primary CTA and you flag it as non-translatable, Lokalise's orchestration layer retains that term across all language pairs. If “Legacy Translate” is a deprecated feature name you've flagged as forbidden, it won't show up in any output, regardless of how frequently it appeared in the model’s training data. 

How Lokalise's AI orchestration leverages glossary context

LLMs are cooperative. When you tell them what context to use, the models mostly follow these instructions. But the challenge is to give these models precise contextual constraints so that the output aligns with your brand rather than sounding generic or causing compliance errors.

AI translation in Lokalise operates at an orchestration layer that routes content to the optimal model, such as GPT-5, Claude, and others, for every language pair and content type. 

Each translation task in Lokalise is enriched with the project glossary, translation memory, and style guide before the model generates anything. These form the contextual constraints the model operates within. 

Rather than loading the entire termbase into every prompt, Lokalise matches each source string lexically and injects only the terms that appear in it. This per-segment approach matters for two reasons:

• Clean context: It keeps the context clean and prevents the risk of the model getting confused by irrelevant entries. A model handed 400 glossary entries for a string that contains two relevant terms is more likely to produce noise than one handed exactly those two terms. 
• Better LQA: The matched terms carry through to your LQA process. That means the quality checks are evaluated against the same constraints the model was working with, instead of a separate reference layer.

As a result, around 80% of outputs are publish-ready without further edits. And glossary compliance plays a huge role in achieving this high degree of accuracy.

Here's how Lokalise’s glossary compares to the alternatives:

How to build an airtight brand glossary for AI translation

Now that we’ve understood how glossaries can support AI translation, let’s talk about the harder part of the problem: maintaining a well-governed glossary. 

Your brand terminology can change every week, features can be deprecated, and legal terms can be updated. All of these updates make your glossary outdated and create a liability because LLMs will faithfully enforce these obsolete constraints. 

That’s why we recommend these best practices for building and maintaining your AI translation glossary.

Types of terms to include

Define three categories of terms for your brand glossary:

• Brand and product terms: This covers product names, feature names, company names, branded services, UI element labels, and taglines. Flag non-translatable where the source form must carry through unchanged. 
• Technical and domain terms: This covers industry-specific jargon, technical identifiers, and regulatory or legal terminology requiring precision. Include language-specific approved translations so the model doesn't invent equivalents.
• Forbidden and risk terms: This covers deprecated product names, retired brand language, competitor trademarks, and legally restricted phrases. Use the Forbidden flag in your Lokalise glossary.

Governance basics

Glossary quality inevitably decays without anyone actively reviewing and maintaining the termbase. That’s why it’s important to clearly define:

• Who can add terms
• Who approves them
• Who reviews for compliance

Lokalise's permission model supports contributor-level access to glossary management. This means you can structure your permissions to match your localization and brand review workflows rather than giving every team member unrestricted write access.

For teams managing multiple product lines or regional deployments, the Shared Glossary feature ensures a single source of truth across all projects.

The quality of your glossary determines the quality of AI translation output. That’s why this governance infrastructure becomes load-bearing for enterprise organizations managing hundreds of glossary terms across dozens of locales. 

Get your terminology right for AI translation

Think of your glossary as a critical part of the AI translation infrastructure. Rather than a tool of passive reference, it’s the constraint layer that makes AI translation deterministic, brand-consistent, and defensible at scale.

The ROI of getting this right is direct. Glossary compliance creates deterministic, brand-aligned output. This means fewer review cycles and lower post-editing volume. And for teams expanding into multiple new markets, brand consistency at that scale is achievable with a well-governed glossary acting as a constraint layer. 

Start a free 14-day trial of Lokalise and see how glossary integration changes your AI translation output from the first run.