Notice to translators

"Philippe Verdy" <[email protected]> Mon, 27 Sep 2004 19:53:06 +0200
Newsgroups gmane.network.gnutella.limewire.translate,gmane.network.gnutella.limewire.core.devel
Message-ID <023f01c4a4ba$d8842df0$b51d7e52@VENGEROV>
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.

_______________________________________________
translate mailing list
[email protected]
http://www.limewire.org/mailman/listinfo/translate