One of my pet peeves: Badly implemented "press CTRL + / to search". Entering an actual slash, which requires e.g. SHIFT+7 on German keyboards, won't open the search box, but pressing the key where American layouts have a slash will.
One of my pet peeves: Badly implemented "press CTRL + / to search". Entering an actual slash, which requires e.g. SHIFT+7 on German keyboards, won't open the search box, but pressing the key where American layouts have a slash will.
Edit for clarity: I type "a to get ä and 'a to get à. If I want to type actual quotes followed by a vocal I need to “confirm” the quotes with space before typing the vocal. That’s all there is to it, really.
⌥s creates the ß.
(Both obviously only applicable for Macs)
defaults write -g ApplePressAndHoldEnabled -bool true
Might help if it got turned off.> Danmark, officielt Kongeriget Danmark, er et land i Skandinavien og en suveræn stat. Det er den sydligste af de skandinaviske nationer, sydvest for Sverige og syd for Norge, og det grænser op til Tyskland mod syd. Grønland og Færøerne indgår også i den danske stat som rigsdele med selvstyre indenfor Danmarks Rige (Danmarks forhold til rigsdelene kaldes Rigsfællesskabet).
Eight Æ+Ø+Å in 382 characters.
When writing email/docs, autocorrector for the win.
Same thing in Italian: `e instead of è. Although, the German replacement is cleaner, I'd say.
As someone from Espanya, I welcome you to the club.
We don't use the accents in the same way as Spanish, Portuguese, Catalan and Italian, it doesn't mark stress.
That's… quite certainly not an opinion shared with all of your fellow inhabitants.
I use it because programming language syntax is mostly ergonomic only on US-like layouts, e.g. typing "{" causes a lot of strain if you have to do it on every other line.
In the Netherlands letters with diacritics don't even have their own key (Dutch computers tend to use US plus €).
I mapped my Caps-Lock key as Compose, so I hit compose-a-" to get ä, and so on through the set. I've made customs for Ω and µ since I use those a lot and couldn't remember their default sequences. It's handy having ® and ™ on tap as well, and I get typographical niceties like — and … vs - and ...
Once comited to muscle memory it's very easy
Edit: and ß is just a Opt+s. It becomes quite logical after you get the hang of it.
After pressing the right Alt key, AltGr, all of those characters are possible to type. Here's the layout:
https://upload.wikimedia.org/wikipedia/commons/thumb/2/22/KB...
right alt + q = ä
right alt + w = å
right alt + s = ß
right alt + y = ü
It took a day or two to get a hang of it but it's such a relief not being constrained by everything being developed for US layouts
⌥u e = ë
⌥w e = ė
For example, the key sequence required to type Kayodé is: ⇧k a y o d ⌥e e
etc.I used a QWERTY keyboard in France for a while, but switching back and forth between AZERTY and QWERTY each time I went on someone else computer, which happened often, I had to switch, qnd it is qnnoying.
You can learn to touch type but keep in mind that not all layouts are the same, you can bring your own keyboard, change the mapping, etc... There are solutions, but it wasn't worth it for me, so I got back to that terrible AZERTY keyboard because that's what everyone has in France.
option-` is for grave (è) option-i is for circumflex (é) option-n is for eñe (ñ) option-c is for cédille (ç)
When you called QWERTZ an abomination I simply had to upvote your comment.
It's slow if you have to type in another language, but in English it's fast "enough" for words like résumé.
The funny thing is that for all the getting used to different layouts, the one thing that really trips me up all the time is the different hand positioning for Control+C on Mac vs PC. Luckily, you can change the modifier key bindings in MacOS independently from the keyboard layout. But yeah, shortcuts that assume everyone has a / or whatever key are a pain too.
Thankfully I only need to write in two languages. With almost the same script.
Also, if you program or use a shell, then the Windows U.S. international keyboard layout is just unspeakably unbearable.
That sounds pretty good indeed. Any idea how could I go about setting this up under macOS?
> Also, if you program or use a shell, then the Windows U.S. international keyboard layout is just unspeakably unbearable.
I have indeed a couple of little, weird problems when working in the terminal. That's inconvenient but still beats switching between 3 layouts 50 times a day.
Sorry, no idea, but I'd expect it to be possible on OS X. And I really want this for Windows, too, as I have to use it.
> I have indeed a couple of little, weird problems when working in the terminal. That's inconvenient but still beats switching between 3 layouts 50 times a day.
Oof, I can't get used to having to type '' to make one ', "" to make one ", `` to make one `, in the shell, in $EDITOR, etc. It's too painful. So I switch layouts as needed, and I hate it. Compose keys would be so much better!
This can be one of the reasons that switching to Dvorak can be super hard, all the shortcuts become quite weird unless you remap them each by hand.
bombcar: often the shortcuts will remain the same even on keyboards where those keys are nowhere near each other
You're objecting to opposite things: you don't like that the shortcuts stayed with the same symbols instead of staying with the physical key, and 9ev the other way around.
(And also 9ev is objecting to misleading documentation)
Issues like this are why often people just give up and learn US English enough to use the computer, then at least it’s tested and consistent.
... Oh, for fuck's sake! What English word do they think "V" is short for in the first place, there?
The validation was done by checking for the AZERTY-specific key combos that result in 0-9; on AZERTY to get a <number> you need to press SHIFT+<number>.
So if you had a QWERTY keyboard, you could not enter your phone number, the input stayed blank. (If you tried with SHIFT, you could get !@#$%^&*(() to the field however.)
I believe either FedEx or UPS still can't deal with it.
In top of that Swiss mail is quite strict to how a letter is addressed and what is written on the mailbox. Luckily the mail carriers know to ignore garbled umlauts.
However, my home country postal system has since changed to an online system for sending post out of the country: You go to a website and enter the destination address, then you pay and it'll print a code which you just give to the actual post office when you bring the letter/package whatever. What's infuriating is that they don't allow Japanese addresses - I can enter it, but it just creates an error message. So I again have to come up with a crude romanized address and cross fingers that it'll arrive (which it usually does - but up to a few weeks delayed).
In short - things are not getting betters over the years.
Now the hard part is changing how to deal with it, because now you need to patch all these huge production systems that were working before, and it's a breaking change.
So if you have a big stack: UI --> business layer --> DB
You can't just change the UI, as that will cause breakage in the pieces below. You start with the DB change, then the business layer, and you do the UI last.
Moreover this is not a simple change. Getting a DB to handle unicode is a known thing, but how do you train your customer support personnel to do data entry with unicode characters? Do you expect the customer to remember the code point? There are many characters that look the same which have different code points. So what you need to do is come up with a list of officially supported extended character code points and do entry with those, but still you will have others -- users of Asian scripts, for example, whose characters will be missing.
And you will get customers still doing the old "u" approach together with the official umlaut code point, sometimes for the same name and the same package. People will call up, trying to find their package, and randomly used one convention, since even though you can train your staff (which isn't cheap) you can't train your customers. So you need some system of identifying different orthography for the same underlying name, some with "u" and some with "ü" and some with "ue". And then that's going to require changes in a lot of other systems, for example reporting systems, etc. We see this problem today, taken to the extreme, in the various different spellings of "Gadafi".
But really it's worse, as a distributed system has
UI <--> business layer <--> regional DB <--> business layer <--> regional UI
And now it's much harder to make these changes without taking systems off line, for a distributed global network.
What they probably did, as most companies do, is look at all these problems and costs, compare them to relatively small benefits, and kick the can down the road, waiting for the next major system upgrade, and sometimes these next major upgrades can take 20 years to happen. Or even longer.
In other words, the hart part is the incremental breaking change to the system, not the dealing with the umlaut. If this was a brand new code base that was just being written, they could make it handle umlaut with much less cost.
[0] https://intellij-support.jetbrains.com/hc/en-us/community/po...
Guess what, y and z are swapped on a German keyboard.
What your parent comment complains about is that the keyboard shortcut is based on the location of the key, and not the letter.
What you complain about is that the keyboard shortcut is based on the letter, and not the location.
Obviously, these complaints don't contradict each other, both make sense in different circumstances. But figuring that out requires awareness of different keyboard layouts, and of the difference between KeyboardEvent.code (location) and KeyboardEvent.key (letter).
Seem rather straight forward.
Many shortcuts are positional, like "hjkl" or "wasd" for moving , or control/meta+numbers but there's no good way to denote them without assuming you are using a qwerty keyboard. Programming against them is possible,but many times there's limitations, ignorance about the different layouts, or straight neglect.
[1]: https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEve...
Google's currently demanding I settle an invoice for an account I closed... and the only way to do this, or even get support, is if you have a Google account. And zero way of replying to the email their Collections department.
On the one hand they have a massive dominant position in multiple markets. On the other hand, if you're even slightly off the happy path you don't exist.
Maybe the blunt response to complaints about the US American bias is, it's our software, our (ASCII/Unicode) language, get used to it.
I mean, seriously, what kind of antiquated statement is that? Do you actually want to keep geographical borders to persist to the internet, or work towards lower barriers for everyone..?
They haven’t and they got the money anyway.