Current Status = Active Development, Chinese, Japanese and Korean are valid .language files currently being built. along with various Charset drivers (valid but empty). Only the Chinese, Japanese (both UTF-8) and Shift-JIS Charset drivers have valid Locale StringID responses when queried, everything else is lacking content and function. the Chinese, Japanese and Korean Language modules currently register with the "perception.library" directly once they are loaded. System Intergration = ***silent***, IPrefs sets up locale during system boot, When Chinese, Japanese or Korean are selected, English is preserved as the primary input language with UTF-8 as the Charset of choice. Japanese is currently including Hiragana and Katakana Conversion Tables internally. Registration with Perception.Library also triggers an internal "Perception-IME" process. There is an InputHandler also registered as part of Perception.Library with FIFO forwarding of Keyboard input being queued and pushed to the Perception-IME process. Each time the user presses a Key... any valid "Key-DOWN" event will trigger Perception to update the internal representation of current input text. Key-UP events will trigger display refresh and active forwarding of conversions. Due to the nature of the Internal Buffering, I have pushed off processing of Keyboard Input onto my own process due to there being a search requirement as part of Candidate Selection and also User-Interaction, this precludes a recursive "input.device" runs twice scenario (which would also provide for deadlocking the OS very quickly). Additionally, in making the core operation and OS awareness a central library, I have limited the Language Libraries to only providing essential functionality without code duplication (only ONE InputHandler for example, not LanguageInputHandler duplication). I am also manually writing out and updating a set of tables for Kanji readings, mainly due to there being multiple ways to use each Ideographic Kanji for Japanese. One of the problems is due to the phonemes in Japanese only being approximately 50 sounds with the number of Kanji counted in thousands. An additional detail is that Unicode defines a "common Chinese, Japanese" code range set. Hiragana is 0x3040-0x309F Katakana is 0x30A0-0x20FF The Common Range for Kanji (Chinese Hanzi) 0x4E00 to 0xA000 providing "CJK-Unified-Ideographs" with 20992 Individual Ideographs, 0x3400 to 0x4E00 providing "CJK Unified Ideographs Extension A" with approxiately 1000 additional Ideographs... 0x20,000 to 0x2F,FFFF providing "CJK Unified Ideographs Extension B" 15x4096 Ideographic Glyphs. With that being both Chinese and Japanese, I have opted to write up initial support as initially translating to Hiragana and then allowing trigger keys to extend for a second conversion using a prebuilt lookup "tree" of data. I am ***manually*** writing up a list of what is the Official and also a listing of "Unofficial" Japanese Kanji from the above Glyph ranges. There is no way I am hand-coding ALL of that information so I will be pre-building tables based on Dictionary Glyph order (Hiragana String to Kanji String Conversion). and all this needs to happen relatively quickly, which dictates keeping the data properly sorted. If anyone knows any Language that is currently supported and can provide a quick translation table from typed to displayed Glyphs, I'm willing to acccept submissions in text as "ASCII=UTF8" styled formatting (the is a Hexidecimal 0xA0 End-Of-Line marker) and label the text file with the name of the Language in English with the first line being the native name in the above formatting. I will be okay with adding additional Perception.Library aware languages providing UTF-8 encodings as needed/requested in addition to the existing libraries. If anyone wishes to do so...they may check out a copy of Perception-IME in it's current state and begin work on writing their own .language by copying and modifying any of the Chinese/Japanese/Korean as a template. Currently I have written everything for AmigaOS 4.1+ SDK materials however I will not stop anyone from porting the code and adapting it for Classic(3.x and earlier) or alternate(MorphOS/AROS) branches. My intentions are to provide a template for the above and also at least one example entrypoint not based entirely on automated tools into programming on AmigaOS. And as per usual, Flames and negative comments can get trashed, if anyone wants to support my efforts...feel free to contact me c/o this site.