Everything You Need To Know About Localization Testing

Localization Testing is checking software for a particular geographic culture or locale to ensure that the software works correctly for that region as it works in the origin region. The target region contains the same software as the origin region, but the only difference is that the languages would be different; functionality-wise, everything would behave similarly. Generally, the User Interfaces, namely buttons, labels, texts, titles, etc., and Contents, are the elements to which high importance is given. These are the primary impact areas for Localization. It is most commonly applied for website testing.

First of all, we should understand why the Localization of a software product is required. Suppose you are the owner of a famous social networking site whose fan base is mainly scattered across the United States and some parts of Asia. After considering its initial response from the fans, you have thought of expanding the application to other global regions. So, it would be gibberish to say that a Russian, French, or Japanese person may know to use your app in English.

French, Russian, Spanish, German, Japanese, Mandarin, Hindi, etc., are native languages limited only across particular locales. You cannot expect to launch your product in these regions where people barely understand English. The software will be less useful in areas where the locals do not understand the defined language.

To make your software World-ready, you should ensure that it is readily available to the users from those locales in the language they are comfortable with. For example, I am an Indian with good knowledge of English, and I might not find any difficulty operating an application in English. However, not all Indians understand English. So an application with Hindi or any regional language the user understands might do wonders. That is why we need Localization.

As mentioned above, Localization Testing mainly deals with the correct translations of the application texts to suit the target audience. Therefore, you may say that certain functionality may not be hampered while performing Localization Testing. However, we should never compromise with Quality while working on a product. That is the job of a Software Tester.

Never Ever Compromise with Software Quality. Yes, there is a high possibility that a particular feature would be impacted because of the translation. What if a translated hyperlink failed to launch a new window when clicked? What if a calculation formula provided a different result on accepting values from the user? Functionality issues arise from localising software; we cannot risk ignoring it.
So basic functional testing should be carried out on the Localised software. Well, such kinds of threats should always be taken into consideration. Our primary purpose as a tester is to find as many bugs as possible, thereby delivering the finest software quality. The ultimate goal of localization testing is to ensure that the product is successfully migrated to the target market with the proper translation.

There are many ways to perform localization testing. For example, sometimes, the vendors provide the excel sheet with the key-value pair where a particular developer key is associated with a value.
The value could be localized content. Consider something like the below, 

< str-header-label> List Management 
The above example is a part of the original English file. Similarly, the same developer key will be associated with different language files.
< str-header-label> Gestion des listes for French 
< str-header-label> Gestione lista for Italian
< str-header-label> सूची प्रबंधन for Hindi
< str-header-label> リストの管理 for Japanese and so on. 

The application package will contain the Language files for the particular regions, which have vital information because these files would be used for performing localization testing for the application. The key-value pair is one method that is widely practiced in several organizations. At our organization, we perform this method for localization testing.

Consider if you do not have a language file provided by the vendor, then you could verify the original text by appending random strings to it so that it would serve as a translated text. That is supposed to be done using a random character generator. The translated text would end with the end of the character denoter.

For example, Welcome will be displayed as Welcome$%24%1E. The E here is the end of the character. E here indicates that the text is completely translated. If it was any random values not followed by E, then it implies that something was wrong and it was not translated correctly. The drawback of these methods is that it is tedious. Generally, Localization testing itself is a tedious activity. You got to compare excel sheets along with the texts on the UI. So you got to have lots of patience while performing Localization Testing.  

Commonly discovered issues during Localization Testing
 
Below are the types of issues that are generally found while performing Localization Testing.
 
1. Corrupted Characters 
 – Wrong display of unique characters. For example, if the translated text in Japanese is リストの管理 and the localized text is displayed as リスâトのë管理, then this would be incorrect. Characters should be translated correctly. I logged a bug the other day that displayed random characters on the warning dialog box that was supposedly a Japanese build. 
 
2. Missing Translation 
 – Finding untranslated text is one of the crucial activities in Localization testing. There might be cases where you could find several untranslated texts. Such issues should be reported and fixed.
 
3. Bad Translation
 – Mistranslated or inconsistent text, including typos and punctuation issues. These kinds of issues are a significant headache for the testers. The translation should be clear, correct, and concise.
 
4. Truncation, Overlap, and misalignment
 – Text truncation, overlapping, and misalignment are common side effects after localizing a software. So to ensure that these kinds of issues are averted, proper testing must be performed. 
 
5. Currency and Number Format 
– Incorrect currency, wrong date/time format, invalid telephone numbers, postal codes, weights, and measures are good bugs. Note that the mentioned parameters should be related to the locale where the product is shipped. France and Japan may have different date/ time formats. So it should be ensured that actual culture study is taken into consideration while localizing
 
6. Other/General Issues
 – Wrong alphabetical order/sorting, font issues, and untranslated image text constitute the other issues. 
 
7. Usability of the UI
 – Localization should not impact the Usability of the UI.