最佳实践
资源文件组织
命名空间(Namespace)用于按业务模块拆分翻译文件,默认命名空间为 translation。按模块拆分可以减少初始加载体积,只在用到时按需加载对应命名空间。
推荐目录结构:
声明多个命名空间:
在组件中使用指定命名空间:
翻译键命名规范
翻译键的命名质量直接影响后续维护成本,建议:
- 用语义化词语,避免缩写:
button.submit优于btn.sbm - 按模块划分前缀:
dashboard.table.header、auth.login.title - 不要用完整中文文案当键名:键名应是稳定的标识符,而不是翻译内容本身
- 用点号表示层级:与 JSON 嵌套结构一一对应
复数
i18next 根据 count 参数自动选择对应的复数形式。注意:i18next v21 之后默认使用 JSON v4 格式,复数后缀改为 CLDR 标准(_zero、_one、_other 等),旧的 _plural 写法已废弃。
不同语言的复数规则不同(英语有单复数,俄语有 one/few/many 等多种形式),i18next 会根据语言代码自动匹配 CLDR 规则。
如果项目使用了旧版 i18next 或显式配置了 compatibilityJSON: 'v3',才需要使用 _plural 写法。新项目统一使用 v4 格式。
嵌套键
嵌套结构可以直观反映 UI 层级,用点号访问:
嵌套层级不建议超过 4 层,过深的结构会让键名变得冗长难维护。
格式化插值
通过 interpolation.format 函数统一处理数字、日期、货币等格式化,避免在每个组件里各自调用 Intl API:
翻译文件中用 , format 指定格式化类型:
错误处理
加载状态处理
使用自定义后端时,翻译资源需要异步加载,推荐用 isResourcesReady 处理加载中状态:
静态资源(HTTP/FS 后端)加载较快,通常不需要处理加载状态;如需检查,可以用 i18n.isInitialized:
翻译键缺失处理
通过 defaultValue 提供兜底文案,防止界面显示 key 字符串:
开发环境可以开启 saveMissing,将缺失的键输出到控制台方便排查:
网络失败与资源 404
翻译文件加载失败时,i18next 会回退到 fallbackLng 对应的资源;若仍失败,t() 直接返回 key 字符串。建议:
- 生产环境确保
fallbackLng(通常是en)对应的翻译文件完整且稳定 - 使用链式后端时,本地文件作为兜底,减少对远程服务的依赖
类型安全
通过扩展 react-i18next 的类型定义,让 TypeScript 检查翻译键是否存在并提供自动补全:
直接引用 JSON 文件的类型,比手写 interface 更不容易与实际翻译文件漂移:
翻译文件较多时,手动维护类型文件成本较高。可以使用 i18next-parser 或 i18next-resources-for-ts 从翻译文件自动生成 TypeScript 类型。