32 ms·

The plague of emoji insertion in French docs

185 points by bibelo 4y ago

9dev 4y ago
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 the key where American layouts have a slash will.
- bombcar 4y ago
  Stuff like this is super, super common. Even where you have things like CTRL + X/C/V for cut/copy/paste it's clear that the letters were picked to be near each other - but then often the shortcuts will remain the same even on keyboards where those keys are nowhere near each other. 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.
  - jefftk 4y ago
    9ev: pressing the key where American layouts have a slash will [open the search box] 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)
    - bombcar 4y ago
      Yeah - and balancing the two is something often entirely overlooked and people stuck with the problem have to learn the options and try to determine “is this key the character or the key (in a US layout)”. 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.
  - yjftsjthsd-h 4y ago
    Yeah, if I could go back in time I would have told my younger self that it's okay to use something other than qwerty, and it's okay to use vim, but trying to to do both was a hilariously terrible idea.
  - TremendousJudge 4y ago
    Some go as far as translating shortcuts, which I dislike even more. In Spanish Windows, copy is CTRL + C (copiar), but paste is... CTRL + P (pegar)
    - bombcar 4y ago
      Reminds me of a US tap in Mexico I saw once - the installer obviously decided C must be for caliente which meant the H should be hielo.
      - TremendousJudge 4y ago
        That's great. To be fair, caliente and helado doesn't seem a very unreasonable interpretation if you're installing in a place where people don't speak English
    - a1369209993 4y ago
      > but paste is... CTRL + P (pegar) ... Oh, for fuck's sake! What English word do they think "V" is short for in the first place, there?
  - wizofaus 4y ago
    You mean it's not X for xterminate, C for copy and V for velcro?
  - lopis 4y ago
    CTRL + Z for undo in QWERTZ keyboards is just absolutely impractical.
- aendruk 4y ago
  My latest peeve here is the websites that try to filter out non-numeric key presses in form fields. You don’t know where my number keys are! Sometimes the only way to enter a number is to copy and paste it from a text editor.
  - jxy 4y ago
    I use Dvorak-dvp, and I hate those form fields.
  - keybored 4y ago
    Ooh, good point. I should test if that works with a French layout in our app :)
- WA 4y ago
  Every small indie game ever: action buttons are x and z. Guess what, y and z are swapped on a German keyboard.
  - amadeuspagel 4y ago
    That's an illustration that the problem is not so easy. 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).
    - runarberg 4y ago
      Give the actions appropriate names and allow users to remap them. Have a few common layouts you can select from. Allow users to select a language and locale (separately) when they first launch. Refer to the actions not the keys in the documentation, and when you do specify key (e.g. in parenthesis) have it dynamically reflect the current setup. Seem rather straight forward.
  - wazoox 4y ago
    And W and Z, and Q and A on French keyboard. WASD is totally unusable, and unfortunately quite common in web apps for instance.
  - poulpy123 4y ago
    I would say it's more a problem of the underlying système (game engine or os) that should manage the compatibility between keyboard layout
- amadeuspagel 4y ago
  That might a problem with a specific website, but you can easily implement that correctly using the event key property[1]. [1]: https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEvent/key https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEve...
  - 9dev 4y ago
    Thank you for the suggestion, but that's indeed a problem with lots of websites that get this utterly wrong. Browsing the web using a non-US keyboard is fun.
- nells 4y ago
  If people of other countries didn’t want American bias in their systems they should’ve made their own and made them better than American ones are.
  - 9dev 4y ago
    If American businesses wanted the money of people from other countries, they should've made their systems internationally accessible. 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..?
    - nells 4y ago
      > If American businesses wanted the money of people from other countries, they should've made their systems internationally accessible. They haven’t and they got the money anyway.
      - 9dev 4y ago
        Assuming what they got was the maximum obtainable amount, yes :)
- dietr1ch 4y ago
  I really hate that so many things break after you switch keyboard layouts. 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.
- mrzool 4y ago
  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 by a vocal I need to “confirm” the quotes with space before typing the vocal. That’s all there is to it, really.
  - grishka 4y ago
    I envy you for all your languages using Latin-based alphabets. I guess I'm stuck with two keyboard layouts for life because I need to be able to type in both Latin and Cyrillic.
  - senand 4y ago
    Same here
  - WA 4y ago
    How do you type ä ö ü ß ?
    - Cockbrand 4y ago
      ⌥u creates the two dots, then you press the key for the vowel to put underneath. ⌥s creates the ß. (Both obviously only applicable for Macs)
      - cwillu 4y ago
        Applicable to linux if you set the mac qwerty keyboard layout, which is surprisingly convenient.
      - mrzool 4y ago
        That would be… inconvenient. That’s not how I use it. 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.
