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

Add Korean Hangul Keyboard Support with Chunjiin and Hanja Integration #38

Open
plumpdolphin opened this issue Jul 15, 2024 · 9 comments · May be fixed by #126
Open

Add Korean Hangul Keyboard Support with Chunjiin and Hanja Integration #38

plumpdolphin opened this issue Jul 15, 2024 · 9 comments · May be fixed by #126
Labels
High Complexity Requires a lot of time and effort Low Priority Get this done when you can

Comments

@plumpdolphin
Copy link

This is my petition for adding Hangul/Korean language support to the keyboard! 🇰🇷

I see essentially 3 levels that this could be implemented to as there are two common keyboard layouts and a secondary writing system, Hanja, which could be added as a nicety but is not necessary for daily use.

Stage 1

Standard keyboard layout for Korean typing maps 1:1 with the QWERTY layout and could be an excellent start to get going!

Stage 2

An additional common keyboard layout that would be good to have is the 10-key layout, which may be more difficult but is preferred by some. This layout is commonly referred to as the Chunjiin/천지인 keyboard for those who are interested.

Stage 3

The last possible stage of implementation, which I believe would prove most challenging is Hanja support. This would include typing out a syllable in Hangul/Korean writing and then have suggestions provided for all of the Hanja characters which match that syllable block.

I believe that is complicated enough to warrant it's own feature request once Hangul is implemented; I'm just mentioning it here to get the conversation started.


These are just my thoughts, and I'm happy to hear any other feedback, suggestions, or questions to get the ball rolling!

@midirhee12
Copy link

Can we add Chinese to this as well? It seems like there's voice language models for both langauges. It's just a matter of adding the support to use it. I assume that this is blocked until a keyboard is implemented.

@plumpdolphin
Copy link
Author

Can we add Chinese to this as well? It seems like there's voice language models for both langauges. It's just a matter of adding the support to use it. I assume that this is blocked until a keyboard is implemented.

I definitely think there should be a Chinese keyboard! It looks like there's already an open issue for Chinese language support which you could find here: futo-org/android-keyboard#707. Since it's going to have it's own layout and potential challenges, I think it's probably best handled separately there.

Note, the voice input works separately of the keyboard functionality, so even though there isn't a layout to type out Korean or Chinese, speech-to-text should still be functional!

@plumpdolphin
Copy link
Author

plumpdolphin commented Jul 24, 2024

Alright, I have taken first steps to fork, compile, and add a quick test layout to see if multi-key composition works automatically (handled by the OS) or if it must be handled by the keyboard. My suspicions seem to be confirmed that multiple characters are not converted into the appropriate character by Android and instead must be handled by the keyboard.

An example for those unfamiliar with the Korean language and typing, the Korean script called Hangul is split into syllable blocks which contain multiple characters. Anywhere from 1 standalone character for text abbreviations up to the largest blocks being 4 characters: 1 consonant -> 1 vowel -> 2 consonants, and always in that order.

For this to work, when a vowel is added it must check the previously pressed character to see if it is a consonant, and if it is, the consonant must be stripped of the previous syllable block and combined with the vowel that was pressed. An example of this would be like this:

ㅋㅣㅇ -> 킹 (King)
ㅋㅣㅇㅏ -> 키아 (Kia)

Where the ㅇ/ieung character is taken from the previous syllable block and combined with the following vowel.

Unless there is an existing system for this that I'm unaware of, I believe that makes this issue a much more challenging to implement and would require additional backend work in addition to a keyboard layout. If anyone else has ideas on how to resolve this, that'd be great, otherwise it's a bit out of my depth to continue.

Edit:
After doing additional research on the topic, it seems it might be best to utilize the existing libhangul/ibus-hangul project as the IME if possible to avoid rewriting the logic from scratch.

@plumpdolphin
Copy link
Author

Since the composition aspect is not functional, I will not make a pull request yet. However, I have created a QWERTY layout for the Korean language and added all of the appropriate metadata that I could find without a contribution guide. I tried to match the Samsung standard layout best I could, with a few issues I did not resolve (% and , not showing in moreKeys).

It's at least a decent starting point for anyone who'd like to try tackling the issue!
plumpdolphin/android-keyboard@dbcde6d

@midirhee12
Copy link

I can help if you need it for understanding the typical korean layout as well.

@plumpdolphin
Copy link
Author

Here is an current sample of the keyboard layout with the current broken bits:

  1. On the ㄹ key, it is set to !text/keyspec_currency which should be ₩ for KRW.
  2. On the ㅎ key, the moreKeys should be a % character, but that does not appear.
  3. On the ㅜ key, the moreKeys should be a , comma, but that also does not appear.
  4. Intermittent crashing because I most certainly missed something in configuration

image

@dean-futo dean-futo added Low Priority Get this done when you can High Complexity Requires a lot of time and effort labels Oct 16, 2024
@dean-futo dean-futo changed the title [Feature Request] Korean Language Support Add Korean Hangul Keyboard Support with Chunjiin and Hanja Integration Oct 16, 2024
@dean-futo dean-futo transferred this issue from futo-org/android-keyboard Oct 20, 2024
@tenextractor
Copy link
Contributor

tenextractor commented Dec 7, 2024

@plumpdolphin How commonly is the 10-key/Chunjiin keyboard used? The combining logic used for it is more complicated than Dubeolsik, so I have just implemented Dubeolsik and 난모음 (Danmoeum) layouts from Gboard

@plumpdolphin
Copy link
Author

@tenextractor, to my knowledge it is much less common than 두벌식/Dubeolsik, being primarily utilized by older demographics. Dubeolsik is the default layout for all smartphones as well as desktop/laptop keyboards, and would certainly take priority. 천지인/Chunjiin was originally designed for typing on phones with number pads--and though some people still use it out of habit--it's been mostly deprecated since smartphones have been popularized.

I don't have exact statistics on how many users there are for each, but I believe it would be fair to say it can wait. A large majority of users would be using either Dubeolsik and Danmoeum. Especially if the combination logic cannot be adopted from an existing, robust Korean IM project, then it doesn't seem worth the effort to implement Chunjiin at least for the time being; just my two cents!

Hope this helps! If you have any other questions, just let me know.

@plumpdolphin
Copy link
Author

I am adding to this issue further context. @tenextractor has made a couple of great PRs which I believe resolves this issue: one with keyboard layouts (#126) and one with a combiner (found here).

I think the combination of the layouts and combining logic as-is implements the all the functionality necessary to use the Futo Keyboard for Korean. I would encourage more people, build and test it if you can! I'm putting this here so those that come looking can find it, and hopefully with more eyes on it, it could be reviewed and potentially merged!

@abb128 abb128 linked a pull request Jan 6, 2025 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
High Complexity Requires a lot of time and effort Low Priority Get this done when you can
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants