استبدال نصوص الموقع بكفاءة

لقد قرأت أن الطريقة الوحيدة لالتقاط كل النصوص التي ترغب في استبدالها هي باستخدام إعدادات نصوص الموقع واستبدال كل واحدة على حدة. أنا أحاول تغيير التعبير:

المواضيع → خيوط
الفئات → منتديات
تصنيفات فرعية → منتديات فرعية

لأن ذلك يبدو أكثر منطقية بالنسبة لي مع لوحات الرسائل. استطعت تغيير الكثير منها باستخدام نصوص الموقع، لكنه أسلوب غير فعال جدًا للتعامل معه. هل هناك طريقة أخرى؟

(بالإضافة إلى ذلك، نظرًا لأنه ستتم إعادة النتائج الأولى 50 فقط، لا يمكنني في الواقع تغييرها جميعًا باستخدام نصوص الموقع على أية حال.)

إذا كان هذا هو الجبل الذي تريد أن تموت عليه (وعندما تطرح أسئلة هنا، هل ستستخدم لغتك أم لغتنا؟)، يمكنك النظر إلى discourse/config/locales/client.en.yml at main · discourse/discourse · GitHub ورؤية كل منها.

3 إعجابات

اعتمادًا على ما إذا كان يمكنك استخدام مكونات إضافية خارجية، قد يكون هذا مفيدًا؟

هاها، سأستخدم لغتك للحفاظ على استقرار الأمور! بخصوص هذا الملف، هل يمكنني فقط تغيير محتواه للتثبيت المحلي الخاص بي وستتغير الأمور في جميع أنحاء الموقع؟

أشكرك على المشاركة. أقلق بشأن احتمال تلف عناصر واجهة المستخدم وفقًا للتعليقات…

إعجاب واحد (1)

هذا غالبًا ليتيح لك رؤية ما تحتويه جميعها.

يمكنك تحرير ذلك الملف ثم التلاعب ليتم نسخ نسختك فوق النسخة الموجودة في الحاوية.

شيء آخر يمكنك فعله هو تحريرها ثم التلاعب لتحديث المحتويات في قاعدة البيانات عبر واجهة برمجة التطبيقات. أو يمكنك القيام بذلك في Rails. في الحقيقة، قد لا يكون الأمر صعبًا جدًا لجعل بعض الذكاء الاصطناعي يكتب سكربتًا لإجراء التحديثات.

أنا لا أوصى بذلك حقًا، لكن قد يكون ممتعًا.

هل تقصد أن هذا الملف هو ما تفسره التطبيق لملء قاعدة البيانات بالقيم الفعلية؟ أعني، هذه هي “الإعدادات الافتراضية” التي يقرأها النظام؟

لا، لا أعتقد ذلك.

هذا لا يُدخل البيانات في قاعدة البيانات (أعتقد أنه سيكون بطيئًا جدًا).

أعتقد أن معظم عمليات التهيئة المتعلقة بالموقع تتم في الذاكرة من أجل السرعة، باستخدام Redis كذاكرة مؤقتة (سعيد أن يتم تصحيحي إذا كنت مخطئًا).

الشيء الوحيد الذي يُخزن في قاعدة البيانات هو تعديلاتك (في جدول translation_overrides) التي ستُقرأ عند تهيئة التطبيق أو بشكل تدريجي عندما تقوم بتعديل واحد وأنت متصل بالإنترنت.

أود أن أشير إلى بعض النقاط:

  • زيادة عدد التعديلات بشكل كبير قد يطيل زمن تهيئة التطبيق (لست متأكدًا ما إذا قام أحد باختباره).
  • قد تصبح هذه مصدر إزعاج إداري مع تطور Discourse لكنه يحافظ على اصطلاحه الخاص. أنت تخلق لنفسك عبئًا هنا.
  • نظرًا لأنه الآن يُعتبر منصة منتديات مشهورة جدًا، يستخدم الكثير من الناس على الأقل موقع Discourse واحدًا ويعتادون على الاصطلاح، لذلك ربما عليك أن تفكر في عدم إرباك المستخدمين بتغيير ما اعتادوا عليه سابقًا إلى المعايير السابقة.

انظر أيضًا:

هذا يوحي بأن كل فئة لها مديروها، عنوان URL، الإعدادات، الهدف…، على سبيل المثال، Meta هو منتدى. ليس مكونًا من عدة منتديات… لست متأكدًا حقًا كيف ستُجادل بذلك؟ لكنني أبتعد عن الموضوع.

[اقتباس=“alkah3st، المشاركة:7، الموضوع:366925”]
هذا الملف هو ما تفسره التطبيق لملء قاعدة البيانات بالقيم الفعلية
[/اقتباس]

