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)
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.
> 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].
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)
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).
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.
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)