The keyboard shortcut is great and convenient but when users forget to swap language it turns wrong since the system mixes up two input types, Keystrokes and Characters.
For example: I browsed to an observation of a sunbeam snake (Xenopeltis unicolor), I hit the ‘I’ key to directly get to identification text input then hit ‘X’ key to start typing the genus name. But it turned out that I failed to give ID and even unintentionally marked that obs to Casual Grade instead.
How that happened: I forgot to swap system input language from Thai to English and the Identification page mixes up different methods of input detection. When I hit the ‘I’ key, it detected character ‘ร’ (Thai character on the same keyboard button) as an unknown command so the highlight didn’t go to ID text input. When I hit the ‘X’ key, it detected keystroke instead. Which means the system doesn’t recognize my command as ‘ป’ (Thai character on X button) but as the X-keystroke and marked that obs to Casual Grade as what it tends to work.
I’d like to suggest to clean all the detection methods up and turn them to Keystrokes instead.
I’ve accidentally done this when identifying Xylocopa a few times, as well as favoriting observations unintentionally when adding sex annotations, but not because of keyboard mapping issues, merely because the Identify module didn’t register the first keystroke the way I intended. I don’t know if this might be what happened to you.
I wish the “captive/cultivated” shortcut were something less likely to be accidentally entered when typing a taxon name (e.g. maybe xx would be better than just a single x)
I understand your point though I would have no issue marking an observation as captive/cultivated by hitting a single X-key if the focus (cursor) was properly moved to the ID text box when hitting the I-key in prior, regardless of the input language. :)
Unfortunately while the platform is recently putting their effort to encourage users to participate in identification, this problem is still unattended so far. :(
i can’t reproduce what you’re describing. i picked one of the non-English language keyboards I have installed in Windows, and then within the other language mode for that keyboard, i pressed the i key while an observation was open on the Identify mode. that started an identification, and moved the focus to the identification input box. then i pressed the x key, and that started typing in the other language.
the only way i can press the x key to trigger captive is if i shift the focus outside of any text input box.
what operating system / device are you using? are you using a normal keyboard or are you using an on-screen keyboard? do you have any extensions installed that might shift the focus out of a text input box?
I switched my keyboard to a few languages that do not use the Latin alphabet (Thai, Greek, Arabic) on Mac OS Safari and Chrome , and can duplicate the problem.
I’m a software developer and I have the iNat Rails app and API running on my machine. I took a look at the keyboard shortcut code in the Rails app. Ken-ichi added a comment over 7 years ago that warns about problem with keyboard shortcuts and other languages.
Works for now but it's brittle, and will be confusing for locales other than English.
If I replace "i" with "ร" in that line of code, then I can switch to the identification text input with the Thai keyboard. My guess is the code for the keyboard shortcuts needs to be rewritten to work with non-Latin alphabets on Mac. I don’t have a Windows machine so I don’t know if this bug exists on Windows.
weirdly enough, when I type in Hebrew, I get a partial bug.
using the “i” key when it’s set to “ן” does nothing. similarly, using the “c” key to add a comment when it’s set to “ב” does nothing.
but using the “x” key when it’s set to “ס” correctly marks an observation as captive. “ר” as r works to set reviewed.
“?” is the same on both keyboards, ditto the arrow keys.
I’m getting the vague impression that when using the non-latin keyboard, it depends where my cursor is? Which is better than no support, but annoying. I wish the shortcuts would work even of my cursor is altogether off the modal, or over the map, etc.
i installed a few more keyboards, and i can reproduce this behavior for Hebrew in Win 11. when the focus is in a text box, the x and r type in the input box, as expected. this is also true for the Russian (Russia) Win 11 keyboard and the main Thai Win 11 keyboard.
there definitely is an inconsistency in behavior, but i’m not sure if the first behavior is the bug or the latter is the bug. even in English, the key that is usually mapped to x (in QWERTY layout) isn’t always x (in alternative keyboard layouts). so then should the iNat shortcut be based on the QWERTY key or the actual output? i suppose the only way to make it consistent across everything is to use the QWERTY key in all cases – mapping to event.code as opposed to event.key – but that could mess up use of alternate keyboard layouts. (otherwise, you would have to allow users to define their own shortcuts.)
i still can’t replicate the OP’s reported behavior of x triggering captive even when the focus was on the input box. the OP reports using Win 10. so maybe that old OS is one of the triggers? (if so, do we care about an OS that is no longer in support?)
just to clarify, it looks like the problem occurs when a single keystroke (or one modified with shift, alt, etc.) produces a single non-Latin output.
Korean and some methods of Chinese input use non-Latin alphabetic input, but it takes a series of keystrokes / inputs to produce the final output, and there are no issues with these language input methods.
Japanese Hiragana input falls somewhere between Korean and Hebrew, but it has no issues with iNat shortcuts either.
…
finally, for what it’s worth, you can easily switch between languages in Win 10/11 using win + spacebar.