多言語コミュニティの構築

:bookmark: このガイドでは、多言語コミュニティ向けに Discourse フォーラムを構成するさまざまなアプローチ、それぞれの長所と短所について解説します。

:person_raising_hand: 必要なユーザーレベル:管理者

Discourse では、多言語コミュニティ向けにサイトを構成するためのいくつかの方法を提供しています。このガイドでは、最も一般的なアプローチとそのメリット・デメリットを探ります。

:spiral_notepad: このトピックはもはや多言語コミュニティの構成に関する推奨アプローチのソースではありません。現在、Discourse コアに組み込まれた コンテンツローカライゼーション 機能の使用(オプションで Discourse AI プラグインによる自動 AI 翻訳も可能)が推奨されています。詳細については、Content Localization - Manual and Automatic with Discourse AI をご覧ください。

カテゴリを使用して言語を分離する

「その他の言語」カテゴリとサブカテゴリ

一つの手法として、「その他の言語」というメインカテゴリを作成し、特定の言語ごとにサブカテゴリを設ける方法があります。

実装方法:

  1. 「その他の言語」という新しいカテゴリを作成します。
  2. 対応する各言語ごとにサブカテゴリを追加します。
  3. ユーザーが適切な言語のサブカテゴリに投稿するよう促します。

メリット:

  • 言語間の明確な分離
  • 各言語内で追加の整理を可能にするカテゴリ制限付きタグの使用

デメリット:

  • 多言語ユーザーは類似の内容を持つ複数のカテゴリを追跡する必要がある
  • 言語に基づいたコンテンツのサイロ化を招く可能性がある

各言語ごとに独立したトップレベルカテゴリを作成する

もう一つの手法として、対応する各言語ごとに独立したトップレベルカテゴリを作成する方法があります。

実装方法:

  1. 対応する各言語ごとに新しいカテゴリを作成します。
  2. Custom Header Links のようなテーマコンポーネントを使用して、ヘッダーに言語切り替えリンクを追加します。

メリット:

  • 言語セクション間の明確な区別
  • 単一言語しか話さないユーザーにとって容易なナビゲーション

デメリット:

  • コミュニティ体験が分断される可能性がある
  • 多言語ユーザーが言語を超えた議論を追うのが困難
  • 言語に基づいたコンテンツのサイロ化を招く可能性がある

タグを使用して言語を識別する

フォーラム全体の言語タグ

このアプローチでは、対応する各言語のタグを作成し、ユーザーが投稿時にそれらのタグを付けるよう促す方法です。

実装方法:

  1. 対応する各言語のタグを作成します(例:#english、#french、#spanish)。
  2. ユーザーがトピック作成時に適切な言語タグを追加するよう促します。
  3. 必要に応じて、視覚的な区別のためにタグ名に絵文字を使用します。

メリット:

  • 独立したカテゴリを必要としない
  • 多言語ユーザーがすべてのコンテンツを簡単にフォローできる
  • 複数の言語が関わるトピックに対して柔軟性がある

デメリット:

  • 正確なタグ付けにはユーザーの協力が不可欠
  • カテゴリベースのナビゲーションに慣れたユーザーには直感的でない場合がある

独立した Discourse インスタンスを使用する

明確に分離された言語グループを持つコミュニティの場合、各言語ごとに独立した Discourse インスタンスを使用することも検討できます。

実装方法:

  1. 各言語ごとに独立した Discourse インスタンスを設定します。
  2. 各インスタンスにサブドメインまたは独立したドメインを使用します(例:en.example.comfr.example.com)。
  3. Custom Header Links のようなテーマコンポーネントを使用して、ヘッダーまたはフッター間でインスタンスをリンクします。

メリット:

  • 言語によるコンテンツとユーザーの完全な分離
  • 各インスタンスを特定の言語コミュニティに合わせてカスタマイズ可能

デメリット:

  • 複数のインスタンスの管理が複雑
  • 多言語ユーザーが言語コミュニティ間で参加するのが困難
  • 重複した議論や分断されたコミュニティのリスク

その他の考慮事項

カテゴリとタグのローカライゼーション

Discourse は、組み込みのコンテンツローカライゼーション機能を通じて、カテゴリ名、カテゴリ説明、タグ名のローカライゼーションをサポートしています。サイト設定で content localization enabled を有効にし、content localization supported locales を設定してください。承認されたグループが手動翻訳を提供することも、Discourse AI プラグインを通じて自動翻訳を設定することも可能です。

ユーザーの言語設定

Discourse には、allow user localeset locale from accept language headerset locale from cookieset locale from param などの組み込みのロケール設定があります。これにより、ユーザーはインターフェースの優先言語を設定できます。コンテンツローカライゼーションが有効になっている場合、ユーザーは自分のロケール設定に基づいてローカライズされたコンテンツを自動的に表示します。

言語スイッチャー

content localization language switcher 設定を使用すると、ヘッダーに言語スイッチャーを表示できます。これにより、訪問者(匿名ユーザーを含む)が対応する言語間を切り替えることができます。

検索機能

ユーザーがすべての言語で検索できるか、または特定の言語で結果をフィルタリングできることを確認してください。

その他のリソース

「いいね!」 20

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.

「いいね!」 8

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).

