You’re three hours into post-editing a 40-page medical manual. The MT engine translates “patient consent form” as “formulario de consentimiento del paciente” on line 12, then “formulario de consentimiento de paciente” on line 47, then “forma de consentimiento de la paciente” on line 89. Same document. Same term. Three different translations.
Your glossary says it should be one specific term, every time. Your post-editing guidelines say “enforce glossary terminology.” But the base MT output is already sloppy with prepositions and gendered articles, so you can’t just let it slide—you have to re-read every sentence to catch these tiny inconsistencies. What was supposed to be a 3-hour job becomes 5 hours, all because machine translation didn’t “understand” your glossary.
This isn’t a skill problem. This isn’t lazy engineering. This is how neural machine translation (NMT) actually works: it predicts translations word-by-word based on context, without remembering what it chose five sentences ago. Your glossary is just a text file. The MT engine doesn’t learn from it; it overrides tokens at output, which often breaks the grammar around them. And for many translators, that’s a deal-breaker.
Why Machine Translation Can’t Respect Your Glossary (And Why It’s Getting Worse)¶
To understand why MT breaks glossaries, you need to understand how neural machine translation actually translates.
A traditional statistical MT engine (the old stuff, pre-2015) would look up your glossary first. If it found a match, it used it. No questions asked. Simple, predictable, and boring—but consistent.
Neural MT changed everything. Instead of rule-based lookups, NMT models work like this:
- Read the source sentence. The model ingests the whole thing—context, surrounding words, punctuation.
- Predict tokens one-by-one. Based on what it reads and what it’s already output so far, it guesses the next target word. Then the next. Then the next.
- Repeat for each sentence. The model has no memory of what it did three sentences ago. Every new sentence is a fresh prediction.
Your glossary is invisible to this process. The engine was trained on billions of words, and it learned statistics: “when I see [source term] in [context], [target translation] is likely.” The glossary override comes after the main translation pass, so it’s like saying “I don’t care what you learned—use this instead.” The engine wasn’t built to integrate glossary constraints gracefully; it just swaps tokens at the end.
Here’s what actually happens when you add a glossary to an NMT engine:
- Token replacement: Engine generates “consentimiento de paciente.” Glossary says “use consentimiento del paciente.” Engine swaps it. But the surrounding sentence was predicted assuming the original order, so now you get “formulario de consentimiento del paciente fue…” (grammatically awkward in Spanish).
- Context blindness: The glossary has no way to say “use this translation only if the patient is singular, female, and the context is surgical.” It applies blindly.
- Quality trade-off: Research from Phrase, AppTek, and TranslateFX shows that applying glossary constraints reduces overall translation quality (BLEU scores) by 5-15%, because the engine has to work around the forced term instead of generating naturally.
So glossaries in commercial MT engines (Google Cloud Translation, Azure, Bing) do work—they enforce the term. But they often leave the surrounding syntax broken or awkward, forcing post-editors to fix the grammar around the glossary term, defeating the whole purpose of having a glossary in the first place.
The Real Cost of Inconsistent Terminology (It’s Not Just Annoying)¶
Yes, it’s frustrating to see the same term translated three different ways. But the cost goes deeper.
Post-editing time. Terminology inconsistency is the #1 reason post-editors report that MTPE takes longer than they expected. When output is inconsistent, your brain can’t rely on patterns; you have to re-verify every occurrence. Studies show that post-editors spend 30-50% of their time on terminology fixes alone when glossaries aren’t enforced upstream. That’s money.
Quality complaints. Clients catch inconsistency fast. They read the translated document and think “didn’t the translator know this should be the same word every time?” Whether or not they admit it, they dock points for professionalism. For regulated industries (medical, legal, finance), inconsistent terminology can create compliance issues—regulatory bodies expect consistent use of defined terms.
Liability and rework. In sectors like pharmaceuticals, contracts, or medical devices, terminology inconsistency can make the document unacceptable for submission to authorities. You discover this in review, not at handoff. Rework costs 2-3x the original editing fee.
Translator burnout. Post-editors who spend half their time fixing “should-be-automatic” fixes get frustrated fast. The work feels repetitive and unrewarding. High-volume MTPE shops report 40% turnover in post-editors specifically because of poor glossary enforcement upstream.
Loss of competitive edge. Agencies that deliver consistent, glossary-enforced translations win contracts against those that don’t. Clients now expect MTPE to produce output as consistent as a human translator, and if your glossary isn’t working, you’re delivering less.
Solution 1: Build a Glossary That Actually Works¶
The problem isn’t glossaries—it’s bad glossaries.
Most glossaries fail because they’re too big, too generic, or too rigid. You’ll see 1000-entry glossaries mixing “the” (definitely skip this) with highly specialized terms. You’ll see glossaries with no context: “bank” → “banco” (singular? which kind of bank?). You’ll see glossaries built by one person who doesn’t post-edit, so they include terms that don’t fit the target language’s grammar.
A working glossary looks different:
1. Focus ruthlessly. Include only terms that: - Appear in 80%+ of source documents, OR - Are client-mandated or brand-critical, OR - Are domain-specific and not intuitive (e.g., “data controller” in GDPR context—not “data manager”).
Aim for 100-200 terms for most projects, not 1000. Every term you add costs post-editors cognitive load when that term shows up. A smaller, tighter glossary is faster to verify.
2. Add context and grammar info. For each entry: - Source term and preferred target translation - Part of speech (noun, verb, adjective) - Usage context (“only in patient-facing documents” or “legal contracts only”) - Forbidden alternatives (“do NOT use [this synonym]”) - Morphological variants if needed (“Data Protection Officer → Datenschutzbeauftragte fem. / Datenschutzbeauftragter masc.”)
A glossary with notes is self-documenting. Post-editors understand why a term is mandatory, not just that it is.
3. Avoid one-to-one translations that don’t work in the target language. If English “the” has no equivalent in your target language, don’t try to force it. If a source term needs to be restructured to sound natural in the target, document that restructuring in the glossary, not as a simple term substitution.
4. Store it in a termbase, not a spreadsheet. CAT tools (Trados, memoQ, Smartcat, SDL) have termbase modules that store metadata and integrate into the editing workflow. When a post-editor is working on a sentence containing a glossary term, the term appears as a suggestion or warning in real-time. Spreadsheets require manual lookup, which post-editors often skip under time pressure.
5. Version and maintain it. Glossaries are living documents. If post-editors find a glossary term that doesn’t fit, flag it for review. If client feedback changes what a term should be, update it and communicate the change. Track versions so you know which version was used for which batch.
Solution 2: Constrain the MT Engine (Carefully)¶
Once you have a solid glossary, you need to tell the MT engine to use it. There are three main approaches, with different trade-offs.
Glossary override at output (simple, but risky):
This is what Google Translate, Bing Translator, and Azure Translation do by default. You attach the glossary, the engine runs as normal, then swaps tokens for glossary matches in the output.
Pros: Easy, no retraining, works with any cloud MT engine. Cons: Breaks surrounding grammar, reduces overall quality by 5-15%, doesn’t handle context or morphology.
Use this only if your glossary is very small (30-50 terms) and consists of proper nouns or brand names that don’t affect syntax (e.g., company names, product names).
Markup-based constraints (better, requires preprocessing):
You wrap glossary terms in markup before sending to MT, e.g.:
<term target="consentimiento del paciente">patient consent form</term>
Some MT engines (AppTek, certain Trados configurations) recognize this markup and treat the glossary term as “locked”—the engine won’t touch it, and the sentence is predicted around it. This preserves syntax better than blind token replacement.
Pros: Better grammar preservation, context-aware (you can add different markups for different contexts). Cons: Requires preprocessing of source text, only works with engines that support it, still adds overhead.
Use this for technical and medical documents where consistency is critical but you’re okay with slightly higher processing cost.
Domain-specific training (best, but expensive):
If you have 10,000+ aligned sentence pairs in your specialized domain, you can fine-tune an open-source NMT model (Opus MT, Hugging Face transformers) or hire a service provider (Translated, Lionbridge, AppTek) to create a custom engine. The glossary terms are embedded in the model’s weights—no override needed.
Pros: The engine naturally learns to use your terminology, no quality loss, handles context and morphology automatically. Cons: High upfront cost (€5,000-25,000), requires 3-6 weeks, only viable for high-volume, ongoing projects (200k+ words/year).
Use this if you have a stable, large volume of specialized content (technical documentation, pharmaceutical, legal) and can amortize the cost over 12+ months of translations.
Solution 3: Validate Glossary Adherence with QA Automation¶
Here’s the hard truth: even with a great glossary and a constrained MT engine, post-editors will sometimes skip glossary terms if they’re under time pressure or the glossary term “feels wrong” in context. This is where QA automation comes in.
Before post-editors even open a document, run an automated QA check that flags: - Terms in the glossary that don’t appear in the output (missed glossary terms) - Terms in the output that should be in the glossary but aren’t (consistency violations) - Glossary terms used in grammatically awkward ways (suggesting a glossary-override artifact)
Most CAT tools have this built-in (Trados’ QA, memoQ’s QA checks, Smartcat’s validation). Set it to “hard stop”—don’t let a translator move on to the next segment until glossary violations are resolved.
The data from QA checks also tells you which glossary terms are causing problems (maybe the term really doesn’t fit the target language, or maybe it needs clarification). Use this feedback to iterate on the glossary.
Research from Phrase and Translated shows that QA-validated glossary enforcement catches 95%+ of terminology errors before a human ever reviews them, cutting final QA time by 40%.
Solution 4: Use Platform-Level Glossary Integration¶
For agencies or high-volume teams, manual glossary management becomes a bottleneck. Modern translation platforms (Phrase, Smartcat, ChatsControl, Crowdin) now offer integrated glossary management that combines all the above approaches.
These platforms typically offer: - Termbase with approval workflows. Terms can be proposed, discussed, approved, and version-controlled within the platform. - Context injection before MT. The platform feeds relevant glossary entries to the MT engine along with domain/tone context, so the engine has more information upfront. - Real-time editor integration. Post-editors see glossary matches and QA flags inline as they work. - Automated pre-validation. Before post-editing starts, QA runs automatically and surfaces glossary violations and inconsistencies. - Adherence reporting. Dashboards show which glossary terms were applied, which were overridden, and which caused issues.
For example, ChatsControl includes terminology enforcement as part of its translation brief system: before translating a document, you specify domain (medical, legal, technical), tone, and a glossary. The platform’s AI translator uses this context to build a plan (including glossary mapping), translates against that plan, then a QA pass re-checks glossary adherence and flags inconsistencies. For high-volume MTPE teams, this reduces post-editing time by 30-40% on terminology work alone. The platform also flags terms that the glossary says should be used but aren’t, making it easy for post-editors to spot misses.
The catch: platforms add a dependency (you’re not translating locally with your own tools anymore). But for teams doing 200k+ words/month, the glossary management benefits often outweigh the tool lock-in.
Best Practices Checklist: Glossary Enforcement Workflow¶
Here’s a concrete workflow that works:
Pre-translation: - [ ] Extract glossary from project context (client docs, previous translations, domain research) - [ ] Build a termbase with 100-250 critical terms (not 1000) - [ ] Add context, morphology, and usage notes to each term - [ ] Have at least one bilingual reviewer approve the glossary before use - [ ] Store glossary in a termbase system (CAT tool or platform), not a spreadsheet
At translation: - [ ] Feed glossary + domain context to the MT engine (via markup, parameter, or platform) - [ ] Choose constraint method based on glossary size and content (override for names/brands; markup for technical terms; custom training for large volumes) - [ ] Log which glossary version was used for each batch (for traceability)
Pre-post-editing: - [ ] Run QA validation flagging glossary violations - [ ] Review QA report for high-violation terms (these need glossary refinement) - [ ] Communicate to post-editors: “These terms are glossary-enforced; you may override only with lead approval and documented reason”
During post-editing: - [ ] Post-editors work with QA flags visible; glossary terms appear as inline suggestions - [ ] Override glossary terms only when absolutely necessary, with notes (these notes feed back into glossary refinement)
Post-post-editing: - [ ] Run final QA to check glossary adherence in completed work - [ ] Extract overridden or problematic terms for glossary review next project - [ ] Document lessons learned (“this term needs morphology variants”, “this term should be forbidden synonym”, etc.)
FAQ¶
Why does Google Translate’s glossary feature not actually work?
Glossary features in free MT engines compare the glossary to source text, then override terms at output—but this override often degrades the surrounding sentence structure and grammar. Additionally, they don’t account for context (e.g., “bank” as a financial institution vs. riverbank), so they force wrong translations. Paid tools like Google Cloud Translation and Phrase.com offer better filtering, but even then, applying glossary constraints reduces overall BLEU scores by 5-10%.
Should I use a glossary with neural MT if it reduces quality?
Yes, but not alone. A focused glossary (100-300 critical terms only) combined with domain-specific training data and QA validation outperforms either glossary or training alone. The key is starting post-editing with consistent base output rather than fixing terminology from scratch. Even a 5-10% quality reduction is offset by 40-50% faster post-editing on terminology fixes.
What’s the difference between a glossary and a termbase?
A glossary is a simple list of source → target pairs. A termbase (used in CAT tools like Trados, memoQ, Smartcat) stores metadata: part-of-speech, usage notes, forbidden synonyms, context rules, and approval status. Termbases integrate directly into the editing interface—editors see suggestions and warnings in real-time. This makes terminology enforcement semi-automatic during post-editing.
How do I prevent “terminology drift” in long projects?
Terminology drift (where translators gradually deviate from the glossary under time pressure) happens in 80% of large MTPE projects. Solutions: (1) feed the glossary to the MT engine before each batch, (2) run an automated QA check flagging glossary violations before post-editing starts, (3) set a hard rule that glossary terms are non-negotiable (document “why this term” in the glossary notes), (4) spot-check 5-10% of completed work for drift, then retrain the engine.
Can machine translation engines be “taught” to respect my glossary without adding it each time?
Yes, through domain-specific fine-tuning or training. If you have 10,000+ sentence pairs with consistent terminology, you can fine-tune an open-source model (like Opus MT) or use a service provider (Translated, AppTek, Lionbridge) to create a custom engine. This embeds your terminology into the model itself—no glossary override needed at inference. However, this costs €5,000-20,000 upfront, so it’s only viable for large volumes (100k+ words/month).
How do I know if my post-editors are actually using the glossary?
Enable QA validation in your CAT tool (most have it built-in) to flag glossary violations automatically. Review QA reports weekly; if violations spike, it means post-editors are either overwhelmed or the glossary isn’t clear. Also, track “terminology consistency” as a separate metric—aim for 95%+ glossary adherence on critical terms. Some platforms (ChatsControl, Smartcat, Phrase) show real-time adherence dashboards.
What happens if a glossary term doesn’t fit the target language grammar or idiom?
This is the most common reason post-editors skip the glossary. The solution: add morphological variants and context notes to the glossary entry. For example, if “Data Protection Officer” is mandatory but won’t work in German’s gender system, add a note: “Use ‘Datenschutzbeauftragte’ (fem.) or ‘Datenschutzbeauftragter’ (masc.) depending on context.” If the glossary is written collaboratively by translators + clients, these exceptions get resolved upfront, not during post-editing.