und dann gibt es alle möglichen Dinge zu handhaben, wie Aliase
Ah-ha!
Ich hatte dieses Repository übersehen, danke @j.jaffeux, wir sind jetzt wieder im Geschäft ![]()
Apple, mit einem Fallback auf Unicode ![]()
Das scheint eine seltsame Vorgehensweise zu sein. Emojis als Bilder im Textfluss darzustellen, widerspricht dem üblichen Vorgehen. Die überwiegende Mehrheit der Benutzer wird an die nativen Emojis ihres Geräts/Betriebssystems gewöhnt sein, sodass eine weniger gute oder andere Version seltsam wirken wird.
Die überwiegende Mehrheit der Websites verwendet native Emojis der Benutzer. Wie kann das wirklich ein Problem sein? Sollte die Standardeinstellung nicht das native Emoji des Benutzers sein, mit der Option, benutzerdefinierte Emoji-Sets als Plugin oder benutzerdefinierte Option anzubieten?
Der aktuelle Ansatz fühlt sich unschön und ungelenk an.
test
test
muss etwas in deinem Theme sein?
- Twitter verfolgt die gleiche Strategie
- Slack verfolgt die gleiche Strategie
- Discord verfolgt die gleiche Strategie
Vielleicht gibt es einen Grund?
Nein, tut mir leid, ich hatte vergessen, einen Screenshot zu zeigen, der darauf hindeutet, dass es sich um einen Upload handelt.
Wenn ich den Beitrag bearbeite, sehe ich Folgendes:
Seltsam, oder? ![]()
![]()
Frage: Bei der Unicode-Zeichensatz ist es der in der Spalte „Sample“ (https://unicode.org/emoji/charts/full-emoji-list.html), richtig? Wenn ja, sind das exakt dieselben wie Noto, nicht wahr? Ich bin nur etwas verwirrt, warum beide angeboten werden, wenn es derselbe Satz ist.
![]()
Ja, Sie haben Recht, wir sollten sie konvergieren lassen, kein großer Schaden.
Ich bin gerade darüber gestolpert, da unser Forumstandard (auch wenn die Option auf ihren Standard zurückgesetzt wird) „Twitter“ ist, obwohl dort steht „veraltet zu Twemoji“.
Es ist sinnvoll, dass „Twitter“-Emojis veraltet sind, da der Name „Twitter“ veraltet ist (und die neue Plattform größtenteils zu einem missbrauchten Scheißloch wurde)
. Aber es ist wahrscheinlich auch sinnvoll, Dinge nicht ohne Zustimmung des Administrators zu ändern.
Bezüglich dieses Standards: Ist es der Standard, mit dem die eigene Discourse-Instanz ursprünglich ausgeliefert wurde, oder sind diese global für alle Instanzen und können sich daher ändern? Haben neue Instanzen standardmäßig Twemoji-Emojis aktiviert?
Wenn dies immer noch der Fall ist, könnte sich dies in Zukunft ändern, siehe:
Sie meinen, wenn es noch nicht der Fall ist?
Mein Punkt ist:
- Es wirkt seltsam, dass „Twitter“-Emojis in der Liste explizit als veraltet gekennzeichnet sind, während sie immer noch die Standardeinstellung sind, d. h. die Schaltfläche „Zurücksetzen“ wendet in unserem Fall immer noch diese veralteten Twitter-Emojis an.
- Ich habe mich also gefragt, ob die Standardeinstellung im Upstream-Code wirklich noch nicht geändert wurde, zusammen mit der Umbenennung von „Twitter“ in „Twitter (veraltet zu Twemoji)“, oder ob Standardeinstellungen nicht retrospektiv auf bestehende Discourse-Instanzen angewendet werden. In diesem speziellen Fall gibt es ein Argument dafür, die Standardeinstellung bei einer bestehenden Instanz nicht zu ändern, damit Administratoren immer zu dem zurückkehren können, womit ihr Forum ausgeliefert wurde, und Einstellungen, die sie nie geändert haben, sich nicht ohne ihre explizite Änderung ändern.
- Andere Formulierung: Wendet die Schaltfläche „Zurücksetzen“ die Discourse-Standardeinstellungen (die sich ändern können) an oder den Wert, mit dem die Discourse-Instanz ursprünglich ausgeliefert wurde?
Nun, ich schätze, die Standardeinstellung wurde wirklich noch nicht geändert, die andere Theorie scheint ein ziemlich kompliziertes Verhalten zu sein
.
Twitter ist immer noch der Standard, selbst bei Neuinstallationen
Ich denke, “Zurücksetzen” setzt immer auf den Standard der aktuellen Version zurück. Zum Beispiel war “E-Mails normalisieren” vor etwa einem Jahr standardmäßig aktiviert DEV: Enable the normalize_emails site setting by default by Drenmi · Pull Request #29952 · discourse/discourse · GitHub, sodass Zurücksetzen die Einstellung jetzt auf aktiviert ändert.
Hat jemand ein Plugin erstellt, um die Apple-Emojis zurückzubringen? Ich vermisse sie wirklich ![]()
Oder ist es möglich, unsere eigenen benutzerdefinierten Emojis zuerst anzeigen zu lassen und grundlegenden Text wie :-) zu überschreiben?
Ich habe kein Plugin erstellt, aber ich habe das „twemoji“-Set in einen anderen Ordner weitergeleitet, in dem ich alle Apple-Icons hochgeladen habe, sodass diese auf der Website angezeigt werden.
Ziemlich einfach, obwohl Sie einige Duplikate und Umbenennungen vornehmen müssen, um sicherzustellen, dass keine fehlerhaften vorhanden sind, und natürlich liegt es an Ihnen, die Bilder neuerer Versionen zu beschaffen.
Gibt es eine einfache Möglichkeit für einen Administrator, einige Emoji-Aliase hinzuzufügen?
Diese Frage kommt daher, dass wir auf 2.5 aktualisiert und damit die Emojis von Apple auf Noto umgestellt haben, aber jetzt haben wir einige dieser Probleme:

