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?
Space is required in all languages for that to work.
Hm why? Plenty of people keep inserting smiles with no space. Requiring a space is not intuitive.
Is it fixable by changing a regex?
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.
Because otherwise, links like
https://www.discourse.org
would become
https:confused:/www.discourse.orgMay we allow the no-space syntax for named emojis only?
So, only :confused: will work with no spaces, but not ://
No, @meglio, what @zogstrip mean is that:
:/ as well as :confused: both map to 
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.
That’s exactly what I meant:
And because lots of emojis are inserted from the Emoji Dialog, there will be fully spelled versions used.
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.
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.
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.
I think we can make two changes to make this a little bit easier to use:
Hello🙂world should work the same as Hello 🙂 world and use the correct Emoji image from Discourse 
.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?
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.
The trailing space is not needed. What’s critical is the leading space.
Hey @venarius,
is this something you’d like to improve given that you spent a lot of time fixing various Emoji issues lately?
I will look into it Thanks for tagging!
Opened a PR
https://github.com/discourse/discourse/pull/7429
Regarding
As far as I recognized it, this got added with the enable_inline_emoji_translations site setting. I noticed that emojiEscape and emojiUnescape didn’t support that site setting so I added it
I picked up @venarius’ work and made some improvements. The most important changes are:
enable_inline_emoji_translation setting in topic titles