Your client’s 47-page compliance manual came back from the MT engine yesterday. You spot “unauthorized disclosure” rendered as “illegal leak” in one paragraph, a dangling pronoun in three sentences, and a technical term used three different ways. Where do you even start categorizing what needs fixing—and more importantly, which errors will tank the final quality score?
Enter DQF-MQM: the translation industry’s shared error taxonomy that post-editors, QA teams, and MT vendors speak in the same language about quality. It’s not just a checklist; it’s a framework that lets you predict effort, track which errors cost you the most time, and make data-backed decisions about MT engine selection. Let’s dig into what it is, how it works, and why your post-editing workflow depends on it.
What Is DQF-MQM, and Why Did We Need It?¶
Before 2014, translation quality looked like chaos. A European project might use their own error taxonomy, a Japanese vendor a different one, and an American LSP yet another. Someone’s “critical error” was another person’s “minor issue.” This fragmentation meant teams couldn’t compare quality across workflows or aggregate data meaningfully.
In response, two frameworks emerged and eventually merged:
DQF (Dynamic Quality Framework), created by TAUS (Translation Automation User Society), introduced the concept of fitness for purpose. Rather than an absolute quality standard, DQF asked: “What does good look like for this specific content type and workflow?” A marketing brochure and a legal contract have different quality requirements; so do raw MT and post-edited output.
MQM (Multidimensional Quality Metrics), developed by DFKI (German Research Center for Artificial Intelligence), provided the detailed error taxonomy—the actual menu of error types and how to classify them.
Around 2014-2015, these frameworks were harmonized into DQF-MQM: TAUS’s workflow model married with DFKI’s error taxonomy. Today, DQF-MQM is the de facto standard across the industry. It’s used by language service providers (LSPs), freelance post-editors, academic researchers, and MT vendors for consistent quality reporting.
Note: The MQM Council has recently released MQM-Core, an update that supersedes the original DQF-MQM, but the core principles and most error categories remain unchanged.
The Error Category Hierarchy: Four Main Buckets¶
DQF-MQM organizes errors into four primary categories. Every mistranslation, typo, or awkward phrase falls into one of these buckets—and that classification determines how a post-editor tackles it.
Accuracy: Did the Meaning Make It?¶
Accuracy errors are the heavyweight of post-editing work. They’re about whether the translated text conveys the source meaning.
Accuracy includes:
- Mistranslation — The translator (or MT engine) chose the wrong meaning for a word or phrase. “Untranslated contract” rendered as “free contract” is a mistranslation (mistranslation ≠ missing translation). This is the single largest source of major errors in machine translation.
- Omission — Content from the source is missing entirely. A whole sentence, a clause, or even a critical word is dropped. In MTPE workflows, these are expensive to fix because the post-editor must mentally reconstruct what was lost.
- Addition — The translation includes words or phrases not in the source. The MT engine “hallucinated” extra content, a common failure mode of neural MT.
- Untranslated text — A word or phrase appears in the source language within the target translation. Classic example: an English proper noun or technical term left as-is in a German translation.
Accuracy errors demand semantic correction, not just style tweaking. They’re what eat up post-editing hours. Research shows that accuracy mistakes—particularly coherence issues and meaning shifts—are the single best predictor of post-editing effort across language pairs and domains.
Fluency: Does It Sound Right?¶
Fluency errors don’t change meaning; they break native-speaker expectations for flow, grammar, and readability.
Fluency includes:
- Grammar — Subject-verb disagreement, tense mismatches, case errors, syntactic construction problems.
- Punctuation — Missing or misplaced periods, commas, quotes, or colons.
- Spelling — Typos, character encoding errors (mojibake), incorrect word forms.
- Register — Mismatched formality level. A legal document translated in casual slang, or a conversational text in stiff corporate language. The words are technically correct but contextually wrong.
- Inconsistency — The same source term translated two different ways within one document. The MT engine uses “data” in one paragraph and “information” in another, breaking consistency.
Fluency errors are usually faster to fix than accuracy errors. A grammar correction or punctuation fix takes seconds; reworking a mistranslation takes minutes. However, register mismatches in specialized domains (legal, medical) can be subtle and require domain knowledge to catch.
Terminology: Is the Technical Term Correct?¶
Terminology errors are about domain-specific vocabulary and consistency.
Terminology includes:
- Inappropriate term for context — The word choice is technically accurate but wrong for the field. Using “storage” where “escrow” is required in legal translation. Using a generic medical term where the text demands the clinical name.
- Inconsistent terminology — The same concept is translated multiple ways in one document. In technical manuals, this is catastrophic (different names for the same component confuse readers).
- Missing terminology entry — If a glossary exists for the project, the term wasn’t found or applied.
Terminology errors sit between accuracy and fluency: they don’t obliterate meaning, but they signal the text wasn’t translated for the intended audience or domain. Professional post-editors catch these by referring to project glossaries and style guides; they’re minimized when clear terminology resources are available upfront.
Style: Does It Sound Like Us?¶
Style errors cover consistency in tone, brand voice, and conventions.
Style includes:
- Awkward phrasing — Syntactically correct but clunky, unnatural phrasing that a native speaker would rephrase.
- Formal vs. informal mismatch — Not quite register (which is about appropriateness), but tone. The text sounds too stiff or too casual for the brand.
- Convention violations — Breaking expected format (numbers written as words vs. numerals, date formats, abbreviation styles).
Style errors are the most subjective and context-dependent. Two equally skilled post-editors might “fix” a style issue differently—one prefers active voice, another passive. They’re rarely showstoppers but accumulate to create a sense that the text wasn’t professionally refined.
Severity Levels: Weighing the Impact¶
Every error also gets a severity tag: Major, Minor, or Neutral.
| Severity | Definition | Example |
|---|---|---|
| Major | Changes meaning, prevents comprehension, or misleads readers. A reader would misunderstand or make a wrong decision based on this error. | A medical instruction “do not take with food” translated as “take with food.” A price mistranslation in a contract. A critical omission of a legal clause. |
| Minor | Affects comprehension or professional quality but doesn’t block understanding. Rework is needed; readers notice but can usually infer correct meaning. | A grammar error that’s obvious to fluent speakers. Terminology used incorrectly but in context you can guess meaning. A single word omitted in a long sentence. |
| Neutral | No impact on comprehension or usability; purely stylistic. Some QA teams omit neutral errors from scoring; others note them as optional polish. | A punctuation preference (Oxford comma), an inconsistent space before punctuation, a capitalization choice. |
How this drives post-editing priority: Post-editors often tackle major errors first (they affect acceptability), then minor errors (they affect quality and reading time), then neutrals (polish). When time is tight, neutral-only issues may be deprioritized.
How Post-Editors Use DQF-MQM in Practice¶
Understanding the taxonomy is step one. Applying it in real work is where value emerges.
Annotation Workflow¶
In formal MTPE environments, post-editors (or QA reviewers) annotate errors: 1. Identify the error span in the translation. 2. Classify it (Accuracy → Mistranslation, Fluency → Grammar, etc.). 3. Mark severity (Major/Minor/Neutral). 4. Add a comment if needed (why it’s wrong, what the fix is).
Tools like memoQ, Memsource, Phrase, and others support DQF-MQM annotation either natively or via plugins. Google Sheets or simple XML also work for smaller projects.
Quality Scoring¶
Once annotated, scores are calculated. The standard approach (MQM Linear Calibrated Scoring Model, 2024): - Tally errors by type and severity. - Apply weights (a major accuracy error “costs” more than a minor punctuation error). - Convert to a 0-100 quality score.
A document with only minor fluency errors might score 92/100 (acceptable). One with multiple major accuracy errors might score 65/100 (needs rework). This score becomes a shared metric between client, post-editor, and MT vendor.
Predictive Work: Which Errors Cost the Most Time?¶
Post-editors who’ve annotated errors over dozens of projects notice patterns. Research confirms:
- Coherence/meaning-shift errors (accuracy) consume the most effort, especially when they require rethinking entire passages.
- Structural problems (grammar chains, sentence-level issues) are also high-effort.
- Simple fluency fixes (punctuation, spelling) are quick.
- Terminology errors depend on domain complexity; legal terminology is slower than marketing.
By tracking these patterns in your own projects, you can estimate post-editing time more accurately. You can also use this data to choose between MT engines: “Engine A has fewer accuracy errors but more fluency issues; Engine B is the opposite.” Depending on your domain and time budget, you optimize for the error profile that suits your workflow.
The Severity Paradox: Why Context Matters¶
Here’s where DQF-MQM earns its “multidimensional” name. The same error can be major in one context and minor in another.
Example: A mistranslation of the word “date.” - In a legal contract about contract date: Major (meaning changes). - In a casual greeting (“How’s your date going?”): Minor (context makes meaning clear, easy fix). - In a dating app UI label: Major (affects user action).
The typology gives you categories; your judgment (and project requirements) determine severity. A post-editor with domain expertise catches nuance that automated tools miss—this is why human review remains essential for high-stakes documents.
Which Error Types Matter Most for MTPE?¶
A landmark 2017 study published in Frontiers in Psychology tracked post-editors using keystroke logging and eye-tracking. The finding was clear: not all errors are created equal.
Errors with the highest post-editing effort: 1. Coherence issues (text flow, logical consistency) — These often stem from accuracy mistakes and require reworking multiple sentences. 2. Meaning shifts (the core semantics changed) — Mistranslations that require re-reading source to verify correct meaning. 3. Structural problems (sentence-level grammar and syntax) — These are sometimes fixable with small edits, sometimes require rephrasing.
Errors with lower effort: - Spelling and punctuation (seconds per fix). - Minor register mismatches (often just a word swap). - Single-word omissions in long sentences (context is still clear).
The implication: if you’re selecting an MT engine or optimizing your workflow, prioritize accuracy (fewer mistranslations) over fluency (which you can quickly clean up). Fluency tools improve fast; meaning preservation is harder and more costly when it fails.
Practical Example: Annotating a Real Segment¶
Let’s say your client submitted this source: “The contract must be signed by the authorized representative within 30 days of receipt.”
The MT engine produces: “The contract must be signed for the authorized representative during 30 days from receiving.”
How would a post-editor annotate this using DQF-MQM?
- “must be signed for” → Accuracy / Mistranslation (Major). “For” changes the meaning (it’s not “on behalf of,” it’s “by”); a lawyer would catch this as a critical error.
- “during 30 days from receiving” → Accuracy / Mistranslation (Minor) + Fluency / Register. “During” is less precise than “within”; “from receiving” is clumsier than “of receipt” (already fixed via accuracy correction, so some double-tagging is OK). The meaning is mostly preserved but the legal register is off.
Post-editor correction: “The contract must be signed by the authorized representative within 30 days of receipt.”
The annotation reveals: this segment had accuracy issues (high priority) that also affected fluency/register. The post-editor would flag these under DQF-MQM, and the aggregate data tells the client: “This MT engine struggles with legal prepositions and precision; expect 12-15% of segments to need accuracy rework.”
FAQ: Post-Editors’ Top Questions¶
Q: Should I annotate every error or just majors? A: For full-sample QA and research, annotate everything (majors, minors, neutrals). For client reporting or time-constrained work, majors and minors suffice. Neutral-only errors can be skipped if time is tight, though they reduce the final quality score.
Q: Does DQF-MQM replace human judgment? A: No. DQF-MQM gives you vocabulary and structure. Deciding whether a terminology mismatch is truly “inappropriate for context” or whether a fluency issue is “major” or “minor” requires human expertise and domain knowledge. Use DQF-MQM to organize your thinking, not to automate it away.
Q: Can I use DQF-MQM for MT selection? A: Absolutely. Run a test document through multiple MT engines, have a post-editor annotate errors in each output, and compare error profiles. Engine A might have fewer accuracy errors but more fluency issues; Engine B the opposite. Choose based on your workflow’s tolerance.
Q: What if my client uses a different error taxonomy? A: Many clients or vendors have their own frameworks (LQA is common for simpler needs). Confirm their scheme upfront. DQF-MQM is standard for professional MTPE but not universal. If there’s a mismatch, align on severity levels at minimum so “major” means the same thing.
Q: Is MQM-Core replacing DQF-MQM? A: MQM-Core is the current evolution from the MQM Council. The core categories (accuracy, fluency, terminology, style) remain; some subcategories and scoring models have been updated. For most practical post-editing work, the differences are minor—check your tool’s support to confirm it uses MQM-Core if that’s required.
DQF-MQM is not glamorous, but it’s the backbone of professional machine translation post-editing. It gives you a shared language to talk about quality, data to back your workflow decisions, and a framework that scales from a single freelance project to enterprise quality programs. The next time you’re staring at 47 pages of raw MT output, remember: every error fits into one of four categories, gets one of three severity levels, and contributes to a picture of your MT engine’s real performance. That’s when the taxonomy becomes a tool.