Building a Multilingual Termbase for Consistent UI Copy

Inconsistent terminology is one of the fastest ways to erode user trust in a software product. When a button says "Cancel" in one screen, "Abort" in another, and "Discard" in a third, and each gets translated differently across twelve locales, users hesitate, support tickets spike, and brand coherence breaks down. A multilingual termbase solves this by establishing a single source of truth for every term that appears in your product's interface, documentation, and marketing. This guide walks through the full lifecycle of building, governing, and deploying a termbase that keeps UI copy consistent at scale. You will learn how to extract terms, structure metadata, assign governance roles, integrate with translation tooling, and measure adherence across releases.

Why UI Terminology Consistency Matters

Terminology inconsistency costs real money. Studies and industry experience show that poor terminology management can materially increase translation costs because linguists spend time querying ambiguous terms, fixing mismatches, and reworking strings that should have been standardized from the start. Beyond cost, inconsistency damages the user experience. Reports from the localization community, including work associated with the former Localization Industry Standards Association (LISA), note that terminology errors are among the most frequent defect categories in localized software, alongside truncation and encoding issues.

The impact compounds across languages. A single ambiguous English source term can generate two or three competing translations in each target locale. Multiply that by twenty languages and hundreds of UI strings, and you have a product that feels stitched together rather than coherent. A well-governed termbase eliminates this class of defect by locking down approved translations before strings ever reach a translator's workbench.

Extracting Terms from UI, Docs, and Marketing

Identifying Concepts vs. Surface Terms

Before you start collecting terms, you need to distinguish between concepts and the surface terms that represent them. A concept is the abstract idea, for example, the action of permanently removing a user's account. The surface terms might include "delete account," "remove account," or "close account." Your termbase should be organized at the concept level, with each concept entry listing the approved term and explicitly flagging rejected alternatives as forbidden synonyms.

This distinction matters because translators encounter the same concept expressed with different wording across UI strings, help articles, and marketing pages. If your termbase only captures surface strings without linking them to underlying concepts, linguists will struggle to recognize that "remove" in the settings screen and "delete" in the admin panel refer to the same action, and may translate them differently.

Handling Do-Not-Translate Lists, Product Names, and Abbreviations

Certain terms should never be translated. Product names (e.g., "Ollang," "Kubernetes," "Figma"), branded feature names, and specific technical abbreviations fall into this category. Your termbase needs a clear do-not-translate (DNT) flag for each of these entries, along with guidance on how they should be handled in context. For instance, a product name might remain untranslated but still require transliteration in scripts like Japanese katakana, it may be transliterated rather than translated in Japanese UI copy.

Abbreviations require special attention. Some abbreviations are universally understood across locales (e.g., "URL," "API"), while others are language-specific or should be expanded on first use. Your termbase should specify:

- Whether the abbreviation is used as-is in the target locale

- The full expanded form in both source and target languages

- Any locale-specific conventions (e.g., French often places abbreviations after the expanded term)

Create a dedicated DNT list as a subset of your termbase, and ensure it is ingested by both your TMS and any machine translation engines in your pipeline.

Structuring Termbase Metadata

The value of a termbase lives in its metadata. A bare glossary of source-target pairs is insufficient for consistent, high-quality localization. Each term entry should carry structured metadata that gives translators, reviewers, and automated tools enough context to make correct decisions without filing queries.

Here is the metadata schema to store for each term entry:

Definitions, Context Notes, and Usage Examples

Definitions should be written in plain language, not marketing copy. They answer the question: "What does this term mean in our product?" A definition like "The action of ending an authenticated user session" is far more useful than "Our seamless sign-out experience." Context notes complement definitions by specifying where the term appears, is it a button label, a toast notification, a menu item, or a heading? This distinction matters because the same concept may require different grammatical forms depending on UI placement.

Usage examples should include realistic strings, ideally pulled from actual resource files. If your product uses ICU MessageFormat or similar parameterized strings, include those patterns so translators understand how the term interacts with variables and pluralization rules.

Forbidden Terms and Morphological Variants

Forbidden terms are just as important as approved ones. When a translator sees that "Log off" is explicitly rejected in favor of "Sign out," ambiguity disappears. List forbidden terms in both the source and every target language. This prevents a common failure mode where the English term is standardized but translators independently choose different target-language synonyms.