- sschueller 4y ago
  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 mailbox. Luckily the mail carriers know to ignore garbled umlauts.
  - Tor3 4y ago
    When I was living in Japan I always had to "romanize" my Japanese address if I got something shipped from USA because USPS only allows ASCII. Even if this did create problems locally - post always arrive quicker (in my experience) if the address is in proper Japanese. When I got mail from my home country I got it forwarded via my company and they always just stuck on a printed label with my address, in Kanji. No problems there. Worked fine for years. 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.
  - rsj_hn 4y ago
    The problem is that they were dealing with it successfully before, by either treating the umlaut as a "u" or a "ue". It's not like umlauts are this new technology that English speakers have never been faced with in their business ledgers. But what you see in older business ledgers, is a variety of different spellings, and a human brain that can map them to each other, with a little bit of training. And when software came along, most systems just used the "u" approach, and that kinda worked as software systems grew to massive scale. 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.
- dcminter 4y ago
  Unless it's changed recently, IntelliJ IDEA has similar annoyances[0]. Again, using the equivalently placed key works instead. Are they using scan-codes for some reason? Seems extra bizarre given that JetBrains isn't even a US based company! [0] https://intellij-support.jetbrains.com/hc/en-us/community/posts/206167969-Foreign-Language-Keyboard-Shortcuts https://intellij-support.jetbrains.com/hc/en-us/community/po...
  - deleted 4y ago
    [deleted]
- jakub_g 4y ago
  I live in France but use QWERTY instead of AZERTY, and I once had an opposite problem: on a French website, there was an <input> for phone number, validating that it stays [0-9] on each keystroke. 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.)
  - layer8 4y ago
    They didn’t allow NumPad?
- generalizations 4y ago
  There was a comment the other day in the discussion about incorporation in Germany. Someone complained that in Germany, they conduct their business in German: the justification was, it's our country, our language, get used to it. Maybe the blunt response to complaints about the US American bias is, it's our software, our (ASCII/Unicode) language, get used to it.
  - 9dev 4y ago
    If I was trying to incorporate in the USA, and the registration form would be unable to process diacritics, sure — even though that would neglect a large part of your own population (see the ASCII debacle) — but we’re talking about internet services marketed globally. I don’t think it’s too much to ask to have an app at least working as designed. We’re not even talking about translating stuff!
- grishka 4y ago
  A very common bug is people confusing key codes (the raw codes for the physical keys on the keyboard) and characters (what they type). This "works" when you use the QWERTY layout, but completely breaks when it's something else, like ЙЦУКЕН.
- afandian 4y ago
  It's amusing that for the huge amounts Google pay developers it doesn't necessarily buy common sense or empathy for the user. 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.
Aardwolf 4y ago
Personally I like auto suggestions like this, but I never want it to interrupt typing, so it should never grab input when you press typing-related keyboard keys, including the enter key, space and arrow keys which you need to move the cursor around. I do not want to have to close boxes that appear at arbitrary times with the esc key to continue regular typing, since the box interrupts flow and there is a reaction time between seeing the box and closing it with esc. It would be ok to me if you have to use another less regularly used key, e.g. tab or ctrl+space, first to get into the suggestion box and then use arrows to select one. This applies also (especially in fact) in code editors, chrome devtools, etc... I wish others felt the same so this feature would be implemented in a less interrupting way by default. I've never seen it implemented in a non-interrupting way in anything ever.
- brookst 4y ago
  I like the implementation in a bunch of IM clients, at least Teams and iMessage: emojis are treated as autocorrect, so if you type the full text version of the emoji (not just the first character!) it gets replaced with the emoji. In the rare cases it's wrong, hitting escape after the autocorrect fixes it. I don't see why the Google Docs implementation wouldn't work that way. If it really must pop up a box, allow the user to continue typing in document and gradually reduce the list of candidate emojis. As soon as a character is typed that either complete the emoji or rules all of them out, the box goes away.
  - happyopossum 4y ago
    The issue is that a very common key to hit after a colon is Enter - which selects the emoji in question. If you simply keep typing other letters, you don't have a problem.
    - brookst 4y ago
      Yes; since emojis don't contain <enter>, in my model it should dismiss the dialog and not do a replacement. The error is in the emoji panel stealing focus so <enter> is seen as a selection in the panel. If they panel did not have focus and keystrokes still went to the main app, this would work fine.
