Strukturierung einer mehrsprachigen Community

[Discourse]

Dieser Leitfaden erläutert verschiedene Ansätze zur Organisation eines Discourse-Forums für eine mehrsprachige Gemeinschaft, einschließlich der Vor- und Nachteile jeder Methode.

Erforderliche Benutzerstufe: Administrator

Discourse bietet mehrere Möglichkeiten, Ihre Site für eine mehrsprachige Gemeinschaft zu strukturieren. Dieser Leitfaden untersucht die gängigsten Ansätze sowie deren Vor- und Nachteile.

Dieses Thema ist nicht länger die Quelle empfohlener Ansätze zur Strukturierung einer mehrsprachigen Gemeinschaft, da wir nun die Verwendung der integrierten Content Localization-Funktionen in Discourse Core empfehlen, mit optionalen automatischen KI-Übersetzungen über das Discourse AI-Plugin. Für weitere Details besuchen Sie bitte Content Localization - Manual and Automatic with Discourse AI.

Verwendung von Kategorien zur Sprachentrennung

Kategorie „Andere Sprachen“ mit Unterkategorien

Ein Ansatz besteht darin, eine Hauptkategorie namens „Andere Sprachen“ mit Unterkategorien für bestimmte Sprachen zu erstellen.

So setzen Sie dies um:

1. Erstellen Sie eine neue Kategorie namens „Andere Sprachen“.
2. Fügen Sie Unterkategorien für jede unterstützte Sprache hinzu.
3. Ermutigen Sie Benutzer, in der entsprechenden Sprach-Unterkategorie zu posten.

Vorteile:

• Saubere Trennung zwischen den Sprachen
• Möglichkeit, kategorienbeschränkte Tags für eine zusätzliche Organisation innerhalb jeder Sprache zu verwenden

Nachteile:

• Mehrsprachige Benutzer müssen mehrere Kategorien mit ähnlichem Inhalt im Auge behalten
• Kann zu sprachbasierten Content-Silos führen

Separate Hauptkategorien für jede Sprache

Ein weiterer Ansatz besteht darin, separate Hauptkategorien für jede unterstützte Sprache zu erstellen.

So setzen Sie dies um:

1. Erstellen Sie eine neue Kategorie für jede unterstützte Sprache.
2. Verwenden Sie eine Theme-Komponente wie Custom Header Links, um Sprachumschalt-Links in der Kopfzeile hinzuzufügen.

Vorteile:

• Klare Unterscheidung zwischen den Sprachbereichen
• Einfache Navigation für Benutzer, die nur eine Sprache sprechen

Nachteile:

• Kann zu einer fragmentierten Community-Erfahrung führen
• Schwierig für mehrsprachige Benutzer, Diskussionen über Sprachgrenzen hinweg zu verfolgen
• Kann zu sprachbasierten Content-Silos führen

Verwendung von Tags zur Sprachidentifizierung

Forumweite Sprach-Tags

Dieser Ansatz umfasst das Erstellen von Tags für jede unterstützte Sprache und die Ermutigung der Benutzer, ihre Beiträge entsprechend zu taggen.

So setzen Sie dies um:

