构建多语言社区

:bookmark: 本指南介绍了为多语言社区组织 Discourse 论坛的不同方法,包括每种方法的优缺点。

:person_raising_hand: 所需用户等级:管理员

Discourse 提供了多种方式来为您的多语言社区构建站点结构。本指南将探讨最常见的几种方法及其优缺点。

:spiral_notepad: 由于我们现在推荐使用 Discourse 核心内置的 内容本地化 功能(可选通过 Discourse AI 插件实现自动 AI 翻译),本主题已不再作为多语言社区结构推荐方法的来源。更多详细信息,请参阅 Content Localization - Manual and Automatic with Discourse AI

使用分类进行语言分离

“其他语言”分类及其子分类

一种方法是创建一个名为“其他语言”的主分类,并为特定语言创建子分类。

实施步骤:

  1. 创建一个名为“其他语言”的新分类
  2. 为每种您希望支持的语言添加子分类
  3. 鼓励用户在相应的语言子分类中发帖

优点:

  • 语言之间界限清晰
  • 可在每个语言内部使用分类限制标签进行进一步组织

缺点:

  • 多语言用户需要跟踪多个包含相似内容的分类
  • 可能导致按语言划分的内容孤岛

为每种语言设立独立的顶级分类

另一种方法是为每种支持的语言创建独立的顶级分类。

实施步骤:

  1. 为每种您希望支持的语言创建一个新分类
  2. 使用如 自定义头部链接 这样的主题组件,在头部添加语言切换链接

优点:

  • 语言板块区分明确
  • 对于只说一种语言的用户而言导航便捷

缺点:

  • 可能导致社区体验碎片化
  • 多语言用户难以跨语言跟踪讨论
  • 可能导致按语言划分的内容孤岛

使用标签进行语言标识

全站语言标签

这种方法涉及为每种支持的语言创建标签,并鼓励用户相应地为其帖子添加标签。

实施步骤:

  1. 为每种您希望支持的语言创建标签(例如 #english、#french、#spanish
  2. 鼓励用户在创建主题时添加相应的语言标签
  3. (可选)在标签名称中使用表情符号以实现视觉区分

优点:

  • 无需创建独立的分类
  • 多语言用户可以轻松关注所有内容
  • 对于可能涉及多种语言的主题具有灵活性

缺点:

  • 依赖用户遵守规则以确保标签准确
  • 对于习惯基于分类导航的用户来说可能不够直观

使用独立的 Discourse 实例

对于具有明显语言群体划分的社区,可以考虑为每种语言使用独立的 Discourse 实例。

实施步骤:

  1. 为每种语言设置一个独立的 Discourse 实例
  2. 为每个实例使用子域名或独立域名(例如 en.example.comfr.example.com
  3. 使用如 自定义头部链接 这样的主题组件,在头部或页脚建立实例间的链接

优点:

  • 按语言完全分离内容和用户
  • 可为每个实例针对其特定语言社区进行定制

缺点:

  • 管理多个实例更为复杂
  • 多语言用户难以跨语言社区参与
  • 可能导致讨论重复和社区碎片化

其他考虑因素

分类和标签的本地化

Discourse 现在支持通过内置的内容本地化功能对分类名称、分类描述和标签名称进行本地化。请在站点设置中启用“启用内容本地化”并配置“支持的内容本地化语言”。授权组可提供手动翻译,或通过 Discourse AI 插件配置自动翻译。

用户语言偏好

Discourse 内置了多种语言设置,包括“允许用户设置语言”、“根据 Accept-Language 请求头设置语言”、“根据 Cookie 设置语言”以及“根据参数设置语言”。这些设置允许用户设置其首选界面语言。启用内容本地化后,用户将根据其语言偏好自动查看本地化内容。

语言切换器

“内容本地化语言切换器”设置可在头部显示语言切换器,允许访客(包括匿名用户)在您支持的语言之间切换。

搜索功能

确保用户能够跨所有语言进行搜索,或按特定语言筛选结果。

其他资源

20 个赞

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.

8 个赞

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).

2 个赞

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)

6 个赞

I like your approach. How you did it?

1 个赞

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.
6 个赞

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?

9 个赞

是什么让一个社区真正具有“社区感”?在一个主要基于文本的媒介中,能够理解其他成员的文本交流似乎至关重要。因此,我想知道:在没有完美自动翻译的情况下,是否有可能在一个主要基于文本的媒介中完全克服你提到的两个陷阱(“孤岛化”或“象征性包容”)?

这里我想到的一个社区是 https://discourse.mozilla.org

目前,我们可以在某个分类中要求帖子必须包含一定数量的标签,参见 https://meta.discourse.org/t/the-option-to-enforce-tagging/69527(分类设置“主题中所需的最小标签数量”)。

然而,这个用例将从一个略有不同的设置“要求从标签组中选择标签”中受益。使用方式如下:

  • 创建一个包含语言列表的 tag_group(标签组)
  • 要求每个新主题在发布前必须从该组中添加一个标签。

@HAWK 我很好奇,你在所链接的主题中提到的该设置的其他一些用例是否也能从类似的功能中受益(或者它们是否已经完全被现有的“主题中所需的最小标签数量”设置所覆盖)?

这可以以一种具有普遍实用价值的方式实现:一个显示特定标签组中标签的标签导航组件。

Discourse 目前允许用户设置其区域设置(通过站点设置“允许用户设置区域设置”切换),并支持区域设置的自动检测(通过站点设置“从 accept-language 头部设置区域设置”切换)。自动检测有三种上下文:

  • 访客(浏览器和头部信息)
  • 注册(同上)
  • 邀请(同上)——这里可能存在一个问题?(参见)(@schungx?)

