Introduction
World is flat. If you are reading this page, chances are that you are experiencing this as well. It is very difficult to survive in the current world if you are selling your product in only one country or geological region. Even if you are selling in all over the world, but your product is not available in the regional languages, you might not be in a comfortable situation.
Products developed in one location are used all over the world with different languages and regional standards. This arises the need to test product in different languages and different regional standards. Multilingual and localization testing can increase your products usability and acceptability worldwide.
Contents:
Definition
Internationalization is the process of designing and coding a product so it can perform properly when it is modified for use in different languages and locales.
Localization (also known as L10N) refers to the process, on a properly internationalized base product, of translating messages and documentation as well as modifying other locale specific files.
Assuming that there is not a separate base product for the locale, the localized files are installed at their proper location in the base product. This product is then released as a localized version of the product.
Localizing a properly internationalized product in most cases should require no changes to the source code.
Internationalization testing is the process, which ensures that product's functionality is not broken and all the messages are properly externalized when used in different languages and locale. Internationalization testing is also called I18N testing, because there are 18 characters between I and N in Internationalization.
Internationalization
In I18N testing, first step is to identify all the textual information in the system. This includes all the text present on the application's GUI, any text/messages that application is producing including error message/warning and help/documentation etc.
Main focus of the I18N testing is not to find functional defects, but to make sure that product is ready for the global market. As in other non functional testing it is assumed that functional testing has been completed and all the functionality related defects are identified and removed.
I18N testing can be divided in to two parts. First, to make sure that application's GUI or functionality will not be broken with the translated text. Second to make sure that translation of all the strings have happened properly. This activity is called Translation Verification Testing and is normally conducted by person who knows the language very well.
To make sure that application's functionality or GUI will not be broken after the translation a popular technique known as pseudo-translation is used. In pseudo-translation instead of translating it completely, it is translated in a pseudo manner. For example an externalized string "Bad Command" can be translated in Japanese as [JA XXXXX Bad Command XXXXXX JA]. Now if the product is launched with locale as Japanese it should show the externalized string as given above instead of "Bad Command". There are utilities to do this job for you, to do pseudo-translation of all the externalized strings of your application. During pseudo-translation you need to make sure that you are doing it roughly according to the rule. For example, width is normally expanded up to forty percent for the pseudo-translated strings as compare to the English.
As stated above, In I18N testing focus is not on the functionality but on the translation and locale related issues. Once all the externalized strings are pseudo-translated, you need to make sure that you have test case for every message or text element present in the system. Once it is done, same set of test cases can be executed on the properly translated build to make sure that translation is proper.
Pseudo-localization
A convenient approach to internationalization testing is to use the technique of pseudo-localization. This technique simulates the process of localizing products, involving many things a localization center does when localizing a product. To pseudo-localize a product:
- Pseudo-translate message files by inserting a specific prefix and suffix into every message. You can also modify localizable non-message resources, such as font names and colors. Localizable non-message resources should not be translated.
Also, other files that may be localized should be modified in some way, such as help, text, html and graphics files.
- Install the pseudo-translated message files, as well as all other pseudo translated or modified files, in the locale of your choice, at the proper location in the product. In certain cases, such as for Java resource bundles, you must name the files with a locale-specific suffix and install them in the same location as other locale-specific message files.
- Run the product from this locale. The messages and GUI labels should display the prefixes and suffixes you added, and not the English default messages. You should also see the behavior of the modified, localizable non-messages, and other files that were modified, like help, text, html and graphics files, will show the modified versions of these files, when run in this locale.
This approach allows you to use the product, including its menus and other GUI objects, without needing to know another language or fully translate the message files.
Many of the sections that follow take this approach.
