Translation Quality Assurance: A Guide for Content Teams

Translation quality assurance (TQA) is what separates a content programme that scales reliably from one that produces a growing backlog of inconsistencies and rework. It is the process that determines whether translated content is accurate, consistent, and right for each target market.

None of the problems starts as a crisis. A term that shifts meaning across language pairs. A tone that drifts between projects. Across a content library, they add up to a brand consistency problem. One that costs more to fix the longer it goes unnoticed.

This guide covers what a structured TQA process involves and how to build it into your workflow.

‍

What is translation quality assurance (TQA)?

Translation quality assurance is the structured process used to prevent, detect, and validate translation quality across the production workflow, from the moment a brief is created to the moment content is signed off for delivery.

The value of TQA is precision at scale. A single translation project with a diligent reviewer can produce good work through effort and attention alone. A content programme spanning multiple markets, multiple translators, and multiple language pairs needs a system. One that produces consistent results regardless of who's working on any given project, and catches problems early enough to fix them cheaply. Within a broader translation services programme, TQA is the operational layer that makes that consistency possible.

Translation QA covers the linguistic quality of translated content: accuracy, consistency, fluency, and formatting. Localisation quality assurance goes further, adding cultural adaptation, functional testing, and market-specific validation to the mix.

Characteristics of high-quality translation

A good translation has to get five things right at once. Any one of them can break on its own. This is why a single-pass review rarely catches everything.

Take a SaaS company expanding into Germany and France. Their product has a feature called "Workspace." The German translator keeps it in English as it's a brand term. The French translator, working from a different brief, renders it as "espace de travail."

Both decisions are defensible. But now the same screen has two different names depending on which market you're in, and support teams in both markets are fielding tickets using different terminology.

‍

A structured TQA process deliberately checks all of these dimensions.

• Accuracy The translation faithfully conveys the meaning of the source: the words, but also the intent, nuance, and register. A subtle shift in meaning in a product description or a legal clause can mislead without any obvious error.
• Consistency The same terms, phrases, and brand vocabulary translate the same way across language pairs and over time. Without a shared glossary or term base, different translators working on the same project will make different choices, and those choices compound across a content library.
• Cultural fit The translation sounds right for the audience in that market. What reads as professional in one market can read as cold or overfamiliar in another. A translation that passes every technical check can still feel wrong to a native speaker.
• FluencyIt reads as if it were originally written in the target language. Fluency issues are often the most visible sign of a process gap, indicating that no native-speaker review took place.
• FormattingDates, currencies, measurement units, and layout conventions match the target market. These are easy to get wrong at scale and immediately visible to every reader.

How does the translation quality assurance process work?

The translation quality assurance process, sometimes referred to as translation quality management when applied across a full content programme, works as a three-layer system: prevention, detection, and validation. Each layer catches a different category of problem, and the earlier a problem is caught, the cheaper it is to fix. 

For example, Marley Spoon was localising campaign content across eight markets, with each cycle taking up to two weeks per market. Working with Contentoo, with QA built into the translation project management from the start, that came down to under one week.

Prevention

Prevention is the input layer. Everything the translator receives before work begins shapes the output: source content, style guide, glossary, brief, and domain context. 

Translation memory (TM) sits in this layer as one of the most consequential assets. TM stores previously approved translations at the segment level. When a similar source phrase appears in a new project, the approved translation is automatically surfaced, and the translator builds on material that has already been signed off. The longer a TM is in use, the more of each project is composed of pre-approved language. Terminology stays consistent, recurring phrasing stays on-brand, and correction volume drops accordingly.

Strong inputs across the board reduce the volume of work the detection and validation layers need to absorb.

For Swan, a Banking-as-a-Service company expanding across five European languages, getting this right from the start meant every translator had locked source content and a defined term base to work from.

Detection

Detection is the check layer. Automated tooling runs continuously during translation to catch rule-based errors at scale: terminology violations, formatting inconsistencies, and missing placeholders. A structured linguistic review by a second specialist captures what automated tools cannot: fluency, register, brand voice, and judgment calls that depend on context.

The same detection layer applies whether the translation is fully human or part of a Machine Translation Post-Editing (MTPE) workflow. ISO 18587 specifically governs MTPE quality, sitting alongside ISO 17100 when machine translation is in scope. Both require independent linguistic review as a core step.

Validation

