Learning to love i18n
There’s an entire software development side to I18N, obviously. However, t I18N testing can be as critical as plopping language support into the code.
Applications need to go global, but language support comes at a cost. For one thing, supporting multiple languages demands additional testing rigor.
For many businesses trying to get ahead in an increasingly competitive world, multi-language support is a must-have feature. Internationalization – or I18N, as it’s frequently abbreviated for the 18 letters between the I and the N – helps to make software more accessible to users in other countries and also can provide an important advantage for non-native speakers in your own country.
There’s an entire software development side to I18N, obviously. However, testing can be as critical, if not more so, than plopping language support into the code. Below are five gotchas to look out for when testing software internationalization.
The German problem
German has become the poster child for words and phrases that can blow up on you when translated. Consider a label for a form with the text “Job Description.” That’s 14 characters in English, but the corresponding German phrase is “Arbeitsbeschreibung,” which clocks in at a whopping 19 characters.
This can create headaches on several fronts. The most obvious is that if the layout is tight and you didn’t make allowances for labels to expand and contract, you can end up with truncated text (or worse, abominations such as “Arbeit…reibung”). Modern responsive web design has minimized this issue, but in “pixel-perfect” apps such as games, it can bite you in a tender place.
Also, languages such as German can string many words into one long mega-word, which can cause text to break awkwardly in a paragraph if the text field is too narrow. Even if there’s space for all the text in, for example, a scrolling text box, it may end up looking like an ugly staircase if there are lines with only one or two words and a lot of white space at the end. And speaking of the end…
Up, Up, Down, Down, Left, Right, Left Right, B, A, Start
English speakers are used to certain conventions as to text and forms. Labels are on the left, fields on the right. But what happens when you translate an application into Hebrew (which reads right to left), or Asian languages that read top to bottom. As far as I know, there are no languages that read bottom to top, thank goodness, but you do still need to make sure that all of your text lays out correctly to the regional norms for each languages.
This may mean reversing the entire screen layout, or perhaps just changing justification rules. But when testing, you need to make sure that it make sense and follows the natural flow for native speakers.
Injection molding
It’s very common for programmers to create formatting strings that inject a value in the middle. For example, in pseudo-code, you might have something like:
print(“You have “ + balance + “ points.”)
Inevitably, someone points out that when you have one point, the application prints “1 points” – so you fix the code to:
if points == 1:
print(“You have 1 point”)
else
print(“You have “ + balance + “points”)
The problem with this strategy comes when you internationalize your software. When you substitute the “You have” and “points” into other languages, you can encounter problems with plurals. You may also have to watch out for things like the genders of objects (“el” vs “la” in Spanish, for example, and then add in plural rules for “los” and “las”). If you don’t get these things right when you do your string construction and formatting, you can end up with things that are the equivalent of “You has three banana in your carts.”
Reuse abuse
Most internationalization is accomplished by maintaining a dictionary file that maps a key (i.e. “THANK_YOU”) to a value in each language (Gracias, etc.). When a developer needs to internationalize a string, they usually start by looking for an existing mapping. That’s all well and good until you get a word that has multiple meanings.
Consider the entry for “trolley.” You might be referring to a cart in one case, and a form of mass transit in another. A shopping site might sell tea trolleys and also have directions for how to get to the store by public transportation. If the developer used the same word (el carrito) for both, you might end up asking your customers to ride a beverage cart to the store.
Of course, blindly literal translations of idioms or jargon can also lead to hilarity down the road. In general, you really need a native speaker (or at least a highly proficient speaker) to QA internationalized application versions.
Dollars, cents, and other regionalization
Does your application display currency information? How about dates? temperatures?
Well, depending on the region, there can be very different conventions for how to display them. In France, the Euro symbol goes after the amount, while in the UK, it goes before. Europe uses DD/MM/YYYY while the U.S. uses MM/DD/YYYY. This can affect not only display fields, but input fields too.
Metric vs. Imperial units is another fun example. Consider this variation on an earlier code snippet.
if temp == 1:
print(“It is one degree out”)
else
print(“It is “ + convertToLocal(temp) + “degrees out”)
In this case, convertToLocal is a function that converts to the device/user’s unit preference (C or F). If it’s 32.5F (1C), you end up with “It is 1 degrees out” because the comparison isn’t done on the localized temperature. This type of stuff crops up all the time.
A final word
Testing I18N functionality isn’t just a matter of making sure that all the text in the application appears to be in the correct language. Formatting, context, appropriate grammar, and differences in conventions can all lead to software that is off-putting to someone in a difference region, or even downright offensive. If you’re going to make the effort to localize your software, it makes sense to invest in appropriate testing resources.
Automation is revolutionizing the worlds of business and IT. The world of testing is no exception. From simple scripts to recorders, and systems that use artificial intelligence, test automation allows testing to be done at scales that were impossible just a few years ago. Learn more about test automation today.
by James Turner
James Turner is a developer with over 40 years of experience spanning technologies from LISP Machines and Z80 assembly language to Docker, Swift, and Java. He is the author of two books on Java development and one on iOS enterprise development. He lives in Southern New Hampshire along with his wife and son, and is currently developing mobile applications for a Fortune 50 company.
