Terminology, Glossaries, and Control in Translation APIs

When your product renders "account" as "cuenta" in one screen and "perfil" in another, you don't have a translation problem, you have a terminology control problem. Inconsistent terms erode user trust, inflate review costs, and create legal risk in regulated industries. Translation APIs from Ollang, Google, DeepL, Microsoft, Amazon, and ModernMT all offer mechanisms to inject glossaries and enforce terminology at request time, but their capabilities, constraints, and failure modes differ significantly. This article breaks down how each provider handles term injection, formality control, and domain adaptation at the API level, with concrete request samples, size limits, precedence rules, and testing strategies that let engineering teams codify style guides into production pipelines.

If your localization pipeline demands consistent, auditable terminology enforcement at scale, consider a unified integration layer that abstracts provider differences. See how Ollang orchestrates glossaries and formality across engines: Schedule a live walkthrough.

Why Terminology Control Matters in API-Driven Localization

The Cost of Inconsistent Terms at Scale

Terminology inconsistency is not merely a cosmetic issue. When a product label, legal term, or brand name is translated differently across surfaces, mobile UI, help center, marketing page, users notice. Support tickets increase. Regulatory reviewers flag discrepancies. And downstream, human reviewers spend disproportionate time correcting terms that should have been locked from the start.

The cost compounds with scale. An organization localizing into 30 languages with a 500-term glossary faces 15,000 term-language combinations. Without API-level enforcement, each of those combinations becomes a point of potential drift every time content is re-translated or updated. Manual review cannot keep pace with continuous delivery cycles.

How Glossaries Differ from Translation Memory

Glossaries and translation memories (TM) solve different problems, though they are often conflated.

A glossary tells the engine: “Whenever you encounter ‘compliance,’ translate it as ‘conformité’ in French, always.” A TM says: “This exact sentence was translated and approved before; reuse it.” Both reduce inconsistency, but glossaries operate at a finer granularity and are the primary mechanism exposed by most translation APIs.

Formality, Domain Adaptation, and Style Enforcement

Terminology is one axis of control. Formality, whether the output uses formal or informal register (e.g., “vous” vs. “tu” in French, “Sie” vs. “du” in German), is another. Not all APIs expose formality as a parameter, and those that do support it for a limited set of target languages.

Domain adaptation goes further, training or tuning the underlying model on domain-specific corpora so that the engine’s baseline output already reflects your industry’s conventions. Microsoft’s Custom Translator and ModernMT’s adaptive engine are the primary examples of API-accessible domain adaptation. Google and Amazon focus on glossary injection rather than model customization.

Comparing Glossary and Terminology Features Across Providers

Google Cloud Translation v3: Glossary Resources

Google’s Cloud Translation v3 (Advanced) treats glossaries as named resources that you create, upload, and then reference by resource ID in translation requests. Glossaries are defined as TSV or CSV files with source-target term pairs, uploaded to Cloud Storage, and then registered via the API.

Key characteristics:

• Glossaries are scoped to a Google Cloud project and location.
• Each glossary supports a language pair (one source → one target) or a set-based configuration (one source → multiple target languages).
• Case sensitivity can be configured during glossary application.
• Glossary entries take precedence over the engine’s output for matched terms; the engine still controls surrounding grammar and syntax.

A simplified request to translate with a glossary attached:

{
"contents": ["Please review the compliance report."],
"targetLanguageCode": "fr",
"sourceLanguageCode": "en",
"glossaryConfig": {
"glossary": "projects/my-project/locations/us-central1/glossaries/my-glossary"
}
}

When a glossary is applied, the response includes a glossaryTranslations field in addition to translations, allowing you to inspect enforced output.

DeepL API: Glossary Endpoints and Formality Parameter

DeepL provides dedicated glossary management endpoints for creating, listing, and deleting glossaries. Glossaries are uploaded as tab-separated entries and are tied to a specific language pair.

Distinctive features:

• Glossaries are strictly unidirectional. A glossary for EN→DE does not apply to DE→EN; you need a separate resource.
• DeepL exposes a formality parameter (less, more, default, prefer_less, prefer_more) on translation requests, supported for a subset of target languages including German, French, Dutch, Polish, Portuguese, and others.
• The prefer_* variants are soft preferences: if formality is unsupported for the target language, the request succeeds without error.

