Translation Glossaries and Termbases: What They Are, How They Differ, and How to Build One that Gets Used

A translation glossary is a list of approved terms and their correct translations in one or more target languages. A termbase is the same thing, but held in dedicated terminology management software rather than a spreadsheet, with richer data attached to each entry and direct integration into a translator’s working environment.

Both tools do the same essential job: they tell translators exactly how to handle the vocabulary that matters most to your business, before the first word of a project is translated. The difference is in how much information each entry carries, how it is accessed during translation, and how well it scales as your content volume grows.

Lionbridge research estimates that approximately 15% of all translation project costs arise from rework, and inconsistent terminology is the primary cause. A glossary or termbase is the single most direct way to cut it.

In this post:

What is a translation glossary?

A translation glossary is a structured list of source-language terms paired with their approved target-language equivalents. In its simplest form it is a two-column spreadsheet: source term on the left, approved translation on the right. More complete entries include a definition, usage notes, part of speech, and any terms that must not be used.

Glossaries are sometimes the only terminology resource a translation project has, particularly for smaller clients or one-off projects. They are cheap to create, easy to share as a document, and can be uploaded to most CAT tools in CSV format.

The limitation is that a spreadsheet glossary is static. It requires translators to consult it manually, it does not surface approved terms as they translate, and it cannot run automated QA checks on terminology use. As project volume grows, these limitations start to cost time.

What is a termbase?

A termbase – also written term base, and sometimes called a terminology database or termbank – is a glossary held in dedicated software. Trados describes it as a searchable repository housing multilingual terms along with reference notes and usage rules. Where a spreadsheet glossary is essentially a lookup table, a termbase is an active component of the translation workflow.

The most widely used standalone terminology management tools include SDL MultiTerm (now part of Trados), memoQ’s QTerm, and Phrase’s term base module. Most translation management systems also include built-in termbase functionality.

The standard file format for exchanging termbases between different tools is TBX (TermBase eXchange), an ISO standard that preserves all field data across platforms. If you work with multiple agencies or tools, this matters: a TBX export from one system can be imported into another without losing entry-level information.

How does a termbase work in practice?

When a translator opens a segment in a CAT tool with an active termbase assigned, the system scans the source text for matches against termbase entries. This is called active term recognition. If the segment contains a term from the termbase, the approved translation appears as an inline suggestion in the editor. The translator does not need to search for it or consult a separate document.

Trados explains the process in four steps: automatic term search, term suggestions surfaced to the translator, translator applies or ignores the suggestion, and QA checks at the end of the project flag any segments where a termbase term was not used correctly.

That last step matters. A termbase is not just a reference tool – it is a quality assurance mechanism. At project close, a terminology QA check can identify every segment where an approved term appeared in the source but the corresponding target translation was missing or substituted. This is something a spreadsheet glossary cannot do.

What is the difference between a glossary and a termbase?

In everyday industry usage, the terms are often used interchangeably. Smartcat notes that within their platform a termbase and a glossary are the same thing. Planet Languages draws a cleaner practical distinction: a glossary is a list typically created in Word or Excel, while a termbase is a more comprehensive database created in dedicated software such as memoQ or SDL MultiTerm, with richer entry data and specific instructions.

The practical difference by format:

For a business translating a short legal document once, a spreadsheet glossary is sufficient. For a software company releasing quarterly updates in eight languages with three different agencies, a termbase is worth the setup cost.

How is either one different from a translation memory?

A translation memory stores full translated segments – sentences, phrases, and clauses – for reuse in future projects. A termbase stores individual terms. The two work at different levels and serve different purposes.

Phrase describes this relationship clearly: translation memory pre-translates a document; the termbase joins the process at the word level after that, with a more “live” quality. In practice, both run in parallel. The TM handles repeated sentence patterns; the termbase handles the vocabulary within those sentences. A project with one but not the other is only half protected against inconsistency.

What should a glossary or termbase entry include?

A minimal entry has a source term and an approved target translation. A useful entry has considerably more. What to include depends on how much ambiguity surrounds the term – the more plausible alternatives exist in the target language, the more guidance the entry needs.

