Translation Quality Assurance: A Practical Guide

Translation quality assurance (TQA) is the set of checks and process controls that catch errors — mistranslations, inconsistent terminology, broken formatting, missing text — before a translated document, app, or website ships. The term gets used loosely to cover two different things: quality assurance, which builds correctness into the translation process before anything is delivered, and quality control, which inspects the finished output for defects. This guide separates the two, walks through the standards that formalize them, lists what a real QA pass actually checks, and explains how QA tools and quality-evaluation frameworks fit into a modern translation workflow — for both human and machine-translated content.

What is translation quality assurance?

A translated text is considered high quality when it meets a set of predefined criteria, not when it merely "sounds right" to one reader. Industry practice groups those criteria into a handful of recurring checks: no spelling or grammar mistakes, terminology used correctly and consistently throughout the text, the meaning of the source preserved without additions or omissions, a style that matches the source material, text that reads naturally in the target language, culture-specific references adapted for the target audience, locale-appropriate formatting for things like dates, and adherence to the client's own guidelines and glossary. That checklist — and the observation that even a skilled translator can miss one of these under a tight deadline — is why translation quality management involves more than one person and more than one step.

TQA, in that sense, is not a single test at the end of a project. It is the combination of process design (deciding who checks what, and when) and the tooling that automates the mechanical part of that checking.

Translation QA vs. QC vs. quality evaluation

In everyday industry writing the terms "translation quality assurance" and "translation quality control" are frequently used interchangeably. Read strictly, though, they describe two different points in the workflow:

• Quality assurance (QA) is process-oriented and preventive. It is decided before a single word is translated: which style guide and glossary apply, which steps the project must go through, and who is qualified to perform each one.
• Quality control (QC) is product-oriented and reactive. It happens after translation and inspects the actual deliverable — a bilingual comparison against the source, a monolingual read for fluency, a final proofread — to catch defects before delivery.
• Quality evaluation is a distinct, later-stage practice: scoring a finished translation (or a batch of machine-translated output) against a shared error typology to produce a comparable number, used to compare translators, vendors, or MT engines over time rather than to fix a single document.

The clearest evidence that the industry treats these as separate steps rather than one blob called "QA" is how the main process standard for translation services actually structures a project — which is the next section.

The standards behind translation quality: ISO 17100 and MQM

ISO 17100: the process standard

ISO 17100:2015, Translation services — Requirements for translation services, specifies requirements for the core processes, resources, and qualifications a translation service provider needs to deliver a translation that meets the agreed specifications. It defines the project as a sequence of distinct steps, each with its own purpose: translation (including a self-check by the translator), revision by a second, appropriately qualified person who compares the target text against the source, an optional review step that assesses whether the translation is suitable for its intended purpose and domain, an optional proofreading pass before publication, and a final verification before delivery. Revision by a second person is mandatory under the standard — it is not an optional extra. Two exclusions matter for anyone working with machine translation: ISO 17100 explicitly does not cover raw machine translation output that is then post-edited, and it does not apply to interpreting.

That last exclusion is why a companion standard exists specifically for MT: ISO 18587:2017 provides requirements for the process of full, human post-editing of machine translation output and for post-editors' competences. It applies only to content that has already been processed by an MT system, and it explicitly defers to ISO 17100 for translation services in general — the two standards are meant to be read together, not as substitutes for each other.

MQM and other quality-evaluation models

Where ISO 17100 defines a process, the Multidimensional Quality Metrics (MQM) framework defines how to score the result. MQM is a hierarchical, open error typology — categories such as accuracy, fluency, terminology, and style, each broken down into more specific error types — paired with analytic and holistic scoring models that turn annotated errors into a comparable quality number. It is designed for both human and machine translation, is stated to align with ISO 5060, and has been maintained by the MQM Council since 2016, continuing work that began in the EU-funded QTLaunchPad and QT21 research projects.

MQM is not the only scoring model in commercial use. Enterprise localization platforms typically let a project manager choose between several named models when setting up a linguistic quality assessment, including the TAUS DQF-MQM model, the LISA QA model, and the SAE J2450 model, or define a custom set of error categories and weights. The mechanics differ, but the underlying idea is the same across all of them: classify each error by type and severity, then turn the tally into a score that means the same thing across projects.

What a translation QA process actually checks

Stripped of vendor-specific labels, the checks that make up a translation QA pass fall into five recurring categories:

A full-service project typically runs these checks across several people and steps: the translator, a dedicated proofreader or editor, sometimes a desktop-publishing pass that puts the translation back into its original layout, a further proofread of the final file, and a project manager who confirms everything before it reaches the client. How many of those steps a given project actually gets tends to track its perceived value, timeline, and budget — an internal memo and a public-facing product page rarely go through the same number of eyes.