「いいね!」 2

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)

「いいね!」 6

I like your approach. How you did it?

「いいね!」 1

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.
「いいね!」 6

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?

「いいね!」 9

コミュニティが「コミュニティ」として感じられる要因は何でしょうか?主にテキストベースの媒体においては、他のメンバーとのテキストベースのコミュニケーションを理解できることが鍵のように思われます。つまり、完全な自動翻訳なしに、主にテキストベースの媒体であなたが挙げた2つの落とし穴(「サイロ化」または「象徴的な対応」)を完全に克服できるかどうか疑問に思います。

ここで思い浮かぶコミュニティの1つに https://discourse.mozilla.org があります。

現在、カテゴリ内の投稿に一定数のタグを必須とするオプションがあります(https://meta.discourse.org/t/the-option-to-enforce-tagging/69527、カテゴリ設定「トピックに必須の最小タグ数」を参照)。

ただし、このユースケースでは、「タググループからタグを必須とする」という少し異なる設定が役立ちます。その使い方は以下の通りです。

  • 言語のリストを定義した tag_group を作成する
  • 投稿前に、このグループから1つのタグを各新しいトピックに追加することを必須とする

@HAWK 関連トピックで言及されたこの設定の他のユースケースの一部も、同様のものから恩恵を受けるでしょうか(あるいは既存の「トピックに必須の最小タグ数」設定で完全にカバーされていますか)?

これは一般的に有用な方法で実装可能です。特定のグループからのタグを表示するタグナビゲーションコンポーネントです。

Discourse は現在、ユーザーがロケールを設定することを許可しています(「ユーザーロケールを許可」サイト設定で切り替え可能)また、ロケールの自動検出もサポートしており、「accept-language ヘッダーからロケールを設定」サイト設定で切り替え可能です。自動検出のコンテキストは以下の3つです。

  • ゲスト(ブラウザとヘッダー)
  • 新規登録(同上)
  • 招待(同上)- これに関して問題があるかもしれません(参照)(@schungx?)

ここで改善できる可能性がある2つの点は以下の通りです。

  • 新規登録フォームでユーザーが手動でロケールを設定できるようにする設定を追加する
  • Facebook のような「ロケール切り替え機能」をゲスト用に追加する(登録ページの下部バーを参照)。実際、私は 別のプロジェクトでこれを作成しましたが、まだプラグイン化していません。

これは非常に興味深く、試してみる価値があると思います。タグ、カテゴリ、およびカテゴリの説明は、ユーザーが実際のトピックを読む前に最初に読むことが多い部分です。これらはしばしばユーザーのコミュニティに対する感覚に寄与します。もしユーザーが自分に関連する言葉や説明を見れば、コミュニティ自体にも親近感を持ちやすくなります。したがって、トピックに入ると言語が異なっていても、ユーザーの興味やコミュニティへの感覚はすでに喚起されているのです。

また、カテゴリの説明やタグをローカライズすることは、トピック全体をローカライズするよりも容易です。技術的には可能ですが、まだ試行されていません。詳細はこちら を参照してください。@erlend_sh について、これに関する追加の作業や例をご存知でしょうか?

言語タグが単一の tag_group にある場合、ここでの変更は高度な検索ページにタググループ固有のタグフィルターを追加することです。

以上、私が挙げた変更点をまとめます。

  • 「タググループからタグを必須とする」サイトまたはカテゴリ設定
  • 特定のグループからのタグを表示するタグナビゲーションコンポーネント
  • 新規登録フォームでユーザーが手動でロケールを設定できるようにする設定
  • ゲスト用の「ロケール切り替え機能」
  • タグ、カテゴリ名、およびカテゴリ説明のローカライズ
  • 高度な検索ページへのタググループ固有のタグフィルターの追加
「いいね!」 10

招待(同上)- これに問題があるかもしれませんか?(参照 1)(@schungx?)

私の知る限り、招待メールはサイトのデフォルト言語で送信されますが、ユーザーはログイン時に自身のロケールを取得します。

現在、招待の言語を指定する方法はありません…

「いいね!」 2

すぐに思い浮かぶ具体例はありませんが、多言語コミュニティが増えつつある現状を考えると、もし特定のユースケースがこれによって簡素化されるなら、それは正当な要望だと考えます。

「いいね!」 8

@HAWK 私もこの機能に賛成です。言語タグの必須化以外にも、多くの活用場面が考えられます。例えば、現在「プロジェクト管理」というタググループがあり、#idea、#scoping、#ready、#in-progress、#celebrating、#evaluating、done というタグが含まれています。特定のカテゴリ内では、投稿者がプロジェクト管理の段階を表す適切なタグをすべての投稿に正しく付与することを必須にできれば、非常に素晴らしいことだと思います。

「いいね!」 3

@neil ご意見をお聞かせください。特定のタググループから1つのタグを強制する作業はどれほど大変でしょうか?

現時点では「3の法則」には達していませんが、上記の質問に対する回答に興味があります。

「いいね!」 7

私のフォーラムでも興味深い内容ですね。当フォーラムは英語話者が中心ですが、スペイン語話者もいます。常に双方向に翻訳し合っています。言語ごとに分かれた2つのフォーラムにするのは、私たちの場合適していません。しかし、自動翻訳機能付きのバイリンガルサイト(ユーザーがデフォルト言語を指定可能)であれば、素晴らしいと思います!

「いいね!」 4

タググループからタグを1つ以上持つことを強制する方法を追加するのは簡単です。この場合(1つの言語を選択する)は、正確に1つのタグを強制したいのだと思いますが、少なくとも1つのタグを必要とするケースもあるかもしれません(「トピックに必要な最小タグ数」設定に類似)。私は「特定のタググループから少なくとも1つのタグ」という実装を優先したいと考えています。なぜなら、Car Talkでは既にこの機能が部分的に機能しており、ユーザーがすべての車メーカーやモデルのタグでトピックにタグ付けすることは可能ですが、実際にはそのようにはなっていないからです。また、多言語コミュニティでは、複数の言語が同時に意味を持つ場合もあります。

「いいね!」 13

ええ、それは賢明に聞こえますね。

「いいね!」 6

おそらく、よりきめ細やかな制御を可能にし、かつ最大値の追加の余地を残すために、ブール値ではなく数値の最小値として追加するのが良い方法でしょう。

「いいね!」 4

今日これを作成しました。タグタブのカテゴリ別設定です:

改善できる点は、ユーザーが選択可能なタグをどうやって把握するかという部分です。現在はタググループ名が表示されていますが、タグそのものをリスト表示するか、数が多すぎる場合はグループ内で最も人気のあるタグを表示するべきでしょう。

@debryc @angus ご意見をお聞かせください。

「いいね!」 11

これってすごくワクワクするね、ニール!

  1. 設定の表示は完璧だと思います。
  2. 選択可能なタグが何かを示す必要があるという点に同意します。

もしかしたら、投稿作成画面のタグドロップダウンで、まずタググループとそのタグオプションを表示し、その後に他の人気タグを表示するのはどうでしょうか。

あるいは、エラーメッセージに「投稿する前に以下のタグのいずれかを選択してください」というメッセージを含めるのも一案です。ユーザーはタグ名をクリックして追加できます!

「いいね!」 5

私はこのアプローチを採用しました。必須タグがまだ選択されていない場合、タグ入力によって必須タグが提案されます。

「いいね!」 6

別の考え:
複数の言語に対して公平であるためには、ユーザーは最も快適な言語でソーステキストを作成・表現できなければなりません。また、読者は最も快適な言語で翻訳されたテキストを消費・読むことができなければなりません。翻訳のニュアンスが失われる問題を最小限に抑えるために、ソーステキストと翻訳されたテキストを並べて表示することが有益です。翻訳テキストのベースバージョンは自動翻訳版とすることができます。その後、翻訳テキストのバージョンはユーザーによる改善版とすることができます。ウィキと同様に、読者は翻訳のニュアンスが失われていると疑う場合、翻訳テキストの以前のバージョンを選択して表示できます。

ユーザーは、システムまたは管理者の決定を上書きするための消費言語を素早く選択できる方法を持つ必要があります。例えば、画面の右上隅にある言語ドロップダウンから選択します。例えば、中国を旅行中の英語話者のゲストユーザー(ログインしていない)は、ブラウザの検出が現地の言語として中国語を示していても、テキストを英語で表示したい場合があります。

タグとカテゴリを翻訳するというこのアイデアは素晴らしいです。ただし、一部の技術用語や科学用語には翻訳が存在しない場合があり、ソース言語のままにする必要があるかもしれません。

「いいね!」 3