テーマコンポーネントサンプルテキストの翻訳

最近、多くの公式テーマコンポーネントがCrowdinに追加されました。

これにより、カラースキーム切り替えのようなコンポーネントのユーザーエクスペリエンスが向上し、ツールチップがユーザーのロケールで提供されるようになります。

しかし、検索バナーのようなサンプルテキストを提供するコンポーネントでは、追加される翻訳が増えるほどカスタマイズが複雑になります。以前は、すべてのユーザーのテキストを変更するために、デフォルトのフォーラム言語(および英語のデフォルト)のテキストを追加するだけで十分でした。追加される翻訳が増えるごとに、カスタマイズする必要があるバージョンが増えます。

詳細な例

この例では、サイトのデフォルトロケールは英語(米国)で、Discourse検索バナーです。これはデフォルトの構成です。


GitHubリポジトリに翻訳がないため、どのロケールを選択しても、すべてのユーザーは次のように表示されます。



英語(米国)のデフォルト文字列を編集すると

他のすべてのロケールのテーマ翻訳には、デフォルトの英語(米国)テキストが表示されたままになります。

しかし、文字列は、設定でデフォルトテキストが表示されているロケールであっても、すべてのロケールで上書きされます。



GitHubリポジトリに同じデフォルト文字列を持つen_GB.ymlを追加した後、サイトのロケールの文字列を編集するだけでは不十分です。英語(GB)のバージョンは変更の影響を受けません。


したがって、管理者は両方のバージョンを調整する必要があり、翻訳が増えるほど、カスタマイズする必要のある文字列が増えます。

Discourse Discoverでさまざまなデフォルトロケールを持つサイトを調べた経験から、管理者はデフォルトロケールのテキストのみを編集することがよくあります。これは、テーマコンポーネントに追加される翻訳が増えるにつれて、カスタマイズされたバージョンを見るユーザーが少なくなることを意味します。

そのため、すべての翻訳を一度に上書きするオプションがない限り、サンプルテキストの翻訳はあまり役に立たないと思います。

「いいね!」 3

「管理者 → 外観 → サイトテキスト」も同様に動作します。カスタマイズされたテキストは、選択した言語にのみ影響します。この動作は、UI の一貫性がなくなる、または場合によっては多くの作業が発生する原因となることを理解しています。

現在、オプションは 2 つだけです。

  1. allow_user_locale サイト設定を無効にする。すべてのユーザーがデフォルト言語を表示するため、カスタマイズされたテキストが表示されます。
  2. 関心のあるすべての言語に対してテキストをカスタマイズする。

提案をお待ちしています。「すべての言語でテキストの上書きを強制する」オプションを追加すべきでしょうか。これはグローバルなトグルにするべきか、文字列ごとにするべきか、私にはわかりません。:thinking:

「いいね!」 1

サンプルテキストのみを含むコンポーネントは翻訳しないことをお勧めします。

利点を見逃しているかもしれませんが、私の意見では、カスタマイズを目的とした文字列のカスタマイズをより複雑にします。

「いいね!」 1

提示されたコンポーネントには慣れていません。検索バナーから投稿された例は、単なる例文ではなく、良いデフォルトのように思えます。

「いいね!」 2

Discourse Discoverを見ていると、テキストがカスタマイズされていることが多いという印象を受けます。例えば、多くのフォーラムでは「community」をフォーラムの名前に置き換えています。

「いいね!」 2

このフォーラムはもう一つの例です

外国語ユーザーは検索機能の使用をより緊急に促す必要があるという印象を受けるかもしれません

「いいね!」 1