Last week we drew a line between internationalization and localization. Now, it is time to move to the most common defects that QA specialists face while testing the internationalization readiness and quality of localization.

Let’s start with the defects that usually come along internationalization readiness testing.

• Broken encodings. If your application does not recognize, for example, Chinese characters, then when you decide to switch to a Chinese locale, you will see unidentified squares instead of hieroglyphs you expect to see.

• Another pain in the tester’s neck is unsupported local calendars, various data and time formatting depending on the region. For example, there could be either 12-hour or 24-hour clock, also data formatting could differ from the local operating system’s formatting set natively.
• Aside from data and time formatting, testers often forget to adapt the decimal symbols that should correspond the locale set natively in the operating system. a1qa team had a project where comma separator was not included into US-locale encoding.
• The hardcoded elements in the app are of a particular note. Such defects are rather common and should be fixed as soon as possible.
  
  
  Inability to add new translations or change the pictures, colour schemes for a particular region also fits in this group of defects.
• Verifying internationalization readiness, it is important to check whether there is a possibility to change text orientation and to mirror user interface for several languages. However, it is crucial to keep an eye that the characters themselves are not mirrored and all the fonts are displayed correctly.

Now we would like to move to localization testing defects.

If internationalization was done correctly, the most common defects of localization will only include UI defects, undertranslations and overtranslations. However, functional defects, which are of high priority for any app, may also appear.

• One of the most common localization defect is the use of different names for one and the same element. Usually, it concerns OK and Cancel buttons. It often happens that in some parts of the app these buttons are translated into the local language, in others –left with no translation.

Thus, names for buttons used for one function should be harmonized.

• The path to system folders is another thing to be checked during localization testing. To do it, it is necessary to disable internet connection. Often the links to system folders may be damaged during translation and thus they won’t lead to the right resources anymore. The user sees the empty square for the picture, but there is no picture itself, as the path is incorrect.
• As we have mentioned before, the lack of support of local calendars is the internationalization challenge, whereas undertranslation of these calendars is the issue for localization. You should pay attention to tooltips and system notifications, as they are often left forgotten.
• UI defects. Unsupported fonts, incorrect button and drop down list sizes, inaccurate division of words – all these are the most vivid examples of UI defects. Usually there are quite a lot of them, especially when pseudolocalization tool was not used during internationalization. Pseudolocalization is a method that implies strings preparation 30% longer than they should be originally to ensure there is a room for translations.
• Undertranslation. A native speaker could easily find mistranslations and undertranslations in the app. Thus, it is essential to engage professional linguists who know target languages and cultures perfectly to be able to check the accuracy and logic of all translations.
  Summarizing the above, we would like to emphasize that functionality and business logic are the most important elements to pay attention to during testing. Obviously, it is more critical to find all functional bugs, like broken sorting algorithm or search field, that influence the work of end-users in the app.

Only after all functional defects are detected and fixed, you may move to the perfection of UI/UX – one of the localization challenges. Of course, these defects are not of such top priority as functional bugs; however, they influence user experience a lot. Indeed, who is excited to use an app in which it is impossible to find a character to enter your name correctly?

For more than 5 years, a1qa team has been ensuring quality of the app developed for interaction between medical devices. The app guarantees correct and smooth operation from any part of the world.

As for now, the application supports 18 locales, including two Chinese writing systems (traditional and simplified characters) and the Korean language. Thus, both internationalization and localization processes were included in the test plan for the creation of this application.

As these two words – localization and internationalization – sound quite similar, they often put an inexperienced tester in utter confusion. As a result, it becomes difficult to relate test cases to the appropriate type of testing. Hence we would like to distinguish these two definitions in this article.

Globalization makes a way for international use of the product

It is an open secret that the success of any app depends largely on how well it is adapted to work around the globe. The strategy to make the product internationally usable is called globalization.

If a software development company shapes its course on globalization, it is necessary to put in place internationalization and localization, as well as content translation of all software strings to the target languages.

Internationalization (I18n) is a product development process that later allows for adapting the app to various languages and cultural differences. The aim of internationalization is to assure further barrier-free localization. To take an example, the developer should set along a vertical-align property in CSS if it is planned to localize the product for vertical-script language.

Localization (L10n) is the adaptation of a product and its documentation to the language or culture needs of the target market(s).

And now we are turning to the main challenges that I18n and L10n deal with.

