国际化后端或前端

Question

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

Answer 1

在这个话题上似乎有两种看法。

最受欢迎的观点是：国际化应该在服务器端

我的看法是：国际化应该在服务器端

合理但次等（IMO）的选择是：国际化是一方还是双方

我不知道大多数互联网公司在做什么，但是我在一家主要的互联网公司工作，我们在服务器端进行了所有国际化。

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

1. DRY：最基本的软件工程原理之一是“不要重复自己”。对于国际化软件，每次显示内容时，您都必须决定要显示的字符串，要显示的颜色，要使用的数字格式，可用的运输选项等。这是逻辑，尽管人们可能会争辩说逻辑是其中的一部分“视图”，因此属于客户端的域。但是，仍然是逻辑，并且逻辑并不需要在您的客户的每种口味中都能正确运行，例如您打算一次用Javascript快速编写，然后在Kotlin中编写它吗？最好让您的数据在模型中表示，让客户端成为“哑渲染器”。
2. 重要逻辑：您网站需要执行的所有操作都必须在服务器端完成。诸如国家要求的用户年龄，要收取多少税费之类的东西。如果您的某些本地化逻辑无论如何都必须在服务器端运行，那么将所有内容都放在一个地方会更好吗？
3. 服务器端渲染：搜索引擎仍然更喜欢预渲染的内容，这就是开发人员竭尽全力进行服务器端渲染的原因。用错误的语言在服务器端呈现字符串标记根本没有任何意义！
4. 性能：根据定义，在客户端进行的本地化将为先前呈现的字符串（包括静态内容）上的缓存命中创建的机会大大减少。即使是使用非常快的硬件的用户也必须付出性能上的损失，并且客户端添加的任何逻辑都会增加基于客户端硬件的用户体验的可变性。
5. 服务！如果您决定与您自己的其他客户端共享API，他们可能会期望并欣赏您内置的本地化。如果您尝试提供令牌而不是英语（或特定于语言的）字符串，那么它们将是就像，“哇！”现在我必须下载一个字符串包并实施翻译吗？
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 Application Internationalization, do it server-side or client-side?
3. Internationalization of api error messages on front end or back end?

Answer 2

通过在rest调用中发送locale来在后端执行错误消息，对于模板中的前端，使用AOT编译获得Angular i18n以获得更好的性能 https://angular.io/guide/i18n