أعتقد أنني واجهت مشكلة محتملة أثناء استخدام ميزة جدول المحتويات الذي تم إنشاؤه تلقائيًا في DiscoTOC:
عند استخدام عناوين بمستويات مختلفة بلغات غير الإنجليزية، مثل الصينية، يبدو أن معرفات data-d-toc في جدول المحتويات الذي تم إنشاؤه تلقائيًا تلتقط فقط الأرقام والحروف الإنجليزية من العناوين. يمكن أن يؤدي هذا الموقف إلى إنشاء معرفات متطابقة بسهولة، مما يؤدي لاحقًا إلى روابط غير صحيحة في شريط التمرير الأيمن.
في الصورة أعلاه، إذا كانت الأرقام التسلسلية داخل العناوين كلاهما 5، فإن معرفات data-d-toc الناتجة ستكون كلاهما toc-h2-5. وبالتالي، سيؤدي ذلك إلى رابطين مختلفين يشيران بشكل خاطئ إلى نفس القسم.
ومع ذلك، من خلال تعديل الأرقام التسلسلية إلى 1.5 و 2.5، ستكون معرفات data-d-toc مختلفة (toc-h2-15 و toc-h2-25)، مما يضمن روابط دقيقة ومناسبة بشكل فعال.
لضمان الربط الدقيق داخل شريط التمرير، هل يُنصح بالاحتفاظ بالعناوين باللغة الإنجليزية؟
علاوة على ذلك، بالنسبة للغات مثل الصينية، هل سيكون الحل الأكثر جدوى هو دمج أرقام تسلسلية متعددة المستويات (مثل 3.5، 3.6.5، 4.2.5.6) إلى العناوين؟
ومع ذلك، على الرغم من أنها تعمل، إلا أنها ليست مثالية، لكنني كسول جدًا لتغيير الكود.
However, although it’s working, it is not perfect, but I am too lazy to change the code.
من الواضح أن الحل الأفضل هو استخدام base64 لإنشاء data-d-toc وإضافة معرف فريد لمنع العناوين المكررة المحتملة
Obviously a better solution is to use base64 to generate data-d-toc and add a unique identifier to prevent possible duplicate titles
ليس لدي حاليًا السلطة لإجراء مثل هذه التغييرات على منتدى شركتي، لكنني أقدر ردك!
بالإضافة إلى ذلك، أود أن أسأل عما إذا كان الفريق الرسمي قد نظر في دمج دعم اللغات الأخرى غير اللاتينية فيما يتعلق بجدول المحتويات الذي تم إنشاؤه تلقائيًا في الإصدارات المستقبلية لمكون DiscoTOC؟ @Lilly@awesomerobot
في الواقع، لقد أخذوا في الاعتبار اللغات غير اللاتينية، باستخدام الطريقة slugify(h.textContent). أشك في أن هذه الدالة slugify تم تطويرها وفقًا لطريقة إنشاء الـ slug الخاصة بالمنتدى. عندما لا تكون في وضع ‘encode’، تميل المشاكل إلى الظهور، على الرغم من أنني لم أختبر هذه الفرضية شخصيًا.
في مناسبات سابقة عندما استخدمنا الإصدار الرسمي لمكون السمة، تم تعيين طريقة إنشاء الـ slug الخاصة بالمنتدى لدينا على ‘none’، مما أدى إلى مشاكل مماثلة. هل لي بالتالي أن أقترح عليك محاولة تغيير الإعداد إلى ‘encode’؟
في الواقع، لقد أخذوا في الاعتبار اللغات غير اللاتينية، باستخدام الطريقة slugify(h.textContent)، وأشك في أن دالة slugify هذه تم إنشاؤها وفقًا لطريقة إنشاء الـ slug الخاصة بالمنتدى، وعندما لا تكون في وضع ‘encode’ فإنها تسبب مشاكل، لكنني لم أجرب ذلك.
في السابق، عندما استخدمنا النسخة الرسمية للمكون الإضافي، كانت طريقة إنشاء الـ slug الخاصة بالمنتدى لدينا مضبوطة على ‘none’، مما تسبب في نفس المشكلة التي تواجهها. ماذا لو حاولت تغييرها إلى ‘encode’؟
بالإضافة إلى ذلك، بالنظر إلى سرعة إصلاح المكونات من قبل المسؤولين… هناك مكون إضافي مجاور لم يتم حل المشكلة التي أبلغت عنها فيه منذ العام الماضي، وأقترح عليك التقدم بطلب لاستخدام النسخة التي قمت بعمل fork لها.
لقد حاولت تعديل هذا الإعداد، لكن المشكلات المذكورة سابقًا لا تزال قائمة. معرف data-d-toc يمكنه قراءة الأرقام والأحرف فقط، ولا تزال هناك حالات لمعرفات جدول محتويات مكررة. أعتقد أن جوهر المشكلة يكمن في مكان آخر؟