The first thing we think of when talking about the internationalization is the use of UNICODE encodings. The use of UNICODE allows supporting most of the world’s writing systems.

The next challenge of internationalization is to support various formatting of dates, calendars, systems of measures, and units of measurement.

It bears mentioning that with the help of internationalization it is possible to change the text orientation and user interface (for example, from right to left interface for Arabic-speaking countries or hieroglyph position vertically down for the Asian region).

Moreover, the allocation of code points into separate source files is one of the basic elements of internationalization. Separate files are convenient as they help to avoid hard-coded elements, in case if the languages are planned to be changed.

Localization: think globally, act locally

As a rule, localization deals with challenges of local context. Translation of the content, translation of the individual elements of UI, messages to users and control elements into all languages foreseen for this product – these are all the examples of localization tasks.

Localization testers should take into account the diverse legal requirements of various countries. Let’s take a look at the legal age of majority. In the USA we get adult from 18 to 21, depending on the state of residence. In Japan you stop being a minor at the age of 20. Thus, while developing an online store, for example, one has to look at the age restrictions for all target regions.

Also, it is important to keep in mind the currency of the country and transactions herewith.

Every software product is designed in specific colour patterns. Color and symbols should be considered as they may bear different meaning in different cultures.

For example, red color symbolizes creed and endurance for Chinese people, while for the Indians it is a color of purity. Europe associates this color with sins and self-sacrifice. People in South Africa see red color as a color of grief and sorrow, in Egypt – mourning, in the USA and Japan – danger and terroristic threat. That’s why we highly recommend paying attention to the color scheme of your product as it could be of critical importance for the success of the application.

Moreover, it is essential to remember about the regional keyboard layouts and hotkeys.

If the application is integrated with other external resources (e.g. cloud storage), it is important to consider their accessibility for all the regions. In China, such services and tools as Google, DropBox, YouTube, Facebook are forbidden by laws.

To sum up, it’s important to undertand that the process of I18n gets into action when the product is to be used internationally, while L10n provides for a set of tools and techniques to adapt the product for the regional usage.

The defects that we meet in the app more often are formed on the basis of the objectives for every process. The types of defects will become the topic for the next article for our blog. Stay tuned!

Within the localization process many issues can appear, which makes it really important to test localized products thoroughly. To achieve high quality and disclose as many issues as possible, localization testing is usually performed in a “native”, localized environment. So, starting the localization testers usually face following issues.

String length

All the text labels and other strings should be appropriately sized and have room to grow when the product is localized. As languages are different in word length, it is necessary to ensure that there is space for more text if needed, and dialogs are not written too tightly. Therefore, it is recommended to accommodate text one and a half the length of the English variant.

Menu items

Quite often menu items do not fit one line, in case like this it is advisable to resort to abbreviations. For example, in German the Help menu have to be translated as simply as a question mark to save space.

String combinations

A common practice of combining multiple strings into a single string may seem harmless, but when localized, the strings may become confusing or utterly incomprehensible to users. Consider, for instance, the simple practice of employing the user’s name to show possession of an item, such as “Jeff’s Document.” It is very easy to program by simply combining two strings: <username> & “’s Document.” But in most other languages it is impossible to show possession by simply adding a suffix to the noun as you can do in English. In Spanish you would have to say “El documento de” & <username>, requiring a change to the code base. It would be better not to combine strings as shown above. So, when it is necessary to combine words to express some compound ideas, use formats that can avoid number and gender agreement such as “Interval: Weeks” rather than “Weekly Interval”.

Text direction

The main issue of the text directionality is that not all languages are written from right to left, Arabic and Hebrew are written from right to left, and others like Chinese can be written from top to bottom. A further complication comes with the concept of bi-directionality, which means that some things are written in one direction and the rest are written in another. For instance, in Hebrew and Arabic the standard text is written from right to left, but numbers are written in the same way as in English, from left to right.

Buttons place

Applications tend to be designed and have controls arranged with the native locale’s directionality in mind, such as placing the Next button on the right and the Previous button on the left. Although some of these design changes can be skipped as computer users in foreign countries can adapt themselves.

Position of input fields

Input fields should not be placed in the same position, they are to be reordered to support different languages. For example, an input field occurs at the end of the source sentence – “Make daily backup every [……….] weeks”. The target language may require changing the word order (as is often the case in German where the verb needs to be at the very end): “Tägliche Sicherungskopie alle [………] Wochen machen”.