How translation QA tools work

Dedicated QA tools automate the mechanical half of that checklist — mainly the linguistic, terminology, formatting, and workflow categories above — by comparing each target segment against its source segment and flagging discrepancies for a human to resolve. They typically run in one of two modes inside a computer-assisted translation tool or translation management system: a manual pass that checks the entire translation in one batch, usually once a translator marks the job complete, or an automated check that runs the moment a single segment is confirmed and blocks it from entering the translation memory until any flagged issue is resolved. The second mode matters more than it might sound: it stops an unverified segment from being reused — and its error propagated — across every future project that draws on the same translation memory.

None of this replaces human judgment. QA tools are good at exact, rule-based mismatches (a number that doesn't match, a tag that's missing, a forbidden term); they cannot tell you whether the translation actually reads well or captures the right tone, which is what the review and proofreading steps in ISO 17100's process exist to catch.

QA for machine translation output

Everything above applies to human translation. Machine-translated content needs an extra layer, because raw MT output is explicitly outside the scope of ISO 17100 and is instead governed, once a human post-editor touches it, by ISO 18587. Two things follow from that split. First, a QA process for MT output has to specify whether the goal is light post-editing (making the output understandable) or full post-editing (bringing it to a quality comparable to human translation) — the two imply very different checklists and effort. Second, evaluating raw MT output before a human ever sees it is its own discipline, combining automatic metrics with human evaluation; we cover the specific metrics — BLEU, COMET, and how human evaluation is structured — in our guide to machine translation quality evaluation. Because MT engines don't produce output of consistent quality across language pairs or content types, the choice of engine itself is a QA decision; our DeepL vs. Google Translate comparison is a concrete example of why that raw-output quality varies enough to matter before any post-editing budget is set.

Building a translation QA workflow

A workable TQA setup, in practice, combines the three layers covered above rather than picking one:

• Process (the QA layer): define the glossary, style guide, and which of ISO 17100's steps — revision, review, proofreading — the project needs, before translation starts.
• Automated checks (the QC layer): run a QA tool's linguistic, terminology, formatting, and workflow checks on every segment, ideally as it's confirmed rather than only at the end.
• Scoring (the evaluation layer): for recurring vendors, language pairs, or MT engines, sample output periodically against an error typology such as MQM so quality is a comparable number over time, not just a pass/fail on a single file.

This is also where the tooling question turns into a broader one: most of the platforms that run these checks are one line item in a larger stack of AI tools for business, and the same automated-checking logic — compare an output against a reference, flag deviations, block anything that fails — increasingly shows up in AI writing tools built for other kinds of text. If your workflow already includes machine translation, start from a platform built around that, rather than bolting QA onto a generic document tool; our guide to the best machine translation software compares seven platforms on exactly this basis.

Frequently asked questions about translation quality assurance

What is quality assurance in translation?

It's the process design and preventive controls — glossary, style guide, defined workflow steps, and who is qualified to perform each one — that are put in place before translation begins, so that errors are prevented rather than only caught afterward. It is distinct from quality control, which inspects the finished translation.

What's the difference between translation QA and translation QC?

QA is process-oriented and happens before and during translation (defining steps and standards); QC is product-oriented and happens after translation (inspecting the actual output for defects, such as the revision and review steps defined in ISO 17100). In casual industry usage the two terms are often blended, but the process standard itself treats them as separate stages.

What are the QA tools used for translation quality assurance?

QA functionality is typically built into computer-assisted translation tools and translation management systems rather than sold as a separate step. These tools compare each target segment against its source and flag linguistic errors, terminology inconsistencies, formatting and tag mismatches, and unresolved workflow items, either in a batch check at the end of a job or automatically as each segment is confirmed.

Is there a certification for translation quality assurance?

There is no single universal "TQA certification." What exists are process and competence standards that a translation service provider or post-editor can be assessed and audited against — chiefly ISO 17100 for translation services in general and ISO 18587 for machine-translation post-editing — plus vendor-specific training on individual QA tools and scoring models such as MQM.

What is a translation quality assurance framework?

It's a structured way of defining and measuring quality rather than a single tool: an error typology (categories and severities of possible defects), a scoring model that turns tallied errors into a comparable number, and guidance on sampling and thresholds. MQM is the most widely referenced open framework of this kind, and commercial platforms often let teams choose between it and other named models, such as the TAUS DQF-MQM, LISA QA, or SAE J2450 models.