lerela 4y ago
It's the same with Gitlab issues and comments and it's a small but very real pain.
- Majestic121 4y ago
  Same for Github as well. Super annoying when you're in the middle of an issue
  - enw 4y ago
    UX testing should be done in a stressful and chaotic environment. Good UX becomes invisible, bad UX becomes abundantly obvious.
gabagool 4y ago
I think the title should say "in French *Google docs." As is, it seems like French code documentation/papers are littered with emojis?
- graindcafe 4y ago
  But it also occurs on Atlassian suite, Gitlab, Github and probably more tools…
ClassyJacket 4y ago
This annoys the hell out of me and I only speak English. Microsoft is probably the biggest development-focused company in the world, but their own work communications app, Teams, doesn't allow you to paste small pieces of code in a chat because it replaces punctuation with emoji. Regardless, if I want an emoji, I will type the emoji. If I typed ':)' I want ':)' not some stupid yellow face. Meta's Facebook Messenger doesn't allow those forbidden strings either. Meta's WhatsApp mobile does, but WhatsApp web does not. My phone has an emoji picker if I want an emoji. I don't want what I type or paste replaced with an emoji. Anywhere. Ever. This practice should stop.
- kaladin-jasnah 4y ago
  My way of getting around the emoji conversions from ':)' to a smiley face is typing it in reverse: '(:' or '):'.
  - homonculus1 4y ago
    But I'm not left-handed!
    - deleted 4y ago
      [deleted]
  - DonHopkins 4y ago
    Plus then you can stick out your tongue like this: c(: c):
  - layer8 4y ago
    I don’t remember which software, but I’ve seen those being converted as well.
- yjftsjthsd-h 4y ago
  > their own work communications app, Teams, doesn't allow you to paste small pieces of code in a chat because it replaces punctuation with emoji. Don't you just put it in backticks `like this`? Even for really short things, it seems clearer and it avoids the machine "helpfully" changing things. (Your general point is correct, of course, just suggesting a solution to this very particular nuisance)
karmakaze 4y ago
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.
- jheriko 4y ago
  the us is fairly unique in the rate it accepts common mistakes into the language. its part of how they diverged from the standard english used in the rest of the world so quickly...
- nmilo 4y ago
  We used to double-space after a period because that looked better on monospaced typewriters. But in French it's simply a part of punctuation, and getting it wrong means you wrote it wrong. It's as wrong as if I'm writing English and put a space before the ':' or '!', or put a comma after a quotation mark. French people shouldn't have to change their language to type in Google Docs. It should be the other way around.
  - cryptonector 4y ago
    In French it's a typographic rule become an orthographic rule. It doesn't have to be that way.
- happytoexplain 4y ago
  >if I have to choose between (no space): or unwanted emojis ending up in docs We absolutely do not have to choose between those two things. We need to stop implementing cute automatic bullshit that makes assumptions about the way people interact with UIs.
- dheavy 4y ago
  >It might be time to lose that space, similar to how we don't double space after period. 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?
Aissen 4y ago
Typographic nerd: technically, you should you use a non-breaking space (espace insécable) before colons in french. Doing that does not show the popup. Wait, what do you mean your keyboard layout does not have it? Keyboard layout nerd: you should use a keymap that has it. Like AFNOR's latest AZERTY or BÉPO. Historical nerd: traditionally wordprocessors have auto-inserted non-breaking spaces before colons, why should I care now ?
- rodelrod 4y ago
  A narrow non-breaking space, please.
  - Aissen 4y ago
    Of course, sorry.
- hadrien01 4y ago
  Non-breaking spaces are transformed automatically when writing French by Word, LaTeX, and other text processors. Why would you want to learn the many ways of writing a spacing character, when your computer can do it for you?
  - Aissen 4y ago
    Thanks for repeating the last sentence of my post in your own words :-)
- klodolph 4y ago
  Or you should use a line-breaking algorithm that does not suggest a break at that location. Line breaking is supposed to be tailored to language.
  - Aissen 4y ago
    I'd agree, but this is even more subtle, as a sibling comment to yours said: the space is actually smaller. So text rendering should take this rule into account as well. But then you're assuming that you're doing single-language text rendering. Putting the character at writing time still seems like a simpler tradeoff (maybe with editing help like auto-replace or correction).