Not every entry needs every field. Product names may only need a DNT flag. Technical terms benefit from a definition and usage note. Forbidden terms are particularly valuable in marketing content, where multiple plausible renderings exist and the wrong choice can feel off-brand or associate your product with the wrong register.

Microsoft’s globalisation guidance treats a definition as the absolute minimum requirement, with context, grammatical information, examples of use, and approval status all adding value beyond that baseline.

Which terms belong in a glossary or termbase?

Not everything. A termbase that tries to cover the entire language is unnavigable. The goal is to capture terms where variation causes genuine problems: where multiple translations are plausible, where the wrong choice is visible to customers, or where consistency across markets is commercially or legally significant.

Terms that typically belong:

• Product and feature names, especially where different markets handle localisation differently
• Brand-specific vocabulary – words your company uses in a way that differs from ordinary usage
• Technical terminology with a single correct rendering in the target language
• Regulated or legally sensitive language in contracts, compliance documents, or pharmaceutical materials
• Acronyms and abbreviations that differ across languages or that should not be translated
• UI copy patterns – button labels, navigation terms, and microcopy that must be identical across platforms
• Forbidden terms – renderings that are plausible but wrong for your context, or associated with competitors

Andovar recommends basing termbases on actual materials used by the company, not generic industry sources. The most useful starting point is your own most-translated content, not a theoretical list of what might be important.

Aim for a manageable initial scope. A termbase of 30–100 well-documented terms is more useful than one with 500 entries and no context. If the termbase becomes too large to search quickly, translators stop consulting it actively.

Why does terminology management actually matter?

The cost argument is straightforward. Lionbridge puts rework at approximately 15% of total project costs, with inconsistent terminology as the primary cause. On a translation budget of £50,000 a year, that is up to £7,500 going to fix problems a glossary or termbase would have prevented.

Brand performance is a separate argument. Aberdeen Group research found that companies which localise on-brand content consistently achieve more than double the average marketing ROI of those that produce local content without brand consistency – 53% versus 21% – along with 46% higher customer retention rates.

CSA Research found that 76% of online shoppers prefer to buy products with information in their own language. That preference only converts into commercial results when the terminology is right – correctly localised content with inconsistent vocabulary confuses rather than converts.

For translators, a well-maintained termbase means less time researching individual terms, fewer decisions overruled in review, and faster onboarding to new client content. This is particularly relevant for marketing translation, where brand voice and terminology interact in ways that take time to learn without documented reference.

When should you create a glossary or termbase?

Before translation begins. A glossary created during or after a project documents inconsistencies rather than preventing them. Translators making ad hoc decisions throughout a project will each make slightly different ones, and the resulting asset reflects that variation rather than correcting it.

Microsoft recommends planning for terminology management from the beginning of any product or content programme, even before localisation is confirmed. Well-defined source terms improve consistency in the original content, and when localisation begins, the termbase foundation is already in place.

For businesses with no existing asset, even a short list of 20–30 critical terms established before the first project in a new language pair will prevent the most common and expensive errors. Start small and add to it.

How do you build a glossary or termbase from scratch?

Step 1: extract candidate terms from source content

Go through your most important or most frequently translated documents and flag every term that meets one of these criteria:

• Multiple plausible translations exist in the target language
• The wrong rendering would be visible to customers
• Consistency across markets or documents is commercially or legally important
• The term should remain untranslated

Automated term extraction tools in platforms like Phrase, memoQ, and Crowdin can surface candidate terms from existing content – useful as a starting point, but the output needs manual review by a terminology specialist or subject matter expert before being approved as entries.

Step 2: agree on approved translations

For each term, identify the approved rendering in each target language. This typically involves subject matter experts who know what the term means in context, and native-speaking translators in the target market who can advise on naturalness, register, and local conventions.

Where multiple options exist, choose one and document why. The definition and usage note fields record the reasoning, not just the decision, which matters when entries are reviewed in future.

Step 3: add context and restrictions

For each entry, include what a translator needs beyond the approved translation: a definition if the term means something specific in your context, usage notes if the term’s role in a sentence affects the translation, and forbidden alternatives if specific options would be wrong even if linguistically plausible.

Step 4: integrate it into the workflow

