我正在使用 nestjs 创建我的 REST API,并且我要求支持 i18n 来处理 API 返回的所有消息(异常消息、提示等),我想知道更好的方法是什么使用nestjs 框架。
使用普通快递,我可以从请求标头中获取用户语言,并且可以将其翻译为 Nestjs 中间件,以便将语言代码放入位于请求执行上下文中的某个软件中,然后从我的 i18n 服务中使用(我这样做不想添加语言参数everyware我需要用户语言)你怎么看?它是解决我的要求的合适架构吗?哪个是为当前请求放置语言的最佳位置?
我正在使用 nestjs 创建我的 REST API,并且我要求支持 i18n 来处理 API 返回的所有消息(异常消息、提示等),我想知道更好的方法是什么使用nestjs 框架。
使用普通快递,我可以从请求标头中获取用户语言,并且可以将其翻译为 Nestjs 中间件,以便将语言代码放入位于请求执行上下文中的某个软件中,然后从我的 i18n 服务中使用(我这样做不想添加语言参数everyware我需要用户语言)你怎么看?它是解决我的要求的合适架构吗?哪个是为当前请求放置语言的最佳位置?
我会使用i18-node包https://github.com/mashpie/i18n-node,与 express 兼容,因此与 Nest 一起使用也没有矛盾。另外,我建议注册一个自定义装饰器作为res.__
调用的包装器。
我一直在使用Nestjs-i18n包。
它包含内置功能,例如I18nService和I18nLang 装饰器。
我认为没有一种方法可以在不将其作为参数传递的情况下在服务中获取语言代码。如果您想从您的服务访问语言代码,您必须将其作为参数传递,或者从另一个地方检索与用户对象关联的语言代码。
我在我的应用程序中处理翻译如下:
我有一个语言装饰器,用于处理客户端覆盖的“接受语言”标头:
export const Language = createRouteParamDecorator((data, req) => {
if (!req.body.lang) return req.getLocale();
return req.body.lang;
});
并在控制器中像这样使用它:
@Post()
public async testLocale(@Req() req, @Language() locale) {
return this.myService.someMethod(someParam, locale);
}
要做出您要求的架构决策,我首先会考虑以下内容。
如果您的 API 包装的服务仅执行某些操作(发送电子邮件、处理某些数据、进行计算等),我将仅返回标准化错误或提示代码及其标准化英语消息。
翻译的事情应该在前端应用程序上完成,不管它是什么。最后,您只需使用任何模板引擎(无论它是 Node 还是 PHP 或您创建前端的任何其他东西)和Poedit都可以。
应用程序负责知道哪个错误或提示代码转换为哪个匹配的前端 UI 消息。Poedit 将使用node-gettext和gettext-parser进行翻译。
相反,如果您的 API 包装了多语言内容(这不是您所描述的情况),那么您别无选择,您必须为每个请求实现语言选择机制。正如您所说,语言是由浏览器通过 HTTP 请求标头定义的。
您必须根据语言参数创建负责获取内容翻译(从内容存储库)的应用程序服务对象,例如,您传递给它的基本语言内容项 ID。
仅供参考,注意REQUEST
范围注入,因此服务依赖于特定的请求上下文并正确处理语言设置。
i18n 实现可以适用于您的情况。