前端或后端的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

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

好处：

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

缺点：

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

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

Answer 2

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

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

Answer 3

TLDR：如果您有移动客户端 - 两者都有（由于向前兼容性）

有时，由于移动客户端的原因，不可能在前端拥有包含所有错误代码的字典。一些移动客户端永远不会更新您的应用程序。这意味着后端可能会发送新的错误，该错误未在客户端上注册。

为了构建可靠的应用程序，我们应该实现具有“前向兼容性”的错误协议。这意味着客户端应该能够识别并显示这些错误的错误消息，但目前尚不清楚。

这一点将我们引向“后备消息”。这意味着 - 对于老客户端，来自后端的所有错误都应包含

error

 和 

errorFallbackMessage

。并且 

errorFallbackMessage

 应该本地化（例如，基于 

Accept-Language

 标头）。