Add documentation for stardard emojis

[Mehgugs]

:wave: Hello! Currently the list of the standard emoji and their names is not officially documented by discord. While I am aware that this isn't a crucial issue, it's also pretty easy to address and would provide some much needed QOL when dealing with emoji within discord content. People are also retreiving lists from the client which is breaching the ToS and that shouldn't be necessary.

[msciotti]

Do you mean the list of standard Unicode emojis? Like https://unicode.org/emoji/charts/full-emoji-list.html ?

[z64]

@msciotti they want a list of the shortcodes the client uses (it doesn't follow the CLDR short name)

[Mehgugs]

I am referring to the shortcut name used in colon forms :like_these: which do not follow any standard I can find, and if such a standard exists there is no information about which one it is within discord's documentation.

[Dramex]

try https://www.webfx.com/tools/emoji-cheat-sheet/

[Mehgugs]

while this appears to be accurate after a glance, my issue is that discord haven't documented the list they use anywhere. A simple link to this site and/or their GitHub in the emoji section of the docs would work

[z64]

@Mehgugs It would help if you described your use case; I'm not sure exactly what it might be because

• Shortcodes are never exposed or used in the API; they are encoded to unicode characters inside the message content field before bots ever see them
• For sending emojis with your bot, any popular unicode reference site like https://emojipedia.org has a searchable index of emoji where you can simply copy the unicode characters or codepoints and put them in your editor for your bots to send them
• Languages may have emoji packages that provide their own shortcode mapping (example; Ruby twemoji) if you want to skip the manual process of the previous step

(To be clear, Discord uses twemoji https://emojipedia.org/twitter/)

[Lachee]

Having this documented would be very useful. I know several people are reverse engineering the client trying to get the emotes and their :names:

Example of use? Well I am not sure how DSharpPlus implements it, but you can either use unicode characters or the names to get the emoji. Since I am running on Win7 (and not every computer has latest emojis anyways), I cannot always see the emoji in my code. In addition, what if I am in a environment that cannot accept unicode for its source code (unlikely but theoretically possible). Its much easier to type in the name of the emoji in discord to see what it will be then use that, versus trying to find the unicode equivalent. Unlike Tom Scott, I dont have a emoji keyboard.

I did notice while browsing D#+ implementation, it has a lookup for discord naming to unicode values; Maybe a simple table like that would be useful?

[z64]

@Lachee you can write unicode codepoint escapes in "any" language, and use a structure like a map:

Emojis = {
  ice_cream: "\u{1f368}"
  # ..
}

"I like #{Emojis[:ice_cream]}"

[Mehgugs]

There are cases when two messages which render the same content are not equal when sent over gateway and I'd like to resolve that (bots using short codes will be left in un-resolved but clients render them resolved).

It's also so I can provide short code mappings consistent with discord's for ease of use since twemoji has no short codes and uses codepoints / utf sequences only.

Perhaps my first use case touches on a separate issue, about the client representing content differently to the content the API transmits. Either way I think a link with a JSON file or a link to the shortcode mapping is useful so we can attempt to resolve that issue ourselves.

Also it's not explicitly explained when and where short codes are resolved by the client and that's useful for users as well as developers.

After some digging around in discord's licences I found that they use emoji-list to get a list of emoji, I'd therefore assume that emoji-keywords using the same list is accurate but does not contain any aliases as far as I can tell. Since discord has not included any other licences they must be rolling their own list or have not documented using the one above in the licence list.

I just want a concrete "yes this is the keywords we use " somewhere that's not inside the client.

[night]

Our API only supports emoji in unicode characters as syntax. Colon based formatting is a client construct (clients convert colon based formatting into unicode characters) that our API doesn't understand or deal with, so it has no place in our API docs. If libraries interpret colon based emoji syntax then they should provide their own documentation using whatever emoji name list they support.

[Mehgugs]

Okay, thank you for clarifying this. While I still believe documenting how a client will render the content one sends is useful, it is not part of the API and I respect your stance on that. It would be great if you could disclose the list you use here, if there is one.

[Mehgugs]

Our API only supports emoji in unicode characters as syntax.

This is no longer true due to guild sticker tags

[advaith1]

technically you can set tags to any string, the client will make you set an emoji to save changes though

[bijij]

Our API only supports emoji in unicode characters as syntax.

This is no longer true due to guild sticker tags

Role icon unicode emoji also currently require and return the name.

Colon based formatting is a client construct (clients convert colon based formatting into unicode characters) that our API doesn't understand or deal with, so it has no place in our API docs.

Given the above I believe there might be some sense in reopening this?

[Mehgugs]

There was a discussion opened about this, it was answered at the time because sticker tags are actually arbitrary strings from an api perspective. This new field on roles seems to be validated, which means the acceptable names need documentation.