Live data from Hacker News

The plague of emoji insertion in French docs

bibelo.info

101–110 of 211 posts

Re: The plague of emoji insertion in French docs

#101

This space before the colon and other marks in French should actually be a narrow non-breaking space (U+202F) [0]. There's no key for it in the AZERTY layout. This has been a problem since the typewriter age. People having to get on with their jobs coped with it by using a full, breaking em-space. Unless this gets replaced automatically by the word processor, you get horrid typography and misplaced line breaks all ov…

A modern solution is simply to have non-breaking space easily accessible in your keyboard layout for when you need it. In the BÉPO layout this is at SHIFT + space. Especially simple since all double punctuations (:?!; those that require an nbsp before them) are also accessed with SHIFT.

Re: The plague of emoji insertion in French docs

#103

This space before the colon and other marks in French should actually be a narrow non-breaking space (U+202F) [0]. There's no key for it in the AZERTY layout. This has been a problem since the typewriter age. People having to get on with their jobs coped with it by using a full, breaking em-space. Unless this gets replaced automatically by the word processor, you get horrid typography and misplaced line breaks all ov…

Or, word processors could understand that the pattern "some-chars" + + ":" must be treated as a single word in French. (I guess it's more complicated than I imagine it is, alright)

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)

Re: The plague of emoji insertion in French docs

#104
post #5
post #2

There's more of this implicit US American bias in modern computing than you would think after the whole ASCII/Unicode mess - I thought they finally learnt something about computers actually being used by other people back then, but no. One of my pet peeves: Badly implemented "press CTRL + / to search". Entering an actual slash, which requires e.g. SHIFT+7 on German keyboards, won't open the search box, but pressing t…

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…

You mean it's not X for xterminate, C for copy and V for velcro?

Re: The plague of emoji insertion in French docs

#105
post #42

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…

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.

Re: The plague of emoji insertion in French docs

#106
post #98

Earlier quoted context omitted.

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 )

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 .

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

Re: The plague of emoji insertion in French docs

#107
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.

Re: The plague of emoji insertion in French docs

#108
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.

Re: The plague of emoji insertion in French docs

#109
post #7

Earlier quoted context omitted.

Every small indie game ever: action buttons are x and z. Guess what, y and z are swapped on a German keyboard.

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 awar…

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.

Re: The plague of emoji insertion in French docs

#110

Earlier quoted context omitted.

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.

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?

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 Académie Française 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)?

Post reply on HN