Information
The topic you requested is included in another documentation set. For convenience, it's displayed below. Choose Switch to see the topic in its original location.

Localizability Testing

Visual Studio .NET 2003

Localizability testing verifies that you can easily translate the user interface of the program to any target language without re-engineering or modifying code. Localizability testing catches bugs normally found during product localization, so localization of the program is required to complete this test. As such, localizability testing is essentially a hybrid of globalization testing and localization testing. Successful completion of localizability testing indicates that the product is ready for localization. You can use pseudo-localization to avoid the time and expense of true localization. Pseudo-localization is perhaps the most cost-effective way of finding localizability bugs and is performed as follows:

Run a pseudo-localized version of a program

The most effective way to perform pseudo-localization is to modify the program's resources automatically. For example, here is what English-speaking localizers do when they translate a program's UI:

  • Replace English text with text containing non-English characters. It is advisable to keep the text readable. For example, make your translation algorithm replace English characters with non-English symbols of a similar shape. For example:
    • For a, use à or å
    • For c, use ĉ or ç
    • For n, use ń or ñ.
  • Add extra characters to your resource strings. In many cases translated text is longer than the English original ("some string" becomes "+++some string+++").
  • Stretch your dialog boxes. Localizers usually do this when the string length grows due to localization.
  • Mark the beginning and the end of each resource string. These markers help you identify when the application displays text at run time — a potential source of localizability bugs.
  • Make your substitution using multi-lingual Unicode (as resource strings are stored as Unicode anyway). This will help you find places where the program utilizes ANSI functions to process or display text.

After you pseudo-localize your program, test its functionality. Pseudo–localized applications should function no differently than the original version.

An area often forgotten in localizability testing is mirroring testing. If you want to distribute your software to markets where the text and UI of the programs display from right-to-left (RTL), you will want to know how your application looks when it is mirrored. This test may be implemented as a part of the pseudo-localization of your product. As a result, your text displays in your chosen language, but the application mirrors windows and text alignment.

Perform code review

Be sure the code meets the following requirements:

  • Write all resources in standard Windows resources format and do not hard-code strings in the source code.
  • Do not use pointer arithmetic for string-length calculations, access to string elements, or string manipulations.
  • Do not build strings at run time by stripping or concatenation.
  • Resources do not make assumptions about string buffer length.
  • Do not position UI controls at run time.
  • Icons and bitmaps do not contain text.
  • No assumptions exist on drive and folder names or registry keys.

Perform UI and documentation review

Make sure the terminology used in the UI and support documentation is clear, consistent, and unambiguous. Localizers can get confused when the UI and the documentation refer to the same features by different names or when the text contains excessive technical jargon.

See Also

Testing for Globalization and Localization

Show:
© 2014 Microsoft