Localization testing tools check a locale build for the four things that go wrong when a product is localized, strings that stayed in the source language, strings that truncate or overflow, text that was hardcoded and never reached the catalog, and plurals, dates, numbers or currencies that render wrong for the locale, and localization quality assurance is the discipline of counting them against a ship threshold every build. Software localization testing splits into what a tool can run automatically, the pseudo-locale build and the placeholder and plural checks, and what a person has to do, the linguistic testing that reads each locale for meaning. This page sets out what the tools check, what localization automation testing covers, and how the defects are counted so the ship decision is a reading rather than a feeling.
What a tool can check without a person
A pseudo-locale build, which pads and accents every catalog string, proves in one run which strings truncate when a language runs longer and which text never changed because it is hardcoded. A placeholder check proves every variable in the source survives in each translation. A plural check proves every plural category the locale needs has a form. A format check renders a date, a number and a currency per locale and compares them with the locale data. Localization automation testing is those four, run with every build of the product, and each one counted is a defect the checklist on this site scores.
What a person has to check
Linguistic testing is a reviewer who knows the locale reading the build: does the translation mean what the source meant, is the terminology the product's, is the tone right for the screen, does the string make sense where it appears. No tool does that, and a team without a reviewer in a locale is shipping that locale untested whatever the automation says. The reviewer's findings are counted with the rest, usually as untranslated or format defects, so the per-locale figure carries both halves of the localization quality assurance.
Counting the defects so the ship decision is a reading
A defect count only means something against the number of locale checks, strings times locales, and against the threshold the team allows per locale. The localization testing checklist on this site takes the four counts and the threshold and returns the defects per locale, the rate per thousand checks, the pass share, the catalog gap the pseudo-locale proved and the fixes owed before the build ships, with no account. Software localization testing done that way every build gives a trend; done before a release gives a verdict. Xlifflane Pro keeps the results against the locale and the release.
Questions people ask about localization testing tools
Which localization testing tools does a small team need?
A pseudo-locale build, which most platforms provide, a placeholder and plural validator on the read-back, and a reviewer per locale. The counting is arithmetic, and the checklist on this site does it.
Is linguistic testing the same as localization QA?
Linguistic testing is one half of localization quality assurance, the human read; the other half is the build checks a tool runs. Both are counted against the same threshold.
How often should localization automation testing run?
With every build of the product if the team runs continuous localization, and before every release otherwise. The pseudo-locale build in particular is cheap enough to run on every merge and catches the hardcoded string the day it is written.
Sources
- Microsoft Learn, Pseudolocalization: padding and accenting catalog strings to expose truncation and hardcoded text
- Unicode CLDR, Plural Rules: the plural categories each language distinguishes
- ICU User Guide, Formatting Messages: MessageFormat, the syntax for plurals, selects and placeholders inside a localised string