You Are Not Done Yet: Localization

International sufficiency testing is important for just about any application, but localization testing kinda only matters if you are localizing your application into other languages. The distinction can be hard to remember, but it's really quite simple: international sufficiency testing verifies that your application does not have any locale-specific assumptions (like expecting the decimal separator to be a decimal point), whereas localization testing verifies your application can be localized into different languages. Although similar the two are completely orthogonal.

The simplest way to get started localization testing is with a pseudo-localized (aka pseudoloc) build. A pseudoloc build takes your native language build and pseudo-localizes it by adding interesting stuff to the beginning and end of each localized string (where "interesting stuff" is determined by the languages to which your product will be translated, but might include e.g. double-byte or right-to-left characters). This process vastly simplifies your localization testing:

• It allows every build to be localized via an automated process, which is vastly faster and cheaper than is the case when a human hand localizes.
• It allows people who may not read a foreign language to test localized builds.
• Strings that should be localized but are not are immediately obvious as they don't have extra characters pre- and post-pended.
• Strings that should not be localized but in fact are do have extra characters pre- and post-pended and thus are also immediately obvious.
• Double-byte bugs are more easily found.
• UI problems such as truncated strings and layout issues become highly noticeable.

If you can, treat pseudoloc as your primary language and do most of your testing on pseudoloc'd builds. This lets you combine loc testing and functionality testing into one. Testing on actual localized builds - functionality testing as well as localization test - is still important but should be trivial. If you do find major localization bugs on a localized build, find a way to move that discovery into your pseudoloc testing next time!

Beyond all that, there are a few specific items to keep in mind as you test (hopefully pseudo-)localized builds:

• Verify each control throughout your user interface (don't forget all those dialog boxes!) is aligned correctly and sized correctly. Common bugs here are auto-sizing controls moving out of alignment with each other, and non-auto-sizing controls truncating their contents.
• Verify all data is ordered/sorted correctly.
• Verify tab order is correct. (No, this shouldn't be affected by the localization process. But weirder things have happened.)
• Verify all strings that should have been localized were. A should-have-been-localized-but-was-not string is likely hard-coded.
• Verify no strings that should not have been localized were.
• Verify all accelerator key sequences were localized.
• Verify each accelerator key sequence is unique.
• Verify all hot key combination were localized.
• Verify each hot key combination is unique.

Posted by The Braidy Tester at 07:30 AM  Permalink