هيكلة مجتمع متعدد اللغات

[Discourse]

يشرح هذا الدليل مختلف الأساليب لتنظيم منتدى Discourse لمجتمع متعدد اللغات، بما في ذلك مزايا وعيوب كل طريقة.

مستوى المستخدم المطلوب: المشرف

يقدم Discourse عدة طرق لهيكلة موقعك لمجتمع متعدد اللغات. سيستكشف هذا الدليل أكثر الأساليب شيوعًا ومزاياها وعيوبها.

لم يعد هذا الموضوع هو المصدر الموصى به لأساليب هيكلة مجتمع متعدد اللغات، حيث نوصي الآن باستخدام ميزات توطين المحتوى المدمجة في نواة Discourse، مع ترجمات تلقائية اختيارية عبر الذكاء الاصطناعي باستخدام إضافة Discourse AI. للحصول على تفاصيل إضافية، يرجى الاطلاع على Content Localization - Manual and Automatic with Discourse AI.

استخدام التصنيفات لفصل اللغات

تصنيف “لغات أخرى” مع تصنيفات فرعية

إحدى الطرق هي إنشاء تصنيف رئيسي يُسمى “لغات أخرى” مع تصنيفات فرعية لكل لغة محددة.

كيفية التطبيق:

1. إنشاء تصنيف جديد يُسمى “لغات أخرى”.
2. إضافة تصنيفات فرعية لكل لغة ترغب في دعمها.
3. تشجيع المستخدمين على النشر في التصنيف الفرعي المناسب للغة.

المزايا:

• فصل نظيف بين اللغات.
• إمكانية استخدام وسوم مقيدة بالتصنيف للتنظيم الإضافي داخل كل لغة.

العيوب:

• يحتاج المستخدمون متعددي اللغات إلى تتبع تصنيفات متعددة تحتوي على محتوى مشابه.
• قد يؤدي إلى إنشاء جزر معزولة للمحتوى بناءً على اللغة.

تصنيفات رئيسية منفصلة لكل لغة

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

كيفية التطبيق:

1. إنشاء تصنيف جديد لكل لغة ترغب في دعمها.
2. استخدام مكون سمة مثل Custom Header Links لإضافة روابط تبديل اللغة في الرأس.

المزايا:

• تمييز واضح بين أقسام اللغات.
• سهولة التنقل للمستخدمين الذين يتحدثون لغة واحدة فقط.

العيوب:

• قد يخلق تجربة مجتمعية مجزأة.
• صعوبة على المستخدمين متعددي اللغات متابعة المناقشات عبر اللغات.
• قد يؤدي إلى إنشاء جزر معزولة للمحتوى بناءً على اللغة.

استخدام الوسوم لتحديد اللغة

وسوم اللغة على مستوى المنتدى

تتضمن هذه الطريقة إنشاء وسوم لكل لغة مدعومة وتشجيع المستخدمين على وضع وسوم لمنشوراتهم وفقًا لذلك.

كيفية التطبيق:

