多言語ウェブサイトのUX原則？
さまざまなWebサイト（最大で最も人気があるものでも）は、ローカリゼーションへのアプローチが異なります。すべてのユーザーが使いやすいとは限りません。オンラインの例を見て記事を読んだり、このフォーラムのいくつかの質問（このような バイリンガルのウェブサイトの使いやすさ またはこの-- 言語セレクターの言語名の言語？ ）
今、私は原則をよく理解していますが、それは最善ではないと思われます。改善点があれば教えてください。
複数の国に存在する大規模なブランドの場合：
- 各国には独立したウェブサイトがあります。ほとんどの国では国コードTLD、米国では.com。
- ユーザーが国コードTLDにアクセスすると、そのサイトのWebサイトに直接アクセスします。ユーザーが一般的な.comにアクセスした場合、ユーザーの場所はIPアドレスから決定され、ユーザーはその場所のサイトに移動します。米国の場合は.com、一致しない場合は、自分がいる国の国コードTLD 。一部の場所は、独自のウェブサイトを持っていない場合、必要に応じて近隣諸国にマッピングされる場合があります。
- その国に一般的に話されている複数の言語がある場合は、言語ネゴシエーションを使用して、ユーザーの言語設定をブラウザーの設定から読み取ります。言語の交渉で一致する言語が見つからない場合に備えて、国ごとにデフォルトの言語が設定されています。
- 現在選択されている言語での国の名前が付いた旗のアイコンが、Webサイトの上部近くに他のナビゲーションリンクとともに表示されます。フラグはウェブサイトのターゲット国を示し、名前は言語を示します。それをクリックすると、ユーザーは表示したい国のウェブサイトを選択できます。国名は現在の言語で表示されます。
- 複数の言語を使用する国がリストに複数回表示され、それぞれに同じフラグが表示されている
- 各項目には、国名と言語名（たとえば、「US-English」）が言語自体で表示されます。アイテムはUnicode順にソートされ、言語間で一貫したソートが可能になります。
- ユーザーが手動でロケールを選択した場合、その設定は自分のアカウント（アカウントにログインしている場合）またはCookie（ログインしていない場合）として保存されます。
- 各ページにはコンテンツIDがあります。ほとんどの場合、.comサイトのURLパスです（ただし、これらのすべてのIDが実際のURLとして存在するわけではありません）。ユーザーが国内のWebサイトを変更すると、コンテンツIDの一致が検索され、一致するまで一度に1レベル上のパスに移動します。たとえば、日本のサイトのページで、東京で開催される特別なイベントについて話しているとします。コンテンツ識別子が/ news/events/tokyo/groundbreaking-ceremonyであるとします。ユーザーは、/ news/events/tokyo/groundbreaking-ceremonyコンテンツIDを含むページがないトルコのWebサイトに切り替えます。レベルを上げます。/news/events/tokyoコンテンツIDを持つページが見つかりません。レベルを上げます。/news/eventsのコンテンツIDを持つページが見つかりました（実際のURLはもちろん、トルコ語ではかなり異なります）。ユーザーは、トルコに関連する今後の会社のイベントについて話しているページにアクセスします。彼らが見ていたページと完全に一致するものはないので、ホームページに単にダンプするのではなく、できるだけ近くのものを見つけようとします。
- 多言語の国内Webサイトの場合、言語はサブドメインとして設定されます。フランス語を話す人向けのスイスにローカライズされたWebサイトはfr.mycompany.chのようなものであり、ドイツ語を話すバージョンはde.mycompany.chです。
- 各国のウェブサイトは、その国で会社が何をしているのか、どのように販売しているのか、どのように描写したいのかなど、コンテンツやデザインが大きく異なる場合がありますが、すべてのページはその国でサポートされているすべての言語に翻訳されます。
- ユーザーが同じ国のWebサイトで言語を変更すると、同じURLに移動しますが、他のサブドメインでは、新しく選択した言語で同じページを読み込みます。
- 各ウェブサイト/言語は適切にlang属性を設定します
これは、ユーザーにとって可能な限りシンプルなものを維持しながら、各地理的市場で完全なマーケティングの自由を可能にするために私が考えることができる最高のものです。私見、スイッチャーは明白で見つけやすいはずですが、デザインにはほとんどスペースを取りません。上記で詳細に概説したアプローチが行き詰まると思う唯一のケースは、誰かが特定の国に住んでいる（または興味がある）が、その国では一般的に見られない言語を話した場合です。ドイツの訪問者はドイツのドイツの全国ウェブサイトまたはスペインのメキシコのウェブサイトを見ることができましたが、ドイツのメキシコのウェブサイトを見ることができませんでした。各ウェブサイトは非常に異なるため、国のウェブサイトをその国であまり一般的に話されていない言語に翻訳することは経済的ではありません。
注：フラグは言語ではなく、国でのみ使用してください。ただし、国と言語の組み合わせを扱う場合は、最初に国を選択してから言語を選択するなど、ユーザーに複数の手順を実行させるよりも、複数のフラグ/国/言語の項目を表示する方が簡単だと思います。
次に、より単純なWebサイトに移動します。コンテンツは同じですが、心配されているのは言語ではなく場所だけです。多くの人気のある情報Webサイトは、国ごとにまったく異なるコンテンツを作成しようとは思わないでしょう。場所に関係なく、コンテンツを複数の言語に翻訳して提供し、より多くの読者を獲得したいだけです。ここにその状況についての私の考えがあります。
- 言語ネゴシエーションは、ブラウザからユーザーの言語設定を読み取るために使用されます。その言語が選択されているか、一致しない場合はデフォルトの言語が使用されます
- sEOとわかりやすくするために、言語にはサブドメイン（サブフォルダーではない）を使用します。
- フラグや地球儀などの場所に焦点を合わせた記号の代わりに、言語アイコン（ http://www.languageicon.org/ ）がページの上部近くに他のナビゲーションとともに名前とともに表示されます現在の言語の（現在の言語で表示されます）。これにより、現在選択されているものが表示され、ユーザーがクリックして言語を変更できることが明確になります。
- 言語のリストが表示されると、各言語名が独自の言語で表示され、Unicode順にソートされます
- rTL言語を使用する場合、サイドバーを反対側に表示し、テキストブロックの「方向」属性を変更し、水平メニューを反対方向に揃えます。 （技術的なメモでは、これは、言語に基づいてbody要素にrtlまたはltrクラスを設定し、関連するCSSルールの2つのバージョンを記述することによって達成するのが最善だと思います。）
- ユーザーが別の言語を手動で選択した場合、この設定はユーザーのアカウント（ログインしている場合）またはCookie（ログインしていない場合）として保存されます。
- ユーザーがたどる内部リンクは、現在選択されている言語でそのURLに移動します。言語を変更する場合、同じページにアクセスしますが、新しい言語のサブドメインを使用します
- ブログの投稿に表示されるコメントは、サイトの同じ言語バージョンで行われたコメントのみです。すべてのコメントは表示されませんが、（おそらく）コンテンツと同じ言語のコメントが表示されます。
- 各ウェブサイト/言語は適切にlang属性を設定します
ウィキペディアのように、クラウドソーシングの多いウェブサイトはどうですか？これはあまり一般的ではない状況ですが、重要なのは、Webサイトは基本的に言語間で同じですが、すべてのページがすべての言語に翻訳されるわけではないということです。ここではウィキペディアのアプローチが最善だと思います。サイドバーに使用可能な言語のリストを表示します。このリストは、一部の記事では長く、他の記事では短くなります。
私は何ができるかを読んで調査し、既存のWebサイトを調べようとしましたが、それにより、競合が増え、期待したよりも確実なベストプラクティスが少なくなったので、そのほとんどは、瞬間。私はそれが完璧ではないと確信しています。私には多くの疑問があります。たとえば、サイトの上部に小さな言語セレクターを配置した方がよいのか、下部に使用可能な言語のリストをスペルアウトして表示した方がよいのかはわかりません。いずれにせよ、あなたの考えを教えてください。これらのベストプラクティスのうちどれを修正しますか、またその理由は何ですか。 UXの観点から最善のアプローチを学びたい。
あなたが尋ねる質問は、ローカリゼーションのための相互作用だけでなく、より詳細な範囲を提供すると思います。それを読んでいるのは、世界中のさまざまな地域の人々がそれを表示または使用する場合に、デザインで考慮しなければならないことです。その場合、考慮すべき設計コンポーネントが多いため、答えるのは非常に難しい質問です。
- 情報アーキテクチャ：密度、構造、レイアウトの両方の観点から、東部（日本、韓国、台湾など）と西部（米国、英国、ドイツなど）のWebサイトでのコンテンツの表示方法を比較します。マーケティングの観点からの blog でのディスカッションの例。
- 視覚的美学：色、フォント、記号、画像などの使用を比較します。Webdesignデポには、 色と文化 の考慮事項についての投稿があります。
- コンテンツ戦略：コンテンツの割合と分布を比較します（例：広告、行動を促すフレーズ、情報、メッセージング、指示、ヘルプ）。 例 日本のウェブサイトについて具体的に話している。
また、各デザインコンポーネントには、言語の性質、アイコン、記号、色などの文化的コンテキスト、値がフォームでどのように提示されるかなど、多くの考慮事項もあります。これらすべての違いに対応できるWebサイト。過度に複雑な構造やコンテンツを持たない多国籍企業またはビジネスでない限り。
各国を個別に検討する必要があるだけでなく、サポートしている国の類似点と相違点を比較する必要もあります。一貫したルックアンドフィールを維持することと、さまざまなユーザーにとってユーザーフレンドリーになることとの間にはトレードオフがあります。
また、Smashing MagazineのWebサイトにある、さまざまな国を取り上げたデザインショーケースも検討することをお勧めしますが、比較は自分で行う必要があります。
これらのタイプの懸念に対処するWebページで使用される名前フォームフィールドの同様の議論の最良の例は、W3C.orgによる 個人名 に関する記事です。
興味深い質問をしていただき、ありがとうございます。私はローカリゼーション機能を実装しているいくつかのサイトをスクリーンショットしてきましたが、ユーザーエクスペリエンスの点では、GoDaddyの
私が分析したサイトは主にeコマースサイトであり、サイト全体のローカライズがCurrency Selectorにあることに気づきました。
GoDaddyは、確認なしでロケールサブドメインURLを設定することで少し進んでいます（使用されているテクノロジーについては尋ねないでください）が、Cookieをオフにしているにもかかわらず発生します。
他のeコマースサイト、主に衣料品や国際配送を利用できるサイトでは、言語の設定と通貨の設定を求めるプロンプトが表示されます。
私は最も人気のある Localization Wordpress Plugin オプションを分析しましたが、ページ内のウィジェットに対してさまざまな配置を提供します。フッターと適切なツールバーが最適な位置のようです私にとってはデザインに干渉しないので、興味深いオプションの1つは、独自のフラグまたは国のアイコンをアップロードできることです。あなたが提供したこのlanguageiconを試してみたいと思いますそれがまだ広く受け入れられているかどうかを確認してください。
Googleと検索エンジンは一般に、ローカリゼーションの時点で別のアプローチを提供し、ブラウザの言語設定と現在の場所に従って結果がリストされます。
私はこの情報であなたの研究を補足したいと思います。
良いアイデアのかなり包括的なリストがあります。これらの一部は「ベストプラクティス」である可能性があり、その他はコンテキストに依存します。
- フラグを使用すると、隅に自分をペイントすることができます。多くの企業は、さまざまな理由がありますが、主に限られたリソースと限界付加価値によるものであるため、さまざまな国を拡大すると単一の市場として扱います（例：ベネルクス、英国/アイルランド、米国/カナダ、オーストラリア/ニュージーランド、中東） ）。
- デフォルトでロケールを設定することは、WebアプリやFacebookなどのソーシャルメディアサイトでは理にかなっています。ただし、ほとんどの場合、URLに基づいてコンテンツを一貫して配信することをお勧めします。
- RTL設計は、大小のすべてのサイトに適用されます。
- 言語にサブドメインを使用する方が良いかもしれませんが、常に利用可能なソリューションであるとは限りません。私にとっては、domain.com/lang/...を使用することはまだ容認できます そしてGoogleも同意しているようです 。
- 視聴者やユースケースによっては、言語固有のコメントを表示するのが良い場合もあればそうでない場合もあります。昨年ギリシャのホテルを予約したとき、booking.comにさまざまな言語のコメントが表示され、Googleで翻訳してフィードバックの大まかな理解を得ることができて嬉しかったです。
言語アイコンなどの他のアイデアは、まだ概念的な段階にあると思います。いいアイデアですが、すぐに認識できるほど一般的ではありません。
あなたの他のアイデアのいくつかは、UXDよりも技術的な解決策として私を強く印象づけます。たとえば、サイト間でURIを同じに保つと、バックトラッキングアルゴリズムが単純になりますが、ユーザーの目的（およびSEO）のために、各オーディエンスに対してURIを日本語とトルコ語にすることは理にかなっています。 URIは、ユーザーが探しているものを見つけるための資産であり、コンピューターにとって無意味なアドレスではないことを忘れないでください。
.comのIPベースの処理におけるソリューションのDitto。非常に多くの場合、米国企業の米国サイトには、衛星市場のサイトよりも詳細かつタイムリーな情報が含まれます。ローカライズされたコンテンツは、品質が悪い、翻訳が不十分、過度に翻訳されている（特定の業界の全員が英語の専門用語や専門用語を使用している場合は公式の辞書の単語を使用する）か、欠落している（トラブルシューティング情報が必要な場合は販売パンフレットのみ）場合があります。他の場所にいるユーザーが必要だと判断した場合に、米国のサイトにアクセスできるようにすることが重要です。
言語セレクターの側面に関するいくつかの優れたアイデアについては、 The Art of the Global Gatewayby John Yunker を検討してください。彼はグローバルWebサイトにいくつかのエレガントなソリューションを提供しています。その最も基本的なものは、ドロップダウンを使用したユーザーの現在のコンテキストまたはロケールのインジケーターです。繰り返しますが、これは状況に依存すると思います。カナダのバイリンガルWebサイトへの一般的なアプローチは反対です。右上隅に、他の公用語の対応するコンテンツへのリンクがあります（したがって、英語のページでは「Français」と表示され、逆も同様です）。
結局のところ、私はUXのハードで高速な「原則」に反対することをお勧めします。重要なのは、コンテンツ、オーディエンス、およびこれらの要件に最適なソリューションを知ることです。さまざまなソリューションやアイデアのリストを用意しておくと、状況に最適なものを特定するのに役立ちます。