命名空间与资源加载
很多人把 i18next 的命名空间当成"翻译文件的分类文件夹"，配置一下 ns 数组就完事了。但命名空间决定的不只是文件怎么分，它直接影响了资源的加载粒度、请求数量和内存占用。一个看似简单的配置选择，可能导致首屏多发十几个请求，也可能让翻译资源在内存里无限堆积。
i18next, 国际化 +1
/**
* 我不知道的 i18next
* 共 4 篇文章
*/
export const series = {
name : "我不知道的 i18next" ,
count : 4 ,
guide : "我不知道的 i18next — 系列导读与阅读路径" ,
description : "《我不知道的 i18next》系列导读、阅读路径与文章索引。" ,
};
文章数量： 4 篇
根据不同背景选择入口：
如果想系统学习 i18next： 按编号 01 → 04 顺序阅读
如果只关心 React 集成： 重点看 02（Trans 组件）
如果在做多语言复数处理： 重点看 03（复数规则与 CLDR 标准）
如果在排查布局错乱或 RTL 问题： 重点看 04（文本膨胀与 RTL 适配）
| # | 文章 | 核心内容 |
|---|---|---|
| 01 | 命名空间与资源加载 | 命名空间本质、加载策略对比、缓存机制与控制 |
| 02 | Trans 组件的边界与陷阱 | t() vs Trans 的使用边界、占位符编号规则、性能差异 |
| # | 文章 | 核心内容 |
|---|---|---|
| 03 | 复数规则与 CLDR 标准 | CLDR 六类别标准、v3→v4 格式迁移、Intl.PluralRules |
| 04 | 文本膨胀与 RTL 适配 | 文本膨胀率、CSS 弹性策略、CSS 逻辑属性、方向切换联动 |
很多人把 i18next 的命名空间当成"翻译文件的分类文件夹"，配置一下 ns 数组就完事了。但命名空间决定的不只是文件怎么分，它直接影响了资源的加载粒度、请求数量和内存占用。一个看似简单的配置选择，可能导致首屏多发十几个请求，也可能让翻译资源在内存里无限堆积。
在 React 项目里用 i18next，很多人一遇到翻译就条件反射般地用 Trans 组件。但实际上，大部分场景 t() 函数就够了，Trans 只在特定条件下才有存在的必要。搞不清两者的边界，轻则代码臃肿，重则引入不必要的渲染开销。
很多人以为复数就是"1 个用单数，2 个及以上用复数"——英语确实如此，但放到阿拉伯语里，复数有 6 种形式；放到波兰语里，"2-4"和"5-21"用不同的词形。i18next 的复数处理远不止加个 _plural 后缀那么简单，而且从 v21 开始，连后缀的命名方式都彻底变了。
很多人以为国际化就是"把文本换成另一种语言"，做完翻译就完事了。但实际上，翻译只是国际化的起点，UI 适配才是真正的战场。同样一个按钮，英文 "Submit" 占 6 个字符，德文 "Absenden" 占 8 个，阿拉伯文还要从右往左排列——这些差异如果不提前处理，上线后就是…