Discussion:
[gui-dev] Notice to translators
Philippe Verdy
2004-09-27 17:53:06 UTC
Permalink
I am performing lots of cleanup in resource bundles currently usedin
LimeWire, in order to make them fully synchronized with LimeWire 4.1.5+.

Most of the changes are finished, and basically consisted in checking badly
named resources, fixing the resource order, finding duplicate resource keys,
checking actual English/translated status, adding some missing "evident"
resources, and getting a more exact view of the translation status.

You'll see that the message bundles include now "LOCALE_*=" headers that are
used to specify the locale parameters, and help generating now the
translation status page on LimeWire.org:
http://www.limewire.org/translate.html.

I have slightly modified the Java source script that Sam Berlin made to
regenerate this page from our MessageBundles. This source is stored in our
repository and can be compiled separately:

$ javac CountPercent.java


(1) When run without parameters, it just displays a simple status about
existing resources on the standard output console:

$ java CountPercent
Total Number of Resources: 1070
---------------------------------
(ar) 086.64%, count: 0927 (Arabic: ?Ö?ä?ÿ???ÿ?® ?ÿ???ÿ???ÿ?¿?Ö?è?ÿ?®,
?ÿ?»?Ö?ê?Ö?ä?Ö?è (?Ö?à?ÿ?Á?ÿ??))
(be) 001.12%, count: 0012 (Belarussian: ?É?æ?É?Á?É???É???æ?Ç?æ?â?æ?ü?É???æ?û
(?É
?æ?É?Á?É???É???æ?Ç?æ?â?æ?ü?æ?î))
[snipped]

Note that the "encrypted" output is the result of the UTF-8 encoding of
localized language names, when they are output on your ISO-8859-1 console.
Note however that this UTF-8 output is not the case for localized bundles
that don't need the UTF-8 encoding, i.e. those that use the Western European
Latin character set (ISO-8859-1), and that are output as they are in the
.properties file (these bundles have no associated source .UTF-8.txt files).

The percentage is determined by counting uncommented properties that are set
with basic keys found in the base English bundle. Basic keys are all those
keys *not* found after the "OPTIONAL" part of the English bundle, detected
by its leading comment banner. Thanks to Sam for finding this technic.

I have slightly modified this script part so that it will load base
resources for variant languages, without overwriting the variant values (I
needed that to perform some resource coherence checks).


(2) When run with the "html" parameter, it generates the HTML page with the
similar status that will be used on the LimeWire.org site. Redirect this
output to a file to save it and view it in your browser:

$ java CountPercent html > translate.html
$ start translate.html

The statistics generated are the same as when running CountPercent without
parameter.

(actually this output will be generated and stored on the LimeWire.org
website by the LimeWire's web admin, so you won't see the result of the
server-side includes that generate the page headers and footers).


(3) I have added the "check" parameter, to perform various coherence checks
on the bundles. For now this parameter allows detecting only the badly named
keys (typos that may come from manual editing of localized bundles), or
extra keys that may be present in translated bundles, but not in the base
English bundle:

$ java CountPercent check


I will add other checks:
- detecting duplicate key names found in the same bundle, that may come from
incorrect copy/paste operations.
- check the effective translation status of resources (to list keys that
have the same value in English and in the translated file)
- check translations whose value in English is equal to the value of another
key (for example the various "OK" buttons), and listing keys that expose
differences in their translation, or that are left untranslated.

And I will probably soon add a "reformat" option to regenerate the localized
bundles, using the English file as a template for the generation order and
for the existing comments (this will save me lots of manual work with
incoming translations, or when files need to be upgraded). Making those
files automatically at the correct format with the same line numbers ease
the manual checking of incoming bundles, by comparing them side by side (it
would also allow accepting translated bundles generated with some Properties
Editors that don't keep the resources order when saving files, because It
could automatically regenerate the correct order and the missing comments
from the English file).

Possibly, I will make a "publish" option, to create the minimum bundles
needed for publication in the software: it will generate a directory in
which all MessagesBundles will be cleaned of their comments and blank lines,
and translated resource values that are equal to the default English one.
This would allow creating a smaller MessagesBundle.jar.

For now I need to finish the cleanup and upgrade of all bundles. But I
suggest that the LimeWire team compiles the new version of CountPercent,
that also include now a more detailed status of existing bundles, and also
because the percentages displayed have changed a lot since my upgrading work
(which took a a lot of time because of many manual editing and various
coherence checks).

