Skip to content

Conversation

@seorgiy
Copy link

@seorgiy seorgiy commented Jan 18, 2026

Problem

The keyboard shortcuts requires using a Latin-based keyboard layout.
For example, Ctrl+k on the Russian layout would result in Ctrl+л.

Assumptions

  • We want to stay with github/hotkeys library
  • We don't want to use event.code instead of event.key, as it discussed here
  • We don't want to mess with the KeyboardEvent due to possible browser-specific troubles and the security reasons
  • Hotkeys should work simultaneously in a Latin and non-Latin variant

Solution

Duplicate all the hotkeys for language-specific variants based on provided language key maps such as { k: 'л' } for the Russian example. This PR contains the Russian hotkey map and the functionality to add more.

Concerns

  • Still not sure we shouldn't switch for event.code approach
  • If we add a lot of key maps, it may lead to some conflicts, so we probably should make them user-controllable like an option «add keyboard support for: [multiple select from allowed keyboards]». But it doesn't make sense until we agree on the approach
  • In general this PR conflicts with custom shortcuts but it's mergeable

@kolaente
Copy link
Member

Hey thanks for the PR! I'll do a proper review later, as the 1.0 release is right around the corner.

If we add a lot of key maps, it may lead to some conflicts, so we probably should make them user-controllable like an option «add keyboard support for: [multiple select from allowed keyboards]». But it doesn't make sense until we agree on the approach

Can't we auto-detect the keyboard that's used and switch based on that? Another option would be to switch based on the selected language, but that might not be the best indicator.

@seorgiy
Copy link
Author

seorgiy commented Jan 24, 2026

It's worth mentioning that I'm not a front-end guy at the first place, so please don't full trust me on this.

But the more I researched the issue, the more convinced I became that we should consider switching to event.code specifically in the Vikunja case, and then the hotkey reassignment would also start makes sense. For now even if I set myself Ctrl+л instead of Ctrl+k, then the English layout will not work for me. While I constantly change the language back and forth, like any other it guys, in order to describe the task in my native language with code inclusions, for example. So I expect hotkeys to stay persistent, as in some game, not in the way like «A goes for Add Task, so in Russian it should be Д for Добавить задачу, which is direct "Add Task" translation». On that topic I can refer to this article.

Can't we auto-detect the keyboard that's used and switch based on that?

There is banch of security reasons why you can't get full info about the user's keyboard before they type anything, so at best case you can create something like pop-up which goes like «We see you typing in Chinese, do you want to enable Chinese-hotkeys support?». And this UX sucks.

Not sure I can promise you a PR with full conversion to event.code approach, but for now we wait for 1.0 release anyway. So please do a quick research on the topic in the mean time and mention me at the moment you will be ready to considering conversion, may be I will try to offer at least some help, dependce on my work load at the moment🫠

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants