What a string-level quality gate caught in a 26-language UI pack
I shipped a 26-language UI pack for a desktop app this week, 60,375 entries, and put three checks in front of every commit. Sharing what they actually caught, because the failures were not the ones I expected.
Placeholder parity. Every marker such as {name} in the English source has to appear the same number of times in the translation. This caught dropped and duplicated markers, and one case where a marker had been transcribed into a lookalike alphabet.
Product and protocol names stay untranslated. Model names, protocol names, file names. A glossary pins them and the check compares against it. This caught the most errors by far: strings that read fluently but renamed the product.
Character-system check. A translated string has to carry characters of its own writing system. A value that differs from the English source but is written only in Latin gets flagged, since a real Greek or Korean translation is written in Greek or Korean. That is what catches romanised words standing in for real translations: a string that reads as translated is sometimes just a transliteration.
What did not work was automated fluency scoring. It flagged style differences and missed real errors, so it is a triage signal rather than a gate.
Untranslated strings fall back to English instead of breaking the screen, so a language ships in a mixed state rather than a broken one. What that buys is publishability, not verified quality. The checks above confirm strings are well formed; they say nothing about whether a native speaker finds them good, and most of these languages have not had that review.
The pack is MIT if it is useful to anyone here.
git clone https://github.com/sayho-pm/dsh-locale-pack.git