One question keeps coming from customers running multilingual docs through machine translation: why does the same term come back different across languages, or even across their own topics?
To understand where terminology drift comes from and how teams can prevent it, we compared common multilingual documentation workflows with practical localization experience from Alconost, a company that specializes in software localization.
What counts as “terminology” in documentation
Not jargon in the usual sense — the specialized vocabulary a subject-matter expert uses. Something narrower: the exact words a product uses for itself. Feature names, button labels, menu items, user roles like Admin or Contributor, and entities like “topic” or “project” that mean something precise inside a documentation tool and something else entirely in everyday language.
Get a marketing sentence slightly wrong and the reader shrugs. Get a button name wrong in a step-by-step guide, and the reader is stuck looking for something that, as far as they can tell, doesn’t exist.
Not all of it works the same way, either. Some terms need one consistent translation across every language, and some shouldn’t be translated at all.
“We keep a separate do-not-translate (DNT) list for exactly this: product names and UI elements that have to stay identical no matter what language surrounds them, alongside the glossary that governs everything that does get translated.” – Denis Zhilko, Product Manager, LangOps
Where the drift comes from
Most often there’s no process to begin with. In one English-to-Brazilian-Portuguese project, the same feature name, “Site,” was rendered “Local” in some parts of the docs and “Sítio” in others — one control ended up with two names, and the reader can’t tell they’re the same thing.
Other times a process exists, but the tools involved have real limits:
- Most MT engines support only one form of a term regardless of context. In an English-to-Spanish legal project, “tax rate” kept coming back as “tarifa de impuesto,” which reads as a service fee, when the context called for “porcentaje de impuesto.” The same project needed “associate” as either “asociar” (verb) or “asociado” (noun) depending on the sentence, but the engine’s glossary locked onto one form regardless of context.
- Once a bad entry lands in the translation memory, it gets reused everywhere as an exact match. On one project, a single wrong term or stray formatting character spread far enough to break a client’s build, and the memory had to be cleaned out across multiple projects before it stopped.
And sometimes the process exists and still breaks down:
- On one enterprise project, a term was updated on the source side, but the old translation survived in the reference files and kept getting reused “for consistency” — so the new concept shipped under the old name.
- On another, an approved glossary had gone stale without anyone noticing, and a core product term came back rendered as a compound word that doesn’t exist in the target language at all. The client’s first instinct was to blame the AI; the actual cause was a glossary nobody owned, updated, or enforced.
Why documentation doesn’t get to shrug this off
A marketing translator has room to vary phrasing, since a slightly different word choice rarely changes what the reader does next. Documentation runs on a tighter link between the words and the screen: the reader matches what they read to what’s in front of them, step by step, and the moment a term drifts, that match breaks.
“Consistency matters far more in instructional content than in marketing copy. If a control is named one way on one page and differently on the next, the reader can no longer follow the steps.” – Alconost
What actually fixes it
Based on Alconost’s experience with software localization, a useful glossary works more like a termbase than a spreadsheet of words. Each entry is concept-oriented and can carry metadata such as part of speech, grammatical details like gender, a Preferred or Forbidden status, usage examples, disambiguation notes, and, where needed, subject-matter expert approval.
Here’s what that looks like on an actual project. The “Site” entry is the one that would have caught the Local/Sítio mismatch from earlier, and “tax rate” is the same case behind the tarifa/porcentaje mix-up:
| Source term | Part of speech | Preferred (target) | Forbidden | Note | Status |
| Site | noun | Local (pt-BR) | Sítio | UI feature name, not a website | Preferred |
| tax rate | noun | porcentaje de impuesto (es) | tarifa de impuesto | tax context, not a service fee | Preferred |
| associate | verb / noun | asociar (v) / asociado (n) | — | pick form by part of speech in context | Disambiguation |
| slots | noun | nyerőgépek (hu) | időpontokban | iGaming sense (slot machines), not time slots | Preferred |
Beyond the termbase itself, Alconost points to three practices that make terminology management actually work:
- Context for translators: screenshots, surrounding strings, or direct access to the product, because without it, even an approved term can be applied incorrectly.
- A separate review pass for terminology, apart from grammar and style. Alconost uses MQM (Multidimensional Quality Metrics) to track terminology issues as a distinct quality category.
- An update cadence tied to product releases, not a calendar. When a feature is renamed, the change should reach both the glossary and the translation memory, or the old term can keep resurfacing in new translations.
Multilingual documentation in ClickHelp
ClickHelp is a documentation tool, and for teams maintaining documentation in multiple languages, the challenge goes beyond producing the initial translation. As the source documentation evolves, translated versions need to keep up with every change.
ClickHelp supports this workflow by keeping translation projects synchronized with their source project. When the source content changes, teams can see what needs to be translated or updated instead of relying on someone to notice the changes manually.
For the translation itself, teams can use machine translation integrations such as Google Cloud Translation, Microsoft Translator, and DeepL, or follow a manual localization workflow by exporting content to XLIFF and importing the translated files back into ClickHelp.
Terminology management is one part of this broader multilingual documentation workflow. We hope these practical insights help teams creating and maintaining multilingual documentation keep their translations consistent as their documentation evolves.
The takeaway
Machine translation has no way of knowing which of a product’s terms are critical and which allow more flexibility. That requires context, clear terminology rules, and human ownership. Without them, even a strong MT engine or LLM can produce individually plausible translations that become inconsistent across a larger documentation set.
Alconost’s experience also shows that terminology management has a practical impact beyond consistency. In practice, machine translation with human post-editing has come in 31–49% below the cost of fully manual translation, depending on the language pair. A well-maintained glossary is one of the things that helps make that workflow efficient: when terminology decisions are already defined, reviewers spend less time correcting the same terms over and over again.
The takeaway is simple: terminology consistency doesn’t come from a smarter MT engine or a more capable LLM. It comes from a well-maintained glossary with clear ownership and a process for keeping it up to date.
FAQ
What’s the difference between a glossary and a translation memory?
A translation memory stores previously translated sentences or phrases so they can be reused. A glossary is narrower: it defines the one correct translation for a specific term, wherever that term shows up.
Can machine translation handle product terminology accurately on its own?
Rarely. Most MT engines support only one form of a term regardless of context, so a word that should shift between a verb and a noun, or that means something different in a specific domain, gets forced into a single shape.
Is this a machine translation problem or an LLM problem?
Both, in different ways. A dedicated MT engine tends to lock onto one rigid form of a term regardless of context. An LLM is more flexible with context, but that flexibility cuts both ways: without a fixed glossary fed into the prompt, it can just as easily choose a different valid-sounding translation each time it’s asked. Neither one remembers a past decision unless something makes it remember.
How often should a documentation glossary be updated?
Whenever the product changes, rather than on a fixed schedule. The practical fix is folding glossary updates into the release process, so a renamed feature and its glossary entry change in the same sprint instead of months apart — and giving the glossary a clear owner so that sync actually happens.
Who should own the glossary — the writer, the translator, or the product team?
Shared ownership tends to work best: the product team defines the terms, technical writers maintain the source-language definitions, and translators or localization managers keep the translated equivalents current.