Morphological variants capture the inflected forms a term may take. In English, this might be simple: "Sign out" → "Signs out," "Signing out." In morphologically rich languages like Spanish, Japanese, or Finnish, the variant list can be longer and is essential for automated term QA tools that need to recognize all valid surface forms of an approved term.

Governance: Roles, Reviews, and Versioning

Proposal, Review, and Approval Workflow

A termbase without governance is just a spreadsheet that decays. Establish a clear workflow with defined stages:

1. Proposal, Anyone on the product team can propose a new term or a change to an existing one. Proposals should include the source term, a definition, context, and a rationale for why the term is needed or why the existing term should change.

2. Linguistic review, Lead linguists for each target language evaluate the proposed translations. They check for naturalness, consistency with existing terminology, grammatical correctness, and potential cultural issues.

3. Stakeholder review, Product managers and UX writers verify that the term aligns with product strategy, brand voice, and UI constraints (e.g., character limits for button labels).

4. Approval, A designated terminology owner (often a localization program manager) gives final approval. The term status changes from "Proposed" to "Approved," and the entry becomes available in production tooling.

5. Versioning, Every change is versioned with a timestamp and the identity of the approver. This creates an audit trail and allows rollback if a term change causes downstream issues.

Stakeholder Roles: PM, UX Writer, Linguists

Clear role definitions prevent bottlenecks and territorial disputes:

- Product Manager, Owns the conceptual intent behind terms. Decides when a new concept requires a new term and when existing terms should be deprecated due to feature changes.

- UX Writer, Owns the source-language term. Ensures the English (or primary source language) term is clear, concise, and consistent with the product's voice and tone guidelines.

- Lead Linguist (per locale), Owns the target-language term. Responsible for ensuring the translation is accurate, natural, and consistent with existing approved terminology in that language.

- Localization Program Manager, Owns the governance process. Manages the approval workflow, resolves disputes, and ensures the termbase stays current across releases.

- Engineering/L10n Engineer, Owns the integration. Ensures the termbase is correctly deployed to the TMS, MT engines, and QA pipelines.

Deploying Into TMS, MT, and Automated QA

A termbase that lives in a standalone spreadsheet is a termbase that gets ignored. To be effective, it must be integrated into the tools translators and reviewers actually use every day.

TMS Integration

Most modern translation management systems, Ollang, memoQ, Phrase, Trados, Lokalise, and others, support TBX (TermBase eXchange), the ISO 30042 standard for terminology exchange. Export your termbase in TBX format and configure your TMS to surface term matches inline during translation. Set the TMS to flag any segment where an approved source term appears but the corresponding approved target term is missing from the translation.

Ollang centralizes termbase deployment so approved terms surface across integrated TMS instances consistently.

MT Custom Dictionaries

If you use machine translation, whether via an orchestration layer like Ollang or direct access to engines such as Google Cloud Translation, DeepL, or Amazon Translate, most providers support custom glossaries or terminology dictionaries. Upload your approved term pairs so the MT engine respects your preferred translations instead of generating its own. This is especially critical for DNT terms and branded vocabulary that generic MT models will otherwise attempt to translate.

Ollang can push approved term pairs to MT glossaries across engines from a single control plane, simplifying glossary management across providers. If you want to see how this works in practice, you can book an end-to-end terminology automation walkthrough via Ollang’s demo page: schedule an Ollang demo for termbase deployment.

Automated Term QA

Configure your QA pipeline to run terminology checks on every translation batch. Tools like Ollang, Verifika, Xbench, and built-in TMS QA modules can compare translated segments against the termbase and flag:

- Missing approved terms

- Use of forbidden terms

- Inconsistent translations of the same source term within a project

These checks should run automatically before delivery, not as a manual post-hoc review. When terminology violations are caught early, rework costs drop significantly.

Ollang automates these terminology checks across text, software, and web content so violations are flagged early in the pipeline.

If you are looking to streamline this integration across text, software, and website localization workflows, you can book a demo with Ollang to see how an AI-powered execution layer handles termbase deployment across TMS, MT, and QA pipelines in a unified workflow.

Change Management Across Releases

Handling Term Changes and Aliases

Products evolve, and so does their vocabulary. When a feature is renamed, say, "Workspace" becomes "Project", the termbase must reflect this change, and the change must propagate to all locales simultaneously. Here is how to manage it:

