What is a term base (translation glossary)?

A term base — also called a termbase, glossary or terminology database — is a list of the terms that must be translated consistently, with an approved translation for each target language. It is shown to translators as they work, so the right word gets used every time rather than most of the time.

It is the smallest, cheapest piece of localization infrastructure and it has an outsized effect on whether an interface feels coherent in a language you cannot read.

The problem#

You have a feature called Workspace. Over eighteen months, four translators touch strings that mention it. In French your product now says espace de travail, espace, atelier and workspace in different places. Every one of those is a defensible translation of the English word. Together they are four different features as far as the user is concerned.

The same thing happens to your brand name if it is also a common noun, to domain vocabulary where your product uses a word in a specific sense, and to any term where the obvious translation is not the one your market actually uses.

Nobody catches this in review, because review happens string by string and the inconsistency only exists across strings. It surfaces when a native-speaking customer asks what the difference between espace and atelier is.

What a term base contains#

At minimum, a source term and its approved translation per language. A useful one carries more:

The definition field is the one teams skip and the one that does the most work. “Workspace: the top-level container an organisation’s projects live in” tells a translator something they cannot infer from the word alone, and it is the same information an AI translation engine needs.

What belongs in it#

Keep it small. A term base containing every noun in your product is a term base nobody reads.

Include:

• Product and feature names. The most important category by some distance.
• Terms with a product-specific meaning. If segment means something particular in your application, say so.
• Domain vocabulary where the industry has settled on specific words in each market.
• Do-not-translate entries — brand names, third-party product names, technical identifiers.
• Terms you have already got wrong once. The single best source of entries.

Leave out:

• Ordinary vocabulary a competent translator handles without help.
• Whole sentences. That is what translation memory is for.
• Terms you have not actually decided on. An unapproved entry is worse than none, because it looks authoritative.

A mature term base for a mid-sized product typically runs to a few hundred entries, not thousands.

A worked entry#

What a good entry looks like, as opposed to a two-column word list:

The notes field is doing something specific: it records the alternatives that were considered and rejected. That is the information a new translator most needs and the information most likely to be lost when the person who made the decision moves on.

Term base vs translation memory#

They are complementary and frequently confused.

The distinction that matters: memory helps when the whole sentence resembles something you have translated. A term base helps when the sentence is brand new but contains a term you have already decided about. Most new strings in a shipping product are exactly that — novel sentences made of familiar vocabulary — which is why a term base keeps paying off long after the memory has stopped growing quickly.

How it gets used#

In the editor. Terms appearing in the current segment are highlighted, with the approved translation one click away. This is where the value is realised: the translator does not have to know the glossary exists, they just see it.

By machine translation. WebTranslateIt passes term base entries to its AI engines, so Gemini and Mistral output uses your approved terminology rather than their own choice. This closes one of the larger quality gaps in machine translation.

In validation. Some workflows flag a translation that contains a known term rendered differently from the approved form. Useful, and worth tuning — morphology means the approved form often legitimately appears inflected.

As onboarding. A new translator joining a project reads the term base and immediately knows the decisions already made. Without one, they infer them from existing translations, inconsistencies included.

Building one#

Start from what already exists. Your marketing site, style guide and interface already imply a vocabulary. Extract the twenty or thirty terms that appear repeatedly.

Add every term you have argued about. If someone asked “what should we call this in German”, the answer belongs in the term base regardless of who decided.

Get native review before locking translations in. A term base entry is a decision propagated everywhere, so a wrong entry is worse than no entry. This is the one place to spend on a specialist.

Import in bulk. Most teams already have a spreadsheet somewhere. WebTranslateIt takes a spreadsheet upload, with a column per language, which is usually a ten-minute job rather than a project.

Share across projects. If you run a web app, a mobile app and a marketing site as separate projects, they should share one term base. Split terminology is exactly the problem you are trying to solve.

Revisit it when the product renames something. A term base is a snapshot of decisions, and a rename invalidates entries silently. Adding it to the rename checklist takes a minute and prevents a slow drift back into inconsistency.

The short version#

A term base is a small, curated list of the words that must be right. It costs an afternoon to build, it makes the interface feel like one product in every language, and it is the single highest-leverage input you can give both human translators and AI engines.

If you do one piece of localization groundwork beyond getting the strings into files, do this one.