Inconsistent keyboard shortcuts on Turkish-Q layout

Anki Help
1

I switch between the standard English keyboard layout and the Turkish-Q layout many, many times a day, so I generally don’t worry about which one is active unless I need for spell-check to work. But Anki responds to keyboard shortcuts inconsistently (as in some work, some don’t) based on which layout I am using.

Mostly I have just tolerated this, but it is frustrating to have to guess which keys to use, and really eliminates the time-savings of keyboard shortcuts! I tested every shortcut I could find that is impacted by the English-Turkish layout change, but I might have missed any shortcuts that aren’t well documented.

Version ⁨2.1.65 (aa9a734f)⁩
Python 3.9.15 Qt 6.4.3 PyQt 6.4.0
Windows 11

Expected behavior:

Anki should respond to a shortcut based on where that character sits in the (active) Turkish-Q layout, regardless of the physical key on the keyboard that character uses. [It seems like all non-English-keyboard users would be served by the same rule applying to their layouts, but I can’t speak for them or test every layout!]

Basic differences between the English and Turkish layouts:
  • One alpha-character changes – dotted-i becomes undotted-ı
  • “Extended” alpha-characters ğüşiöç are added on 6 punctuation keys [{]};:'",<.> at the right
  • Punctuation from those 6 keys moves to various other keys, with a bit of trickle-down effect on other punctuation.

English-QWERTY_Turkish-QWERTY
English-QWERTY_Turkish-QWERTY800×542 97.5 KB

Current behavior [all in the Editor/Browser window]:

  • Superscript Ctrl = does not work at all. Neither at the Turkish-Q keyboard location Ctrl Shift 0 or the English keyboard location.
  • The following only work with the English keyboard location, not with the Turkish-Q location
    • Unordered list Ctrl , [which is Ctrl ö in Turkish].
    • Outdent list Ctrl Shift , (but really Ctrl <, see related issue) [which is Ctrl Ö in Turkish].
    • Indent list Ctrl Shift . (but really Ctrl >, see related issue) [which is Ctrl Ç in Turkish].
Shortcuts that work as expected (in case it suggests possible fixes):
  • For all shortcuts involving i (card info, italic), both dotted-i and undotted-ı are accepted. [This is for the best, based on how the world generally relates to the dotted/undotted-mismatch problem.]
  • In the study-session window
    • All punctuation-related shortcuts that I tested @*=-/ work using the character’s location on the Turkish-Q layout.
  • In the Editor/Browser window
    • Subscript Ctrl + works using the character’s location on the Turkish-Q layout (typed as Ctrl Shift 4).
    • Ordered list Ctrl . works using the character’s location(s) on both the Turkish-Q (Ctrl .) and English layouts. [Strange for both to work, but obviously not worth a fuss to fix.]
  • On the Main screen
    • Open debug console Ctrl Shift ; (but really Ctrl :, see related issue) works using the character’s location on the Turkish-Q layout (Ctrl :, typed as Ctrl Shift .).

Related issue:

Shortcuts that use Shift are documented and tool-tipped as Ctrl Shift [lowerchar] instead of Ctrl [upperchar], which leads to inconsistencies when the those characters move. Look at open debug console as an example. It is documented as Ctrl Shift ; – but on an English keyboard, that is just “typing instructions” for Ctrl :.

When that shortcut is moved for the Turkish-Q layout, it doesn’t move to Ctrl Shift ; (an impossibility, because ; is already an upper character), it properly moves to Ctrl : (which you access in the layout with Ctrl Shift .). The note in the manual doesn’t help here, but correctly labelling the shortcut as Ctrl : would.

On some non-English keyboards, you may need to press : or + instead of ;.

Why is this issue related? Because if you can fix outdent and indent, you should do so by moving them to the Turkish-Q layout’s Ctrl < and Ctrl > (arguably more evocative and easier to remember shortcuts for that functionality anyway). Then, I would advocate for the docs/tool-tips being corrected to call the shortcuts by these correct names (and for open debug console too) – instead of names based on the English-layout-only typing instructions.

1 Like
2

I neglected to mention – In my research, I found other posts/bugs that were closed or deemed fixed. I felt this was different enough from them to merit its own post.

3

This isn’t an answer to your issue, but I just wanted to give a link to Windows keyboard layouts - Globalization | Microsoft Learn, which gives a set of links to all Microsoft keyboard layouts. This might be helpful for developers.

At the individual pages for each keyboard layout, including Turkish Q Keyboard - Globalization | Microsoft Learn, you can mouseover the Ctrl, Shift, and Alt keys on the displayed keyboard to see what effect they have. Deadkeys (for typing accents) show up highlighted.

1 Like
4

I also switch keyboards between languages for language study, and have also encountered problems like this. For example, the problem of the @ key not working for “suspend” on the Russian keyboard.

My ideal preference would be that all shortcuts should use the same physical key locations as for English. So Shift+2 would always invoke the “@” shortcut for “suspend” even though this actually types a double-quote character in the Russian layout.

There are two reasons for this: touch-typing muscle memory, and also the fact that there is no way to type a @ character in the standard Russian layout (or many other languages’ layouts).

It might not be possible, because Anki depends on the Qt toolkit, so it might not have access to low-level keypress information.

PS,
Deadkeys are another issue. In the Canadian Multilingual Standard Keyboard used for French (Canada) layouts, shortcuts that use Ctrl can’t use the right-hand-side Ctrl key because it is reassigned and doesn’t function as a Ctrl key.

5

My understanding was that we’re limited here by how QShortcut behaves, but I may be mistaken or outdated. Any thoughts @abdo?

6

