كانت الأيام القليلة الماضية مزدحمة للغاية. لكنني اقتربت من الانتهاء من تحديث منطق الحصول على أقرب إحصائية تالية: بدلاً من النظر إلى النسبة المئوية، ينظر إلى أقل قيمة فعلية يمكن تحقيقها لاحقًا.
أما بالنسبة لمستويات 3 (TL3) التيوشوش أن تفقد تقدمها، فقد بدأت العمل في ذلك أيضًا. على الأرجح لا ينبغي استخدام المستودع في الوقت الحالي لأنه في مرحلة انتقالية بين المنتج النهائي.
حسنًا. سأقول إنها كانت موجودة تقريبًا منذ الأزل. وجدت التزامًا (commit) بإعادة تسميتها من عام 2014
لا أعتقد أن هناك “فترة طويلة” من تاريخ Discourse قبل ذلك.
أعتقد أنك قد تحتاج إلى إعدادات منفصلة لمخططات الألوان الفاتحة والداكنة. فالرمادي الفاتح على الأسود له تباين مختلف عنه على الأبيض.
بدلاً من time_period: "Based on last %{num_days} days." يمكنك استخدام
time_period:
one: "Based on last %{count} day."
other: "Based on last %{count} days."
ثم ستحصل على day/days اعتمادًا على الرقم. الأمور تصبح أكثر تعقيدًا قليلاً عندما يكون هناك أكثر من رقم تعتمد عليه كلمات أخرى في النص. سأحاول تجنب Message Format.
مثير للاهتمام، الآن يجب أن أتساءل لماذا أعتقد ما لاحظته.
ملاحظة أخرى مثيرة للاهتمام حول هذا الالتزام، كان قد قام به جيف ( coding-horror) وهو أمر نادرًا ما نراه في أيامنا هذه.
بعد القراءة:
تذكرت مشكلة يواجهها بعض المستخدمين عند محاولة الوصول إلى مستوى الثقة 3 (TL3).
عندما يُطلب من المستخدمين قراءة عدد معين أو نسبة محددة من المنشورات، يفترضون بشكل طبيعي أن جميع المنشورات المدرجة في هذا الحساب مرئية لهم. ومع ذلك، قد لا يكون ذلك صحيحًا دائمًا.
على سبيل المثال، إذا كانت المنشورات في فئة مُكتممة لا تزال تُحسب ضمن المتطلب، فقد يكون هناك عدد كافٍ من المنشورات المؤهلة في الفئات المكتممة لجعل الهدف صعبًا — أو ربما مستحيلًا — التحقق منه دون إلغاء كتم تلك الفئات وقراءة المنشورات أولاً.
لذلك، يجب أن يقدم البرنامج المساعد تفصيلًا فئةً بفئة يُظهر:
سيكشف ذلك عما إذا كانت الفئات المكتممة تؤثر على تقدم المستخدم، ويوضح ما يحتاج إلى فعله لتلبية المتطلب — أو، كما قد يصفه بعض المستخدمين، كيفية “التلاعب” بالنظام.
لوحات الألوان للوضع الفاتح/الداكن
اكتمل تقريباً عرض الإحصائيات إذا كان مستخدم المستوى الثالث (TL3) على وشك فقدان هذا المستوى (مع إعداد حد أدنى لعرض تحذير إذا كانت الإحصائية أقل من هذه القيمة).
المشكلة هي أن حتى النظام الأساسي لا يحتوي على هذا النوع من المؤشرات. الفكرة الأصلية هي نقل المعلومات التي يمكن لمشرفي النظام رؤيتها إلى المستخدمين أنفسهم. أعتقد أن هذا قد يكون خارج نطاق الملحق. لكنني أود معرفة المزيد حول هذا الأمر. هل تقصد أن الفئات غير المكتومة لا تحتوي على عدد كافٍ من المنشورات لتلبية المتطلب، وأن العدد المتبقي يمكن أن يأتي من الفئات المكتومة؟
بالإضافة إلى ذلك، كيف سيعمل ذلك؟ الحصول على كل منشور تم إنشاؤه خلال الإطار الزمني، التحقق من الموضوع الذي ينتمي إليه، التحقق من معرف الفئة، ومقارنته مع الفئات المكتومة لدى المستخدم، ثم إضافته إلى عداد؟ أو ربما استعلام SQL مُحسّن…
ليس بالضرورة، على الرغم من أن ذلك قد يكون صحيحًا في حالة متطرفة.
من وقت لآخر، أثناء مساعدة المستخدمين، لُوحظ أن عدد المنشورات التي قرأها مستخدم واحد كان يزداد بشكل أسرع من عدد منشورات مستخدم آخر. كان الاختلاف غالبًا أن القارئ الأكثر نشاطًا لم يكن قد صَمَتَ على فئات معينة. وبالتالي، كانت مواضيع تلك الفئات تظهر في قوائم مواضيعه وكانت أكثر عرضة للقراءة.
عندما أزال المستخدم الآخر الصمت عن الفئة، أصبحت المزيد من المواضيع مرئية في مشاهد التصفح العادية الخاصة به، وزاد عدد المنشورات التي يقرأها يوميًا ليقترب تقريبًا من عدد منشورات المستخدم الآخر.
نعم. يمكن احتساب المنشورات في تلك الفئات عندما يتم قراءتها فعليًا. ومع ذلك، يمكن أن يؤدي صمت فئة ما إلى إبطاء تقدم المستخدم بشكل غير مباشر، لأن مواضيعها تكون مخفية في مشاهد مثل الأحدث وبالتالي يكون من السهل تفويتها.
منذ سنوات، كان متطلب قراءة المنشورات على منتدى OpenAI يعتمد بشكل أساسي على نسبة من نشاط المنتدى، دون الحد الأدنى الموجود في العديد من التكوينات الحالية. على منتدى نشط للغاية، كان ذلك يتطلب قراءة 10,000 منشور أو أكثر.
لُوحظ من قبل بعض المستخدمين أن إجمالي المنشورات التي قرأها أعضاء آخرون، كما هو موضح في دليل المستخدمين، كان يزداد بسرعة أكبر بكثير على الرغم من أنهم كانوا يقرأون كل منشور مرئي يمكنهم العثور عليه. بعد بعض التحقيقات، تم تحديد الفئات المُصَمْتَة كسبب: لم يكن عدد كبير من المنشورات المتاحة يظهر في قوائم مواضيعهم المعتادة.
هذه هي الطريقة التي سأحاول بها القيام بذلك أولاً.
حسنًا، لقد أضفت ميزة إظهار أقل إحصائية إذا كان المستخدم فوق المستوى الثالث (TL3). لقد قمت بحساب الاستعلامات اللازمة لإيجاد عدد المواضيع والردود في الفئات المُصَمَتة، وأعمل الآن على دمجها في واجهة المستخدم.
Bingo bongo: @EricGT لقد أضفت عرضًا حول ما إذا كان المستخدم مقيدًا، وكم عدد المواضيع والرسائل في الفئات المُكتممة، وما إذا كان المستخدم سيخسر TL3 قريبًا. أنا في انتظار رد على How do I access topics in muted categories? للحصول على الرابط الصحيح لعرض تلك المواضيع المُكتممة.
تم تحديث الرابط ليوجه فقط إلى /u/<username>/preferences/tracking. إذا لم يكن هناك أي شيء آخر، سأقوم بإنشاء موضوع Customization > Plugin!
هذا رائع، شكرًا لك على بناءه ومشاركته!
أتساءل عما إذا كان يمكن استخدام هذا الأساس لتتبع تقدم مماثل يتعلق بالشارات. نظام الكارما/التحديات لدينا (المعروف سابقًا باسم التشجيع/الشارات) ومستوى الثقة مخصص، ومجتمعنا يحتاج إلى مؤشر تقدم يرتبط بالتحديات/الشارات ليكون الأنسب لنا.
تم نشر هذا على See TL3 Progress 
!