Validation is the final confirmation step before handover. It checks accuracy against the source language, verifies formatting as it actually renders in the target environment (a layout issue invisible in a document can be obvious in a CMS), and reviews terminology consistency across the full delivery.

The last step is final sign-off from a named approver, identified before the project starts. Without a defined approver, review rounds drag on without resolution as content moves among stakeholders.

How do you build translation quality assurance into your workflow?

Building TQA into a translation workflow mostly comes down to designing the right inputs at the start of each project. The detection and validation layers can only catch what the prevention layer has set up to be caught, so most of the meaningful design work happens before translation begins.

• Lock source content before translation starts. Any change after briefing requires reprocessing downstream: re-translating affected segments, re-running checks, and re-collecting approvals. Source approval is a production gate.
  ‍
• Build a glossary or term base before the first project. A shared glossary defines how key terms translate across language pairs, so every translator on the programme works from the same reference point. Even twenty or thirty terms covering your most critical product and brand vocabulary makes a measurable difference to consistency from day one.
• Match translators to content type and domain. A translator who specialises in SaaS product content brings different expertise to a feature description than one who works primarily in retail or legal copy, even in the same language pair.
  ‍
• Configure automated checks before the first project runs. Define the rules: terminology, formatting, consistency flags, so they're in place from the start.
  ‍
• Define a single approver per language before the project starts. Approval processes with multiple stakeholders and no defined hierarchy produce revision cycles rather than sign-offs.
  ‍
• Build revision round limits into the brief. Two rounds is standard for a well-structured project. Consistent overruns signal an input gap: an incomplete brief or an underdeveloped glossary.

Meister's experience with Contentoo illustrates what this looks like in practice. By working with specialist freelancers who understood their content domain from the start, they removed the need for multiple revision rounds — reducing back-and-forth and speeding up delivery. The consistency came from getting the inputs right at the start of each project, which meant less correction work at the end.

Translation quality assurance checklist

A checklist is the most practical tool for ensuring TQA checkpoints are met consistently across projects. The distinction between what belongs at each stage — and how it differs from the broader scope of localisation work — becomes clearest when you see the checkpoints side by side.

These are the minimum requirements for a structured TQA process at each stage.

How do you measure translation quality?

The translation industry has two recognised scorecard frameworks for evaluating quality at the segment level: MQM (Multidimensional Quality Metrics) and DQF (Dynamic Quality Framework). Both classify errors by type and severity, producing a quality score per translation. They're useful when the question is "how good was this specific output?" They're less useful for a content team trying to identify which inputs in their process need fixing.

For most content programmes, the more actionable measures are operational ones: indicators that something upstream needs attention before it compounds across more projects.

• Revision round count per project Two rounds is the baseline for a well-run project. Consistent overruns on a specific language pair or content type point to something upstream: an incomplete brief, a glossary that needs updating, or a translator match that wasn't right for the domain. The round count tells you where in the process to look.
• Rework rate per language pair Tracking which language pairs generate the most corrections over time surfaces systemic issues faster than reviewing projects individually. A rising rework rate in a specific language is usually traceable to one of three things: a brief that's changed without updating the glossary, a style guide that hasn't been localised for that market, or a reviewer who isn't matched to the content type.
• Terminology compliance rate This tracks how many glossary violations make it past automated checks into linguistic review. A rising rate means the glossary isn't keeping pace with the content programme — new terms are appearing in source content that haven't been defined for each target language yet.
  ‍
• Time to final sign-off Tracked across projects, this shows where the process is creating delays — and whether those delays cluster around specific language pairs, content types, or approval stages. A pattern here points to a structural gap rather than a one-off.

Should you use automated checks or human review?

Automated checks and human review are complementary layers that catch different types of problems. Using one without the other leaves a category of errors unchecked.

What automated checks catch:

• Terminology violations against the glossary or term base
• Formatting issues: date formats, currency symbols, measurement units
• Consistency flags: the same source phrase translated differently across segments
• Mechanical errors: missing placeholders, tag inconsistencies, length restrictions

What human review catches:

• Whether the translation reads naturally for a native speaker
• Tone and register: Does it match the content type and intended audience?
• Brand voice: Does it sound like the client, in that market?
• Judgment calls that require context — cultural nuance, implied meaning, idiomatic accuracy

Domain expertise matters within human review. Legal content, technical documentation, and brand copy each require reviewers who understand the domain. The quality criteria vary by content type — what makes a judgment call right in regulatory copy isn't the same as what makes it right in brand copy.