rodelrod 4y ago
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 over the place. The Académie Française should have dealt with this years ago, if their ass wasn't stuck in the 17th century. [0] https://www.compart.com/en/unicode/U+202F https://www.compart.com/en/unicode/U+202F
- TheRealPomax 4y ago
  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.
  - pcdavid 4y ago
    FWIW, LibreOffice automatically inserts an actual Unicode NO-BREAK SPACE when I type ":" at the end of a word (if the language is set for French of course). If I insert an actual SPACE and then hit ":", it even replaces the SPACE with a NO-BREAK SPACE. I'd be surprised MS Word doesn't do the same. No need for a "true" typesetting solution.
    - rodelrod 4y ago
      I think the point of the GP is that it inserts NO-BREAK SPACE instead of a NARROW NO-BREAK SPACE. If that's the case, it's a bug.
  - dieulot 4y ago
    This? https://en.wikipedia.org/wiki/Code_page_1010 https://en.wikipedia.org/wiki/Code_page_1010 There’s no space for it nor for many other more useful characters (like â).
poulpy123 4y ago
It was also the case on gitlab/GitHub at one point
- jansan 4y ago
  Seems like the person who came up with the idea got fired and then hired by Google ;)
Kenji 4y ago
derac 4y ago
I have a partial solution in TamperMonkey here: https://gist.github.com/derac/887efd8891caa026322b76249548931f https://gist.github.com/derac/887efd8891caa026322b7624954893... I wrote it over my lunch break quickly, it only closes the menu the first time. I was trying to add the functionality to close it every time you enter the key combo, but it wasn't working. If someone wants to improve this feel free. MIT licensed.
- derac 4y ago
  doesn't really matter since they are fixing it, but I made this work
usrusr 4y ago
A similar insensitivity is the observation that none of the major Android keyboards allows true disabling of auto-blank, which is super annoying in a language like German where custom composite words occur a lot. Modern keyboards offer a wide selection of clever tricks to keep the auto-blank from messing up punctuation, but allowing one word to be swiped directly after the one before? I'm sorry, Dave, I'm afraid I can't let you do that. This post is written on Swype, final release back in 2014.
dvh 4y ago
Same thing happen in pascal in lot of forums, in: var x:Pointer; The :P changes to tongue out emoji
TeeMassive 4y ago
Auto insertions or anything that does things behind the users' back should go die in a fire.
- cryptonector 4y ago
  Problem is that this is totally normal for CJK users, where you really want to type in a syllabic or phonetic or similar system and get drop-down selection menus for Chinese/Kanji characters to replace your writing with. Doing that for emoji is basically the same thing for CJK users. For Latin script users, however, this is very disruptive.
  - TeeMassive 4y ago
    I dabbled in Japanese; you are not comparing the same thing.
    - cryptonector 4y ago
      It's not that different.
      - TeeMassive 4y ago
        It is because it is required to produce the wanted characters and is usually implemented by the OS / browser, not at the final application level which interferes with this process.
        cryptonector 4y ago
        The UX is still that you get a drop-down picker. What component of the system implements that seems of little importance to users unless that becomes obvious (each app doing it differently, though obviously that happens). I expect that the emoji picker will become part of the OS eventually. Heck, Windows has one that you have to call up explicitly (with <Alt>-.), iOS has an emoji "keyboard" (input mode), etc, so we're headed in that direction.
earthboundkid 4y ago
8)
jansan 4y ago
So this was reported on October 31st, then escalated on November 3rd, and the "feature" is still in there. Seeing how severly this impacts users from France, this is slightly diappointing. Here is a discussion in the product support forum: https://support.google.com/docs/thread/186496870/how-to-deactivate-emoji-popup-on-colon-in-google-docs?hl=en https://support.google.com/docs/thread/186496870/how-to-deac...
djcannabiz 4y ago
i have caps lock and escape swapped on my computer. soooo nice for vim and just in general.
alucardo 4y ago
The same happens with Jira. It's a nightmare since if you press escape to quit the emoji mode, you abort your input and lose focus. There should be a way to configure that shortcut to whatever suites you. Anyway i don't get why web apps bother implementing their own emoji input, the operating system does it already (the windows key + ; shortcut for example). And to reply to those who simply ask people to change their habit: it's rude. Imagine the other way around: all the English typing people having to insert a space before a : for whatever reason, would that makes sense to you?
antpls 4y ago
In Zendesk, you get an Halloween pumpkin emoji instead of a thumb up. I always wondered if it was an annoying easter egg or a bug.
tonnydourado 4y ago
We have some templates for gitlab issues at work, and it always bothered me that all the colons had a space before it. Both because it triggers the same annoying emoji feature, and also because it looks weird to me. Now it all makes sense: although the templates are in English, they have been authored by a French person, so the rule just bled into English writing.

