Content languages

What are content languages?

Content languages are the languages used in forum posts.

Screenshot at Feb 25 15-28-47

Content languages are different from interface languages, which can already be set in Discourse (see default locale and allow user locale site settings, and the Interface language user setting).

Screenshot at Feb 25 10-25-15

In a multilingual forum, you may have more than one content language. This raises a few issues:

  1. How do I make it easy for my users to find content in their language?
  2. How do I make it easy for my users to filter out content in a language they can’t understand?
  3. How do I make it easy for my users to translate content in a language they can’t understand?

The content languages feature is designed to make it easy to handle these and similar issues when running a multilingual forum.

How do content languages work?

Tagging

The content languages feature uses Discourse’s tagging system to filter content. When content languages are enabled, a new tag selector appears in the topic composer and topic edit controls that lets a user add a content language tag to a topic.

Screenshot at Feb 25 14-09-53

When a topic is tagged with a content language, a content language tag is applied to the topic, appearing in the topic list item and underneath the topic title, next to the normal tags but differentiated by a language symbol.

Screenshot at Feb 25 14-31-17
(pro tip: the tag itself is the languge ISO code, e.g. “en”, but it is rendered using the “native name” of the language, e.g. “English” for ease of use).

User preferences

A user can set a content language(s) for their account in their interface preferences.

Screenshot at Feb 25 14-02-28

If a user sets a content language, all topic lists on the site will be filtered by that language (i.e. only topics tagged with that language will appear) and the language icon next to the topic list filters will change color to indicate the topic list is being filtered.

Screenshot at Feb 25 14-03-45

Clicking on the language icon shows the languages being filtered by, and links the user to their content language setting. If the user has more than one content language set, they will see all topics tagged with any of their content languages.

Screen Shot 2020-02-25 at 2.24.51 PM

If the user has at least one content language set, the first in their list will appear automatically in the composer content language selector when the user is creating a topic.

Screenshot at Feb 25 14-26-35

Guests can also filter topics by a content language by selecting it in the language dropdown next to the topic list filters.

Screenshot at Feb 25 14-29-11

How to administer content languages

Like interface languges, content languages can be administered in the “Languages” list in the “Multilingual” admin panel. This list gives you an overview of the languages in your Discourse. If you wish to use a content language not in the standard language list, you can add it by adding a Custom Language.

Screen Shot 2020-02-25 at 9.40.39 PM

Site and language settings

Content languages can be enabled by toggling the site setting multilingual content languages enabled. This setting is off by default. None of the content languages features will work if that setting is disabled.

If content languages are enabled, the list of content languages a user (or guest) can select is determined by which languages in your Languages list have “content” checked

Screenshot at Feb 25 14-37-42

Content tag group

Any language with “content” checked will automatically have a corresponding tag in a tag group called “Multilingual content tags”. Both the group and the corresponding tags will be automatically generated if the setting is enabled, and they do not currently exist (see below on how to remove the group and tags).

You can navigate to the “Multilingual content tags” tag group by clicking the “Tags” link in the Multilingual admin panel

Screen Shot 2020-02-25 at 12.10.11 PM

This group of tags determines what tags will be available in the content language tags selector. The tags in this group are also filtered out of the normal tag selector and in the Tags page.

The Tags Group interface has been changed for the Multilingual content tag group, to reflect its unique character (the interface for other tag groups remains the same).

Screen Shot 2020-02-25 at 2.43.40 PM

You can’t change the permissions of the group, or its visibility. That is determined by the content languages settings. Also, administrators (but not moderators) are given the power to delete all tags in the group and update all tags in the group.

Updating all tags means ensuring that all languages with “content” enabled in your Languages list have a corresponding tag in the group. This should be the case anyway, but the control is there in the event the two get out of sync for any reason.

Deleting all tags is added to allow you to easily remove all of the content language tags generated by the multilingual plugin if you wish to disable content languages or remove the plugin entirely. The plugin does not do this automatically, as you may wish to retain the tags.

Requiring a content language

You can require users to select a content language when creating a topic by setting the multilingual require content language tag setting. This setting has three options:

  • no: content languages are not required when creating a topic
  • non-staff: content languages are only required of non-staff when creating a topic
  • yes: content languges are required of everybody when creating a topic

If this setting is enabled, and it applies to the user in question, they will not be able to post a topic without a content language.

Discourse Translator sync

If you have:

  1. the Discourse Translator Plugin installed;
  2. the Translator Plugin enabled;
  3. the Multilingual Plugin enabled; and
  4. content languages enabled

you can enable multilingual translator content tag sync (you won’t be able to enable it unless all four things are true).

The sync automatically applies the detected language of posts in a topic as content languages, as long as the detected language matches a content language enabled on your site.

Screen Shot 2020-02-25 at 3.22.54 PM
Screenshot at Feb 25 15-23-30

If the Translator plugin detects additional languages in subsequent posts in a topic, these will also be added as content language tags.

Screenshot at Feb 25 15-26-23

I’m still wrapping my head about the combination of features between the Multilingual and the Translator plugins.

Let’s say that a user can read 4 languages and they selects them as their content languages. From that point, topics without the tags of these languages will be filtered, correct?

However, does this really matter when Translate is enabled? Even if the user can’t read the other languages, they can easily translate them with one click. They can also reply in their language, knowing that other will be able to read the reply with Translate as well.

Therefore… isn’t it better to avoid the filtering when Translate is enabled? It still may make sense to prioritize topics with original content in my content languages, but not filter out the rest.

What do you think? Or is this the behavior already?

Yes, that’s correct.

I would say that tagging the original language of a post is still important when the translate plugin is enabled. Speakers of a language will still want to easily be able to find content in their native language, even if the machine translation is 100% perfect (it isn’t). The primary utility of content language tags is discovery.

However, I agree that a user may not way to all their topic lists to be filtered by their selected content language(s) if it’s possible for them to automatically translate content not in their content languages. Perhaps the solution here would be to add another topic list filter to the plugin, which would be whatever content language the user has selected, e.g.

Monosnap Discourse 2022-05-23 13-55-57

The site admin could select whether a user’s entire topic discovery is filtered by their content language, or if they just get a new topic list showing topics originally in their content language. If the site was using the translator plugin, they’d likely choose the latter for the reasons you mention.

Yes, 100% agree.

Interesting, but we need to keep in mind that many users may read two or more languages. This might be problematic UX wise.

We could deduce that chances are that the language selected in the interface language is going to be the primary, leaving the other ones as secondary. This has shortcomings because only a few languages are available as Interface Language, but this would be better than nothing.

Hello, I’m trying to use this plugin for my forum, but I’d like to mass upload old topics with language tags. So I add the corresponding code “fr” for french posts, but on the website, the post isn’t tagged with fr, so I was wondering how to upload topics through the API and still have the language tag applied