61–70 of 211 posts
Earlier quoted context omitted.
It may work for you, but there are users of languages that simply cannot be covered by QWERTY, and in these cases they would like from developers to simply fix their goddamn code, and bind to keys, not characters.
You are correct. It works for me.
Earlier quoted context omitted.
As multilingual user constantly switching between 3 languages, that's why I fully committed to the US_intl keyboard layout a while ago and ditched the abomination that is QWERTZ. Took a while to get used to, but overall it has been a very noticeable improvement. One layout to cover all languages, no more constant switching. Edit for clarity: I type "a to get ä and 'a to get à. If I want to type actual quotes followed…
How do you type ä ö ü ß ?
Once comited to muscle memory it's very easy
I think the title should say "in French *Google docs." As is, it seems like French code documentation/papers are littered with emojis?
There's more of this implicit US American bias in modern computing than you would think after the whole ASCII/Unicode mess - I thought they finally learnt something about computers actually being used by other people back then, but no. 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 t…
Even at a multinational like apple. I was fighting in the provisioning dash board a few years ago because it would not load. Issue was my last name which has an umlaut in it. This wasn't 1990 it was 2012 issh and I still see companies unable to deal with umlaut. 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 mai…
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.
I didn't realize French was written with spaces before colons. It might be time to lose that space, similar to how we don't double space after period. I'm not saying G.Docs or any editor should dictate how French is written, only being pragmatic if I have to choose between (no space): or unwanted emojis ending up in docs.
Well, that's is a bit like saying "it might be time to write your whenever you mean you're" just because Google Docs' autocorrect feature kept messing up the two when you wrote English.
How would it look like in an email to a client?
Earlier quoted context omitted.
As multilingual user constantly switching between 3 languages, that's why I fully committed to the US_intl keyboard layout a while ago and ditched the abomination that is QWERTZ. Took a while to get used to, but overall it has been a very noticeable improvement. One layout to cover all languages, no more constant switching. Edit for clarity: I type "a to get ä and 'a to get à. If I want to type actual quotes followed…
How do you type ä ö ü ß ?
Edit: and ß is just a Opt+s. It becomes quite logical after you get the hang of it.
Earlier quoted context omitted.
As multilingual user constantly switching between 3 languages, that's why I fully committed to the US_intl keyboard layout a while ago and ditched the abomination that is QWERTZ. Took a while to get used to, but overall it has been a very noticeable improvement. One layout to cover all languages, no more constant switching. Edit for clarity: I type "a to get ä and 'a to get à. If I want to type actual quotes followed…
How do you type ä ö ü ß ?
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...
This space before the colon and other marks in French should actually be a narrow non-breaking space (U+202F) [0]. There's no key for it in the AZERTY layout. This has been a problem since the typewriter age. People having to get on with their jobs coped with it by using a full, breaking em-space. Unless this gets replaced automatically by the word processor, you get horrid typography and misplaced line breaks all ov…
"some-chars" + + ":"
must be treated as a single word in French.
(I guess it's more complicated than I imagine it is, alright)
This space before the colon and other marks in French should actually be a narrow non-breaking space (U+202F) [0]. There's no key for it in the AZERTY layout. This has been a problem since the typewriter age. People having to get on with their jobs coped with it by using a full, breaking em-space. Unless this gets replaced automatically by the word processor, you get horrid typography and misplaced line breaks all ov…
This sounds like it's not actually true? If it was, the French code page 646 that we used until Unicode finally won would have included a narrow space, but it doesn't. "Regular" computer text in French has only ever used a normal space, even if handwriting and/or "true" typesetting using typesetting solutions like TeX or PageMaker etc. allowed for a narrow space.
I'd be surprised MS Word doesn't do the same. No need for a "true" typesetting solution.
