Multilingual Plugin 🌐

I’ve opened a PR that (mostly) fixes this bug !

it works on category names, descriptions, and subcategories when the option show_subcategory_list is active on a category !
The only issue left is subcategories when show_subcategory_list is off :purple_heart:

4 Likes

If I want to translate categories, category-descriptions and tags in my forum to 10 different languages, I have to create and upload 3 x 10 = 30 separate files for configuration and updates.

I’m thinking about having all translations in one file with following structure:

categories:
  slug: 
    _de: German name
    _en: English name 
    .description:
       _de: German description
       _en: English description
tags:
  tag:
     ...

This would have several benefits:

  • All translations could be updated at once
  • Translators see context during translation
  • Streamline translation tasks utilizing Large Language Models

Has anyone tried this before?

Are there any downsides I do not see?

Regarding a first implementation, I will try to write a plugin that creates and updates all needed entries in Multilingual::CustomTranslation.

3 Likes

This plugin is in need of an upgrade. I want to gauge whether it is worth it, and what is needed. If you’re interested in multilingual features please vote:

  • I use the plugin and just want it to keep working.
  • I use the plugin and want better/different functionality or UX.
  • I want better multilingual functionality in Discourse but don’t use this plugin (please explain below).
  • None of the above (please explain below why you voted).
0 voters
2 Likes

My answer “I want better multilingual functionality in Discourse but don’t use this plugin (please explain below)” is because we are just evaluating for good a multilanguage-option. It would be great to find your tool to be the one.

As you asked for what ist needed I put my post I wrote for general question fĂźr multilanguage support here:

We do have a website with one domain and two languages (german, english). The content ist divided by domain.org/de/[nameofsite] and domain.org/en/[nameofsite].
Wo do have a discourse-forum in german language at the subdomain [germankeyword]-forum.domain.org
Now we want to add an english forum version.
Unfortunately the english keyword, which aptly describes the topic, and which we would want to use for the english forum ([englishkeyword]-forum.domain.org) differs from the german keyword. The german keyword doesn’t work in english and the english keyword doesn’t work in german.

Question:
Is ist possible to run a (one) discourse-forum with different subdomains for different languages while using only one account management?
Or do we have to build a completely new english forum with its own subdomain and its own account management?

With the term “one account management” i do mean only one database for users and only one login for both languages.
Ist there any possibility to avoid that users, who want to use both languages, have to register twice?

Or do we strictly need to restrict us to one domain if we want to offer the same logins for different languages oft the same forum?

If we do need one domain and one forum, ist there a possibility to show the language of a post in the linkname oft the post?

Just like
https://meta.discourse.org/t/multilingual-plugin/*en/*142740/125
for english posts and
https://meta.discourse.org/t/multilingual-plugin/*de/*142740/125
for german ones?

Sorry if my questions were too stupid…

2 Likes

In short, no, that’s not possible.

Part of the goal of this plugin is to allow different native speakers to exist on the same forum and for their preferred language to be naturally surfaced to them. That was the original intent of the plugin.

Yes, you’d have them on the same forum. If you really have to have two separate forums you’d have to use an identity provider, e.g. auth0 or okta, which then provides authentication for both forums.

This isn’t currently a feature of the plugin however it’d be possible to achieve this with some additional work. To fully achieve your vision additional work would be needed either way. You can send me a private message on coop.pavilion.tech.

2 Likes

Given the results of this poll I’m going to work on the next major version of this plugin starting in September. If you have any specific requests for features, now’s the time to make them. The next version of the plugin will also have a paid business subscription available with support and other benefits. The plugin will remain 100% open source.

4 Likes

You could have two instances and use discourse connect to make one of them the site that handles authentication.

1 Like

As a part of very small and difficult language family I need AI-based translations for my finnish and estonian users. Translation services are horrible bad outside main languages.

Translations into English are a bit better, though.

4 Likes

