Si les étiquettes sont localisées, soit
Le nom n’est pas “slugifié”, ce qui entraîne toutes sortes de problèmes lorsqu’il y a des espaces ou des guillemets dedans.
Honnêtement, je me demande si les classes de corps devraient contenir les étiquettes localisées.
Cela provoque également des problèmes étranges lorsque les étiquettes sont affichées sous le titre du sujet.
@nat probablement hors sujet mais cela aurait-il pu être corrigé par :
Ceci ne concerne pas le slug, mais le nom “slugifié” (j’espère que vous suivez toujours)
Une étiquette avec le nom my-name et le slug my-slug se trouvera à /tag/my-slug/ID et aura une classe de corps tag-my-name.
Alors que le champ name d’étiquette normal dans la page de modification de l’étiquette supprimera tous les caractères spéciaux (my-name\"(123) sera enregistré comme my-name123), les champs de nom dans les localisations ne le font pas, et ils ne sont pas non plus correctement “slugifiés” à la sortie.
Une étiquette avec le nom my-name et une localisation néerlandaise de mijn-naam obtiendra la classe de corps tag-mijn-naam.
Une étiquette avec le nom my-name et une localisation néerlandaise de mijn-naam\" (123) obtiendra une classe de corps tag-mijn-naam\" (123) ce qui casse beaucoup de choses.
La méthode de génération de slug est définie sur ascii au fait.
Merci, laissez-moi regarder.
Nous avons fusionné un correctif qui nettoie les noms de balises localisées après leur retour du LLM, ainsi qu’une post-migration qui nettoie les noms de balises localisées “sales” existants.
Notez également que la pull request indique que la post-migration a une certaine logique d’application pour nettoyer les balises, mais nous devrions être en sécurité ici avec certaines conditions et tests.
Je garderai ce sujet ouvert pour voir ce qu’il en ressort pour vous.
