Localization Project Management Log

I always regret having to pseudo-translate, because it involves an extra step, annoys the engineers, and generally slows things down. BUT, whenever I don’t pseudo-translate, I regret it even more.

Earlier posts discuss the process in greater detail, and I do it to try to flush out ugly problems when time is cheap, rather than when it gets expensive. On most projects, I won’t start translation until after pseudo-translation and testing.

In short, pseudo-translation and internationalization testing help you find all of the incorrect assumptions the developers had when they created the software, for example:

• “English is the only language this app will have to process.” This assumption becomes obvious when multibyte characters from Asian languages – or even just accented characters from Latin-based languages – are corrupted. To clean this up properly, you need to examine not only the code that renders text on screen, but also the code that processes characters entered by users.
• “Dates should always be formatted mm/dd/yy, and the period is the decimal separator.” All modern operating systems and browsers now handle this for you, so don’t bother writing it yourself. Use the common resources in the OS or browser.
• “Many of our error messages begin with the same five words, so we’ll append the rest of the message at run time to keep our code trimmed down.” This is sure to disrupt sentence structure, especially in Asian languages. The engineers will have to fix it and put up with less-trim code, but the localization process will appreciate the improvement.
• “We’ll never localize this message. I’ll leave it in the source code.” Pseudo-translation and testing finds these instances immediately, and the engineer needs to comb the string out of the code and into the translatable resources.

So take the extra step of pseudo-translating, especially if you’re starting a software or Web project that involves an architecture in which you’ve never localized before: C# and Ajax come to mind, since many engineering teams are still cutting their teeth on these, after years of C++, HTML and Java.

Remember: Internationalization is only going to be of interest to engineers once – the first time – so you should get as much out of it as you can that first time.