This article shows you how to validate your internationalized product and prepares you for the types of common problems you can expect during translation testing. It includes an Eclipse plug-in that defines a Properties File Compare view that can help your translation testers find errors more quickly.

From the author of

From the author of

Translation verification testing

You followed the internationalization steps outlined in the first article of
this series,
How to Internationalize your Eclipse Plug-in,
then sent your national language (NL) resources (*.properties files, HTML files,
icons, etc.) to a translation center. The items are returned and you
reintegrated them into your product, but now what? To make all that investment
in time and money worthwhile, you must verify that your product works correctly
with the translations and that they are semantically correct in the context of
actual product usage. This process is known as Translation Verification
Testing (TVT).

TVT can be viewed from two aspects: process and technique. The process
that you adopt will likely resemble the one that you have already put in place
for your product's functional validation. But the particular
techniques that you will employ are quite specific and these choices also
impact the quality and efficiency of the testing process. This article will
outline translation verification techniques and classic errors and will provide
a tool that you can
download to
help your translation testers work more efficiently and effectively.

Ideally, the national language version (NLV) and domestic version of a
product are developed and shipped at the same time, with the translation being
tested before the domestic version is shipped. This is more likely the case for
the second and subsequent release of an NL-enabled product. However, in the case
of the first release, the domestic version may be released with the code already
NL-enabled, but before the translations are available. This is often unavoidable
since the language translation may take weeks or months, depending on the amount
of NL material, during which it serves little purpose to delay the release of
the domestic version.

Subsequent releases can reduce the delay between domestic and international
releases since the bulk of the translation and testing carries forward from the
prior release. When planning your validation test cycle, weigh the amount of
time and personnel that you expect to invest in proportion to the amount of
material that was affected by translations. In general, minor changes in the
translation materials are usually isolated risks, unlike functional
modifications where one bad line of code can disrupt the stability of the entire
system. This allows you to scale down the "version two" and subsequent
translation efforts considerably, on the order of two-thirds to one-half your
version 1.0 investment.