也许这里可以进行的两项改进是:

  • 添加一个设置,允许用户在注册表单中手动设置其区域设置
  • 为访客添加一个“区域设置切换器”,类似于 Facebook 的(参见注册页面底部的栏)。我实际上已经为不同的项目制作了这样一个功能,但尚未将其转化为插件。

我觉得这一点非常有趣,认为绝对值得尝试。标签、分类和分类描述是用户通常在阅读实际主题之前首先看到的内容。它们往往会影响用户对社区的感知。如果用户看到与自己相关的词汇和描述,他们就更有可能认同这个社区本身。因此,即使用户进入主题后内容使用不同的语言,他们对社区的兴趣和归属感已经得到了初步培养。

此外,本地化分类描述和标签比本地化整个主题要容易得多。从技术角度来看,这是可行的,但尚未有人尝试过。详见@erlend_sh 你是否了解关于此方面的进一步工作或示例?

如果所有语言标签都位于同一个 tag_group(标签组)中,那么接下来的改进就是在高级搜索页面添加一个针对特定标签组的标签筛选器。

总结一下我上面提到的更改:

  • 添加“要求从标签组中选择标签”的站点或分类设置
  • 添加一个显示特定标签组中标签的标签导航组件
  • 添加允许用户在注册表单中手动设置区域设置的选项
  • 为访客添加“区域设置切换器”
  • 对标签、分类名称和分类描述进行本地化
  • 在高级搜索页面添加针对特定标签组的标签筛选器
10 个赞

邀请(同上)——这里可能有个问题?(参见 1)(@schungx?)

据我所知,邀请邮件将使用网站默认语言发送,但用户登录后会获得其个人语言设置。

目前无法指定邀请邮件的语言…

2 个赞

我一时想不出具体的例子,但我们看到越来越多的多语言社区。如果这能简化该特定用例,那么我认为这是一个合理的需求。

8 个赞

@HAWK 我也支持此功能。除了要求使用语言标签外,我看到了许多其他用途。例如,我们目前有一个名为“项目管理”的标签组,包含标签 #idea(想法)、#scoping(范围界定)、#ready(就绪)、in-progress(进行中)、#celebrating(庆祝)、#evaluating(评估)和 done(完成)。如果能在特定分类中要求用户为每篇帖子正确添加对应的项目管理阶段标签,那将非常棒。

3 个赞

@neil 你怎么看?强制要求从某个标签组中选择一个标签需要多少工作量?

请注意,我们尚未达到“三次法则”,但我仍然对上述问题的答案很感兴趣。

7 个赞

这听起来对我的论坛也很有吸引力。我们的成员主要是英语使用者,但也有西班牙语使用者。我们一直在互相翻译。将论坛分为两个独立的语言版本对我们来说并不是好的选择。但是,一个自动翻译的双语网站——用户指定默认语言——那就太棒了!

4 个赞

添加强制要求从标签组中选择标签的功能很容易。我想在这种情况下(选择一种语言),我们需要强制恰好一个标签,但我猜有些人可能希望至少一个标签(类似于“主题中所需的最小标签数”设置)。我倾向于实现“从特定标签组中至少选择一个标签”,因为我们在 Car Talk 已经可以看到类似的效果:用户可以用所有汽车品牌及型号标签来标记主题,但实际上这种情况很少发生。此外,在多语言社区中,有时选择多种语言也是有意义的。

13 个赞

没错,我觉得这听起来很明智。

6 个赞

也许实现这一功能的方式是将其作为一个数值最小值(而非布尔值)添加,以提供更细粒度的控制,同时也为将来添加最大值预留空间。

4 个赞

我今天构建了这个功能。它是在“标签”选项卡中的按类别设置:

可以改进的一点是,用户如何知道有哪些标签可供选择。目前显示的是标签组的名称,但更好的做法是列出该组中的标签,或者在标签数量过多时,列出该组中最受欢迎的标签。

@debryc @angus 你们怎么看?

11 个赞

这太令人兴奋了,尼尔!

  1. 我认为设置界面非常完美。
  2. 我同意需要提供一些提示,告知用户有哪些标签可供选择。

或许可以在发布器的标签下拉菜单中,先显示标签组及其标签选项,然后再显示其他热门标签。

或者,错误消息中可以包含“请在发布前选择以下标签之一”的提示。用户可以直接点击标签名称来添加它!

5 个赞

我采用了这种方法。如果尚未选择标签,标签输入框将自动建议所需的标签。

6 个赞

另一个想法:
为了公平对待多种语言,用户必须能够使用自己最舒适的语言进行创作/表达(源文本),而读者也必须能够使用自己最舒适的语言进行阅读/消费(翻译文本)。为了尽量减少“翻译失真”的问题,最好能并排显示源文本和翻译文本。翻译文本的基础版本可以是自动翻译版本,而后续版本则可以是用户贡献的改进内容。就像维基百科一样,如果读者怀疑存在翻译失真问题,可以选择查看翻译文本的早期版本。

用户必须能够快速选择要消费的语言(以覆盖系统或管理员所做的任何决定)——例如,通过屏幕右上角的语言下拉菜单。例如,一位正在中国旅行的英语母语访客用户(未登录)可能希望看到英语文本,尽管浏览器检测可能显示当地语言为中文。

非常喜欢这个翻译标签和分类的想法。不过,一些技术或科学术语可能没有对应的翻译,可能需要保留原文语言。

3 个赞