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/:paramin 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.
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.
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 Glossa 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.
