The deadline’s behind you. Your post-editing team finished their day. Then QA finds 140 errors across 2,000 segments—and half of them should’ve been caught automatically, before humans touched the text. Double spaces. Forgotten glossary terms. Format mismatches. Missing numbers. All the things an algorithm sees better than people, but nobody configured the checks.
That’s why automated QA checks aren’t a nice-to-have in MTPE workflows—they’re the foundation. They don’t replace human review, but they catch 70% of gross errors before editing even starts, saving 25-40% of your reviewer’s time and preventing the rework that costs downstream.
What Automated QA Checks Are¶
Automated QA checks are configured rules that scan translated text and flag objective, easy-to-miss errors without needing a human reference translation or human judgment.
Unlike a human reviewer who reads the full text and assesses semantics, QA checks work by simple rules:
- “If there’s a double space in the target, flag it.”
- “If a glossary term appears in the source but the translation doesn’t match the glossary, warn.”
- “If the source has 3 numbers and the target has 2, flag it.”
- “If tag <b> is in source but not target, block.”
These checks run automatically in CAT tools (memoQ, Trados, Smartcat, Phrase) or standalone QA modules at each stage of the MTPE pipeline.
Why QA Checks Matter for MTPE¶
The MTPE cycle goes: machine translation → post-editing → quality review → export. In reality, if QA checks are weak or missing, your QA reviewer spends 40-50% of their time hunting mechanical errors instead of reviewing semantics or terminology.
According to research on QE for Post-Editing (2025), when post-editors know where the MT is weak, they edit 30% faster—they have focus. But without QA signals, they waste 15-25% of their time searching for errors instead of fixing them.
Also, ISO 18587:2017 (the standard for MTPE) requires validation across at least 8 error categories: 1. Terminology (consistency, glossary match) 2. Punctuation 3. Numbers and date formats 4. Tags (HTML, XML, formatting) 5. Formatting (paragraphs, spacing, line breaks) 6. Missing or extra segments 7. Spelling 8. Context (some errors need surrounding context, not just a segment)
If you’re not checking all 8, you’re risking non-compliance.
Essential QA Checks for Every MTPE Workflow¶
1. Terminology Consistency¶
The term “API” translated once as “интерфейс программирования” cannot appear as “API интерфейс” later. Ever.
How it works: - Your project glossary holds approved terms and their translations. - QA scans each segment: if the source term exists and the target doesn’t match the glossary, it signals. - In memoQ, you can configure bidirectional checks: if source has a term, target must have the matching translation; if target has a term, it must be in the glossary.
Real example: Financial domain. Glossary: “share” → “акция”, “dividend” → “дивиденд”, “risk” → “риск”. An editor accidentally types “shares” (plural, not in glossary) instead of the approved singular. QA flags it as “terminology mismatch.” Without the check, it publishes.
How to set it up: - In memoQ/Trados: QA Settings → Terminology → enable “Check terminology” + “Both directions.” - Be careful though: if your glossary is huge or has optional variants, you’ll get alert fatigue. Split it into “mandatory” and “recommended” terms.
2. Formatting and Punctuation¶
Double spaces, missing commas, stray symbols where they shouldn’t be.
QA catches: - Double spaces (two consecutive spaces) - Missing trailing punctuation (if source ends with a period, target must too) - Mismatched quotes or brackets (opening bracket without closing) - Broken paragraph structure
Example:
Source: “Hello, world.”
Translation: “Привет, мир”
QA flags: missing period at end.
Setup: memoQ/Trados → QA → Punctuation & Spacing → check “trailing punctuation” and “double spaces.”
3. Numbers and Dates¶
Numbers often need localization (thousand separators, date formats), and if MT missed a number or got it wrong, it should be caught.
QA flags: - Count mismatch: source has 3 numbers, target has 2 - Format changes (1,000 in English, 1.000 in German, 1 000 in Russian) - Wrong date format (DD.MM.YYYY vs MM/DD/YYYY)
Example:
Source (English): “Cost: $1,500”
Translation: “Стоимость: $1500” (missing separator)
QA detects: number present, but format changed — depending on settings, it signals.
4. Tags and Placeholders¶
HTML/XML tags, variable placeholders, DOCX formatting tags (bold, italic, hyperlinks).
QA catches:
- Tag <b> in source but not target (or vice versa)
- Placeholder {name} missing in target
- Unmatched brackets
Without this, the translated document breaks on export.
Example:
Source: <p>This is <b>bold</b> text.</p>
Translation: <p>Это <b>жирный текст.</p> (closing </b> missing)
QA flags: tag mismatch.
5. Missing or Extra Segments¶
If source has 2,000 segments and the translation has 1,998 or 2,002, that’s a serious problem.
QA catches: - Segment count mismatch - Empty segment (only spaces or special chars) - Untranslated segment (source text copied as-is into target)
Quality Metrics for MT Output¶
Beyond rule-based checks, understand the quality of the raw MT output before editing. This helps decide: edit the whole thing or cherry-pick?
BLEU (Bilingual Evaluation Understudy)¶
BLEU measures how similar the translation is to a reference translation using n-grams (word sequences). Scale: 0-100.
- BLEU > 50 — good quality, editing should be light.
- BLEU 30-50 — medium quality, typical editing effort.
- BLEU < 30 — poor quality, either rework the content or the data is highly specialized.
Limitations: BLEU ignores context and can reward translations that use the right words in the wrong order.
TER (Translation Edit Rate)¶
TER counts the number of edits (insertions, deletions, substitutions, phrase shifts) needed to transform the MT output into a reference, divided by reference length.
- TER < 40 — strong quality (few edits needed).
- TER 40-50 — acceptable quality.
- TER > 60 — weak quality, needs serious rework or full retranslation.
Example: Source: 100 words. MT needs 35 edits to match reference. TER = 35 / 100 = 35% — strong quality.
COMET (Crosslingual Optimized Metric for Evaluation of Translation)¶
COMET is a neural network trained on human quality judgments and gives far more accurate scores than BLEU. It correlates with human judgment at the segment level much better.
By 2024-2025, COMET is becoming the standard in professional QA pipelines where accuracy matters.
Intelligent Routing by Quality¶
If you know MT quality upfront, route intelligently:
- BLEU > 60, TER < 30: content already meets quality standards, skip post-editing or do light review only.
- BLEU 40-60, TER 30-50: typical post-editing, but editors know quality is baseline-acceptable.
- BLEU < 40, TER > 50: retranslate fully, don’t post-edit.
This lets you allocate resources smarter.
Common QA Setup Mistakes¶
1. Too Many Signals → Alert Fatigue¶
If QA flags 500 warnings in 1,000 segments, editors ignore them. Be selective.
Fix: split rules into hard blocks (stop export) and soft warnings (suggestions). Hard: missing segments, tag mismatches. Soft: possible glossary misuse.
2. QA Profile Not Updated with Project Changes¶
Your glossary changed but QA rules didn’t. Result: old errors get through, new terms go unchecked.
Fix: review and update QA settings whenever the glossary or key constraints change.
3. One QA Profile for All Languages¶
Date formats, punctuation, word order differ by language. English→German QA is different from English→Japanese.
Fix: create language-pair-specific QA profiles.
Implementing QA in Your Workflow¶
Step 1: Identify Which Errors Matter Most¶
For your domain/project, ask: what gets missed most? Terminology? Numbers? Tags? Start there.
Step 2: Configure Your CAT Tool¶
- memoQ: Workspace → Project Settings → QA → enable relevant checks (Terminology, Punctuation, Numbers, Tags, etc.).
- Trados: Tools → QA Checker Configuration → set up per-project rules.
Step 3: Pilot with a Small Set¶
Run QA on 100-200 segments, review results: how many real errors vs false alarms? Tune sensitivity.
Step 4: Integrate into Editor Workflow¶
Export QA results to editors before they start, or show signals live in the editor. Most CAT tools have built-in alerting.
Step 5: Monitor Trends¶
Track: QA signals per segment, errors missed by QA, patterns in what slips through. Over a few projects, you’ll see what works.
Frequently Asked Questions¶
How often should automated QA run in an MTPE workflow?
At every gate: after MT output (to route intelligently), during editing (live signals to the editor), and before export (final validation). In integrated CAT tools, this happens continuously with zero manual trigger.
Can I just run terminology consistency checks and skip the rest?
No. Terminology alone catches 10-15% of errors. You need multidimensional QA: formatting + terminology + numbers + tags + punctuation. Otherwise your QA reviewer spends 50-60% of their time finding things QA should have flagged.
Are BLEU and TER the same metric?
No. BLEU measures similarity to a reference translation (0-100, higher is better). TER counts edits needed to fix the output (lower is better). Together they give a complete picture: BLEU shows “how close,” TER shows “how much work.”
If QA detects an error, should it block export?
Depends on severity. Critical errors (missing segments, tag mismatches) — yes, hard block. Warnings (possible glossary misuse) — no, show as a signal for manual review. Your QA profile needs clear rules for “hard block” vs “warning.”
Do automated QA checks replace human quality review?
No. They replace ~70% of mechanical, easy-to-miss errors. For semantic issues (wrong context, language nuance), judgment calls on terminology, and overall quality — humans are still essential. QA frees them from hunting double spaces.