AI translation QA should verify that the business meaning survived the rewrite. A translated page can read naturally while changing a price, omitting a condition or breaking a booking link, and fluent output gives a reviewer less reason to look twice. Let the agent improve the language, but treat commercial facts and functional elements as a separate acceptance contract that fluency cannot satisfy.
Specify which facts must stay fixed and which presentation choices may adapt to the locale. A decimal separator can change while the approved amount and currency stay the same; a date can be reordered while the day it names does not move. This playbook sets out the contract, the checks that can be automated, the review a person still has to do, and the failure modes that make translated marketing content a liability rather than an asset.
- 01Separate meaning from presentation.Local formatting can change while the approved price, condition or destination remains fixed. Write down which is which before the agent starts.
- 02Protect functional text.Placeholders, identifiers and links need explicit, deterministic checks rather than a fluency review. A reviewer reading for naturalness will not notice a changed route.
- 03Review the rendered result.A correct translation can still overflow, lose context or send a user to the wrong language page. Strings in a spreadsheet are not the product.
- 04Release by meaning, not by diff.Classify every change as language-only, approved adaptation or unresolved meaning change. Only the third category needs the offer owner.
01 — The ContractWrite the invariants before the translation
Create a short source-of-truth record alongside the content. It should identify approved amounts, currencies, dates, product names, conditions and target destinations. Specify which terms must remain unchanged and which should use an approved local equivalent. The agent should not infer a new offer while making the language sound natural, and it cannot know which words are the offer unless someone tells it.
W3C’s distinction between localization and internationalization explains that localization includes adapting content to a target locale and can extend beyond language. That supports an important boundary: translating the words and deciding the local commercial offer are separate tasks. The first is the agent’s job. The second is a business decision that happens before the brief, and the invariants record is where that decision is written down.
The table is the contract in its smallest useful form. The middle column is what the agent is free to change; the right column is the check that proves the meaning survived. Most of the right column can be tested without reading the target language; the offer-condition row needs a reviewer who can.
| Element | Allowed adaptation | Required check |
|---|---|---|
| Price | Locale-specific number formatting | Same approved amount and currency; no implicit conversion |
| Date | Unambiguous local presentation | Same underlying date and specified time zone |
| Offer condition | Natural grammar | Eligibility, exclusions and duration preserved |
| Placeholder | Surrounding language | Identifier and substitution syntax remain intact |
| Product name | Approved localized name | Consistent with the glossary |
| Link | Approved local destination | Correct route, language and action |
| Button | Natural action wording | Describes the action the interface performs |
| Measurement | Approved unit presentation | Conversion happens only under an explicit rule |
02 — The BoundaryMeaning versus presentation
The reason the contract works is that every row splits into two layers. Presentation is how a value is written: separators, order, unit symbols, grammatical case. Meaning is the value itself: the amount, the day, the condition, the destination. A translation agent can handle the first layer well and has no authority over the second, and the failure mode is that the two layers are mixed together in a single string where the agent cannot tell which characters it may touch.
An illustrative case: the source says “from €1,299 for the first three months”. A fluent target-language rendering might reorder the sentence, swap the separator, and move the currency symbol. All of that is presentation and all of it is allowed. If the rendering says “€1.299 per month” the amount has not changed but the condition has, and the page now describes an offer the business did not make. The contract’s “offer condition” row exists for that sentence.
Presentation
Word order, separators, unit symbols, grammatical agreement, register. Change it to read naturally in the target locale. Nothing here needs sign-off.
Meaning
Amounts, currencies, dates, eligibility, exclusions, duration, destinations, identifiers. Change any of these only under an explicit rule in the invariants record.
Ambiguity
A source date that could be read two ways, a product term used inconsistently. The agent flags it and stops; the offer owner decides. A guess here is a new offer.
03 — The ReviewerFluency is one review, not the final review
The MEGA multilingual evaluation paper examines generative models across languages and tasks. Use target-language acceptance examples; historical English-focused results cannot approve a different language workflow. A model that is strong on English benchmarks has told you little about how it handles conditional clauses in Polish, and the paper reports particular difficulty with low-resource languages.
Ask a qualified language reviewer to assess whether the text sounds natural and whether the intended meaning is preserved. Give them the source, glossary and commercial constraints. Without those inputs, a reviewer can improve the prose while missing that the offer itself changed; they are reading for the wrong thing because nobody told them what the right thing was.
Back-translation can flag suspicious differences, but it is not proof of equivalence. A second pass may reproduce the same ambiguity or normalize away the error. Use it to prioritize review, then compare the relevant phrase with the approved meaning.
A source says delivery is available in selected areas. A fluent rewrite that promises delivery everywhere has changed the offer. The error belongs in the acceptance check even if the sentence sounds excellent, and a reviewer briefed only on fluency will approve it.
04 — The ChecksMake the deterministic checks explicit
Extract the functional elements before generation and compare them afterward. Check that every required placeholder is present with the same identifier, that no extra placeholder appeared, and that each link maps to an approved destination. Separate display text from identifiers so the model can rewrite one without touching the other; a template that interleaves the two is asking the agent to do a parsing job it was not given.
Compare amounts, currencies and dates as structured values so legitimate formatting changes do not mask a changed offer. “1.299,00 €” and “€1,299.00” are the same value and should pass; “€1,299” and “€1,299 per month” share every digit and should fail, because the comparison is of meaning, not characters.
Have the agent return unresolved decisions in a separate note. If the source contains an ambiguous date or inconsistent product term, the system should not silently pick one. Route the question to the owner of the offer or glossary before the localized version is released. The boundary between checking and asking is covered in our agent clarification rubric. The broader model-selection tradeoffs appear in the translation-model reference. Neither replaces target-language acceptance examples.
05 — The PageInspect the page in the target language
W3C’s internationalization quick tips recommend practices such as identifying content language, handling direction and accommodating translated text. Those are reasons to inspect the actual page after translation, rather than approving a document of strings in isolation. The strings can all be right and the page still wrong.
Check navigation, buttons, form hints and error states at the supported viewport sizes. Longer text can reveal a fixed-height component. A translated button may wrap in a way that obscures the action. A correct paragraph can be separated from the condition it qualifies, so that the price sits above the fold and the “selected areas only” sits below it. Treat these as product defects, not as reasons to force unnaturally short language.
Our browser-versus-API reference explains why structured content validation and rendered-page validation need different evidence. For language work, both belong in the delivery contract: the first proves the values, the second proves the reader will see them together.
06 — The FailuresThe failures that read beautifully
Translation errors that look like errors tend to get caught. The ones that matter commercially are the ones that look like good writing. Four illustrative patterns, each of which passes a fluency review and fails the contract.
The softened condition: “subject to availability” becomes a phrase that in the target language reads as a courtesy rather than a limitation, and the exclusion has quietly left the offer. The helpful conversion: a model “improves” a price by converting it to the local currency at a rate it invented, producing a number nobody approved. The confident date: a source written “03/04” is rendered as a specific day in the target locale, resolving an ambiguity the source never resolved. The repaired link: a URL path with a typo in the source is “corrected” to a path that does not exist, or to the English page.
None of these is detectable by reading the target text alone, which is why the contract puts the checks on values and routes rather than on prose. A language reviewer with the source and the glossary in front of them will catch the first; the structured checks are what reliably catch the other three.
Each failure is the agent being helpful one layer too deep. It was asked to make the words natural and it also made the facts tidier. The contract’s job is to make “tidier” impossible for the elements where tidier means different.
07 — The ReleaseRelease by changed meaning, not just changed strings
Give the reviewer a concise diff with three categories: language-only edits, approved local adaptations and unresolved meaning changes. This is more useful than asking them to inspect every character equally, because it tells them where their judgment is needed and where a machine has already done the work. Keep the original source revision attached so later edits can be traced to the right version.
If the source offer changes, invalidate the dependent translations rather than leaving them to drift. A change to a condition may matter more than a headline rewrite. The agent can identify affected passages, but the release record should show which languages were updated and which remain pending, and the same discipline that governs a changed fact in one language governs it across all of them; our guide to updating facts without losing context describes the revision map that makes this traceable. Marketing teams that want the contract and the checks built into their localization workflow can do that with our AI transformation practice.
08 — DecisionA fluent page is a hypothesis, not a release
Let the language adapt while the approved meaning stays intact.
Create the invariants first, test the functional elements and review the actual target-language journey. That gives a marketing team a practical way to use agents without turning fluent copy into an unreviewed change to the business offer.
For implementation support, explore our AI transformation services.