Re: Help me about "Test a New Translation (Japanese)"

Phillippe,

Just for your information,
this is very small thing and not so important, but I found out one thing.
Just in case, I send you this information.


Phill >> Now include the generated .properties file into the LimeWire bundles.
Phill >> Open "MessagesBundle.jar" with a zip tool, and put the .properties file into it,


It works successfully WITHOUT doing this.
Just I put the newly generated .properties file in the same folder.
That's all.
LimeWire automatically picks up the new JP.properties and load it.
Perfectly working now.


Thank you for your help.


Kay

----- Original Message ----- 
From: "Philippe Verdy" <[email protected]>
To: "Kayoko Sawada" <[email protected]>; <[email protected]>
Sent: Thursday, November 09, 2006 4:42 PM
Subject: Re: [trans] Help me about "Test a New Translation (Japanese)"


Hello Kay,


(1) Method of construction

You must first edit your Japanese translation as a plain-text UTF-8 file;
Save it as "MessagesBundle_ja.UTF-8.txt"

Then use native2ascii to convert it to ISO-8859-1 using special Unicode hexadecimal escapes with the form "\uXXXX" for each Unicode 
codepoint which is not ASCII or ISO-8859-1:

native2ascii < MessagesBundle_ja.UTF-8.txt > MessagesBundle_ja.properties

Now include the generated .properties file into the LimeWire bundles. Open "MessagesBundle.jar" with a zip tool, and put the 
properties file into it, along with the other bundled .properties files for all other languages (the JAR internally contains NO 
subdirectories for bundled .properties files).

This is exactly the way LimeWire builds its translations. all those operations are automated from the set of easily editable UTF-8 
resource files. If a language does not use any character out of ISO-8859-1 (for example German), the conversion through native2ascii 
is not needed, and so the German bundle is directly saved as:

"MessagedBundle_de.properties"

And this .properties file is still integrated into the "MessagesBundle.jar". This method of construction is very standard for all 
Java applications which are delivered as compressed JARs (ZIpped archives containing all application code in .class files and 
properties files stored in the archive.)

The other location where LimeWire looks for properties files is the application's directory for its binaries (.EXE, .DLL, or startup 
scripts), but they are not necessarily in the same directory as the one used to store the .JAR files, and LimeWire FIRST looks into 
the "MessagesBundles.jar" at run-time (whose complete filename is listed in the Java's CLASSPATH). But this works reliably only with 
the development version (where class and properties files are not packed into JARs, taking much space on disk). The actual LimeWire 
runtime is installed with JARs because it is faster and simpler to install, it saves lots of disk space (and it also increases the 
performance of startup time due to reduced disk I/O), and because it allows checking fast the runtime files against possible 
corruption.


(2) Selecting the translated file to transmit to LimeWire via email

Note that we highly prefer that you edit your Japanese file using UTF-8, and that you send your UTF-8 file to us, rather than the 
generated .properties file, i.e. send us the "MessagesBundle_ja.UTF-8.txt" file which is directly editable with a standard UTF-8 
text editor. This is effectively the file that is used as the source in the automated build process, and the file which is kept in 
the source repository. The .properties file is automatically generated from the .UTF-8.txt file, as well as the JAR.


(3) About the prefered Email attachment format

We also suggest that you send your "MessagesBundle_ja.UTF-8.txt" packed into a compressed ZIP archive in email attachment (to avoid 
corruption by email agents that are sometimes modifying the encoding of the attachment, thinking thatthis is allowed for text files, 
but that fail to properly handle its character set, or that may insert additional linebreaks within the attached text file, as they 
incorrectly think this is safe for text files).

This recommandation is general every time you are sending program source files through emails. Email agents are sometimes doing such 
transforms only to avoid using a Base64 encoding for the attached text file, and make the email envelope format still readable. This 
is really a bad option used by email agents that should never transform attachment files which are not inlined with the email 
message body. But anyway there still exists such agents, (including in mail transfer SMTP agents of some ISP) that's why compacting 
a source text file into a ZIP is always an excellent idea. This recommandation of ZIP is NOT specific to LimeWire. Don't worry about 
the ZIP format, it is safe for us, and we do support it in our email agents and mailboxes, as well as antivirus tools (but please 
don't use other compressed archive formats such as .RAR, .7Z, .TGZ archives or .GZ and .Z compressed files... because not everybody 
on this list has the tools available to support it).

The ZIP format in email attachments is not necessarily the one with the best compression ratio, but it is good enough for sending a 
single source file through email. And this universal format is supported by really lots of tools on almost all platforms. Some other 
Linux-only projects prefer the .TGZ format (gzipped .tar archives created by using the Linux/Unix "tar" tool and then compressed 
using GNU's "gzip" compression tools) or .TAZ (.tar archives compressed with Unix tool "compress"), but LimeWire is not specific to 
Linux and the .TGZ and .TAZ formats are rarely supported on Windows and Mac OSX without first installing and additional environment 
for GNU tools.



I hope I was helpful by explaining you all the details.
Thanks. Philippe.

----- Original Message ----- 
From: "Kayoko Sawada" <[email protected]>
To: <[email protected]>
Sent: Wednesday, November 08, 2006 4:56 PM
Subject: [trans] Help me about "Test a New Translation (Japanese)"


> My Lime Wire version 4.12.
> Language: japanese
>
> Following the reference of the page "HOW TO TEST A NEW TRANSLATION",
> I am trying to test the new translation, but it doesn't work...
> Since I am struggling for some days but can't figure out the problem yet.
> Can you help me???
>
> Problem and what I tried...:
>
> 1. First, I encode the language file from UTF8 into Unicode, which is named "MessagesBundle_ja.properties".
> When I launch LimeWire, the language file is ignored and default (English) becomes available instead.
> Then, when I click [Language] from the Menu in order to change the language,
> there is NOT the option [Japanese].  ONLY the selection of [Japanese] is missing in the list...
>
> 2: Then, I tried...
> The language file is UTF-8, which is named "MessagesBundle_ja.properties". (without encoding it)
> When I launch LimeWire, the language file is (taken up) loaded successfully.
> But the all letters in the LimeWire got turned in strange characters and it's impossible to read.
> There IS an option of [Japanese] in the language selection in the Menu of LimeWire.
> (Strictly I can't read, but I can guess and click, then I can see the Japan Flag.)
>
> Note: For encoding, I tried some ways,
> sush as "native2ascii"(Java2 Dev Kit StandardEdition) tool and 2 other "converter" softwares.
>
> What is wrong!?!?


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