Getting your terminology right is not nice‑to‑have. It is how you protect meaning, speed up translation, and keep your brand coherent across products, markets and teams. This guide shows you how to plan, build and run a pragmatic termbase that people will actually use, with a mix of clear narrative and a few focused checklists.

What a termbase solves

Modern content moves fast. Product pages, help centres, app strings, contracts and investor materials often ship in multiple languages on the same day. If each team uses different words for the same thing, you create friction: reviewers argue about wording, translators raise avoidable queries, and customers see inconsistent language.

A good terminology database, or term base, reduces that friction. It gives writers and translators approved terms with clear definitions, flags what not to use, and enforces consistency inside the tools where content is created. Over time, it stabilises phrasing so translation memory works harder and review cycles shorten.

What terminology management is

Terminology management is the discipline, within translation management, of deciding, documenting and enforcing the words your organisation uses. The output is a terminology database – also called a termbase – that stores concepts, the preferred term in each language, and the rules for how those terms behave.

Glossary vs termbase

A glossary is a simple list of words and equivalents. It is easy to start and just as easy to lose control of. A termbase is structured, searchable and integrated with your writing and translation tools. It treats each entry as a concept, supports definitions and context, and records status and ownership so you can govern change rather than chase it.

What a good termbase contains

Think of the termbase as a data model, not a spreadsheet. Each entry represents a concept, and each concept can have one or more terms per language. Start small but make the fields you capture do real work for you.

At minimum, capture a preferred term, a plain‑language definition, an example sentence, domain ownership, and who approved it. Add synonyms, forbidden terms and do‑not‑translate flags as soon as you can – these decisions prevent rework and stop word debates from spiralling.

Core fields to capture

• Concept ID and preferred term per language

   

• Definition in plain language and a real example sentence

   

• Domain tag – legal, marketing, UI, support, finance

   

• Synonyms and variants, plus forbidden terms with the approved alternative

   

• Do‑not‑translate items and handling notes

   

• Owner and approver, status, review date and change history

   

Optional fields when you are ready

If your teams need them, add gentle grammar notes, attributes for UI case sensitivity and character limits, SEO notes for public‑facing phrasing, and pronunciation guides for names and acronyms. Only capture fields you will maintain.

Who owns a termbase and who contributes

Clear roles keep the database useful. Most organisations do well with a single accountable owner in content, localisation or product marketing, supported by a linguist or terminologist who curates entries and runs reviews. Contributors include product managers, writers, support and translators who propose terms when they spot gaps. Approvals sit with subject‑matter leads for each domain, with legal weighing in on sensitive items.

A pragmatic governance model

Publish how proposals move from draft to approved, who can deprecate a term, and how often you release updates. Keep it explicit but light. When people can see the path, they follow it.

How terms move from idea to approved entry

The workflow you are showing – suggestions → approval → translation or adaptation → approval → integration – is the backbone of a healthy termbase. Here is how to run it in practice.

Suggestions for new terms

Anyone close to the product or content can propose a term – product managers, writers, support, engineers and translators. Proposals include the source sentence, a plain‑language definition, domain, suggested preferred term, known synonyms, and whether the term should be translated or not. Submissions land in the termbase as proposed with an auto‑assigned curator.

First approval

The curator de‑duplicates, checks for clashes with existing entries, and routes the proposal to the right domain owner – legal, UI, marketing or finance. At this stage you decide the concept scope and set initial usage notes. Status moves to in review.

Translation or adaptation

In‑market linguists add target‑language entries, adapting for morphology, register and constraints such as UI character limits. Do‑not‑translate cases are validated here and documented with handling notes – for example, pluralisation or case rules. Entries are returned to the curator with any risks flagged.

Final approval

The domain owner approves meaning and fit for purpose; legal signs off sensitive items. The curator resolves comments, finalises the definition and usage examples, and flips status to approved.

Integration into the termbase

Approved entries publish to read‑only lookup for all staff and sync to CAT tools so terms highlight automatically during translation and QA. Release notes list new, changed and deprecated items so reviewers know what to watch for in the next sprint.

Service‑level targets to keep momentum:

• Triage within 2 working days
• Domain review within 5 working days
• Translation and in‑market review within 5–7 working days
• Monthly publication with a short change log

When to fast‑track

Critical items – product names, legal phrases, safety messages and KPI labels – can bypass the monthly cycle. Run a same‑week path with the curator, domain owner, legal and lead linguists, then publish an interim update.

How to build your first termbase

Do not try to boil the ocean. Aim for a useful first release in four to six weeks, then iterate with regular, small updates so teams learn to trust the system. The sequence below keeps momentum without creating side quests.

Step 1 – audit what you already have

Collect existing glossaries, brand word lists, style guides, UI string exports, help‑centre articles and recent translations. Read across them to find collisions: product names that change between teams, features described three ways, or legal phrases that drift from document to document. This is your starter backlog.

Step 2 – extract candidate terms

Run a term extraction on high‑value sources such as product pages, user interfaces, contracts, technical docs and release notes. Automated extraction will surface volume; human judgement trims that list to the concepts that actually affect meaning, legal risk or user action. Keep the signal, drop the noise.

Step 3 – define and decide

