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:
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.
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.
Here is a rule of thumb: add an extra 30% of space for the English text that will be translated for your international product.
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.
This again shows that leaving enough space in your English build beforehand is a good idea.
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.
5. Over localized
But not everything needs to be localized. The following items should generally be kept in English.
- Book Name
- 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.
This happens when the controls in a window or dialog overlap with others.
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.
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:
Let us know if we missed any important localization defects?
Allen Guo and Jan Princen