For a kid it wasn't that easy to understand that there are such things as different keyboard layouts. Turns out that ` is a single key press to the left of the '1', in English, while it is a bit obscure character to write in other languages. In mine, you have º and ª in that place... so no ` at sight.
But game devs assume that ` is just a keypress away in a confortable area of the keyboard, and it became the de facto way to open in-game consoles. Oh well.
But the console you only open sometimes.
But everyday(!), I have to use {[(| ... and they are just awkward to reach on a german layout.
The alternative would have been buying a laptop with literally every key I care about in the wrong place in some local store. It's great that alternate keyboard layouts are available to those that actually need/want them but it really sucks that you get locked into these choices just because of where you are. Local shop owners don't seem to have any commercial sense whatsoever. Here's a genius idea in a city full of expats (Berlin, Munich), you know, maybe stock a few laptops with international keyboards. Even the local Apple store doesn't do that. And any time you go there, a very meaningful percentage of the customers is clearly not German.
Every non German buying a German keyboard because they have to is basically an unhappy customer. I know loads of foreigners here moaning about German keyboards. I've never met a non German that actually prefers having keys in the wrong place. That's not a thing; it's bloody annoying. It's equally annoying in other countries where expats live. E.g. French keyboard layouts are worse, AZERTY instead of QWERTY. At least in Germany you get QWERTZ (Y and Z are swapped). I've actually met quite a few German programmers that remap their keyboards so they can program without having to use four fingers to produce a single key-press.
But there's a problem. I want to spell people and places' names correctly, and on my PC that means I have to swap input locales often in order to type proper icelandic characters like ð, ö, þ, æ, í etc. This is annoyingly hard on a keyboard that doesn't support them natively! I will give apple some credit here - it's incredibly easy and intuitive to type foreign characters on a US keyboard just by holding down 'i' for example, if you only occasionally need to use them. Windows requires you to either learn the old-school way of holding alt, and typing the ascii code on the number pad, or hot-swap input languages. I know German uses far fewer unique characters, but how do you cope with that problem when you need German characters like.. sharp S, oumlaut, etc?
- the registers "+, "*, "~ are on the same key
- `,` and `;` for backward and forward searching are on the same key
- the macro operations `q` and `@` are also on the same key
- `^` for the line beginning is the key left to `1`, which also makes sense for `Ctrl+^` to switch recent buffers.
There is such a thing as a Dutch keyboard layout and keyboard, but almost no one in the Netherlands uses them, as well as configuring one's system to be in Dutch, because it leads to such problems as described.
My entire system is configured in U.S. English, though most of the spelling I use is closer to U.K. English, but I find that it leads to the least problems in practice.
If it were configured to be Dutch, then troubleshooting would be a mess. — this is a common mentality in the Netherlands to never have any electronics or website configured to be Dutch, even when the option allow itself.
Special characters are usually input using the U.S. International layout which which allows one to type, say, “schöne scheiße”. quite easily.
I have learned on the US keyboard and keep using it more or less.
In English we don't have any diacritics. We do have a few extra symbols, beyond the alphabet for certain situations. Quotations ... " ... meh should be 66 99 and that will be fixed up by DTP software. We use ' to denote a dropped letter - abbreviation. There are a few others. I won't dwell on "thorne" and ligatures and other oddities.
I do not know of any reason to write ` - it is not an apostrophe, which is: '. What is it?
Not sure if you meant this literally, but I've seen it refered to as a back tick. As to what it's for, I have no idea either. I can't recall ever seeing it outside of programming.
So if you pressed backspace followed by "`", you'd give the last character a grave accent.
That's my theory for it being called backtick anyways.
Nowadays you could configure your input method to make that key give the next character a grave accent
A lot of programming resources I've seen have an explicit explanation that the backtick is a different character than the single quote. Better yet, some fonts make the two almost identical.
Out of curiosity, what keyboard layout do you use?
Windows for backwards compatibility reports 'right-alt' as 'alt+control'.
Many applications developers assign key combos with no negative checks. So 'ctrl-s', typically used for save gets triggered when user wants to type 'ś'. To repeat, "right-alt"+"s" is reported as "alt"+"control"+"s", which triggers crappy "control"+"s" checks.
Similar scenarios happen many places that check for 'alt'+'letter' without checking if control also is not pressed.
Microsoft thread for team user voice issues on this https://microsoftteams.uservoice.com/forums/555103-public/su...
or Medium's developer talking about 'ś' and 'ctrl'+'s'. https://medium.engineering/the-curious-case-of-disappearing-...
Interesting because on French AZERTY we also have an "altgr" key, and while Windows considers alt-control equivalent (ie. you cant type alt-control-à as well as altgr-à to get an @), typing altgr itself never triggers ctrl or alt shortcuts, it only goes the other way.
So when you wanted to type 'ć' in any program in Windows, it would not work, and launch CCC instead.
Luckily the shortcuts were user-modifiable. So first thing to do on Windows after installing GPU drivers was to disable this hotkey.
> Windows for backwards compatibility reports 'right-alt' as 'alt+control'.
There’s your problem, right there
An application shouldn't accept ctrl+alt+n as either ctrl+n or alt+n. That is simply a bug, no way around it.
I would argue that the bug is implicitly pressing Control. Control is not a layer modifier.
This may make sense to do with some of the more annoying key combinations, e.g. the German layout requires pressing AltGr+7 for '{'. Both keys individually are usually pressed by the right hand, but pressing the combination with the right hand alone is a very uncomfortable hand position.
I don't know how other OSes allow for users to trigger "right-alt" when the keyboard has only one alt character.
I actually do this on two-alt keyboards too, because I like to use either alt for shortcuts.
But I must say that most tools on Windows seem to handle it well with AltGr, only Ctrl+Alt is problematic.
Taking a screenshot? Thats the claw handed Cmd+Shift+4 or maybe even Cmd+Ctrl+Shift+4. Why!? Triggering the emoji picker? Cmd+Ctrl+Space. Don't accidentally press Cmd+Option+Space or you get the world's most useless Finder window.
To make this worse, Apple sell a bunch of keyboards without the symbols printed on them. So often you have software telling you to press the ⌥, ^ and ⇧ keys when your keyboard doesn't even have labels for those symbols.
In contrast, Windows has the Windows key for interfacing with the OS and the Ctrl key for interfacing with apps. So much more logical.
It goes way beyond that though: if command’s in a shortcut it pretty much guarantees that’s an application / system shortcut, which frees Ctrl to only deal with text control (and literal control codes in the shell).
And thus Option essentially only does alternate characters.
It’s not perfect, mind, for instance the number of keychords means emacs is annoying whether you leave meta on option or move it to command.
As the article explains, there is a difference between the physical keyCode and character it corresponds to. Which to use really depends on what it is being used for, and there are situations for both. The article suggests checking the character typed, but this is not always the correct way to do it.
For instance, the most annoying are games which default to WASD based on the letter typed and not the physical keys (I've seen this both in web app and native games). Using WASD based on letters simply does not make sense because the whole purpose is to mimic arrow keys. If you base it off of letters typed, then on Dvorak it's like if you used ,A;H on Qwerty which makes absolutely no sense for directional navigation.
For shortcuts where the letter has a meaning, then you might want to look at the actual character. But beware that even alphanumeric keys are not always in the same place because of layouts such as Dvorak and Colemak.
If you're using `keyCode` for anything, you're doing it wrong. There's a reason it's marked ‘legacy’.
Physical key position is the UI Event ‘code’, which is in this example will be "KeyW" regardless of layout. This field is essentially 1:1 with hardware HID codes (as used by USB and Bluetooth keyboards).
The biggest annoyance for me is if you want to sometimes use hardware-level dvorak or another layout (which expects software-level qwerty) and sometimes use it in software. Like, if your keyboard runs QMK but you use it with a laptop and might want to use the laptop's built-in keyboard if you take it on the go.
GTK also has some weird issues if you have multiple layouts enabled where the shortcuts are in the wrong place and don't all work (happens in Dino and Gedit). So, I now have only qwerty enabled in Sway and I'll just edit the config if I ever need to change virtual layouts instead of doing it with a couple keypresses.
Is it even possible to do anything else? I can’t imagine keyboards report their physical layout..
Windows, macOS and the various input libraries on Linux provide ways to query the key map - and a number of games do use this to provide localized bindings (Ubisoft and Blizzard are notorious for doing this right, something I appreciate as a dvorak user who hates dealing with rebinding or constantly having to toggle layouts). As far as the browser there is coming support for reading the keyboard layout as well: https://developer.mozilla.org/en-US/docs/Web/API/Keyboard/ge...
If you type WASD on a US layout USB keyboard, the computer will receive key codes 26, 4, 22, 7.
If you type ZQSD on a French keyboard you get exactly the same result.
So if you are writing a game, you might listen for codes 26, 4, 22, 7 and these will be in the sample place on the keyboard regardless of layout. You can ask the OS to translate these codes to letters for help text.
(Some of the details here are omitted—the codes above are USB HID codes, but those go through an additional OS-specific translation table before they are sent to your program.)
It’s impossible to know the physical layout for absolute certainty. For all you know, my “Enter” could be a pedal under the desk.
Other games like the Java version of minecraft didn't work with Dvorak when I tried them. Even with key remapping.
You can easily ask the OS what layout is being used or even ask the user.
Here is the function for macOS:
https://developer.apple.com/documentation/coreservices/13905...
Also, not that “alt-s” will produce an s character on a US keyboard on windows, but will not produce an s on MacOS with a US layout - alt-anything will produce all sorts of interesting characters on MacOS.
https://developer.apple.com/documentation/coreservices/13905...
My memory is that if you press option E on a Mac, the translation function reports a non-zero state but no character output. You can detect this and call the translation function again with a space to get the diacritic by itself.
Just look at this image: https://i.stack.imgur.com/3LL8a.png
Can you find the [ and ] keys? If you’re having trouble, it’s because you have to use 2 (two!) modifier keys and activate the ( or ) keys, which themselves are clumsily placed. This cannot be typed one-handed in a comfortable way. Apple’s azerty layout is unique in this, as regular azerty puts those keys in a more sensible place. I keep wondering: why does apple make me do a Vulcan nerve pinch every time I want to index an array?
I use a US keyboard for that exact reason
Original keyboards (up until 1980s) had special polish letters like ąęśćżń on dedicated keys, and various characters like [{$ moved around.
That is called „Polish” layout.
Then, since 1990 we have „Polish (programmer’s)” , which is essentially the american keyboard and local characters hidden under alt-right.
Literally everyone uses „Polish (programmers)” now, and you just need to remember to choose this, and not the regular „Polish” in system settings :)
'@' meant 'at' looong before e-mail was invented.
Why is it so bad? Because folks keep on buying it. So there's no demand to improve it.
This is my #1 annoyance with German keyboards as someone who learned a UK layout and who needs to do lots of programming and terminal hacking (#2 is the swapping of Y and Z). I take it this layout was invented before Unix and its heavy use of forward slashes, but it does show how shortcuts are rather discriminatory. I know more than a few Germans who use UK or US keyboards because they dislike this unhappy feature.
My guess would be that Unix chose many of its special characters and keyboard shortcuts precisely because they were easy to type on a US keyboard.
When I need to type Spanish characters like áéíóú, ñ, etc. I switch to latin american ISO layout using WIN + Spacebar and then switch back.
I have a strange ISO/ANSI US keyboard, with an ANSI left shift and an ISO enter key.
I know you can configure that in IJ but I'm too lazy to do that, especially if there are many keys to remap.
So now I have a keyboard with UK Layout.
Another issue I run into is forms that dismiss via keydown and escape. I type in Japanese which means I'm using an IME. An IME, or at least the Japanese IME, you type characters and they appear with possible completions. They haven't actually been given to the app yet. Pressing Escape cancels the completions. But webpages that cancel some model form dialog via escape means that if I press ESC to cancel IME completion (which is common) I also cancel the dialog and lose all input had previously entered into the form.
I'd think this would been solved at the browser level, if the IME is active then don't pass keys to the app but for probably valid reasons that's not what happens.
TL;DR don't use escape to cancel a model form!
edit: apparently there's the 'isComposting' property on the KeyboardEvent to find out if the user is currently using the IME
https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEve...
If you follow these three rules feel free to use the esc to close the dialog. I just tested logging `event.key` with hiragana Mozc input device and every keydown while selecting the correct kanji registers as `Process` even cancelling the input with Esc just adds another Process keydown event. I admit it can be frustrating if you double tab Esc accidentally to close the input (second Esc will close the dialog), but that is where rule one comes in, and the accident will only cause the user a minor annoyance.
In this scenario, the "current interaction" is IME input. The bug is that the page intercepts Esc keypresses intended to be handled by it.
The article mentions an open-source example that does it this way and works fine on international layouts: Discourse
https://developer.mozilla.org/en-US/docs/Web/API/Document/ke...
> Hint for developers: Switch your computer’s keyboard layout to something other than US to debug your application’s shortcut handling on different layouts.
The problem with this and all the other X is broken and should be tested articles is that the testing burden is already enormous. Plenty of companies don’t even test with Firefox and/or Safari.
That’s really the problem that needs to be solved. How to reduce the testing burden.
They still employ as few people as they can get away with.
I'd imagine you'd need multi-lingual testers to use the product too, not just a native speaker given a foreign keyboard. There's no way to find bugs an average user would face with normal use.
Monolinguals, especially those living in the United States, are a minority globally. If you're going to develop all software in the United States, please at least make it work for the rest of us.
It reminds me of developers who want to capture link clicks for internal navigation but acccidently block right or middle click as well because it is the easy thing to do.
If we provide APIs that make the right thing the easiest we will have more websites that do the right thing.
I only wish there was good support for it on Linux and Windows. I will eventually contribute a patch to xkb to fix its version of this.
It's great for programming and quite good for all the Western European languages (maybe not so much for Eastern European languages that are more creative with diacritics).
I wish I'd known about it before spending a lot of time creating my own custom layout for Linux and Windows, although since I went through the trouble that's what I still use.
I'm talking about "AltGr dead keys", in which the quotes are available directly and the accents are entered using e.g. AltGr-'.
I'm using 6 european languages occasionally, of which 3 every day, including French. Of these, Canadian English would be only useful for French (e.g. it does not have a tilde dead key AFAIK) and is still different enough from US to be annoying for programming (e.g. the angle brackets are in the "wrong place"). Certainly a big upgrade from AZERTY though!
EDIT: My remark on the Canadian English layout above is based on the first layout that showed up when I googled it, but now I noticed that a lot of different variants come up in the search and I don't know which one you're using. In any event, they all seem to be weaker either for programming or for non-FR/EN languages or both.
However, the canadian english variant I'm using definitely has a ~ key and accepts alt+n for ñ. Concerning angle brackets they are at the same position as on a standard US layout.
I assume that we are using different operating systems and that they use the same name for different layouts.
These days, on Windows, I use the Colemak layout, which has a alt-` meta-combo to type common accented letters - I assign that to caps-lock+A with AutoHotKey, and “Bob est ton oncle”.
I'm talking about "AltGr dead keys", in which the quotes are available directly and the accents are entered using e.g. AltGr-'.
It's not available out of the box in Windows but you can easily find ready to install layouts online.
Some tips:
- switch out ALL you keyboards, at home, at work, on all devices - use EurKey* for reaching special keys in your language (french, german, whatever...)
For instance, consider ‘/’ (beside right shift). The normal hardware code (USB HID) is page 7 usage 0x38 (sometimes written 0x070038; in theory HID usage codes can exceed 16 bits, but in practice they don't). The PS/2 hardware code (for old keyboards) is 0x4A. The Windows ‘scan code’ is 0x35. And finally, the browser legacy ‘keyCode’ which you can see at https://w3c.github.io/uievents/tools/key-event-viewer.html is 191 (0xBF), which is the Windows virtual key ‘VK_OEM_2’.
(For context: I was writing a simple mouse gestures utility that sends that keyboard shortcut to accomplish backward navigation for an appropriate gesture, but discovered this to be unreliable across keyboard layouts).
There‘s a physically different key arrangement on these, so even when switching to the US lay-out, some important system-wide shortcuts are still impossible to type (most notably the one for „switch to different window“).
I wonder if it's any better on iOS or are you just completely out of luck there when you can't reconfigure the shortcuts?
Edit: 0: or at least a pass-multiple-words, depending on how picky your definition of "phrase" is about grammer. It shouldn't be "word", singular, is the point.
https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEve...
Regarding events, attributes, and deprecation: keydown (event), code (attribute), and key (attribute) are not deprecated.
Now when you press "shift+7" on your keyboard it only sends "regular US keycode for /"
As a benefit you'll maybe also realize that Azerty or Qwertz are pretty bad layout for typing French/German, and you'll come up with something better.
And Alt+S already opens the browser's History menu, on Firefox, and I'm not sure that applications can override this binding, or if users will appreciate it.
----
Last year, I was working on a Qt app that needed to translate physical scancodes (not layout-dependent character codes) located in a piano layout, into music notes. I developed a library (https://github.com/nyanpasu64/qkeycode/) and submitted several Qt/QtWebEngine bugfixes.
Anyway, fuck KeyboardEvent.keyCode. It differs across OSes and browsers.
Fun fact: On QWERTY, + requires holding Shift. Some apps (Qt Creator, QtWebEngine) don't zoom in upon Ctrl-=, but only Ctrl-Shift-+. IIRC Firefox in English locales binds both Ctrl-+ and Ctrl-= to "zoom in"
Tilde ~ is similar: option-click and then space.
This makes the out-of-the-box keyboard shortcut for switching window on macOS unreachable on my macbook pro.
There are several default shortcuts on osx that are unreachable from international keyboards.
(I'm from the UK, so I only really lose the British currency symbol)
> This means when the key combination is alt+/, the shortcut should be triggered when a german layout user presses alt+shift+7.
No way. I want to press alt+dash, which is in the same place as alt+/ on a US keyboard. Pressing alt+shift+7 is the equivalent of Lee-Harvey-Oswald-grade marksmanship on a keyboard.
However, developers defining and documenting alt+/ as an alternative for alt+/ when registering the binding would indeed be a fine solution.
It switches to a US layout if ctrl/lalt/cmd are pressed, including switching `Z` and `Y`:
https://github.com/ivancuric/mac-hr-sane-layout
MacOS is notoriously bad for handling international shortcuts. Eg, `Cmd+[` is back system-wide. To get [ on my keyboard I need to press `AltGr + F`. `Cmd + AltGr + F` doesn't work, of course.
Where the `[` character is on a US keyboard, I have `Š`. `Cmd + Š` also doesn't work. Manually recording a shortcut to rebind it to `Cmd + Š` also used to output `Cmd + Ctrl + Alt + F`, which seems to be fixed at some point in the last 3 years.
On French keyboard, the numbers 0-9 and special chars (#$&@...) are swapped, so you need "shift+<num>" to type in a number. Effect on the web compat:
A phone number validator on French lowcost railway website was built/tested with French keyboard only; they were checking input codes in JS on each keypress and only allowing the presses of certain keys with shift enabled. Since you can't type a number on QWERTY with shift enabled, I was unable to complete the form until I realized what's up by reading the JS and switched to AZERTY layout.
(copy-pasting into the input didn't work either)
---
Unrelated aside: as I was raised in Poland which is based on US QWERTY and all programs using US shortcuts (with the only quirk being AltGr mentioned in other comments), I was mind blown than in other countries it's customary to localize shortcuts.
For example in Spain in notepad.exe, save is not CTRL-S but CTRL-G ("guardar").
In France, you don't bold in Excel with CTRL-B, you bold with CTRL-G ("grossir"). For some reason Excel online only lets me use the FR version despite settungs all possible locale settings to en and this drives me nuts.
(pt-PT keyboard, parenthesis and brackets are either an off-by-one or require Alt-Gr+Shift to type.)
Using a US keyboard layout for a while really drives home how much it influenced popular CLI character choices (like path separators, pipe characters, etc.), too.
Arabic, Chinese, Hebrew, Russian among others.
When set to different layout many apps ignore common actions like Cmd/Ctrl + C and you need to make sure you're using a latin layout.
> This means when the key combination is alt+/, the shortcut should be triggered when a german layout user presses alt+shift+7.
Really? The / is conveniently accessible on a US layout; shift+7 isn't. So this gains you the benefit that you don't have to change documentation (it is "/" however you type it), but much less usable on other layouts. Alternatively, you could try to use the key in the same physical position, but - is already used for other shortcuts due to its meaning.
[0] https://en.wikipedia.org/wiki/CSA_keyboard
[1] https://en.wikipedia.org/wiki/AltGr_key#Finnish_multilingual
So indeed avoid symbols. If the application needs more shortcuts, then use prefix keys for less frequently used shortcuts or allow the user to type commands.
No, I use a national (UK) one.
It would be nice if keyboard shortcuts were a matter of the OS and applications would expose a list of all available commands with default shortcuts...
Don't like the dead keys, but the shortcut confusion is worse.
I also like my ';' and '.' swapped, because dot is clearly more useful when typing in terminal
Only an issue when your mouse on the right side of the keyboard
