Plugin multilingue 🌐

Honeyxilia · Février 9, 2024, 8:21

J’ai ouvert une PR qui corrige (en grande partie) ce bug !

github.com/paviliondev/discourse-multilingual

FIX : Custom Translations not showing to logged off users

main ← Honeyxilia:fix

opened 10:02AM - 08 Feb 24 UTC

Honeyxilia

+38 -15

**Note: Currently, this PR doesn't fix a specific case that I'll explain later -… it's still a relative improvement but might need some tweaking!** # Base situation On a forum me and my company are hosting, we're currently using this plugin to show both French and German users the translated names and descriptions of the categories, with the custom translation feature! Unfortunately, we've noticed that for logged off users only see the site's default locale version of the translation, which creates a discrepancy between the base site and the categories, that the plugin should arrange :( For reference, here are some screenshots - these are all coming from a local installation of Discouse running on Ubuntu 22.04 with English as the default locale: * Base version, while logged on/off ![en_logged_on_off_pre_fix](https://github.com/paviliondev/discourse-multilingual/assets/72192278/436926d4-b9c3-45fc-b75e-851f984cad21) * Custom french translation, logged on ![fr_logged_on](https://github.com/paviliondev/discourse-multilingual/assets/72192278/f3d0602c-3db3-43a6-ae19-a2ebb612e40b) * Logged off user with fr locale in browser, pre-fix ![fr_logged_off_pre_fix](https://github.com/paviliondev/discourse-multilingual/assets/72192278/29820b8c-d683-45b7-bf3d-fe62481eee3a) As you can see, while the category and topic nouns are translated (__"Catégories"__ and __"Sujets"__), the categories names, descriptions and subcategories are not translated and remain in the site's default locale, and this mismatch is what I aimed to fix - now, I present to you this fix! # Fix In the current production code, the locale is detected in the `plugin.rb` files, in the `add_to_serializer` relating to the custom translations of the category names, descriptions, and subcategories. However, the way it infers the used locale is by getting either the logged-on user's Interface language setting `scope.current_user.locale`, or the default locale of the site `SiteSetting.default_locale`. ```rb if object.uncategorized? I18n.t('uncategorized_category_name', locale: SiteSetting.default_locale) elsif !(scope && scope.current_user && scope.current_user.locale && object.slug_path && Multilingual::Translation.get("category_name", object.slug_path)).blank? Multilingual::Translation.get("category_name", object.slug_path)[scope.current_user.locale.to_sym] || object.name else object.name end ``` This is not ideal, as for a multilingual plugin, it would be right to assume that a given user's client wouldn't match the site's default locale, and it would be preferable to show them the translation that are in their language (if the translation exists). As a fix, I've decided to use the `I18n.locale` variable - indeed, this variable is set by the site through cookies or HTTP requests (if the site allows so), and when the value is updated, it runs through the serializers to get the corresponding translation, or the base one if the translation is not available. So, I've inserted this lambda that tests if a current user is logged on, or if the locale set by I18n is supported in the plugin (through the overridden `locale_available?` method) ```rb find_locale = -> (scope) { if (scope && scope.current_user && scope.current_user.locale) scope.current_user.locale else I18n.locale_available?(I18n.locale) ? I18n.locale : SiteSetting.default_locale end } ``` Then I've modified the corresponding `add_to_serializer` calls to use this lambda. For instance, here's the `add_to_serializer` call getting the translation for a main category's name : ```rb add_to_serializer(:basic_category, :name, respect_plugin_enabled: false) do if object.uncategorized? I18n.t( 'uncategorized_category_name', locale: I18n.locale_available?(I18n.locale) ? I18n.locale : SiteSetting.default_locale ) elsif !(object.slug_path && Multilingual::Translation.get("category_name", object.slug_path)).blank? Multilingual::Translation.get("category_name", object.slug_path)[find_locale.call(scope).to_sym] || object.name else object.name end end ``` # Results of the fix With this implemented, the logged-on users are not affected - as for the logged-off users, here are the differences : * The custom translations of the name and description are displayed to users in their language (if the site allows header or cookies reading) * The custom translations of the sub categories are only shown when a given category's `show_subcategory_list` is activated/true * Base version (English) - unaffected ![en_logged_on_off_post_fix](https://github.com/paviliondev/discourse-multilingual/assets/72192278/5aaf1a36-be97-4423-997f-a58e9dece0f9) * Custom translation post fix (French) - `show_subcategory_list` off for `Test deux` ![fr_logged_off_post_fix_no_subcat](https://github.com/paviliondev/discourse-multilingual/assets/72192278/41a8f84c-94e7-4cac-8fc4-671ccb406574) * Custom translation post fix (French) - `show_subcategory_list` on for `Test deux` ![fr_logged_off_post_fix_subcat_show](https://github.com/paviliondev/discourse-multilingual/assets/72192278/9eea5964-fe8a-4c68-a366-49eb1b4ec657) As you can see, the fix is mostly functional, except for this specific case for subcategories when the option to show a list of subcategories in a main category is off. After testing, it would seem that this is the case because the site doesn't rerun/yield the serializer relating to the subcategories unless this option is on, so only the default names are shown (initiated when the instance is launched, with the default locale). Sadly, I'm not well versed enough in either Ruby or the structure of the main discourse code as well as this plugin's - so, if maintainers on this repository wish to fix that specific case and then fuse this PR with the main code, I'd be very pleased :)

Ça fonctionne pour les noms de catégories, les descriptions et les sous-catégories lorsque l’option show_subcategory_list est activée sur une catégorie !
Le seul problème restant concerne les sous-catégories lorsque show_subcategory_list est désactivé

thoka · Juillet 20, 2024, 6:50

Si je veux traduire des catégories, des descriptions de catégories et des tags dans mon forum vers 10 langues différentes, je dois créer et télécharger 3 x 10 = 30 fichiers de configuration et de mise à jour distincts.

Je pense avoir toutes les traductions dans un seul fichier avec la structure suivante :

categories:
  slug: 
    _de: Nom allemand
    _en: Nom anglais 
    .description:
       _de: Description allemande
       _en: Description anglaise
tags:
  tag:
     ...

Cela présenterait plusieurs avantages :

Toutes les traductions pourraient être mises à jour en une seule fois
Les traducteurs voient le contexte pendant la traduction
Rationaliser les tâches de traduction en utilisant de grands modèles linguistiques

Quelqu’un a-t-il déjà essayé cela ?

Y a-t-il des inconvénients que je ne vois pas ?

Concernant une première implémentation, j’essaierai d’écrire un plugin qui crée et met à jour toutes les entrées nécessaires dans Multilingual::CustomTranslation.

angus · Juillet 23, 2024, 10:49

Ce plugin a besoin d’une mise à niveau. Je veux évaluer si cela en vaut la peine et ce qui est nécessaire. Si vous êtes intéressé par les fonctionnalités multilingues, veuillez voter :

J’utilise le plugin et je veux juste qu’il continue de fonctionner.
J’utilise le plugin et je veux une meilleure/différente fonctionnalité ou expérience utilisateur.
Je veux une meilleure fonctionnalité multilingue dans Discourse mais je n’utilise pas ce plugin (veuillez expliquer ci-dessous).
Aucune des options ci-dessus (veuillez expliquer ci-dessous pourquoi vous avez voté).

0 voters

UlBre · Août 7, 2024, 9:29

Ma réponse « Je veux une meilleure fonctionnalité multilingue dans Discourse mais je n’utilise pas ce plugin (veuillez expliquer ci-dessous) » est due au fait que nous sommes en train d’évaluer une bonne option multilingue. Ce serait formidable si votre outil s’avérait être celui-ci.

Comme vous avez demandé ce qui est nécessaire, je poste ici mon message écrit pour une question générale sur le support multilingue :

Nous avons un site web avec un seul domaine et deux langues (allemand, anglais). Le contenu est divisé par domaine.org/de/[nomdusite] et domaine.org/en/[nomdusite].
Nous avons un forum Discourse en langue allemande sur le sous-domaine [mot-clé-allemand]-forum.domain.org
Maintenant, nous voulons ajouter une version anglaise du forum.
Malheureusement, le mot-clé anglais, qui décrit bien le sujet et que nous aimerions utiliser pour le forum anglais ([mot-clé-anglais]-forum.domain.org), diffère du mot-clé allemand. Le mot-clé allemand ne fonctionne pas en anglais et le mot-clé anglais ne fonctionne pas en allemand.

Question :
Est-il possible de faire fonctionner un (un) forum Discourse avec différents sous-domaines pour différentes langues tout en utilisant une seule gestion de compte ?
Ou devons-nous construire un tout nouveau forum anglais avec son propre sous-domaine et sa propre gestion de compte ?

Par le terme « une seule gestion de compte », j’entends une seule base de données pour les utilisateurs et une seule connexion pour les deux langues.
Y a-t-il une possibilité d’éviter que les utilisateurs qui souhaitent utiliser les deux langues doivent s’inscrire deux fois ?

Ou devons-nous nous limiter strictement à un seul domaine si nous voulons offrir les mêmes connexions pour différentes langues du même forum ?

Si nous avons besoin d’un seul domaine et d’un seul forum, est-il possible d’afficher la langue d’un message dans le nom du lien du message ?

Comme par exemple
https://meta.discourse.org/t/multilingual-plugin/*en/*142740/125
pour les messages en anglais et
https://meta.discourse.org/t/multilingual-plugin/*de/*142740/125
pour les messages en allemand ?

Désolé si mes questions étaient trop stupides…

angus · Août 8, 2024, 12:46

En bref, non, ce n’est pas possible.

Une partie de l’objectif de ce plugin est de permettre à différents locuteurs natifs d’exister sur le même forum et que leur langue préférée leur soit naturellement proposée. C’était l’intention originale du plugin.

Oui, vous les auriez sur le même forum. Si vous devez vraiment avoir deux forums séparés, vous devrez utiliser un fournisseur d’identité, par exemple auth0 ou okta, qui fournit ensuite l’authentification pour les deux forums.

Ce n’est pas actuellement une fonctionnalité du plugin, mais il serait possible d’y parvenir avec un travail supplémentaire. Pour réaliser pleinement votre vision, des travaux supplémentaires seraient nécessaires dans tous les cas. Vous pouvez m’envoyer un message privé sur coop.pavilion.tech.

angus · Août 8, 2024, 1:04

Compte tenu des résultats de ce sondage, je vais travailler sur la prochaine version majeure de ce plugin à partir de septembre. Si vous avez des demandes spécifiques de fonctionnalités, c’est le moment de les faire. La prochaine version du plugin disposera également d’un abonnement professionnel payant avec support et d’autres avantages. Le plugin restera 100% open source.

pfaffman · Août 8, 2024, 8:33

Vous pourriez avoir deux instances et utiliser discourse connect pour faire de l’une d’elles le site qui gère l’authentification.

Jagster · Août 8, 2024, 11:17

En tant que membre d’une famille de langues très restreinte et difficile, j’ai besoin de traductions basées sur l’IA pour mes utilisateurs finlandais et estoniens. Les services de traduction sont horriblement mauvais en dehors des langues principales.

Les traductions en anglais sont un peu meilleures, cependant.

das-g · Août 16, 2024, 4:32

Je cherche à utiliser le réglage multilingual guest language switcher footer visible pour rendre les langues principales de la communauté facilement accessibles en tant que langues d’interface pour les visiteurs. Voici ce que j’ai observé :

La barre avec la liste restreinte des langues d’interface n’est visible que lorsque multilingual guest language switcher est défini sur footer, mais pas lorsqu’il est défini sur header.

Comme la barre est également appelée « pied de page » dans le nom du réglage (même si elle ne se trouve pas dans le pied de page de Discourse, mais flotte au-dessus du contenu près du coin inférieur droit de la fenêtre), cela pourrait être attendu. Cependant, sur les sites proposant un grand nombre de langues d’interface (par exemple, toutes celles actuellement disponibles dans Discourse), il serait souhaitable d’avoir une liste restreinte d’accès rapide aux langues principales de la communauté, indépendamment de l’emplacement du menu complet de sélection de langue pour les visiteurs. (Et je pense qu’un bouton de menu dans l’en-tête est beaucoup plus élégant qu’une barre flottant sur des parties aléatoires du contenu de la page, en en couvrant une partie.)

Peut-être que lorsque header est choisi et que des langues sont sélectionnées dans multilingual guest language switcher footer visible, celles-ci pourraient être triées en haut du menu et mises en surbrillance ?
Le réglage permet de réorganiser les langues sélectionnées pour la liste restreinte dans la barre :

capture d'écran du réglage , avec les langues « de », « fr », « it », « zh_CN », « en » et « ar » sélectionnées (dans cet ordre). Le pointeur de la souris survole « it », faisant apparaître des boutons fléchés qui permettent de déplacer l'élément vers le haut ou vers le bas dans la liste440×442 17.3 KB

Cependant, la barre semble ignorer cet ordre et semble plutôt trier les langues par ordre alphabétique de leur code court à 2 lettres :

Il serait souhaitable que l’ordre configuré dans le réglage soit respecté (soit par défaut, soit via une option de réglage supplémentaire).

das-g · Août 16, 2024, 4:39

Oh, et lorsque multilingual guest language switcher est défini sur header, le menu avec la liste des langues n’est pas déroulable (ni limité par la hauteur de la fenêtre du navigateur), de sorte que certaines langues ne sont pas sélectionnables, car elles se retrouvent en dessous du bord inférieur du navigateur. (Solution de contournement dans Firefox : Dézoomez avec Ctrl+molette de la souris, de sorte que l’ensemble du menu tienne dans la fenêtre du navigateur.)

Ceci est avec la version 0.2.9 (ba63f9a) du plugin « Multilingual ».

das-g · Août 16, 2024, 5:26

Un administrateur précédent de notre instance semble avoir déjà téléchargé certains fichiers category_name.<code langue>.yml à l’adresse https://<URL de base de Discourse>/admin/multilingual/translations.

~~Cependant, ils ne semblent pas fonctionner.~~ Existe-t-il un moyen de visualiser ou de télécharger leur contenu, afin que je puisse les modifier et les télécharger à nouveau ?

Édition :

Ils fonctionnent maintenant. (Je ne sais pas ce qui a changé.) Je serais toujours intéressé à les télécharger (ou à y accéder sur le serveur, s’ils se trouvent dans le système de fichiers là-bas), au cas où j’aurais besoin de les modifier à un moment donné.

evenlo · Septembre 4, 2024, 9:56

Bonjour, j’ai installé discourse-multilingual sur deux sites.
Il y a une erreur avec require is not defined dans i18n.js :

Lorsque j’ai désactivé discourse-multilingual, l’erreur ne s’est pas produite. Pourriez-vous s’il vous plaît me dire ce qui pourrait causer cela ?

Merci.

jesus2099 · Novembre 13, 2024, 7:23

Mais je veux :

jesus2099 · Novembre 18, 2024, 9:45

J’ai découvert un deuxième bug sur ce sujet.

J’ai remplacé 简体中文 par 한국어.
Une icône de crayon est apparue, signalant un changement.
Mais si vous regardez l’entrée de l’historique des modifications, le changement de langue du sujet n’est pas affiché.
Le Avant et Après sont identiques, même en mode Brut.

Moin · Novembre 18, 2024, 9:52

Je pense que c’était aussi le problème dans

Sheena · Février 8, 2025, 7:28

Bonjour !

Désolé si ma question est étrange, mais y a-t-il un endroit où je peux voir le plugin en action ? J’ai lu la documentation et parcouru ce fil de discussion, mais la plupart des sites d’exemples liés ne semblent pas fonctionner ou ont changé. Par exemple : Pavilion et http://try.thepavilion.io/ Pour cette raison, je ne peux pas consulter les exemples mentionnés pour le plugin, le sélecteur de langue, etc.

S’il n’y a actuellement aucun moyen de le tester, quelqu’un serait-il assez gentil pour répondre à quelques questions ?

Les utilisateurs peuvent-ils choisir leur(s) langue(s) préférée(s) lors de l’inscription, afin que le contenu du forum soit automatiquement filtré en fonction de leur sélection ?
Est-il possible de changer le bouton “LanguageSwitch” en une icône de globe ou autre chose ? Pour l’instant, il semble s’agir d’un caractère japonais, mais comme personne sur mon forum n’utilise cette langue, cela pourrait confondre les utilisateurs ou les amener à l’ignorer.
Je comprends que les catégories et les descriptions peuvent être traduites (si j’ai bien compris), mais cela fonctionne-t-il aussi pour les sous-catégories de sous-catégories ? De plus, cela pourrait-il s’appliquer à des éléments tels que les liens dans l’en-tête de la marque (plugin) ? Par exemple, le mot “Products” pourrait-il être traduit et rediriger les utilisateurs vers la version espagnole ou anglaise, en fonction de la langue sélectionnée ? Je pose cette question car il s’agit d’un plugin très populaire et je me demandais s’il était pris en charge par le plugin multilingue.

Désolé pour toutes ces questions ! J’ai fait de mon mieux pour tout comprendre en regardant les captures d’écran et la documentation.

Zas666 · Février 25, 2025, 12:43

Il semble que ce plugin ne fonctionne pas bien avec Discourse 3.5.0beta1, j’ai dû le désactiver pour reprendre le forum. Je n’ai rien trouvé dans les journaux sauf :

Avis de dépréciation : add_to_serializer ne doit pas être utilisé pour remplacer directement les méthodes include_* ?. Utilisez plutôt l’argument keyword include_condition
À /var/www/discourse/plugins/discourse-multilingual/plugin.rb:314:in block in activate!

thoka · Février 25, 2025, 9:56

Je reçois une erreur 500 / Oops avec le discours actuel :

ArgumentError (nombre incorrect d'arguments (donné 2, attendu 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 niveaux) in activate!'

Ma locale est réglée sur de_DE.UTF-8.

Au fait : “Signaler un bug” au-dessus renvoie vers le domaine actuellement inconnu discourse.pluginmanager.org.

TRgala_Murat · Février 25, 2025, 10:50

Ce plugin fait planter mon site en ce moment même.

angus · Février 25, 2025, 12:54

Le plugin a été mis à jour pour ne pas se casser sur la dernière version de Discourse.

Sujet		Réponses	Vues
Make a multi-language forum Feature multi-lingual	43	19698	Octobre 31, 2021
Structuring a multilingual community Site Management multi-lingual , how-to , localization	28	13601	Janvier 18, 2022
I could not edit tags for old topics Support	10	675	Mai 6, 2022
Content Localization - Manual and Automatic with Discourse AI Site Management ai , content-localization	47	1773	Novembre 27, 2025
Discourse Translator Plugin official , multi-lingual , translator	23	69693	Juillet 10, 2025

Plugin multilingue 🌐

Édition :

Sujets connexes