Strutturare una comunità multilingue

[Discourse]

Questa guida illustra diversi approcci per organizzare un forum Discourse per una comunità multilingue, inclusi pro e contro di ciascun metodo.

Livello utente richiesto: Amministratore

Discourse offre diversi modi per strutturare il tuo sito per una comunità multilingue. Questa guida esplorerà gli approcci più comuni e i loro vantaggi e svantaggi.

Questo argomento non è più la fonte di riferimento per gli approcci raccomandati alla strutturazione di una comunità multilingue, poiché ora raccomandiamo l’utilizzo delle funzionalità integrate di Localizzazione dei contenuti nel nucleo di Discourse, con traduzioni automatiche opzionali tramite AI tramite il plugin Discourse AI. Per ulteriori dettagli, consulta Content Localization - Manual and Automatic with Discourse AI.

Utilizzo delle categorie per la separazione linguistica

Categoria “Altre lingue” con sottocategorie

Un approccio consiste nel creare una categoria principale denominata “Altre lingue” con sottocategorie per lingue specifiche.

Come implementare:

1. Crea una nuova categoria chiamata “Altre lingue”
2. Aggiungi sottocategorie per ogni lingua che desideri supportare
3. Incoraggia gli utenti a pubblicare nella sottocategoria linguistica appropriata

Pro:

• Separazione chiara tra le lingue
• Possibilità di utilizzare tag con restrizioni per categoria per un’organizzazione aggiuntiva all’interno di ciascuna lingua

Contro:

• Gli utenti multilingue devono tenere traccia di più categorie con contenuti simili
• Può portare a silos di contenuti basati sulla lingua

Categorie di livello superiore separate per ciascuna lingua

Un altro approccio consiste nel creare categorie di livello superiore separate per ogni lingua supportata.

Come implementare:

1. Crea una nuova categoria per ogni lingua che desideri supportare
2. Utilizza un componente del tema come Custom Header Links per aggiungere collegamenti per il cambio lingua nell’intestazione

Pro:

• Distinzione chiara tra le sezioni linguistiche
• Navigazione semplice per gli utenti che parlano una sola lingua

Contro:

• Può creare un’esperienza di comunità frammentata
• Difficile per gli utenti multilingue seguire le discussioni tra le lingue
• Può portare a silos di contenuti basati sulla lingua

Utilizzo dei tag per l’identificazione linguistica

Tag linguistici a livello di forum

Questo approccio prevede la creazione di tag per ogni lingua supportata e l’incoraggiamento degli utenti a etichettare i propri post di conseguenza.

Come implementare:

