Typical localizable issues
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.
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.
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.
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”.
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.
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”.
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.
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.
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.
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.