Keybindings do not work with non English language

Ctrl+Z works fine if i’m using English layout but Russian language does not work. I guess that does not work because app is listening for key. I can suggest checking code property if that’s the case.

[onemenzel]

German macOS user (QWERTZ) here. Here’s an example of what I have to use for which feature, despite the help dialog telling me otherwise:

• zoom in: cmd + ß
• stats for nerds: option + -
• zen mode: option + y
• send backward: cmd + ü
• bring forwards: cmd + +

… and the list goes on. I’d be grateful for a fix. It would be nice if at least the help dialog would state the correct shortcuts.

Provided that non-latin keyboards are dual-language, i.e. they have the latin letters printed on they keycaps as well (I believe this is mostly the case), and they adhere to QWERTY (unclear if this is the majority case)

the problem with adhering to QWERTY is that in most other languages, all the special characters are on other keys. So if you make a shortcut which involves a special character, it is almost certainly unusable. And unfortunately, there are many shortcuts in Excalidraw that use such keys. I think it would be a good start to move those to “letter keys”. Especially much needed shortcuts like zooming in and out (like cmd + i (for in) and cmd + o (for out)). I must admit that this would be quite unusual though. But I’d say better unusual than unusable 😄

I think it would be nice if there were a mechanism to switch keyboard layouts.

[dwelle]

Hey @mhsattarian. As far as I know, there’s no easy solution to this problem. If we use code, we break it for non-QWERTY layout users. If we use key, we break it for users with non-latin keyboards.

I skimmed the Mozilla blog post and I couldn’t find any recommendation.

From my experience, apps actually have been using event.which for the longest time which is similar to event.code. When event.key was introduced it seems to have replaced the “recommended” solution.

I don’t know what is worse. If we say “press A to use the arrow tool” and the user presses A and it does nothing (or the wrong thing) because the layout is different, or the user doesn’t know what key to press or cannot press anything because they use a different alphabet. I’d say the former is worse, because with the latter there’s at least some expectation that it won’t work or explanation why it doesn’t.

---

Alright, this is nice and all, but can we do something about this situation? I think to an extent we can (as I stated in previous comment).

Provided that non-latin keyboards are dual-language, i.e. they have the latin letters printed on they keycaps as well (I believe this is mostly the case), and they adhere to QWERTY (unclear if this is the majority case), then we can detect whether event.key is in latin, and if not, fall back to event.code.

This wouldn’t solve everything for everyone, but I think it would help a lot.

It will require some work and rewriting how we handle the keyboard, though.