and then there are all kind of things to handle like aliases
3 likes
Ah-ha!
I’d missed that repo, thanks @j.jaffeux we’re now back in business 
Apple, with a fallback to unicode 
5 likes
This seems strange way of doing things. Rendering emoji as images in the flow of text feels against the grain. The vast majority of users will be very used to their device/OS native emoji so looking at some less-good or different version will feel strange.
The vast majority of websites use user-native emoji, how is this ever really a problem? shouldn’t the default be the user’s native emoji, with the option to do custom emoji sets as a plugin or user customizable option?
Current approach feels and looks inelegant
5 likes
test 
test
must be something in your theme?
3 likes
- twitter uses the same strategy
- slack uses the same strategy
- discord uses the same strategy
Maybe there’s a reason?
7 likes
No, sorry, I’d missed a screen shot to show it was an upload by the looks of things.
If I edit the post this is what I see:
Strange eh 
1 like
Question: For the Unicode set, it is the ones in the “Sample” column right? If so, these are the same exact ones as Noto, are they not? I’m just a bit confused as to why both are offered if they are the same set.
1 like
Ja, je hebt gelijk, we moeten ze laten convergeren, geen grote schade echter.
1 like
I just stumbled over this, as our forum default (also when resetting the option back to its default, is “Twitter” while it says “deprecated to Twemoji”.
It makes sense that “Twitter” emojis are deprecated, since the name “Twitter” is deprecated (and the new platform turned into an abused shit hole mostly) 
. But also it probably makes sense to not change things without admin consent.
About this default: is it the default the own Discourse instance was originally shipped with, or are these global to all instances, and hence can change? Do new instances have Twemoji emojis enabled by default?
1 like
If this is still the case, it might change in the future, see:
1 like
You mean if it is not yet the case?
My point is:
- It looks weird that “Twitter” emojis are explicitly stated deprecated in the list, while they are still the default, i.e. the “reset” button in our case still applies these deprecated Twitter emojis.
- So I was wondering whether the default has really not changed in upstream code, along with renaming “Twitter” to “Twitter (deprecated to Twemoji)”, or default settings changes do not apply retrospectively to existing Discourse instances. In this particular case I see an argument to not change the default on an existing instance, so admins can always revert to what their forum was shipped with, and settings they never touched do not change without them explicitly changing them.
- Other wording: Do the “reset” buttons apply the Discourse defaults (which may change), or do they apply whichever value the Discourse instance was originally shipped with?
Well, I guess the default has really not been changed yet, the other theory seems quite complicated behavior .
1 like
Twitter is still the default, even on new installs
I think “reset” always resets to the default of the current version. For example, Normalize emails was enabled by default about a year ago DEV: Enable the normalize_emails site setting by default by Drenmi · Pull Request #29952 · discourse/discourse · GitHub, so reset changes the setting to enabled now.
2 likes
Has anyone created a plugin to bring back the Apple emojis? I’m really missing them 
Or is it possible to make our own custom emojis show up first and override basic text like :-)?
1 like
I’ve not made a plugin but I forwarded the “twemoji” folder to a different folder where I uploaded all the Apple icons, so those are what appear on the site.
Quite simple, although you have to do some duplication and renaming to make sure there aren’t any broken ones, and of course it’s down to you to get the images of new ones released.
1 like
Is there a simple way for an admin to add some emoji aliases?
This question, because we have upgraded to 2.5 and with that, switched the emojis set from Apple to Noto, but now we have quite a few of these issues:
The one working one is using :netherlands: while all the others are using 2-letter country codes which used to work but, I assume, were alias that now no longer work.
Any clean way to address this as we have a large amount of posts affected by this? I’m a little wary of trying posts:remap on this, but open to suggestions.
While I’m at it, here in meta, :de: works just fine for 
, so I guess twemoji comes with that alias too — just not Noto.
Personally to fix this I just duplicate the image with lots of different names. It’s messy but it works.
1 like
I changed the emoji set on my site to Noto and :de: seems to work fine:
Is there anything special in the raw of your post? Does ‘rebuild html’ help?
Those aliases are not added per emoji set
I’ve tripled checked and :de: doesn’t do it for my installation. The only difference I can think of is that we are on 2.5.2 and you are likely testing it against tests-passed.
I had a look in discourse/discourse-emojis and there is indeed a noto/de.png symlink which seems to have been added back in March, and although 2.5 was released in June, it might have not made it?
Here’s what I have/don’t have:
# ls -l /var/www/discourse/public/images/emoji/{twemoji,fluentui,noto,unicode}/{de,flag_de,germany}.png
ls: cannot access '/var/www/discourse/public/images/emoji/fluentui/de.png': No such file or directory
ls: cannot access '/var/www/discourse/public/images/emoji/fluentui/flag_de.png': No such file or directory
ls: cannot access '/var/www/discourse/public/images/emoji/noto/de.png': No such file or directory
ls: cannot access '/var/www/discourse/public/images/emoji/noto/flag_de.png': No such file or directory
lrwxrwxrwx 1 discourse discourse 22 Oct 3 14:40 /var/www/discourse/public/images/emoji/fluentui/germany.png -> ../unicode/germany.png
lrwxrwxrwx 1 discourse discourse 22 Oct 3 14:40 /var/www/discourse/public/images/emoji/noto/germany.png -> ../unicode/germany.png
lrwxrwxrwx 1 discourse discourse 11 Oct 3 14:40 /var/www/discourse/public/images/emoji/twemoji/de.png -> germany.png
lrwxrwxrwx 1 discourse discourse 11 Oct 3 14:40 /var/www/discourse/public/images/emoji/twemoji/flag_de.png -> germany.png
-rw-r--r-- 1 discourse discourse 246 Oct 3 14:40 /var/www/discourse/public/images/emoji/twemoji/germany.png
lrwxrwxrwx 1 discourse discourse 11 Oct 3 14:40 /var/www/discourse/public/images/emoji/unicode/de.png -> germany.png
lrwxrwxrwx 1 discourse discourse 11 Oct 3 14:40 /var/www/discourse/public/images/emoji/unicode/flag_de.png -> germany.png
-rw-r--r-- 1 discourse discourse 854 Oct 3 14:40 /var/www/discourse/public/images/emoji/unicode/germany.png
The alias flag_de and de are in there, but only for some sets. It seems that both noto and fluentui don’t have it’s own germany.png and are falling back to the one in the unicode set. Perhaps because of that, the aliases aren’t (weren’t?) being created.
Unless someone sees a cleaner workaround, I might try to create the missing symlinks on the after_code hook of the build process, at least until we hop into a Discourse version that has that change included.