Internationalization Testing

 

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.

 

Internationalization testing is the process of testing software which is supposed to work uniformly across multiple regions and cultures. There are two of the major aspects of international software – world readiness (globalization) and localization. World readiness refers to the process of designing, coding and testing the product such that it can be easily localized for different regions. Localization involves translating and customizing the product for different regions.

Ensuring world readiness is different from testing localized versions of the product, and it is broader than just testing the functionality. It also includes realizing the implications of globalization, and verifying that those implicit requirements are met throughout all the design and development steps.

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.

Internationalization Testing

The goal of Internationalization testing is to detect potential problems in software globalization. It makes sure that the code can handle all international support without breaking functionality that would cause either data loss or display problems. Globalization testing checks proper functionality of the product with any of the locale settings using every type of international input possible. There are two basic testing requirements which ensure that the product works well in all regions for which it was developed:

• Testing to check if the product is locale aware (globalization).
• Testing the localized versions of the product.

The following diagram depicts the breakdown of the product with respect to internationalization and localization testing:

 

 

Goals

The typical goals of system usability testing are to:

·  Cause the application to fail to meet its internationalization requirements so that the underlying defects can be identified, analyzed, fixed, and prevented in the future.

Objectives

 

The typical objectives of system usability testing are to:

·  Partially validate the application by determining if it fulfills its internationalization requirements including:

                          (a.) Native languages, language idioms, spelling, and character sets.

      (b.) Formats of contact information such as name, address, and phone number.

                          (c.) Currencies including real-time currency conversion.

                          (d.) Legal issues such as import/export laws, tariff and sales tax calculations,

                                Customs documentation, trademarks, and privacy laws.

                          (e.) Culture (e.g., use of inappropriate colors, symbols, or product names).

        • Report these failures to the development teams so that the associated defects can  be fixed.

           • Help determine the extent to which the application is ready for launch.

        • Provide input to the defect trend analysis effort.

 

 

Examples

Typical examples include internationalization testing of an application by:

·  Users from different cultures.

·  Users from different countries.

·  Native speakers of different languages.

·  Subject matter experts in different legal issues.

Preconditions

Internationalization testing typically can begin when the following preconditions hold:

·  The internationalization requirements to be tested have been specified and implemented.

·  The independent test team is adequately staffed and trained in internationalization testing.

·  The application under test exists.

Completion Criteria

Internationalization testing is typically complete when the following post conditions hold:

·  The independent test team has tested the application against its internationalization requirements including:

 

 

(a.)   Native languages, language idioms, spelling, and character sets.

(b.) Formats of contact information such as name, address, and phone number.

(c.) Currencies including real-time currency conversion.

(d.) Legal issues such as import/export laws, tariff and sales tax calculations, customs        documentation, trademarks, and privacy laws.

(e.)   Culture (e.g., use of inappropriate colors, symbols, or product names).

 

Tasks

Internationalization testing typically includes the independent test team performing the following testing tasks:

·  Test Planning

·  Test Reuse

·  Test Design

·  Test Implementation

·  Test Execution

·  Test Reporting

Environments

Internationalization testing is typically performed on the following environments using the following tools:

·  Development Environments

·  Production Environments

Work Products

Internationalization testing typically results in the production of all or part of the following work products from the test work product set:

·  Documents:

(a)   Project Test Plan

(b)   Master Test List

(c) Test Procedure (a.k.a., test protocol, test script)

(d)  Test Report

(e)  Test Summary Report

·  Software and Data:

(a)  Test Suite

(b) Test Case

(c)  Test Data

 

Test Phases of Internationalization testing

Internationalization testing typically consists of the following tasks being performed during the following phases:

PHASE → TASK ↓	Business Strategy	Business Optimization	Initiation	Construction	Delivery	Usage	Retirement
Test Planning	Not Applicable	Not Applicable	Completed	Optional Regression	Not Applicable	Not Applicable	Not Applicable
Test Reuse	Not Applicable	Not Applicable	Optionally Started	Completed	Not Applicable	Not Applicable	Not Applicable
Test Design	Not Applicable	Not Applicable	Optionally Started	Completed	Not Applicable	Not Applicable	Not Applicable
Test Implementation	Not Applicable	Not Applicable	Optionally Started	Completed	Not Applicable	Not Applicable	Not Applicable
Test Execution	Not Applicable	Not Applicable	Optionally Started	Completed	Not Applicable	Not Applicable	Not Applicable
Test Reporting	Not Applicable	Not Applicable	Not Applicable	Completed	Not Applicable	Not Applicable	Not Applicable

 

Best Practices in Internationalization Testing

• Feature Based Testing