Sort order

The correct sort order differs in languages. It is essential to test that an application can sort according to the proper order for a specific locale. Sorting can be done according to the alphabet of the language, according to the number of characters in a symbol (like Traditional Chinese), or other means. Sorting rules can also vary with respect to upper vs. lowercase letter and other rules. For example, in Spanish the double “L” is a single letter; so, the word “loco” would appear alphabetically before the word “llave”. Usually a common operating system provides rules for sorting, so testers need to verify that the application follows the rules. Sorting is something that is universal to almost all programs and occurs in main data windows, dialogs, list boxes, etc.

Images with text

Images with text on them can be a problem because translating a picture is not as easy as translating a simple text string. Developers should try to minimize the amount of text that appears in icons, toolbar buttons, splash screens and other images that need to be changed when the product is localized.

Translation

As testers usually don’t speak languages they check, it’s better to leave the verification of translation to the experts. However, testers should check that terminology is consistent by verifying that the same words appear in the same places throughout the product.

Special characters

There are common problems with special characters in localized versions – sometimes they are replaced with other symbols. Testers should verify that characters with an umlaut (ä), diacritics (è, é), etc. are correctly displayed.

Localization updates

Changes to the original version (e.g. text in messages, titles of columns, button captions, etc.) must also be made in localized versions. Testers need to check that localized versions are correspondingly updated.

