


Automated localization QA with transglot

transglot team
Most localization bugs are not "the translation is wrong" in some subjective, hard-to-pin-down way. They are mechanical: a `{{count}}` placeholder that got dropped, a plural category that was never filled in for Arabic, a translated string that blows past the character budget on a mobile button, or a brand term that should never have been translated in the first place. Those are exactly the kind of thing you can catch automatically — before a translator or reviewer ever needs to look at the string, and definitely before your users do. That is what transglot's QA pass does.
A deterministic pre-gate, before any AI is involved
Every translation is checked against a set of free, structural rules first, with no AI call involved: does every placeholder in the source appear in the target (checked per plural form too), are all the plural categories a locale requires actually filled in, does the string respect a configured max length, and does it satisfy the same deterministic glossary/terminology check used during translation. A row that fails one of these is flagged immediately — there's no reason to spend an AI call scoring a translation that's already structurally broken.
- Placeholder integrity — every `{{token}}` / `%s` / `:param` in the source has a matching token in the target, checked per plural form.
- Plural completeness — every CLDR plural category a locale requires (not just singular/plural) is actually present.
- Max length — a translation does not exceed a configured character budget (useful for buttons, labels, and other tight UI space).
- Terminology — the same deterministic glossary check used at translation time, re-run against what actually got saved.
The AI review pass, for what only a fluent reader can catch
Rows that pass the structural pre-gate move to a batched AI review pass that scores each translation from 0–100 against an MQM-style rubric — the same style of framework professional linguists use for quality evaluation — and returns specific findings tagged by category: accuracy, fluency, terminology, style, placeholder, plural, or length. A translation is marked as needing review automatically when it scores below a configurable threshold (70 by default) or when any single finding is major or worse — so a reviewer opens the editor to a prioritized list instead of skimming every row hoping to notice what is wrong.
{
"qa_score": 62,
"needs_review": true,
"qa_findings": [
{
"category": "terminology",
"severity": "major",
"message": "Brand term \"Acme Cloud\" was translated instead of kept verbatim.",
"suggestion": "Acme Cloud"
}
]
}Re-running QA does not mean re-checking everything
QA is incremental by design. A row is skipped on re-run when its source has not changed since it was last checked, so QA-ing an already-clean project after a small content update costs nothing for the rows that were not touched. You can scope a run to whatever is missing a QA score, whatever has gone stale because its source text moved, a specific selection, or the whole project — the same scoping shape used elsewhere in the platform (missing / selected / stale / all), run through the API or the web UI.
Self-heal: suggest by default, never touch a human edit
Finding a problem and fixing it are different levels of trust, so transglot treats them as an explicit, per-project setting. In `suggest` mode (the default), a QA-flagged machine translation gets one candidate fix generated automatically; if that candidate passes every deterministic validator, it's attached to the finding as a suggestion for a human to accept — no translation value is written automatically. In `apply` mode, transglot goes a step further: it re-translates the failing row (bounded to a small number of retries), validates the result deterministically, and if it passes, writes it as the new value with a full revertible version snapshot, authored distinctly as an autoheal edit rather than a human one. Either mode can also simply be turned off.
Where the numbers come from, and what they cost
QA and self-heal are Team-plan features, since the semantic review pass is a real Claude call — it uses the same quota-metered, batched-per-chunk model as translation itself (about 30 rows per chunk), and a chunk that's already been retried never gets re-scored or re-metered by a retry of the same delivery. The deterministic pre-gate — placeholders, plurals, length, terminology — is free and runs on every plan tier that has QA enabled; only the AI semantic pass consumes quota.
What this replaces
Before automated QA, catching this class of bug meant a human reviewer reading every string in every locale, or — more realistically — not catching it until a user reported a broken button label in production. A deterministic pre-gate plus a scoped AI review pass does not replace human review for anything customer-facing and high-stakes, but it turns "hope someone notices" into a repeatable check that runs the same way every time, on exactly the rows that changed.
Related articles
More guides on localization workflows, terminology, and translation QA.