Looks like the only way to solve this in a general way is to map platform-specific virtual keys (QKeyEvent::nativeVirtualKey).

The Qt docs recommend using translatable keys, so for example, the debug console shortcut (Ctrl+: in source code) would be translated as Ctrl+shift+ş in Turkish.

7

It’s an interesting proposal, but I think there’s at least 2 groups of users it wouldn’t work well for –

  • Users who do serious amounts of typing in multiple layouts, and have muscle memory for both (or all). That would ask them to know that even though they regularly type @ (following your lead on the example, even if it’s not the most common character – it would be all the worse with a more common character like comma or period), the @ Anki wants them to use is not that @. This is the sort of guessing game I’m hoping can be fixed.
  • Users who don’t switch keyboards because they only type in their native (non-English) layout – which is probably printed on their physical keyboard. That would ask them to know where the @ is on a keyboard they don’t even use (and might not be familiar with).

I’ll be honest that with the ubiquity of email addresses, it boggles my mind that there are layouts that don’t have access to @. :grin: But for me, that would be an argument for not using @ for shortcuts, rather than making it harder to find for users who do have @ in their layout.

8

Hmm, I’m not sure what the best approach is here. Years ago, Anki used to have translatable shortcuts. It was somewhat problematic - translators often got confused by the syntax, or did things like assigning multiple actions in the same window to the same shortcut (because of the lack of context when translating). So if we moved back to this approach, there’d be an increased risk of new bugs. There’d also be an increased risk of conflicts with add-ons, as they wouldn’t be able to rely on the same shortcuts being used across languages.

9

Actually, the “ideal preference” I described seems to be mostly already in effect for languages that use non-Latin writing systems.

Using the Russian layout or the Hindi (Devanagari) layout, many (or even most) shortcuts based on letters of the Latin alphabet work fine by pretending you are typing on an English keyboard. But non-letter shortcuts like @ or / do not. There’s a / symbol on a Russian keyboard in a different position, and it does work when you type that.

They do have access to @… by switching to the English layout. After all, the rest of the email address uses the Latin alphabet, so you have to switch anyway. And there are many other contexts that require Latin letters: chemical and mathematical formulas, chess notation, etc.

There are keyboard shortcuts for switching keyboard layouts. But obviously if you had to type Windows+Space @ Windows+Space in Anki, it wouldn’t be much of a shortcut anymore.

10

There may be distinct use cases.

Someone using a language with a Latin-based alphabet will probably stick to a single keyboard layout, like French AZERTY or German QWERTZ or Turkish.

But someone using a language with a different writing system is already used to switching to the globally dominant Latin alphabet from time to time for certain unavoidable purposes, e-mail addresses being one example. And obviously, when using Anki to study such a language, creation of Front and Back cards will involve constant switching.

I wonder how it works currently, since my “ideal preference” already mostly works. Is there an elaborate internal mapping of, for example, Cyrillic щ and Hindi द to the “o” shortcut in the review screen, to ensure that typing that same physical key works despite inputting a completely different character?

11

I want to make sure I understand you. When you say “translatable,” does that mean translating the physical location of the character on the English-Latin layout to whatever it would take to type that same physical location on another layout? Like the example abdo gave of Ctrl : becoming Ctrl Shift ş – since both are the upper-half of the key to the right of the “L” key?

That strikes me as odd, since “alphabet” shortcuts are generally not case-sensitive. And it would certainly require a lot of re-work for the interface translations/localizations. But it would avoid the guessing games from a user perspective.

I guess I would wonder – which is easier from a dev/add-on-dev perspective?
A. Having the app respond to the same physical key-press in the same way, regardless of what keyboard layout is active when triggering them (and so, regardless of what layout characters are being entered)
or
B. Having the app respond to the same character entry in the same way, regardless of what physical keys are being pressed

As an outsider, it seems like B would be easier, but apparently there are some challenges to it that I don’t understand yet. As a user, I know that B is certainly preferrable, whenever possible. And it seems like if there are going to have to be concessions made for impossible cases – with apologies to Cyrillic- and Hindi-keyboard users for leaving them out in the cold – they shouldn’t be necessary on keyboards that are Latin-based and highly similar to an English layout, such as the Turkish layouts.

12

Actually, they are case-sensitive in Anki.

In the review screen, the popup menu associated with the More button at bottom right shows “I” and “O” as the shortcuts for card info and options, respectively. But in fact, only the lowercase versions work.

13

I had to laugh at that – since they are always shown as capital letters! :grin:

But yes, I do see now that there are several where Ctrl letter and Ctrl Shift letter are different actions.

14

Actually, I should have been more precise.

Shift+o doesn’t invoke the shortcut for “o”. However, if you turn Caps Lock on, the “o” key still works the same way as when Caps Lock is off.

15

I mean giving each language’s translators the ability to change the English shortcut to something else, like Ctrl : becoming Ctrl Shift ş

I don’t think that’s practical; different keyboards will have different layouts, and I don’t see how we could describe the shortcuts in a way that makes sense in each language.

While it’s confusing, I believe it’s standard UI convention. For example, in macOS menus, you may have actions with “Command+A” and “Command+Shift+A”. The former being the lowercase variant.

16

I think you’re right that is more likely to introduce bugs and conflicts than be a solution.

That’s okay! Having Anki respond to the character being entered [B, above] would be a great outcome. It makes more sense from a user perspective, and it sounds like it would work better for add-ons too.

After all, that’s how most of the shortcuts already behave, and what makes these inconsistent ones so puzzling. Especially the “pairs” of features where only one of them works – subscript works, but not superscript – ordered list works, but not unordered.

17

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.