QShortcut really isn’t the problem though. For example in addcards.py QShortcut is used and to my knowledge works for every keyboard layout (see line 121).
In the add cards window on the other hand the shortcut for intendation doesn’t work, which expects Ctrl+Shift+.. As said in my comment above, I believe shortcuts.ts is the issue.
As a proof of concept I tested it out. In addcards.py (l. 139) another shortcut is used, set with QKeySequence as above and which is supposed to show the added cards history. Here’s the original code of the addcards.py shortcut for the history:
# history
b = bb.addButton(f"{tr.adding_history()} {downArrow()}", ar)
if is_mac:
sc = "Ctrl+Shift+H"
else:
sc = "Ctrl+H"
b.setShortcut(QKeySequence(sc))
b.setToolTip(tr.adding_shortcut(val=shortcut(sc)))
qconnect(b.clicked, self.onHistory)
b.setEnabled(False)
self.historyButton = b
I changed the sc = "Ctrl+H" part so that it says sc = "Ctrl+Shift+." and rebuild anki. The result is that this shortcut works (anki knows how to process it, unlike the same shortcut used for intendation which is not handeled by QKeySequence) and the tooltip changes accordingly too:
So why does the same shortcut not work for intendation? Because the shortcut for the intendation is using some custom logic, which probably doesn’t account for non english keyboard layouts.
The file extension of shortcuts.ts .ts indicates that it’s typescript. So if my knowledge is correct, that’s basically javascript. And in javascript the keyboard layout is correctly identified and used if event.key is used. event.code on the other hand shows the problem anki currently has (where you’d have to use the keys where the keys would be on the english layout). See the documentation I linked above.
Edit: I do know that ankis code doesn’t really use this exact function but it makes it easier to explain why the custom code might not work properly.
The custom logic anki uses for the intendation (and others) is way above my skill level though and while I’m not 100% sure that that file is the root cause of the problem, I would say that I do believe it’s a likely culprit.
I’d also like to add that translating the tooltip is absolutly not necessary and not the way to go. The shortcut should stay the same, always. But anki needs to be able to understand that the user pressed the correct shortcut keys (e.g. Ctrl+Shift+.), not just the correct location on the keyboard. What I mean by that is this: imagine the standard QWERTY layout. If a shortcut y existed and was mapped to some function, e.g. opening stats, I’d have to press y on a QWERTY keyboard to open stats. On that same position where the y in the QWERTY keyboard would be, there’s a z instead on a QWERTZ layout. A user with a QWERTZ layout wouldn’t press z though, just because the letter y would be on that position in an english layout. So if a user pressed y on a QWERTZ layout (where a z would be on a QWERTY layout), then anki needs to know what key has been pressed, not the code that might change for every layout (again, see documentation of event.key and event.code linked above). So it’s not an issue with translating tooltips, but an issue with the underlying code itself.
In the topic you linked someone mentioned that the russian keyboard doesn’t have a @ key readily available. Such conflicts would have to be resolved either by allowing to customize shortcuts keys or by using a shortcut that doesn’t have this kind of issue (though the first one is probably best, since there are a lot of keyboard layouts and even more of them that do not follow the standards).