Thanks.
Philippe.
Sam Berlin
2004-09-28 14:46:29 UTC
Permalink
Thanks very much for touching up the script that generates the html &
percentages, Philippe. I have re-run the CountPercent and put an
updated version of translate.shtml on the website, located at
http://www.limewire.org/translate.shtml . Thanks also to the many
translators who have helped LimeWire to be internationalized.

Thanks,
Sam
Post by Philippe Verdy
I am performing lots of cleanup in resource bundles currently usedin
LimeWire, in order to make them fully synchronized with LimeWire
4.1.5+.
Most of the changes are finished, and basically consisted in checking
badly named resources, fixing the resource order, finding duplicate
resource keys, checking actual English/translated status, adding some
missing "evident" resources, and getting a more exact view of the
translation status.
You'll see that the message bundles include now "LOCALE_*=" headers
that are used to specify the locale parameters, and help generating
http://www.limewire.org/translate.html.
I have slightly modified the Java source script that Sam Berlin made
to regenerate this page from our MessageBundles. This source is stored
$ javac CountPercent.java
(1) When run without parameters, it just displays a simple status
$ java CountPercent
Total Number of Resources: 1070
---------------------------------
(ar) 086.64%, count: 0927 (Arabic: ?Ö?ä?ÿ???ÿ?® ?ÿ???ÿ???ÿ?¿?Ö?è?ÿ?®,
?ÿ?»?Ö?ê?Ö?ä?Ö?è (?Ö?à?ÿ?Á?ÿ??))
?É?æ?É?Á?É???É???æ?Ç?æ?â?æ?ü?É???æ?û (?É
?æ?É?Á?É???É???æ?Ç?æ?â?æ?ü?æ?î))
[snipped]
Note that the "encrypted" output is the result of the UTF-8 encoding
of localized language names, when they are output on your ISO-8859-1
console. Note however that this UTF-8 output is not the case for
localized bundles that don't need the UTF-8 encoding, i.e. those that
use the Western European Latin character set (ISO-8859-1), and that
are output as they are in the .properties file (these bundles have no
associated source .UTF-8.txt files).
The percentage is determined by counting uncommented properties that
are set with basic keys found in the base English bundle. Basic keys
are all those keys *not* found after the "OPTIONAL" part of the
English bundle, detected by its leading comment banner. Thanks to Sam
for finding this technic.
I have slightly modified this script part so that it will load base
resources for variant languages, without overwriting the variant
values (I needed that to perform some resource coherence checks).
(2) When run with the "html" parameter, it generates the HTML page
with the similar status that will be used on the LimeWire.org site.
$ java CountPercent html > translate.html
$ start translate.html
The statistics generated are the same as when running CountPercent
without parameter.
(actually this output will be generated and stored on the LimeWire.org
website by the LimeWire's web admin, so you won't see the result of
the server-side includes that generate the page headers and footers).
(3) I have added the "check" parameter, to perform various coherence
checks on the bundles. For now this parameter allows detecting only
the badly named keys (typos that may come from manual editing of
localized bundles), or extra keys that may be present in translated
$ java CountPercent check
- detecting duplicate key names found in the same bundle, that may
come from incorrect copy/paste operations.
- check the effective translation status of resources (to list keys
that have the same value in English and in the translated file)
- check translations whose value in English is equal to the value of
another key (for example the various "OK" buttons), and listing keys
that expose differences in their translation, or that are left
untranslated.
And I will probably soon add a "reformat" option to regenerate the
localized bundles, using the English file as a template for the
generation order and for the existing comments (this will save me lots
of manual work with incoming translations, or when files need to be
upgraded). Making those files automatically at the correct format with
the same line numbers ease the manual checking of incoming bundles, by
comparing them side by side (it would also allow accepting translated
bundles generated with some Properties Editors that don't keep the
resources order when saving files, because It could automatically
regenerate the correct order and the missing comments from the English
file).
Possibly, I will make a "publish" option, to create the minimum
bundles needed for publication in the software: it will generate a
directory in which all MessagesBundles will be cleaned of their
comments and blank lines, and translated resource values that are
equal to the default English one. This would allow creating a smaller
MessagesBundle.jar.
For now I need to finish the cleanup and upgrade of all bundles. But I
suggest that the LimeWire team compiles the new version of
CountPercent, that also include now a more detailed status of existing
bundles, and also because the percentages displayed have changed a lot
since my upgrading work (which took a a lot of time because of many
manual editing and various coherence checks).
Thanks.
Philippe.
_______________________________________________
gui-dev mailing list
http://www.limewire.org/mailman/listinfo/gui-dev
Loading...