185 points by bibelo 4y ago

9dev 4y ago

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 the key where American layouts have a slash will.

bombcar 4y ago
Stuff like this is super, super common. Even where you have things like CTRL + X/C/V for cut/copy/paste it's clear that the letters were picked to be near each other - but then often the shortcuts will remain the same even on keyboards where those keys are nowhere near each other. 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.
- jefftk 4y ago
  9ev: pressing the key where American layouts have a slash will [open the search box] 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)
  - bombcar 4y ago
    Yeah - and balancing the two is something often entirely overlooked and people stuck with the problem have to learn the options and try to determine “is this key the character or the key (in a US layout)”. 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.
- yjftsjthsd-h 4y ago
  Yeah, if I could go back in time I would have told my younger self that it's okay to use something other than qwerty, and it's okay to use vim, but trying to to do both was a hilariously terrible idea.
- TremendousJudge 4y ago
  Some go as far as translating shortcuts, which I dislike even more. In Spanish Windows, copy is CTRL + C (copiar), but paste is... CTRL + P (pegar)
  - bombcar 4y ago
    Reminds me of a US tap in Mexico I saw once - the installer obviously decided C must be for caliente which meant the H should be hielo.
    - TremendousJudge 4y ago
      That's great. To be fair, caliente and helado doesn't seem a very unreasonable interpretation if you're installing in a place where people don't speak English
  - a1369209993 4y ago
    > but paste is... CTRL + P (pegar) ... Oh, for fuck's sake! What English word do they think "V" is short for in the first place, there?
- wizofaus 4y ago
  You mean it's not X for xterminate, C for copy and V for velcro?
- lopis 4y ago
  CTRL + Z for undo in QWERTZ keyboards is just absolutely impractical.
aendruk 4y ago
My latest peeve here is the websites that try to filter out non-numeric key presses in form fields. You don’t know where my number keys are! Sometimes the only way to enter a number is to copy and paste it from a text editor.
- jxy 4y ago
  I use Dvorak-dvp, and I hate those form fields.
- keybored 4y ago
  Ooh, good point. I should test if that works with a French layout in our app :)
WA 4y ago
Every small indie game ever: action buttons are x and z. Guess what, y and z are swapped on a German keyboard.
- amadeuspagel 4y ago
  That's an illustration that the problem is not so easy. 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).
  - runarberg 4y ago
    Give the actions appropriate names and allow users to remap them. Have a few common layouts you can select from. Allow users to select a language and locale (separately) when they first launch. Refer to the actions not the keys in the documentation, and when you do specify key (e.g. in parenthesis) have it dynamically reflect the current setup. Seem rather straight forward.
- wazoox 4y ago
  And W and Z, and Q and A on French keyboard. WASD is totally unusable, and unfortunately quite common in web apps for instance.
- poulpy123 4y ago
  I would say it's more a problem of the underlying système (game engine or os) that should manage the compatibility between keyboard layout
amadeuspagel 4y ago
That might a problem with a specific website, but you can easily implement that correctly using the event key property[1]. [1]: https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEvent/key https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEve...
- 9dev 4y ago
  Thank you for the suggestion, but that's indeed a problem with lots of websites that get this utterly wrong. Browsing the web using a non-US keyboard is fun.
nells 4y ago
If people of other countries didn’t want American bias in their systems they should’ve made their own and made them better than American ones are.
- 9dev 4y ago
  If American businesses wanted the money of people from other countries, they should've made their systems internationally accessible. 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..?
  - nells 4y ago
    > If American businesses wanted the money of people from other countries, they should've made their systems internationally accessible. They haven’t and they got the money anyway.
    - 9dev 4y ago
      Assuming what they got was the maximum obtainable amount, yes :)
dietr1ch 4y ago
I really hate that so many things break after you switch keyboard layouts. 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.
mrzool 4y ago
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 by a vocal I need to “confirm” the quotes with space before typing the vocal. That’s all there is to it, really.
- grishka 4y ago
  I envy you for all your languages using Latin-based alphabets. I guess I'm stuck with two keyboard layouts for life because I need to be able to type in both Latin and Cyrillic.
- senand 4y ago
  Same here
