Localisation fails at the schedule far more often than at the language. The work is not hard; it is simply started too late, after every decision that constrains it has already been made.
Weeks twelve to ten: decide scope and freeze terminology
Choose the markets, and be honest about which are real. Build or update the glossary now, while the product team is still willing to argue about what things are called. Terminology settled at this stage costs an afternoon; settled in week three it costs a rewrite.
Weeks ten to eight: prepare the source
Most localisation problems are source problems. Strip concatenated strings, remove text baked into images, check that your date, number and currency formatting is not hard-coded, and give every UI string a context note. A translator working from a spreadsheet of disembodied fragments will guess, and roughly one guess in ten will be wrong in a way you notice only after launch.
Weeks eight to five: translate and review
Run translation in parallel across languages rather than sequentially, but hold one language slightly ahead as a pilot. Problems found in the pilot are fixed once; problems found in all languages simultaneously are fixed everywhere.
Weeks five to three: in-context review
This is the step teams cut when they are late, and it is the one that catches the errors users see. Put the translated strings in the actual interface and have a native speaker use it. Truncation, overlapping labels, text that runs off a button and sentences that made sense in isolation but not in place all surface here and nowhere earlier.
Weeks three to one: local legal and support readiness
Confirm that legal text has been reviewed for the market rather than translated for it, and that support has the material and the language coverage to answer the first week’s questions. A launch that goes live with no local support is a launch that generates complaints in a language nobody on the rota reads.
Leave a Reply