Localization Testing Best Practices for Mobile and Web

Software localization is a process of translating and adapting a product such that it can be marketed to users whose cultures and languages differ from that of the original authors. It is a tedious and laborious job that is difficult to completely automate. Fortunately, best practices exist to ensure thorough and effective localization.

Plan for Localization Early

The effort to achieve excellence in localization is not as simple as hiring a native-speaking translator to rewrite the text within an app or web site. Consider carefully the effort to adapt your software to these additional factors:

  • Over 100,000 language characters exist among the world’s languages and many languages’ fonts differ significantly in size. Properly localized, your software must account for this on output and input.
  • Word lengths in various languages differ significantly, which your GUI must handle gracefully.
  • Some languages read right-to-left, which sets expectations for the layout of elements and pages.
  • Only the U.S., Liberia and Burma do not use the metric system.
  • Dates, time, currency and other numerical representations differ among regions.
  • Cultural differences can create misperceptions or embarrassments with regard to the content of your app or website.

Hire One or More Localization Consultants

End-to-end localization firms with native speakers/residents in your software’s targeted areas are expensive but invaluable. If you are new to localization, try performing a pass-through with automated tools with the help of one or two freelance translators. The experience will be enlightening. If it went well, then hire a local consultant as a reviewer and editor.

The ideal localization consultant does more than simply translate. They should provide sound marketing advice to ensure that emotional or rational marketing messages in your content are expressed appropriately but with equal power in the target language and culture.

Take Care with Strings

Every single string displayed by the software should reside in property files separately from program logic files. Assign each string a symbolic name, e.g. UserName = “User Name,” which is used within the program itself. New strings can replace the originals without changing the program itself.

Once strings have been converted, be sure their character encoding is Unicode/UTF-8. This makes subsequent localization steps and processing by tools, such as debuggers, less time-consuming.

There are other best practices for text localization:

  • Strings must never be concatenated as this leads to the creation of grammar errors.
  • Avoid the use of idioms, which can be difficult, if not impossible, to translate.
  • Include with string definitions any necessary punctuation. This might require duplicate strings with and without punctuation.
  • Avoid using the same word or phrase in different contexts as that often leads to unintended meanings. For example, in English alone there are dozens of contronyms, which are words that have opposite meanings in different contexts such as overlook, sanction, trim or screen.

Internationalizing Dates, Times and Currencies

Date, time and currency representations have many regional differences. Even for the same currency, some countries place the currency symbol in front or behind the amount. In these cases, the static indirection used for strings will fail. Often, such differences can be captured as macros or subroutines, which other parts of the software use inline or at runtime. These can be segregated in separate files to accommodate localization.

Avoiding GUI and Layout Issues

There are numerous ways a GUI can go wrong from one language to the next. For example, a GUI designed for English speakers, when internationalized for Arabic, must flip the entire layout of a page to make content appear in a natural organization for Arabic users. The layout of buttons, text fields or pull-downs may also exhibit an unnatural flow among them in a left-to-right language.

Text fields designed for the average length of English words are too short for many languages such as German. This can be a problem for visible labels on buttons or other widgets as well. If the interface is designed to re-size/re-order controls to accommodate labels or screen size, the entire layout may be morphed into something rather awkward looking.

Modern interfaces routinely provide context-sensitive help on controls via a hover action. If you do not localize both the GUI and Help system simultaneously, these may diverge significantly.

Test It Again, Sam

Once localization has been thoroughly applied, you need to re-test the software in much the same manner as the original language version to ensure no mistakes have occurred that would affect the user’s experience negatively.

Many organizations underestimate the amount of planning, development and testing required for quality localization. The effort and cost must be carefully scoped and weighed against the advantages of marketing to a new region. Once the investment has been made and experience gained, however, the effort is normally less for localization to other countries and regions.