The Top 10 Localization Defects

Localization testing is a necessary part of the development life cycle of any application with international aspirations.

With the economic down turn in many parts of the world, it often makes business sense to lower risk and sell an application in different language areas. However for us in QA delivering software in multiple languages creates another type of risk: the risk of localization defects.

In order to help testers that are new to localization testing (or for old hands that wants to refresh their memory) this post lists the 10 most common types of localization defects, explains their root causes and provides ideas to prevent them.

1. Garbage characters

When the characters displayed become unreadable we call this garbage characters. It usually is a high priority defect. Here is an example:

localization_1

We distinguish three types of garbage characters:

a) Strings that are displayed as unrecognizable characters.
b) Strings that are displayed as rectangles.
c) Strings that are displayed as question marks (?).

Garbage characters are typically caused by character encoding.

If you use the wrong encoding to display the characters, you will see type a. Type b, usually happens when you don’t have the correct encoding installed in your system. And type c often occurs when developers program on a different type of machine that the machine that is used to run the software on. For example let’s assume developers write code on Windows with GB18030 as the default language environment, and run the build on an AIX which uses ISO8859-1 as the default character set. So during the compiling, javac uses GB18030 to read the source file, converts it into UTF-8 and compiles it into a class file. While running on AIX, it uses the default ISO8859-1 to express the output. Since ISO8859-1 doesn’t support Chinese characters all strings are displayed as a “?”.

Applying a wrong font could also lead a garbage character issue.

 2. Truncation

Often, when a term is translated from English to another language, it uses more characters. For example, The English “No” (two characters) is “Nee” (three characters) in Dutch. If we don’t leave enough character space on the “No” button in our GUI, the string is truncated.

localization_2

Here is a rule of thumb: add an extra 30% of space for the English text that will be translated for your international product.

3. Misalignment

After localizing an application from one language to another, the layouts of the UI controls often need to be re-adjusted to keep the original alignment. For instance when the window or the dialog box was re-sized  or the strings in the UI controls were extended or wrapped into a new line.

Localization_3

 

This again shows that leaving enough space in your English build beforehand is a good idea.

4. Un-localized

Texts in dialog boxes or windows that should have been localized are not. Testers also need to pay attention to the images or screenshots in the documents or UIs during the test. These also need to be localized to match the habits of the target markets.

Localization_4

5. Over localized

But not everything needs to be localized. The following items should generally be kept in English.

  •         Trademarks
  •         Logo
  •         Book Name
  •         Abbreviation
  •         Product Name
  •         Some references

Also please take note that in some cases the English word is more common in the local language than the local word.

A best practice is: to make a list of “no need to localized strings” and send these to the translation vendors or freelancers as early in the development cycle as possible.

6. Overlap

This happens when the controls in a window or dialog overlap with others. localization_5

To fix it, you can use an IDE (such as Visual Studio) to open your GUI file and adjust the UIs directly.

7. Missing texts

During the process of translation or application building texts sometimes get lost.

localization_6

 

To avoid missing text, we recommend a tester to use two machines during test – one with an English environment and with an English build installed, and the other with a localized environment with a localized build installed. Testers then need be careful to check and make sure the localized texts match the English build.

8. Incorrect font / size

Different countries use different default fonts and sizes. For example, Asian countries normally use “9” as the default font size while America uses “8”.

This issue normally won’t break any functions, but it influences the user experience a lot.

A wise solution is to use “9” as the font size for all the texts.

9. Inconsistent Term

One term should have the same translation throughout an application. It often happens that the translations are inconsistent to each other. This can be solved by maintaining a good translation library and sharing this with all parties involved in developing the application.

10. Incorrect Hotkey

Hotkey issues contain the following situations:

  • Lost hotkey
  • Duplicate hotkey
  • Invalid hotkey – hotkey should be English characters
  • Bad hotkey – avoid of using the following hotkeys which are difficult to read:  g -> g, y -> y, p -> p, q -> q, j -> j
  • Hotkey doesn’t work

Let’s look at some samples to get better understanding:

localization_7

 

localization_8

Let us know if we missed any important localization defects?

Allen Guo and Jan Princen