Home > Articles > Programming > Java

How to Test Your Internationalized Eclipse Plug-In

  • Print
  • + Share This
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.
First published by IBM developerWorks at http://www.ibm.com/developerWorks.
From the author of

Editor's note

This article reflects Eclipse release 2.0.

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.

  • + Share This
  • 🔖 Save To Your Account