Designing Hybrid LLM+MT Pipelines: Glossaries, Tags, and Control

Machine translation APIs deliver speed and consistency, but they struggle with domain terminology, nuanced tone, and context-dependent phrasing. Large language models handle those tasks well, yet they hallucinate, drop placeholders, and resist deterministic control. Neither engine alone satisfies the requirements of production localization pipelines that must be fast, accurate, and auditable.

A hybrid pipeline combines both: the MT engine handles bulk translation with glossary enforcement and tag preservation, while a constrained LLM performs terminology extraction, quality estimation, or targeted fixups. The challenge is designing the integration so that each component does what it does best without introducing new failure modes. This article walks through the architecture, API-level implementation details, and validation safeguards you need to ship a hybrid pipeline that is safe, cost-efficient, and repeatable.

If you're evaluating how to bring this kind of pipeline into your localization stack, explore how Ollang's API layer can accelerate your integration: Get a guided integration plan.

Why Combine LLMs and MT Engines?

MT engines like Google Cloud Translation, DeepL, and Amazon Translate are optimized for throughput, consistency, and format preservation. They handle high volumes, respect glossary constraints, and return structurally predictable output. But they can produce stiff translations, miss domain-specific nuance, and lack the ability to reason about whether a translation is contextually appropriate.

LLMs excel at exactly those tasks. They can evaluate whether a translated sentence sounds natural, flag terminology mismatches, and rewrite awkward phrasing. However, they introduce risks that are unacceptable in production: they may invent content, silently drop format tags, or return output that differs structurally from the source.

A hybrid pipeline assigns each engine to its strengths:

- MT engine: Produces the base translation with glossary enforcement, tag preservation, and deterministic behavior.

- LLM: Handles pre-processing (terminology extraction, context enrichment) and post-processing (quality estimation, targeted fixups) under strict constraints.

The result is translation quality that exceeds what either engine achieves alone, with auditability and safety guarantees that production workflows demand.

Pre-Processing with an LLM: Terminology and Placeholder Extraction

Before a source segment reaches the MT engine, an LLM can perform two high-value pre-processing tasks: extracting domain terminology and identifying placeholders that must be protected during translation.

Ollang's API layer can centralize these extraction and tokenization steps so the same glossary and placeholder mappings are applied consistently across MT providers.

Extracting Domain Terminology

Feed source segments to the LLM with a prompt that constrains its output to a structured terminology list. The goal is not translation, it is identification of terms that the MT engine should handle via glossary lookup rather than general inference.

{
"model": "gpt-4o",
"messages": [
{
"role": "system",
"content": "You are a terminology extractor. Given source text, return a JSON array of domain-specific terms that require controlled translation. Do not translate. Do not explain."
},
{
"role": "user",
"content": "The API rate limiter enforces a sliding window algorithm with configurable burst capacity."
}
],
"response_format": { "type": "json_object" }
}

A well-constrained prompt returns structured output like:

{
"terms": ["rate limiter", "sliding window algorithm", "burst capacity"]
}

These extracted terms are then matched against your translation memory or terminology database. Approved translations are passed to the MT engine as glossary entries.

Protecting Placeholders and Markup