I’m trying to use the multilingual guest language switcher footer visible setting, to make the community’s main languages quickly accessible as interface languages for guests. Here is what I observed:

  1. The bar with the shortlist of interface languages is only visible when when multilingual guest language switcher is set to footer, but not when it’s set to header.

    As the bar is also called a “footer” in the setting name (even though it isn’t in Discourse’s page footer, but rather floats over the content near the lower right corner of the window), this might be expected. Though on sites offering a lot of interface languages (e.g. all currently available in Discourse), it’d be nice to have a quick-access short-list of the community’s main languages available independent of the placement of the full language chooser menu for guests. (And I think a menu button in the header looks much cleaner than bar floating over random parts of the page content, covering up some of it.)

    Maybe when header is chosen and languages are selected in multilingual guest language switcher footer visible, those could be sorted to the top of the menu and somewhat highlighted?

  2. The setting allows to re-order the languages selected for the shortlist in the bar:
    screenshot of  setting, with languages "de", "fr", "it", "zh_CN", "en" and "ar" selected (in that order). The mouse pointer hovers over "it", making arrow buttons pop into existence that allow to move the item up or down in the list

    However, the bar seems to ignore that order and instead seems to sort the languages alphabetically by their 2-letter short code:
    screenshot of the multilingual guest language switcher bar. The languages are (in that order), Arabic, German, English (US), French and Italian, all listed by their native names: "اللغة العربية", "Deutsch", "English (US)", "Français", "Italiano" and "简体中文"

    It’d be nice if the order configured in the setting was honored (either by default, or through an additional setting toggle.)

1 Like

Oh, and when multilingual guest language switcher is set to header, the menu with the list of languages is not scrollable (nor limited by the height of the browser window), so some languages aren’t selectable, because they happen to end up below the lower edge of the browser. (Workaround in Firefox: Zoom out with Ctrl+Scrollwheel, so that the whole menu fits into the Browser window.)

This is with version 0.2.9 (ba63f9a) of the “Multilingual”-Plugin.

1 Like

A previous admin of our instance seems to have already uploaded some category_name.<language code>.yml at <discourse base URL>/admin/multilingual/translations.

However they don’t seem to work. Is there a way to view or download their content, so I can modify them and upload again?

Edit:

They do work now. (I don’t know what changed.) I’d still be interested in downloading them (or accessing them on the server, if they’re on the file system there), in case I need to modify them at some point.

1 Like

Hi I’ve installed discourse-multilingual in two sites.
There is an error with require is not defined in i18n.js:

When I disabled discourse-multilingual, the error did not occur. Could you please let me know what might be causing this?

Thank you.

But I want to:

I came across a second bug on this topic.

I have replaced 简体中文 with 한국어.
A pencil icon did appear, notifying of a change.
But if you look at edit history entry, the topic language change is not shown.
The Before and After are identical, even in Raw mode.

I think that was also the problem in

1 Like

Hello there!

Sorry if this is a strange question, but is there anywhere I can see the plugin in action? I’ve read the documentation and gone through this thread, but most of the linked example sites don’t seem to work or have changed. For example: Pavilion and http://try.thepavilion.io/ Because of this, I can’t check out the mentioned examples for the plugin, the locale switcher, etc.

If there’s currently no way to test it, would someone be kind enough to answer a few questions? :slightly_smiling_face:

  • Can users choose their preferred language/s during sign-up, so the forum’s content is automatically filtered based on their selection?
  • Is it possible to change the “LanguageSwitch” button to a globe icon or something else? Right now, it appears to be a Japanese character, but since no one on my forum uses that language, it might confuse users or cause them to ignore it.
  • I understand that categories and descriptions can be translated (if I got that right), but does this also work for subcategories of subcategories? Additionally, could it apply to elements like links in the brand header (plugin)? For example, could the word “Products” be translated and redirect users to either the Spanish or English version, depending on their selected language? I’m asking since this is a very popular plugin and was wondering if it’s supported by the multilingual plugin.

Sorry for all the questions! I did my best to figure everything out by looking at the screenshots and documentation.

It seems this plugin doesn’t play well with Discourse 3.5.0beta1, I had to disable it to get the forum back. I found nothing in logs but:

Deprecation notice: add_to_serializer should not be used to directly override include_*? methods. Use the include_condition keyword argument instead
At /var/www/discourse/plugins/discourse-multilingual/plugin.rb:314:in block in activate!

2 Likes

I get an Error 500 / Oops with current discourse:

ArgumentError (wrong number of arguments (given 2, expected 1))
app/controllers/extra_locales_controller.rb:44:in `url'

Backtrace

plugins/discourse-multilingual/extensions/extra_locales_controller.rb:21:in `bundle_js_hash'
app/controllers/extra_locales_controller.rb:44:in `url'
plugins/discourse-multilingual/lib/multilingual/locale_loader.rb:30:in `preload_tag_translations'
plugins/discourse-multilingual/plugin.rb:77:in `block (2 levels) in activate!'

My locale is set to de_DE.UTF-8.

Btw: “Report a bug” above links to the currently unknown domain discourse.pluginmanager.org.

1 Like

This plugin is definitely crashing my site right now.

1 Like

The plugin has been updated so it doesn’t break on the latest version of Discourse.

13 Likes