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

Для этого основным строительным блоком стал бы тег, специфичный для языков. Этот тег был бы обязательным для всех тем, а по умолчанию устанавливался бы английский язык. Темы на других языках помечались бы соответствующим образом.

В настоящее время у нас есть возможность требовать определённое количество тегов в публикации в категории, см. The option to enforce tagging (настройка категории «Минимальное количество требуемых тегов в теме»).

Однако данный случай использования выиграл бы от немного другой настройки «Требовать тег из группы тегов». Использование этого механизма выглядело бы следующим образом:

• Создать группу тегов (tag_group) с фиксированным списком языков;
• Требовать, чтобы каждая новая тема имела хотя бы один тег из этой группы перед публикацией.

@HAWK Мне интересно, могли бы некоторые из других случаев использования этого типа настройки, которые вы упомянули в связанной теме, выиграть от чего-то подобного (или они полностью покрываются существующей настройкой «Минимальное количество требуемых тегов в теме»)?

@icaria36

С помощью панели языков, извлекающей названия из тегов, пользователи могли бы видеть темы, доступные на конкретном языке.

Это можно реализовать в формате, который мог бы быть полезен в целом: компонент навигации по тегам, отображающий теги из конкретной группы.

@icaria36

С помощью обнаружения браузера, выбора языка пользователем при регистрации, предпочтений пользователя и других способов, которые предстоит определить, система будет решать, какой(ие) язык(и) отображать пользователю.

Discourse в настоящее время позволяет пользователю устанавливать свой локаль (переключается настройкой сайта «разрешить выбор локаля пользователем») и автоматически определяет локаль, переключается настройкой сайта «устанавливать локаль из заголовка accept language». Существует три контекста автоматического определения:

• Гостевые пользователи (браузер и заголовки);
• Регистрация новых пользователей (то же);
• Приглашения (то же) — возможно, здесь есть проблема? (см.) (@schungx?)

Возможно, два улучшения, которые можно было бы здесь внедрить, это:

• добавить настройку, позволяющую пользователю вручную устанавливать свой локаль в форме регистрации;
• добавить переключатель локалей для гостей, аналогичный тому, что используется в Facebook (см. нижнюю панель страницы регистрации). Я уже создавал подобное для другого проекта, но ещё не превратил это в плагин.

@icaria36

Теги, категории и их описания могли бы быть локализованы.

Мне этот пункт кажется действительно интересным, и я считаю, что его определённо стоит попробовать. Теги, категории и описания категорий — это то, что пользователь часто читает первым, прежде чем перейти к самой теме. Они часто формируют у пользователя ощущение принадлежности к сообществу. Если они видят слова и описания, которые им близки, они с большей вероятностью почувствуют связь с самим сообществом. Таким образом, даже если после перехода в тему язык меняется, интерес и чувство принадлежности к сообществу уже сформированы.

Кроме того, локализовать описания категорий и теги проще, чем локализовать целые темы. С технической точки зрения это осуществимо, но пока не было опробовано. Подробнее см.. @erlend_sh, знаете ли вы о каких-либо дальнейших работах или примерах в этой области?

@icaria36

Пользователи могли бы искать во всех языках или фильтровать результаты по языкам, указанным в их профилях.

Если все языковые теги находятся в одной группе тегов, следующим шагом будет добавление фильтра тегов, специфичного для группы тегов, на страницу расширенного поиска.

Подводя итог упомянутым выше изменениям:

• Настройка сайта или категории «Требовать тег из группы тегов»;
• Компонент навигации по тегам, отображающий теги из конкретной группы;
• Настройка, позволяющая пользователю вручную устанавливать свой локаль в форме регистрации;
• Переключатель локалей для гостей;
• Локализация тегов, названий категорий и описаний категорий;
• Добавление фильтра тегов, специфичного для группы тегов, на страницу расширенного поиска.

[schungx (Stephen Chung)]