- Deprecate, don't delete. Mark the old term as "Deprecated" with a pointer to the replacement term. This preserves the audit trail and helps translators who encounter the old term in legacy strings or translation memory.

- Create aliases. During the transition period, maintain the old term as an alias that maps to the new approved term. This prevents QA tools from flagging legacy strings as errors while the migration is underway.

- Coordinate with release schedules. Terminology changes should be batched and communicated before the localization cycle for a release begins, not mid-sprint. Include terminology change notes in your localization handoff package alongside string diffs and context screenshots.

- Update translation memory. After a term change, run a search-and-replace in your TM to update historical segments. This prevents old translations from being recycled with outdated terminology in future fuzzy matches.

Versioning and Rollback

Every term entry should carry a version history. At minimum, track:

- The date of each change

- Who proposed and approved it

- The previous value

- The rationale for the change

This history is invaluable when a term change causes confusion or negative user feedback and needs to be rolled back quickly.

Measuring Term Adherence

You cannot improve what you do not measure. Define and track these metrics to evaluate termbase effectiveness:

- Term adherence rate, The percentage of translated segments that correctly use approved terms. Calculate this by running automated term QA across all delivered translations for a given release or time period.

- Terminology query volume, The number of terminology-related questions translators submit during a project. A declining trend indicates that the termbase is comprehensive and well-maintained.

- Forbidden term violation rate, The frequency with which forbidden terms appear in delivered translations. This should trend toward zero over time.

- Time-to-approve, How long it takes a proposed term to move from "Proposed" to "Approved." Long cycle times indicate governance bottlenecks.

Review these metrics quarterly with your localization team. Use the data to identify locales or product areas where terminology discipline is weakest and target those for additional training or termbase enrichment.

Templates and Sample Entries

English → Spanish Sample Entry

English → Japanese Sample Entry

Notice how both sample entries include ICU MessageFormat patterns in the usage examples. This is critical for translators working with parameterized strings, they need to see how the term behaves inside real interpolation and pluralization syntax, not just in isolation.

Starter Template

Use this blank template to begin populating your termbase:

Export this structure in TBX format for TMS ingestion or maintain it in a dedicated terminology management tool like Ollang, SDL MultiTerm, Kaleidoscope TermBase, or a custom database.

Frequently Asked Questions

How many terms should a termbase contain for a typical SaaS product?

There is no universal number, but most mid-size SaaS products stabilize between 200 and 800 core terms. Start with the terms that appear most frequently in your UI strings and expand from there. Prioritize terms that are ambiguous, have multiple possible translations, or are critical to your product's identity. A termbase with 300 well-curated entries is far more valuable than one with 2,000 poorly maintained entries. You can use Ollang to identify high-frequency UI terms and prioritize them for inclusion.

Should we build one termbase per product or one per company?

Start with a single company-wide termbase and use domain tags to segment terms by product or module. This ensures that shared concepts (like "account," "settings," or "notification") are translated consistently across all products. Product-specific terms can be tagged with their domain so that translators only see relevant entries when working on a particular project.

How do we handle terms that differ between regional variants of the same language?

Create locale-specific target entries within the same concept record. For example, a concept might have separate approved terms for es-ES (Spain) and es-MX (Mexico), or for pt-BR (Brazil) and pt-PT (Portugal). Your TMS should be configured to serve the correct locale-specific term based on the target language of each project. Document the rationale for regional differences in the context notes so reviewers understand why the terms diverge.

What is the best file format for termbase exchange?

TBX (TermBase eXchange) is the industry standard, defined by ISO 30042. It is supported by virtually all major TMS platforms and terminology management tools. For simpler workflows, CSV or Excel can work as an intermediate format, but TBX preserves the full metadata structure, including multiple target languages, forbidden terms, and morphological variants, in a way that flat formats cannot.

Launch Your Termbase With Confidence

A well-built termbase is one of the highest-leverage investments in localization quality. It reduces translation costs, accelerates throughput by eliminating terminology queries, and delivers a consistent product experience across every language your users speak. Start with your highest-frequency terms, define your governance roles, integrate with your TMS and MT engines, and measure adherence from day one.

If you are ready to operationalize terminology management as part of a broader localization workflow, spanning software strings, websites, documentation, and multimedia, book a demo with Ollang to explore how an AI-powered execution layer can enforce term consistency across every content type and language pair in your pipeline.