前端或后端 API 错误消息的国际化?

我的团队目前正在处理一个Web项目,其中前端使用后端提供的json api。我们使用的技术是Spring Boot和AngularJS。该 API 具有如下所示的标准错误格式:

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

错误响应还可以包含字段验证错误的可选列表。问题是我们应该在哪里翻译用户错误消息?后端是否应根据请求的区域设置返回已翻译的消息,或者前端是否应使用 errorCode 及其 i18n 机制。我们在后端(Spring i18n支持)和前端(角度转换)都有i18n机制。

最佳实践是什么?每种方法的优缺点是什么?任何建议都是值得赞赏的。


答案 1

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

好处:

  • 所有内容的单一翻译来源 - 按钮,工具提示等和错误消息
  • 格式支持 - 您可能需要使消息的某些部分加粗/可点击/等,这需要在前端完成
  • 仅客户端验证 - 客户端验证的错误消息应与相同错误的服务器端错误消息相同(使用后端本地化,您可能最终会复制某些翻译)
  • 语言不可知性测试是可能的
  • 与语言无关的后端是可能的 - 不需要仅仅为了翻译而在后端进行区域设置
  • 与尽可能靠近客户端进行本地化的一般建议同步
  • 消除了将来进行更多后端翻译的动力

缺点:

  • 无法翻译错误。如果在捆绑客户端应用后在后端定义了错误,则客户端需要显示一般消息(但如有必要,可以显示新的错误 ID)。
  • 更复杂的捆绑

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


答案 2

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

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


推荐