Localization Testing & Internationalization Testing

Globalization
Globalization is the process of developing, manufacturing and s/w products that are intended for worldwide distribution. An important feature of these products is that, they support multiple languages and locale. In a globalize product, code is separated from the messages or text that it uses. This enables software to be used with different languages without having to rebuilding the complete s/w. Globalization is achieved through the Internationalization and localization. It is important to understand locale as supporting different locale is more than supporting different language. In addition to languages and geographical location, locale incorporates cultural information such as time, date, font, currency convention etc. Differences in spelling, currency and other conventions make testing with different locales necessary. Internationalization In I18N testing, first step is to identify all the textual information in the sytem. 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 cases 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.

Localization Testing (L8N orl8n)
Localization testing typically follows after internationalization testing, which verifies the product's readiness for localization and its international use in the required culture or locale.As part of localization testing, User Interface (UI) testing concentrates on the appearance of the product assuring that the product looks good to the end user. We perform a series of UI checks on every dialog in the software. This series includes steps such as:
All User Interface is localized
List box and Combo box items are localized and are not truncated.
No duplicate items on list box/combo box.
Any available drop-down menus are localized.
The User Interface format and design is comparable to the source version.
No duplicate hotkeys exist.
No items are truncated.
No items overlap.
When a control gets focus, it does not truncate the text.
Alternative texts (tool-tips) are localized.
Additional UI testing steps check the localized product compliance with the relevant national language standards, such as formats consistency, capitalization, alphabet, currencies format etc.Localization testing involves also a number of functionality testing passes to verify if no functionality issues have been introduced into the product during the process of localization. The basic functionality tests include setup and upgrade tests run in the localized environment. The complete functional testing as a standalone service will verify the product's behavior in both source and localized versions and environments.

Internationalization testing (i18n or I18N)
Common i18n issues:
Adding a New Character Set or Language
8 bit clean (many encodings need to use the 8th bit for non-ASCII characters)
1 character = 1 byte (some Asian characters are multibyte)
Layout
Locale-sensitive integers (e.g. date/time)
English protocol elements (English retained on-the-wire, but translation on UI)
Issues with when reading text into fixed-size buffers (partial characters)
Special encodings of non-ASCII text (e.g. encoding standards for sending email)
Front Ends (FEs – e.g. winfe (Windows), macfe (Mac), xfe (Unix))
Complex Language Support (BiDi, Thai, Indic, etc.)
Non-Latin Layout Styles (Vertical, Ruby, etc)
Platform Independent IME Support
Natural Language Dictionary Lookup
Proofing API (in addition to spell checking)
Import/Export of database formats
Hardcopy outputs

For more information refer:
http://www.testinggeek.com/