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

Hello, Phillippe.

Thank you for your great help.

Following your advice, I tried but failed in the middle of the process.
I would be very pleased if you give me one more advice.
(If my English is NOT clear, ask me again please...)


Phill said>> (1) Method of construction
Phill said>>   native2ascii < MessagesBundle_ja.UTF-8.txt > MessagesBundle_ja.properties

YES, I did.


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


YES, I did.... with WinZip Tool,    BUT..........

After that, when I open the LimeWire, an Error Message comes up on the screen,
which seems to be like "Consistency Check Process" or something.
The Message says, "One or more necessary files appear to be invalid. This is generally caused by a corrupted installation.......".
This is because "MessagesBundle.jar" has been changed/modified, isn't it.
So, I am not able to launch the LimeWire.

What's wrong with what I did?
I suppose I need to do some more things to keep the consistency of the files...


I would be very happy if you give me any advice.
Thanks,

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