Localization testing checklist

The localization testing checklist scores a locale build from the defects the locale pass actually found rather than from a feeling that the German build looked fine: the strings in the release, the locales in the build, the strings that shipped untranslated, the strings that truncated or overflowed on screen, the hardcoded text the pseudo-locale exposed, and the plural, date, number and currency format failures, against the number of defects per locale the team allows a release to ship with. It returns the locale checks in the build, the defects found across every locale and per locale, the defect rate per thousand checks, the share of checks that passed, the catalog gap the pseudo-locale proved, how far over the ship threshold the build is and the defects over the release's allowance to fix before it ships. It is the checklist every localisation engineer keeps in a spreadsheet, with the arithmetic written down.

Why the checklist counts checks, not strings

A release of three thousand strings in six locales is eighteen thousand locale checks, and a defect rate only means something against that denominator. Twelve truncated strings is a bad Japanese build and a rounding error across six locales, and the checklist keeps both readings on the page: the defects per locale on average, which is what the ship threshold is set against, and the rate per thousand checks, which is what lets this release be compared with the last one and a small product with a large one.

Pseudo-localisation finds the strings that are not in the catalog

Switching on a pseudo-locale, one that pads and accents every catalog string, does two jobs at once: it shows which strings will truncate when a real language runs longer than English, and it shows which text did not change, which is text that is hardcoded and not in the catalog at all. That second count is the catalog gap, and the checklist reports it on its own because it is not a translation defect, it is a key that does not exist yet. Xlifflane Pro keeps the catalog, so a hardcoded string found by the pseudo-locale becomes a key with a status rather than a bug nobody owns.

The ship threshold is the team's number, and the sheet holds it to it

Every team ships with some known locale defects, and the honest position is to say how many per locale rather than to pretend the number is zero. Dividing the defects found by the locales and reading it against the threshold gives how far over the build is, and multiplying the threshold by the locales gives the defects the release may carry, so the fixes owed before ship is a count the release manager can plan, not an argument. A build under the threshold ships; one over it does not, and the checklist says which by how much.