Table of Contents
Every engineering team managing a multi-language product eventually writes a translation style guide. It's usually 10 pages, covers tone, punctuation, and capitalization rules, and gets ignored by 80% of translators within three months.
Glossaries work differently. A glossary is a finite list of domain-specific terms with exact translations and context notes. Ours has 40 entries. It produces more consistent translations than any style guide we've tried—and it's enforceable by tooling in a way that prose guidelines never are.
This post covers why glossaries outperform style guides, what to put in yours, how to structure it, and how to enforce it with AI translation checking.
Why Glossaries Beat Style Guides
Style guides operate at the level of rules: "Use formal register in German." "Don't use contractions in French UI copy." These rules require judgment to apply, and judgment varies between translators, agencies, and time zones.
Glossaries operate at the level of facts: "The English term 'workspace' translates to 'Arbeitsbereich' in German and 'espace de travail' in French. Never use 'Arbeitsfläche' or 'espace de travaille'." No judgment required. The term is either correct or it isn't.
This is measurable. When we audited a client's German localization before and after implementing a glossary, we found:
- Brand term inconsistency: dropped from 23 unique variations of their product name across the app to 1
- Translator onboarding time: reduced from ~4 hours of style guide reading to ~30 minutes of glossary review
- Translation review cycles: average 2.1 rounds before glossary, 1.3 rounds after
The reason isn't that translators ignored style guides out of negligence. It's that style guides require working memory to apply consistently. A glossary is a lookup table. Lookup tables are easy to check.
What to Include in Your Glossary
Resist the urge to include everything. A 200-term glossary with obvious entries ("user" → "Nutzer") is just a bad dictionary. The goal is to capture terms where:
- There's ambiguity in the target language — multiple valid translations exist, and you need to pick one
- The term is domain-specific — industry jargon that generic translation tools get wrong
- The term has brand significance — product names, feature names, pricing tier names
- The term appears frequently — inconsistency compounds with frequency
For a typical SaaS product, 40 core terms hits the sweet spot. Fewer, and you're missing real inconsistencies. More, and translators stop treating it as authoritative.
Categories to cover:
- Product and feature names — Don't translate these unless you have to. If you do, establish the translation explicitly.
- UI primitives — "Settings," "Dashboard," "Workspace," "Account," "Profile." These have multiple valid translations in most languages.
- Action verbs — "Invite," "Remove," "Archive," "Delete," "Publish." Verb choice shapes the feel of the product.
- Technical concepts — "API key," "Webhook," "Integration," "Sync." Some of these don't translate; establish the convention explicitly.
- Business terms — "Plan," "Subscription," "Trial," "Billing cycle." Pricing copy needs exact consistency.
- Error states — "Something went wrong," "Try again," "Contact support." Tone in error messages matters.
Glossary Structure: What Each Entry Needs
A glossary entry that just lists term → translation is half a glossary. The context note is what makes it usable.
Each entry should include:
| Field | Purpose |
|---|---|
| Source term | The canonical English term |
| Part of speech | Noun, verb, adjective — affects inflection rules |
| Target translations | One per locale, marked as required or preferred |
| Do not use | Common wrong translations to explicitly prohibit |
| Context note | Where it appears, how it's used |
| Example | A sentence showing it in context |
The "do not use" field is underrated. Knowing that "Arbeitsbereich" is correct is useful. Knowing that "Arbeitsfläche" is incorrect—and why—is actionable during review.
Sample Glossary: SaaS Product (10-15 Terms)
| English Term | German (DE) | French (FR) | Context Notes |
|---|---|---|---|
| Workspace | Arbeitsbereich | Espace de travail | Top-level container for a team's projects. Not "Arbeitsfläche" (too literal, implies physical space). |
| Dashboard | Dashboard | Tableau de bord | Retain "Dashboard" in DE (widely understood). "Tableau de bord" for FR formal copy; "Dashboard" acceptable in FR product UI. |
| Invite (verb) | Einladen | Inviter | Used for inviting team members. Not "hinzufügen" (add) — implies a request, not an action. |
| Archive (verb) | Archivieren | Archiver | Reversible action. Distinct from "Delete." Never use "Löschen"/"Supprimer" for archive flows. |
| Settings | Einstellungen | Paramètres | Account-level configuration. Not "Konfiguration" (too technical) or "Optionen" (too vague). |
| Plan (pricing) | Tarif | Forfait | Pricing tier. "Plan" (EN loanword) acceptable in DE informal UI copy; "Tarif" preferred in formal/billing contexts. FR: always "Forfait," never "Plan." |
| API key | API-Schlüssel | Clé API | Do not translate "API." "Schlüssel"/"Clé" required — not "Token" (different concept). |
| Sync (noun/verb) | Synchronisierung / synchronisieren | Synchronisation / synchroniser | Both noun and verb forms needed. Do not abbreviate. |
| Trial | Testzeitraum | Période d'essai | Free trial period. DE: not "Probe" or "Testphase" (both acceptable in other contexts but inconsistent). |
| Billing | Abrechnung | Facturation | Section label and feature name. Not "Zahlung" (payment, different concept). |
| Remove | Entfernen | Supprimer | Removing a user from a workspace. Distinct from "Delete" (permanent). |
| Delete | Löschen | Supprimer | Permanent deletion. FR "Supprimer" covers both remove and delete — add context in FR UI to distinguish. |
| Webhook | Webhook | Webhook | Do not translate. Always rendered in code formatting in docs. |
| Notification | Benachrichtigung | Notification | FR retains English form. DE: not "Mitteilung" (implies written message, not system notification). |
| Export | Exportieren | Exporter | Action verb. Do not use "Herunterladen"/"Télécharger" (download — different action). |
Enforcing the Glossary with AI Checking
A glossary is only as good as its enforcement. Human review catches some violations; systematic AI checking catches the rest.
The enforcement workflow we use:
- Pre-translation: Inject the glossary into the AI translation prompt as a constraint. "Translate the following string. You MUST use these exact translations for the listed terms: [glossary subset]."
- Post-translation check: Run a separate AI pass that reads the glossary and flags any string where a source term appears but the required target translation does not.
- Review queue: Flagged strings go to a human reviewer, not back to the AI. The AI is good at detecting violations; humans are better at adjudicating edge cases.
The second pass is the key piece that most teams skip. Even with glossary-constrained prompts, AI translators occasionally choose synonyms—especially for verbs that have multiple valid conjugations. The post-translation check creates an audit trail and catches the cases the prompt constraints miss.
For teams working at scale, this enforcement needs to be part of the translation platform, not a custom script. Better i18n's glossary feature runs both the constraint injection and the post-translation audit pass automatically, with violations surfaced in the review queue rather than requiring a separate tooling layer.
Maintaining the Glossary Over Time
A glossary that doesn't get updated becomes a liability. Terms get renamed, features get removed, new markets require new entries.
Three maintenance practices that work:
1. Gate new feature naming on glossary updates. When a new feature ships, the glossary entry for it (in all supported locales) is part of the definition of done—same as documentation. If you can't name it consistently in your target languages before launch, you're going to spend cycles fixing inconsistencies after.
2. Quarterly audit against your most-translated strings. Export the 100 most frequently translated strings in your product. Check each for glossary term coverage. If a term appears frequently but isn't in the glossary, add it.
3. Flag translator-suggested alternatives. When translators consistently choose a different term than the glossary specifies, treat that as a signal to revisit the entry—not as a compliance failure. Translators often know the market better than the team writing the glossary.
Starting from Scratch: A 30-Minute Bootstrap
If you're starting from zero, this is the fastest path to a working glossary:
- Export your UI strings from your codebase or translation platform.
- Filter for the 50 most frequently appearing non-trivial terms (skip articles, conjunctions, common verbs).
- For each term, ask: "Are there multiple valid translations in German/French/Spanish?" If yes, it's a glossary candidate.
- Draft the glossary using the structure above. Aim for 30-50 entries.
- Review with one native speaker per locale. A 30-minute call per language is enough for the initial pass.
- Load it into your translation platform as an enforced glossary. If your platform supports it, mark high-priority terms as "required"—violations block the string from being marked as complete.
The entire process takes a day for a focused team. The consistency payoff starts showing up in the first translation batch.
The 40-Term Rule
We've run this experiment with enough teams to have a rough heuristic: 40 domain-specific terms in a glossary produces more consistent translations than a 10-page style guide, across every product vertical we've tested.
The reason is operational. Style guides require training and ongoing reinforcement. Glossaries require a lookup. At 40 terms, the glossary is comprehensive enough to cover the domain without being so large that translators stop trusting it to be curated.
If you're currently working from a style guide and your translations are still inconsistent, don't make the style guide longer. Build a 40-term glossary and enforce it automatically.
Next Steps
The glossary structure described here works with any translation workflow. If you want automated enforcement—constraint injection, post-translation auditing, and violation review queues—Better i18n's glossary feature handles the full pipeline. You maintain the glossary, the platform handles enforcement across every translation, every locale, every time.
