How to Internationalize your Eclipse Plug-In
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
June 2002
This article is a roadmap for writing Eclipse plug-ins destined for the international market. We'll begin with a brief review of the motivations and technical challenges of internationalization, followed by step-by-step instructions for internationalizing your plug-in. We'll finish by examining how these steps were applied to the internationalization of the Eclipse Platform itself.
An old joke in the internationalization community goes like this:
"A person who speaks three languages is called trilingual. And a person who speaks two languages is called bilingual. So what do you call someone who only speaks one language?"
"American."
Today, providing a software product solely in English is no longer acceptable from a usability, quality, marketing, and in some cases, legal standpoint. Enabling your product for the world market simply makes economic sense. And the enablement process is relatively straightforward, as this article will show.
A few notes before we begin. Because the Eclipse Platform adopts the internationalization implementation provided with the Java SDK, it's helpful to read the Java Tutorial: Internationalization trail before continuing. The tutorial presents a fine overview of the issues and steps involved in the process. We will assume that you've already read the tutorial so we can underscore the key points, surface other noteworthy items, and cover Eclipse-specific issues and steps in this article. And when you run into unfamiliar terminology or acronyms in this article, jump to our glossary.
Overview of internationalization
Internationalization is the process of creating software for the world market. Besides the economic benefits, some countries require products to pass certain localization requirements set by the government before it can be introduced to their markets.
The process of internationalizing the Eclipse Platform was accomplished in two steps:
NLS-enabling the product.
Translating the product.
This step covers coding techniques and user interface design issues. Enabling a product for National Language Support (NLS) ensures the product is designed for national language function and uses proper APIs to handle national language data. During this step, smart coding practices -- such as avoiding hardcoded strings, making input buffers large enough to hold translatable text, properly parsing strings that contain non-Latin characters, not localizing strings saved as part of a file format, and isolating the national language elements from program code -- must be weighed and considered so the translation can be completed with minimal expense and effort.
This step involves translating the domestic language elements into a foreign language. As with words and phrases, pictures and symbols may also be interpreted differently by various cultures. It is during the translation verification step that all translations are reviewed for contextual accuracy, icons or clip art are modified to ensure there are no user misinterpretations, and page layouts are checked for inadvertent text truncation. While verifying the product's functional integrity after translation, this step also looks for hidden cultural impacts.