Structurer une communauté multilingue

[Discourse]

Ce guide explique différentes approches pour organiser un forum Discourse destiné à une communauté multilingue, en incluant les avantages et inconvénients de chaque méthode.

Niveau utilisateur requis : Administrateur

Discourse propose plusieurs façons de structurer votre site pour une communauté multilingue. Ce guide explorera les approches les plus courantes ainsi que leurs avantages et inconvénients.

Ce sujet n’est plus la source des approches recommandées pour structurer une communauté multilingue, car nous recommandons désormais l’utilisation des fonctionnalités intégrées de localisation du contenu dans le noyau de Discourse, avec des traductions automatiques optionnelles via le plugin Discourse AI. Pour plus de détails, veuillez consulter Content Localization - Manual and Automatic with Discourse AI.

Utilisation de catégories pour la séparation des langues

Catégorie « Autres langues » avec sous-catégories

Une approche consiste à créer une catégorie principale appelée « Autres langues » avec des sous-catégories pour chaque langue spécifique.

Comment l’implémenter :

1. Créez une nouvelle catégorie nommée « Autres langues »
2. Ajoutez des sous-catégories pour chaque langue que vous souhaitez prendre en charge
3. Encouragez les utilisateurs à publier dans la sous-catégorie de langue appropriée

Avantages :

• Séparation claire entre les langues
• Possibilité d’utiliser des tags restreints par catégorie pour une organisation supplémentaire au sein de chaque langue

Inconvénients :

• Les utilisateurs multilingues doivent suivre plusieurs catégories avec un contenu similaire
• Peut entraîner la création de silos de contenu basés sur la langue

Catégories de niveau supérieur distinctes pour chaque langue

Une autre approche consiste à créer des catégories de niveau supérieur distinctes pour chaque langue prise en charge.

Comment l’implémenter :

1. Créez une nouvelle catégorie pour chaque langue que vous souhaitez prendre en charge
2. Utilisez un composant de thème comme Custom Header Links pour ajouter des liens de changement de langue dans l’en-tête

Avantages :

• Distinction claire entre les sections linguistiques
• Navigation facile pour les utilisateurs ne parlant qu’une seule langue

Inconvénients :

• Peut créer une expérience communautaire fragmentée
• Difficile pour les utilisateurs multilingues de suivre les discussions dans plusieurs langues
• Peut entraîner la création de silos de contenu basés sur la langue

Utilisation de tags pour l’identification des langues

Tags de langue à l’échelle du forum

Cette approche consiste à créer des tags pour chaque langue prise en charge et à encourager les utilisateurs à taguer leurs publications en conséquence.

Comment l’implémenter :

