Emoji short names are inconsistent with Unicode and other chat platforms

[wezm]

Description

The emoji short names used in Riot are inconsistent with their unicode names and other chat platforms.

Steps to reproduce

1. Choose an emoji reaction from the picker based on its visual appearance, use in other platforms, or long name.
2. Hover over the reaction.

How this differs from what I expect:

If I choose an emoji reaction like 😅 which the long name describes as, "Grinning Face With Sweat". and hover over the reaction on the post it says, "Wes reacted with :embarassed:". I think this misrepresents the emoji and what I was trying to express — I was not embarrassed.

This name differs from other platforms and is not limited to just this emoji:

Emoji	Riot	Mattermost	Slack	GitHub	Unicode
😅	:embarassed:	:sweat_smile:	:sweat_smile:	:sweat_smile:	SMILING FACE WITH OPEN MOUTH AND COLD SWEAT
🤓	:nerd:	:nerd_face:	:nerd_face:	:nerd_face:	NERD FACE
🤣	:entertained:	:rofl:	:rolling_on_the_floor_laughing:	:rofl:	ROLLING ON THE FLOOR LAUGHING
🤔	:curious:	:thinking:	:thinking_face:	:thinking:	THINKING FACE
😆	:amused:	:laughing:	:laughing:	:laughing:	SMILING FACE WITH OPEN MOUTH AND TIGHTLY-CLOSED EYES
😉	:coy:	:wink:	:wink:	:wink:	WINKING FACE
😜	:mischievous:	:stuck_out_tongue_winking_eye:	:stuck_out_tongue_winking_eye:	:stuck_out_tongue_winking_eye:	FACE WITH STUCK-OUT TONGUE AND WINKING EYE
😛	:playful:	:stuck_out_tongue:	:stuck_out_tongue:	:stuck_out_tongue:	FACE WITH STUCK-OUT TONGUE

Note: There's a lot more than this, these are just a sample.

In each case I think the Riot one misrepresents what the person was trying to express by renaming it away from the emoji name. Chat is all about communication and I feel that these editorialised short names can communicate emotions that the original author did not intend. Sticking with the more literal description like other platforms leaves more room for interpretation and versatility of the emoji.

Version information

• Platform: web (in-browser)

For the web app:

• Browser: Firefox 76.0.1
• OS: Arch Linux
• URL: private (modular.im) riot-web version: v1.6.2

[t3chguy]

These come from the https://github.com/milesj/emojibase source

[t3chguy]

Sticking with the more literal description like other platforms leaves more room for interpretation and versatility of the emoji.

Maintaining a list as the set of emoijs grow over time especially in multiple languages does not sound feasible for the Riot team, you should perhaps open the issue upstream.

[wezm]

Thanks for the pointer. I took a look at the linked repo. It seems they are actively against doing what I proposed. The shortcode documentation says:

Must use emotions when describing smileys. For example, "happy" over "smiling face with open mouth & smiling eyes".

As a result of this I'm hesitant to raise an issue with them. What do you think?

Edit: There is this open issue by the author suggesting that different shortcode sets might be desired.

[nailyk-fr]

For some time (few month ago) the 'new' shortcode was displayed but the 'old' shortcode was active, allowing to use both. Is there any way to come back to both shortcode or this should also be asked in the https://github.com/milesj/emojibase repo ?

Thanks in advance 🙂

[t3chguy]

Seems like emojibase now supports multiple "dialects" of shortcodes we can pick from
https://emojibase.dev/emojis/?shortcodePresets=emojibase-legacy
so it falls down to a Product decision if we want to break muscle memory of existing users and which to choose

[ShadowJonathan]

You wouldn't have to break muscle memory, as the old emoji codes (:curious:) can still "map" onto newer codes, we'd just have to put the legacy set on the "older" codes, and have another set of emoji shortcodes be the "front" of those codes.

For instance, with the legacy emojibase set, :curious: and :thinking: both point to the same emoji, but :curious: has a higher precedence, so it comes first (and shows as the canonical name), we switch the "main" set to github (i hope) and have the legacy emojibase set have a lower precedence, so that way 🤔 still shows up when you do :curious:, it wont be a hard break for muscle memory.

We could also add support for slack and "joypixels" (discord) emojis this way, as people coming from slack would have that muscle memory, and emojibase can just recognise those "lower priority" shortcodes.

[t3chguy]

That would mean doubling (or more) the size of the shortcodes JSON we're including which should be avoided as our bundle size is already too large.

[ShadowJonathan]

(I'd be curious how much it would add to the JSON, I would wanna see that first)

[t3chguy]

See its size in proportion to other things; its almost as big as the subset of tree-shaken lodash we import. It is larger than CommonMark.

[t3chguy]

And I guess the other issue this points out is, we just use the compact JSON that they provide, so we would have to add a new build stage to compile our own "compact" JSON built from multiple JSON files from emojibase-data mixing in the right shortcodes mapping JSON. We previously moved away from doing this when compact came into existence.

[ShadowJonathan]

Hmm, that is indeed a conundrum... 🤔

[ShadowJonathan]

Some extra interesting links from #15982;

https://github.com/milesj/emojibase/blob/master/packages/data/CHANGELOG.md
https://github.com/milesj/emojibase/blob/master/packages/regex/CHANGELOG.md

[ara4n]

we decided in #element-dev to swap the default dialect for the slack-style dialect (rather than import both and waste space with 500K of JSON).

[ara4n]

(PRs very welcome to do so!)

[ShadowJonathan]

emojibase-data 6.0.0 is a breaking change that altered the way they lay out their data, but interestingly enough, it's easier now to see the actual size for the shortcodes;

(link)

Legacy + github would only be ~180kb to support, adding that with the new compact.json size, that'd come to ~635kb, which is only 100kb more than we currently set aside for emojibase.

Removing the legacy set will net a overall 40kb win, but that is getting close to bikeshedding, the point is; it is easy to support both legacy + github with minimal size increases. I haven't looked closely at the way emojis are referenced and passed around in the app, but I expect some refactoring there.