A glossary sent to translators as a spreadsheet before each project is better than nothing. A termbase assigned to a project in a TMS and active in the translation editor is significantly more effective: the approved term surfaces automatically as the translator works, and QA checks at project end catch any misses.

Most major platforms – Phrase, Lokalise, memoQ, Trados, Smartcat – support termbase integration in real time. Setting it up once pays out on every project that follows.

Step 5: handle locale variants from the start

A single target language is rarely a single market. Spanish for Spain and Spanish for Latin America are not the same, and the same term may have different approved renderings in each. Andovar recommends building locale-specific variants directly into the termbase structure rather than treating regional differences as exceptions to fix later. The same applies to French for France versus French for Canada, or Portuguese for Portugal versus Portuguese for Brazil.

Phrase notes that term bases can be associated with specific locales within a TMS, so a project for ES-MX automatically draws on different approved entries than one for ES-ES where the terminology differs.

Step 6: treat it as a living document

A termbase that reflects product terminology from two years ago is not a neutral resource – it actively leads translators towards outdated decisions. Build a review cycle that matches how fast your terminology changes:

• Software products: review after significant feature releases, or quarterly
• Marketing content: review when brand positioning or campaign language shifts
• Legal or regulated content: review when underlying regulations or compliance documents are updated
• Technical documentation: review when products are revised or retired

When terms are updated, communicate the change explicitly to all translators and agencies. A new file with no change log leaves translators unsure what changed and why.

What is Do Not Translate (DNT)?

Some terms belong in a termbase precisely because they should not be translated. A DNT flag tells translators to leave the term in the source language rather than finding a target-language equivalent.

Common DNT categories include registered trademarks, globally marketed product names, technical standards and format names (PDF, HTML, API), and proper nouns specific to a company or organisation. Without a DNT entry, translators face a judgment call each time the term appears. Some will translate; some will not; and the inconsistency compounds across documents.

One nuance worth noting: a DNT designation on a brand name does not mean the term is handled identically in every market. A Spanish-speaking audience encountering an English product name for the first time may need a short explanatory phrase alongside it on first mention, even if the name itself stays in English. The usage note field in the termbase is where to record this kind of instruction.

What is the connection between a termbase and SEO?

For SEO translation and multilingual keyword research, terminology decisions are keyword decisions. The most searchable rendering of a concept in a target market is often not the most literal translation of the source term. Including keyword-informed term choices in the termbase means translators automatically use the SEO-optimal rendering across every page that contains the term, not only on pages where keyword research was explicitly applied.

Gridly makes this point directly: incorporating keyword research into termbase entries helps translators use terms most likely to improve rankings in their respective languages, since some translation options carry higher search volume than others.

This matters particularly for product descriptions, service pages, and any content where organic search is part of the acquisition strategy. A translator working without a keyword-informed termbase will make linguistically defensible choices that may be commercially suboptimal – and correcting that at scale, after the fact, is expensive.

How does AI change terminology management?

AI and machine translation systems produce fluent output for vocabulary they have seen frequently in training data. For common vocabulary, this is generally reliable. For client-specific brand language, regulated terms, and low-frequency technical vocabulary, it is not.

Most modern MT engines and AI translation platforms support termbase input as a constraint: you provide a list of approved term pairs, and the system is required to use them. This is materially different from asking the model to infer the correct rendering from context. Phrase notes that Smartcat uses glossary terms to improve the accuracy of automated translation results; the same applies across other AI platforms that accept terminology constraints.

The practical implication is that AI makes a good termbase more important, not less. Without one, an AI system will translate your brand terminology as ordinary vocabulary – using whatever rendering appears most frequently in its training data, which may have no relationship to the terms your business has chosen to use.

Work with a team that takes terminology seriously

Building a glossary or termbase is a relatively small upfront investment that pays out on every project that follows. The time spent documenting approved terms before a project almost always costs less than the time spent correcting inconsistency after it.

For marketing translation in particular, terminology decisions are inseparable from how content performs in a given market. The words chosen are the words search engines index and customers read. Getting them right once, and encoding that decision in a termbase, is how that work compounds over time.

If you would like help building a glossary or termbase for your multilingual content programme, get in touch.

Frequently asked questions about termbases and glossaries

