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

Phill,
Thank you for the clear explanation.
I learn something about Java. You are an expert, don't you.
(If I have questions in the future, I will come back to ask you... Ha,ha,ha, :-) )


Phill> Did I forget to give you the parameters "-encoding UTF-8" in the command line for native2ascii ?

Phill>  * If you don't specify the encoding of the source file, then the conversion would depend on the host on which you run 
"native2ascii",


Yeah, I knew the Command Option (parameters) about Encoding in ""native2ascii  tool.
But following your guidance, I didn't think it is necessary to do it (spesify the endocing).

At this moment, I don't have any critical problems,
but I will try the Encoding method once more to see how it goes (for my studying).

Thank you for your help, Phill.

Kay


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



> 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.

Hmmm.... "ANSI" is not an actual encoding. Your method is equivalent but you change the source encoding of the "ANSI" file is in 
fact probably MS codepage 932 (if you are using a japanese version of Windows, and your current codepage is 932 in the command 
window where your run the "native2ascii" tool.

I was not wrong in my guidance; both methods use a editable source text file but stored in different encodings. Normally, to run 
"native2ascii" to convert from a editable plain text format to a format with Unicode hex sequences and ISO 8859-1 characters only, 
you must specify the source encoding of the file.

Did I forget to give you the parameters "-encoding UTF-8" in the command line for native2ascii ?

* If the source text file is in UTF-8 format the command line is:
  native2ascii -encoding UTF-8
    < MessagesBundles_ja.UTF-8.txt
    >  MessagesBundles_ja.properties
* If the source text file is in codepage 932, the command line is:
  native2ascii -encoding CP932
    < MessagesBundles_ja.CP932.txt
    >  MessagesBundles_ja.properties
* If you don't specify the encoding of the source file, then the conversion would depend on the host on which you run 
"native2ascii", because not all hosts have the same encoding. In LimeWire development, it would be impossible to determine which 
encoding is used in each "native" file. So the choice was to use a common encoding for source text files and UTF-8 is the only one 
that is supported on all platforms and that can support every local native encoding (badly named "ANSI" in Windows, when it fact it 
is one of the local Windows codepage).

Even worse: the "ANSI" designated codepage for Windows is not necessarily the same as the one used in command windows (which use the 
"OEM" designated codepage as set by CHCP or by the OS once it has booted), or at boot time for loading kernel device drivers (which 
uses a "boot OEM" designated codepage which is different on chinese/japanese/korean versions of Windows from the normal "OEM" 
codepage used elsewhere).

The "Boot OEM" codepage is fixed for each localization of Windows and is not changed with CHCP and this erxplains why Windows kernel 
drivers, .386 or .SYS, have specific versions for each localization of Windows, if they contain localized messages, because their 
native encoding is different and this boot OEM encoding does not support all languages (the same is true for binary applications and 
DLLs which use a system-speciic "ANSI" encoding, but newer applications and DLLs for Windows, as well as kernel mini-drivers in DLL 
formats can use Unicode instead of this system specific ANSI codepage); the support for Unicode is still not available at boot time 
when loading kernel drivers, because the support for unicode and other codepages is loaded sometime later as a kernel driver, after 
other critical kernel drivers (this is still true in XP and even in Vista).

In Java programming, the Boot OEM is never used, because Java does not run any component at kernel level (all runs in user space). 
But the ANSI and OEM codepages are still used: they are typically equal on Japanese/Chinese/Korean systems (unlike European 
Latin/Greek/Cyrillic, Hebrew, Arabic and Thai systems where they differ for historic reasons but where the "boot OEM" and "OEM" 
codepages match). So your 'ANSi" codepage is actually differrent from mine and from another use in China or Korea.

That's why we do not depend on Windows "ANSI" or "OEM" codepages: even if one of them is supported on your version of Windows, it is 
not necessarily supported on another version of Windows! Only UTF-8 (and ISO 8859-1, which is NOT any Windows codepage!) are 
supported on all platforms supporting Java (your japanese codepage 932 is not supported on all other systems, and even varies across 
Windows versions!

This instability of Windows codepages (especially the large CJK codepages which have lots of variants and updates!) is not desired 
and in fact unpredictable, and we support only UTF-8 as a stable alternative to ISO 8859-1 encoding, that works with all languages 
and on all Java platforms (whatever their OS type and exact version or update).


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