hodgef / simple-keyboard

Javascript Virtual Keyboard - Customizable, responsive and lightweight

Home Page:https://virtual-keyboard.js.org/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Automatically convert input to 3/4 syllables in Korean layout

dzikoysk opened this issue · comments

Current implementation of Korean keyboard is still that primitive that it's just hard to use - mostly because of:

  1. It doesn't resolve all syllables (simple-keyboard/simple-keyboard-layouts#1963)
  2. The hint box doesn't make sense, because the keyboard should automatically render the most up-to-date state as there's just one allowed variant - just like it already works for 2-letter syllables.

As a good example of Korean keyboard, I'd choose the branah keyboard:

You can pretty much randomly type various letters, and you'll see the huge difference between the output. It'd be nice to have at least these 2 adjustments :)

Hey @dzikoysk,

I don't think it's possible for me to make these changes, as I'm not familiar with Korean and the keyboard you've linked for reference doesn't appear to be Open source. If you have time, I would appreciate if you could submit a PR with your solution. Thanks!

Could you show me the function in the current implementation that already converts automatically 2 letters into one symbol? I guess it should be a matter of it, as these syllables are already displayed in the candidates tooltip above the keyboard.

The current logic is very rudimentary, just a regex match performed on the layoutCandidate items:

const layoutCandidates = Object.keys(layoutCandidatesObj).filter(

const candidateListPages = this.utilities.chunkArray(

One thing to note is that each key in the layoutCandidates object could point to several suggestions. Here's the chinese (pinyin) layout for example:

https://github.com/simple-keyboard/simple-keyboard-layouts/blob/6775b2402a0bcdfb3ba13772ba447f3d9686ab1a/src/lib/layouts/chinese.ts

layoutCandidates: {
    a: "阿 啊 呵 腌 嗄 吖 锕",
    e: "额 阿 俄 恶 鹅 遏 鄂 厄 饿 峨 扼 娥 鳄 哦 蛾 噩 愕 讹 锷 垩 婀 鹗 萼 谔 莪 腭 锇 颚 呃 阏 屙 苊 轭",
    ...

Since the korean layout was generated through script, it was a bit difficult to arrange it like that, but a dev who knows Korean could do so and verify that the output is good.

Thanks, I'll try to take a look at it tomorrow. I guess that the auto conversion to the first candidate could be simply configurable through layout options - by default it'd be 2 as it is now & e.g. Korean layout could customize this property to 4, so it could work out of the box for users. Korean is pretty much the same as our alphabet, despite the fact they're grouping 1-4 letters into a single symbol, so such completion (like in Chinese) is not really applicable to this language and we can safely auto-convert to the matching symbol immediately.

Ok, I found some time to take a look at the codebase. Unfortunately, I see that the auto-conversion of 2 letters into one symbol is a side effect, not an intentional behavior of the keyboard:

output = source + str;

As it's purely handled by JavaScript:

"\u110b" + "\u1175"
// > "이"

Because of that, such enhancement is more likely a feature request rather than an adjustment of an existing implementation and that's beyond my scope as I don't feel comfortable enough in the current codebase to make this change (not my tech stack & I don't have enough time for such a deep dive into that :/). For my needs, I'll try to craft sth on top of the existing API/I'll just move to my custom keyboard, as it seems to be just easier approach in that case.


Speaking of some references that could be useful for people that would like to implement this in the future: I think that the approach with list of all variants is kinda redundant as all the variants can be calculated:

So in theory, 27 letters should be enough to properly handle a full keyboard with that formula. I'll try to implement it using the current listeners from API and in case of any achievements, I'll let you know about that.

I literally tried all the available JS libraries/pet projects on GitHub to process Hangul and all of them were definitely worse than the algorithm used by Branah keyboard. Their impl is minified, so it's hard to understand what's going on there, but after a while I've definitely figured out the core impl, so I've converted it into a library. I released it & added an example with react-simple-keyboard:

In the example, I also had to use custom Korean layout, because korean.ts uses some strange variants, not the base symbols. Anyway, it works now:

firefox_LIMkoIJPM4.mp4

Thanks for sharing! Indeed the korean layout uses variant letters, this was raised on the Discord chat last March:

[...]
Ok I think I understand the issue. Check this out:
https://codesandbox.io/s/elastic-brook-2dj6hb?file=/src/index.js
For that first Letter in the layout called "Pieup" there are several variants.

In simple-keyboard-layouts, we use this one:
https://www.compart.com/en/unicode/U+1107

However there are also these ones:
https://www.compart.com/en/unicode/U+11B8
https://www.compart.com/en/unicode/U+3142

Only the last one of these, meaning u3142 is the true "default", the others are variants
This is why your fonts are not applying to the variant "letters" we use. This is not something I have the time to fix for the whole layout right now, but if you want to give it a try and perhaps send a PR I would really welcome that

https://discord.com/channels/498978399801573396/498978399801573398/1088388045172129793

I will keep note of these shortcomings and point to this thread, so people are aware of the issues & your workaround. Thanks!