The role of LLM-based tools

A more recent development is the use of large language models for first-pass translation evaluation. LLM-based QA tools can assign quality scores at the segment level, flag potential issues, and surface them for reviewer attention at scale — and they're increasingly being used as a layer between automated rule-based checks and full human linguistic review.

They're useful in a specific place in the process. LLMs catch problems that rule-based tools miss and do so faster than human review. But they also have their own blind spots: they can score a translation as fluent when it's off-brand, or miss a culturally inappropriate phrase that a native-speaker reviewer would flag immediately. LLM-based tools extend the detection layer. The human review step remains.

How does Contentoo handle translation QA?

Contentoo handles translation QA through a network of 3,500+ specialist freelancers across 40+ languages, matched to content domain and subject matter rather than language pair alone. Content goes through machine translation, specialist post-editing, and AI-assisted quality scoring before delivery.

Most QA problems don't start with the translation, though. They start earlier. A client runs their content through DeepL, hands over the output, and asks for post-editing on something a domain specialist would rather rewrite from scratch. That's a QA failure, but it happened before Contentoo touched the project.

It's a common pattern, and it's the one we're most focused on fixing. Contentoo's current translation offering prioritises speed and cost-efficiency: content comes in, machine translation runs, a specialist post-edits and delivers. For straightforward volume, it works. But it inherits whatever quality the upstream inputs carried in.

The shift we're making is taking more ownership of the full funnel. The direction we're building towards adds structured brief intake before machine translation runs, terminology assets that travel with the project, and AI-assisted quality scoring before human review, so the specialist isn't making judgment calls on content they've never seen in context.

The goal is the same consistency Contentoo applies to original content, applied to translation from brief to delivery. If that's the kind of translation programme you're trying to build, book a demo to talk through what it looks like in practice.

What breaks when translation quality management isn't in place?

Without structured TQA, four things break: terminology consistency, brand tone, formatting accuracy, and revision cycles. Each problem accumulates gradually and is typically only visible in aggregate, by which point it's already live.

• Terminology drifts across projects Without a shared glossary, different translators make different choices for the same source terms. The same product feature ends up with multiple names across languages, invisible project by project and only obvious when someone runs a content audit months later.
• Tone inconsistency that compounds Translators working from incomplete briefs make their own judgements about register and brand voice. A brand that reads as confident in English can read as blunt in one market and deferential in another, with no single decision to trace it back to.
• Errors that surface after publishing Wrong currency symbols, incorrect date formats, and mismatched units are often only caught once content is live. For Swan, expanding into five European languages with regulatory content meant accuracy was a compliance requirement. A post-publish error in that context carries compliance consequences.
• Revision spirals from upstream gaps When prevention and detection layers are missing, problems accumulate at the validation stage. Projects running to four or five rounds point to a never-completed brief, a never-built glossary, or a never-defined review structure.

Need a more reliable translation QA workflow?

Building a consistent TQA process takes the same inputs every time: a clear brief, a shared glossary, the right translator for the content domain, and a review structure with a defined approver. If you're managing translation across multiple markets and those inputs aren't consistently in place, the quality variation you're seeing is predictable — and fixable.

We work with content teams to build translation programmes that produce consistent quality at volume — whether that's five pieces across two languages or five hundred across thirty.

Book a demo

FAQs

What is the difference between translation QA and translation QC?

Translation QA (quality assurance) is process-oriented — it's the system built to produce consistent quality across the workflow. Translation QC (quality control) is product-oriented — it checks the finished output for errors. QA runs throughout production; QC happens at the end.

What does a translation QA process include?

A structured TQA process includes a prevention layer (locked source content, glossary, translator matching), a detection layer (automated checks and independent linguistic review), and a validation layer (accuracy, formatting, and terminology checks before sign-off).

How do you maintain translation quality across multiple translators?

Consistency across translators requires shared inputs: a term base or glossary that all translators work from, a style guide that defines tone and register for each target market, and a review process that consistently checks alignment against those standards — not based on individual reviewers' preferences.

Where does translation QA fit in the production process?

TQA runs across the entire production process. Prevention occurs before translation starts, detection occurs during translation, and validation occurs before handover.

How do you measure translation quality?

Two approaches work together. Scorecard frameworks like MQM and DQF assess individual translations at the segment level, classifying errors by type and severity. Operational metrics track process health across projects: revision round count, rework rate per language pair, terminology compliance rate, and time to final sign-off.

‍