Localization is the process of taking content, labels, navigation items and other display items in an application and having them appear in another language or locale. The process can simply display content in another language or extend to several languages and multiple alphabets, such as Russian (Cyrillic), Korean (Hangul), Japanese (Kana and Kanji), as well as many others.
Regardless of the languages chosen, the process is similar. I must identify the areas in the application that I wish to test, the English values for those items, and the additional language(s) used for localization. I also need a way to determine that the content displayed is in the correct language and alphabet; and that the text and characters displayed are in the correct context for the localized language.
Common Automation Tricks
For localization tests, it’s important that I have two variable instances for each string that I will test. Depending on how exhaustive I want to make the testing, the list of variables could be just a subset of everything that would appear on the page, all the way up to a pair of values for every repeating label or element within the application. To this end, having separate data dictionaries formatted the same way for each language is critical. The naming convention for each variable needs to be consistent.
For example, here are some abbreviated pairings of words, using French and German. Each term is a pair of similarly named variables, with ${valueA} being English and ${valueB} being the localization language:
| ${valueA} | ${valueB} |
|---|---|
| language | French (Français) |
| locale | fr |
| help_text | de travail |
| My_Settings | Mes paramètres |
| Creating | Création |
| Accounts | Comptes |
| ${valueA} | ${valueB} |
|---|---|
| language | German (Deutsch) |
| locale | de |
| help_text | finden Sie auch |
| My_Settings | Meine Einstellungen |
| Creating | Wird erstellt |
| Accounts | Konten |
The longer the text string, the more important it is to get the translation for those strings in the target language in the correct context.
Things That Are Hard to Automate
Some English words will have an obvious translation to a word in another language, but sometimes there are nuances and variations, depending on the language used. While it may be tempting to go to Google Translate and create a pairing of words and terms, the longer the phrase, the more important having a correct translation becomes. Working with someone who is fluent in the language to be localized is essential.
Of course, having someone who fluently speaks every language I wish to support may be impossible within my team. Fortunately, there are localization services that can be hired to provide translations for key phrases. Once those have been proofread and confirmed to be accurate, then creating pairings for those pieces of text is easier.
Another challenge is variable proliferation and keeping the values all in order. Rather than having a large table of values, creating different dictionaries for the words and phrases I want to use is a better approach. Treating each language and term as a pair of variables allows me to run the tests desired for each language without having to create needlessly long scripts.
By having the ability to source a unique dictionary for each language, the scripts created can be reused with each dictionary. By necessity, this also means that I can examine a subset of values on the page, rather than trying to look at the entire page and confirm all of the content displays correctly in the target language.
Common Themes
In this series, there are going to be some familiar patterns and areas that need to be considered for effective testing. Several of these are areas that could be combined into modules, considering I will likely use them frequently.
Known Data Set
In addition to having known values to look for in English (navigation items, labels, tags, etc.), I will also need to have matching values for each language and alphabet I wish to use. To this end, having a set of values that can be compared is essential. The values need to make sense in the context of the language being used. Using a consistent encoding format for text characters is also vital. Note that Selenium WebDriver uses the JSON wire protocol, which uses UTF-8 Unicode formatting.
Multiple Accounts, Users, and Roles
To examine the display languages, it helps to have a variety of accounts, users, pages, and profiles to determine whether the text in one account can be viewed and compared in another. Having accounts with similar values being created makes that possible. To allow parallel tests to run, using a value such as ${start_time} will be helpful. Having processes that create and delete this structural data between language tests allows for a direct comparison.
Cross-Browser Tests
Formatting of alphabets and how they are displayed varies within browsers. It is important to check that the text is lining up correctly and doesn’t run off the end of the screen or wraps in a way that would not look good within the application areas.
Download your risk-free, full-featured version of Ranorex Studio now to experience the power of test automation.
Michael Larsen has, for the better part of his 20+ year career, found himself in the role of being the “Army of One” or “The Lone Tester” more times than not. He has worked for with a broad array of technologies and industries including virtual machine software, capacitance touch devices, video game development and distributed database and web applications. Michael currently works with Socialtext in Palo Alto, CA.