Dealing with the localizable issues discussed here is important, although initially seems a second place task. Nevertheless, carefully done localization is a true way to gain users` credibility.

Today the world is a global village, the products are developed in one part of the world, undergo globalization process, launched in multiple markets and used in different part of the world. As a consequence, the need of internationalization and localization process and testing requirement for the internationalized product is considerably increased.

Software Internationalization is the process of preparing a product so that it can properly operate when modified for use in different languages and locales. Internationalization refers to the process of designing, developing and engineering the product that can be adaptable to various locales and regions without further engineering changes.

Once an application has been internationalized, it is ready to be adapted for specific locales, or localized. Localization it is the process of customizing the software product for each language that is to be supported. It includes translating the program, choosing the appropriate icons and graphics and other cultural considerations. It also may include the translation of help files and documentation.

Releasing the products in all continents means that the product needs to comply with the local user culture. To be successful in capturing the global market, software product developers need to step out of their native locale and develop world-ready products. The elements are localized in most cases: GUI context, Help, Error messages, dialog boxes, Documents such as User manual, Installation guide, Release notes, Tutorials/Readme files.

Localization and internationalization testing includes the following types of testing:

Testing is always an integral part of such projects, and is specifically broken down to internalization and localization testing. These cover the following testing sub-types:

• Compatibility testing: includes testing the product behaviour in identifying and initializing from its language environment and its ability to customize to that environment.
• Functionality testing: includes running the whole functionality regression test on different language environments and exercising the interface with native language strings. It involves verifying the culture specific information such as date/time display.
• User interface validation: includes check for visual problems such as text truncation or overlap, graphics issues or other visual problems.
• Interoperability testing: ensures that the software interacts properly with targeted platforms, operating systems, applications (and versions) and so on.
• Usability testing: evaluates the ease of use of the system.
• Installation testing: ensures that the product installation messages are displayed in a corresponding language when installing the application on a dedicated server.

Difference in character-encoding (ASCII and MBCS)

One of the most challenging aspects of developing software for international use is testing that speakers of other languages are able to input information into the application in an intuitive and natural way. Testers should also assure that the program will be able to handle properly a wide range of characters and character combinations that people will use. Since languages don’t use the same written symbols, a variety of means have been established for programs to store and display these symbols, primarily using different character sets, which testers should focus on.

The ASCII character set consists of 256 ordered symbols with a numerical index, with each character capable of being represented by one byte. This is a sufficient number of characters for English and most of the European languages. However, Far Eastern languages require more symbols than can be contained in this one set of characters, with some, like Chinese and Japanese, using thousands of symbols. These languages employ sets of characters using one or more bytes to represent the symbols, which are multi-byte character sets (MBCS).

A lot of problems are encountered when working with MBCS, so careful attention should be paid to testing of how these characters are used. The biggest problems come from programs that assume that each character is a single byte. For instance, when the user presses the backspace key to clear a character, many programs that aren’t multi-byte enabled will delete only the second byte of the character, thus changing the symbol that is displayed rather than deleting the entire character. In addition, the selection of words, line breaking, and simple text editing will all suffer if the proper measures aren’t taken to enable an application to work with MBCS systems.

To test that a product correctly handles a complex array of characters, testers should include combinations of various character sets in their test data. Any place where text can be entered and displayed should be tested with upper ASCII characters (those in the upper half of the set that require the eighth bit to be set), double-byte characters in pure double-byte systems, and single- and double-byte characters in multi-byte systems. The areas that need this kind of focus include control labels, input fields, and filenames and paths. Including character set testing in every test plan will prevent many embarrassing and costly errors later on. Next time, I ‘tell you about the most typical localizable issues.

Localization is the process of translating text elements of an application and adjusting the user interface to a specific language or region. In broader terms, localization is the adaptation of a software product, together with its online help and documentation, for use in one or more regions of the world.

Localization of software can include translating user-interface text, resizing text-related graphical elements, and modifying images and sound to conform to local conventions. The localization process consists of the following steps:

The main goal of preparation phase is to prepare all necessary documents and other items that may be required for localization. On this step a tester goes through the activities like:

• Scheduling and resource plan development
• Software analysis
• Glossary creation. The glossary contains menu items abbreviations, technical terms, notions used in a certain domain.
• Creation of untranslatable words list
• Test documentation creation
• Functionality learning by translators

Apart from that, there are some specific points which are usually need to be addressed during localization:

• Duration of the localization and required efforts depend on the overall words count in the application and documentation.
• Usually the localization process has several cycles (translation->implementation->testing->defect fixing and validation).
• It is necessary to use terminology consistently to avoid alternative translations of the same term.
• On this phase close cooperation between translator and QA specialists is a MUST for better understanding of the functionality. And of course learning will require more in case of translating into many languages. For that very purpose QA engineers can prepare detailed instructions and check-lists for translators, which allow making translation without deep product investigation. The approach allows the company to decrease the budget of the project and saves the time.

After all the preparation activities the process moves to software adaptation, where a tester can choose between two localization methods: source-based localization and binary localization. Source-based localization is a universal process that can be used with products designed for any platforms.

It is based on localization of text files that contain only textual representation of user interface elements. In this model, source file compilation as well as build creation is typically performed by the software engineers.

While binary localization, all activities are focused on the compiled modules or directly on the whole product as such with already built-in translations.

Source-based localization is the most frequently used method. It allows easily localizing the product into a particular language without the development team having to spend many efforts. If the source-based method is chosen, a development engineer adapts the software for using external text files.

During the process the development engineer also adapts methods of data, currency, and unit of measure representation, sort order, which allows the engineer to easily consider peculiarities of foreign languages

As soon as all text elements are exported to resource files, professional linguists start translation. Native speakers as well as professional translators get involved in the process. Translation is made using special tools, which help to track the translation process, use common terminology, and check spelling errors. While the translation process, it is really necessary to follow some tips to increase the translation quality. First of all translators should have access to the application and its screenshots to be sure they use words in proper context.

If you want to avoid long debates on “which word to choose”, distribute the documents or modules between the translators, follow the rule: one translator – one module/document. And one more thing, if the source files contain control symbols, translators should have instructions from the development team for how to use them.

Once the translation is over, the development engineer compiles a project with translated resources. Afterwards the process moves to linguistic verification testing, when a linguistic expert runs through the localized application, reviews each screen and compares it with the source-language application.

The linguist checks the translation of every screen and help topic in runtime context. QA specialists work closely with the linguists and guide them through the screens and address any functional, network, and file access issues that are uncovered during the review. The linguistic verification testing phase includes the steps like:

• Verification of translation accuracy
• Check for typographical errors
• Check for truncated or misallocated text
• Assessment of cultural compliance
• Check for politically sensitive content

Formats like dates, times, numbers, currencies, separators, units of measure, and calendars are to be thoroughly tested. The testing ensures that items are placed in the correct order, separator symbol is placed in a proper location, and the entered values are properly recognized.

Localization testing is a part of software testing process focused on internationalization and localization aspects of software. It is the process of adapting a globalized application to a particular culture. Localizing an application requires a basic understanding of the character sets typically used in modern software development and comprehension of the issues associated with them.

Localization is quite a comprehensive task, and there is a lot of room for error. So check back the translation is contextual and done correctly.