1. Crea tag per ogni lingua che desideri supportare (ad es. #inglese, #francese, #spagnolo)
2. Incoraggia gli utenti ad aggiungere il tag linguistico appropriato quando creano nuovi argomenti
3. Opzionalmente, utilizza emoji nei nomi dei tag per una distinzione visiva

Pro:

• Non è necessario creare categorie separate
• Gli utenti multilingue possono seguire facilmente tutti i contenuti
• Flessibile per argomenti che possono coinvolgere più lingue

Contro:

• Dipende dalla conformità degli utenti per un tagging accurato
• Potrebbe essere meno intuitivo per gli utenti abituati alla navigazione basata sulle categorie

Utilizzo di istanze Discourse separate

Per comunità con gruppi linguistici distinti, si può prendere in considerazione l’uso di istanze Discourse separate per ogni lingua.

Come implementare:

1. Configura un’istanza Discourse separata per ogni lingua
2. Utilizza sottodomini o domini separati per ogni istanza (ad es. it.esempio.com, fr.esempio.com)
3. Crea collegamenti tra le istanze nell’intestazione o nel piè di pagina utilizzando un componente del tema come Custom Header Links

Pro:

• Separazione completa di contenuti e utenti per lingua
• Possibilità di personalizzare ogni istanza per la propria comunità linguistica specifica

Contro:

• Gestione più complessa di più istanze
• Difficile per gli utenti multilingue partecipare tra le comunità linguistiche
• Rischio di discussioni duplicate e di una comunità frammentata

Considerazioni aggiuntive

Localizzazione di categorie e tag

Discourse supporta ora la localizzazione dei nomi delle categorie, delle descrizioni delle categorie e dei nomi dei tag tramite la funzionalità integrata di Localizzazione dei contenuti. Abilita content localization enabled e configura content localization supported locales nelle impostazioni del sito. I gruppi autorizzati possono fornire traduzioni manuali, oppure è possibile configurare traduzioni automatiche tramite il plugin Discourse AI.

Preferenze linguistiche degli utenti

Discourse dispone di impostazioni di locale integrate, tra cui allow user locale, set locale from accept language header, set locale from cookie e set locale from param. Queste consentono agli utenti di impostare la propria lingua preferita per l’interfaccia. Quando la Localizzazione dei contenuti è abilitata, gli utenti vedranno automaticamente i contenuti localizzati in base alla loro preferenza di locale.

Selettore di lingua

L’impostazione content localization language switcher può visualizzare un selettore di lingua nell’intestazione, consentendo ai visitatori (inclusi gli utenti anonimi) di passare tra le lingue supportate.

Funzionalità di ricerca

Assicurati che gli utenti possano cercare in tutte le lingue o filtrare i risultati per lingue specifiche.

Risorse aggiuntive

• 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’obiettivo è offrire uno spazio di discussione che i parlanti di qualsiasi lingua (e combinazioni di lingue) possano sentire come proprio, al contrario di un forum in inglese con un angolo multilingue o di un forum suddiviso in molte lingue che diventa di fatto tanti forum separati.

Cosa rende una comunità percepita come tale? In un mezzo prevalentemente basato sul testo, la capacità di comprendere la comunicazione testuale degli altri membri sembra fondamentale; mi chiedo quindi se sia possibile superare completamente i due ostacoli che hai menzionato (‘siloizzazione’ o ‘tokenismo’) in un mezzo prevalentemente testuale (senza una traduzione automatica perfetta).

Una comunità che mi viene in mente è https://discourse.mozilla.org

@icaria36

Per questo, il blocco principale sarebbe un tag specifico per le lingue. Questo tag sarebbe obbligatorio per tutti i topic e avrebbe come valore predefinito l’inglese. I topic in lingue diverse dall’inglese verrebbero contrassegnati di conseguenza.

Attualmente abbiamo l’opzione di richiedere un certo numero di tag in un post all’interno di una categoria, vedi The option to enforce tagging (impostazione della categoria “Numero minimo di tag richiesti in un topic”).

Tuttavia, questo caso d’uso beneficerebbe di un’impostazione leggermente diversa: “Richiedi tag da un gruppo di tag”. Il modo in cui si utilizzerebbe sarebbe il seguente:

• Creare un tag_group con un elenco fisso di lingue
• Richiedere che ogni nuovo topic abbia un tag aggiunto da questo gruppo prima di essere pubblicato.

@HAWK Sono curioso di sapere se alcuni degli altri casi d’uso per questo tipo di impostazione che hai menzionato nel topic collegato beneficerebbero di qualcosa di simile (o se sono completamente coperti dall’impostazione esistente “Numero minimo di tag richiesti in un topic”?)

@icaria36

Attraverso una barra delle lingue che attinge dai titoli dei tag, gli utenti potrebbero vedere i topic disponibili in una lingua specifica.

Questo potrebbe essere realizzato in un modo che potrebbe essere generalmente utile: un componente di navigazione dei tag che visualizza i tag di un gruppo specifico.

@icaria36

Attraverso il rilevamento del browser, la lingua scelta dall’utente durante la registrazione, le preferenze dell’utente e altri metodi da determinare, il sistema deciderebbe quale/i lingua/e mostrare a un utente.

Discourse consente attualmente all’utente di impostare la propria localizzazione (attivata dall’impostazione del sito allow user locale) ed esegue il rilevamento automatico della localizzazione, attivato dall’impostazione del sito set locale from accept language header. Esistono tre contesti di rilevamento automatico:

• Ospiti (browser e intestazioni)
• Registrazioni (come sopra)
• Inviti (come sopra) - forse c’è un problema con questo? (vedi) (@schungx?)

Forse i due miglioramenti che potrebbero essere apportati qui sarebbero:

• aggiungere un’impostazione per consentire a un utente di impostare manualmente la propria localizzazione nel modulo di registrazione
• aggiungere un ‘selettore di localizzazione’ per gli ospiti, simile a quello di Facebook (vedi la barra inferiore della pagina di registrazione). In realtà l’ho realizzato per un progetto diverso, ma non l’ho ancora trasformato in un plugin.

@icaria36

I tag, le categorie e le loro descrizioni potrebbero essere localizzati.

Trovo questo punto davvero interessante e penso che sarebbe sicuramente interessante provarlo. I tag, le categorie e le descrizioni delle categorie sono ciò che un utente legge spesso prima di leggere un vero e proprio topic. Questi spesso contribuiscono al senso di appartenenza dell’utente alla comunità. Se vedono parole e descrizioni con cui si identificano, è più probabile che si identifichino con la comunità stessa. Quindi anche se c’è una lingua diversa una volta che l’utente entra nel topic, il suo interesse e il suo senso di appartenenza alla comunità sono già stati stimolati.

È anche più facile localizzare le descrizioni delle categorie e i tag rispetto a localizzare interi topic. Tecnicamente parlando, è fattibile, ma non è ancora stato provato. Vedi oltre. @erlend_sh Conosci altri lavori o esempi al riguardo?

@icaria36

Gli utenti potrebbero cercare in tutte le lingue o filtrare per le loro lingue definite nei loro profili.

Se i tag linguistici sono tutti in un unico tag_group, la soluzione qui sarebbe aggiungere un filtro di tag specifico per il gruppo di tag alla pagina di ricerca avanzata.

Per riassumere le modifiche che ho menzionato sopra:

• Un’impostazione del sito o della categoria “Richiedi tag da un gruppo di tag”
• Un componente di navigazione dei tag che visualizza i tag di un gruppo specifico
• Un’impostazione per consentire a un utente di impostare manualmente la propria localizzazione nel modulo di registrazione
• Un ‘selettore di localizzazione’ per gli ospiti
• Localizzazione di tag, nomi delle categorie e descrizioni delle categorie
• Aggiunta di un filtro di tag specifico per il gruppo di tag alla pagina di ricerca avanzata

[schungx (Stephen Chung)]

Inviti (ibid) - c’è forse un problema con questo? (vedi 1) (@schungx?)

Per quanto ne so, le email di invito verranno inviate nella lingua predefinita del sito, ma l’utente riceverà la propria localizzazione una volta effettuato l’accesso.

Attualmente non esiste un modo per specificare la lingua degli inviti…

[HAWK]

@angus

Sono curioso di sapere se alcuni degli altri casi d’uso per questo tipo di impostazione menzionati nell’argomento collegato trarrebbero beneficio da qualcosa di simile (o se sono già completamente coperti dall’impostazione esistente “Numero minimo di tag richiesti in un argomento”).

Non mi viene in mente nulla, ma stiamo vedendo sempre più comunità multilingue; se ciò dovesse semplificare quel particolare caso d’uso, penso che sia una richiesta legittima.

[debryc (Deborah Chang)]

@angus

Tuttavia, questo caso d’uso trarrebbe vantaggio da una configurazione leggermente diversa: “Richiedi un tag da un gruppo di tag”. Il modo in cui lo useresti sarebbe il seguente:

• Crea un tag_group con un elenco fisso di lingue
• Richiedi che ogni nuovo argomento abbia almeno un tag aggiunto da questo gruppo prima di essere pubblicato.

@HAWK Supporto anch’io questa funzionalità. Posso vedere molti utilizzi oltre alla richiesta di tag linguistici. Ad esempio, attualmente abbiamo un gruppo di tag chiamato “project management” con i tag #idea, #scoping, #ready, in-progress, #celebrating, #evaluating, done. Sarebbe incredibile obbligare gli utenti a taggare correttamente ogni post che pubblicano con la fase appropriata di project management all’interno di determinate categorie.

[HAWK]

@neil, cosa ne pensi? Quanto lavoro comporterebbe imporre un solo tag da un gruppo di tag specifico?

Nota che non abbiamo ancora raggiunto la regola del tre, ma sono comunque interessato alle risposte alla domanda sopra.

[JimPas]

Questo sembrerebbe interessante anche per il mio forum. Abbiamo principalmente membri di lingua inglese, ma anche membri di lingua spagnola. Traduciamo sempre avanti e indietro. L’idea di due forum separati (lingue diverse) non fa per noi. Ma un sito bilingue con traduzione automatica - con lingua predefinita specificata dall’utente - sarebbe fantastico!

[neil (Neil Lalonde)]

@HAWK

Quanto lavoro comporterebbe imporre l’uso di un solo tag da un gruppo specifico di tag?

Sarebbe semplice aggiungere la possibilità di imporre l’uso di almeno un tag da un gruppo di tag. Immagino che in questo caso (scegliere una lingua) si voglia imporre esattamente un tag, ma credo che alcune persone potrebbero preferire almeno un tag (simile all’impostazione “Numero minimo di tag richiesti in un argomento”). Preferirei implementare “almeno un tag da un gruppo specifico di tag”, poiché possiamo già vedere qualcosa di simile in azione su Car Talk, dove è possibile per gli utenti contrassegnare i propri argomenti con tutti i tag relativi ai marchi e ai modelli di auto, ma ciò non accade. Inoltre, in una comunità multilingue, a volte ha senso utilizzare più di una lingua.

[HAWK]

Sì, mi sembra una buona idea.

[angus (Angus McLeod)]

@neil

Preferirei implementare “almeno un tag da un gruppo di tag specifico”.

Forse il modo migliore per farlo sarebbe aggiungerlo come minimo numerico, anziché booleano, per avere un controllo più granulare e lasciare anche la porta aperta all’aggiunta di un massimo?

[neil (Neil Lalonde)]

L’ho costruito oggi. È un’impostazione per categoria nella scheda Tag:

Un aspetto che può essere migliorato è come gli utenti possono sapere quali tag hanno a disposizione. Al momento viene mostrato il nome del gruppo di tag, ma sarebbe meglio elencare i tag stessi o, nel caso in cui siano troppi per essere elencati tutti, i tag più popolari del gruppo.

@debryc @angus Cosa ne pensate?

[debryc (Deborah Chang)]

Che emozione, Neil!

1. Penso che la visualizzazione delle impostazioni sia perfetta.
2. Sono d’accordo sul fatto che serva un’indicazione dei tag tra cui scegliere.

Forse, nel menu a tendina dei tag del compositore, si potrebbero mostrare prima il gruppo di tag e le relative opzioni, prima di elencare gli altri tag popolari.

Oppure, il messaggio di errore potrebbe includere una frase come “seleziona uno dei seguenti tag prima di pubblicare”. Gli utenti potrebbero fare clic sul nome del tag per aggiungerlo!

[neil (Neil Lalonde)]

@debryc

Forse nel menu a tendina dei tag del compositore, mostrare prima il gruppo di tag e le sue opzioni di tag, prima di mostrare gli altri tag popolari.

Ho optato per questo approccio. I tag richiesti verranno suggeriti dall’input dei tag se non è ancora stato scelto.

[achebe]

@icaria36

Di default, l’argomento mostrerebbe argomenti in tutte le lingue. Gli amministratori potrebbero configurare come predefinito una sola lingua, una combinazione di lingue, mantenere tutte le lingue…

Attraverso una barra linguistica che si basa sui titoli dei tag, gli utenti potrebbero vedere gli argomenti disponibili in una lingua specifica.

Un’altra riflessione:
Per essere equi verso più lingue, un utente deve poter produrre/esprimere (testo sorgente) nella lingua più comoda per lui/lei. E il lettore deve poter consumare/leggere nella lingua più comoda per lui/lei (testo tradotto). Per minimizzare i problemi di “perdita nella traduzione”, sarebbe utile mostrare affiancati sia il testo sorgente che il testo tradotto. La versione base del testo tradotto potrebbe essere una versione tradotta automaticamente. Le versioni successive del testo tradotto potrebbero essere miglioramenti contribuiti dagli utenti. Proprio come in una wiki, i lettori potrebbero scegliere di vedere le versioni precedenti del testo tradotto se sospettano problemi di “perdita nella traduzione”.

@icaria36

Attraverso il rilevamento del browser, la lingua scelta dall’utente durante la registrazione, le preferenze dell’utente e altri metodi da determinare, il sistema deciderebbe quale/i lingua/e mostrare a un utente.
…
Ancora una volta, il predefinito sarebbe l’inglese e gli amministratori potrebbero definire altre combinazioni. L’utente potrebbe sempre andare alle proprie preferenze utente e impostare la/e lingua/e che desidera vedere/ignorare. Sarebbe ulteriormente utile se gli utenti potessero impostare la lingua predefinita per la pubblicazione, per evitare di dover selezionare un tag linguistico ogni volta.

L’utente deve avere un modo rapido per scegliere la lingua di consumo (per sovrascrivere eventuali decisioni prese dal sistema o dall’amministratore) - ad esempio tramite un menu a discesa delle lingue nell’angolo in alto a destra dello schermo. Ad esempio, un utente ospite di lingua inglese (non collegato) in viaggio in Cina potrebbe voler vedere il testo in inglese, anche se il rilevamento del browser potrebbe indicare il cinese come lingua locale.

@icaria36

Tag, categorie e le loro descrizioni potrebbero essere localizzati.

Adoro questa idea di tradurre tag e categorie. Tuttavia, alcuni termini tecnici/scientifici potrebbero non avere traduzioni e potrebbero dover rimanere nella lingua originale.