Automation of L10n testing

This page aims at giving more background and detail about the suggestion to automate all or part of Localization testing work.

What is Localization testing?

L10n testing implies 2 main areas of testing.

Linguistic review

• Ensure translations are adapted to the target device (netbook, tablet, handset...) and audience, they are meaningful, culturally sensitive, and thus follow some defined style guidelines.

When performing linguistic review from translated files, every translations are indeed reviewed but a poor or missing context puts this work at risk as some translations may seem correct out of the context, and not that suitable when in situation.

When perform runtime testing, testers have a full context but one can hardly guaranty that every translation will be displayed, as scenarios leading to display certain error messages may be very difficult to reproduce.

UI review

• Ensure the UI rendering is optimal in a locale, translations do not break any functionality, there are no truncations (text being too long to display correctly), no widgets overlapping (some UI frameworks have the ability to adapt their widgets’ size to the text they display) nor any other cosmetic issue.

This work is relieved when applications were designed in the perspective of being localized (which is relevant to Internationalization/i18n). Translating from English is known to often increase text length and widgets should be organized in such a way that they favor a clean display.

For both linguistic and UI review, a good knowledge of testing scenarios is required in order to perform runtime testing (miscellaneous configurations, testing data presets…).

Investigation

So far, we didn’t find any open-source tool to handle automatically all or part of L10n testing, but TDriver offers the ability to do rendering verification through screen captures.

Links

Collection of wiki pages related to Localization
About internationalization/i18n and localization/L10n