ローカライズはどこで行うべきですか（サーバー側またはクライアント側）？

現在、サーバー上の複数のREST Webサービスと通信するリッチJavaScriptクライアントに基づいた新しいWebアプリケーションを開発しています。そのアプリケーションは、異なる言語を持つ少なくとも2つの国で使用することを目的としているため、ローカライズする必要があります。

私の質問は、ローカライズをどこで管理する必要があるかということです。RESTサービスは、ローカライズされたデータを使用してリクエストを受信し、回答を送信する必要がありますか？

翻訳された文字列の代わりに文字列IDを提供すると、REST APIを他の人が使用しやすくなります。返されるAPIの使用は、"E_NOT_AUTHORIZED"何らかの人間の言語、さらにはローカライズされた文字列を返す場合よりも簡単です。

また、将来のバージョンではローカライズされた文字列を変更する必要がありますが、これはAPIの重大な変更になります。文字列IDアプローチでは"E_NOT_AUTHORIZED"、APIの互換性を保ちながらを返します。

Angular.jsのようなフレームワークを使用している場合、文字列IDアプローチを使用すると、言語のホットスイッチングを簡単に実装できます。別の文字列テーブルを読み込むだけで、テンプレートでフィルタロジックを使用するだけであるため、すべての文字列が自動的に言語を変更します{{errorStringID | loc}}。

別の考慮事項：サーバーの負荷を減らすには、バックエンドをできるだけシンプルにしてください。同じ数のサーバーでより多くのクライアントにサービスを提供できます。CDNを介して文字列テーブルを配信し、フロントエンドでローカライズを行います。

クライアントAccept-Languageに要求で標準化されたヘッダーを送信してから、サーバーにローカライズしてContent-Language、応答にヘッダーを含めます。詳細については、RFC 7231セクション5.3.5を参照してください。

サーバー側でローカライズすると、クライアントのローカリゼーションメタデータを送信するよりもラウンドトリップと帯域幅の消費が少なくなります。しかし、サーバーがクライアントが必要とする言語を推測することはできません。なぜなら、そのクライアントが他の誰かにそれを提供するプロキシである場合はどうでしょうか？クライアントとサーバーの間にキャッシングレイヤーがある場合はどうなりますか？サーバーは、任意の要求にどの言語を使用する必要があるのか​​を「単に把握」することになっていますか？

これらの質問に答えようとするのは複雑なので、代わりに要求が自己記述的であり、クライアントが希望する言語をネゴシエートできるように標準ヘッダーを使用する必要があります。これはコンテンツネゴシエーションと呼ばれます。Accept-Languageヘッダはの形で積極的なクライアントは、それの好みが何であるかをサーバに伝えコンテントネゴシエーション、サーバは、それらの設定に基づいて応答する何を決定します。リアクティブコンテンツネゴシエーションは、クライアントがサーバーにどのようなコンテンツがあるかを尋ねる要求を送信し、通常はリンクのリストを含む応答を受信し、次にリンクを選択することで希望するものを選択する場所です。

複数のデバイスをサポートする場合は、サーバー側でできる限り多くのことを言うでしょう。

もちろん、各デバイスは独自にいくつかの翻訳を使用しますが、APIなどからのエラーメッセージはデバイスに関係なく同じであるため、共有のものを使用します。

これは個人の好みの問題ですが、クライアント側で何かをすれば、サーバーの負荷（静的またはキャッシュされた辞書を想定）を節約でき、言語に依存しないツールを使用してサービスをテストできます。