What is the difference between a glossary and a termbase? Both store approved terms and their translations. A glossary is typically a simple spreadsheet or document – easy to create, low cost, and shared manually with translators. A termbase is the same concept housed in dedicated terminology management software, with richer entry data, active integration into CAT tools and translation management systems, and automated QA functionality. In many platform-specific contexts the terms are used interchangeably; in a workflow discussion, the distinction is mostly about depth and integration level.

What is a termbase in translation? A termbase is a terminology database that stores approved source-language terms alongside their correct translations in one or more target languages, along with supporting information such as definitions, usage notes, part of speech, domain, and forbidden alternatives. When assigned to a translation project in a CAT tool or TMS, it highlights matching terms in the source text and surfaces approved translations as inline suggestions. At project end, automated QA checks can flag any segments where a termbase term was not used correctly.

What is terminology management? Terminology management is the broader process of identifying, documenting, and maintaining the terms that need to be translated in a consistent and specific way. A termbase is the tool that stores this information; terminology management is the ongoing practice of building, reviewing, and applying it across projects. Without some form of terminology management, translation consistency depends entirely on individual translators making the same decisions independently – which they do not.

How is a termbase different from a translation memory? A translation memory stores full translated segments – sentences and phrases – for reuse in future projects. A termbase stores individual terms. They work at different levels: the termbase controls vocabulary choices within sentences; the translation memory controls the sentences themselves. Both run in parallel in a professional workflow. A project with one but not the other is only partially protected against inconsistency.

What should a termbase entry include? At minimum, a source term and an approved target translation. A complete entry also includes a definition, part of speech, domain or category, usage notes, forbidden alternatives, a Do Not Translate flag where applicable, locale-specific variants, and an approval status with date. The depth of each entry should reflect how much ambiguity surrounds the term – the more plausible alternatives exist in the target language, the more guidance the entry needs.

What does DNT mean in a termbase? DNT stands for Do Not Translate. A DNT flag on a termbase entry tells translators to leave the term in the source language rather than translating it. Common DNT entries include registered trademarks, globally marketed product names, technical standards, and format names. Without a DNT entry, translators face a judgment call each time the term appears, and the results vary.

When should you build a glossary or termbase? Before translation begins. A glossary built during or after a project documents inconsistencies rather than preventing them. Even a short list of 20–30 critical terms, established before the first project in a new language pair, will prevent the most common and expensive errors. For businesses with existing translated content, that material is a useful starting point for extracting and standardising terms that have already been decided.

How many terms should a termbase contain? Enough to cover vocabulary where variation causes real problems – and no more. A termbase of 30–100 well-documented terms is more useful than one with 500 entries and no context. If the termbase becomes too large to navigate quickly, translators stop consulting it in real time. Focus on terms where multiple plausible translations exist, where the wrong choice is visible to customers, or where consistency across markets is commercially important.

Can a termbase be used with machine translation and AI? Yes, and it should be. Most AI translation platforms accept termbase or glossary input as a hard constraint, which means the system uses the approved term pairs rather than inferring translations from context. This produces significantly more reliable output for brand-specific and client-specific vocabulary than relying on the model’s general training. If AI-assisted translation is part of your workflow, a termbase is one of the most important quality controls you can apply.

Does a termbase help with SEO? Yes, particularly for multilingual SEO. Keyword research often reveals that the highest-volume rendering of a concept in a target market differs from the most literal translation of the source term. Recording keyword-informed term choices in the termbase ensures translators use the SEO-optimal rendering across all content, not only on pages where keyword work was explicitly commissioned.

What file format is used to exchange termbases between tools? TBX, or TermBase eXchange, is the ISO standard format for termbase data. It preserves entry-level information – definitions, usage notes, domain, status – when a termbase is moved between different CAT tools or translation management systems. CSV is a simpler alternative supported by most platforms, but does not carry full entry metadata. If you work with multiple agencies or tools, TBX is the more reliable choice for maintaining entry depth across transfers.

---

Author: Maria Scheibengraf

Maria Scheibengraf is an award-winning marketer, multilingual SEO specialist, and English-to-Spanish translator specialised in software, including SaaS, martech, and fintech. She is the co-founder and Operations Manager of Crisol Translation Services and the author of The SEO Translation Bible.