et ensuite, il y a toutes sortes de choses à gérer, comme les alias
Ah-ha !
J’avais raté ce dépôt, merci @j.jaffeux nous sommes de nouveau opérationnels ![]()
Apple, avec un fallback vers unicode ![]()
Cela semble une façon étrange de faire les choses. Rendre les emojis sous forme d’images dans le flux de texte va à l’encontre de la logique. La grande majorité des utilisateurs sont très habitués aux emojis natifs de leur appareil/système d’exploitation, donc regarder une version moins bonne ou différente leur semblera étrange.
La grande majorité des sites Web utilisent les emojis natifs de l’utilisateur, comment cela pose-t-il vraiment problème ? ne devrait-il pas être par défaut les emojis natifs de l’utilisateur, avec la possibilité de définir des ensembles d’emojis personnalisés comme plugin ou option personnalisable par l’utilisateur ?
L’approche actuelle semble et paraît peu élégante.
test
test
doit-il y avoir quelque chose dans votre thème ?
- Twitter utilise la même stratégie
- Slack utilise la même stratégie
- Discord utilise la même stratégie
Peut-être y a-t-il une raison ?
Non, désolé, j’avais manqué une capture d’écran pour montrer qu’il s’agissait d’un téléchargement d’après ce que j’ai vu.
Si je modifie le message, voici ce que je vois :
Étrange hein ![]()
![]()
Question : Pour l’ensemble Unicode, ce sont ceux de la colonne « Exemple », n’est-ce pas ? Si c’est le cas, ce sont exactement les mêmes que Noto, n’est-ce pas ? Je suis juste un peu confuse quant à la raison pour laquelle les deux sont proposés s’il s’agit du même ensemble.
![]()
Oui, vous avez raison, nous devrions les faire converger, sans grand mal cependant.
Je viens de tomber sur ceci, car le forum par défaut (même en réinitialisant l’option à sa valeur par défaut) est « Twitter » alors qu’il est indiqué « déprécié vers Twemoji ».
Il est logique que les emojis « Twitter » soient dépréciés, étant donné que le nom « Twitter » est déprécié (et que la nouvelle plateforme est devenue un dépotoir largement abusé)
. Mais il est probablement aussi logique de ne pas modifier les choses sans le consentement de l’administrateur.
À propos de cette valeur par défaut : s’agit-il de la valeur par défaut avec laquelle la propre instance Discourse a été initialement livrée, ou s’agit-il de valeurs globales pour toutes les instances, et donc susceptibles de changer ? Les nouvelles instances ont-elles les emojis Twemoji activés par défaut ?
Si tel est toujours le cas, cela pourrait changer à l’avenir, voir :
Vous voulez dire si ce n’est pas encore le cas ?
Mon point est le suivant :
- Il semble étrange que les emojis « Twitter » soient explicitement indiqués comme obsolètes dans la liste, alors qu’ils sont toujours ceux par défaut, c’est-à-dire que le bouton « réinitialiser » dans notre cas applique toujours ces emojis Twitter obsolètes.
- Je me demandais donc si la valeur par défaut n’avait pas vraiment changé dans le code source, avec le renommage de « Twitter » en « Twitter (obsolète pour Twemoji) », ou si les changements de paramètres par défaut ne s’appliquaient pas rétroactivement aux instances Discourse existantes. Dans ce cas particulier, il y aurait un argument pour ne pas changer la valeur par défaut sur une instance existante, afin que les administrateurs puissent toujours revenir à ce avec quoi leur forum a été expédié, et que les paramètres qu’ils n’ont jamais touchés ne changent pas sans qu’ils les modifient explicitement.
- Autre formulation : les boutons « réinitialiser » appliquent-ils les valeurs par défaut de Discourse (qui peuvent changer), ou appliquent-ils la valeur avec laquelle l’instance Discourse a été initialement expédiée ?
Eh bien, je suppose que la valeur par défaut n’a vraiment pas encore été modifiée, l’autre théorie semble un comportement assez compliqué
.
Twitter est toujours le réglage par défaut, même sur les nouvelles installations
Je pense que « réinitialiser » rétablit toujours la valeur par défaut de la version actuelle. Par exemple, « Normaliser les e-mails » était activé par défaut il y a environ un an DEV: Enable the normalize_emails site setting by default by Drenmi · Pull Request #29952 · discourse/discourse · GitHub, donc réinitialiser modifie le réglage pour l’activer maintenant.
Quelqu’un a-t-il créé un plugin pour ramener les emojis Apple ? Ils me manquent vraiment ![]()
Ou est-il possible de faire apparaître nos propres emojis personnalisés en premier et de remplacer le texte de base comme :-) ?
Je n’ai pas créé de plugin, mais j’ai transféré l’ensemble « twemoji » vers un autre dossier où j’ai téléchargé toutes les icônes Apple, c’est donc ce qui apparaît sur le site.
Assez simple, bien qu’il faille faire des duplications et des renommages pour s’assurer qu’il n’y a pas d’éléments cassés, et bien sûr, c’est à vous de récupérer les images des nouvelles icônes publiées.
Existe-t-il un moyen simple pour un administrateur d’ajouter des alias d’emoji ?
Cette question, car nous sommes passés à la version 2.5 et avec cela, nous avons remplacé les emojis Apple par Noto, mais nous avons maintenant pas mal de ces problèmes :

Celui qui fonctionne utilise :netherlands: tandis que tous les autres utilisent des codes de pays à 2 lettres qui fonctionnaient auparavant mais qui, je suppose, étaient des alias qui ne fonctionnent plus maintenant.
Y a-t-il un moyen plus propre de résoudre ce problème car nous avons un grand nombre de messages affectés par cela ? Je suis un peu méfiant à l’idée d’essayer posts:remap.
Pendant que j’y suis, ici sur meta, :de: fonctionne très bien pour
, donc je suppose que twemoji vient aussi avec cet alias — juste pas Noto.
Personnellement, pour résoudre ce problème, je duplique simplement l’image avec de nombreux noms différents. C’est désordonné, mais ça fonctionne.
J’ai changé l’ensemble d’emojis sur mon site pour Noto et :de: semble fonctionner correctement :

Y a-t-il quelque chose de spécial dans le brut de votre publication ? Est-ce que ‘reconstruire le html’ aide ?
J’ai vérifié trois fois et :de: ne fonctionne pas pour mon installation. La seule différence que je peux imaginer est que nous sommes sur la version 2.5.2 et que vous testez probablement avec les versions de tests réussis (tests-passed).
J’ai regardé dans discourse/discourse-emojis et il y a bien un symlink noto/de.png qui semble avoir été ajouté en mars, et bien que la version 2.5 soit sortie en juin, il est possible qu’elle n’ait pas été incluse ?
Voici ce que j’ai/n’ai pas :
# 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
Les alias flag_de et de sont présents, mais seulement pour certains ensembles. Il semble que noto et fluentui n’aient pas leur propre germany.png et se rabattent sur celui de l’ensemble unicode. C’est peut-être pour cette raison que les alias n’ont pas été (ou ne sont plus) créés.
À moins que quelqu’un ne voie une solution de contournement plus propre, je pourrais essayer de créer les liens symboliques manquants dans le hook after_code du processus de construction.



