# Editor keyboard shortcuts conflict with some international keyboard layouts
**URL:** https://meta.discourse.org/t/editor-keyboard-shortcuts-conflict-with-some-international-keyboard-layouts/53969
**Category:** Feature
**Tags:** pr-welcome, keyboard-shortcuts
**Created:** [December 8, 2016, 5:20pm UTC](https://meta.discourse.org/t/editor-keyboard-shortcuts-conflict-with-some-international-keyboard-layouts/53969 "2016-12-08T17:20:01Z")
**Posts on this page:** 5
**Page:** 1
### Author:  [@ibnesayeed](https://meta.discourse.org/u/ibnesayeed)
#### Post date: [December 8, 2016, 5:20pm UTC](https://meta.discourse.org/t/editor-keyboard-shortcuts-conflict-with-some-international-keyboard-layouts/53969/1 "2016-12-08T17:20:01Z")
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.
> **[Sunsetting Atom](https://github.blog/news-insights/product-news/sunsetting-atom/)**
>
> We are archiving Atom and all projects under the Atom organization for an official sunset on December 15, 2022.
---
### Author:  [@sam](https://meta.discourse.org/u/sam)
#### Post date: [December 9, 2016, 12:38am UTC](https://meta.discourse.org/t/editor-keyboard-shortcuts-conflict-with-some-international-keyboard-layouts/53969/2 "2016-12-09T00:38:01Z")
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.
---
### Author:  [@ibnesayeed](https://meta.discourse.org/u/ibnesayeed)
#### Post date: [December 9, 2016, 1:01am UTC](https://meta.discourse.org/t/editor-keyboard-shortcuts-conflict-with-some-international-keyboard-layouts/53969/3 "2016-12-09T01:01:59Z")
> [@sam](#):
>
> afaik it is just really hard to get proper access to this information in JavaScript
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.
> [@sam](#):
>
> but maybe something changed recently, I don’t know
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.
> **[KeyboardEvent: key property - Web APIs | MDN](https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEvent/key)**
>
> The KeyboardEvent interface's key read-only property returns the value of the key pressed by the user, taking into consideration the state of modifier keys such as Shift as well as the keyboard locale and layout.
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.
---
### Author:  [@sam](https://meta.discourse.org/u/sam)
#### Post date: [December 9, 2016, 1:04am UTC](https://meta.discourse.org/t/editor-keyboard-shortcuts-conflict-with-some-international-keyboard-layouts/53969/4 "2016-12-09T01:04:37Z")
I added a #pr-welcome here in case anyone wants to give this a shot. But careful… there be dragons 🐉
---
### Author:  [@cpradio](https://meta.discourse.org/u/cpradio)
#### Post date: [December 9, 2016, 1:07am UTC](https://meta.discourse.org/t/editor-keyboard-shortcuts-conflict-with-some-international-keyboard-layouts/53969/5 "2016-12-09T01:07:38Z")
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.
[Repository search results · GitHub](https://github.com/discourse/discourse/search?utf8=%E2%9C%93&q=mousetrap)