أتابع طلبي الأصلي بمخطط تنفيذي ملموس — ويسعدني المساعدة في تقديم طلب سحب (PR) إذا بدا الاتجاه معقولاً.
المشكلة: قوالب مواضيع الفئات (categories.topic_template) غير قابلة للترجمة. نموذج CategoryLocalization وقلق Localizable يغطيان فقط name وdescription، ويتخطى خط أنابيب الترجمة التلقائية للمحتوى بالذكاء الاصطناعي القوالب وفقاً لذلك. يقوم المحرر دائماً بإدراج قالب اللغة الأساسية، بغض النظر عن لغة المستخدم.
حالة الاستخدام: ندير مجتمعاً ثنائي اللغة (ألماني/إنجليزي) على Discourse مع الترجمة التلقائية للمحتوى بالذكاء الاصطناعي في بيئة الإنتاج. ترجمة المشاركات/المواضيع تعمل بشكل ممتاز، لكن قوالب الفئات للمحتوى المهيكّل — نماذج تقارير الأخطاء مع قوائم التحقق، وتدفقات تأكيد الحضور عبر BBCode [event] — لا يمكن تكرارها لكل لغة، لأن BBCode الوظيفي يجب أن يوجد مرة واحدة بالضبط. الحل الوحيد هو قالب واحد بعلامات ثنائية اللغة غير مريحة (“App-Version / App version:”)، مما يضر بقابلية القراءة للجميع.
الاقتراح:
- إضافة عمود نصي قابل للقيمة الفارغة
topic_templateإلىcategory_localizations - المحرر: إذا كان هناك ترجمة للغة الحالية للمستخدم، استخدم قالبها؛ وإلا فاعتمد على
category.topic_template - عرض/حفظ الحقل لكل لغة في واجهة إدارة الفئات (بجانب الاسم/الوصف المحلي)
- تضمين
topic_templateفي خط أنابيب الترجمة التلقائية للمحتوى بالذكاء الاصطناعي عند ترجمة الفئات (مثلdescription)
الهجرة بسيطة (add_column :category_localizations, :topic_template, :text)؛ العمل الرئيسي هو منطق اختيار المحرر وواجهة الإدارة.
البدائل التي تم النظر فيها:
- قالب واحد ثنائي اللغة (الحل الحالي) — ينهار مع كتل BBCode الوظيفية
- مكوّن سمة يحقن نصاً لكل لغة — هش، بدون تحقق على مستوى الخادم، يكسر محررات الواجهة البرمجية (API)