Localization QA
A tool that checks translated product copy in seven languages against our rules and guidelines before it ships. Built with Claude Code. Useful for the whole team.
Overview
Every batch of product copy is translated into six languages and merged into the product. Localization QA checks that batch before the merge.
It looks for missing translations, broken placeholders, punctuation and spacing, numbers and dates, length, plurals and glossary terms, against our rules and guidelines. It never changes anything. It suggests a fix, explains why, links the glossary entry, and leaves the decision to the person running it.
Context
Checking many languages against very specific rules and guidelines was something we needed all the time. Translation happens in Lokalise, one batch at a time, and nothing checked a batch before it merged. So mistakes were found late, or not at all. I built Localization QA as a web app inside Qonto's internal tools.
My role
I built it alone, in two weeks. Then I applied the feedback from all the content designers who used it, and from the people who own each language.
The content challenge
The hard part was deciding what counts as wrong. Writing a check is easy. Knowing what it should flag is the real work, and it is where a content designer earns a place on a project like this. I kept having to decide things about languages I do not speak.
Better to miss something than to raise a false alarm.
Five decisions shaped the tool. First, it checks a branch, not the whole project: a full scan gave thousands of findings nobody would read, and limited to the keys you touched, the same checks give 86 findings in about four seconds. Second, the rules live in simple files, not in the code. I got percent-sign spacing wrong twice, in opposite directions, and the people who own those languages caught it both times. Now a correction is a one-line change made by the person who knows.
Third, a false alarm costs the tool its credibility, and if someone acts on it, it makes good copy worse. Fourth, when it breaks, it breaks loudly: a crash is honest, while a believable report of the wrong thing gets acted on. Fifth, it says what it cannot decide. The German glossary says "Kund:in" and the shipped product says "Kunde", across 148 strings. The tool can count that disagreement exactly, but it cannot tell which side is wrong. That call belongs to whoever owns German. For deliberate rewrites, there is a "Rewritten copy" button instead of a clever guess.
How I used AI
Claude built all of it. It was pure vibe coding: I gave the direction, Claude wrote the code, and I applied the feedback from the content designers and the language owners. The checks are plain rules in code, not AI judging the copy, and a person makes the decision on every finding.
Outcome
It cuts the time it takes to check translations in a tool like Lokalise. Whole project, 15,226 keys: 7,633 findings in about 90 seconds. Branch plus feature tag, 226 keys: 86 findings in 4 seconds.
It reduces the chance of mistakes, and so the cost of fixing them later. Problems are caught before the merge, not after they ship.
It lets the whole team run an extra check after the localization specialists have done their work. The specialists still own the languages; the tool gives everyone a second pair of eyes.
10 categories of checks across 7 languages, 647 tests. The language owners now look after the rules, not me.
A tool that admits what it cannot know earns more trust than any check I added.
A tool nobody can open gets no feedback, and feedback from the people who own the languages is the only thing that made the checks right.