This blog will focus on the best practices to be followed for Internationalization & Localization testing of web based applications.

Introduction

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.

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:

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.

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.

Related posts:

1. Best Practices in Software Performance Engineering Introduction In today’s competitive and ever changing world, where most software applications are complex in nature having distributed, multi-tiered, Web-based architectures, one of the key success factors is the application’s...
2. FitNesse- Testing Business scenarios for UAT In this blog I will be introducing FitNesse tool, an automated testing tool for user acceptance testing. This blog will give an overview of the tool which is a Wiki...