[HN Gopher] The plague of emoji insertion in French docs
___________________________________________________________________
The plague of emoji insertion in French docs
Author : bibelo
Score : 173 points
Date : 2022-11-14 16:54 UTC (6 hours ago)
(HTM) web link (bibelo.info)
(TXT) w3m dump (bibelo.info)
| gabagool wrote:
| I think the title should say "in French *Google docs." As is, it
| seems like French code documentation/papers are littered with
| emojis?
| graindcafe wrote:
| But it also occurs on Atlassian suite, Gitlab, Github and
| probably more tools...
| karmakaze wrote:
| 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.
| Am4TIfIsER0ppos wrote:
| > similar to how we don't double space after period
|
| What do you mean? Every sentence in this comment has two spaces
| after the punctuation. That one and this one. Just because
| browsers and html condense it all into one space doesn't make
| it right.
| dheavy wrote:
| >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?
| nmilo wrote:
| 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 wrote:
| In French it's a typographic rule become an orthographic
| rule. It doesn't have to be that way.
| happytoexplain wrote:
| >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.
| cryptonector wrote:
| I'd upvote for the first part of the second sentence, but
| downvote for the second part of the second sentence.
|
| Typographically speaking English language text should have a
| _wide_ space following a sentence-ending period [that isn 't
| also a paragraph-ending period]. However, because wide spaces
| are not easy to type on normal keyboard layouts, the simplest
| thing to do is to type two spaces after sentence-ending periods
| and let the word processor change those to wide spaces when
| using a proportional font. When using a fixed-width font,
| however, it should always be two spaces after a sentence-ending
| period for two reasons: to disambiguate non-sentence-ending
| periods, and to make it easier to read. Coders write a lot of
| text in fixed-width fonts, so we should write two spaces after
| sentence-ending periods in, e.g., code comment blocks.
| keybored wrote:
| The French aren't gonna change their language over an emoji
| picker. :slightly_smiling_face:
| cryptonector wrote:
| They should abandon out of date typographic rules though. As
| a French speaker, I want to.
| derac wrote:
| I have a partial solution in TamperMonkey here:
| 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.
| djcannabiz wrote:
| i have caps lock and escape swapped on my computer. soooo nice
| for vim and just in general.
| TeeMassive wrote:
| Auto insertions or anything that does things behind the users'
| back should go die in a fire.
| cryptonector wrote:
| 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.
| usrusr wrote:
| 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.
| 9dev wrote:
| 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.
| aendruk wrote:
| 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.
| keybored wrote:
| Ooh, good point. I should test if that works with a French
| layout in our app :)
| jxy wrote:
| I use Dvorak-dvp, and I hate those form fields.
| nells wrote:
| 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 wrote:
| 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 wrote:
| > 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.
| sschueller wrote:
| 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.
| rsj_hn wrote:
| 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 "u" 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.
| Tor3 wrote:
| 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.
| grishka wrote:
| 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 ITsUKEN.
| dietr1ch wrote:
| 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.
| jakub_g wrote:
| 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 wrote:
| They didn't allow NumPad?
| afandian wrote:
| 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.
| generalizations wrote:
| 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.
| bombcar wrote:
| 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.
| wizofaus wrote:
| You mean it's not X for xterminate, C for copy and V for
| velcro?
| jefftk wrote:
| _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 wrote:
| 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.
| lopis wrote:
| CTRL + Z for undo in QWERTZ keyboards is just absolutely
| impractical.
| yjftsjthsd-h wrote:
| 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 wrote:
| 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_ )
| a1369209993 wrote:
| > 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?
| bombcar wrote:
| 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 wrote:
| 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
| mrzool wrote:
| 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 a and 'a to get a. 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.
| AndriyKunitsyn wrote:
| 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.
| mrzool wrote:
| You are correct. It works for me.
| cryptonector wrote:
| It works for you _now_.
| number6 wrote:
| For me too, maybe we should containerize users
| AndriyKunitsyn wrote:
| They'll containerize themselves when they see basic
| shortcuts not working, no action necessary.
| WA wrote:
| How do you type a o u ss ?
| number6 wrote:
| AltGr+q; AltGr+p; AltGr+y; AltGr+s and Bonus: SS
| (AltGr+Schift+s)
|
| Once comited to muscle memory it's very easy
| Iv wrote:
| French on US intl here a o u ss are easy to make on such a
| setup but also the accented letters like e a o or the
| infamous c. It is even easier to type them in capital than
| it typically is on AZERTY (French keyboard) or QWERTZ
| (German one)
| Cockbrand wrote:
| [?]u creates the two dots, then you press the key for the
| vowel to put underneath.
|
| [?]s creates the ss.
|
| (Both obviously only applicable for Macs)
| cwillu wrote:
| Applicable to linux if you set the mac qwerty keyboard
| layout, which is surprisingly convenient.
| mrzool wrote:
| That would be... inconvenient. That's not how I use it. I
| type "a to get a and 'a to get a. If I want to type
| actual quotes followed by a vocal I need to "confirm" the
| quotes with space before typing the vocal.
| piva00 wrote:
| I use US_Intl keyboard for Swedish and Portuguese and can
| type all of this without the need of special char keys: a o
| a - a a a a. Just a mix of Opt+(u/a/e/i/n/`) and the next
| character I want with the diacritic.
|
| Edit: and ss is just a Opt+s. It becomes quite logical
| after you get the hang of it.
| markstos wrote:
| On Linux I use the "altgr-intl" layout variation.
|
| 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/K
| B...
| jorge-d wrote:
| On a mac keyboard you can just long-press?
| grishka wrote:
| This kind of thing usually only works in native apps that
| use NSTextView for text input, which is unfortunately not
| all of them.
| Symbiote wrote:
| That's fine if you live elsewhere and type your Danish
| colleague Laerke's name once in a while, but if you speak
| a language using non-ASCII characters it feels rather
| slow to long-press every few characters.
|
| > Danmark, officielt Kongeriget Danmark, er et land i
| Skandinavien og en suveraen stat. Det er den sydligste af
| de skandinaviske nationer, sydvest for Sverige og syd for
| Norge, og det graenser op til Tyskland mod syd. Gronland
| og Faeroerne indgar ogsa i den danske stat som rigsdele
| med selvstyre indenfor Danmarks Rige (Danmarks forhold
| til rigsdelene kaldes Rigsfaellesskabet).
|
| Eight AE+O+A in 382 characters.
| kayodelycaon wrote:
| I've never had that work reliably for me, across three
| completely different Mac installs. :/
| bombcar wrote:
| It works in "most places" but not in others (like (some)
| terminals, for example). defaults write
| -g ApplePressAndHoldEnabled -bool true
|
| Might help if it got turned off.
| [deleted]
| rpadovani wrote:
| Personally, I don't. I live in Muenchen, not Munchen. When
| strictly needed, CTRL+C/CTRL+V from a Google search makes
| the trick.
|
| When writing email/docs, autocorrector for the win.
|
| Same thing in Italian: `e instead of e. Although, the
| German replacement is cleaner, I'd say.
| keybored wrote:
| I like that. Makes me wish I could just input all my text
| in Emacs which would make mapping such things to the
| "proper" sequence of strings very simple.
| kace91 wrote:
| > I live in Muenchen, not Munchen
|
| As someone from Espanya, I welcome you to the club.
| jobigoud wrote:
| Interestingly that's the Catalan spelling.
| Asraelite wrote:
| You might want to consider using a keyboard layout that
| supports diacritics. I use UK Extended Winkeys for
| example, where I can do AltGr+[ followed by a letter to
| get it with a diaeresis, allowing me to type aou. It
| supports almost every European language character.
| Freak_NL wrote:
| > I live in Muenchen, not Munchen.
|
| That's... quite certainly not an opinion shared with all
| of your fellow inhabitants.
| rpadovani wrote:
| You are right, but this is the internet, and the official
| website for the city is https://www.muenchen.de/, so
| -\\_(tsu)_/-
| 998244353 wrote:
| Not GP but I use a similar setup. I have an "extended" US
| keyboard layout where AltGr+(location of character on
| native keyboard layout) types the character. For example,
| AltGr+[ is "u". I find this more convenient than the
| compose-like approaches suggested elsewhere in this thread.
|
| 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.
| tapland wrote:
| I swapped to us_intl as well full time a few years back
| (Swedish)
|
| right alt + q = a
|
| right alt + w = a
|
| right alt + s = ss
|
| right alt + y = u
|
| 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
| myself248 wrote:
| Personally I use a compose-key on Linux and Wincompose on
| Windows, with SyncThing to keep my .XCompose file
| synchronized between machines when I add a custom sequence.
|
| I mapped my Caps-Lock key as Compose, so I hit compose-a-"
| to get a, and so on through the set. I've made customs for
| O and u since I use those a lot and couldn't remember their
| default sequences. It's handy having (r) and (tm) on tap as
| well, and I get typographical niceties like -- and ... vs -
| and ...
| Freak_NL wrote:
| There's loads of ways. Dead keys is one, the compose key is
| another suitable one for multilingual folk. I can write a o
| u ss pretty much automatically with the compose key on a US
| layout, as well as any e e e u I might need in Dutch.
|
| In the Netherlands letters with diacritics don't even have
| their own key (Dutch computers tend to use US plus EUR).
| kayodelycaon wrote:
| Not OP, but I have a Mac and use the "ABC - Extended"
| keyboard, which has a full set of diacritics. You type them
| by using the option ([?]) key and a letter to set the
| diacritics and then type the letter. [?]u
| e = e [?]w e = e
|
| For example, the key sequence required to type Kayode is:
| |k a y o d [?]e e
|
| etc.
| phh wrote:
| Using xkb map us(intl-unicode) it's a then alt gr + shift +
| " (I'm not totally sure if that's the correct, and ss is
| alt-gr + s.
| [deleted]
| keybored wrote:
| I for some reason have a very low tolerance for dead keys.
| Two keypresses for one common letter becomes too much.
|
| Thankfully I only need to write in two languages. With almost
| the same script.
| grishka wrote:
| 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.
| c7b wrote:
| For various reasons, I've been switching both in hardware and
| software between two different QWERTY (US and UK) and two
| non-English keyboard layouts for years (usually, I'll have
| multiple keyboard layouts configured, but I'll generally go
| with the one that is actually printed on the keys unless I
| really need a different one).
|
| 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.
| cryptonector wrote:
| Yes, this. Though I prefer the X11 compose sequence business
| where you type <Compose>'a to get a and so on. X11 compose
| sequences are a lot more intuitive than the Windows U.S.
| international keyboard because there's no ambiguities, so,
| for example, a cedille is just <Compose>,c whereas in the
| Windows U.S. international keyboard layout it's 'c -- X11 for
| the win here, as the latter is super a) counter-intuitive and
| b) conflicts with c (U+0107).
|
| Also, if you program or use a shell, then the Windows U.S.
| international keyboard layout is just unspeakably unbearable.
| GuB-42 wrote:
| It is fine as long as you don't have to user other people
| computers.
|
| 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.
| keybored wrote:
| BYOK ;)
| dfxm12 wrote:
| Do you pick the "a for an umlaut? It seems like :a would be
| be typed less commonly than "a, so less need to confirm the
| punctuation.
| nier wrote:
| That's quite memorable. On the Mac I have to press option-u
| and then a, u, or o to get an a, u, or o. Optionally holding
| the shift key to get an uppercase vowel with the diacritic.
|
| option-` is for grave (e) option-i is for circumflex (e)
| option-n is for ene (n) option-c is for cedille (c)
|
| When you called QWERTZ an abomination I simply had to upvote
| your comment.
| bombcar wrote:
| I used to be pretty good at those but now I just use the
| feature that works (almost) everywhere in Mac OS and iPhone
| - press and hold the character to get a little pop-up of
| options: moose
|
| It's slow if you have to type in another language, but in
| English it's fast "enough" for words like resume.
| juujian wrote:
| Yup, did the same. And the layout I happen to work with also
| has a third layer (menu button) that includes aouss--that was
| a glorious discovery.
| senand wrote:
| Same here
| WA wrote:
| Every small indie game ever: action buttons are x and z.
|
| Guess what, y and z are swapped on a German keyboard.
| wazoox wrote:
| And W and Z, and Q and A on French keyboard. WASD is totally
| unusable, and unfortunately quite common in web apps for
| instance.
| amadeuspagel wrote:
| 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 wrote:
| 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.
| poulpy123 wrote:
| I would say it's more a problem of the underlying systeme
| (game engine or os) that should manage the compatibility
| between keyboard layout
| amadeuspagel wrote:
| 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/KeyboardEve...
| 9dev wrote:
| 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.
| dcminter wrote:
| 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/po...
| [deleted]
| Aardwolf wrote:
| 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.
| klodolph wrote:
| Yes, at some point I reconfigured autocomplete in to only
| complete when you press <tab>. I almost never press <tab>
| otherwise when I'm typing something.
| nyanpasu64 wrote:
| Interestingly, when using Kate as a Markdown editor I'm
| interrupted by the word-based completion panel popping up,
| grabbing input, and incorrectly completing words when I press
| Enter. I wish it either didn't auto-popup or didn't grab input
| in Markdown mode.
| gkoberger wrote:
| I've remapped emojis to `::` and it's been great. Barely more
| work than `:`, and don't have to deal with a clunky popup when
| I don't intend it.
| brookst wrote:
| 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 wrote:
| 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 wrote:
| 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.
| jansan wrote:
| 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-deac...
| earthboundkid wrote:
| 8)
| poulpy123 wrote:
| It was also the case on gitlab/GitHub at one point
| jansan wrote:
| Seems like the person who came up with the idea got fired and
| then hired by Google ;)
| dvh wrote:
| Same thing happen in pascal in lot of forums, in:
|
| var x:Pointer;
|
| The :P changes to tongue out emoji
| Kenji wrote:
| lerela wrote:
| It's the same with Gitlab issues and comments and it's a small
| but very real pain.
| Majestic121 wrote:
| Same for Github as well. Super annoying when you're in the
| middle of an issue
| enw wrote:
| UX testing should be done in a stressful and chaotic
| environment. Good UX becomes invisible, bad UX becomes
| abundantly obvious.
| alucardo wrote:
| 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?
| ClassyJacket wrote:
| 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.
| yjftsjthsd-h wrote:
| > 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)
| cryptonector wrote:
| In Skype you have to write {code}...{code}. Or prefix your
| entire message with @@ (but it used to be you could prefix !!
| -- why oh why did they change it?!).
|
| I so so wish we could standardize on GitHub markdown for all
| these things!
| kaladin-jasnah wrote:
| My way of getting around the emoji conversions from ':)' to a
| smiley face is typing it in reverse: '(:' or '):'.
| homonculus1 wrote:
| But I'm not left-handed!
| [deleted]
| DonHopkins wrote:
| Plus then you can stick out your tongue like this: c(: c):
| layer8 wrote:
| I don't remember which software, but I've seen those being
| converted as well.
| mynameisvlad wrote:
| IIRC, Teams supports Markdown-style code, either `single line`
| or
|
| ```
|
| multi
|
| line
|
| ```
| usrusr wrote:
| Truly a joy on German keyboards where ` is a dead key that
| makes the system wait for an e, or an a to receive that
| accent and certain OS don't come with a nodeadkeys
| alternative keyboard map. I often find myself with the ` in
| the copy/paste buffer when worrying code-heavy markdown
| because pasting is so much easier...
| kps wrote:
| Can't you just type [deadkey]+Space to get the 'undead'
| version? That works on Linux and MacOS and ChromeOS.
| usrusr wrote:
| Sure, but it's super annoying when you write something in
| markdown knowing that being lazy with the
| proportional/monospace mix will noticeably harm
| understandability. Particularly when you suspect that
| readers will be close to failing to understand, doubly so
| when you suspect that this reader might be a future self.
| Is it worth the time writing? Only if I get the monospace
| right. Dead keys can make that writing situation a
| weirdly subtle kind of hell.
|
| So annoying in fact that I've just spent the last two
| hours with Microsoft Keyboard Layout Creator (yeah, I'm
| still a Windows person) shifting the dead key version to
| hide behind alt-gr.
|
| Then I used it to mitigate some oddities on the dynabook
| keyboard (pipe and smaller/greater than weirdly moved to
| where the windows connect menu button usually resides)
| and continued duplicating some of the usual alt-gr
| suspects at locations inspired by their US KB position.
| Right now I'm an inappropriately happy person, let's see
| how I'll think about it in the future (getting too used
| to something non-standard cab be a terrible cost).
| keybored wrote:
| Probably, but having to type six keys just to open a code
| block is probably painful.
| usrusr wrote:
| Six keys, with a distracting lack of visual feedback on
| half of them...
| jheriko wrote:
| use the code blocks?
|
| even messenger supports the backticks and triple backticks now
| keybored wrote:
| > Regardless, if I want an emoji, I will type the emoji. If I
| typed ':)' I want ':)' not some stupid yellow face.
|
| But are you sure that you didn't really want
| `:slightly_smiling_face:`? (Auto-complete to passive-
| aggressiveness)
| layer8 wrote:
| Totally agree. In some software, a strategically placed
| backslash helps.
| Aissen wrote:
| Typographic nerd: technically, you should you use a non-breaking
| space (espace insecable) 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 BEPO.
|
| Historical nerd: traditionally wordprocessors have auto-inserted
| non-breaking spaces before colons, why should I care now ?
| klodolph wrote:
| 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 wrote:
| 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).
| cryptonector wrote:
| This is all a big pain in multi-lingual documents. What, am I
| supposed to switch locales every time I switch languages? No
| no, that's absolutely not OK.
| hadrien01 wrote:
| 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 wrote:
| Thanks for repeating the last sentence of my post in your own
| words :-)
| rodelrod wrote:
| A _narrow_ non-breaking space, please.
| Aissen wrote:
| Of course, sorry.
| cryptonector wrote:
| > Historical nerd: traditionally wordprocessors have auto-
| inserted non-breaking spaces before colons, why should I care
| now ?
|
| Because I don't want to switch locales in order to write short
| bits of text in another language. I don't even want to have to
| switch keyboard layouts -- just use compose sequences for
| diacritical marks and so on. And I don't use a French locale,
| but I do write French text sometimes.
|
| I would imagine that in Europe this is a big deal. So many
| Europeans are multi-lingual... But you don't expect a Spaniard
| to switch to a French locale to write in French and vice-versa
| -- that's too disruptive.
| [deleted]
| rodelrod wrote:
| 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 Academie Francaise 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
| cryptonector wrote:
| If you fail to put a space before a colon when writing in
| French, what happens next? Do people point and laugh? You get
| disciplined? Or would French speakers accept this as a better
| way to use the colon character?
|
| It looks like this rule is based on old typographic
| considerations. Much like the Spanish Royal Academy's rule that
| capitalized letters carry no accents (unlike the opposite
| French rule that capitalized letters _do_ carry accents!),
| which stems from typewriters not having accented letters, so
| one would type a vowel, backspace, then an apostrophe to make
| an accented vowel, but for capitals there 's not enough space
| so you couldn't and wouldn't overstrike them.
|
| Users and language academies should distinguish typographic
| from non-typographic language rules, and typographic rules
| should be context-specific (well technology-specific, since
| technology is the context).
| shakow wrote:
| I don't know, what would happen in English if you didn't
| capitalize the days of the week? Do people point and laugh?
| You get disciplined? Or would English speakers accept this as
| a better way to write the days of the week?
|
| No human language on Earth is in a position where it can
| laughs at others for their idiomatisms.
| wewtyflakes wrote:
| I do not think that was their point (to laugh at other
| languages), but rather, that there may be contemporary
| situations in which warrant rethinking the idioms of a
| language. As an aside, I do not think many people who speak
| english would even notice a lack of capitalization for the
| days of the week.
| cryptonector wrote:
| I've had colleagues who refuse to use capitals in most
| cases. And yet their writing is completely
| comprehensible.
| cryptonector wrote:
| In English most people wouldn't care. You're going to get
| in more trouble in French schools for this than in U.S.
| schools (I don't know about UK schools, or elsewhere in the
| Anglosphere). My impression is that European culture is a
| lot more sensitive to these things than U.S. culture.
| keybored wrote:
| > Especially simple since all double punctuations (:?!; those
| that require an nbsp before them) are also accessed with SHIFT.
|
| I just tested with `setxkmap fr`. These are not shifted:
| :!;
|
| Only this requires Shift: ?
|
| Also French layouts use an inverted number row (although none
| of those are accessed through that row).
| TheRealPomax wrote:
| 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.
| dieulot wrote:
| This? https://en.wikipedia.org/wiki/Code_page_1010 There's no
| space for it nor for many other more useful characters (like
| a).
| bombcar wrote:
| Codepages are from back in the era of little memory available
| and monospaced fonts.
|
| And another "US English" centered thing; spacing does not
| _really matter_ in English, but can have functional
| differences in other languages and scripts.
|
| https://www.youtube.com/watch?v=2yWWFLI5kFU is a fun look at
| one of the problems with Unicode in general.
| pcdavid wrote:
| 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 wrote:
| 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.
| rodelrod wrote:
| This is mostly correct, but I don't see how it contradicts my
| statement.
|
| Did the 646 standard account for variable-width characters at
| all?
| TheRealPomax wrote:
| Not so much contradict as wondering about the claim that it
| should be a specific Unicode codepoint when Unicode wasn't
| around when we started "computering" text (and the Academie
| Francaise can't have possibly formally declared things in
| terms of Unicode =)
|
| What are the actual official rules in this case (and are
| there links to those? Because that'd be fascinating
| information to read through)?
| sdeframond wrote:
| Or, word processors could understand that the pattern
|
| "some-chars" + <whitespace> + ":"
|
| must be treated as a single word in French.
|
| (I guess it's more complicated than I imagine it is, alright)
| cryptonector wrote:
| It's more complicated than you imagine it is. Basically you
| need to know both: whether the current locale is a French
| locale, and also whether original text was written in a
| French locale.
|
| The former is easy enough, but also very annoying to
| multilingual people since one might run in a Spanish locale
| but occasionally write in French. So that's not a solution.
|
| The latter is... hard to do, because while Unicode has
| language tags that you can embed in documents, those are
| deprecated and they were never well supported, and so there's
| no way to mark-up text as being in one language or another,
| and a document-wide setting wouldn't be enough nor
| sufficiently generic and standard and portable.
|
| The best solution here is to relax the French typographic
| rule (since it isn't needed anymore). But that would take
| time to filter through to French speakers (writers, and
| readers) so that they learn to not put that pesky space
| before punctuation, but also so that they don't complain when
| it's missing.
|
| Or... you know, this business of emoji pickers could be
| something you could turn off. Nahhh, that would never fly!
| (/s)
| gnubison wrote:
| > Unicode has language tags that you can embed in
| documents, those are deprecated and they were never well
| supported,
|
| Huh? MDN doesn't mention this ... why are they deprecated?
| cryptonector wrote:
| Yes, [sadly] deprecated by the Unicode Consortium in
| Unicode 5.2, and by the IETF in RFC 6082. Nor have they
| be undeprecated since them (see https://www.unicode.org/v
| ersions/Unicode15.0.0/ch05.pdf#G115...).
|
| IMO we should have tried harder to make Unicode language
| tags useful _and used._ But it didn 't happen, so they're
| a thing of the past. Of course, they're still _there,_
| and one _could_ attempt to resurrect them, but most
| likely one would fail.
|
| Choice quotes below:
|
| https://www.rfc-editor.org/rfc/rfc6082 >
| RFC 2482, "Language Tagging in Unicode Plain >
| Text" [RFC2482], describes a mechanism > for using
| special Unicode language tag > characters to
| identify languages when needed. > It is an idea
| whose time never quite came. > It has been
| superseded by whole-transaction > language
| identification such as the MIME > Content-language
| header [RFC3282] and more > general markup
| mechanisms such as those > provided by XML. The
| Unicode Consortium > has deprecated the language
| tag character > facility and strongly recommends
| against > its use. RFC 2482 has been moved to
| > Historic status to reduce the possibility > that
| Internet implementers would consider > that tagging
| system an appropriate mechanism > for identifying
| languages. > > A discussion of the status of
| the language tag > characters and their
| applicability appears > in Section 16.9 of The
| Unicode Standard > [Unicode52].
|
| https://www.unicode.org/versions/Unicode5.2.0/ch16.pdf
| (section 9 of that chapter, 16) > 16.9
| Deprecated Tag Characters 519 The Unicode >
| Standard, Version 5.2 Copyright (c) 1991-2009 >
| Unicode, Inc. for detailed recommendations > on
| the use of U+FFFD as replacement for > ill-formed
| sequences. See also Section 5.3, > Unknown and
| Missing Characters for related > topics. 16.9
| Deprecated Tag Characters > Deprecated Tag
| Characters: U+E0000-U+E007F > The characters in
| this block provide a > mechanism for language
| tagging in Unicode > plain text. These characters
| are deprecated, > and should not be used--
| particularly with any > protocols that provide
| alternate means of > language tagging. The Unicode
| Standard recom- > mends the use of higher-level
| protocols, such as > HTML or XML, which provide for
| language tagging > via markup. See Unicode
| Technical Report #20, > "Unicode in XML and Other
| Markup Languages." > The requirement for language
| information embedded > in plain text data is often
| overstated, and > markup or other rich text
| mechanisms constitute > best current practice. See
| Section 5.10, > Language Information in Plain Text
| for further > discussion.
|
| (Reformatting is mine.)
| makapuf wrote:
| And thus impossible to use the emoji inserting feature, and
| other bugs (silently replacing whitespace with different but
| looking the same whitespace will make for fun issues)
| c80e74f077 wrote:
| Well, double colon :: is just as convenient, make more
| sense and not a problem in either French or English. Even
| in English, you might want to stick an emoji to the
| previous word. Like Hell::devil:: (my nephew would like
| that though).
| troglodynellc wrote:
| Double colon would make talking about perl even worse (::
| is namespace separator) -- it's already bad enough that
| any namespace starting with D becomes an emoticon in
| pretty much all online editors.
|
| This stuff should just stop. Operating Systems / Browser
| vendors should instead standardize on a hotkey to bring
| up an emoji selector that steals focus to filter via
| typing and inserts on enter key.
| keybored wrote:
| Code should be quoted upfront.
|
| Finding some sequence that also isn't a valid Perl
| substring is impossible, in any case.
| makapuf wrote:
| Indeed. Replace scroll lock with emoji lock
| sdeframond wrote:
| MS Word actually replaces normal whitespaces with non
| breaking spaces in some cases. Kinda works.
| jobigoud wrote:
| A modern solution is simply to have non-breaking space easily
| accessible in your keyboard layout for when you need it. In the
| BEPO layout this is at SHIFT + space. Especially simple since
| all double punctuations (:?!; those that require an nbsp before
| them) are also accessed with SHIFT.
| Normille wrote:
| >A modern solution is simply to have non-breaking space
| easily accessible in your keyboard layout
|
| An even better solution would be --for grown up people who
| have progressed beyond cave-painting and want to communicate
| using, you know, actual words-- to be able to disable emojis
| completely.
|
| Fucking moronic shite that they are. I've seen people on
| Twatter and FB have entire conversations in bloody emojis.
| Talk about reverse evolution! Why don't we just go back to
| grunting and gesturing and have done with it?
| benj111 wrote:
| I'm surprising myself by saying this, but emoji are pretty
| useful in certain contexts.
|
| Certainly more useful than the requirement to put a space
| before a colon, non breaking or not.
| cryptonector wrote:
| A modern solution is to abandon old, no-longer-relevant
| typographic language rules, or to make typographic language
| rules context-specific.
|
| But I agree that we need to make several alternative space
| characters easy to type: - non-breaking space
| (for this French rule) - wide space (for disambiguating
| sentence ending periods from non-sentence-ending
| periods) - zero-width non-breaking space (for
| preventing word-splitting?)
| Kwpolska wrote:
| What makes the French rules old, no-longer-relevant,
| invalid? Why should we change language to appease lazy
| software developers?
| cryptonector wrote:
| Not "rules", just _this_ rule. It has to do with
| typographic considerations that apply to old typesetting
| technologies that are no longer in use.
___________________________________________________________________
(page generated 2022-11-14 23:02 UTC)