国际化后端或前端

Question

我正在创建一个带有前端 angularJs 和后端 Java API 服务器的网站。我已经在 API 服务器中进行了错误消息国际化，但我想知道是否应该在服务器端进行 api 结果的翻译？例如，如果法国用户请求一个苹果对象，我应该返回他翻译的苹果对象，还是让前端为他翻译苹果对象？

Answer 1

关于这个话题，似乎有两种观点。

最流行的观点是：国际化应该在服务器端

我的观点是：国际化应该在服务器端

合理但劣等 (IMO) 的选择是：国际化是在任何一方或两者兼而有之

我不知道大多数互联网公司在做什么，但我在一家大型互联网公司工作，我们在服务器端完成所有国际化。

我相信服务器端是国际化的最佳场所的原因：

1. DRY：最基本的软件工程原则之一是“不要重复自己”。对于国际化软件，每次显示内容时，您都必须决定显示哪个字符串、显示哪种颜色、使用哪种数字格式、可用的运输选项等。这是逻辑，尽管人们可能会争论的逻辑是其中的一部分“视图”因此属于客户端的域。但是，它是逻辑，而且逻辑不需要在您的客户的每一种风格中都正确运行，例如，您是否打算用 Javascript 编写一次，快速，然后在 Kotlin 中？最好让您的数据在模型中表示，让客户端成为“哑巴渲染器”。
2. 关键逻辑：您的站点需要强制执行的任何操作都必须在服务器端完成。诸如国家规定的用户年龄、要收多少税等等。如果您的某些本地化逻辑无论如何必须在服务器端运行，那么将它们全部放在一个地方不是更好吗？
3. 服务器端渲染：搜索引擎仍然对预渲染的内容更满意，这就是开发人员不遗余力地进行服务器端渲染的原因。用错误的语言在服务器端渲染字符串标记根本没有多大意义！
4. 性能：根据定义，在客户端完成的本地化将为先前渲染的字符串（包括静态内容）上的缓存命中创造更少的机会。即使拥有非常快的硬件的用户也必须付出性能损失，并且任何添加的客户端逻辑都会增加基于客户端硬件的用户体验的可变性。
5. 服务！如果您决定与其他客户共享您的 API，而不是您自己的客户，他们可能会期待并欣赏您内置的本地化。如果您尝试提供令牌而不是英语（或特定语言）字符串，它们将是就像，“Whhhhuuuuuud？” 现在我必须下载一个字符串包并实现翻译？
6. 重复的工作、费用和协调。我看到的一个人提出了字符串应该在客户端本地化的论点，因为如果客户端想要提供一种您的服务不提供的语言怎么办？我还没有看到，无论如何它不会很好地工作。每次您对提供新字符串令牌的服务进行增强时，客户端都会至少有一些失败的令牌，除非您进行了一些激进的版本控制，并且有人喜欢激进的 API 版本控制吗？最后，您希望每个客户都为独立翻译付费吗？一点都不便宜......

以下是我关于该主题的一些参考资料：

1. https://www.quora.com/When-building-a-large-scale-website-whats-the-best-way-to-implement-I18n-in-back-end-or-front-end
2. Web 应用程序国际化，是服务器端还是客户端？
3. 前端或后端api错误消息的国际化？

Answer 2

通过在其余调用中发送区域设置，在后端执行错误消息，对于模板中的前端，请使用带有 AOT 编译的 Angular i18n，以获得更好的性能 https://angular.io/guide/i18n