Blog details
Blog details

Automated localization QA with transglot

transglot team

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"
    }
  ]
}
A representative QA finding on one translation row

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.

A human edit is never touched — this is a hard safety gate
Any row a human has already edited or explicitly reviewed is completely off-limits to self-heal, enforced at the database level with a lock-and-recheck compare-and-swap, not just an application-level check. However confident the automated fix is, a human decision on that row always wins.

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.

Share this post

transglot team

transglot team

EngineeringTerminology & QA

Related articles

More guides on localization workflows, terminology, and translation QA.

globe
Get started

Stop hand-editing locale files. Start shipping in every language.

Claude-powered translation, an in-context editor, a glossary and QA workflow, and a CLI, GitHub Action, and REST API — open source, MIT licensed, and self-hostable.