لقد رأيت هذا في منتدى اليوم
وأعتقد أن Discourse على حق: لا يوجد dashboard.problem.sidekiq_check. هناك
والتي تتم الإشارة إليها هنا:
ولكن يبدو أن Discourse يشير إلى اسم فحص المشكلة هذا بدلاً من ذلك.
3 إعجابات
تم الإصلاح عبر:
إعجابَين (2)
هل يمكنك مساعدتي في فهم كيفية عمل الإصلاح؟ أرى أن مفتاح الترجمة في ملف server.en.yml وoverride_key قد تم إعادة تسميتهما ليتطابقا مع اسم الفحص. أتساءل لماذا كان من الضروري إعادة تسمية كليهما ليتطابقا مع اسم الملف. أليس من المفترض أن يعمل أيضًا باستخدام sidekiq بدلاً من sidekiq_check؟ أتساءل عما إذا كان لا يزال اسم الفحص بدلاً من override_key هو ما يؤثر على التحذير الذي يتم عرضه، لذا أتساءل عما إذا كان التجاوز dashboard.problem.queue_size يعمل أم أنه نص لا يتم عرضه أبدًا، تمامًا كما لم يتم عرض dashboard.problem.sidekiq.
إعجابَين (2)
نعم، نرجع في ملف منفصل إلى معرف فحص المشكلة:
لذلك يضمن طلب الدمج (PR) المذكور أعلاه أن يتطابق النص في ملفات الترجمة مع اسم ملف فحص المشكلة، والذي يتم تحويله إلى هذا المعرف، أي sidekiq_check. لم يكن استخدام sidekiq في سلاسل الترجمة يعمل، لأنه لم يكن يطابق المعرف.
إعجاب واحد (1)
عذراً، لا أفهم الأمر حقاً بعد.
queue_size لا يطابق اسم الملف/المعرف أيضاً، تماماً كما لم يفعل sidekiq. ولا أفهم أيضاً لماذا لا يُعد هذا مشكلة في تلك الحالة.
هل السبب هو وجود مسار كود آخر يستخدم المعرف مباشرةً بدلاً واحد من مفاتيح التخطي (override keys)؟ لذا، بدلاً من إضافة مفتاح ترجمة ثالث يطابق اسم الملف، قمت بتغيير sidekiq لاستخدام المفتاح القائم على المعرف؟ نوعاً ما حل يجمع بين أمرين يدعم كل حالة التخطي وحالة المعرف؟
إذا كان الأمر كذلك، فلا أفهم لماذا يجب تمرير dashboard.problem.sidekiq_check كمفتاح تخطي. ففحوصات المشاكل الأخرى التي يطابق فيها مفتاح الترجمة اسم الملف لا تحتاج إلى ذلك. إذن، لماذا يلزم التخطي هنا؟
إعجاب واحد (1)
نعم، هذا صحيح.
لا نحتاج إليه، وكان من الممكن أن يعمل هذا بشكل جيد إذا استخدمنا return problem في السطر 8 من ملف sidekiq_check.rb. إنهما متكافئان. (لقد أبقيت على مرجع التخطي لإجراء تغيير أصغر في طلب الدمج ذلك في ذلك الوقت.)
إعجاب واحد (1)
هل هناك شيء يمكنني تغييره بسهولة في تثبيت التطوير لتحفيز رسالة الخطأ dashboard.problem.queue_size؟
اعتقدت أن تغيير
def massive_queue?
Jobs.queued >= 100_000
end
إلى >= 0 سيؤدي إلى تحفيز ذلك الخطأ - ولكن هذا أدى إلى ظهور dashboard.problem.sidekiq_check
إعجاب واحد (1)
من الأسهل إعادة إنتاج المشكلة في مواصفات النظام. حاولت القيام بذلك وكشفت عن بعض المشكلات الأخرى، وهذا يجب أن يصلحها:
إعجاب واحد (1)
عند ترجمة واجهة Discourse، من المفيد أحيانًا رؤية النص في سياقه، ولهذا السبب أحاول أحيانًا استدعاء هذه التحذيرات وأنا دائمًا مهتم بتعلم كيفية القيام بذلك بسهولة أكبر. هل هذا ممكن باستخدام مواصفات النظام؟ أم أن كلمة “أسهل” لديك تتعلق فقط بسياق ضمان عمل الكود كما هو متوقع؟
نعم، يمكنك استخدام مواصفات النظام لرؤية الترجمات في سياقها.
إذا كان لديك بيئة تطوير لـ Discourse، يمكنك فعل شيء مثل هذا:
- أضف عبارة
pause_testفي مواصفات النظام التي تريد رؤيتها في المتصفح - شغّل مواصفات النظام هذه في وضع headful، أي باستخدام متصفح كامل (بشكل افتراضي، تعمل المواصفات في وضع headless)
على سبيل المثال، بالنسبة للمواصفات أعلاه، أضفت pause_test إلى السطر 47 من ملف admin_notices_spec.rb ثم شغّلت المواصفات باستخدام:
PLAYWRIGHT_HEADLESS=0 bin/rspec spec/system/admin_notices_spec.rb:47
هذا أدى إلى تشغيل متصفح والتوقف عند هذه الشاشة المحددة:
إعجاب واحد (1)