The product may be marketed with some features applicable and others not applicable to specific cultures. While testing, it is important to ensure that these features are turned on or off as required while switching locales.

• Testing for Localized Content

Localized content includes both text and graphic artifacts on the user interface. Textual content to be localized includes the static text on controls such as menus, buttons, etc. and user specific messages. Language experts are required for testing the localized content in each language that the product supports.

• Testing for Culture Awareness

User locale settings define items such as number, date and currency formatting. Input locales should be handled and the user be allowed to input data in that language.

In many cases, data would need to be converted from one encoding format to another. Correct handling and understanding of encoding formats is required in such cases. If coded incorrectly, in addition to operational errors, it can also result in loss of data. For example, converting from a multi-byte character set to a single or double-byte character set can result in data loss if not handled properly. User locales do not impact conversion of data from one encoding format to another.

• Testing Rendering

Internationalization testing should check whether an internationalized product properly displays all supported scripts in accordance with the linguistic characteristics associated with them. The characteristics include bi-directionality, character reordering, contextual shaping, combining characters and special rules in terms of word breaking, line breaking and text justification.

• Testing User Interface

Internationalization testing should cover whether the user interface, on which the fonts are rendered, supports the different fonts and character widths as well as the varying spacing requirements introduced by translation. For example, it is a well known fact that German text occupies more space to convey the same information when compared to English. Thus, the user interface should be adaptable to accommodate user messages in both languages.

Following are the recommended guidelines for user interface testing:

1. Check if textbox labels appear on top of the textboxes in order to handle text with larger widths. If it is still required to have the label beside a textbox, enough room should be left for the text to grow.
2. Check if dialog boxes expand while localizing. Additional space (ideally, 30%) should be left between the end of messages and the edge of dialog boxes for further expansion.
3. Check the text embedded in images and icons. Having text in images will make localization difficult and require the efforts of a user interface designer/tester.
4. Buttons and labels should have a larger width to accommodate for longer text in non-English languages.
5. Images embedded within resource files of forms should be moved out as separate image files.
6. Mirroring: Mirroring is the process of localizing the user interface to handle right to left (RTL) languages such as Arabic, Hebrew, Farsi, etc. To give a perfect RTL look and feel to an application’s UI, both the text and the UI elements need to be laid out from right to left once they are translated into RTL languages. A complete discussion on Mirroring is not within the scope of this paper.
7. Graphical images: Graphics can be difficult and expensive to translate. Hence it is preferable to have graphics which are universally acceptable.

 

8. Following are some of the key user interface elements that need to be localized:
1. Menus
2. Messages
3. Dialog boxes
4. Images
5. Toolbars
6. Status bar

• Storage Testing

Internationalization testing should also cover data storage and retrieval in multilingual applications, which warrants careful attention. The key sources of storage include files and databases.

• Testing File Transactions
While reading from a file which contains Unicode characters, it is important to specify the encoding. If the encoding is not explicitly specified, a default encoding may be used (UTF-8 in case of .NET framework) resulting in misinterpretation of data. For example, if a text file stored in UTF-16 is read without specifying the encoding, .NET will interpret the UTF-16 characters as UTF-8 resulting in unintelligible input. Please note that ASCII and UTF-8 are interoperable if the file contains only English characters having code point less than 128
• Database Testing
Testing should cover the support of Unicode characters in databases; special data types are used which are defined for this purpose. For example, SQL Server defines nchar, nvarchar and ntext data types to allow you to store Unicode text. (The n prefix for these data types comes from the SQL-92 standard for National (Unicode) data types). Use of nchar, nvarchar and ntext in SQL Server 2000 is the same as char, varchar, and text, respectively, except that:
• Unicode supports a wider range of characters.
• More disk space is needed to store Unicode characters.
• The maximum size of nchar and nvarchar columns is 4000 characters and not 8000 characters as for char and varchar.
Unicode constants are specified with a leading N (for example, N<a Unicode string>). The following example shows how to insert Unicode values (Russian) into an nvarchar column.
INSERT INTO ACCOUNT (ACC_NO, NAME, AGE, ADDRESS) VALUES(4544,N’HARDESH’,28,N’INDIRAPURAM’)
Once you have defined a Unicode compatible column in the database, inserting and retrieving multilingual data is the same as working with regular (ASCII) data. In database migration, care should be taken while mapping the source and target data columns. If the source data type is nchar, and the target data type is char, data could be lost upon migration.
In summary, there are several aspects to be kept in mind while designing software for a global audience. These aspects cover not only coding and testing, but also the interface and layout of the software as well as factors such as the file formats and data encoding to be used.
 

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:

1. 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.
2. 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.
3. 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.