Chinese, Japanese and Korean .language library skeletons ...

This forum is for discussion of the AmigaOS 4.x localization. This includes translation errors as well as proposals for improved translations, and other topics related to localization.
Post Reply
Belxjander
Posts: 291
Joined: Mon May 14, 2012 10:26 pm
Location: 日本千葉県松戸市 / Matsudo City, Chiba, Japan
Contact:

Chinese, Japanese and Korean .language library skeletons ...

Post by Belxjander »

I've initially coded up Chinese, Japanese and Korean ".language" libraries for LOCALE:Languages/

they currently open a couple of libraries in addition to locale.library.

If anyone wants to work from them for additional language support feel free.

I'm actively starting to deal with encoding Japanese locale strings into the Japanese.Language and additionally It will have embedded two sets of the core strings.

One set will be ISO-2022-JP and the other set will be UTF-8

User avatar
ssolie
Beta Tester
Beta Tester
Posts: 1010
Joined: Mon Dec 20, 2010 8:51 pm
Location: Canada
Contact:

Re: Chinese, Japanese and Korean .language library skeletons

Post by ssolie »

There is little point in working on these until we have an IME and input stream to handle the characters.

This kind of work is fine but we really need an input method first.
ExecSG Team Lead

Belxjander
Posts: 291
Joined: Mon May 14, 2012 10:26 pm
Location: 日本千葉県松戸市 / Matsudo City, Chiba, Japan
Contact:

Re: Chinese, Japanese and Korean .language library skeletons

Post by Belxjander »

@SSolie: The reason I have done the strings now is for an immediate set of test strings,

currently I am working on the InputHandler and trying to work up how to split it in half and only require the independant process to access any ".language" registered hooks for Input Modes.

Each "Language" will register as having 1 or more "modes" based on Glyph groupings (UTF-8 will be the default encoding for the Locale preferred languages listing).

Right now I am a little bit "into the darkness" with going past what I originally had in mind, however I am sticking with native libraries where possible.

a full set of complete UTF-8 strings can be found in the "Japanese.Language" and an incomplete set of "ISO-2022-JP" strings in the "Japanese_ISO-2022-JP.charset"

I have also managed to locate and confirm the "Native Language Name" for Korean and add that as well.

I'd estimate that I have maybe around 32-40% of the whole project completed but there is still a lot of work to do.

I have gone with a simple encoding for single glyph selections in UTF8 format currently and will be needing to execute additional calls into language libraries which register with perception.library.

I'm deliberately putting such calls as Hook methods to avoid messing with the official API call set.

But if anyone wants to try and use any of the existing hard-coded strings in the Japanese.Language module, they are fixed UTF-8 strings ready for testing.

I can also generate however many more as demand requires.

Post Reply