Why You Should Give Localization Testing Top Priority

If you envision a successful business in a global marketplace, i.e. your software product should address users in different countries, localization testing should become an essential part of your globalization process from the very beginning.

When it comes to quality in localization, teams often tend to focus more on inspecting specific parts of a software product for functional problems rather than creating an integral strategy for localization testing and quality assurance. Let’s take an in-depth look at what it means to assess the market fit of your multilingual product.

Defining Text Fields, Labels and Form Size Limitations

From a visual perspective, an application might look different depending on the language that it is currently using. For example, if an application was developed with a single language in mind (e.g., English), the width of the fields is usually shorter than in other languages. while if an application is developed for another language (e.g Russian or German) the labels and the fields usually take more space.

Software engineers should know from the beginning the maximum length of each field is to make the application visually appealing for a user. There are two most common problems when doing localization testing of the content appearance:

  • Fields are shorter than the text. In this case, the text is overflowing from the field.
  • Fields are appearing properly, but truncated by using a dots (…). In this case, while it might seem correct, this is not an ideal way to present information to the user. Truncation should be avoided as much as possible.

The best way to resolve those issues is having a defined size of the fields from the beginning and where truncation is unavoidable, reducing the text size might be a good solution. A test engineer plays a crucial role in making sure that all dialogs, pop-ups, and messages are appearing correctly.

Accessibility Validation

Although it might seem initially like localization and accessibility are not closely linked, those two things depend and complement each other in many ways.

When a team starts to think in terms of adding accessibility identifiers to all forms and text fields, it motivates everyone to unify those labels and name it properly. Further down the road, it makes it easier to find necessary text fields and labels in the code. Unification plays an important role, as well as having a naming convention across the project.

It is also equally important that modern applications are developed with accessibility in mind – having an application ready to help users with a disability is definitely a plus.

Right-to-Left Test Approach

One topic that is frequently left out during the design phase of the application is a right to left (RTL) scenario. The most common languages that write from right to left are Arabic and Hebrew.

Making sure that an application is translated is one thing, but engineering an application to be properly formatted for correct language display is another thing. It’s much more effort because in many cases, it also involves creating separate assets for LTR and RTL.

For example, if there are arrows present, they should be properly flipped and appear familiar to the user. Failure to do so will result in a mixed experience, where your interface is partially adapted, but still not fully polished.

Fortunately, modern software is designed to handle this use case well. Usually, a small modification to the configuration file can accomplish this

For example, on Android, adding those two lines forces the layout to be flipped:

android:layoutDirection=”rtl” 

android:layout_alignParentRight=”true”

A Test engineers role is to verify that all the strings, assets and other content appear properly displayed when changing the language. In the case of an exception to this rule (for example, not technically possible), it should be discussed within your team beforehand.

Translation Context Verification

Context matters, so it’s crucial that the translation team is aware of it. For example, the term “mute” usually means disabling sound functions. But simultaneously, it could also suggest archiving a mail or disabling something in the program. Using the wrong terminology would confuse a user and possibly make them use the software incorrectly.

It’s not always possible to have a large team of translators available onsite, but at least making sure that contractors do their best to properly translate the application is a must. It’s not acceptable to have translation errors in a modern application.

Best practice would be to train your localization team by explaining the meaning of specific terminology within your application. It is even better if they use the application daily themselves. In the end, a qualified linguist should review the whole translation corpus in its final form to guarantee an error-free product build.

While Quality Assurance Engineers are capable of verifying localization problems in general, this becomes a different topic when it comes to the quality of translation. Test engineers cannot speak every language and for that reason, that main resource that should be relied on are the localization team themselves.

User Environment Simulation for Location Testing

Users of multi-language applications are physically located all across the world. There might be different features available for different countries and even regions within the country.

For testing purposes, it’s important to have a way to simulate an environment that is as close as possible to what the user actually experiences That includes simulation of:

  • IP address location. This usually involves using a VPN service.
  • GPS location. There are software utilities available to make the software think that GPS coordinates are different from where a user is actually located.
  • Operating system locale. The application either depends on a specific account setting, application setting or operating system locale. Most commonly, the application depends on a system locale. That’s why it’s important to verify that locale is respected. Proper language should be displayed on switching the OS language.
  • User’s account. If an application requires having a specific user account then proper testing involves creating accounts for each language.
  • Custom operating systems for specific markets. In some cases, there are specific operating systems set only for that market. In this scenario, those operating systems need to be installed to have a proper environment.
  • Using SIM-cards available for targeted markets. Some smartphone application depends on a specific cellular network signal. If that’s the case for your application, then having a correct SIM card for testing is an important aspect.

When considering simulation for localization quality assurance, it’s important to understand that while simulation does a good job finding issues, nothing replaces physical testing. To be sure that software properly works for a specific market and location, it’s best to have a test engineer or a group of test engineers physically present there.

Localization Testing Is a Must

Making an application fully internationalized and localized takes effort. That’s why it’s important to be disciplined and set things correctly from the start. Localization quality assurance is a set of good practices that an organization applies to a software product; to make it work, all team members should recognize how valuable it is – not just the QA team.

Why You Should Give Localization Testing Top Priority
5 (100%) 10 votes
Author
Dmitry PhraseApp Content Team
Comments