1. إنشاء وسوم لكل لغة ترغب في دعمها (مثل: #english، #french، #spanish).
2. تشجيع المستخدمين على إضافة وسم اللغة المناسب عند إنشاء المواضيع.
3. اختياريًا، استخدام الرموز التعبيرية في أسماء الوسوم للتمييز البصري.

المزايا:

• لا حاجة لتصنيفات منفصلة.
• يمكن للمستخدمين متعددي اللغات متابعة جميع المحتويات بسهولة.
• مرونة للمواضيع التي قد تتضمن عدة لغات.

العيوب:

• يعتمد على امتثال المستخدمين للوسم بدقة.
• قد يكون أقل بديهية للمستخدمين المعتادين على التنقل القائم على التصنيفات.

استخدام نسخ منفصلة من Discourse

بالنسبة للمجتمعات ذات المجموعات اللغوية المتميزة، يمكن النظر في استخدام نسخ منفصلة من Discourse لكل لغة.

كيفية التطبيق:

1. إعداد نسخة منفصلة من Discourse لكل لغة.
2. استخدام نطاقات فرعية أو نطاقات منفصلة لكل نسخة (مثل: en.example.com، fr.example.com).
3. الربط بين النسخ في الرأس أو التذييل باستخدام مكون سمة مثل Custom Header Links.

المزايا:

• فصل كامل للمحتوى والمستخدمين حسب اللغة.
• إمكانية تخصيص كل نسخة لمجتمع اللغة المحدد الخاص بها.

العيوب:

• إدارة أكثر تعقيدًا لعدة نسخ.
• صعوبة على المستخدمين متعددي اللغات المشاركة عبر مجتمعات اللغات.
• احتمال تكرار المناقشات وتجزئة المجتمع.

اعتبارات إضافية

توطين التصنيفات والوسوم

يدعم Discourse الآن توطين أسماء التصنيفات، ووصف التصنيفات، وأسماء الوسوم عبر ميزة توطين المحتوى المدمجة. فعّل خيار content localization enabled وقم بتكوين content localization supported locales في إعدادات موقعك. يمكن للمجموعات المصرح لها تقديم ترجمات يدوية، أو يمكن تكوين ترجمات تلقائية عبر إضافة Discourse AI.

تفضيلات لغة المستخدم

يحتوي Discourse على إعدادات محلية مدمجة تشمل allow user locale، set locale from accept language header، set locale from cookie، وset locale from param. تسمح هذه الإعدادات للمستخدمين بتعيين لغتهم المفضلة للواجهة. عند تفعيل توطين المحتوى، سيرى المستخدمون تلقائيًا محتوى موطنًا بناءً على تفضيلهم المحلي.

مفصل اللغة

يمكن لإعداد content localization language switcher عرض مفصل للغة في الرأس، مما يسمح للزوار (بما في ذلك المستخدمون المجهولون) بالتبديل بين اللغات المدعومة.

وظيفة البحث

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

موارد إضافية

• Content Localization - Manual and Automatic with Discourse AI
• Custom Header Links
• Brand Header

[tophee (Christoph)]

I think https://community.wd.com have quite an elegant version of the “other languages” category. They use several such categories for different languages and added a language bar above the header (via css I suppose, but they forgot to add it to the mobile css).

They even managed to somehow exclude the language categories from the “all categories” page (also via CSS?) And also the “latest” page seems free of non-english topics, but that may be because there are non at the moment.

However, another downside of this solution is clearly that the illusion of beeing on, for example, a German WD forum is shattered when you click on “latest” because what you get are not the latest German posts.

[notriddle (Michael Howell)]

Is there anybody who uses completely separate instances of Discourse for multi-lingual communities? This seemed like the most obvious way to do it (especially since you can set each language-subcommunity to default to use the same language in the Discourse UI).

[swfsql (Thiago Machado Da Silva)]

I’m setting them up, but I do:

https://en.ancap.ch
https://br.ancap.ch
https://jp.ancap.ch
https://th.ancap.ch

and so on… they are in a multisite configuration

I prefer that each one has a link to each others in the Header (the https://br.ancap.ch one has)

[vitorl]

I like your approach. How you did it?

[erlend_sh (Erlend Sogge Heggen)]

There’s nothing special to @swfsql’s approach.

1. Set up a dedicated Discourse forum for each language. No need for a multisite configuration.
2. Use a theme component like Custom Header Links or Brand header theme component to create the menu you need.

[icaria36]

I would like to share some ideas about how to turn Discourse in a truly and multilingual space, equitable to speakers of dozens of languages, some of them multilingual, some of them not, some fluent in English some of them not, or not at all. In our organization we might be able to invest in the development of these features, after a good technical and community review.

The idea would be to use language tags with some customization. Posters would be able to tag their post with the relevant language so as to keep topics searchable by language.

Goal

The goal is to offer a discussion space that speakers of any language (and language combinations) can feel as theirs, as opposed to an English forum with a multilingual corner or a forum split in many languages becoming effectively many separate forums.

Language tags

For this, the main building block would be a tag specific to languages. This tag would be required for all topics, and it would default to English. Topics in non-English languages would be tagged accordingly.

Languages displayed

By default, the topic would display topics in all languages. Admins could configure as default just one language, a combination of languages, keep all languages…

Through a language bar that pulls from the tag titles, users could see the topics available in a specific language.

Language user preferences

Through browser detection, language chosen by the user during registration, user preferences, and other means to be determined, the system would decide which language(s) are displayed to a user.

Again, the default would be English and admins could define other combinations. The user could always go to their user preferences and set the language(s) they want to see / ignore. It would be of further use if the users could set the default language of posting, to save them from selecting a language tag each time.

Localization of categories and tags

Tags, categories and their descriptions could be localized.

Search filter

Users could search in all languages or filter for their languages defined in their profiles.

Progressive implementation

Not all these features would be deployed at once, and maybe not all these features need to be in just one plugin. It would be preferred to test and build incrementally, and start with a minimum viable product that a multilingual community could start testing.

Does this approach sound like the right one? Are there other ideas for how we could more effectively build the multilingual element of this discussion space?

[angus (Angus McLeod)]

@icaria36

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

ما الذي يجعل المجتمع يشعر بأنه مجتمع؟ في وسيط يعتمد إلى حد كبير على النصوص، يبدو أن القدرة على فهم التواصل النصي بين الأعضاء الآخرين أمر جوهري، أي أتساءل عما إذا كان من الممكن التغلب تمامًا على المأزقين اللذين ذكرتهما (‘العزلة’ أو ‘التكريم الرمزي’) في وسيط يعتمد إلى حد كبير على النصوص (دون ترجمة آلية مثالية).

المجتمع الذي يتبادر إلى ذهني هنا هو https://discourse.mozilla.org

@icaria36

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

حاليًا، لدينا خيار إلزام عدد معين من العلامات على المنشور في فئة معينة، انظر The option to enforce tagging (إعداد الفئة “الحد الأدنى لعدد العلامات المطلوبة في الموضوع”).

ومع ذلك، فإن حالة الاستخدام هذه ستستفيد من إعداد مختلف قليلاً وهو “تطلب علامة من مجموعة علامات”. الطريقة التي ستستخدم بها هذا هي:

• إنشاء مجموعة علامات (tag_group) تحتوي على قائمة محددة من اللغات
• إلزام كل موضوع جديد بإضافة علامة واحدة من هذه المجموعة قبل نشره.

@HAWK أنا فضولي لمعرفة ما إذا كانت بعض حالات الاستخدام الأخرى لهذا النوع من الإعدادات التي ذكرتها في الموضوع المرتبط ستستفيد من شيء مشابه (أو هل هي مغطاة بالكامل بواسطة إعداد “الحد الأدنى لعدد العلامات المطلوبة في الموضوع” الحالي)؟

@icaria36

من خلال شريط لغة يستمد عناوين العلامات، يمكن للمستخدمين رؤية المواضيع المتاحة بلغة معينة.

يمكن تنفيذ ذلك بطريقة تكون مفيدة بشكل عام: مكون تنقل للعلامات يعرض العلامات من مجموعة معينة.

@icaria36

من خلال اكتشاف المتصفح، واللغة التي يختارها المستخدم أثناء التسجيل، وتفضيلات المستخدم، وطرق أخرى سيتم تحديدها، سيقرر النظام أي اللغة (اللغات) يتم عرضها للمستخدم.

يسمح نظام Discourse حاليًا للمستخدم بتعيين موقعه اللغوي (يتم التبديل بينه عبر إعداد الموقع “السماح للمستخدم بتعيين موقعه اللغوي”)، ويقوم باكتشاف الموقع اللغوي تلقائيًا، ويتم التبديل بينه عبر إعداد الموقع “تعيين الموقع اللغوي من رأس قبول اللغة”. هناك ثلاثة سياقات لاكتشاف تلقائي:

• الضيوف (المتصفح والرؤوس)
• التسجيلات (نفس الشيء)
• الدعوات (نفس الشيء) - ربما هناك مشكلة هنا؟ (انظر) (@schungx?)

ربما تكون التحسينان اللذان يمكن إجراؤهما هنا هما:

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

@icaria36

يمكن ترجمة العلامات والفئات ووصفاتها.

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

كما أن ترجمة وصف الفئات والعلامات أسهل من ترجمة المواضيع بأكملها. من الناحية التقنية، هذا ممكن، لكنه لم يتم تجربته بعد. انظر المزيد. @erlend_sh هل تعرف أي عمل إضافي أو أمثلة على ذلك؟

@icaria36

يمكن للمستخدمين البحث في جميع اللغات أو تصفية النتائج حسب لغاتهم المحددة في ملفاتهم الشخصية.

إذا كانت جميع علامات اللغة موجودة في مجموعة علامات واحدة، فإن الخطوة هنا هي إضافة مرشح علامة خاص بمجموعة العلامات إلى صفحة البحث المتقدم.

لخص التغييرات التي ذكرتها أعلاه:

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

[schungx (Stephen Chung)]

الدعوات (نفس المرجع) - هل هناك مشكلة محتملة هنا؟ (انظر 1) (@schungx؟)

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

لا توجد حاليًا طريقة لتحديد لغة الدعوات…

[HAWK]

@angus

أنا فضولي لمعرفة ما إذا كانت بعض حالات الاستخدام الأخرى لهذا النوع من الإعدادات التي ذكرتها في الموضوع المرتبط ستستفيد من شيء مماثل (أو ما إذا كانت مغطاة بالكامل من خلال إعداد “الحد الأدنى لعدد الوسوم المطلوبة في الموضوع” الحالي)؟

لا يخطر ببال شيء، لكننا نلاحظ ظهور مجتمعات متعددة اللغات بشكل متزايد، لذا إذا كان هذا سيبسط حالة الاستخدام تلك، فأعتقد أن الطلب مشروع.

[debryc (Deborah Chang)]

@angus

ومع ذلك، فإن هذه الحالة الاستخدامية ستستفيد من إعداد مختلف قليلاً وهو “تطلب وسمًا من مجموعة وسوم”. الطريقة التي ستستخدم بها هذا الإعداد هي:

• إنشاء مجموعة وسوم تحتوي على قائمة محددة من اللغات
• اشتراط إضافة وسم واحد على الأقل من هذه المجموعة لكل موضوع جديد قبل نشره.

@HAWK أنا أيضًا أؤيد هذه الميزة. يمكنني رؤية العديد من الاستخدامات لها بالإضافة إلى اشتراط وسوم اللغات. على سبيل المثال، لدينا حاليًا مجموعة وسوم تسمى “إدارة المشاريع” تحتوي على وسوم مثل #فكرة، #تحديد_النطاق، #جاهز، #قيد_التنفيذ، #احتفال، #تقييم، #مكتمل. سيكون من الرائع إلزام المستخدمين بوضع الوسم الصحيح لكل منشور ينشرونه وفقًا لمرحلة إدارة المشاريع المناسبة ضمن فئات معينة.

[HAWK]

@neil ما هي آراؤك؟ كم من العمل سيتطلب فرض وسم واحد من مجموعة وسوم محددة؟

لاحظ أننا لم نصل بعد إلى قاعدة الثلاثة، لكنني ما زلت مهتمًا بالإجابات على السؤال أعلاه.

[JimPas]

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

[neil (Neil Lalonde)]

@HAWK، المشاركة: 12، الموضوع: 73225

كم من العمل سيتطلب فرض وضع علامة واحدة من مجموعة علامات محددة؟

سيكون من السهل إضافة طريقة لفرض وجود علامة من مجموعة علامات. أظن أنه في هذه الحالة (اختيار لغة واحدة) نريد فرض علامة واحدة بالضبط، لكنني أعتقد أن بعض الأشخاص قد يرغبون في علامة واحدة على الأقل (مشابهة لإعداد “الحد الأدنى لعدد العلامات المطلوبة في الموضوع”). أفضل تنفيذ خيار “علامة واحدة على الأقل من مجموعة علامات محددة” لأننا نستطيع رؤية ذلك عمليًا بالفعل في Car Talk، حيث من الممكن للمستخدمين وضع جميع علامات مصنعي السيارات وموديلاتها، لكن هذا لا يحدث. أيضًا، في مجتمع متعدد اللغات، قد يكون وجود أكثر من لغة منطقيًا في بعض الأحيان.

[HAWK]

نعم، يبدو ذلك ذكياً من وجهة نظري.

[angus (Angus McLeod)]

@neil

أفضل تنفيذ شرط “على الأقل وسم واحد من مجموعة وسوم محددة”

ربما تكون الطريقة المناسبة لذلك هي إضافته كحد أدنى رقمي بدلاً من قيمة منطقية (boolean)، وذلك لمنح تحكم أكثر دقة، ولترك الباب مفتوحًا لإضافة حد أقصى أيضًا.

[neil (Neil Lalonde)]

لقد بنيت هذا اليوم. إنه إعداد حسب الفئة في علامة التبويب الوسوم:

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

@debryc @angus ما رأيكم؟

[debryc (Deborah Chang)]

هذا مثير جدًا يا نيل!

1. أعتقد أن عرض الإعدادات مثالي.
2. أتفق على ضرورة وجود مؤشر يوضح الوسوم المتاحة للاختيار منها.

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

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

[neil (Neil Lalonde)]

@debryc

ربما في قائمة التنقل الموسومة للمؤلف، يتم عرض مجموعة الوسوم وخياراتها أولاً، قبل عرض الوسوم الشائعة الأخرى.

اتبعتُ هذا النهج. سيتم اقتراح الوسوم المطلوبة من خلال مدخل الوسوم إذا لم يتم اختيار واحدة بعد.

[achebe]

@icaria36

افتراضيًا، ستعرض المواضيع جميع اللغات. يمكن للمسؤولين تكوين الإعداد الافتراضي ليكون لغة واحدة فقط، أو مجموعة من اللغات، أو الاحتفاظ بجميع اللغات…

من خلال شريط لغوي يستمد بياناته من عناوين الوسوم، يمكن للمستخدمين رؤية المواضيع المتاحة بلغة معينة.

فكرة أخرى:
لكي يكون النظام عادلًا تجاه لغات متعددة، يجب أن يتمكن المستخدم من إنتاج/التعبير (النص المصدر) باللغة الأكثر راحة له. وفي الوقت نفسه، يجب أن يتمكن القارئ من الاستهلاك/القراءة باللغة الأكثر راحة له (النص المترجم). ولتقليل مشكلات الفقدان في الترجمة، سيكون من المفيد عرض النص المصدر والنص المترجم جنبًا إلى جنب. يمكن أن تكون النسخة الأساسية للنص المترجم نسخة مترجمة آليًا. أما النسخ اللاحقة من النص المترجم فيمكن أن تكون تحسينات يساهم بها المستخدمون. تمامًا مثل الويكي، يمكن للقراء اختيار رؤية النسخ السابقة من النص المترجم إذا اشتبهوا في وجود مشكلات فقدان في الترجمة.

@icaria36

من خلال كشف المتصفح، واللغة التي يختارها المستخدم أثناء التسجيل، وتفضيلات المستخدم، وطرق أخرى سيتم تحديدها، سيقرر النظام أي لغة/اللغات سيتم عرضها للمستخدم.
…
مرة أخرى، ستكون اللغة الافتراضية هي الإنجليزية، ويمكن للمسؤولين تعريف مجموعات أخرى. يمكن للمستخدم دائمًا الانتقال إلى تفضيلات المستخدم الخاصة به وتحديد اللغة/اللغات التي يريد رؤيتها/تجاهلها. سيكون من المفيد أيضًا إذا تمكن المستخدمون من تعيين لغة النشر الافتراضية، لتوفير عليهم اختيار وسم اللغة في كل مرة.

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

@icaria36

يمكن توطين الوسوم والفئات ووصفاتها.

أحب فكرة ترجمة الوسوم والفئات. ومع ذلك، قد لا تتوفر ترجمات لبعض المصطلحات التقنية/العلمية، وقد تحتاج إلى البقاء باللغة المصدر.