Приглашения (ibid) — возможно, здесь есть проблема? (см. 1) (@schungx?)

Насколько я понимаю, электронные письма с приглашениями будут отправляться на языке по умолчанию для сайта, но пользователь получит свой локаль после входа в систему.

В настоящее время нет возможности указать язык приглашений…

[HAWK]

@angus

Мне интересно, помогут ли некоторые другие сценарии использования этого типа настройки, упомянутые в связанной теме, аналогичному решению (или они полностью охвачены существующей настройкой «Минимальное количество тегов, необходимых в теме»)?

Ничего конкретного не приходит на ум, но мы наблюдаем всё больше и больше многоязычных сообществ. Если это упростит указанный сценарий, то я считаю, что такой запрос вполне обоснован.

[debryc (Deborah Chang)]

@angus

Однако этот сценарий использования выиграл бы от немного другого параметра «Требовать тег из группы тегов». Использовать его можно следующим образом:

• Создать группу тегов с фиксированным списком языков
• Требовать, чтобы каждый новый топик содержал хотя бы один тег из этой группы перед публикацией.

@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. Я согласен, что нужно как-то указать, какие теги доступны для выбора.

Возможно, в выпадающем списке тегов в редакторе сначала показывать группу тегов и её варианты, а затем уже другие популярные теги.

Или, возможно, в сообщении об ошибке будет фраза «выберите один из следующих тегов перед публикацией». Пользователи смогут кликнуть по названию тега, чтобы добавить его!

[neil (Neil Lalonde)]

@debryc

Возможно, в выпадающем списке тегов редактора сначала отображать группу тегов и её варианты тегов, а затем уже другие популярные теги.

Я выбрал именно такой подход. Необходимые теги будут предлагаться полем ввода тегов, если ещё не выбран ни один.

[achebe]

@icaria36

По умолчанию тема будет отображать темы на всех языках. Администраторы смогут настроить параметр по умолчанию: один язык, комбинацию языков или все языки.

Посредством языковой панели, которая извлекает данные из заголовков тегов, пользователи смогут видеть темы, доступные на конкретном языке.

Еще одна мысль:
Чтобы обеспечить справедливость в отношении множества языков, пользователь должен иметь возможность создавать/выражать (исходный текст) на языке, наиболее удобном для него. А читатель должен иметь возможность потреблять/читать на языке, наиболее удобном для него (переведенный текст). Чтобы минимизировать проблемы, связанные с потерей смысла при переводе, было бы полезно отображать бок о бок как исходный текст, так и переведенный текст. Базовая версия переведенного текста может быть автоматически сгенерированной. Последующие версии переведенного текста могут представлять собой улучшения, внесенные пользователями. Как в вики, читатели могут выбрать просмотр более ранних версий переведенного текста, если они подозревают потерю смысла при переводе.

@icaria36

С помощью определения браузера, выбора языка пользователем при регистрации, настроек пользователя и других способов, которые будут определены, система решит, какой(ие) язык(и) отображать пользователю.
…
Опять же, по умолчанию будет выбран английский язык, а администраторы смогут определить другие комбинации. Пользователь всегда сможет перейти в свои настройки пользователя и установить язык(и), который(е) он хочет видеть / игнорировать. Было бы еще полезнее, если бы пользователи могли установить язык публикации по умолчанию, чтобы не выбирать тег языка каждый раз.

Пользователь должен иметь быстрый способ выбора потребляемого языка (чтобы переопределить любые решения, принятые системой или администратором) — например, с помощью выпадающего списка языков в правом верхнем углу экрана. Например, гость-пользователь, говорящий по-английски (не авторизованный), путешествующий в Китай, может захотеть видеть текст на английском языке, хотя определение браузера может указывать на китайский как на местный язык.

@icaria36

Теги, категории и их описания могут быть локализованы.

Мне нравится эта идея перевода тегов и категорий. Хотя некоторые технические/научные термины могут не иметь переводов и могут нуждаться в сохранении на исходном языке.