Ich glaube, ich bin bei der Verwendung der automatisch generierten Inhaltsverzeichnis-Funktion in DiscoTOC auf ein potenzielles Problem gestoßen:
Wenn Überschriften unterschiedlicher Ebenen in anderen Sprachen als Englisch verwendet werden, z. B. Chinesisch, scheinen die data-d-toc-IDs im automatisch generierten Inhaltsverzeichnis nur numerische Ziffern und englische Buchstaben aus den Überschriften zu erfassen. Diese Situation kann leicht zur Erstellung identischer IDs führen, was anschließend zu falschen Links in der rechten Scrollleiste führt.
Im obigen Bild, wenn die Seriennummern in den Überschriften beide 5 sind, sind die resultierenden data-d-toc-IDs beide toc-h2-5. Folglich führt dies dazu, dass zwei verschiedene Links fälschlicherweise auf denselben Abschnitt verweisen.
Wenn jedoch die Seriennummern zu 1.5 und 2.5 geändert werden, unterscheiden sich die data-d-toc-IDs (toc-h2-15 und toc-h2-25), wodurch korrekte und angemessene Links sichergestellt werden.
Um eine genaue Verknüpfung innerhalb der Scrollleiste zu gewährleisten, ist es ratsam, die Überschriften auf Englisch zu belassen?
Wäre für Sprachen wie Chinesisch die praktikabelste Lösung die Einbeziehung von mehrstufigen Seriennummern (z. B. 3.5, 3.6.5, 4.2.5.6) zu den Überschriften?
Obwohl meine Lösung funktioniert, ist sie nicht perfekt, aber ich bin zu faul, den Code zu ändern.
Offensichtlich ist eine bessere Lösung, base64 zu verwenden, um data-d-toc zu generieren und eine eindeutige Kennung hinzuzufügen, um mögliche doppelte Titel zu verhindern.
Ich habe derzeit nicht die Befugnis, solche Änderungen an den Foren meines Unternehmens vorzunehmen, aber ich schätze Ihre Antwort trotzdem!
Außerdem möchte ich fragen, ob das offizielle Team in Betracht gezogen hat, die Unterstützung für andere nicht-lateinische Sprachen bezüglich dieser automatisch generierten Inhaltsverzeichnisse in zukünftigen Veröffentlichungen der DiscoTOC-Komponente einzubauen? @Lilly@awesomerobot
Tatsächlich haben sie non-Latin-Sprachen berücksichtigt und die Methode slugify(h.textContent) verwendet. Ich vermute, dass diese slugify-Funktion gemäß der slug generation method des Forums entwickelt wurde. Wenn sie nicht im ‘encode’-Modus ist, treten tendenziell Probleme auf, obwohl ich diese Hypothese noch nicht persönlich getestet habe.
In früheren Fällen, als wir die offizielle Version der Theme-Komponente verwendeten, war die slug generation method unseres Forums auf ‘none’ eingestellt, was zu ähnlichen Problemen führte. Darf ich Ihnen daher vorschlagen, die Einstellung auf ‘encode’ zu ändern?
Darüber hinaus, wenn man die Reparaturgeschwindigkeit der offiziellen Komponenten berücksichtigt … Bei einer Komponente nebenan wurde ein Problem, das ich letztes Jahr gemeldet habe, bisher nicht behoben. Ich empfehle Ihnen, die Verwendung meiner geforkten Version zu beantragen.
Ich habe versucht, diese Einstellung zu ändern, aber die zuvor erwähnten Probleme bestehen weiterhin. Die ID data-d-toc kann nur Zahlen und Buchstaben lesen, und es gibt immer noch doppelte Verzeichnis-IDs. Ich vermute, der Kern des Problems liegt woanders?
Ich frage meinen Vorgesetzten, danke für die Antwort~
Ich habe versucht, diese Einstellung zu ändern, aber die zuvor erwähnten Probleme bestehen weiterhin. Die ID data-d-toc kann nur Zahlen und Buchstaben lesen, und es gibt immer noch doppelte Verzeichnis-IDs. Ich vermute, der Kern des Problems liegt woanders?
Ich frage meinen Vorgesetzten, danke für die Antwort~
