Emoji not recognized after cyrillic symbols


(Anton) #1

Example:

Всегда можно уделить время туристу:slight_smile:

Renders as:

Всегда можно уделить время туристу:slight_smile:

Here, there is no space between the emoji code and the Russian word preceeding it.

Compare to English:

there’s always time to spend with a visitor:slightly_frowning_face:

Looks like it’s not recognized after latin words either.

Is thins a bug or by design?


(Jeff Atwood) #2

Space is required in all languages for that to work.


(Anton) #3

Hm why? Plenty of people keep inserting smiles with no space. Requiring a space is not intuitive.

Is it fixable by changing a regex?


(Stephen Chung) #4

My suggestion is to have the emoji picker inserts spaces. Either around or just before.

I have a huge problem with this also. It is worse because many of my users are Chinese and Chinese does t use spaces.


(Régis Hanol) #5

Because otherwise, links like

https://www.discourse.org

would become

https:confused:/www.discourse.org

(Anton) #6

May we allow the no-space syntax for named emojis only?

So, only :confused: will work with no spaces, but not ://


(Stephen Chung) #7

No, @meglio, what @zogstrip mean is that:

:/ as well as :confused: both map to :confused:

Emoji’s start off as simple text-based combos like :-), :-o etc.

You have to be an old dog like myself to remember the times when we used text-based emoji’s on Unix talk.

So, there are a large number of combinations starting with a colon that may map into an emoji, but shouldn’t if it is not separated by a space (for example, the :/ above, when attached to http, should obviously mean http:// instead of an emoji). Without this space rule, the MarkDown processor has no way to tell if there should be an emoji or not.

So, my suggestion remain: automatically add a space in front (or both in front and after) the emoji, when chosen by the emoji picker.

Or, alternatively, modify the emoji processor to only recognize fully-spelt emoji names in non-space applications. For example: :/ is only recognized with a space before, but :confused: is always recognized wherever it is.


(Anton) #8

That’s exactly what I meant:

And because lots of emojis are inserted from the Emoji Dialog, there will be fully spelled versions used.


(Stephen Chung) #9

Modifying the MarkDown processor may be a bit hairy…

My suggestion of adding a space in front of an emoji chosen from the emoji picker dialog requires simply changing one single line. MarkDown is mostly not space conscious, so adding an extra space in most places will do nothing to it.


(Anton) #10

Yes, one-liner solution to add an extra-space sounds reasonable. It will also make sense to only add it if it’s not there yet.


(Anton) #11

Btw, this is still a huge issue for us. Note how the Russian message in the image below spoiled with English emoji codes.

I now have to fix it manually (and ask my mods to do so), and it takes so much time, every single day.


(Gerhard Schlager) #12

I think we can make two changes to make this a little bit easier to use:

  • Emoji selector should insert a leading and trailing whitespace when it inserts an emoji.
  • Replacing of Unicode emojis should work even when there are no surrounding whitespaces.
    So, Hello🙂world should work the same as Hello 🙂 world and be converted to Hello :slightly_smiling_face: world.

#13

I like this.
This happens a lot in my discourse site. My users forget to add a white-space before inserting emoji’s. I’m guessing its because they are not used to that - because in other platforms like whatsapp etc. its somehow taken care automatically.

@gerhard
Is it going to be a quick fix at Discourse end?
Or do you think this can be accomplished using CSS too?


(Joffrey Jaffeux) #14

We can’t do the trailing one because of diversity level modifier :woman:t4: it would break the flow of selecting :woman: and then typing t to display the menu.


(Stephen Chung) #15

The trailing space is not needed. What’s critical is the leading space.