Je crois avoir rencontré un problème potentiel lors de l’utilisation de la fonctionnalité de table des matières générée automatiquement dans DiscoTOC :
Lorsque vous utilisez des titres de différents niveaux dans des langues autres que l’anglais, comme le chinois, il semble que les ID data-d-toc dans la table des matières générée automatiquement ne capturent que les chiffres numériques et les lettres anglaises des titres. Cette situation peut facilement entraîner la création d’ID identiques, conduisant ainsi à des liens incorrects dans la barre de défilement de droite.
Dans l’image ci-dessus, si les numéros de série dans les titres sont tous deux 5, les ID data-d-toc résultants seront tous deux toc-h2-5. Par conséquent, cela conduira deux liens distincts à pointer erronément vers la même section.
Cependant, en modifiant les numéros de série en 1.5 et 2.5, les ID data-d-toc seront différents (toc-h2-15 et toc-h2-25), garantissant ainsi des liens précis et appropriés.
Afin d’assurer une liaison précise dans la barre de défilement, est-il conseillé de conserver les titres en anglais ?
De plus, pour des langues comme le chinois, la solution la plus viable consisterait-elle à intégrer des numéros de série à plusieurs niveaux (par exemple, 3.5, 3.6.5, 4.2.5.6) aux titres ?
Cependant, bien que cela fonctionne, ce n’est pas parfait, mais j’ai la flemme de modifier le code.
Évidemment, une meilleure solution consiste à utiliser base64 pour générer data-d-toc et à ajouter un identifiant unique pour éviter les titres potentiellement dupliqués.
Je n’ai pas l’autorisation de faire de tels changements sur le forum de mon entreprise pour le moment, mais je vous remercie de votre réponse !
De plus, je voudrais demander si l’équipe officielle a envisagé d’intégrer la prise en charge d’autres langues non latines pour cette table des matières générée automatiquement dans les futures versions du composant DiscoTOC ? @Lilly@awesomerobot
En vérité, ils ont pris en compte les langues non latines, en utilisant la méthode slugify(h.textContent). Je soupçonne que cette fonction slugify a été développée conformément à la méthode de génération de slug du forum. Lorsqu’elle n’est pas en mode ‘encode’, des problèmes ont tendance à survenir, bien que je n’aie pas personnellement testé cette hypothèse.
Dans des cas précédents, lorsque nous utilisions la version officielle du composant de thème, la méthode de génération de slug de notre forum était réglée sur ‘none’, ce qui a donné lieu à des problèmes similaires. Puis-je donc suggérer d’essayer de modifier le paramètre sur ‘encode’ ?
De plus, compte tenu de la vitesse de correction des composants par le développeur officiel… il y a un composant à côté pour lequel le problème que j’ai signalé l’année dernière n’a toujours pas été résolu, je vous suggère de demander à utiliser ma version fork.
J’ai essayé de modifier ce paramètre, mais les problèmes mentionnés précédemment persistent. L’ID data-d-toc ne peut lire que des chiffres et des lettres, et il y a toujours des ID de table des matières dupliqués. Je suppose que le nœud du problème se situe ailleurs ?