- WA 4y ago
  How do you type ä ö ü ß ?
  - Cockbrand 4y ago
    ⌥u creates the two dots, then you press the key for the vowel to put underneath. ⌥s creates the ß. (Both obviously only applicable for Macs)
    - cwillu 4y ago
      Applicable to linux if you set the mac qwerty keyboard layout, which is surprisingly convenient.
    - mrzool 4y ago
      That would be… inconvenient. That’s not how I use it. 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.
sschueller 4y ago
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 mailbox. Luckily the mail carriers know to ignore garbled umlauts.
- Tor3 4y ago
  When I was living in Japan I always had to "romanize" my Japanese address if I got something shipped from USA because USPS only allows ASCII. Even if this did create problems locally - post always arrive quicker (in my experience) if the address is in proper Japanese. When I got mail from my home country I got it forwarded via my company and they always just stuck on a printed label with my address, in Kanji. No problems there. Worked fine for years. 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.
- rsj_hn 4y ago
  The problem is that they were dealing with it successfully before, by either treating the umlaut as a "u" or a "ue". It's not like umlauts are this new technology that English speakers have never been faced with in their business ledgers. But what you see in older business ledgers, is a variety of different spellings, and a human brain that can map them to each other, with a little bit of training. And when software came along, most systems just used the "u" approach, and that kinda worked as software systems grew to massive scale. 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.
dcminter 4y ago
Unless it's changed recently, IntelliJ IDEA has similar annoyances[0]. Again, using the equivalently placed key works instead. Are they using scan-codes for some reason? Seems extra bizarre given that JetBrains isn't even a US based company! [0] https://intellij-support.jetbrains.com/hc/en-us/community/posts/206167969-Foreign-Language-Keyboard-Shortcuts https://intellij-support.jetbrains.com/hc/en-us/community/po...
- deleted 4y ago
  [deleted]
jakub_g 4y ago
I live in France but use QWERTY instead of AZERTY, and I once had an opposite problem: on a French website, there was an <input> for phone number, validating that it stays [0-9] on each keystroke. 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.)
- layer8 4y ago
  They didn’t allow NumPad?
generalizations 4y ago
There was a comment the other day in the discussion about incorporation in Germany. Someone complained that in Germany, they conduct their business in German: the justification was, it's our country, our language, get used to it. Maybe the blunt response to complaints about the US American bias is, it's our software, our (ASCII/Unicode) language, get used to it.
- 9dev 4y ago
  If I was trying to incorporate in the USA, and the registration form would be unable to process diacritics, sure — even though that would neglect a large part of your own population (see the ASCII debacle) — but we’re talking about internet services marketed globally. I don’t think it’s too much to ask to have an app at least working as designed. We’re not even talking about translating stuff!
grishka 4y ago
A very common bug is people confusing key codes (the raw codes for the physical keys on the keyboard) and characters (what they type). This "works" when you use the QWERTY layout, but completely breaks when it's something else, like ЙЦУКЕН.
afandian 4y ago
It's amusing that for the huge amounts Google pay developers it doesn't necessarily buy common sense or empathy for the user. 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.

Aardwolf 4y ago

Personally I like auto suggestions like this, but I never want it to interrupt typing, so it should never grab input when you press typing-related keyboard keys, including the enter key, space and arrow keys which you need to move the cursor around. I do not want to have to close boxes that appear at arbitrary times with the esc key to continue regular typing, since the box interrupts flow and there is a reaction time between seeing the box and closing it with esc. It would be ok to me if you have to use another less regularly used key, e.g. tab or ctrl+space, first to get into the suggestion box and then use arrows to select one. This applies also (especially in fact) in code editors, chrome devtools, etc... I wish others felt the same so this feature would be implemented in a less interrupting way by default. I've never seen it implemented in a non-interrupting way in anything ever.

brookst 4y ago
I like the implementation in a bunch of IM clients, at least Teams and iMessage: emojis are treated as autocorrect, so if you type the full text version of the emoji (not just the first character!) it gets replaced with the emoji. In the rare cases it's wrong, hitting escape after the autocorrect fixes it. I don't see why the Google Docs implementation wouldn't work that way. If it really must pop up a box, allow the user to continue typing in document and gradually reduce the list of candidate emojis. As soon as a character is typed that either complete the emoji or rules all of them out, the box goes away.
- happyopossum 4y ago
  The issue is that a very common key to hit after a colon is Enter - which selects the emoji in question. If you simply keep typing other letters, you don't have a problem.
  - brookst 4y ago
    Yes; since emojis don't contain <enter>, in my model it should dismiss the dialog and not do a replacement. The error is in the emoji panel stealing focus so <enter> is seen as a selection in the panel. If they panel did not have focus and keystrokes still went to the main app, this would work fine.