Source content frequently contains elements that must pass through translation untouched: ICU message format variables ({count, plural, one {# item} other {# items}}), HTML tags (<strong>, <a href="...">), Markdown formatting, and software placeholders like %s or {{username}}.

The LLM can identify and tag these elements before the MT call, but a more reliable approach is regex-based extraction combined with LLM verification. Use deterministic pattern matching to find placeholders, then optionally ask the LLM to confirm that the identified elements are non-translatable.

A practical pattern:

1. Run regex extraction to identify all placeholders and tags in the source segment.

2. Replace each with a numbered token (for example, <x id="1"/>) that MT engines are trained to preserve.

3. Store the mapping in a lookup table.

4. After translation, restore original placeholders using the mapping.

This tokenization step is critical. MT engines handle XML-like tokens far more reliably than raw ICU syntax or nested HTML.

Passing Glossaries and Terminology via MT APIs

Each major MT API supports glossary or terminology injection, but the mechanisms differ significantly. Passing the right terms through the right parameter is what turns generic MT output into domain-accurate translation.

DeepL: glossary_id

DeepL requires you to create a glossary resource first, then reference it by ID in each translation request. Glossaries are language-pair specific.

curl -X POST https://api-free.deepl.com/v2/translate \
-H "Authorization: DeepL-Auth-Key YOUR_KEY" \
-d "text=The rate limiter enforces burst capacity." \
-d "source_lang=EN" \
-d "target_lang=DE" \
-d "glossary_id=abc123-def456"

DeepL glossaries support one-to-one term mappings and are enforced deterministically, the engine will use the glossary translation whenever the source term appears.

Google Cloud Translation: glossaryConfig

Google's Advanced (v3) API accepts a glossary configuration object that references a glossary resource stored in your Google Cloud project.

{
"sourceLanguageCode": "en",
"targetLanguageCode": "fr",
"contents": ["The sliding window algorithm resets every 60 seconds."],
"glossaryConfig": {
"glossary": "projects/my-project/locations/us-central1/glossaries/my-glossary",
"ignoreCase": true
}
}

Google supports unidirectional and equivalent-set glossaries, giving you flexibility for terms that translate differently depending on direction.

Amazon Translate: terminologyNames

Amazon Translate accepts one or more custom terminology files referenced by name. Terminology files are uploaded as CSV or TMX and can be applied to any supported language pair.

{
"Text": "Configure the burst capacity for your API gateway.",
"SourceLanguageCode": "en",
"TargetLanguageCode": "ja",
"TerminologyNames": ["api-platform-terms", "product-names"]
}

Amazon allows stacking multiple terminology files, which is useful when you maintain separate glossaries for product names, UI strings, and technical vocabulary.

Azure Translator: Category and Custom Models

Azure's approach differs from the others. Rather than injecting a glossary at request time, Azure uses the category parameter to route requests to a custom-trained model that has been fine-tuned with your terminology through Custom Translator (https://learn.microsoft.com/en-us/azure/ai-services/translator/custom-translator/overview). Dynamic dictionary markup can also force specific translations inline using XML tags in the source text.

Provider glossary mechanics at a glance:

- DeepL: parameter glossary_id; scope per language pair; entry limits vary by plan.

- Google Cloud: parameter glossaryConfig; scope per glossary resource; quotas documented per project.

- Amazon Translate: parameter terminologyNames; stack multiple files; per-file limits apply.

- Azure Translator: category for custom models and inline dynamic dictionary tags; limits are model-dependent.

Choosing the right glossary mechanism depends on your language pair coverage, update frequency, and whether you need real-time glossary changes or can tolerate a training cycle. Ollang can transform a canonical TBX or CSV glossary into provider-specific formats at runtime to simplify multi-provider deployments.

Tag Handling: HTML, Markdown, and ICU Formats

Format preservation is where hybrid pipelines most commonly break. A single dropped </span> or reordered {placeholder} can crash a UI, corrupt a document, or produce gibberish for end users.

How MT APIs Handle Tags

Most MT APIs offer some form of tag-aware translation:

- DeepL supports tag_handling set to xml or html, with options to specify non_splitting_tags, splitting_tags, and ignore_tags.

- Google Cloud Translation accepts mimeType: "text/html" to preserve HTML structure.

- Amazon Translate processes HTML natively when the content type is set accordingly.

For ICU message format strings, none of the major MT APIs offer native support. The safest approach is to pre-process ICU patterns into tokenized segments (translating only the translatable text fragments), translate those fragments, and then reassemble the ICU structure.

Protected Segments

Some segments should never be translated: brand names, code identifiers, legal citations, URLs. Mark these as protected before sending to the MT engine. If the MT API supports ignore_tags or non-translatable spans, wrap protected content in those markers. Otherwise, replace protected content with numbered tokens during pre-processing and restore them afterward.

A protected-segment workflow:

1. Identify protected spans (regex + terminology database lookup).

2. Replace with tokens: Brand X → <x id="7"/>.

3. Send tokenized source to MT.

4. Validate that all tokens appear in the MT output.

5. Restore original content from the mapping table.

Constraining the LLM: QA-Only Mode to Prevent Hallucinations

The most dangerous use of an LLM in a translation pipeline is giving it unconstrained rewrite authority. When an LLM is asked to "improve" a translation, it may add information not present in the source, remove qualifiers, or change meaning subtly enough that human reviewers miss the error.

The safest post-processing role for an LLM is quality estimation (QE), evaluating the MT output without rewriting it, unless a specific fixup is authorized.

Structuring the QE Prompt

Constrain the LLM to return a structured assessment rather than a revised translation:

{
"model": "gpt-4o",
"messages": [
{
"role": "system",
"content": "You are a translation quality evaluator. Given a source and translation, return a JSON object with: score (1-5), issues (array of {type, severity, span}), and pass (boolean). Do not rewrite the translation."
},
{
"role": "user",
"content": "Source (EN): The API enforces rate limits per tenant.\nTranslation (DE): Die API erzwingt Ratenbegrenzungen pro Mandant."
}
],
"response_format": { "type": "json_object" }
}

The expected response:

{
"score": 5,
"issues": [],
"pass": true
}

When the LLM identifies issues, the pipeline can route the segment for human review rather than allowing the LLM to auto-fix it. This preserves auditability: every translation in the output was either produced by the MT engine (deterministic) or reviewed by a human (accountable).

When to Allow LLM Fixups

If you do permit the LLM to make targeted corrections, constrain the scope:

- Allow only terminology substitutions (replacing a generic term with the glossary-approved term).

- Allow only fluency edits that do not change meaning (reordering words for naturalness).

- Require the LLM to return both the original and revised translation so the diff can be audited.

- Reject any fixup that changes the placeholder count or tag structure.

Pipeline Sequencing: MT→LLM Fixups vs. LLM QE-Only with Rollback

Two dominant architectures emerge when combining MT and LLM engines. Each has distinct tradeoffs in quality, cost, latency, and risk.

Strategy 1: MT → LLM Fixup

The MT engine produces the base translation. The LLM reviews it and applies targeted corrections.

Sequence:

1. Pre-process source (extract terms, tokenize placeholders).

2. Call MT API with glossary enforcement.

3. Validate MT output (placeholder parity, tag structure).

4. Send source + MT output to LLM with a constrained fixup prompt.

5. Validate LLM output (placeholder parity, tag structure, diff size limit).

6. If LLM output passes validation, use it. Otherwise, fall back to the MT output.

Advantages: Higher fluency. Domain-specific phrasing improvements. Works well for marketing and user-facing content.

Risks: LLM may introduce subtle meaning shifts. Validation must be rigorous. Higher cost and latency due to two API calls per segment.

Strategy 2: LLM QE-Only with Automatic Rollback

The MT engine produces the translation. The LLM scores it but does not modify it. Segments that fail QE are routed to human review or retranslated with a different MT engine.

Sequence:

1. Pre-process source (extract terms, tokenize placeholders).

2. Call MT API with glossary enforcement.

3. Validate MT output (placeholder parity, tag structure).

4. Send source + MT output to LLM for quality scoring.

5. If QE score ≥ threshold, accept MT output.

6. If QE score < threshold, route to fallback (alternative MT engine, human review, or retry with adjusted glossary).

Advantages: No hallucination risk from LLM. Fully auditable. LLM cost is lower (scoring is cheaper than generation). Clear rollback path.

Risks: Segments that fail QE require human intervention, which adds latency. The LLM's quality scores must be calibrated to avoid false positives and false negatives.

At-a-glance comparison:

- Output quality ceiling: MT→LLM Fixup = Higher; QE-Only + Rollback = Moderate (MT-limited).

- Hallucination risk: Fixup = Moderate (mitigated by validation); QE-Only = None.

- Auditability: Fixup = Requires diff tracking; QE-Only = Full.

- Cost per segment: Fixup = Higher (generation tokens); QE-Only = Lower (scoring tokens).

- Latency: Fixup = Higher; QE-Only = Moderate.

- Best for: Fixup = Marketing, UX copy; QE-Only = Legal, technical, regulated content.

For most enterprise localization programs, a blended approach works best: use QE-only for high-risk content types and allow constrained fixups for content where fluency matters more than literal accuracy.

If you're weighing these strategies for your own content types and language pairs, talk to the Ollang team about the right decision criteria: Get pipeline design guidance.

Validation Steps: Placeholder Parity, Count Checks, and Structural Integrity

Validation is not optional in a hybrid pipeline. It is the mechanism that makes the pipeline safe. Every segment must pass validation before it enters your TMS or reaches end users.

Placeholder Parity Check

After translation (whether by MT or LLM), compare the set of placeholders in the source to the set in the target. Every placeholder token that appeared in the source must appear exactly once in the target, in any order.

import re

def check_placeholder_parity(source: str, target: str) -> bool:
pattern = r'<x id="\d+"/>'
source_tokens = sorted(re.findall(pattern, source))
target_tokens = sorted(re.findall(pattern, target))
return source_tokens == target_tokens

Tag Structure Validation

For HTML and XML content, parse the target to verify that all tags are properly opened and closed, and that nesting order is preserved. A simple stack-based parser catches most structural errors.

Count Checks

For ICU plural and select messages, verify that the target contains the same number of branches as the source. A {count, plural, one {...} other {...}} pattern in the source must have exactly the same branches in the target.

Diff Size Limiting

When using LLM fixups, compute the edit distance between the MT output and the LLM output. If the diff exceeds a configurable threshold (for example, more than 30% of characters changed), reject the fixup and fall back to the MT output. Large diffs indicate the LLM rewrote the segment rather than making targeted corrections.

Validation Pipeline Summary

1. Placeholder parity: source tokens == target tokens.
2. Tag structure: valid nesting, no orphaned tags.
3. ICU branch count: source branches == target branches.
4. Diff size (fixup mode only): edit distance ≤ threshold.
5. Length ratio: target length within expected range for the language pair.
6. Encoding: no mojibake, correct Unicode normalization.

Any segment that fails validation is flagged, logged, and routed to the fallback path.

Cost, Latency, and Fallback Chain Design

Cost Tradeoffs

MT API costs are typically per-character, while LLM costs are per-token (input + output). In a QE-only pipeline, the LLM processes both the source and the translation as input but generates minimal output (a score and a short issue list), keeping token costs low. In a fixup pipeline, the LLM generates a full alternative translation, increasing output token cost.

For high-volume pipelines processing millions of words per month, the cost difference between QE-only and fixup strategies is significant. Batch both MT and LLM calls where possible, most MT APIs offer batch endpoints, and LLM providers support batched requests at reduced rates.

Latency Considerations

MT APIs typically return results with low latency. LLM calls add more latency, depending on the model and prompt length (often sub-second to a few seconds). For real-time use cases (live UI string translation, chat support), the LLM step may need to run asynchronously, with the MT output served immediately and the LLM QE result applied retroactively.

For batch localization workflows, latency is less critical. Pipeline both steps and process segments in parallel where the API supports it.

Fallback Chains

A robust hybrid pipeline defines a fallback chain for every failure mode:

- MT API timeout or error: Retry with exponential backoff, then fall back to a secondary MT provider.

- LLM API timeout or error: Accept the MT output without QE scoring; flag the segment for later review.

- Validation failure (MT output): Retry with adjusted glossary settings or fall back to a secondary MT provider.

- Validation failure (LLM fixup): Discard the LLM output and use the validated MT output.

- QE score below threshold: Route to human review queue.

Document the fallback chain explicitly. Every segment in the final output should carry metadata indicating which path it took: MT-only, MT+QE-pass, MT+LLM-fixup, or human-reviewed. This metadata is essential for quality reporting and continuous improvement.

Frequently Asked Questions

How do I prevent the LLM from hallucinating in a translation pipeline?

Constrain the LLM to a quality estimation role rather than giving it rewrite authority. Use structured output formats (JSON with explicit fields), enforce response schemas, and validate every LLM output against the source before accepting it. If you allow fixups, limit the edit distance between the MT output and the LLM revision, and reject any change that alters placeholder counts or tag structure. In practice, platform-side schema enforcement and validation, like those Ollang applies, reduce hallucination risk.

Can I use a single glossary across multiple MT providers?

Not directly, each provider uses a different glossary format and API parameter. However, you can maintain a single canonical glossary in a standard format (TBX or CSV) and transform it into provider-specific formats at deploy time. This keeps your terminology consistent regardless of which MT engine handles a given request.

What is the best pipeline strategy for regulated or legal content?

Use the LLM QE-only strategy with automatic rollback. The MT engine produces the translation, the LLM scores it without modifying it, and any segment that fails quality thresholds is routed to human review. This approach eliminates hallucination risk and provides a fully auditable trail showing that every translation was either produced deterministically by the MT engine or reviewed by a qualified linguist.

How do I handle ICU message format strings in MT APIs?

No major MT API natively supports ICU message syntax. Pre-process ICU strings by extracting the translatable text fragments from each branch, translating them individually, and reassembling the ICU structure afterward. Validate that the target has the same number of branches and that all variables are preserved. Tokenize variables before sending to the MT engine to prevent them from being translated or corrupted.

Build Your Hybrid Pipeline with Confidence

Designing a hybrid LLM+MT pipeline is not about choosing one technology over another. It is about assigning each engine to the task it handles best, wrapping both in validation that catches errors before they reach users, and maintaining an auditable record of every decision the pipeline makes. The patterns described here, glossary enforcement, placeholder tokenization, constrained QE prompts, diff-limited fixups, and structured fallback chains, give you the building blocks for a pipeline that is both high-quality and production-safe.

Ollang's API integration layer orchestrates hybrid workflows across MT providers, LLM services, and human review queues, simplifying glossary mapping, tokenization, validation, and audit metadata.

Get a hands-on walkthrough

Book a Demo