Keyboard remapper to offer a fallback for non latin keyboard users #17583
Conversation
|
does this also fix #17579? |
|
I don't think websites are supposed to implement keyboard remappers. I don't know of any website that does that. Github has an extensive list of keyboard shortcuts and no remapper. |
|
They simply don’t work. If I switched my keyboard to Arabic and tried pressing “g d” to go to the dashboard, or s to go to the search bar, it will not work unless I switch my keyboard language back again to English.
However, in a website like Youtube, keys do work normally. k to pause, l and j to move forward and backward, ... they work regardless of the keyboard layout. no idea how they implemented it.
|
|
@ikrami1 No this does not fix the nvui ... it is the preparation. @ornicar I understand your caution. Let me test the github case and the youtube case to see if it changes my approach. Just a bit more context in the meantime: |
|
The tested situation with shortcuts on Github and Youtube (which is what I expected based on @ikrami1 's comment). Github does not translate their interface and they rely on the characters (event.key) for the shortcuts. QWERTY and AZERTY users will be able to go to wiki tab typing 'g w' (letter w being in 2 different locations on the keyboard). Users with non latin keyboard don't have access to shortcuts. Youtube uses characters and fall back on qwerty positions. Example to mute the video:
So, we would do like Youtube |
|
@ikrami1 while I was looking for another solution that would not involve Lichess code, I found out that there is a very quick way to cycle through your keyboard layouts.
I don't know how you know the layout your are using when you are back on your computer after a pause |
|
Thanks for the tip! I actually already know and use these shortcuts regularly. My issue isn’t about not knowing how to switch layouts—it’s more about convenience and predictability during gameplay.
When a Lichess shortcut fails because the active layout is Arabic, I can still press the screen reader shortcut and it announces the current layout. But ideally, I shouldn't have to do that or switch layouts just to make a Lichess shortcut work.
I was actually looking for a solution that doesn’t depend on modifying Lichess code, but rather something that makes shortcut behavior layout-independent. Something like triggering actions based on physical key positions (key codes) rather than the character values tied to each layout. That would make the experience more consistent, especially for blind users relying on muscle memory.
|
fixes #16925
The idea is initially for the nvui interface, but the solution seems to fit mousetrap as a fallback if no binding is found.
Point of reflection/discussion: the fallback is systematic. Is there any case we would not want it ? (then we would add a preference)
I went for qwerty only because it seems to be the vast majority. There are other types of hybrid keyboards (like arabic / azerty) but we may never hear of them.
Demo here
The demo may not be compelling unless you consider that hybrid keyboards have the qwerty chars printed on them.