前端或后端的 api 错误消息的国际化？答案

【问题标题】：Internationalization of api error messages on front end or back end?前端或后端的 api 错误消息的国际化？
【发布时间】：2015-07-18 12:58:42
【问题描述】：

我的团队目前正在做一个前端使用后端提供的 json api 的 web 项目。我们使用的技术是 Spring Boot 和 AngularJS。该 api 具有如下所示的标准错误格式：

{
    "errorCode": "1111",
    "message": "Error occurred: some error message",
    "developerMessage": "message for developer"
}

错误响应还可以包含可选的字段验证错误列表。问题是我们应该在哪里翻译用户错误信息？后端是否应该根据请求的语言环境返回已翻译的消息，或者前端是否应该使用 errorCode 及其 i18n 机制。我们在后端（Spring i18n 支持）和前端（角度平移）都有 i18n 机制。

最佳做法是什么？每种方法的优缺点是什么？任何建议表示赞赏。

【问题讨论】：

【解决方案1】：

如果我必须这样做，我会在后端进行，主要是因为后端具有语言环境，并且还会生成错误，因此预期会出现本地化错误确实有意义。它还将解耦系统，这样，如果在后端完成了任何新功能/更改，并添加了新错误，您不需要仅仅因为错误而释放前端部分。

此外，一旦规模扩大，并且您有多个后端系统，上述方法就可以很好地工作，因为所有错误生成器都负责处理它们各自的本地化。

【讨论】：

【解决方案2】：

我会通过本地化前端的所有内容来做到这一点。后端将发送 ids，然后客户端应用程序会将其转换为本地化文本。

好处：

缺点：

要支持多个客户端应用程序，您可能需要在构建的捆绑步骤中进行 resx 转换。它将以客户端所需的格式创建资源文件，因此您可以保留单一的翻译来源

【讨论】：

我会添加更小的负载，在我们的设置中，UI 可以动态更改它的本地，因此后端不知道语言环境，它必须发送每种语言的完整翻译。
这两种方法各有利弊。参见例如this answer 后端意见。
在这里聚会晚了 4 年，但是@andreister - 当你说你的后端应该将 ID/代码发送到前端时，这是否意味着我需要一个字典，我存储在前端的某个地方将所说的 ID 映射到它们的可翻译字符串？