Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Input of Chinese, Japanese, and Korean languages. #3398

Open
c933103 opened this issue Dec 9, 2021 · 1 comment
Open

Input of Chinese, Japanese, and Korean languages. #3398

c933103 opened this issue Dec 9, 2021 · 1 comment

Comments

@c933103
Copy link

c933103 commented Dec 9, 2021

🚀 Feature request

📝 Description

To support Chinese, Japanese, and Korean language on the MuditaOS platform, it is necessary to not just displaying them, but also to allow user to type messages and notes in their languages.
Currently, in the i18n document for keyboard, it mentioned "Every language has its own files for upper and lower letters.". However, such assumption is incorrect for Chinese, Japanese and Korean languages, and it would not be possible to input Chinese, Japanese, Korean languages into the system using such form of system.

📝 Describe the solution you'd like

First, for simplicity, let begin with the Japanese input system. In Japanese, the most basic 5-tap system indeed follow a similar rule like existing rules in keyboard input file, letting user cycle each key up to 5 times to get the desired kana. However, there will be key for dakuten, hanadakuten, and small kana, which modify the kana, and thus changing the character that was entered before it.

Furthermore, what being described above can only be used to type in kana. In reality, Kanji, ideographic characters, is an important component of Japanese language. Systems are expected to guess, based on dictionary and user frequency, which kana/kanji combination are users trying to enter, and let users choose the correct combination.

And then, there's another input system for Japanese called 2-tap system. Since Japanese have 48 common syllables, and the regular method of entering kana require tapping each keys up to 5 times, an method have been developed to encode these syllables into two-digit codes. This way, no matter which kana the user want to enter, they will only need to tap twice, and one of the most popular arrangement make it that the first key being pressed will determine the syllable's consonant, while the second key being pressed will determine the syllable's vowel, producing a single consonant letter after two key press. This is something cannot be handled by MuditaOS's current input system either. Not to mention they will also have to go through the dictionary prediction process to guess and user select the proper kana/kanji representation of the characters.


Then, for Korean. I am not that familiar with Korean so please read the introduction part of http://kentlyons.net/pubs/korean-twid-chi06.pdf this essay for further information. But the key is, Korean Hangul characters are formed by combination of consonants and vowels and occasionally final consonants, it also allocate the keys utilizing the fact that vowels and consonants intertwines, and thus same key can automatically represent different parts of letter in different time. This is not possible to reproduce in current form of the MuditaOS input system.


So then it comes to Chinese. There are multiple ways to enter Chinese characters into mobile phone, different regions have different customs. The pinyin system, as an romanization of Chinese language, in Mainland China have essentially the same key mapping as the English keyboard, but then again like Japanese, it is the system's responsibility to map and predict which pinyin input correspond to which Chinese character based on dictionary and user usage frequency, and let user choose their desired character. There are also some other mapping to map each vowels/consonants directly to each keys, such that the letter's pronunciation can be determined within two tap, but that still require the system to judge which character is the sound supposed to represent, especially since Mandarin Chinese is a tonic language and user will not be required to enter tones. In recent years, there are more advanced form which require user only typing the initial parts of a character's romanization, and let the system predict what it might represent.

In Taiwan, the Zhuyin input method is widely used for input on phone. This is similar to pinyin in Mainland China, except it used dedicated bopomofo symbols to represent consonants and vowels in Mandarin Chinese, and have different mappings.

Most of these pinyin or zhuyin input system also feature helps that can help correct users input with less than full proficiency in Mandarin Chinese, and automatically provide candidate suggestion on what the user might actually want to type in despite they might have pressed incorrect key during the entering process

And then, among users and in area where Mandarin Chinese aren't as popular, there are also additional stroke input method, which mean users are allowed to type Chinese characters directly according to the way they are written, following the stroke order. But since same stroke order positioned differently could produce different characters, the system also need to predict which Chinese character the user want to type, and provide real time candidate for user to select the desired character. A multi-key is also available in most such system, in case user forget or unable to figure our exactly which stroke should be in which place or which order, allowing users to type a character out without complete memory of the total correct order of stroke of the character they intended to type.

And since stroke order are in some occasions different between Simplified and Traditional Chinese, and there are also some subtle differences between Traditional Chinese as used in Hong Kong versus as used in Taiwan, it is best to have different conversion table for each of the region for the Chinese characters.

📝 Describe alternatives you've considered

Speech recognition might be a simpler way to implement CJK input than figuring out how to fit these input systems into MuditaOS? But it would definitely be less usable, not to mention the problem with dialects which varies quite widely for both Chinese, Japanese, and Korean.

@Fantasticji
Copy link

for Chinese,it needs Simplified Chinese and traditional Chinese,pinyin system is enough for me.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants