Structuring a multilingual community

[Discourse]

This guide explains different approaches to organizing a Discourse forum for a multilingual community, including pros and cons of each method.

Required user level: Administrator

Discourse offers several ways to structure your site for a multilingual community. This guide will explore the most common approaches and their advantages and disadvantages.

This topic is no longer the source of recommended approaches to structure a multilingual community since we now recommend the use of the built-in Content Localization features in Discourse core, with optional automatic AI translations via the Discourse AI plugin. For additional details, please take a look at Content Localization - Manual and Automatic with Discourse AI.

Using categories for language separation

“Other languages” category with sub-categories

One approach is to create a main category called “Other Languages” with sub-categories for specific languages.

How to implement:

1. Create a new category called “Other Languages”
2. Add sub-categories for each language you want to support
3. Encourage users to post in the appropriate language sub-category

Pros:

• Clean separation between languages
• Ability to use category-restricted tags for additional organization within each language

Cons:

• Multilingual users need to track multiple categories with similar content
• Can lead to content silos based on language

Separate top-level categories for each language

Another approach is to create separate top-level categories for each supported language.

How to implement:

1. Create a new category for each language you want to support
2. Use a theme component like Custom Header Links to add language switching links in the header

Pros:

• Clear distinction between language sections
• Easy navigation for users who speak only one language

Cons:

• Can create a fragmented community experience
• Difficult for multilingual users to follow discussions across languages
• Can lead to content silos based on language

Using tags for language identification

Forum-wide language tags

This approach involves creating tags for each supported language and encouraging users to tag their posts accordingly.

How to implement:

1. Create tags for each language you want to support (e.g., #english, #french, #spanish)
2. Encourage users to add the appropriate language tag when creating topics
3. Optionally, use emojis in tag names for visual distinction

Pros:

• No need for separate categories
• Multilingual users can easily follow all content
• Flexible for topics that may involve multiple languages

Cons:

• Relies on user compliance for accurate tagging
• May be less intuitive for users accustomed to category-based navigation

Using separate Discourse instances

For communities with distinct language groups, using separate Discourse instances for each language can be considered.

How to implement:

1. Set up a separate Discourse instance for each language
2. Use subdomains or separate domains for each instance (e.g., en.example.com, fr.example.com)
3. Link between instances in the header or footer using a theme component like Custom Header Links

Pros:

• Complete separation of content and users by language
• Ability to customize each instance for its specific language community

Cons:

• More complex to manage multiple instances
• Difficult for multilingual users to participate across language communities
• Potential for duplicate discussions and fragmented community

Additional considerations

Localization of categories and tags

Discourse now supports localizing category names, category descriptions, and tag names via the built-in Content Localization feature. Enable content localization enabled and configure content localization supported locales in your site settings. Authorized groups can provide manual translations, or automatic translations can be configured via the Discourse AI plugin.

User language preferences

Discourse has built-in locale settings including allow user locale, set locale from accept language header, set locale from cookie, and set locale from param. These allow users to set their preferred language for the interface. When Content Localization is enabled, users will automatically see localized content based on their locale preference.

Language switcher

The content localization language switcher setting can display a language switcher in the header, allowing visitors (including anonymous users) to switch between your supported languages.

Search functionality

Ensure that users can search across all languages or filter results by specific languages.

Additional resources

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

Last edited by @pedro 2025-09-30T05:35:05Z

Last checked by @hugh 2024-07-26T00:58:56Z

Check document

Perform check on document:

[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 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

다만, 이 사용 사례는 "태그 그룹에서 태그 요구"라는 약간 다른 설정이 더 적합할 것입니다. 이 기능을 사용하는 방법은 다음과 같습니다.

• 언어 목록으로 구성된 tag_group을 생성합니다.
• 새 토픽이 게시되기 전에 이 그룹에서 한 개의 태그가 추가되도록 요구합니다.

@HAWK 저도 이 기능을 지지합니다. 언어 태그를 요구하는 것 외에도 이 기능의 활용도가 매우 많을 것이라고 생각합니다. 예를 들어, 현재 프로젝트 관리라는 이름의 태그 그룹에 #idea, #scoping, #ready, #in-progress, #celebrating, #evaluating, #done이라는 태그들이 있습니다. 특정 카테고리 내에서 사람들이 작성하는 모든 게시글에 적절한 프로젝트 관리 단계 태그를 붙이도록 요구할 수 있다면 정말 훌륭할 것입니다.

[HAWK]

@neil 의견이 어떻게 되나요? 특정 태그 그룹에서 하나의 태그만 적용하도록 강제하려면 얼마나 많은 작업이 필요할까요?

아직 세 번의 규칙을 충족하지는 않았지만, 위의 질문에 대한 답변에는 여전히 관심이 있습니다.

[JimPas]

이것은 제 포럼에도 흥미로울 것 같습니다. 우리 포럼은 영어 사용 회원이 대부분이지만, 스페인어 사용 회원도 있습니다. 우리는 항상 두 언어 사이를 오가며 번역을 하고 있습니다. 서로 다른 언어로 된 두 개의 별도 포럼을 만드는 것은 우리에게 적합한 방식이 아닙니다. 하지만 자동 번역되는 이중 언어 사이트 — 사용자가 기본 언어를 지정할 수 있는 — 것은 정말 훌륭할 것입니다!

[neil (Neil Lalonde)]

@HAWK

특정 태그 그룹에서 하나의 태그를 강제하려면 얼마나 많은 작업이 필요할까요?

태그 그룹에서 태그를 하나 이상 가져야 하는 방식을 추가하는 것은 쉬울 것입니다. 이 경우(언어 하나 선택)에는 정확히 하나의 태그를 강제하는 것이 바람직할 것 같지만, 일부 사용자는 최소 하나의 태그를 원할 수도 있다고 생각합니다(“주제에 필요한 최소 태그 수” 설정과 유사하게요). Car Talk에서 이미 이를 일부 확인할 수 있는데,在那里 사람들은 모든 자동차 제조사 및 모델 태그를 주제에 붙일 수 있지만 실제로는 그렇게 하지 않습니다. 또한 다국어 커뮤니티에서는 때때로 여러 언어가 모두 의미 있을 수 있습니다. 따라서 “특정 태그 그룹에서 최소 하나의 태그”를 구현하는 것이 더 적절할 것 같습니다.

[HAWK]

응, 그거 꽤 현명한 것 같아.

[angus (Angus McLeod)]

@neil

저는 "특정 태그 그룹에서 최소 하나의 태그"를 구현하는 쪽을 선호합니다.

이 기능을 구현하는 방법은 불리언 값 대신 숫자형 최소값으로 추가하여 더 세밀한 제어를 가능하게 하고, 동시에 최대값을 추가할 수 있는 여지를 남겨두는 것일 수 있습니다.

[neil (Neil Lalonde)]

오늘 이것을 만들었습니다. 태그 탭에 있는 카테고리별 설정입니다:

개선할 수 있는 부분은 사람들이 어떤 태그를 선택해야 하는지 어떻게 알 수 있느냐는 것입니다. 현재는 태그 그룹 이름이 표시되고 있지만, 태그를 나열하거나 목록으로 나열하기엔 너무 많을 경우 그룹 내 인기 있는 태그를 표시하는 것이 더 적절할 것입니다.

@debryc @angus 의견 주시겠습니까?

[debryc (Deborah Chang)]

너무 설레네요, 닐!

1. 설정 표시는 완벽하다고 생각합니다.
2. 어떤 태그를 선택할 수 있는지 표시가 필요하다는 데 동의합니다.

아마도 작성기(composer)의 태그 드롭다운에서 먼저 태그 그룹과 해당 태그 옵션을 표시하고, 그 다음에 인기 태그를 표시하는 방식이 좋을 것 같습니다.

또는, 오류 메시지에 "게시하기 전에 다음 태그 중 하나를 선택하세요"라는 내용을 포함하는 방법도 있습니다. 사용자가 태그 이름을 클릭하면 바로 추가할 수 있도록 말이죠!

[neil (Neil Lalonde)]

@debryc

작성기(Composer)의 태그 드롭다운에서 다른 인기 태그를 표시하기 전에, 먼저 태그 그룹과 해당 태그 옵션을 표시하는 것은 어떨까요?

저는 이 방식을 채택했습니다. 아직 태그가 선택되지 않은 경우, 태그 입력 필드가 필수 태그를 제안합니다.

[achebe]

@icaria36

기본적으로 모든 언어의 주제가 표시되었습니다. 관리자는 기본값으로 하나의 언어, 여러 언어의 조합, 또는 모든 언어를 유지하도록 설정할 수 있습니다.

태그 제목에서 가져온 언어 바를 통해 사용자는 특정 언어로 제공되는 주제를 볼 수 있습니다.

또 다른 생각:
여러 언어에 공정하려면, 사용자는 가장 편안하게 사용할 수 있는 언어로 생성/표현(원문)할 수 있어야 합니다. 그리고 독자는 가장 편안하게 읽을 수 있는 언어로 소비/읽기(번역문)할 수 있어야 합니다. 번역 과정에서 생기는 정보 손실을 최소화하기 위해 원문과 번역문을 나란히 표시하는 것이 유용할 것입니다. 번역문의 기본 버전은 자동 번역된 버전일 수 있습니다. 그리고 이후 번역문의 버전은 사용자가 기여한 개선 사항일 수 있습니다. 위키와 마찬가지로, 독자는 번역 과정에서 정보 손실이 의심될 경우 이전 버전의 번역문을 선택하여 볼 수 있습니다.

@icaria36

브라우저 감지, 가입 시 사용자가 선택한 언어, 사용자 설정 및 기타 결정할 방법을 통해 시스템이 사용자에게 표시할 언어를 결정합니다.
…
다시 말하지만, 기본값은 영어이며 관리자는 다른 조합을 정의할 수 있습니다. 사용자는 언제든지 사용자 설정으로 이동하여 보고 싶거나 무시할 언어를 설정할 수 있습니다. 사용자가 게시할 때의 기본 언어를 설정할 수 있다면 매번 언어 태그를 선택할 필요가 없어 편리할 것입니다.

사용자는 시스템이나 관리자가 내린 결정을 무시하고 소비할 언어를 선택할 수 있는 빠른 방법을 가져야 합니다 - 예를 들어 화면 우측 상단의 언어 드롭다운 메뉴를 통해 말입니다. 예를 들어, 중국을 여행 중인 영어권 게스트 사용자(로그인 안 함)는 브라우저 감지가 중국어를 지역 언어로 표시하더라도 영어로 된 텍스트를 보고 싶어 할 수 있습니다.

@icaria36

태그, 카테고리 및 그 설명을 지역화할 수 있습니다.

태그와 카테고리를 번역한다는 아이디어를 좋아합니다. 다만, 일부 기술/과학 용어는 번역이 없을 수 있으며 원어로 남아야 할 수도 있습니다.