Translation Glossary: How to Keep Your Docs Consistent in Every Language

Your English manual calls it a “workspace.” The German version says “Arbeitsbereich” on one page and “Projektraum” on the next. The Spanish help center leaves it in English. Nobody made a mistake on purpose. There was simply no shared list of terms.

A translation glossary is that list. This guide explains what goes in one, how it differs from translation memory and a style guide, and how to build and maintain a glossary your writers, reviewers, and machine translation can all follow.

What is a translation glossary?

A translation glossary is a shared list of the terms your documentation must translate the same way every time. Each entry gives the source term, a short definition, and the approved translation in every target language. It also lists the words that should never be translated, like product names.

Glossaries go by other names, too. Translators often call a structured one a termbase. Localization teams may say localization glossary or multilingual glossary. The idea is the same: one agreed answer per term.

Why your documentation needs one

Documentation repeats itself on purpose. The same button, setting, and feature name show up in dozens of topics. Readers learn your words, then search for them. When terms drift, problems follow:

• Readers get confused. Two names for one thing look like two different things.
• Search breaks. A customer who searches for the term in your UI won’t find the topic that uses a synonym.
• Translated docs stop matching the product. If your interface says one word and your manual says another, users can’t follow the steps.
• Review takes longer. Without a reference, every reviewer debates the same terms again.

Machine translation makes this more urgent, not less. A translation engine doesn’t know your product. Left alone, it may translate a feature name as an everyday word, or pick a different translation of the same word in different sentences. A glossary gives it the answer in advance.

Translation memory vs. glossary vs. style guide

These three tools work together, but they do different jobs.

A common question is whether translation memory makes a glossary unnecessary. Research suggests it doesn’t. A 2025 study of machine translation for technical documentation compared a system trained only on translation memory with one that also used a glossary. With good bilingual data, translation memory alone came close on term accuracy. But the glossary still improved consistency, and terminology errors appeared in every setup. The author’s conclusion: terminology databases remain essential for quality checks.

Translation memory reuses what you’ve translated. A glossary says what’s correct. If you already have a documentation style guide, the glossary is its natural companion.

What to put in a translation glossary

Keep entries short. Glossaries work best for single words and short phrases, not full sentences. A sentence belongs in translation memory.

Good candidates for your glossary:

• Product, plan, and feature names
• Labels on buttons, menus, and settings
• Words with more than one meaning in your field
• Industry and legal terms your readers must recognize
• Terms you’ve retired, so nobody brings them back

Words with more than one meaning deserve extra care. The classic example is “bat,” which can mean sports equipment or an animal. Your product will have its own versions. “Publish,” “variant,” and “draft” can all mean something specific in your docs and something vaguer in everyday language.

A translation glossary template

A spreadsheet is enough to start. Use one row per concept and one column per field:

The Avoid column matters as much as the approved term. It records the synonyms writers keep reaching for, so reviewers can catch them quickly.

Tip: Write one entry per concept, not per word. If “account” means both a customer organization and a single user login in your product, make two entries with two definitions.

Your do-not-translate list

Some words should stay exactly as they are in every language. Mark these clearly with “No” in the Translate? column:

• Your company and product names
• Labels printed on hardware that ships in one language
• Code, commands, file names, and API fields
• Names of standards and regulations, when readers know them in their original form

The web has a convention for this: the HTML translate="no" attribute tells translation tools to leave an element alone. The W3C, which maintains web standards, gives a documentation example: a German manual pointing to a printer whose panel button reads “CONTINUE” in English. Translate that word, and readers look for a button that doesn’t exist.

How to build a translation glossary in five steps

You don’t need a terminology department, just a small, accurate list and the habit of using it.

1. Pull candidate terms from what you already have

Start with your product UI, your most-viewed help topics, and your support tickets. List every product name, setting, and label. Add terms that support agents explain often. That’s usually where confusion lives.

2. Pick one preferred term per concept

For each concept, decide the word you’ll use and record the ones you won’t. Settle this in the source language first. If English uses three names for one feature, translators will faithfully reproduce all three.

3. Add a definition and an example

A definition tells translators what the term means. An example sentence shows how it’s used. Together they prevent the most common error: a correct translation of the wrong meaning.

4. Approve translations with a native-speaking reviewer

Ask a native speaker who knows your product — a local support agent, partner, or customer — to approve each translation. Translate for the market, not word for word. Some terms read best translated; others are better left in English because that’s what local users already say.

5. Put it where people actually work

A glossary that lives in a forgotten folder won’t be used. Link it from your style guide and review checklist. Load it into your translation tools. If you document in Sonat, you can keep the glossary as its own topic in your manual, so writers and reviewers find it in the same place as the docs it governs.

Using a glossary with machine translation

Many machine translation services accept glossaries. You upload your term list, and the engine uses your approved translation whenever it finds a matching term. A few practical points:

• Simple files work. Translation services commonly accept glossaries as CSV or TSV files, with the source term in one column and its translation in the next.
• Watch capitalization. Some engines match glossary terms case-sensitively by default. “Workspace” at the start of a sentence may not match “workspace.”
• Still review the output. A glossary reduces term errors; it doesn’t remove them. Check new translations against the glossary before you publish.

If you’ll move terms between tools, look for support for TBX (TermBase eXchange). It’s an international standard (ISO 30042) for exchanging terminology data between translation and authoring tools.

Sonat includes built-in machine translation, so you can produce each language version of your manual from a single source. Pair it with a glossary and a quick review, and every language stays consistent with the English original. For the bigger picture, see our guide to building a documentation localization strategy.

Keep your multilingual glossary up to date

Products change and features get renamed. An outdated glossary is worse than none, because it gives confident wrong answers. Build updates into the work you already do:

• Tie it to releases. When a feature is added or renamed, update the glossary in the same release checklist as the docs.
• Update everything at once. When a term changes, update the glossary, your translation memory, and the published topics. Otherwise the old term keeps coming back.
• Give it an owner. One person approves changes. Anyone can suggest them.
• Review it on a schedule. A quarterly check catches terms that drifted. Treat it like any other part of documentation governance.

This is where terminology management stops being a one-time project and becomes a routine.

Start with twenty terms

You don’t need a perfect, thousand-entry termbase to see results. Start with the twenty terms your readers see most: your product name, your main features, and the buttons in your most-used how-to guides. Agree on them, translate them once, and share the list.

Every new topic and every new language then starts from the same words. Readers recognize what they’re looking at, search works, and your docs say the same thing in every language.

Ready to publish multilingual documentation from a single source? Try Sonat for free.