The Korean base is not input.

[kuns0820]

HI.

There is a problem. microsoft > keyboard ms-korea The Korean base is not input.

ex) 사라ㅇ해 , 루ㄹ루ㄹ루ㄹ

Thanks!

[Mottie]

Hi @kuns0820!

I am sorry, I do not know Korean, so I do not understand the problem, nor do I know how to fix it.

I would appreciate it if you could submit a pull request, or share a solution in this issue... or modify the demo I included at the end of this response.

The source layouts in the ms-Korean.js and in the GreyWyvern Korean layout appear to have a very similar "normal" layout for the essential keys. Does the GreyWyvern keyboard work as expected?

If you are fluent in Korean, I would also appreciate it if you could share a translation of the _language_template.js. And if Korean has a method similar to Vietnamese Telex key combinations, an additional "combo" keys object would need to be included (see Vietnamese example.

I set up this demo using the keys and layout from https://www.branah.com/korean, but it seems like it is worse because nothing combines. If you have time, please modify that demo with the correct letters and or combos to make it work properly.

Sorry, I know that is a lot of work 😿

[fariskas]

Hi @kuns0820 , did you solve this issue?

[squarism]

I'm not a korean speaker and yes it seems like a lot of work. I've just lightly studied the Hangul writing system (which is delightful).

There seems to be existing work already on the definitions of the Hangul syllabic block glyphs. For example, hangul-js has a function that works like this:

hangul.decompose('가')
// => ['ㄱ', 'ㅏ']

Or even better:

hangul.compose('ㄱ', 'ㅏ')
// '가'

Using this while typing live would work like branah.com's keyboard. Some work would need to be done probably to handle spaces, the delete key and user experience type things. For example, a string of characters might be ambiguous but a space can be used to be specific (this is how the branah keyboard behaves too).

Take this glyph 갟 0xAC1F. It's made from ㄱㅐㄱㅅ. So it's ambiguous because you could mean 객 (the first three "letters"ㄱㅐㄱ). If you want to start a new word with ㅅ, you just hit space. That's how the branah keyboard behaves.

I'm not sure what other cases exist. I'm not sure if Mottie handles double consonants or double vowels as is. It looks like branah does not support turning vowel combinations into their combined form. ㅜㅣ would become ᅱ.

Using this library would add a dependency but make it easier to implement. I'm assuming this is not desired as jquery is the only dependency right now. ☹️

[Poitrin]

Take this glyph 갟 0xAC1F. It's made from ㄱㅐㄱㅅ. So it's ambiguous because you could mean 객 (the first three "letters"ㄱㅐㄱ). If you want to start a new word with ㅅ, you just hit space. That's how the branah keyboard behaves.

I think this is wrong. On Branah keyboard, if you type ㄱㅐㄱㅅ, you get 갟, yes, but if you add a 5th "letter" like ㅏ, ㅅ will be removed from 갟 and fusion with ㅏ to form 사.

This logic is, e.g., provided here: https://github.com/e-/Hangul.js