Localizability testing is the first step in software localization process. It verifies that the user interface of the program being tested can be easily translated to any target language without re-engineering or making code modifications. Localizability testing is of extreme importance because missed errors might cause significant problems in the successive stages. Since localizability bugs have to be fixed in the application source code, they must be looked for at the earliest stage of development possible. By doing so, you can avoid having to fix bugs for every language version at a later point.
During localizability testing you should check that your software meets the following requirements:
Resources are separated from the code
All resources, that should be translated, must be separated from the code. By doing so, you can avoid having to send your source code to translator.
Only locale-sensitive functions
All text manipulations and parsing - such as finding string length, locating substrings, changing text case, and so on - have to be done using locale-sensitive and encoding-sensitive library routines. Most ANSI centric routines work incorrectly with Asian languages.
No string concatenations
Strings are not calculated at run time by stripping or concatenation, because it is impossible to translate the whole phrase. String substitution have to be done via language-aware APIs such as FormatMessage or _stprintf.
No assumptions about string length
Do not make assumptions about string buffer length if it is loaded from resources. For example, you should not use fixed length buffer of 10 characters for month name, just because the longest month name in English "September" takes 9 characters. Since English is one of the most compact languages, translation is likely to increase this length, so the localized name might not fit into the buffer.
Careful runtime positioning
Avoid where possible positioning user interface controls at a run time, because localized application may use different fonts and display other content. All layout algorithms should be carefully checked.
No assumptions exist on drive and folder names
The names of the system folders are usually translated; the same can apply to the names of other objects defined by the operating system and applications your code interacts with. Folder names, names of built-in accounts, and other localizable elements of the operating system can and should be queried at run time using Windows API functions such as SHGetFolderPath.
How to Test
There are two ways to ensure localizability requirements. The first is to review all source code. It can be done only by highly qualified professional who reviews all the code and checks that every string operation and constant meets localizability requirements.
Another way is to test application after pseudo-localizing its interface. Pseudo-localization is the most effective way to find localizability problems before translation of the program's UI is started. Pseudo-localization gives you a translation without the cost of an actual localization. This approach doesn’t require any profound technical or localization skills and thus it can be done by an average tester.
The common pseudo-translation techniques are:
- Replace English characters with accented one: a -> å, c -> ç, n -> ñ, etc. This will keep the text readable, and non-modified text will catch your attention.
- Replace English characters with Asian symbols. This will help you to test how your application deals with two-byte characters, encoding and locale. This will make finding places where the program utilizes ANSI functions to process or display text.
- Add extra characters to your resource strings. In many cases translated text is longer then the English original the length will also increase. English is one of the most compact languages: what is usually depicted as “OK” in English becomes “Aceptado” in Spanish, for example.
- Mark the beginning and the end of each resource string. Having those markers, you’ll easily see when text is built at run-time – potential source of localizability bugs. (Some text -> #Some text$).
Once you pseudo-localize your program, test its functionality. Pseudo–localized applications should function no differently than its original US version, but thanks to readability of pseudo-localized text it is very easy to recognize potential problems.
The easiest way to perform pseudo-localization is to modify the program’s resources automatically. There are several tools that simplify this process. One of them is pseudoLocalizer (http://www.codeproject.com/csharp/ploc.asp) – free tool, that pseudo-translates input text. The major drawback is that if you use pseudoLocalizer with Visual Studio projects (MFC/.NET) you have to manually replace text in every resource element. It takes a lot of time and patience to do.
Another option is to use software localization tool such as Lingobit Localizer. Lingobit Localizer automatically extracts all resources from application executable file and pseudo-localizes all the strings. Then Lingobit creates pseudo-localized application for you to test. Even thought Lingobit Localizer is commercial, you do not need to buy it to do localizability testing – trial limitations do not affect pseudo-localization features.