How many terms should be in a product termbase?

Start with the terms that actually cause problems: feature names, UI navigation labels, core technical concepts, and any terms that have appeared inconsistently in support tickets. For most SaaS products, this is 100–300 terms in the initial build. Don't try to include every word — the value of a termbase is in constraining the high-frequency, high-impact terms where inconsistency is most damaging. Add more over time as you discover gaps.

What do I do about existing terminology inconsistency in production?

Audit first, update strategically. Identify the terms that are inconsistent across your product, help center, and support — prioritize by frequency of appearance and severity of confusion they cause. Build the termbase from this audit. Then update in priority order: fix the product UI first (it's what users learn from), then the help center, then older content. Don't try to update everything simultaneously — it creates a period where old and new terminology coexist, which is the problem you're trying to solve.

Should I keep English product terms in all languages or always translate?

It depends on the market and the term. Some markets (especially Japan) strongly prefer localized terminology; others (German tech users, many B2B markets) are comfortable with English technical terms. The decision should be made per-language and per-term category, with input from local market teams. Document the decision in your termbase as the approved choice for that language, and apply it consistently. The consistency of application matters more than the specific choice.

Global

The Terminology Silo Problem in Multi-Market SaaS — Why Your Users in Different Countries Are Learning Different Products

When your SaaS product uses different translated terms for the same feature across markets, users can't share knowledge, support costs multiply, and churn accelerates. Here's the structural fix.

TL;DR — Key Takeaways

1.When the same SaaS feature has different names in different language versions, users in each market learn different vocabulary — and can't share knowledge, documentation, or peer support across markets.
2.Terminology drift happens when translation is done in silos: different teams, different vendors, different projects, with no shared source of truth for product terminology.
3.The support cost of terminology inconsistency is measurable: duplicate tickets, longer resolution times, community posts that don't find existing answers because search terms don't match.
4.A centralized product termbase — maintained before translation starts — prevents the problem. Fixing it retroactively requires auditing existing translations and a coordinated update across all markets.

What Terminology Inconsistency Actually Looks Like in Production

A SaaS company that has grown internationally often discovers the problem not through a planned audit but through a support ticket. A user in Germany refers to a feature by a name that doesn't appear in any documentation, because the German version of the product uses a different translation than the German help center, which uses a different translation than the German sales materials. None of the three teams that translated each material had visibility into the others' choices.

The downstream effects are systematic. Users who search for help using the in-product terminology find nothing, because documentation was translated by a different vendor with different terminology. They open a support ticket. The support team answers using yet another terminology set from their training materials. The conversation takes twice as long because both parties are describing the same thing with different words.

At the community level, the effect is knowledge fragmentation. User communities for SaaS products are valuable because experienced users answer questions for newer users. But if the German community uses different feature terminology than the French community, the knowledge doesn't transfer. Each language market reinvents product understanding from scratch.

Why Terminology Drift Is the Default, Not the Exception

Terminology drift happens because translation is typically purchased in projects, not maintained as infrastructure. A company localizes its product, then localizes its help center with a different vendor, then has its sales team localize their pitch decks internally, then launches a community translated by yet another team. Each project starts from the English source without reference to what terminology decisions were made in previous projects.

The problem compounds over product updates. When a new feature launches, the engineering team writes strings in English, they get translated — often by whoever is available — and the new terminology may or may not align with existing translated terms for related features. Over time, the product terminology in each language becomes a palimpsest of decisions made by different people with no continuity.

Most companies discover the scale of the problem only when they try to consolidate: when they audit their translation memory, they find multiple translations of the same source string, none of which matches the terminology in the current product interface. The cost of retroactive harmonization is substantially higher than the cost of prevention.

The Termbase Solution — How to Build a Single Source of Truth

A product termbase is a managed list of source terms (in English) with approved translations in each target language, mandatory usage notes, and context for when each term applies. It's not a glossary in a document — it's a constraint enforced in every translation workflow. When a translator encounters a term in the termbase, they use the approved translation; deviations are flagged for review.

Building the initial termbase requires a terminology audit: identify all the product terms that appear across your UI, help center, and marketing — features, UI labels, technical concepts — and consolidate the existing translations, resolving conflicts with input from local market teams. For a typical SaaS product, this is 200–500 terms. The audit is time-consuming once; the maintenance is continuous but manageable.

Tools like leapCAT enforce termbases at translation time and flag violations automatically. This means that when a new feature launches and its strings go through translation, any deviation from approved terminology is caught in the QA step rather than reaching production. The cost of enforcement is dramatically lower than the cost of correction.

What Consistent Terminology Does for Your Business

The most direct benefit is support cost reduction. When terminology is consistent across product, help center, and support, users find answers before opening tickets. When support agents and users use the same vocabulary, ticket resolution is faster. For SaaS companies where support cost is a meaningful percentage of gross margin, this is a hard dollar improvement.

The second benefit is onboarding effectiveness. New users learn a product's terminology from the UI and onboarding flows. When those terms match the terminology in the help documentation and community answers, the learning curve is shorter. Onboarding completion rates and time-to-value both improve when the language is consistent.

The larger effect is on expansion revenue. CSA Research finds that 66% of B2B buyers prefer to buy in their native language. Buyers who evaluate SaaS products in their language and find consistent, professional localization are more likely to sign; customers who experience consistent localization throughout their contract are more likely to expand. Inconsistency signals that the vendor's commitment to the market is partial.

Frequently Asked Questions

Get expert-level translation without the expert cost

43 AI agents run the full professional translation workflow — analysis, terminology, translation, review, QA — starting at $0.01/word.

Try it free