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

Question

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

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

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

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

Answer 1

如果我必须这样做，我会在后端完成它，主要是因为后端具有语言环境，并且还产生错误，所以期望从中获得本地化错误是有意义的。它还会解耦系统，这样，如果后端有任何新功能/更改，并且添加了新错误，则不需要仅为错误释放前端部分。

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

Answer 2

我会通过本地化前端的所有内容来实现。后端会发送id，然后客户端应用程序转换为本地化文本。

优点：

• 单一翻译源用于所有内容 - 按钮，工具提示等以及错误消息
• 格式化支持 - 您可能需要将消息的某些部分设置为粗体/可点击/等等，这些部分需要在前端完成
• 仅客户端验证 - 客户端验证的错误消息应与服务器端验证相同的错误消息（后端本地化可能会导致重复某些转换）
• 语言无关的测试是可能的
• 语言无关的后端是可能的 - 只是为了翻译而不需要后端的区域设置
• 与尽可能靠近客户端进行本地化的一般建议同步
• 消除了将来进行更多后端翻译的动机

缺点：

• 无法翻译新错误。如果在捆绑客户端应用程序后在后端定义了错误，则客户端需要显示通用消息（但如果需要，可以显示新的错误ID）。
• 更复杂的捆绑

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