Are there any plans for simplified/traditional Chinese and Korean input methods on MorphOS? I use both frequently in my day to day life and it's one of the (few) reasons keeping me from using MorphOS as a main OS.

Thank you

[ Edited by chinchilla 10.05.2016 - 23:52 ]

Quote:

We certainly need to think about allowing proper Unicode input for the previous few applications that actually do Unicode... Problem with Asian languages is we don't really have anyone speaking those in the team so it's a bit hard to actually know what's needed there.

If you mean something like http://www.sayjack.com/type/korean/ , then that'd be really tricksy. I can name exactly three applications on MorphOS that could get close to displaying what you type in Korean (Odyssey, Scribble and SSHCON), but even then a lot of stuff related to input would have to be rewritten to allow for a more complex input system. The current stuff, designed by Commodore, does allow typing multiple keys to create a single character, but it does not cover the situation in which you need to display something in-between keystrokes or allow the user to pick a final letter/sequence out of multiple possible combinations from the Romanised input (at least that's a common case in Japanese, as far as I know).

[ Edited by jacadcaps 11.05.2016 - 16:34 ]

@ chinchilla

Same for me. Although MorphOS is my main OS, I have to run away from it for certain tasks like everything about Unicode because the current support is just selective. I am in need for this as well as I am writing and reading CJK documents almost every day. For short text passages I can work around using Google translator but that is slow and needs an extra resource. For Kana and Kanji/Hanzi it pops up lists of possible characters same as IMEs on other platforms do, so the simulation of that behaviour is quite okay and Odyssey does the job. Picking the right character from that list through arrow keys works and this is how it should work in a MorphOS native input.device, too, I think. Therefore I think it should not be necessary for now to have a special handling of in-between keystrokes as a small popup list would do the trick. The way Google translator makes it usable in OWB would be a big step forward already. We already have that in Shell for tab completion of file names.

@ jacadcaps

Yes, the link you found shows a quick overview of Hangul characters, and I understand why it will be tricky.

The easy part about those character systems (Kana, Kanji/Hanzi but not Hangul) is that they are steady characters, meaning you type Chinese "ma" and then the list of characters with all tone combinations shows up. There is no change to the characters, you just pick one from the list or filter out by further editing (which we don't have yet in Shell's name completion and would be a nice feature). An improved version, though, would be to allow the direct input of the tone like "ma4" to select the fourth tone implicitly instead of walking through a popup list. Some IMEs do it like that. Although Kana, Kanji, Hanzi are build up from radicals (basic symbols) that are combined to a more sophisticated new symbol with a new meaning, you usually never enter them. Only a few IMEs allow that but it is quicker to enter the Romanised string instead and pick from the list or let the IME decide by content (i.e. by the meaning of the sentence that you write) which characters only make sense, e.g. selecting "ma5" automatically if a question mark follows as it is a question particle and most common at the end of an interrogative sentence.

For Hangul, though, it is a bit more complicated as you are writing with a special form of an alphabet. Because there are certain rules which way these letters can be combined and which way they must not, you usually don't pick a syllable or word from a popup list but continue to write and
insert blanks yourself or use the cursor keys to "escape" from further filling up a syllable but starting a new one. In certain situations a character can be placed legally in both - the bottom part of the left or the upper part of the right syllable. Should the IME pop up both of them and let the user decide? I don't think so. Funnily this makes typing Hangul more complicated than typing Kanji although Hangul itself is very simple. Although picking an entry from a list may lead to many mistakes, it could be filtered out by teaching the rules of writing to the IME. I prefer to "just" write characters same as I do with the Latin or Cyrillic alphabet, though.

Besides entering text, there is also the problem of post-processing. Hardly any of our applications is Unicode-ready as jacadcaps already mentioned ... and they do not support it because a standard way is missing in the OS. So writing CJK texts on MorphOS only makes sense if you can live with the current browser support through Odyssey. Otherwise you end up marking and copying the written text to the clipboard which can hold UTF-8 but then you can insert it almost nowhere as Shell and almost all MUI classes besides Scintilla.mcc cannot handle that, so you will see control characters only.
Additionally to that short list of jacadcaps there are more applications that could make use of Unicode support quite soon: the current TeXLive
distribution lacks Unicode support because MorphOS does not offer it (this is what the porter said). Hence, I have to TeX my CJK documents on another platform. Also, gTranslator seems to be just waiting for a centralised Unicode support as it already makes use of Scintilla.mcc.
VPDF supports marking and exporting Unicode characters through clipboard. This seems to be faulty, though, as pasting these characters to e.g. Google translator can input a totally different character. Example documents on request.
Also the font loading (at least in OWB) is extremely slow. On certain sites it can take minutes to load the page with a Unicode font (under full CPU
load) while it is up within second if not using a CJK Unicode font.

To sum it all up: yes, we need system-wide Unicode support and it is a difficult task. If the basic support is there, applications can more easily
make use of it. A nice way would be if e.g. existing MUI classes could be empowered to fully display UTF-8/16/32 such that old applications could display those texts without changes to the program. Not to speak of Intuition (window titles), Shell, file names in filesystems ...

How about supporting Perception-IME-master?
"Input Method Infrastructure on AmigaOS 4.x(PPC), AROS(need to port) and MorphOS(need to port)"
https://github.com/Belxjander/Perception-IME

> How about supporting Perception-IME-master?

Discussion between jacadcaps and Belxjander on that:

http://amigaworld.net/modules/newbb/viewtopic.php?topic_id=40572&forum=42#769036

@Sprocki

Yes, as you can see this is an enormous task and I don't even think it makes sense to try to add this before MorphOS goes NG. Even minimal stuff is not just "input.device" extensions as you call that (though that really does not belong to the input.device) - you need some support for this in the application as well. The app has to instruct the OS where to display the selection menu, the app needs to support drawing the temporary selection too and *changing* the input it already processed until it's finalized.

I've got some experience with this stuff from OSX programming and doing all this right is a complicated process. Don't even get me started on Arabic and other languages that aren't left-to-right...

[ Edited by jacadcaps 12.05.2016 - 19:50 ]