Das funktionierende verwendet :netherlands:, während alle anderen 2-buchstabige Ländercodes verwenden, die früher funktionierten, aber, wie ich vermute, Aliase waren, die jetzt nicht mehr funktionieren.
Gibt es eine saubere, einfachere Möglichkeit, dies zu beheben, da eine große Anzahl von Beiträgen davon betroffen ist? Ich bin etwas vorsichtig bei dem Versuch von posts:remap.
Wo ich gerade dabei bin: Hier im Meta funktioniert :de: einwandfrei für
, daher gehe ich davon aus, dass twemoji diesen Alias auch mitbringt – nur Noto nicht.
Um dies persönlich zu beheben, dupliziere ich das Bild einfach mit vielen verschiedenen Namen. Es ist unordentlich, aber es funktioniert.
Ich habe das Emoji-Set auf meiner Seite auf Noto umgestellt und :de: scheint einwandfrei zu funktionieren:

Gibt es etwas Besonderes im Rohformat deines Beitrags? Hilft „HTML neu erstellen“?
Ich habe es dreifach überprüft und :de: funktioniert bei meiner Installation nicht. Der einzige Unterschied, den ich mir vorstellen kann, ist, dass wir auf 2.5.2 sind und Sie es wahrscheinlich gegen tests-passed testen.
Ich habe in discourse/discourse-emojis nachgesehen und es gibt tatsächlich einen noto/de.png Symlink, der anscheinend im März hinzugefügt wurde, und obwohl 2.5 im Juni veröffentlicht wurde, hat er es vielleicht nicht geschafft?
Hier ist, was ich habe/nicht habe:
# 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
Die Aliase flag_de und de sind vorhanden, aber nur für einige Sets. Es scheint, dass sowohl noto als auch fluentui kein eigenes germany.png haben und auf das im unicode-Set zurückgreifen. Möglicherweise wurden deshalb die Aliase nicht (oder noch nicht?) erstellt.
Sofern jemand keine sauberere Umgehungslösung sieht, werde ich versuchen, die fehlenden Symlinks im after_code-Hook des Build-Prozesses zu erstellen.



