【发布时间】：2018-03-06 18:28:05
【问题描述】：
我正在使用前端 angularJs 和后端 Java API 服务器创建一个网站。我已经在 API 服务器中完成了错误消息国际化，但我想知道是否应该在服务器端进行 api 结果的翻译？例如如果法国用户请求一个苹果对象，我应该返回他翻译的苹果对象，还是让前端为他翻译苹果对象？
【问题讨论】：
【发布时间】：2018-03-06 18:28:05
【问题描述】：
在这个话题上似乎有两种意见。
最流行的观点是：国际化应该在服务器端
我的观点是：国际化应该在服务端
合理但劣等 (IMO) 的选择是：国际化在任一侧或两者兼而有之
我不知道大多数互联网公司在做什么，但我曾在一家大型互联网公司工作，我们在服务器端做了所有的国际化工作。
我相信服务器端是国际化的最佳场所的理由：
- DRY：最基本的软件工程原则之一是“不要重复自己”。对于国际化软件，每次显示内容时，您都必须决定要显示的字符串、显示的颜色、使用的数字格式、可用的运输选项等。这是逻辑，尽管人们可能会争辩说这是逻辑的一部分“视图”，因此属于客户端的域。但是，尽管如此，它是逻辑，并且不需要在您的客户的每一种风格中正确运行的逻辑，例如。你打算用 Javascript 编写一次，快速，然后在 Kotlin 中编写吗？最好让您的数据在模型中表示，让客户端成为“哑渲染器”。
- 关键逻辑：您的站点需要强制执行的任何操作都必须在服务器端完成。诸如全国要求的用户年龄、要征收多少税等。如果您的某些本地化逻辑无论如何都必须在服务器端运行，那么将它们全部保存在一个地方不是更好吗？
- 服务器端渲染：搜索引擎仍然对预渲染的内容更满意，这就是开发人员不遗余力地进行服务器端渲染的原因。使用错误语言的服务器端渲染字符串标记根本没有多大意义！
- 性能：根据定义，在客户端完成的本地化将减少对先前呈现的字符串（包括静态内容）的缓存命中率。即使是使用非常快的硬件的用户也必须付出性能损失，并且任何添加的逻辑客户端都会增加基于客户端硬件的用户体验的可变性。
- 服务！如果您决定与您自己以外的其他客户共享您的 API，他们可能会期待并欣赏您内置的本地化。如果您尝试提供令牌而不是英语（或特定语言）字符串，他们将比如，“哇哇哇哇？”现在我必须下载一个字符串包并实现翻译？
- 重复的工作、费用和协调。我看到的一个人提出了字符串应该在客户端本地化的论点，因为如果客户端想要提供一种您的服务不提供的语言怎么办？我还没有看到，无论如何，它不会很好地工作。每次您对提供新字符串令牌的服务进行增强时，客户端至少会有一些失败的令牌，除非您进行了一些激进的版本控制，并且有人喜欢激进的 API 版本控制吗？最后，您希望每个客户都为独立翻译付费？一点都不便宜……
以下是我对该主题的一些参考资料：
【讨论】：
通过在 rest 调用中发送语言环境在后端执行错误消息，因为模板中的前端使用 AOT 编译的 Angular i18n 以获得更好的性能 https://angular.io/guide/i18n
【讨论】：
-
所以最好只在后端翻译错误信息，其他东西比如项目名称应该在前端翻译？
-
是的，您的休息服务将发送一个区域设置并根据该区域设置获取正确的错误消息。