问国际化后端或前端

EN

通过在rest调用中发送区域设置，在后端对错误消息执行此操作，对于模板中的前端，则使用i18n编译以获得更好的性能https://angular.io/guide/i18n。

在这个问题上，似乎有两种观点。

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

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

合理，但次等的选择是:国际化是在任何一方或两者。

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

我相信服务器方的理由是国际化的最好地方：

1. DRY:最基本的软件工程原则之一是“不要重复自己”。对于国际化软件，每次显示内容时，都必须决定要显示哪个字符串、要显示什么颜色、要使用什么数字格式、有哪些发送选项等。这是逻辑，尽管人们可能会认为这是“视图”的一部分，因此属于客户端的领域。但是，尽管如此，逻辑并不需要在客户端的每一种风格中正确运行，例如，您要用Javascript编写一次、一次、然后用Kotlin编写吗？最好让您的数据在模型中表示，并让客户端成为一个“愚蠢的呈现者”。
2. 关键逻辑:您的站点需要执行的任何操作都必须在服务器端完成。比如国家要求的用户年龄，征收多少税等等。如果你的一些本地化逻辑无论如何都要运行服务器端，那么把它放在一个地方不是更好吗？
3. 服务器端呈现:搜索引擎对预先呈现的内容仍然更满意，这就是为什么开发人员会不遗余力地进行服务器端呈现。服务器端用错误的语言呈现字符串标记一点意义都没有！
4. 性能:根据定义，客户端的本地化将为以前呈现的字符串(包括静态内容)提供更少的缓存访问机会。即使硬件速度非常快的用户也必须支付性能损失，而任何增加的逻辑客户端都会增加基于客户端硬件的用户体验的可变性。
5. 服务！如果您决定与您自己的客户端以外的其他客户端共享您的API，他们可能会期待并欣赏您内置的本地化。如果您试图提供标记而不是英语(或特定于语言的)字符串，它们将是：“谁的胡uuuuud？”现在我必须下载一个字符串包并实现翻译？
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?

为什么要翻译API中的错误消息？只需发送与该特定错误相关联的唯一错误代码，并将国际化留给表示层(android、web等)。他们将决定/将该唯一的错误消息与要显示给最终用户的正确消息相关联，并决定要显示什么是正确的翻译；有时直译不适合设计，必须使用更短的/剪切的版本，所有这些都取决于表示层，与API无关。