Testing for Internationalization

Objective

In today’s world, most of the companies are aiming to go global in order to tap the vast opportunities that exist in various global territories. To achieve this aim, there is a growing need of their applications (web and desktop) and websites to support multiple languages. Apart from developing such applications, there is a huge demand for testing these applications.

 

During my career, we did a lot of research for performing effective language specific testing for various applications. In this paper I am summarizing the findings which can help any novice to understand and achieve effective internationalization testing.

What is Internationalization

Internationalization (abbreviated as “i18n”) entails to design and development of an application or product that removes the barriers to localization.

It can be termed as a process or a practice that allows easy migration of a product from one language to another. The main aim of internationalization is that it helps in product localization.

What is Localization

Localization (abbreviated as “l10n”) entails to adaptation of an application or a product to support the language, culture and other requirements of a particular Locale.

The first thing that comes to anyone’s mind when asked to perform localization is translation to a particular language. But localization is not just translation. During the course of this document you will come to know about the various things that will help you to perform effective localization testing.

Environment Compatibility

Though Unicode is becoming an increasingly adapted standard for coding, still different Operating Systems show different behaviors for this support. Windows 2000 and Windows XP provide a support for i18n, but Windows Millennium shows a bit of issues with Unicode. Other kind of issues can be seen with Mac and Unix platforms.

Know the Languages and Locales

Various different languages in the world have different characteristics. To build an application that is compatible with Western Europe languages is simpler to the one that needs to support Far eastern languages like Arabic.

For Left-to-Right (L2R) languages, some of these languages require more screen area as compared to English. E.g. German language UI typically require almost 30% more area than that required by English. Some text translations can also raise issues like in Spanish, OK is translated to ‘Aceptar’, which will raise the issue of button size.

For Right-toLeft (R2L) languages, to perform tests for these languages, an input Method Editor (IME) is mostly preferred as they require a combination of keys for the 101 key keyboards. Among other far east languages, Japanese language uses the combination of two syllabaries with ideographs and also makes use of Latin characters as well, which further complicates the testing process.

Before starting testing identify and decide on the locales that are to be certified initially.

Identify Areas to Test and create Test Plan

It is very important to define the environments before starting the testing for internationalization. The hardware and software requirements for an application that needs to be internationalized should be narrowed down, in the starting, for getting quick results.

Apart from locale language, some of the things that should be kept in mind while testing for localization are

• Date and time formats – Some regions put date in dd/mm/yyyy while some put the same in mm/dd/yyyy. The clock is preferred in some regions as in 24 hour format, while some prefer AM/PM.
• Numeric – These can be denoted differently in different countries. Like in US, 100000 is written as 100,000 while the same in India is written as 1,00,000.
• Use of currency – Currency is different for different locales. Even in English locale, currency is different for different countries like US and Canada.
• Symbols, icons and colors – Color schemas can be different for different regions. Like in the traffic lights in US, “Green” symbolizes the “Go” while in Japan the color for same is “Blue”. Same holds true for symbols and icons for regions.
• Names – Most of the English speaking countries use First Name + Middle Name + Last Name, but in some countries like China, Family Name is considered as the First Name. Similar kind of differences can be seen for different countries.
• Keyboard Usage – Apart from the 101 Key Keyboards, different countries have different key caps. Like English-language keyboard starts with “qwerty”, while a German-language keyboard starts with “qwertz”.
• Text and graphics can contain references to objects, actions or ideas which make different sense in different regions
• Varying legal requirements including the appropriate contact information for various locales

Based on the above information, create a Test Matrix that includes platforms and versions for all the components eligible for certification. Create test cases based on the following guidelines:

• Specify tests for English and non-English configurations.
• Develop non-ASCII data for any text that is used in testing. This can either be real non-English data or it can be pseudo-localized data.
• Develop tests that use non-ASCII values in path names, file names, URIs, account preferences, etc., not just in “regular” data.
• Develop tests for time or date values that specify different time zones and include cross-time zone and daylight savings.
• Create some testcases for some mixed configurations (such as Indian client to Japanese server).
• Develop tests for localizability
• Test the Life-cycle (install, uninstall, configure, etc.)