lerela 4y ago

It's the same with Gitlab issues and comments and it's a small but very real pain.

Majestic121 4y ago
Same for Github as well. Super annoying when you're in the middle of an issue
- enw 4y ago
  UX testing should be done in a stressful and chaotic environment. Good UX becomes invisible, bad UX becomes abundantly obvious.

gabagool 4y ago

I think the title should say "in French *Google docs." As is, it seems like French code documentation/papers are littered with emojis?

graindcafe 4y ago
But it also occurs on Atlassian suite, Gitlab, Github and probably more tools…

ClassyJacket 4y ago

This annoys the hell out of me and I only speak English. Microsoft is probably the biggest development-focused company in the world, but their own work communications app, Teams, doesn't allow you to paste small pieces of code in a chat because it replaces punctuation with emoji. Regardless, if I want an emoji, I will type the emoji. If I typed ':)' I want ':)' not some stupid yellow face. Meta's Facebook Messenger doesn't allow those forbidden strings either. Meta's WhatsApp mobile does, but WhatsApp web does not. My phone has an emoji picker if I want an emoji. I don't want what I type or paste replaced with an emoji. Anywhere. Ever. This practice should stop.

kaladin-jasnah 4y ago
My way of getting around the emoji conversions from ':)' to a smiley face is typing it in reverse: '(:' or '):'.
- homonculus1 4y ago
  But I'm not left-handed!
  - deleted 4y ago
    [deleted]
- DonHopkins 4y ago
  Plus then you can stick out your tongue like this: c(: c):
- layer8 4y ago
  I don’t remember which software, but I’ve seen those being converted as well.
yjftsjthsd-h 4y ago
> their own work communications app, Teams, doesn't allow you to paste small pieces of code in a chat because it replaces punctuation with emoji. Don't you just put it in backticks `like this`? Even for really short things, it seems clearer and it avoids the machine "helpfully" changing things. (Your general point is correct, of course, just suggesting a solution to this very particular nuisance)

karmakaze 4y ago

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.

jheriko 4y ago
the us is fairly unique in the rate it accepts common mistakes into the language. its part of how they diverged from the standard english used in the rest of the world so quickly...
nmilo 4y ago
We used to double-space after a period because that looked better on monospaced typewriters. But in French it's simply a part of punctuation, and getting it wrong means you wrote it wrong. It's as wrong as if I'm writing English and put a space before the ':' or '!', or put a comma after a quotation mark. French people shouldn't have to change their language to type in Google Docs. It should be the other way around.
- cryptonector 4y ago
  In French it's a typographic rule become an orthographic rule. It doesn't have to be that way.
happytoexplain 4y ago
>if I have to choose between (no space): or unwanted emojis ending up in docs We absolutely do not have to choose between those two things. We need to stop implementing cute automatic bullshit that makes assumptions about the way people interact with UIs.
dheavy 4y ago
>It might be time to lose that space, similar to how we don't double space after period. 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?

Aissen 4y ago

Typographic nerd: technically, you should you use a non-breaking space (espace insécable) before colons in french. Doing that does not show the popup. Wait, what do you mean your keyboard layout does not have it? Keyboard layout nerd: you should use a keymap that has it. Like AFNOR's latest AZERTY or BÉPO. Historical nerd: traditionally wordprocessors have auto-inserted non-breaking spaces before colons, why should I care now ?

rodelrod 4y ago
A narrow non-breaking space, please.
- Aissen 4y ago
  Of course, sorry.
hadrien01 4y ago
Non-breaking spaces are transformed automatically when writing French by Word, LaTeX, and other text processors. Why would you want to learn the many ways of writing a spacing character, when your computer can do it for you?
- Aissen 4y ago
  Thanks for repeating the last sentence of my post in your own words :-)
klodolph 4y ago
Or you should use a line-breaking algorithm that does not suggest a break at that location. Line breaking is supposed to be tailored to language.
- Aissen 4y ago
  I'd agree, but this is even more subtle, as a sibling comment to yours said: the space is actually smaller. So text rendering should take this rule into account as well. But then you're assuming that you're doing single-language text rendering. Putting the character at writing time still seems like a simpler tradeoff (maybe with editing help like auto-replace or correction).

rodelrod 4y ago

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 over the place. The Académie Française should have dealt with this years ago, if their ass wasn't stuck in the 17th century. [0] https://www.compart.com/en/unicode/U+202F https://www.compart.com/en/unicode/U+202F