A curl example attaching both a glossary and formality preference:

curl -X POST https://api-free.deepl.com/v2/translate \
-H "Authorization: DeepL-Auth-Key YOUR_KEY" \
-d "text=Please review the compliance report." \
-d "source_lang=EN" \
-d "target_lang=DE" \
-d "glossary_id=abc123-def456" \
-d "formality=more"

Microsoft Translator: Custom Translator and Protected Spans

Microsoft offers two distinct mechanisms. The Custom Translator portal lets you train custom models on parallel corpora, producing a category (categoryId) that you pass in translation requests to route traffic to your trained model. This is full domain adaptation, not just term injection. You can include a terminology (dictionary) file during training to reinforce specific terms.

For lighter-weight control in real-time requests, Microsoft supports HTML-aware translation with the ability to protect spans from translation (e.g., using translate="no" or a notranslate class). This avoids unwanted changes to tokens and brand names, but it does not replace a per-request glossary.

Notes on Microsoft’s approach:

• No native, external glossary resource you can attach per request in the standard real-time API.
• Custom Translator models are versioned; you can deploy and roll back model versions independently.
• Effective domain adaptation typically requires thousands of parallel sentence pairs for training.

Amazon Translate: Custom Terminology

Amazon Translate supports custom terminology as CSV or TMX files uploaded via the API. Terms are matched in the source text, and the engine is constrained to use the specified target term.

Key characteristics:

• Terminology files have a documented size limit (commonly 10 MB per file; check the latest AWS limits).
• You can attach one terminology resource per translation request.
• Amazon Translate supports a Directionality setting: UNI (unidirectional) or MULTI (entries carry language codes and can serve multiple pairs).
• Formality control is available for a limited set of language pairs via the Settings.Formality parameter (FORMAL or INFORMAL).

A request payload with custom terminology:

{
"Text": "Please review the compliance report.",
"SourceLanguageCode": "en",
"TargetLanguageCode": "fr",
"TerminologyNames": ["my-legal-glossary"],
"Settings": {
"Formality": "FORMAL"
}
}

ModernMT: Adaptive Engine and Context Injection

ModernMT takes a different approach. Rather than relying only on static glossary files, ModernMT’s engine adapts in real time to translation memories and glossaries provided as context. You can supply TM segments and glossary entries alongside the translation request or select specific memories to influence output, without a pre-training step.

In this context-injection model, terms act as constraints while TM entries steer phrasing and style. You can route different content types (legal, marketing, UI) to different memories within the same API integration.

Feature Comparison Table

Note: Ollang is not a standalone MT engine. It is an orchestration and execution layer that sits across the engines above, providing centralized glossary and terminology management, terminology enforcement, multi-engine routing with fallback orchestration, human-in-the-loop workflows, and centralized monitoring of adherence across every provider and language pair.

Request Patterns: Attaching Glossaries and Controlling Output

Specifying Formality Levels in API Calls

Formality is a deceptively simple parameter with significant downstream impact. In languages with formal and informal registers, choosing the wrong level can make a banking app sound casual or a gaming app sound stiff.

Only DeepL and Amazon Translate currently expose formality as a request-level parameter. For other providers, formality must be controlled indirectly, either through glossary entries that encode formal variants of key terms, or through domain-adapted models trained on formal-register corpora.

When using DeepL’s prefer_more or prefer_less options, the API degrades gracefully: if the target language doesn’t support formality control, the parameter is ignored and the request succeeds. This is preferable in production to hard-failing on unsupported pairs.

Preserving Placeholders, HTML, and Markup

