ローカリゼーション（サーバー側またはクライアント側）はどこで行うべきですか？
現在、サーバー上の複数のREST Webサービスと通信するリッチJavaScriptクライアントに基づく新しいWebアプリケーションを開発しています。このアプリケーションは、少なくとも2か国で異なる言語で使用することを目的としています。ローカライズする必要があります。
私の質問は、ローカリゼーションをどこで管理すべきかです。RESTサービスはローカライズされたデータでリクエストを受信して回答を送信する必要がありますか？
REST APIは、翻訳された文字列の代わりに文字列IDを提供すると、他の人が使いやすくなります。"E_NOT_AUTHORIZED"を返すAPIを使用することは、人間の言語を返す場合よりも簡単です、さらにはローカライズされた文字列です。
また、将来のバージョンでローカライズされた文字列を変更することもできます。これは、APIの重大な変更になるでしょう。文字列IDのアプローチを使用しても、APIの互換性を維持しながら"E_NOT_AUTHORIZED"を返します。
Angular.js のようなフレームワークを使用する場合、文字列IDアプローチを使用すると、言語のホットスイッチングを簡単に実装できます。別の文字列テーブルをロードするだけで、{{errorStringID | loc}}などのテンプレートでフィルターロジックを使用するだけなので、すべての文字列が自動的に言語を変更します。
もう1つの考慮事項：サーバーの負荷を軽減するには、バックエンドをできるだけ単純にしてください。同じ数のサーバーでより多くのクライアントにサービスを提供できます。 CDNを介して文字列テーブルを配信し、フロントエンドでローカライズを行います。
クライアントにリクエストで標準化されたAccept-Languageヘッダーを送信させ、サーバーでローカライズして、レスポンスにContent-Languageヘッダーを含めます。詳細は RFC 7231セクション5.3.5 を参照してください。
サーバー側でローカライズすると、クライアントのローカライズメタデータを送信するよりも、ラウンドトリップと帯域幅の消費が少なくなります。しかし、サーバーがクライアントが希望する言語を想定することはできません。そのクライアントが他の誰かにサービスを提供するプロキシである場合はどうでしょうか。クライアントとサーバーの間にキャッシング層がある場合はどうなりますか？サーバーは、任意のリクエストにどの言語を使用する必要があるかを「理解する」ためにどのように想定されていますか？
これらの質問に答えるのは複雑なので、代わりにリクエストが自己記述的であり、標準ヘッダーを使用してクライアントが交渉できるようにする彼らが望む言語。これはコンテンツネゴシエーションと呼ばれます。 Accept-Languageヘッダーは、proactiveコンテンツネゴシエーションの形式であり、クライアントはサーバーにプリファレンスを通知し、サーバーはそれらのプリファレンスに基づいて何を応答するかを決定します。 Reactiveコンテンツネゴシエーションでは、クライアントがサーバーにどのような種類のコンテンツがあるかを要求するリクエストを送信し、通常、リンクのリストを含む応答を受信して、希望するものを選択しますフォローするリンクを選択する。
複数のデバイスをサポートする場合は、サーバー側でできるだけ多くのことを言います。
もちろん、各デバイスは独自にいくつかの翻訳を使用しますが、APIなどからのエラーメッセージはデバイスに関係なく同じであるため、共有されます。
これは非常に個人的な好みの問題ですが、クライアント側で行う場合は、サーバーの負荷を軽減し（静的またはキャッシュされた辞書を想定）、言語に依存しないツールを使用してサービスをテストできます。