J’ai constaté un comportement incohérent avec les balises emoji dans l’éditeur de sujet et je l’ai reproduit sur la branche main non modifiée à la révision 802125b979b5bb848a7cfc52409ef3176ffd4d82.
Pour une balise emoji existante, la saisie de son nom peut afficher l’option Créer au lieu de la balise existante et de son nombre d’utilisations. La sélection de cette option et la publication du message attachent tout de même la balise existante. Une balise emoji nouvelle est un cas distinct : elle peut être sélectionnée dans l’éditeur, mais disparaît après publication.
Pour reproduire le problème lié aux balises existantes :
- Utilisez un site disposant d’une balise emoji existante, telle que
😊, ainsi que d’autres balises plus fréquemment utilisées. - Ouvrez l’éditeur de sujet et saisissez le nom de la balise emoji.
- Si cette balise se trouve en dehors de la limite des balises populaires retournées, la liste déroulante affiche une option de création et des balises populaires non liées, sans indiquer le nombre d’utilisations de la balise existante.
- Sélectionnez l’option de création, publiez et actualisez la page. Le sujet utilise toujours l’enregistrement de la balise d’origine.
Lors d’un test isolé dans un navigateur, j’ai utilisé une balise emoji existante avec un compteur de 17, une balise non liée avec un compteur de 100 et une limite de recherche de 1. La liste déroulante affichait Créer : '😊' et populaire x100 ; après publication, la balise emoji existante a été correctement réutilisée. En l’absence d’un enregistrement existant pour 😊, la même opération a renvoyé un code HTTP 200 mais n’a enregistré aucune balise.
La cause réside dans DiscourseTagging.clean_tag, qui est utilisé à la fois pour les termes de recherche et l’enregistrement de nouveaux noms. Cette méthode supprime les caractères emoji. La recherche retombe alors sur les résultats populaires, tandis que l’enregistrement peut encore trouver une balise existante par son nom d’origine avant le nettoyage des nouveaux noms.
Je dispose d’un petit correctif qui préserve les graphèmes emoji complets reconnus par les données existantes de Emoji.unicode_replacements. Il conserve le filtrage ASCII existant et supprime les caractères invalides du texte non-emoji. Il permet également aux suggestions de balises désactivées de correspondre au début d’un nom, car l’expression régulière actuelle basée sur les limites de mots ne détecte pas les noms commençant par un emoji, tels que 😊-restricted.
Le correctif modifie deux fichiers d’implémentation et ajoute une couverture de régression dans trois fichiers de tests. Il n’ajoute ni migration de base de données, ni modification du front-end, ni nouvelle API, ni autre cache emoji.
Validation locale : 572 exemples backend liés et 8 exemples navigateur ont réussi. Les tests navigateur vérifient qu’une balise emoji existante affiche x17, et que celle-ci, ainsi qu’une nouvelle balise 😊 véritablement inédite, subsistent après publication et actualisation.
Branche du correctif :
Signalements et discussions associés :
Ces signalements décrivent des limitations antérieures concernant les balises emoji. Ce correctif traite des échecs de recherche et d’enregistrement dans l’éditeur reproduits ci-dessus ; il ne prétend pas résoudre tous les problèmes liés aux balises emoji.