前端或后端api错误消息的国际化？
前端或后端api错误消息的国际化？
提问于 2015-05-07 19:14:53
我的团队目前正在开发一个web项目，前端使用后端提供的json。我们使用的技术是Spring和AngularJS。api的标准错误格式如下所示：
{
"errorCode": "1111",
"message": "Error occurred: some error message",
"developerMessage": "message for developer"
}错误响应还可以包含字段验证错误的可选列表。问题是我们应该在哪里翻译用户错误信息？如果后端根据请求的区域设置返回已翻译的消息，或者前端应该使用errorCode及其i18n机制。我们在后端(Springi18n支持)和前端(角度转换)都有i18n机制。
什么是最佳做法？每种方法的优缺点是什么？如有任何建议，敬请见谅。
回答 2
Stack Overflow用户
回答已采纳
发布于 2017-07-27 11:51:08
我会把前面的每样东西都本地化。后端将发送ids，然后客户端应用程序将其转换为本地化文本。
好处：
- 所有东西的单一翻译源-按钮、工具提示等和错误消息
- 格式化支持-您可能需要使消息的某些部分粗体/可点击/等等，这需要在前端完成
- 用于客户端验证的客户端验证-客户端验证的错误消息应该与服务器端相同的错误消息相同(对于后端本地化，您可能会复制一些翻译)
- 语言无关测试是可能的
- 语言无关的后端是可能的--不需要仅仅为了翻译而在后端进行区域设置。
- 与尽可能接近客户端的通用建议同步
- 消除了将来进行更多后端翻译的动机
缺点：
- 翻译新错误是不可能的。如果在客户端应用程序打包后在后端定义了错误，客户端将需要显示通用消息(但如果有必要，可以显示新的错误id)。
- 更复杂的捆绑
为了支持多个客户端应用程序，您可能需要在构建的捆绑步骤中进行resx转换。它将以客户机所需的格式创建资源文件，这样您就可以保留一个翻译源。
Stack Overflow用户
发布于 2015-05-07 19:31:02
如果我必须这样做的话，我就会在后端这样做，主要是因为后端有区域设置，而且还会生成错误，因此期望它的本地化错误是有意义的。这样，如果后端有任何新的特性/更改，并且添加了一个新的错误，您就不需要仅仅因为错误而释放前端部分。
而且，一旦扩展到多个后端系统，上述方法就能正常工作，因为所有的错误生成器都负责处理它们各自的本地化。
页面原文内容由Stack Overflow提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接：
https://stackoverflow.com/questions/30109787
复制相关文章
相似问题
腾讯云开发者