For each candidate, write a one‑sentence definition people can understand without specialist knowledge. Choose a preferred term per language. Record common synonyms and mark any forbidden terms with the approved alternative so reviewers have something to point to. If a term should not be translated, set it as do not translate and explain how to handle inflection or plural in target languages.

Step 4 – translate and review

Translate entries into your priority languages with in‑market linguists. Ask reviewers to check clarity and fit for purpose, not just correctness. Lock high‑impact items first – product names, UI labels, legal phrases and KPI names – because these drive the most queries and the most rework if left vague.

Step 5 – publish and integrate

Make the termbase available where people work. Integrate it with your authoring tools and your translation environment so terms appear as suggestions and are checked automatically. Provide a fast, read‑only lookup for everyone else – support, sales, partners – and show a short change log when you release updates so people can see what moved.

Getting the tooling right

Pick tools that fit your reality – team size, security posture and existing systems. Cloud tools are quick to deploy and easy to share. On‑premise or private cloud makes sense when data sensitivity or network policy demands it.

Selection criteria that matter

• Role‑based access with audit trails and single sign‑on

   

• Connectors or APIs for your CMS, design tools and translation memory

   

• Automatic term highlighting and checks in CAT tools

   

• Workflows for propose, review, approve and deprecate

   

• Fast search, inline previews and friendly editing

Integrations you will actually use

Wire up the termbase to the places where words are written and translated. Suggestions should appear in your CMS or editor, and in your CAT tool. A separate portal that requires another login will be ignored.

Driving adoption across teams

Adoption is the hard part. People adopt tools that remove pain. Put the lookup one click away in your intranet or editor toolbar. Train writers and reviewers to resolve wording debates by checking the termbase first. Close the loop with contributors – when someone proposes a term, let them know when it is approved and show where it lives. That small feedback cycle builds trust.

Bake it into reviews

Add a short terminology pass to your editorial and localisation checklists so consistency is verified alongside grammar and numbers. When reviewers are measured on it, it happens.

Keeping it healthy

A termbase is a living system. Treat it like a product, not a one‑off project. Release in small, regular cycles so you do not build pressure for big, risky drops. Review high‑risk domains quarterly – legal, safety, finance – and archive deprecated entries rather than deleting them so you preserve history and avoid ghost terms returning via copy‑paste.

Usage analytics help you focus. Search queries with no results indicate gaps to fill. Entries that never surface in suggestions may be candidates for pruning. Spend an hour a month with your curator to look at this data and plan the next set of tweaks.

Handling tricky cases

Some terms resist one‑size‑fits‑all rules. Regional variants like colour and color or lift and elevator are best handled with per‑locale entries, not footnotes that nobody reads. Character limits in interfaces require tight, testable phrasing with fallbacks for narrow screens. Languages with agreement need explicit guidance on gender, case and plural so translators do not have to guess. Ambiguous words such as account should be reserved for a single concept – for example, the login – with a billing profile given a distinct name.

Measuring impact and ROI

Define what good looks like at the start. You are aiming for fewer debates, faster cycles and cleaner output. Track terminology queries from translators and reviewers; they should trend down as the database stabilises. Watch review time; it should fall as people stop word‑smithing and start checking the meaning. Translation‑memory leverage should improve because phrasing repeats. Most importantly, your product and UI language should read the same across platforms.

How major public institutions manage terminology

Public institutions that publish in many languages treat terminology as a core governance function. The European Union is a clear example. Twenty‑four official languages, hundreds of domains, and legislation that must mean exactly the same thing everywhere – the only way that works at scale is with disciplined, concept‑based terminology management.

The EU’s interinstitutional database, IATE, is used by translators, lawyer‑linguists and policy teams across the Commission, Parliament and Council. Entries are concept‑oriented, richly annotated and reviewed under defined workflows; the database is also publicly available so external stakeholders can align with institutional usage. You can explore it here: IATE – the EU’s terminology database.

What you can copy from the EU model

Adopt the principles, right‑size the tooling.

• Concept first – one entry per concept, with variants and forbidden terms recorded per language
• Ownership – domain leads and legal reviewers approve high‑risk items
• Metadata – definitions, contexts, sources, status and change history on every entry
• Integration – term checks in the tools where writing and translation happen
• Openness – a read‑only lookup for partners and vendors to reduce drift

Other bodies follow similar patterns. The United Nations maintains UNTERM, a multilingual database used across its agencies, and many national governments publish style and terminology guides for public‑facing content. The common lesson is simple: when meaning has consequences, terminology needs policy, process and tools.

Where to go from here

A clear, enforced terminology database pays for itself. It reduces friction, protects meaning and speeds up every content and localisation workflow you run. Start small, integrate where people work, and keep it alive with regular, low‑drama updates. If you are already running a glossary, migrate the top 150 concepts into a concept‑based termbase and retire the spreadsheet once your first release is live.

How AdHoc Translations can help

AdHoc Translations builds and maintains practical termbases that plug into your writing and translation stack. We combine native‑language specialists with a governance model that keeps decisions clear and lightweight, and we set up integrations so the database does real work in your tools rather than sitting on a shelf.

If you are ready to turn scattered glossaries into a working terminology database, get in touch for a short scoping call or a fast quote. We will map languages and domains, propose a field template, and deliver a first release you can grow without changing platform later