[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [babel-dev] Eclipse i18n guidelines

Thanks for your answer Kit, please see comments inline.

On Jan 14, 2008 11:11 AM, Kit Lo <kitlo@xxxxxxxxxx> wrote:

1. Translated "properties files" should be suffixed with the locale name. That's the standard Java Resource Bundle way of searching the translated resource bundles. Eclipse enhanced the searching capability for translated markup files (HTML/XML) since we cannot add any suffix to an HTML file name (like welcome.html -> welcome_ja.html) because that will break the links in the HTML files. When the special variable $nl$ is added to the search path, Eclipse will search the nl folders for the translated markup files.

2. I prefer to keep the English properties files in the code plugin, and package all the translated properties files in the NL fragment plugin. That way, software installers can provide an option to the user to install the "additional" language files during install. If an English user who does not need the "additional" language files, he can run in English and skip installing the additional NL fragment plugins and reduce the footprint.
Is it possible to sum up 1 and 2 and include them in the guidelines wiki page ?

I took a shot at it, please see the attached file.

I understand Pascal's argument. But then the software installer has to make sure that "at least one" NL fragment plugin is selected during install. In the case of simple plugin without a software installer, for example, plugins downloaded from Plugin Central, how do we ensure that the user also download and install "at least one" NL fragment plugin?

3. I couldn't find the section in [1] requiring us to create one properties file per package. (Point me to the section, I will look again.) But, I don't think it's required.
It is in the "Guidelines for managing resource bundles and properties files" paragraph:

To achieve these goals, we propose the following guidelines:

Use a properties file per package, and qualify the keys by class name

It is not required, just a strong incentive for best practices. My personal experience with String externalization led me to think that one properties file per plugin is good enough, as long as you use the class name as prefix for the key. I don't know if that should be considered a best practice.

4. Read http://java.sun.com/j2se/1.4.2/docs/api/java/util/Locale.html for the supported language codes and country codes:

The language argument is a valid ISO Language Code. These codes are the lower-case, two-letter codes as defined by ISO-639. You can find a full list of these codes at a number of sites, such as:

The country argument is a valid ISO Country Code. These codes are the upper-case, two-letter codes as defined by ISO-3166. You can find a full list of these codes at a number of sites, such as:

Thanks, any chance you could include a reference to this documentation on the guidelines page ?

Do you think it would be possible to modify [1] as to redirect people to the guidelines page, and/or to your article ?



Kit Lo
IBM Eclipse SDK Globalization Technical Lead

"Antoine Toulme" <antoine@xxxxxxxxxxxxxxx>
Sent by: babel-dev-bounces@xxxxxxxxxxx

01/11/2008 12:14 PM

Please respond to
antoine@xxxxxxxxxxxxxxx; Please respond to
Babel committers mailing list <babel-dev@xxxxxxxxxxx>

[babel-dev] Eclipse i18n guidelines

Hi all,
I submitted a patch over the Babel Editor to migrate it to the Eclipse way of doing things.


I discussed this patch with Pascal and we had some questions we wanted to address to this list.

I worked using this document
[0], "Teach Your Eclipse to Speak the Local Lingo" for reference.

Pascal, however, referred to
[1] "How to Internationalize your Eclipse Plug-In".

Apparently the document I used was more recent, and contradicts the other documents on some points.
We would like to clarify those points.

1. Should the properties files be placed in the nl folder, or should they be suffixed with the locale (messages_fr.properties for example ?)
2. Are the properties for the root locale and the plugin required to live in the plugin ? Could they be located in the fragment ? Pascal argues with reason that it would be a good way to economize hard drive space, and users could choose the fragment they are interested in. The document I referred to does not seem to allow this.

I have more questions on the subject that I didn't have the opportunity to discuss with Pascal.

3. Are we required to create one properties file per package, as [1] requires ? What are the advantages of such a method ? It does not seem to work well with the NLS approach.

4. Can you list all the suffixes used for the translation packs ? Apparently they follow the ISO 639-1 codes (
http://en.wikipedia.org/wiki/List_of_ISO_639-1_codes ), but for some reason brazilian portuguese is added (pt_BR).

I would be very grateful if you could answer those questions; Eventually we could clarify more on this page

Thanks for reading,



babel-dev mailing list

babel-dev mailing list

Plugin internationalization:

Strings should be externalized from the code using the PDE tools. They should be gathered into one or more properties files placed in the plugin classpath, next to the NLS subclasses that load them in memory.

The properties file for other locales should be arranged in fragments named "packs" (see [0] for which to place where).

Properties should be placed in the same folder as in the plugin, ie if my original properties file is placed in src/org/eclipse/ui/messages.properties, its French translation will go into src/org/eclipse/ui/messages_fr.properties

The translation of plugin.properties should be placed at the root of the fragments, following this rule.

Textual resources and/or images depend on the locale.
Those files should be arranged in fragments in the same way strings are. They should be located into a nl/{locale} folder placed at the root of the fragment

For example:
an image needs translation:
Its French version should be placed into:
Its Brazilian portuguese version would be placed as: