[
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:
http://www.ics.uci.edu/pub/ietf/http/related/iso639.txt
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:
http://www.chemie.fu-berlin.de/diverse/doc/ISO_3166.html
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 ?
Thanks,
Antoine
Kit Lo
IBM Eclipse SDK Globalization Technical Lead
Hi all,
I submitted a patch over the Babel Editor to migrate it to the Eclipse
way of doing things.
https://bugs.eclipse.org/bugs/show_bug.cgi?id=215036
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
[2].
Thanks for reading,
Antoine
[0]:
http://www.eclipse.org/articles/Article-Speak-The-Local-Language/article.html
[1]: http://www.eclipse.org/articles/Article-Internationalization/how2I18n.html
[2]: http://wiki.eclipse.org/Eclipse_Globalization_Guidelines
--
http://www.lunar-ocean.com/blog_______________________________________________
babel-dev mailing list
babel-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/babel-dev
_______________________________________________
babel-dev mailing list
babel-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/babel-dev
--
http://www.lunar-ocean.com/blog
Plugin internationalization:
Strings:
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.
Resources:
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:
icons/image.gif
Its French version should be placed into:
nl/fr/icons/image.gif
Its Brazilian portuguese version would be placed as:
nl/pt/BR/icons/image.gif