1. Créez des tags pour chaque langue que vous souhaitez prendre en charge (par exemple, #anglais, #français, #espagnol)
2. Encouragez les utilisateurs à ajouter le tag de langue approprié lors de la création de sujets
3. Optionnellement, utilisez des émojis dans les noms de tags pour une distinction visuelle

Avantages :

• Pas besoin de catégories séparées
• Les utilisateurs multilingues peuvent facilement suivre tout le contenu
• Flexible pour les sujets pouvant impliquer plusieurs langues

Inconvénients :

• Dépend de la conformité des utilisateurs pour un taggage précis
• Peut être moins intuitif pour les utilisateurs habitués à la navigation par catégories

Utilisation d’instances Discourse séparées

Pour les communautés avec des groupes linguistiques distincts, il est possible d’envisager l’utilisation d’instances Discourse séparées pour chaque langue.

Comment l’implémenter :

1. Configurez une instance Discourse séparée pour chaque langue
2. Utilisez des sous-domaines ou des domaines séparés pour chaque instance (par exemple, fr.example.com, en.example.com)
3. Établissez des liens entre les instances dans l’en-tête ou le pied de page en utilisant un composant de thème comme Custom Header Links

Avantages :

• Séparation complète du contenu et des utilisateurs par langue
• Possibilité de personnaliser chaque instance pour sa communauté linguistique spécifique

Inconvénients :

• Plus complexe à gérer avec plusieurs instances
• Difficile pour les utilisateurs multilingues de participer à travers les communautés linguistiques
• Risque de discussions dupliquées et de communauté fragmentée

Considérations supplémentaires

Localisation des catégories et des tags

Discourse prend désormais en charge la localisation des noms de catégories, des descriptions de catégories et des noms de tags via la fonctionnalité intégrée de localisation du contenu. Activez content localization enabled et configurez content localization supported locales dans les paramètres de votre site. Les groupes autorisés peuvent fournir des traductions manuelles, ou des traductions automatiques peuvent être configurées via le plugin Discourse AI.

Préférences linguistiques des utilisateurs

Discourse dispose de paramètres de langue intégrés, notamment allow user locale, set locale from accept language header, set locale from cookie et set locale from param. Ces paramètres permettent aux utilisateurs de définir leur langue préférée pour l’interface. Lorsque la localisation du contenu est activée, les utilisateurs verront automatiquement du contenu localisé en fonction de leurs préférences de langue.

Sélecteur de langue

Le paramètre content localization language switcher peut afficher un sélecteur de langue dans l’en-tête, permettant aux visiteurs (y compris les utilisateurs anonymes) de basculer entre les langues prises en charge.

Fonctionnalité de recherche

Assurez-vous que les utilisateurs peuvent rechercher dans toutes les langues ou filtrer les résultats par langue spécifique.

Ressources supplémentaires

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

[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

L’objectif est d’offrir un espace de discussion que les locuteurs de n’importe quelle langue (et de n’importe quelle combinaison de langues) puissent considérer comme leur propre, par opposition à un forum en anglais avec un coin multilingue ou à un forum divisé en plusieurs langues, ce qui revient effectivement à créer de nombreux forums séparés.

Qu’est-ce qui donne à une communauté le sentiment d’être une communauté ? Dans un média largement basé sur le texte, la capacité à comprendre la communication textuelle des autres membres semble essentielle. Je me demande donc s’il est possible de surmonter complètement les deux écueils que vous mentionnez (« silotisation » ou « tokenisme ») dans un média principalement textuel (sans traduction automatique parfaite).

Une communauté qui me vient à l’esprit ici est https://discourse.mozilla.org

@icaria36

Pour cela, le bloc de construction principal serait un tag spécifique aux langues. Ce tag serait obligatoire pour tous les sujets et aurait pour valeur par défaut l’anglais. Les sujets dans des langues autres que l’anglais seraient tagués en conséquence.

Actuellement, nous avons la possibilité d’exiger un certain nombre de tags sur un message dans une catégorie, voir The option to enforce tagging (Paramètre de catégorie « Nombre minimum de tags requis dans un sujet »).

Cependant, ce cas d’usage bénéficierait d’un paramètre légèrement différent : « Exiger un tag d’un groupe de tags ». Voici comment vous l’utiliseriez :

• Créer un tag_group avec une liste définie de langues
• Exiger que chaque nouveau sujet ait un tag ajouté à partir de ce groupe avant d’être publié.

@HAWK Je suis curieux de savoir si certains des autres cas d’usage pour ce type de paramètre que vous avez mentionnés dans le sujet lié bénéficieraient d’une approche similaire (ou s’ils sont entièrement couverts par le paramètre existant « Nombre minimum de tags requis dans un sujet ») ?

@icaria36

Grâce à une barre de langues tirant ses informations des titres des tags, les utilisateurs pourraient voir les sujets disponibles dans une langue spécifique.

Cela pourrait être réalisé d’une manière généralement utile : un composant de navigation par tags affichant les tags d’un groupe spécifique.

@icaria36

Grâce à la détection du navigateur, au choix de langue effectué par l’utilisateur lors de l’inscription, aux préférences utilisateur et à d’autres moyens à déterminer, le système déciderait de quelle(s) langue(s) afficher à un utilisateur.

Discourse permet actuellement à l’utilisateur de définir sa locale (activé par le paramètre du site allow user locale) et effectue une détection automatique de la locale, activée par le paramètre du site set locale from accept language header. Il existe trois contextes de détection automatique :

• Invités (navigateur et en-têtes)
• Inscriptions (idem)
• Invitations (idem) - il y a peut-être un problème avec cela ? (voir) (@schungx?)

Peut-être que les deux améliorations qui pourraient être apportées ici seraient :

• d’ajouter un paramètre permettant à un utilisateur de définir manuellement sa locale dans le formulaire d’inscription
• d’ajouter un « sélecteur de locale » pour les invités, similaire à celui de Facebook (voir la barre inférieure de la page d’inscription). Je l’ai d’ailleurs créé pour un autre projet, mais je ne l’ai pas encore transformé en plugin.

@icaria36

Les tags, les catégories et leurs descriptions pourraient être localisés.

Je trouve celui-ci vraiment intéressant et pense qu’il serait certainement intéressant d’essayer. Les tags, les catégories et les descriptions de catégories sont ce qu’un utilisateur lit souvent en premier avant de lire un sujet réel. Ils contribuent souvent au sentiment d’appartenance à la communauté de l’utilisateur. S’ils voient des mots et des descriptions avec lesquels ils s’identifient, ils sont plus susceptibles de s’identifier à la communauté elle-même. Ainsi, même s’il y a une langue différente une fois que l’utilisateur entre dans le sujet, son intérêt et son sentiment envers la communauté sont déjà amorcés.

Il est également plus facile de localiser les descriptions de catégories et les tags que de localiser des sujets entiers. D’un point de vue technique, c’est faisable, mais cela n’a pas encore été essayé. Voir plus. @erlend_sh Connaissez-vous d’autres travaux ou exemples à ce sujet ?

@icaria36

Les utilisateurs pourraient rechercher dans toutes les langues ou filtrer selon leurs langues définies dans leurs profils.

Si tous les tags de langue sont dans un seul tag_group, la démarche ici serait d’ajouter un filtre de tag spécifique au groupe de tags à la page de recherche avancée.

Pour résumer les changements que j’ai mentionnés ci-dessus :

• Un paramètre de site ou de catégorie « Exiger un tag d’un groupe de tags »
• Un composant de navigation par tags affichant les tags d’un groupe spécifique
• Un paramètre permettant à un utilisateur de définir manuellement sa locale dans le formulaire d’inscription
• Un « sélecteur de locale » pour les invités
• La localisation des tags, des noms de catégories et des descriptions de catégories
• Ajouter un filtre de tag spécifique au groupe de tags à la page de recherche avancée

[schungx (Stephen Chung)]

Invitations (ibid) - il y a peut-être un problème ici ? (voir 1) (@schungx ?)

À ma connaissance, les e-mails d’invitation sont envoyés dans la langue par défaut du site, mais l’utilisateur obtiendra sa propre localisation une fois connecté.

Il n’existe actuellement aucun moyen de spécifier la langue des invitations…

[HAWK]

@angus

Je me demande si certains des autres cas d’usage pour ce type de paramètre que vous avez mentionnés dans le sujet lié bénéficieraient d’une solution similaire (ou s’ils sont entièrement couverts par le paramètre existant « Nombre minimum de balises requis dans un sujet ») ?

Rien ne me vient à l’esprit pour le moment, mais nous constatons de plus en plus de communautés multilingues. Si cela permet de simplifier ce cas d’usage particulier, je pense que c’est une demande légitime.

[debryc (Deborah Chang)]

@angus

Cependant, ce cas d’usage bénéficierait d’un paramétrage légèrement différent : « Exiger une étiquette provenant d’un groupe d’étiquettes ». Voici comment vous pourriez l’utiliser :

• Créer un groupe d’étiquettes avec une liste prédéfinie de langues.
• Exiger que chaque nouveau sujet comporte une étiquette issue de ce groupe avant sa publication.

@HAWK Je soutiens également cette fonctionnalité. Je vois de nombreuses utilisations possibles, au-delà de l’exigence d’étiquettes de langue. Par exemple, nous disposons actuellement d’un groupe d’étiquettes appelé « gestion de projet » contenant les étiquettes #idée, #cadrage, #prêt, #en-cours, #célébration, #évaluation, #terminé. Il serait formidable d’exiger que les utilisateurs étiquettent correctement chaque publication avec l’étape appropriée de gestion de projet au sein de certaines catégories.

[HAWK]

@neil, qu’en penses-tu ? Quel serait le volume de travail nécessaire pour imposer l’utilisation d’un seul tag provenant d’un groupe de tags spécifique ?

Note que nous n’avons pas encore atteint la règle de trois, mais je suis toujours intéressé par des réponses à la question ci-dessus.

[JimPas]

Cela semblerait intéressant pour mon forum également. Nous avons principalement des membres anglophones, mais aussi des membres hispanophones. Nous traduisons constamment dans les deux sens. L’idée de deux forums séparés (avec des langues différentes) ne nous convient pas. Mais un site bilingue à traduction automatique avec une langue par défaut définie par l’utilisateur serait formidable !

[neil (Neil Lalonde)]

@HAWK

Quelle serait l’ampleur du travail pour imposer l’utilisation d’un seul tag à partir d’un groupe de tags spécifique ?

Il serait facile d’ajouter une fonctionnalité pour imposer la présence d’un tag issu d’un groupe de tags. Dans ce cas précis (choisir une langue), je suppose que nous souhaitons imposer exactement un tag, mais je parie que certaines personnes voudraient au moins un tag (similaire au paramètre « Nombre minimum de tags requis dans un sujet »). Je préférerais implémenter « au moins un tag à partir d’un groupe de tags spécifique », car nous pouvons déjà observer cela en action sur Car Talk, où il est possible pour les utilisateurs d’ajouter tous les tags de marques et de modèles de voitures à leurs sujets, mais cela ne se produit pas. De plus, dans une communauté multilingue, il peut parfois avoir du sens d’avoir plus d’une langue.

[HAWK]

Oui, ça me semble judicieux.

[angus (Angus McLeod)]

@neil

Je préférerais mettre en œuvre « au moins un tag d’un groupe de tags spécifique »

Peut-être que la meilleure façon de procéder serait de l’ajouter en tant que minimum numérique plutôt que booléen, afin d’offrir un contrôle plus granulaire et de laisser la porte ouverte à l’ajout d’un maximum ?

[neil (Neil Lalonde)]

Je l’ai construit aujourd’hui. Il s’agit d’un paramètre par catégorie dans l’onglet Étiquettes :

Une amélioration possible serait de mieux indiquer aux utilisateurs quelles étiquettes ils peuvent choisir. Actuellement, le nom du groupe d’étiquettes est affiché, mais il vaudrait probablement mieux lister les étiquettes elles-mêmes, ou les plus populaires du groupe si elles sont trop nombreuses pour toutes les afficher.

@debryc @angus Qu’en pensez-vous ?

[debryc (Deborah Chang)]

C’est tellement excitant, Neil !

1. Je pense que l’affichage des paramètres est parfait.
2. Je suis d’accord pour dire qu’il faut une indication sur les balises disponibles.

Peut-être que dans la liste déroulante des balises de l’éditeur, on pourrait afficher d’abord le groupe de balises et ses options, avant de montrer les autres balises populaires.

Ou alors, le message d’erreur pourrait inclure un texte du type « Choisissez l’une des balises suivantes avant de publier ». Les utilisateurs pourraient cliquer sur le nom de la balise pour l’ajouter !

[neil (Neil Lalonde)]

@debryc

Peut-être, dans la liste déroulante des tags de l’éditeur, afficher d’abord le groupe de tags et ses options de tags, avant d’afficher les autres tags populaires.

J’ai opté pour cette approche. Les tags requis seront suggérés par la saisie de tags si aucun n’a encore été choisi.

[achebe]

@icaria36

Par défaut, le sujet afficherait les sujets dans toutes les langues. Les administrateurs pourraient configurer par défaut une seule langue, une combinaison de langues, ou conserver toutes les langues…

Grâce à une barre de langues qui s’appuie sur les titres des balises, les utilisateurs pourraient voir les sujets disponibles dans une langue spécifique.

Une autre réflexion :
Pour être équitable envers plusieurs langues, un utilisateur doit pouvoir produire/s’exprimer (texte source) dans la langue qui lui convient le mieux. Et le lecteur doit pouvoir consommer/lire dans la langue qui lui convient le mieux (texte traduit). Pour minimiser les problèmes de perte dans la traduction, il serait bénéfique d’afficher côte à côte à la fois le texte source et le texte traduit. La version de base du texte traduit pourrait être une version traduite automatiquement. Et les versions ultérieures du texte traduit pourraient être des améliorations proposées par les utilisateurs. Tout comme sur un wiki, les lecteurs pourraient choisir de voir les versions antérieures du texte traduit s’ils soupçonnent des problèmes de perte dans la traduction.

@icaria36

Grâce à la détection du navigateur, à la langue choisie par l’utilisateur lors de l’inscription, aux préférences utilisateur et à d’autres moyens à déterminer, le système déciderait quelle(s) langue(s) sont affichées à un utilisateur.
…
Encore une fois, la valeur par défaut serait l’anglais et les administrateurs pourraient définir d’autres combinaisons. L’utilisateur pourrait toujours accéder à ses préférences utilisateur et définir la ou les langues qu’il souhaite voir/ignorer. Il serait encore plus utile que les utilisateurs puissent définir la langue par défaut de publication, pour les éviter de sélectionner une balise de langue à chaque fois.

L’utilisateur doit avoir un moyen rapide de choisir la langue consommée (pour annuler toute décision prise par le système ou l’administrateur) - par exemple, via une liste déroulante de langues en haut à droite de l’écran. Par exemple, un visiteur anglophone (non connecté) se rendant en Chine pourrait souhaiter voir le texte en anglais, même si la détection du navigateur indique le chinois comme langue locale.

@icaria36

Les balises, les catégories et leurs descriptions pourraient être localisées.

J’adore cette idée de traduire les balises et les catégories. Cependant, certains termes techniques/scientifiques peuvent ne pas avoir de traduction et peuvent devoir rester dans la langue source.