لا.

[اقتباس=“alkah3st، المشاركة:7، الموضوع:366925”]
أي أن هذا هو “القيم الافتراضية” التي يقرأها النظام
[/اقتباس]

نعم.

لذا إذا أردت تغييرها جميعًا، وهو فكرة سيئة، يمكنك تعديل ذلك الملف، وضعه في /var/discourse/shared/standalone/أيا كان

ثم أضف أمر تنفيذ إلى app.yml الذي ينسخه من /shared/أيا كان إلى /var/www/discourse/config/locales/

لكن ستحتاج أيضًا إلى مراقبة الالتزامات لترى إذا تم تغييره أبدًا حتى تتمكن من إضافة كل ما تم تغييره.

لذا، قد يكون طريقة API أو Rails، التي تضع القيم في قاعدة البيانات، أفضل.

على نحو محترم، أنتم لا تعرفون حالتي في الاستخدام. قولكم بأنه “فكرة سيئة” أو أنني قد أضر بتجربة المستخدم دون معرفة السبب وراء ما أفعله يفترض أنني أفعله بجهل. لست مهتمًا بالدخول في نقاش حول التصنيف أو تجربة المستخدم. بالنسبة لحالتي وجمهوري، فإن المصطلحات التي يستخدمها Discourse لوصف أنواع المحتوى الخاصة به لا معنى لها.

لذا لإعادة التلخيص:

  • يقرأ Discourse هذا الملف لملء تسمياته بشكل افتراضي؛ أي تغييرات أجريها في الترجمة تتجاوز ذلك وتُحفظ في قاعدة البيانات. لذا فإن الطريقة الأكثر كفاءة لتغيير هذه المصطلحات عبر الموقع هي ببساطة تغيير هذا الملف ونقله إلى مجلد /locales/.
  • يبدو أن الاهتمام الوحيد هنا هو إذا تم تحديث ذلك الملف بواسطة النواة. أفترض أن النصوص الجديدة ستُقرأ من النسخة /standalone/ من الملف بدلاً من ملفي، لذا سأحتاج إلى تحديث ملفي لاستيعاب ذلك. لست متأكدًا من مدى تأثير الأداء في هذه الحالة، حيث إن قاعدة البيانات ليست معنية والأمر يقتصر على القراءة من ملف؟

شكرًا.

إعجاب واحد (1)

هذه طريقة واحدة للقيام بذلك. ستحتاج إلى تعديل ملف app.yml الخاص بك ليقوم بذلك في كل مرة تبني حاوية جديدة.

إذا قمت بما وصفته أعلاه، فإن إصدارك سيدخل في تعارض مع الإصدار المقدم مع الإصدار الحالي. النسخة الموجودة في دليل locales هو ما أعتقد أنك تقصده بـ “النسخة المستقلة”. لذا، إذا قمت بذلك، فسيختفي في النهاية بعض المحتويات، إلا إذا راقبته عند تغييره. في أسوأ الأحوال، سترى فقط اسم الشيء المفقود، لذا ربما لن تهتم. لن يتسبب ذلك في تعطل، فقط سيبدو مربكًا.

أقول إنه فكرة سيئة لأنه يمكن أن يسبب مشاكل إذا لم تفهمها، لذلك عندما تنتهي الكارثة، أنا على سجل أنني لم أوصِ بهذه التغييرات التي أخبرتك بكيفية القيام بها.

إعجاب واحد (1)

يمكنك إصدار مجموعة من أوامر sed في app.yml لأتمتة التحديثات.

بهذه الطريقة قد تكون أكثر “تحملًا للتغييرات” قليلاً.

إذا تبين أنك تغير فقط حوالي 20 مدخلاً، فسيكون من الأفضل فعل ذلك عبر الإدارة عبر الإنترنت!

تحدي مثير للاهتمام!

إعجاب واحد (1)

شكرًا على النصيحة!

يبدو أنني حصلت على معظم (إن لم يكن جميع) المراجع الظاهرة للجمهور عبر نصوص الموقع. لكنني سأحتفظ بذلك في ذهني إذا قمت بتطوير طريقة أكثر شمولية.

إعجابَين (2)

فكرة جيدة! هذا بالتأكيد أفضل من الكتابة فوق كل شيء كما اقترحت. . . . طالما أن عمليات sed هذه لا تغير أسماء النصوص!

إعجاب واحد (1)

نعم، سيحتاج المرء إلى توخي الحذر والنظر في الاختلافات! :sweat_smile:

إعجاب واحد (1)