Why Localization Testing is About More than Language

A software product can’t achieve global domination without internationalization (I18n) and localization (L10n).

Internationalization is the first step: this process requires that a product have the ability to support other languages and regional formats. When done well, it makes localization (perfecting a product for each region/language on an individual level), much much smoother. But regardless of how skilled the internationalization team, localization and localization testing must occur before deployment to a new, previously untouched user base.

Unfortunately, many companies still don’t take this seriously, and international users are faced with obnoxious issues every single day. The English-heavy focus of most products is continually apparent to users in many non-English speaking countries.

Grammatical errors, nonsensical imagery, horrendous responsiveness—all of these come into play. So while accurate translation is essential, there are tons of other factors to be aware of during localization testing.

UI elements affected by language

First off, let’s look at the design elements affected by language that testers always need to watch out for:

Character counts & design space

The most common problem faced by localization is having enough space for translations.

What would take 30 characters to say in one language could be said in 4 in another—meaning there could be too much space, or too little. Words can fall outside of buttons or margins, sometimes becoming obscured or invisible.

Images with text inside

Testing teams are often presented with a product or site that’s been fully translated except for the images.

Certain words might be purposefully kept in the original language (because the intended user base knows them or the inclusion of foreign words is part of the app’s stylistic experience) but other images may have been simply forgotten about. Unless testers have been notified otherwise, any images that have text in the wrong language for that audience need to be logged.

Ungrammatical sentences with UI elements

Here’s an interesting localization conundrum: drop down menus inside of text sentences.

Imagine if a budgeting app’s transaction entry were worded like this:

It would be a huge challenge to translate. For any mixed UI elements that have passed through the internationalization process, testers need to check that they’ve been properly localized in terms of placement and grammar.

Mobile responsiveness

Localization is a huge conundrum for mobile responsiveness. Changes in string sizes can wreak havoc on layout, to the extent that sometimes different layouts are required. Nothing can be assumed, which is excellent device coverage is necessary.

Testers should be using devices that are commonly used in that region. Certain brands will have a lot more market presence than others.

Additional issues to hunt for during localization testing

Yes, language has a big impact on UI elements, but there are also issues that stretch beyond language itself:

Imagery and icon meaning

Luckily, there are popular icons that are generally understood around the world:

• Magnifying glass for search
• House for home or dashboard
• Gears for settings
• Plus sign for add or create

But edit, cancel, go back or go forward can sometimes pose a challenge as there may be existing norms for the meaning of a slash, X, or arrow (especially depending on RTL or LTR reading directionality).

Only native translators, testers, designers, or other resources can ensure full comprehension with icon and imagery use.

Keyboard shortcuts and swiping functionality

For web based applications, there has to be a complete understanding of keyboard shortcuts. Commonly used keyboard shortcuts in one language may not even be possible in another (if that key is absent from a native keyboard), or they could serve a different function.

Swiping directionality and norms come into play for mobile apps or web-based apps that are optimized for touch.

Currency and date formats

Even in countries that speak the same language, there will be different currencies and different standards for date formats.

The fact that the month/date order is reversed between the UK and the US isn’t necessarily known to everyone in either country, so if something is presented incorrectly (a pre-scheduled task or version history details), user experience can suffer dramatically.

Currency, on the other hand, isn’t just about presentation, because currency must also be correctly calculated in real time, particularly for banking, retail, and other transaction-heavy sites and products.

Layout directionality

RTL languages require lots of adaptations beyond backward/forward/redo/undo icons. Layouts, menus, text boxes, dialogue boxes, and edit boxes must be mirrored.

Why localization testing often requires functional testing

Let’s think about currency calculation again.

Pulling in live currency data might not have existed before the internationalization process, meaning this new backend function requires fresh functional testing.

Many of the other factors mentioned above also necessitate additional functional testing—which is really at the crux of why localization testing is about more than language.

So many new issues can be introduced in updates made to menus, formats, and layouts.

Basically, things can break. When a product is localized, it likely needs a full round of functional testing to ensure that no new issues have been introduced during the process. A review of translations and design elements could be just the beginning.

Testers will be asking:

Do the translations make sense in context? Do they look right on the screen?

But they will also be asking:

Has localization caused any existing features to break? Do all new tasks and functions required by localization work properly?

Creating a team feedback loop for successful localization

The need for continued communication between design, development, and QA is super apparent during localization testing. QA lessons learned can impact future efforts to localize a different OS and can even strengthen the team’s skill at the early stages of internationalization.

With so much interaction between language and UI, localization mostly begins with design. And when QA is involved early on or can pass on learnings, the process only gets easier over time. Sharing commonalities and root causes for localization issues strengthens the organization’s capability of going global.

Testlio’s testers are always involved in the overall lifetime success of a product. It’s why we have long term testing teams, why testers love to collaborate, and why we submit requests and suggestions (not just bugs).