Localisation test cases, past are the strings translated

The assumption behind most localisation work is that it is a translation problem, and the string catalogue is the easy part. Layout is where it first goes visibly wrong: several languages expand text substantially, so buttons, tabs, navigation and table headers designed around English labels clip, overlap or push actions off screen. That is testable by switching language and looking, and it is frequently deferred until after launch because the English build looks finished.

The structural problem is concatenation. A message assembled from a count, a noun and a date in code cannot be translated correctly into any language whose word order differs, and no translator can fix it because they never see the whole sentence. Full sentences as single translatable strings with placeholders are the only workable form. Plural rules sit alongside it: a singular and plural pair covers English and is wrong for languages with three or more forms, so a count of two, five and twenty one need distinct cases.

Numbers and dates are where a localisation defect stops being cosmetic and starts changing meaning. A decimal comma parsed as a thousands separator alters a value by a factor of a thousand, silently, with a result that looks entirely plausible in the record. A date typed day first and interpreted month first produces a different day, which on a contract, a booking or a claim is consequential. Both are fixed by parsing with the user locale and echoing the interpreted value back unambiguously before it is saved. The related trap is currency: switching language must never change the amount or the currency, because language is not a currency selector.

Finally, the data layer needs its own attention. Sorting by byte order rather than locale collation groups every accented name after every unaccented one, which looks broken to anyone whose name has an accent. Accent sensitive search silently returns nothing and reads to the user as missing data rather than as a search limitation. Names, addresses and phone numbers vary far more than a single field set allows, and rejecting a valid address because the country has no postcode is a hard blocker. And encoding needs verifying at every hop, since a character that survives the interface and the API can still arrive as a replacement character in an export or an email.