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. Let the agent improve the language, but treat commercial facts and functional elements as a separate acceptance contract.
The practical approach is to define what must remain invariant and what may adapt to the locale. Invariant means the underlying fact stays the same, even if its presentation changes. A decimal separator may change; the amount should not change unless the brief explicitly calls for conversion. This article proposes a review workflow rather than ranking translation models.
- 01Separate meaning from presentation.Local formatting can change while the approved price, condition or destination remains fixed.
- 02Protect functional text.Placeholders, identifiers and links need explicit checks rather than a fluency review.
- 03Review the rendered result.A correct translation can still overflow, lose context or send a user to the wrong language page.
01 — Write the invariants before the translationWrite 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.
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.
| 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 — Fluency is one review, not the final reviewFluency is one review, not the final review
The MEGA multilingual evaluation paper examines generative models across languages and tasks, challenging the assumption that English-focused evaluation describes multilingual capability. We do not use its historical model results as a current ranking. The practical implication is to test the actual target language and task instead of approving a workflow on English examples alone.
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.
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.
03 — Make the deterministic checks explicitMake 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.
Numbers require semantic checks. A simple string comparison may reject legitimate formatting differences or miss a changed currency. Normalize the approved amount, currency and date into structured fields, then compare meaning rather than punctuation. Keep examples in the brief so the expected treatment is unambiguous.
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.
04 — Inspect the page in the target languageInspect the page in the target language
W3C’s internationalization quick tips recommends 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.
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. Treat these as product defects, not as reasons to force unnaturally short language.
Verify the user’s destination. A localized call to action that lands on a different offer is a broken promise even if both pages are individually correct. Where the destination is intentionally in another language, make that transition understandable to the reader.
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.
05 — Release by changed meaning, not just changed stringsRelease 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. 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.
For a first rollout, choose a representative page with both prose and a real interaction. Test the checks before scaling to the archive. The valuable result is a repeatable acceptance process, not an unsupported claim that a particular model eliminates the need for review.
06 — DecisionWhat to do next
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.