我应该在哪里进行本地化（服务器端还是客户端）？

我目前正在基于富JavaScript客户端开发一个新的Web应用程序，该客户端可与服务器上的多个REST Web服务进行通信。该应用程序打算在至少两个使用不同语言的国家/地区使用，因此我们需要对其进行本地化。

我的问题是我应该在哪里管理本地化：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等的错误消息将是相同的，而与设备无关。

这很大程度上是个人喜好问题，但是如果您在客户端进行操作，则可以节省服务器负载（假设使用静态字典或缓存的字典），并且可以使用语言不可知的工具来测试服务。