It really surprised and disappointed me recently that native macOS apps have the same problem outlined here. For example, the standard system-wide ‘back’ shortcut (e.g. in Safari, Finder, Preview) is Cmd+[, but this is inoperable in many keyboard layouts that don’t have any key that produces [ without modifiers.
(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).
It‘s even worse on ISO keyboards (the ones with the large return key).
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“).
Yeah Apple doesn't seem to even try to cater to non-US users with their shortcuts. That's the first I've heard of a system-wide back shortcut. You can't type that in my layout. The default switch between windows of a single app shortcut is also impossible, IIRC. One that I always have to reconfigure when I switch editors is the line comment shortcut which defaults usually to something like cmd-/.
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?
One favourite of mine in this genre is applications who use both command-[ and option-command-[. On a Swedish mac keyboard, [ is on option-8, so it is impossible to type just command-[ without the option key...
> For example, on my German layout, / is produced via Shift+7.
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.
I used to switch between US and DK layouts, it's just so much easier to just have one layout. In my opinion, learning US Intl is worth it. Besides, it's pretty predictable for Spanish characters: á = altgr+a, é = altgr+e and so on.
Yeah it's great for Spanish. But I found that knowing (and using) native layout is more valuable to me because when I need to type on someone else's keyboard I'm not lost and can still touch type. If you never need to do this US international is indeed superior layout.
Trying to remember more than two layouts becomes confusing very fast. AZERTY and QWERZ are the two worst ones, fortunately I never need to use those.
These keys are present on the UK keyboard, but not the US: £¬
Compared to every other common ISO keyboard layout, ISO UK and ANSI are very similar. For non-programmers, ", @ and (nowadays) # are the ones that matter. For a programmer used to an ISO keyboard, the UK layout may well be a better choice than the US ANSI one. (US ISO would be a good choice, but the extra key seems to duplicate symbols already present on the layout).
Same problem with latin american keyboards found just a few kilometers south the US. If I remember correctly, the default modifier key in VIM is next to imposible to press on a l-a keyboard. It was ` ?
In intellij this was a bit frustrating to me, you can do ctrl-shift-`/` to block-comment (in german keyboard: ctrl+shift+shift+7). How do I double-shift?
I know you can configure that in IJ but I'm too lazy to do that, especially if there are many keys to remap.
Dead keys are particularly fun, as it takes two key presses to produce a result. Accessibility of keyboards/layout could indeed be improved. I switched to custom US layout, because of too many issues with a non-US layout. My custom layout uses AltGr combinations to add a few local characters. It is a bit clumsy, but at least keyboard shortcuts work most of the time.
Polish has a "traditional" (typewriter) and "programmer's" (US + AltGr) variants of the keyboard layout. Everyone uses the "programmer's" one, even people who don't know what programming is.
> What baffles me is that the problem exists in apps used by millions of people every day, developed by gigantic corporations who pride themselves with having the best engineers in the world. Why is this baffling? Because the underlying technical issues are rather trivial!
> 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.
I agree to some extent. However, I have outlined a few very simple approaches. At the very least, developers could stop using special characters for their most important shortcut bindings.
For a 10-person startup, that's fair. For a company like Google , with offices in Germany and France and hundreds of engineers from any nationality, not so much. Other companies fall somewhere in between based on their headcount and global reach.
Plus it's all about profit margins. Investing in tons of testing for not enough return from users means they just won't do that.
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.
If there was a standard way to define hotkey bindings, a simple linter could take care of that. It just shows how far we still have to go in terms of good UI creation tooling.
This is part of why I’d like to see more VSCode-as-an-OS (disclaimer work on VSCode)... imagine writing only the code to go from bytes on disk => view and back, and getting for free: version control, command palette, keybindings, Windows/Mac/Linux/Web support, file explorer, tabs, split views, hot exit, etc etc etc.
This is the real solution. Providing a native API with i18n built in would quickly start resolving this issue.
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 don't think testing with a non-US region settings and a non-English language is a huge burden. As a regular user of “internationalised” software, it's really obvious when the people who wrote it do not speak more than one language, or only considered a single-country perspective.
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.
There is also a whole slew of issues with Polish characters. Polish keyboard setup relies on "right-alt" and a letter to get it's diacritics variation. Ie:
'ą' is 'right-alt'+a
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.
As a Polish Linux user I think I'd switch between mappings in this case. One for typing źdźbłos and żółws, another to interact with shortcut-heavy apps.
I actually do this on two-alt keyboards too, because I like to use either alt for shortcuts.
That also works the other way around -- you can use alt+control instead of right alt.
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.
This is actually fascinating to me. I’ve dealt with keyboard input numerous times (not WinForms or browser either) and I always devised a way where control characters were a bitwise with the keycode. You would have to include this in any input mapping. I can totally see where this key combo issue would be a problem in a UI scenario in the browser or other shortcut-laden desktop app.
The same applies for a bunch of other languages with a character that's "s" with diacritic modifier, and ctrl-s as save isn't as bad - the most horrible case of this that I had was an old version of outlook webmail that I had to use for one client rarely, where ctrl-s was bound to 'send'. With no option to re-bind or disable it. So about half of the time when I'd get to writing an email it got sent in the middle of the sentence right before where a letter ś would be... And since I had to use it rarely, I never got used to it enough to switch keybord layouts.
Really shows how useful macs having 4 modifier keys (versus PC’s 3) is. Also the better (though not perfect) matching of scopes and modkeys: on macs, command / control / option tend to affect different system areas entirely (with command taking precedence, then control, although control and option are rarely used together).
I do like Cmd+c vs Ctrl+c on a mac. On linux I've changed my terminal to use Ctrl+Shift+c instead of Ctrl+c for ^C because I kept accidentally killing programs when trying to copy text with Ctrl+c which works in every app except terminals...
I configured my terminal to copy on mouse release. This allowed to keep Ctrl-C for killing processes while I use Ctrl-V to paste with Ctrl—Shift-V configured to send the original Ctrl-V.
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.
I recently discover that if you remap Ctrl+C to Copy in a Linux terminal, you still get ^C when nothing is selected. It has made the experience so much better.
I personally find the Mac's use of command keys to be horrendous.
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.
> Windows for backwards compatibility reports 'right-alt' as 'alt+control'.
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.
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 think the answer is that their engineers overwhelmingly use the English layout keyboards and work in Cupertino. Most improvements to coding on a Mac I have seen have a design-for-self element where apple employees are eating their own dog food and want to improve the taste.
C was famously designed in Murray Hill on a system with Teletype 37s, which featured then-fairly-novel { and } keys (as it so happens, the shifted versions of [ and ]).
‘Happens’ is understating it. ‘[’ is ASCII 0x5B and ‘{’ is ASCII 0x7B, and the Teletype 37 was entirely electromechanical. For those unfamiliar, see https://en.wikipedia.org/wiki/Bit-paired_keyboard
It's the other way around. The keyboard was the foundation for the programming languages and shortcuts, like moving with hjkl in vim. No German keyboard user would have created a language like C with curly braces, when you would break your fingers typing this (alt 8 is {, alt 9 is }, and alt+5 is [, alt+6 is ] ).
I reassign my Caps lock key as a third level modifier. That way I can type { with Caps Lock + 7. Caps lock is so large I can comfortably use my pinky and ring finger to press and hold it, while I use my right hand to press 7, 8, 9 or 0 for {, [, ], } respectively.
Most keyboard-layouts predate programming-languages, because they were designed for typewrites decades before the first modern computers even existed. So there did gave much to usage of special chara back then. Additionally most languages were designed by americans, on US-layout, which had a great impact on usages of different char in our digital world. Like for example the usage of @, which AFAIK was only used for e-mail because there was no other free char on the developers keyboard available.
In American usage, it has had widespread use as shorthand for “at” in many different contexts, not just in terms of price per unit fir quite a while; some of them.may have been catalyzed by thr usage in email, but I think enough are older that email fits into an existing pattern rather than creating a new one.
Yes, in english language. Other languages have/had different names, if they even knew it at this point. There was of course a reason why the @ was on the english keyboard-layout, but it was a very different reason from the later usage as location/user-reference. Point is, if e-mail would have been invented in a different culture, there would be a good chance that the symbol wasn't even on their keyboard at the time and a different symbol would likely have been used.
Honestly that's one of the reasons I'm happy with the Logitech Craft: it lets me use a proper Azerty layout yet silent like the Apple keyboards (plus I can control both my computers from a single keyboard, but that's more an edge case).
Also while we're at it...fix this for bitlocker. Makes special characters in passwords a nightmare and you need to memorize where that stupid character is...
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.
The root of the problem is what this article correctly describes as the deprecated properties `keyCode` et al. These are essential raw Windows events that browsers in the '90s unwisely decided to expose. For any platform that is not Windows, these have to be emulated, which is not at all simple, since the details vary according to particular Windows keyboard layouts.
Nope. They're Windows ‘virtual key codes’, which are entirely unrelated to Windows ‘scan codes’, which are also not hardware codes (but are distantly descended from the original IBM PC).
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’.
As a kid, I remember being utterly confused, when most games with a console would have the key ` to open it. WTF is the key ` and where is it?
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.
Also programming languages used it as an alias for exec. Even if you have a ` key, on some layouts (such as the Irish keyboard layout) it can be a weird key to type due to dead key behaviour, often requiring multiple presses to respond and eating the next keypress.
yeah.. i never use js template strings because of that frigging unusable backtick character.
Ist so hard to type on my layout, that its just not worth it -_-
We all suffer from character blindness of some sort. For you: ` - that thing isn't formally defined in English either as far as I know.
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?
It’s an ASCII approximation of the proper typography for single quotes (except when you’d use inverted quotes for some reason, not sure how common it is in English).
Similarly, LaTeX uses `` and ‘’ for double quotes because the opening and closing symbols are not the same in properly typeset texts.
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.
My mum had a mechanical typewriter and yes it would do that. However English has no formal diacritics. We do have shit loads of borrow words from French and others that do have them.
If the back tick on the en_GB keyboard is a sop for the grave accent, then why do we not have an acute accent available as well? or a cedilla for that matter?
ASCII has a limited number of characters, so they designed it so some do double-duty. The grave could be a grace accent if you backspaced over a letter, or it could be an opening quote mark. The apostrophe was the reverse: it could be the acute accent. The fonts were drawn so these characters were angled enough to be accents, but also looked like quote marks. The apostrophe wasn't a vertical prime sign. Angle brackets and greater/lesser-than also double-up.
Last time I needed a new laptop (my old one died) I took a 8 hour train to travel to the Netherlands from Munich instead of back home to Berlin (where I live) just so I could visit a store that has laptops with a non German layout (US international). The only way to get a non German keyboard in Germany is to order them online and wait for a week+ (typically) for that to ship internationally (because they don't stock these locally). That was clearly unacceptable. So, 8 hour train ride it was because I needed a replacement in a hurry and I got to visit my parents. Win win.
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.
I moved to Iceland a year ago, and brought my PC and my laptop with me. I am confounded by icelandic (nordic in general) keyboards. I can understand their use for a non-technical person, but even keys such as @ are obscured behind "Alt Gr" which is a secondary right side only alt-key? And the position of braces, brackets, and parantheses is also clearly an afterthought. Obviously, years of muscle memory are hard to replace, so I've continued to use my US keyboards.
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?
I would guess that the amount of people who care about which keyboard layout
they use, don't use the local keyboard layout, and require appropriate labeling
of keys (i.e. don't touch type) at the same time isn't that high. I can imagine
how annoying it must be to be in that group, though.
There are few million people in Berlin. A couple of hundred of thousand of them are Turkish or Russian minorities. And another few hundred thousand expats are working in the tech industry from all over the world. Most coffee shops in my area don't even have German speaking staff; much to the annoyance of some of the locals.
Some, of those people buy locally and suffer the bad experience of dealing with a sub optimal keyboard. But a lot of them take their money abroad. Local businesses are missing out on that, which IMHO is kind of stupid.
I am a non German, but I spent more time using German layout than the US one.
The killer feature of German keyboard: it is so natural for vim (and IDEs with vim emulation)
- 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.
I think this is an interesting cultural difference.
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.
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.
I'm french canadian and the most satisfying solution I've found is to keep switching from one keyboard layout to another. I mostly use the american layout when I code, and the french canadian one to communicate. I got used to it in about a week.
I now exclusively use US-International No Dead Keys. I just use the right alt key + qpys to get äöüß. I hate having to switch layouts and switching layouts accidentally while typing. Those key combinations are not worse than []{}\ on the german layout.
I use a US keyboard with Caps Lock mapped to Compose (using WinCompose [0]), which lets me type any Unicode character I need. Totally agree that switching layouts is a pain.
Not sure it's comforting but after exposure to french and swiss keyboard layouts, the canadian one is for me a sweet spot. It's "almost standard qwerty" while allowing to write in french properly. "US International with dead keys" is workable but somehow weirder and less consistent between OSX and Linux.
It's not just international keyboards that are affected by this. I'm a Dvorak user so I run into these issues from time to time.
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.
In X11 with the Xkb extension you can configure simplified vector drawings of your input devices, which any application can query. It is intended that applications use these drawings in their help systems and tutorials, as well as in their key binding editors. Few applications bother though.
Physical layout is mostly irrelevant, different keycap label arrangements use the same keycodes - the input system in your OS or application uses a keyboard layout to translate those into what you want to type.
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...
A few games map based on the key codes. For example, SC2 will get grid layout right on Dvorak or Colemak without any remapping. It did take me directly emailing a designer, who passed it on to the developers, though. ;)
Yes, the UI Events ‘code’ field represents the physical key (essentially 1:1 with USB hardware codes). The key that's labelled ‘W’ on a US keyboard and ‘Z’ on a French keyboard and ‘Ц’ on a Russian keyboard and ‘て’ on a Japanese keyboard (and so on) will have code=="KeyW" in all cases.
Normally, keyboards report data to the computer which represents the location of a key on a standard keyboard. The OS translates to characters based on configured layout. The actual letters printed on the key caps are just decorative.
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.)
Is there a programmatic way to figure out what letter corresponds to a given keycode without that key being pressed? Because you may have to display that info somewhere to give an indication what the user has to press.
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.
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.
Yes. You have to dig a bit to find these APIs, and they are OS-specific (and the scan codes reported by the OS are OS-specific too, even though most keyboards are USB HID these days).
OS X's solution works perfectly: Dvorak + QWERTY shortcuts layout. It's brilliant and elegant, Windows needs to implement the same thing (revert to QWERTY when holding the ctrl or windows keys).
I've used dvorak and now workman and I don't mind the shortcuts moving around.
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.
Does windows a way to simultaneously use different layouts for different connected devices? It's really annoying shifting between my Japanese USB keyboard and English laptop. In Ubuntu I had startup script to detect input devices IDs by name and force different layouts, but even that was a bit of a hack.
Judging by the comments here, looks like we’re globally a rare breed that want absolute priority for keytop labeling over software configuration items.
Another Dvorak typist here! Personal funny anecdote: I learned vim modal navigation after I learned Dvorak, and never bothered to remap the keys. Totally debilitating if I'm using a coworkers QWERTY keyboard for vim navigation, but at least I can still navigate on remote servers without reconfiguring anything!
No, `keyCode` can also change with layout. Since you mentioned WASD, ‘W’ on a US layout has `keyCode` 87. Select a French layout, and the same physical key now has `keyCode` 90.
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).
I’ve gotten so used to switching between keyboard layouts when moving from e-mail to coding that I don’t think about this much, but it can be tremendously irritating when I’m on a new machine or just forget to switch.
(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.
Same here. I use US International, which allows me to type the languages I speak. I even buy all my computers with US Keyboard layouts because I like when my keys match the OS configuration.
I am using a French azerty keyboard, but since '[]' and '{}' are in wierd locations,i always remap them to US-alike. This breaks the diacritics, but oh well
I also like my ';' and '.' swapped, because dot is clearly more useful when typing in terminal
For Western European devs: do try the "USA International (AltGr dead keys)" layout.
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.
It totally f—ks up handling of quotes though. I just cannot stand it, personally.
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 don't know which language you're using but for french I migrated from "US International with dead keys" to "canadian english". I fill that, among other things, simple quotes are easier to type and consistency between OSX and Linux is better. A matter of habits and workload balance I guess.
You are talking about a different layout, which I also dislike.
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.
I can't find any "AltGr dead keys" variant on the OSX I'm using at the moment, I'll check later on Linux. I don't have any keyboard with a key marked "AltGr" either btw :).
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.
> I don't have any keyboard with a key marked "AltGr" either btw :).
That's the right alt (not to be confused with the alt right).
> the canadian english variant I'm using definitely has a ~ key
Can you type "ã" or "õ"?
I'm not saying it's the optimal solution, in fact my custom layout works slightly better for myself. However, learning how to build that custom layout in both Linux and Windows took me time that would have been better spent elsewhere.
All I'm saying is that people in the same situation I was in (programmer writing daily in multiple Western European languages), this obscure-niche-that-nobody-seems-to-know-about layout will serve you fine 100% of the times, whatever the language, without you spending ungodly hours coming up with your own.
> That's the right alt (not to be confused with the alt right).
I laughed, thanks for that.
> Can you type "ã" or "õ"?
on OSX' Canadian English yes, AltGr+n followed by a/o.
On the other hand, after paying closer attention to the behavior of the layout with the same name on Linux, there are annoying discrepancies and "English (intl. with AltGr dead keys)" is indeed pretty nice for me too. Thanks for the pointer, I may adopt it too.
Hah, yes, I’ve had lots of problems with keyboard layouts. I have a hobby requiring lots of unusual characters (e.g. ɛɔþʔəɬɑʒ), and I haven’t yet found a keyboard layout which allowed me to type all these characters with absolutely no problems. I started off using the Canadian Multilingual Standard [0], which worked well enough, but uses Ctrl rather than AltGr as a modifier, with all the conflicts that entails. Also, some frequent characters such as []/ were hard to get to, and I never did manage to retrain my muscle memory to get used to their positioning. I eventually switched to the Finnish Multilingual layout [1], which fixed the Ctrl problem but not my muscle memory. I think I used Keyman [2] for a while, but I don’t remember it working very well. At the moment, I’m using my own custom keyboard layout [3], which generally seems to work very well… except in Microsoft applications, which seem to inconsistently not recognise dead keys with AltGr. (Excel is a particular offender, which is particularly horrible since I often need to type characters like λση⁻¹ in it.) Not that they’re alone: out of the major GUI libraries I tested recently, only Qt and Electron worked correctly. Clearly, this is an area in need of improvement.
Absolutely, that would be a fine solution. It is also mentioned in the article. I really don't know why web application developers are not doing it. Especially when you could be the first to do it and have a real edge over your competitors.
> For example if you have / as you shortcut for focusing the search field because your US users are accustomed to this behavior, just add alt+s as an alternative for international users.
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"
211 comments
[ 5.8 ms ] story [ 224 ms ] thread(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?
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.
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.
Trying to remember more than two layouts becomes confusing very fast. AZERTY and QWERZ are the two worst ones, fortunately I never need to use those.
These keys are present on the UK keyboard, but not the US: £¬
Compared to every other common ISO keyboard layout, ISO UK and ANSI are very similar. For non-programmers, ", @ and (nowadays) # are the ones that matter. For a programmer used to an ISO keyboard, the UK layout may well be a better choice than the US ANSI one. (US ISO would be a good choice, but the extra key seems to duplicate symbols already present on the layout).
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.
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.
> 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.
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.
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.
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-...
> 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.
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.
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.
But I must say that most tools on Windows seem to handle it well with AltGr, only Ctrl+Alt is problematic.
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.
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.
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.
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.
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.
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.
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 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.
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?
Similarly, LaTeX uses `` and ‘’ for double quotes because the opening and closing symbols are not the same in properly typeset texts.
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
If the back tick on the en_GB keyboard is a sop for the grave accent, then why do we not have an acute accent available as well? or a cedilla for that matter?
https://en.wikipedia.org/wiki/Grave_accent#English
Out of curiosity, what keyboard layout do you use?
But the console you only open sometimes.
But everyday(!), I have to use {[(| ... and they are just awkward to reach on a german layout.
I have learned on the US keyboard and keep using it more or less.
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?
Some, of those people buy locally and suffer the bad experience of dealing with a sub optimal keyboard. But a lot of them take their money abroad. Local businesses are missing out on that, which IMHO is kind of stupid.
- 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.
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.
[0] https://github.com/samhocevar/wincompose
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.
Is it even possible to do anything else? I can’t imagine keyboards report their physical layout..
It’s impossible to know the physical layout for absolute certainty. For all you know, my “Enter” could be a pedal under the desk.
https://www.x.org/releases/current/doc/libX11/XKB/xkblib.htm...
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...
Other games like the Java version of minecraft didn't work with Dvorak when I tried them. Even with key remapping.
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.)
You can easily ask the OS what layout is being used or even ask the user.
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.
Here is the function for macOS:
https://developer.apple.com/documentation/coreservices/13905...
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.
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).
(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.
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.
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 also like my ';' and '.' swapped, because dot is clearly more useful when typing in terminal
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.
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.
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.
I don't use OSX, sorry. Maybe try https://github.com/xv0x7c0/osx-us-altgr-intl
> I don't have any keyboard with a key marked "AltGr" either btw :).
That's the right alt (not to be confused with the alt right).
> the canadian english variant I'm using definitely has a ~ key
Can you type "ã" or "õ"?
I'm not saying it's the optimal solution, in fact my custom layout works slightly better for myself. However, learning how to build that custom layout in both Linux and Windows took me time that would have been better spent elsewhere.
All I'm saying is that people in the same situation I was in (programmer writing daily in multiple Western European languages), this obscure-niche-that-nobody-seems-to-know-about layout will serve you fine 100% of the times, whatever the language, without you spending ungodly hours coming up with your own.
I laughed, thanks for that.
> Can you type "ã" or "õ"?
on OSX' Canadian English yes, AltGr+n followed by a/o.
On the other hand, after paying closer attention to the behavior of the layout with the same name on Linux, there are annoying discrepancies and "English (intl. with AltGr dead keys)" is indeed pretty nice for me too. Thanks for the pointer, I may adopt it too.
[0] https://en.wikipedia.org/wiki/CSA_keyboard
[1] https://en.wikipedia.org/wiki/AltGr_key#Finnish_multilingual
[2] https://keyman.com/
[3] https://github.com/bradrn/Conkey
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"