Localization QA tools run a family of mechanical, rule-based checks that compare each source segment with its translation. The core ones are: UNTRANSLATED (the target is empty, or identical to a non-trivial source); PLACEHOLDER / TAG / VARIABLE mismatch — every {0}, {name}, {{var}}, %s, %d, %1$s, $1, <b></b>, [x] and &entity; in the source must appear unchanged in the translation, because a missing or altered placeholder breaks the build or shows a raw token to the user; NUMBER mismatch — the digits in the source should appear in the translation; TERMINOLOGY / GLOSSARY consistency — an approved term must always be translated the same way; CONSISTENCY — the same source segment should get the same translation; ending-PUNCTUATION mismatch; WHITESPACE (double spaces, leading / trailing); REPEATED words; and LENGTH ratio (possible truncation or over-translation). AnyTool’s Translation QA Sheet runs all of these deterministically, tags each with error / warning / info severity, and exports a CSV or Markdown report.

The tool is deliberately honest about its scope. It compares source and target with deterministic string rules to find mechanical defects — a missing placeholder, a number that vanished, an untranslated line, an inconsistent term, a stray double space, a wildly different length. It has no understanding of meaning: it cannot tell whether the words chosen are accurate, natural, grammatical, well-toned or culturally appropriate, and a segment can pass every mechanical check while being a completely wrong translation. Some flags are also legitimate false positives — a number correctly re-localized (1,000 → 1.000), an idiom, an intentional length change, a language whose punctuation rules differ. So a clean result is not a quality verdict; it means no mechanical defect was found in the checks that ran. Always follow it with a human / native-speaker review.

There are two input modes. In two-block mode you paste the source text in one box and the translation in the other, one segment per line, aligned 1:1; the tool pairs line 1 with line 1, line 2 with line 2, and so on. In 2-column mode you paste one segment per line as source, a TAB (or a “ | ”), then the translation — which is exactly what you get when you copy two columns out of Excel, Google Sheets or a CSV. You can also supply an optional glossary, one pair per line as “source term = required target term” (also “=>”, “:” or TAB), and the glossary check flags any segment whose source contains the term but whose target is missing the required translation. You can toggle individual checks on or off, then export the flagged report as CSV or Markdown.

Everything happens locally with deterministic string and regex matching — there is no AI or LLM, no server and no network call. The source and translation you paste are analysed on your device and never sent anywhere, logged or stored, no account or email is required, and the page works offline once cached. That is unlike cloud QA tools and many online “translation checker” sites, which send your strings to a server before returning a result — a problem when the text is a pre-launch app, an unreleased product, a contract or other confidential material. Because the tool is rule-based and mechanical, it is also explicit that you must still have a human review the translation for meaning and quality.