على مدى الأسابيع القليلة القادمة، سنقوم بنقل عدد من إضافات Discourse الشائعة إلى المستودع الأساسي. هذا يعني أن Discourse سيأتي مع عدد أكبر من الإضافات افتراضيًا، وسيكون من الأسهل علينا الحفاظ على اختبارها وتحديثها جميعًا.
ستظل جميع هذه الإضافات معطلة افتراضيًا، لذا لن يكون لهذا أي تأثير مرئي على المجتمعات الحالية. إذا كنت تستخدم خدمة استضافة مُدارة مثل discourse.org، فلا تحتاج إلى القيام بأي شيء.
المجتمعات المستضافة ذاتيًا
إذا كنت تستضيف Discourse بنفسك، وتستخدم بالفعل إحدى هذه الإضافات، فسيُطلب منك إزالة السطر ذي الصلة من ملف app.yml الخاص بك قبل إعادة البناء التالية.
بيئة التطوير
إذا كان لديك بالفعل أحد المكونات الإضافية مثبتًا محليًا، ثم قمت بسحب أحدث إصدار من Discourse الأساسي، فسيحدث أحد أمرين.
إذا كنت تستخدم روابط رمزية (symlinks) للمكونات الإضافية الخاصة بك، فستتلقى خطأ أثناء git pull. لحل المشكلة، احذف الرابط الرمزي، ثم قم بتشغيل git pull مرة أخرى.
إذا قمت باستنساخ المكونات الإضافية مباشرة، فسينجح سحب git pull الأساسي، ولكن سيكون لديك بعض “التغييرات غير المرحّلة” المفاجئة الناتجة عن مستودعات git المتداخلة. أفضل طريقة للمضي قدمًا هي حذف الدليل المتأثر، ثم استعادته من main. على سبيل المثال:
شكرًا لك. مع معرفتي المتواضعة بالتطوير والبرمجة، أود أن أطرح عليك سؤالاً. هل يمكن لهذه المكونات الإضافية، التي هي في الأصل مكونات مخصصة للإضافة إلى تثبيت أساسي، أن تفقد طابعها الإضافي يومًا ما وتصبح جزءًا كاملاً من تثبيت أساسي، دون أن يطلق عليها اسم مكونات إضافية على الإطلاق؟
قد يفعلون ذلك، نعم. على وجه الخصوص، من المحتمل جدًا أن يتم استيعاب مكونات المصادقة الإضافية (مثل apple-auth) في النواة الأساسية، تمامًا مثل طرق المصادقة المضمنة الأخرى لدينا (مثل Google و Facebook، وما إلى ذلك).
إذا كنت أتذكر بشكل صحيح من تجربتي، فستتمكن فقط من تحديث دوكر أولاً. بمجرد تحديث دوكر، ستظهر لك رسالة في واجهة المستخدم للتحديث تشرح أنه يتعين عليك التحديث عبر سطر الأوامر، وكيفية القيام بذلك.
ثم عند التحديث على سطر الأوامر، سترى التلميح لكل مكون إضافي تحتاج إلى إزالته من app.yml كما هو موضح في المنشور الأول أعلاه.
هذا تحديث جيد ولكن هل كان هذا ضروريًا حقًا؟ يبدو أن فشل إعادة البناء قاسٍ بعض الشيء بالنسبة لي.. كان تحذير واجهة المستخدم أو التحديث التلقائي (أو تجاهلها تمامًا) سيكون أفضل من وضع مسدس على رأسي والقول “أزل هذه الآن”
لقد تسبب هذا في إرباكي الأسبوع الماضي عندما حاولت التحديث عبر سطر الأوامر وفشل (ملحق التفاعلات).
لقد تسبب هذا في إرباكي مرة أخرى عندما فشل تحديث سطر الأوامر الخاص بي مرة أخرى هذا الصباح (ملحق مستكشف البيانات).
أرحب بشدة برسالة تحذير على سطر الأوامر قبل بدء عملية التحديث، ثم فشلها حتمًا.
لقد فشلت تحديثاتي مرتين في أسبوعين، وهذا يعني أن منصة Discourse الخاصة بي كانت غير متاحة طوال الوقت الذي استغرقته لتصحيح المشكلة، وتعديل الإعدادات، والمحاولة مرة أخرى، وما إلى ذلك - كل ذلك أثناء حالة من الذعر الخفيف لأن كل شيء معطل.
أتساءل، هل سيؤدي وجود كل هذه الإضافات مجمعة في النواة إلى تضخيم المنتديات؟ بمعنى أنه سيكون هناك على الأرجح عدد قليل من الإضافات التي لا يرغب المسؤولون في منتدياتهم (على سبيل المثال، Discourse AI)، ولكن ليس لديهم خيار سوى إضافتها. يمكن تعطيلها بالطبع، لكنني أتساءل عما إذا كانت الملفات الإضافية والأشياء الأخرى ستبطئ المنتديات؟
على جانب العميل، لا يقدم Discourse أي أصول JavaScript للمكونات الإضافية المعطلة، لذلك لن يكون هناك أي تأثير هناك.
على جانب الخادم، بالنسبة للمكونات الإضافية المنفذة بشكل صحيح (وهي كلها كذلك)، يتم تجاوز التخصيصات من المكونات الإضافية عند تعطيلها. لذا نعم، من الناحية الفنية قد يكون هناك حمل طفيف للتحقق من حالة التمكين/التعطيل، ولكنه يجب أن يكون ضئيلًا.
المكونات الإضافية التي ندمجها هنا هي تلك التي نقوم بتشغيلها على كل نسخة من Discourse على استضافة discourse.org الخاصة بنا. لذلك تم اختبارها جميعًا جيدًا على نطاق واسع.
هل هناك سبب للقيام بكل هذا دفعة واحدة قبل الإصدار بفترة وجيزة؟ بالنسبة للمترجمين الذين يقومون بذلك في وقت فراغهم، فإن 3000 سلسلة إضافية في غضون أسبوعين هو أمر كبير. وحتى في اللغات التي تمت فيها ترجمة الإضافات سابقًا، يجب إعادة تدقيق جميع النصوص البالغ عددها 3000 نص. بين الحين والآخر، من المحتمل أن يكون 300 أكثر قابلية للإدارة من 3000.
بالنسبة للمجتمعات المستضافة ذاتيًا التي تقوم بالفعل بتشغيل واحد أو أكثر من هذه المكونات الإضافية، هل ستفقد المكونات الإضافية بيانات التكوين عند إزالتها من app.yml ودمجها في النواة؟
لقد قمت بإعداد المكون الإضافي للذكاء الاصطناعي بالطريقة التي أريدها بالضبط؛ إذا احتجت إلى إعادة تكوينه (أو على الأقل تدوين خيارات التكوين حتى أتمكن من إضافتها مرة أخرى)، فسيكون من الجيد معرفة ذلك الآن.
لقد كنا نحاول جعل هذا الأمر سلسًا قدر الإمكان للمترجمين من خلال الاستفادة من ذاكرة الترجمة في crowdin، بحيث لا تضطر الترجمات إلى إعادة إنشائها من الصفر. ولكن لا يزال، أتفق معك، هناك الكثير مما يجب مراجعته.
أتساءل عما إذا كان هناك المزيد مما يمكننا أتمتته هنا، على سبيل المثال، ربما يمكننا “الموافقة تلقائيًا” على أي سلاسل نصية من هذه الإضافات، بدلاً من طلب المراجعة
