Some international language keyboard layouts use modifier keys (such as Shift, Alt, Ctrl, or combination of these) to fit extended set of letters, numbers, and symbols and different variations in the keyboard. One such keyboard layout used in our community has mapped a symbol on AltGr+1 or Ctrl+Alt+1 which conflicts with the Markdown editor’s keyboard shortcut for h1 heading. Would it be better to respect the actual character typed (key) and not just based on the physical key pressed (code), then make decisions whether to trigger shortcuts only if the combination of the code and key attributes match certain criteria? This would only be an issue when a keyboard input is desired such as in the editor.
This is a rather serious problem for international communities. Recently, the Atom editor solved this issue elegantly and blogged about it.
We are open to improvements here provided nothing regresses on standard keyboards. afaik it is just really hard to get proper access to this information in JavaScript, but maybe something changed recently, I don’t know.
This is true and the Atom blog I linked in my first post talks about the issue and their solution in details.
For earlier versions of Atom, it was right about here that everything got really hard. Unfortunately, prior to Chrome 51, no API existed to help us determine that on a particular keyboard layout, a keystroke that looked like an alt-g actually inserted a @ character. In many cases, this misunderstanding caused no harm, but if the character collided with a binding (as was the case with @ on the Swiss German layout), that binding ended up shadowing the ability to type that character in the editor.
As that blog post notes:
With Atom’s upgrade to Electron 1.3, we finally had access to the promised APIs. Two new fields have been added to KeyboardEvent objects, a code property, which describes the physical key pressed as a human-readable string, and a key property, which contains the previously-unavailable information about the actual character typed by the user on the current keyboard layout.
In Chrome 51+, Firefox 23+, IE 9+, and Opera 38+ KeyboardEvent.key property is available.
Atom blog notes that even this new property was not 100% reliable to fight the ambiguity, so they did some custom solution to get the info from the OS itself which is beyond the scope of Discourse. However, even just considering what is available now would probably solve the issue for Discourse as the key bindings are very limited in the editor as compared to the Atom where every plugin might add a few key bindings. In case of Atom though, these bindings are user customizable, which is not the case with Discourse, so the issue is more severe here.
Also, for anyone interested in taking this on, please realize Discourse is using a third party tool for Keyboard Shortcut handling. So you may end up wanting to correct it there instead of within Discourse specifically.