TheRealPomax 4y ago
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.
- pcdavid 4y ago
  FWIW, LibreOffice automatically inserts an actual Unicode NO-BREAK SPACE when I type ":" at the end of a word (if the language is set for French of course). If I insert an actual SPACE and then hit ":", it even replaces the SPACE with a NO-BREAK SPACE. I'd be surprised MS Word doesn't do the same. No need for a "true" typesetting solution.
  - rodelrod 4y ago
    I think the point of the GP is that it inserts NO-BREAK SPACE instead of a NARROW NO-BREAK SPACE. If that's the case, it's a bug.
- dieulot 4y ago
  This? https://en.wikipedia.org/wiki/Code_page_1010 https://en.wikipedia.org/wiki/Code_page_1010 There’s no space for it nor for many other more useful characters (like â).

poulpy123 4y ago

It was also the case on gitlab/GitHub at one point

jansan 4y ago
Seems like the person who came up with the idea got fired and then hired by Google ;)

Kenji 4y ago

derac 4y ago

I have a partial solution in TamperMonkey here: https://gist.github.com/derac/887efd8891caa026322b76249548931f https://gist.github.com/derac/887efd8891caa026322b7624954893... I wrote it over my lunch break quickly, it only closes the menu the first time. I was trying to add the functionality to close it every time you enter the key combo, but it wasn't working. If someone wants to improve this feel free. MIT licensed.

derac 4y ago
doesn't really matter since they are fixing it, but I made this work

usrusr 4y ago

A similar insensitivity is the observation that none of the major Android keyboards allows true disabling of auto-blank, which is super annoying in a language like German where custom composite words occur a lot. Modern keyboards offer a wide selection of clever tricks to keep the auto-blank from messing up punctuation, but allowing one word to be swiped directly after the one before? I'm sorry, Dave, I'm afraid I can't let you do that. This post is written on Swype, final release back in 2014.

dvh 4y ago

Same thing happen in pascal in lot of forums, in: var x:Pointer; The :P changes to tongue out emoji

TeeMassive 4y ago

Auto insertions or anything that does things behind the users' back should go die in a fire.

cryptonector 4y ago
Problem is that this is totally normal for CJK users, where you really want to type in a syllabic or phonetic or similar system and get drop-down selection menus for Chinese/Kanji characters to replace your writing with. Doing that for emoji is basically the same thing for CJK users. For Latin script users, however, this is very disruptive.
- TeeMassive 4y ago
  I dabbled in Japanese; you are not comparing the same thing.
  - cryptonector 4y ago
    It's not that different.
    - TeeMassive 4y ago
      It is because it is required to produce the wanted characters and is usually implemented by the OS / browser, not at the final application level which interferes with this process.
      - cryptonector 4y ago
        The UX is still that you get a drop-down picker. What component of the system implements that seems of little importance to users unless that becomes obvious (each app doing it differently, though obviously that happens). I expect that the emoji picker will become part of the OS eventually. Heck, Windows has one that you have to call up explicitly (with <Alt>-.), iOS has an emoji "keyboard" (input mode), etc, so we're headed in that direction.

earthboundkid 4y ago

jansan 4y ago

So this was reported on October 31st, then escalated on November 3rd, and the "feature" is still in there. Seeing how severly this impacts users from France, this is slightly diappointing. Here is a discussion in the product support forum: https://support.google.com/docs/thread/186496870/how-to-deactivate-emoji-popup-on-colon-in-google-docs?hl=en https://support.google.com/docs/thread/186496870/how-to-deac...

djcannabiz 4y ago

i have caps lock and escape swapped on my computer. soooo nice for vim and just in general.

alucardo 4y ago

The same happens with Jira. It's a nightmare since if you press escape to quit the emoji mode, you abort your input and lose focus. There should be a way to configure that shortcut to whatever suites you. Anyway i don't get why web apps bother implementing their own emoji input, the operating system does it already (the windows key + ; shortcut for example). And to reply to those who simply ask people to change their habit: it's rude. Imagine the other way around: all the English typing people having to insert a space before a : for whatever reason, would that makes sense to you?

antpls 4y ago

In Zendesk, you get an Halloween pumpkin emoji instead of a thumb up. I always wondered if it was an annoying easter egg or a bug.

tonnydourado 4y ago

We have some templates for gitlab issues at work, and it always bothered me that all the colons had a space before it. Both because it triggers the same annoying emoji feature, and also because it looks weird to me. Now it all makes sense: although the templates are in English, they have been authored by a French person, so the rule just bled into English writing.