1. Erstellen Sie Tags für jede unterstützte Sprache (z. B. #english, #french, #spanish).
2. Ermutigen Sie Benutzer, beim Erstellen von Themen das entsprechende Sprach-Tag hinzuzufügen.
3. Optional können Sie Emojis in den Tag-Namen zur visuellen Unterscheidung verwenden.

Vorteile:

• Keine Notwendigkeit für separate Kategorien
• Mehrsprachige Benutzer können alle Inhalte leicht verfolgen
• Flexibel für Themen, die mehrere Sprachen umfassen können

Nachteile:

• Verlässt sich auf die Einhaltung durch die Benutzer für eine genaue Tagging
• Kann für Benutzer, die an eine kategoriebasierte Navigation gewöhnt sind, weniger intuitiv sein

Verwendung separater Discourse-Instanzen

Für Gemeinschaften mit distincten Sprachgruppen kann die Verwendung separater Discourse-Instanzen für jede Sprache in Betracht gezogen werden.

So setzen Sie dies um:

1. Richten Sie eine separate Discourse-Instanz für jede Sprache ein.
2. Verwenden Sie Subdomains oder separate Domains für jede Instanz (z. B. de.example.com, fr.example.com).
3. Verlinken Sie zwischen den Instanzen in der Kopf- oder Fußzeile mithilfe einer Theme-Komponente wie Custom Header Links.

Vorteile:

• Vollständige Trennung von Inhalten und Benutzern nach Sprache
• Möglichkeit, jede Instanz für ihre spezifische Sprachgemeinschaft anzupassen

Nachteile:

• Komplexer im Management mehrerer Instanzen
• Schwierig für mehrsprachige Benutzer, an Sprachgemeinschaften über Grenzen hinweg teilzunehmen
• Potenzial für doppelte Diskussionen und eine fragmentierte Community

Weitere Überlegungen

Lokalisierung von Kategorien und Tags

Discourse unterstützt nun die Lokalisierung von Kategoriennamen, Kategoriebeschreibungen und Tag-Namen über die integrierte Content Localization-Funktion. Aktivieren Sie content localization enabled und konfigurieren Sie content localization supported locales in Ihren Site-Einstellungen. Berechtigte Gruppen können manuelle Übersetzungen bereitstellen, oder automatische Übersetzungen können über das Discourse AI-Plugin konfiguriert werden.

Sprachpräferenzen der Benutzer

Discourse verfügt über integrierte Locale-Einstellungen, einschließlich allow user locale, set locale from accept language header, set locale from cookie und set locale from param. Diese ermöglichen es Benutzern, ihre bevorzugte Sprache für die Benutzeroberfläche festzulegen. Wenn Content Localization aktiviert ist, sehen Benutzer automatisch lokalisierte Inhalte basierend auf ihrer Locale-Präferenz.

Sprachumschalter

Die Einstellung content localization language switcher kann einen Sprachumschalter in der Kopfzeile anzeigen, der Besuchern (einschließlich anonymen Benutzern) ermöglicht, zwischen Ihren unterstützten Sprachen zu wechseln.

Suchfunktion

Stellen Sie sicher, dass Benutzer in allen Sprachen suchen oder Ergebnisse nach bestimmten Sprachen filtern können.

Weitere Ressourcen

• 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

Das Ziel ist es, einen Diskussionsraum zu schaffen, der sich für Sprecher jeder Sprache (und jeder Sprachkombination) als ihr eigener anfühlt – im Gegensatz zu einem englischsprachigen Forum mit einer mehrsprachigen Ecke oder einem Forum, das in viele Sprachen aufgeteilt ist und effektiv zu vielen separaten Foren wird.

Was macht eine Gemeinschaft zu einer Gemeinschaft? In einem weitgehend textbasierten Medium scheint die Fähigkeit, die textbasierte Kommunikation anderer Mitglieder zu verstehen, entscheidend zu sein. Ich frage mich daher, ob es möglich ist, die beiden von dir genannten Fallstricke (‚Verschließung‘ oder ‚Tokenismus‘) in einem weitgehend textbasierten Medium (ohne perfekte automatische Übersetzung) vollständig zu überwinden.

Eine Gemeinschaft, die mir dabei einfällt, ist https://discourse.mozilla.org

@icaria36

Dafür wäre der Hauptbaustein ein tag, der spezifisch für Sprachen ist. Dieser Tag wäre für alle Themen erforderlich und würde standardmäßig auf Englisch gesetzt. Themen in anderen Sprachen würden entsprechend getaggt.

Derzeit haben wir die Option, eine bestimmte Anzahl von Tags für einen Beitrag in einer Kategorie vorzuschreiben, siehe The option to enforce tagging (Kategorie-Einstellung „Mindestanzahl erforderlicher Tags in einem Thema“).

Dieser Anwendungsfall würde jedoch von einer etwas anderen Einstellung profitieren: „Tag aus einer Tag-Gruppe erforderlich“. Die Anwendung wäre wie folgt:

• Erstellen einer Tag-Gruppe mit einer festgelegten Liste von Sprachen
• Vorschreiben, dass jedes neue Thema mindestens einen Tag aus dieser Gruppe enthält, bevor es veröffentlicht wird.

@HAWK Ich bin neugierig, ob einige der anderen Anwendungsfälle für diese Art von Einstellung, die du im verlinkten Thema erwähnt hast, von etwas Ähnlichem profitieren würden (oder ob sie vollständig durch die bestehende Einstellung „Mindestanzahl erforderlicher Tags in einem Thema“ abgedeckt sind)?

@icaria36

Durch eine Sprachleiste, die sich aus den Tag-Titeln speist, könnten Nutzer die in einer bestimmten Sprache verfügbaren Themen sehen.

Dies könnte in einer allgemein nützlichen Weise umgesetzt werden: Eine Tag-Navigationskomponente, die Tags aus einer bestimmten Gruppe anzeigt.

@icaria36

Durch Browser-Erkennung, die vom Nutzer bei der Registrierung gewählte Sprache, Benutzereinstellungen und andere noch zu bestimmende Mittel würde das System entscheiden, welche Sprache(n) einem Nutzer angezeigt werden.

Discourse ermöglicht es Nutzern derzeit, ihr Locale festzulegen (gesteuert durch die Site-Einstellung „allow user locale“) und führt eine automatische Erkennung des Locales durch, gesteuert durch die Site-Einstellung „set locale from accept language header“. Es gibt drei Kontexte für die automatische Erkennung:

• Gäste (Browser und Header)
• Registrierungen (ebd.)
• Einladungen (ebd.) – hier gibt es vielleicht ein Problem? (siehe) (@schungx?)

Vielleicht wären die beiden Verbesserungen, die hier möglich wären:

• Eine Einstellung hinzufügen, die es einem Nutzer erlaubt, sein Locale im Registrierungsformular manuell festzulegen
• Einen „Locale-Switcher“ für Gäste hinzufügen, ähnlich wie bei Facebook (siehe untere Leiste der Registrierungsseite). Ich habe dies bereits für ein anderes Projekt erstellt, habe es aber noch nicht als Plugin umgesetzt.

@icaria36

Tags, Kategorien und deren Beschreibungen könnten lokalisiert werden.

Ich finde diesen Punkt wirklich interessant und denke, es wäre definitiv lohnenswert, dies auszuprobieren. Tags, Kategorien und Kategorienbeschreibungen sind das, was ein Nutzer oft zuerst liest, bevor er ein tatsächliches Thema liest. Diese tragen häufig zum Gefühl des Nutzers gegenüber der Gemeinschaft bei. Wenn sie Wörter und Beschreibungen sehen, mit denen sie sich identifizieren können, sind sie eher geneigt, sich mit der Gemeinschaft selbst zu identifizieren. Selbst wenn nach dem Betreten des Themas eine andere Sprache verwendet wird, ist das Interesse und das Gefühl für die Gemeinschaft bereits geweckt.

Außerdem ist es einfacher, Kategorienbeschreibungen und Tags zu lokalisieren als ganze Themen. Technisch ist dies machbar, wurde aber noch nicht ausprobiert. Siehe weiter. @erlend_sh Wissen Sie von weiteren Arbeiten dazu oder von Beispielen?

@icaria36

Nutzer könnten in allen Sprachen suchen oder nach ihren im Profil definierten Sprachen filtern.

Wenn alle Sprach-Tags in einer einzigen Tag-Gruppe sind, wäre der nächste Schritt, einen tag-gruppenspezifischen Tag-Filter auf der Seite für die erweiterte Suche hinzuzufügen.

Zusammenfassung der oben genannten Änderungen:

• Eine Site- oder Kategorie-Einstellung „Tag aus einer Tag-Gruppe erforderlich"
• Eine Tag-Navigationskomponente, die Tags aus einer bestimmten Gruppe anzeigt
• Eine Einstellung, die es einem Nutzer erlaubt, sein Locale im Registrierungsformular manuell festzulegen
• Ein „Locale-Switcher“ für Gäste
• Lokalisierung von Tags, Kategoriennamen und Kategorienbeschreibungen
• Hinzufügen eines tag-gruppenspezifischen Tag-Filters auf der Seite für die erweiterte Suche

[schungx (Stephen Chung)]

Einladungen (ebd.) – gibt es hier vielleicht ein Problem? (siehe 1) (@schungx?)

Soweit ich das beurteilen kann, werden Einladungs-E-Mails in der Standardsprache der Website versendet, aber der Benutzer erhält seine eigene Lokalisierung, sobald er sich anmeldet.

Derzeit gibt es keine Möglichkeit, die Sprache von Einladungen festzulegen…

[HAWK]

@angus

Ich frage mich, ob einige der anderen Anwendungsfälle für diese Art von Einstellung, die du im verlinkten Thema erwähnt hast, von etwas Ähnlichem profitieren würden (oder ob sie bereits vollständig durch die bestehende Einstellung „Mindestanzahl an Tags pro Thema“ abgedeckt sind)?

Mir fällt spontan nichts ein, aber wir sehen immer mehr mehrsprachige Communities. Wenn dies diesen speziellen Anwendungsfall vereinfacht, halte ich die Anfrage für berechtigt.

[debryc (Deborah Chang)]

@angus

Dieser Anwendungsfall würde jedoch von einer etwas anderen Einstellung profitieren: „Tag aus einer Tag-Gruppe erfordern“. So würdest du das nutzen:

• Erstelle eine Tag-Gruppe mit einer festgelegten Liste von Sprachen.
• Stelle sicher, dass jeder neue Beitrag mindestens ein Tag aus dieser Gruppe enthält, bevor er veröffentlicht wird.

@HAWK Ich unterstütze diese Funktion ebenfalls. Ich sehe dafür zahlreiche Anwendungsmöglichkeiten, die über die Anforderung von Sprach-Tags hinausgehen. Beispielsweise haben wir derzeit eine Tag-Gruppe namens „Projektmanagement“ mit den Tags #Idee, #Abgrenzung, #bereit, #inBearbeitung, #feiern, #evaluieren, #erledigt. Es wäre großartig, wenn man verlangen könnte, dass Nutzer jeden Beitrag in bestimmten Kategorien korrekt mit dem entsprechenden Projektmanagement-Status versehen.

[HAWK]

@neil, was hältst du davon? Wie viel Aufwand wäre damit verbunden, die Vorgabe zu erzwingen, dass aus einer bestimmten Tag-Gruppe genau ein Tag verwendet werden muss?

Hinweis: Wir haben die Regel der Drei noch nicht erreicht, aber ich bin trotzdem an Antworten auf die oben genannten Fragen interessiert.

[JimPas]

Das klingt auch für mein Forum interessant. Wir haben hauptsächlich englischsprachige Mitglieder, aber auch spanischsprachige. Wir übersetzen ständig hin und her. Die Idee mit zwei separaten Foren (in verschiedenen Sprachen) kommt für uns nicht infrage. Aber eine automatisch übersetzte zweisprachige Website – mit einer vom Benutzer festgelegten Standardsprache – wäre großartig!

[neil (Neil Lalonde)]

@HAWK

Wie viel Aufwand wäre mit der Durchsetzung eines Tags aus einer bestimmten Tag-Gruppe verbunden?

Es wäre einfach, eine Möglichkeit hinzuzufügen, um die Pflicht zur Verwendung eines Tags aus einer Tag-Gruppe zu erzwingen. In diesem Fall (eine Sprache auswählen) möchten wir vermutlich genau ein Tag erzwingen, aber ich vermute, dass einige Personen mindestens ein Tag wünschen (ähnlich wie die Einstellung „Mindestanzahl erforderlicher Tags in einem Thema“). Ich würde eher „mindestens ein Tag aus einer bestimmten Tag-Gruppe“ implementieren, da wir dies bereits bei Car Talk beobachten können: Es ist zwar möglich, Themen mit allen Marken- und Modell-Tags zu versehen, aber das geschieht nicht. Außerdem kann in einer mehrsprachigen Community manchmal mehr als eine Sprache sinnvoll sein.

[HAWK]

Ja, das klingt für mich schlau.

[angus (Angus McLeod)]

@neil

Ich würde es vorziehen, „mindestens ein Tag aus einer bestimmten Tag-Gruppe" umzusetzen.

Vielleicht wäre der richtige Weg, dies als numerisches Minimum und nicht als booleschen Wert hinzuzufügen, um eine feinere Kontrolle zu ermöglichen und gleichzeitig die Möglichkeit zu lassen, später auch ein Maximum hinzuzufügen.

[neil (Neil Lalonde)]

Ich habe das heute gebaut. Es ist eine Einstellung pro Kategorie im Reiter „Tags":

Eine Verbesserungsmöglichkeit besteht darin, wie Nutzer erkennen können, welche Tags zur Auswahl stehen. Momentan wird nur der Name der Tag-Gruppe angezeigt. Es wäre besser, wenn die Tags selbst aufgelistet würden oder – falls zu viele vorhanden sind – die beliebtesten Tags der Gruppe.

@debryc @angus Was haltet ihr davon?

[debryc (Deborah Chang)]

Das ist ja so aufregend, Neil!

1. Ich finde die Einstellungsdarstellung perfekt.
2. Ich stimme zu, dass es eine gewisse Anzeige dafür geben muss, welche Tags zur Auswahl stehen.

Vielleicht sollte man im Tag-Dropdown des Editors zuerst die Tag-Gruppe und ihre Tag-Optionen anzeigen, bevor andere beliebige Tags gezeigt werden.

Oder vielleicht enthält die Fehlermeldung eine Nachricht wie „Wählen Sie vor dem Posten einen der folgenden Tags aus“. Nutzer könnten dann auf den Tag-Namen klicken, um ihn hinzuzufügen!

[neil (Neil Lalonde)]

@debryc

Vielleicht sollte im Dropdown-Menü für Tags des Editors zuerst die Tag-Gruppe und ihre Tag-Optionen angezeigt werden, bevor andere beliebige Tags erscheinen.

Ich habe mich für diesen Ansatz entschieden. Die erforderlichen Tags werden vom Tag-Eingabefeld vorgeschlagen, falls noch keines ausgewählt wurde.

[achebe]

@icaria36

Standardmäßig würden Themen in allen Sprachen angezeigt werden. Administratoren könnten als Standard nur eine Sprache, eine Kombination von Sprachen oder alle Sprachen festlegen …

Über eine Sprachleiste, die die Titel der Tags verwendet, könnten Nutzer die in einer bestimmten Sprache verfügbaren Themen sehen.

Noch ein Gedanke:
Um mehreren Sprachen gerecht zu werden, muss ein Nutzer in der Lage sein, den Quelltext in der für ihn/sie bequemsten Sprache zu verfassen/auszudrücken. Und der Leser muss den übersetzten Text in der für ihn/sie bequemsten Sprache lesen können. Um Probleme durch Übersetzungsverluste zu minimieren, wäre es vorteilhaft, Quelltext und übersetzten Text nebeneinander anzuzeigen. Die Basisversion des übersetzten Textes könnte eine automatisch übersetzte Version sein. Nachfolgende Versionen des übersetzten Textes könnten von Nutzern eingebrachte Verbesserungen sein. Genau wie bei einem Wiki könnten Leser frühere Versionen des übersetzten Textes einsehen, wenn sie Übersetzungsverluste vermuten.

@icaria36

Durch Browsererkennung, die vom Nutzer bei der Registrierung gewählte Sprache, Nutzerpräferenzen und weitere noch zu bestimmende Mittel würde das System entscheiden, welche Sprache(n) einem Nutzer angezeigt werden.
…
Wiederum wäre die Standardsprache Englisch, und Administratoren könnten andere Kombinationen definieren. Der Nutzer könnte jederzeit in seine Nutzerpräferenzen gehen und die Sprache(n) festlegen, die er/sie sehen oder ignorieren möchte. Es wäre zusätzlich nützlich, wenn Nutzer die Standardsprache für Beiträge festlegen könnten, um sie vor der Auswahl eines Sprach-Tags bei jedem Beitrag zu bewahren.

Nutzer müssen eine schnelle Möglichkeit haben, die konsumierte Sprache auszuwählen (um Entscheidungen des Systems oder der Administratoren zu überschreiben) – beispielsweise über ein Dropdown-Menü für Sprachen in der oberen rechten Ecke des Bildschirms. Zum Beispiel könnte ein englischsprachiger Gastnutzer (nicht angemeldet), der nach China reist, Texte auf Englisch sehen möchten, obwohl die Browsererkennung Chinesisch als lokale Sprache anzeigt.

@icaria36

Tags, Kategorien und ihre Beschreibungen könnten lokalisiert werden.

Ich liebe diese Idee, Tags und Kategorien zu übersetzen. Allerdings haben einige technische/wissenschaftliche Begriffe möglicherweise keine Übersetzungen und müssen in der Ausgangssprache bleiben.