Real-world content is rarely plain text. UI strings contain placeholders ({username}, %d items), ICU MessageFormat tokens ({count, plural, one {# item} other {# items}}), HTML tags, and XML markup that must pass through translation untouched. Mishandling these elements produces broken interfaces and rendering errors.

Provider handling highlights:

• Google v3: Supports text/html as a MIME type, preserving HTML structure. Placeholders in non-HTML content require pre/post-processing.
• DeepL: Offers tag_handling (xml or html) and ignore_tags to protect elements from translation. split_sentences controls segmentation around tags.
• Microsoft: Accepts textType as html or plain; you can protect spans with translate="no" or a notranslate class.
• Amazon Translate: Real-time requests expect plain text; batch jobs support HTML handling. Protect placeholders via terminology or pre-processing.
• ModernMT: Supports XML/HTML tag handling with tag projection.

A practical pattern for placeholder protection is to register placeholders as glossary entries that map to themselves:

{username} {username}
{{count}} {{count}}

This forces the engine to leave these tokens untouched, though it consumes glossary capacity. For broader coverage, combine glossary protection with pre-processing that wraps tokens in non-translatable spans.

Handling Language-Pair Constraints and Size Limits

Not every glossary works with every language pair. Google’s set-based glossaries let you define multi-language mappings, but DeepL requires a separate glossary per language pair. Amazon’s MULTI directionality is flexible but still depends on supported pairs.

Size and quota constraints vary by provider and change over time. Keep glossaries curated and high-signal. A tightly scoped 200-term glossary of critical brand, product, and legal terms outperforms a 5,000-term dump that introduces false matches and increases latency.

Versioning, Precedence, and Conflict Resolution

Glossary Versioning Strategies

Glossaries evolve. New products launch, legal terminology changes, brand names get updated. Your API integration needs a versioning strategy that prevents stale terms from reaching production.

• Immutable replacement: upload a new glossary resource and update your API calls to reference it. Google and Amazon follow this pattern.
• Blue-green glossary deployment: maintain active and staging glossaries, validate staging with test translations, then switch the reference. This avoids windows where requests hit a partially uploaded or untested glossary.
• Custom models: for Microsoft Custom Translator, version at the model level. Train, test, and update the category in production requests. Roll back by reverting to the previous category.

Store glossary version identifiers alongside your deployment artifacts. If a release introduces a glossary change that degrades quality, roll back the glossary reference as part of your deployment rollback.

Precedence Rules When Multiple Controls Overlap

What happens when a glossary entry conflicts with a custom-trained model’s learned behavior? Or when two glossary entries could match the same source span?

A practical precedence hierarchy:

1. Glossary/custom terminology, highest priority. Matched terms override engine output.
2. Custom-trained model, the engine’s baseline is already shifted toward domain-appropriate output.
3. Default engine, the provider’s general-purpose model.

Within a glossary, longer matches typically take precedence over shorter ones (“compliance report” beats “compliance”). Edge cases, overlapping terms, spans that cross sentence boundaries, or compound words, can still produce surprises. Test before rollout, and document your intended precedence to avoid regressions when glossaries grow.

Coordinating multiple engines and deterministic precedence across them is operationally non-trivial. If you need a single control plane for terms, memories, and fallbacks, you can streamline this with an orchestration layer: See a unified approach in action.

Testing and Quality Assurance for Glossary-Driven Translation

Sampling and A/B Testing With and Without Glossary

Before deploying a glossary to production, run controlled comparisons. Translate a representative sample of content, covering all content types your pipeline handles, both with and without the glossary attached.

A practical test protocol:

1. Select 50-100 segments that contain glossary terms, plus 50 segments that do not, as a control group.
2. Translate each segment twice: once with the glossary and once without.
3. Compare outputs for term consistency, grammatical correctness, and overall fluency.
4. Flag regressions: cases where the glossary forces a correct term but damages surrounding grammar, a common failure mode in morphologically rich languages.

Automate this comparison in your CI pipeline. Store baseline translations and diff against new glossary versions to catch regressions before they reach users.

LQA Checks for Consistency and Accuracy

Linguistic Quality Assurance (LQA) for glossary-driven translation should focus on three dimensions:

• Term adherence: Does the output use the glossary-specified term in every instance? Automated checks can verify this with string matching against the glossary.
• Grammatical integration: Does the forced term fit grammatically in context? In morphologically rich languages (German, Finnish, Turkish), a glossary may force a nominative form where a genitive or accusative is required. This needs human review or advanced NLP checks.
• Contextual appropriateness: Is the forced term correct in this specific context? A glossary entry for “account” → “compte” works for financial contexts but may be wrong in “take into account” → “prendre en compte.” Overly broad entries create false positives.

Use the MQM (Multidimensional Quality Metrics) framework to categorize and score errors systematically. Track error rates per glossary version to measure whether terminology updates improve or degrade quality over time.

Failure Modes, Fallbacks, and Edge Cases

Common Failure Modes

• Term conflicts: Two glossary entries match overlapping spans in the source text. Many engines prefer the longest span, but behavior can vary. Audit glossaries for overlaps.
• Unsupported language pairs or mismatched glossaries: If a glossary doesn’t match the request’s language pair, providers may ignore it or return an error. Handle both outcomes gracefully and alert on mismatch.
• Morphological mismatches: The glossary specifies a base form, but the source text contains an inflected form. Engines often lemmatize before matching, but compound words and agglutinative languages (e.g., German, Turkish, Finnish) are prone to misses.
• Placeholder corruption: The engine translates or repositions a placeholder despite protection. This happens when tokens resemble natural language (e.g., {count}).
• Latency and rate limits: Large glossaries can increase request time. If you’re near provider rate limits, the added processing may cause timeouts. Monitor P95/P99 latency after deployment.

Fallback Strategies When Glossary Enforcement Fails

• Fallback to unglossaried translation: If a glossary resource is unavailable (deleted, quota exceeded, API error), translate without it rather than failing the entire request. Log the fallback for review.
• Post-processing term replacement: As a safety net, apply regex-based term replacement after translation. This is blunt, it doesn’t handle morphology, but it catches critical terms the engine missed.
• Multi-engine routing: If your primary engine doesn’t support glossaries for a specific language pair, route that pair to a provider that does. Normalize glossary formats across providers to keep behavior consistent.
• Human-in-the-loop escalation: Flag segments where glossary terms appear in the source but not in the output for review. This catches both engine failures and glossary gaps.

Codifying Style Guides and Terms for Production

Terminology control is not a one-time setup. It is an ongoing process that must be embedded in your content operations:

• Source glossaries from authoritative owners: Product managers own product terms, legal teams own regulatory terms, brand teams own brand terms. Centralize contributions but maintain clear ownership.
• Automate glossary validation: Before uploading, check for duplicates, overlapping entries, conflicting entries, and entries missing target-language translations.
• Version glossaries alongside code: Store glossary files in your repository, review changes in pull requests, and deploy them through the same CI/CD pipeline as your application.
• Monitor term adherence in production: Sample translations regularly and measure glossary term hit rates. Declining hit rates indicate glossary drift or content evolution.
• Review quarterly: Align glossary reviews with product releases. New features introduce new terms; deprecated features leave stale entries that can cause false matches.

Frequently Asked Questions

Can I use the same glossary file across multiple translation API providers?

Not directly. Each provider expects a specific format and import method, common formats include TSV/CSV, TMX, or API-specific uploads. Maintain a canonical glossary source (such as TBX, the TermBase eXchange ISO standard) and use export scripts to produce provider-specific formats. Platforms that orchestrate integrations can automate these exports and normalize terminology across engines.

How do I handle terms that need different translations depending on context?

Most translation API glossaries do not support context-dependent mappings, they enforce one target term per source term and language pair. The practical workaround is to use multi-word entries that capture disambiguating context. For example, “bank account” → “compte bancaire” and “user account” → “compte utilisateur.” If your content frequently requires context sensitivity, consider domain-adapted models or adaptive engines that learn preferences from data.

What happens if my glossary contains a term that the translation engine doesn’t recognize in the source text?

Nothing, the term is simply not applied. Glossary matching requires the source term to appear in the input text (subject to case and tokenization rules). If the term doesn’t match due to inflection or phrasing differences, the engine translates normally. Test your glossary against real content to verify match rates and adjust entries as needed.

How do I measure whether my glossary is actually improving translation quality?

Run a structured A/B evaluation. Translate a representative sample with and without the glossary, then score both outputs using an LQA framework like MQM. Focus on terminology consistency (are the right terms used?), accuracy (does the forced term fit the context?), and fluency (does the surrounding sentence read naturally?). Track these scores over time as you update the glossary.

Get Started with Consistent Terminology at Scale

Terminology control through translation APIs is achievable, but the variation in glossary formats, language-pair support, formality options, and failure behaviors across providers makes it operationally complex. Teams that treat glossary management as an infrastructure concern, versioned, tested, monitored, outperform those that treat it as a one-time configuration.

Ollang’s localization platform normalizes glossary and terminology control across engines, giving your team a single interface to manage terms, enforce formality, and monitor adherence across every language pair and content type in your pipeline.

Book a Demo