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

[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

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.

What is it that makes a community feel like a community? In a largely text-based medium, being able to understand the text-based communication of the other members seems key, i.e. I wonder whether it’s possible to completely overcome the two pitfalls you mention (‘siloisation’ or ‘tokenism’) in a largely text-based medium (without perfect auto-translation).

One community that comes to mind here is https://discourse.mozilla.org

@icaria36

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.

Currently we have the option of requiring a certain number of tags on a post in a category, see The option to enforce tagging (Category setting “Minimum number of tags required in a topic”).

However, this use case would benefit from a slightly different setting “Require tag from a tag group”. The way you would use this would be to

• Create a tag_group with a set list of languages
• Require each new topic to have one tag added from this group before it is posted.

@HAWK I’m curious if some of the other use cases for this type of setting you mentioned in the linked topic would benefit from something similar (or if they are entirely covered by the existing “Minimum number of tags required in a topic” setting)?

@icaria36

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

This could be done in a fashion that could be generally useful: A tag navigation component that displays tags from a specific group.

@icaria36

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.

Discourse currently allows the user to set their locale (toggled by the allow user locale site setting) and does auto-detection of locale, toggled by the site setting set locale from accept language header. There are three auto-detection contexts:

• Guests (browser and headers)
• Signups (ibid)
• Invites (ibid) - there is perhaps an issue with this? (see) (@schungx?)

Perhaps the two improvements that could be made here would be to:

• add a setting to allow a user to manually set their locale in the signup form
• add a ‘locale switcher’ for guests, similar to facebook’s (see bottom bar of signup page). I’ve actually made this for different project, but haven’t yet turned it into a plugin.

@icaria36

Tags, categories and their descriptions could be localized.

I find this one really interesting, and think it would definitely be interesting to try. The tags, categories and category descriptions are what a user often reads first before reading an actual topic. These often contribute to the user’s sense of the community. If they see words and descriptions that they relate to, they’re more likely to relate to the community itself. So even if there’s a different language once the user gets into the topic, their interest and sense for the community is already primed.

It is also easier to localize category descriptions and tags than it is to localize entire topics. Technically speaking, this is doable, but hasn’t yet been tried. See further. @erlend_sh Do you know of any further work on / examples of this?

@icaria36

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

If the language tags are all in a single tag_group, the move here would be to add a tag-group-specific tag filter to the advanced search page.

To summarise the changes I’ve mentioned above:

• A “Require tag from a tag group” site or category setting
• A tag navigation component that displays tags from a specific group
• A setting to allow a user to manually set their locale in the signup form
• A ‘locale switcher’ for guests
• Localisation of tags, category names and category descriptions
• Add a tag-group-specific tag filter to the advanced search page

[schungx (Stephen Chung)]

Invites (ibid) - there is perhaps an issue with this? (see 1) (@schungx?)

As far as I can tell invite emails will be sent in the site default language, but the user will get his/her locale once signing in.

There is currently no way to specify the language of invites…

[HAWK]

@angus

I’m curious if some of the other use cases for this type of setting you mentioned in the linked topic would benefit from something similar (or if they are entirely covered by the existing “Minimum number of tags required in a topic” setting)?

Nothing springs to mind but we’re seeing more and more multilingual communities so if that is going to simplify that particular use case then I think it’s a legit ask.

[debryc (Deborah Chang)]

@angus

However, this use case would benefit from a slightly different setting “Require tag from a tag group”. The way you would use this would be to

• Create a tag_group with a set list of languages
• Require each new topic to have one tag added from this group before it is posted.

@HAWK I also support this feature. I can see so many uses for this in addition to requiring language tags. For example, we currently have a tag group called project management with tags #idea, #scoping, #ready, #in-progress, #celebrating, #evaluating, #done. It would be incredible to require people to correctly tag every post they make with the appropriate project management stage within certain categories.

[HAWK]

@neil what are your thoughts? How much work would be involved in enforcing one tag from a specific tag group be?

Note that we haven’t hit the rule of three yet, but I’m still interested in answers to the above.

[JimPas]

This would sound interesting for my forum also. We mostly have English-speaking members, but also Spanish-speaking members. We’re always translating back and forth. The thought of two separate forums (different languages) is not the way to go for us. But an auto-translated bi-lingual site - user-specified default language - would be great!

[neil (Neil Lalonde)]

@HAWK

How much work would be involved in enforcing one tag from a specific tag group be?

It would be easy to add a way to enforce having a tag from a tag group. I guess in this case (choose one language) we want to enforce exactly one tag, but I’m guessing some people might want at least one tag (similar to the “Minimum number of tags required in a topic” setting). I’d rather implement “at least one tag from a specific tag group” since we can kind of see this in action already at Car Talk where it’s possible for people to tag their topics with all the car make and model tags, but it doesn’t happen. Also in a multilingual community, more than one language can make sense sometimes.

[HAWK]

Yup, that sounds smart to me.

[angus (Angus McLeod)]

@neil

I’d rather implement “at least one tag from a specific tag group”

Perhaps the way to do this would be to add it as a numerical minimum, rather than a boolean, to give more granualar control, and also leave the door open to adding a maximum?

[neil (Neil Lalonde)]

I built this today. It’s a per-category setting in the Tags tab:

Something that can be improved is how people know what tags they have to choose from. Right now it’s showing the tag group name, but it should probably list the tags, or the most popular tags in the group in the case that there are too many to list.

@debryc @angus Thoughts?

[debryc (Deborah Chang)]

This is so exciting, Neil!

1. I think the settings display is perfect.
2. I agree that there needs to be some indication of what tags they have to choose from.

Perhaps in the tags dropdown of the composer, display the tag group and its tag options first, before displaying other popular tags.

Or, perhaps the error message includes a “choose one of the following tags before posting” message. Users could click on the tag name to add it!

[neil (Neil Lalonde)]

@debryc

Perhaps in the tags dropdown of the composer, display the tag group and its tag options first, before displaying other popular tags.

I went with this approach. The required tags will be suggested by the tag input if one hasn’t been chosen yet.

[achebe]

@icaria36

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.

Another thought:
To be equitable to multiple languages, a user must be able to produce/express (source text) in the language most comfortable to him/her. And the reader must be able to consume/read in the language most comfortable to him/her (translated text). To minimize lost-in-translation issues, it would be beneficial to show side-by-side both the source text and the translated text. The base version of the translated text could be an auto-translated version. And subsequent versions of translated text could be user-contributed improvements. Just like a wiki, readers could choose to see earlier versions of translated text if they suspect lost-in-translation issues.

@icaria36

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.

User must have a quick way to choose the consumed language (to over-ride any decisions made by the system or admin) - say from a language drop-down from top-right corner of screen. For e.g., an English speaking guest-user (not logged in) traveling to China might want to see text in English though browser-detection may indicate Chinese as local language.

@icaria36

Tags, categories and their descriptions could be localized.

Love this idea of translating tags and categories. Although, some technical/scientific terms may not have translations and may need to remain in source language.