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

Internationalization of api error messages on front end or back end?

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

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

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

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

如果我必须这样做，我会在后端完成，主要是因为后端有语言环境，并且也会生成错误，因此期望从中产生本地化错误确实有意义。它还会解耦系统，这样，如果后端有任何新的 feature/change 完成，并且添加了新的错误，您不需要仅仅因为错误而释放前端部分。

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

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

好处：

  • 单一翻译来源 一切 - 按钮、工具提示等和错误消息
  • 格式支持 - 您可能需要制作消息的某些部分bold/clickable/etc，这需要在前端完成
  • 仅客户端验证 - 客户端验证的错误消息应与服务器端相同错误的错误消息相同（使用后端本地化，您可能最终会重复一些翻译)
  • 语言不可知测试是可能的
  • 与语言无关的后端是可能的 - 后端不需要语言环境只是为了翻译
  • 与本地化尽可能接近客户的一般建议同步
  • 消除了将来进行更多后端翻译的动机

缺点：

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

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