我不知道的 i18next
文本膨胀与 RTL 适配
很多人以为国际化就是"把文本换成另一种语言",做完翻译就完事了。但实际上,翻译只是国际化的起点,UI 适配才是真正的战场。同样一个按钮,英文 "Submit" 占 6 个字符,德文 "Absenden" 占 8 个,阿拉伯文还要从右往左排列——这些差异如果不提前处理,上线后就是…
CSS, i18next +1
// 共 4 篇文章
很多人以为国际化就是"把文本换成另一种语言",做完翻译就完事了。但实际上,翻译只是国际化的起点,UI 适配才是真正的战场。同样一个按钮,英文 "Submit" 占 6 个字符,德文 "Absenden" 占 8 个,阿拉伯文还要从右往左排列——这些差异如果不提前处理,上线后就是…
很多人以为复数就是"1 个用单数,2 个及以上用复数"——英语确实如此,但放到阿拉伯语里,复数有 6 种形式;放到波兰语里,"2-4"和"5-21"用不同的词形。i18next 的复数处理远不止加个 _plural 后缀那么简单,而且从 v21 开始,连后缀的命名方式都彻底变了。
在 React 项目里用 i18next,很多人一遇到翻译就条件反射般地用 Trans 组件。但实际上,大部分场景 t() 函数就够了,Trans 只在特定条件下才有存在的必要。搞不清两者的边界,轻则代码臃肿,重则引入不必要的渲染开销。
很多人把 i18next 的命名空间当成"翻译文件的分类文件夹",配置一下 ns 数组就完事了。但命名空间决定的不只是文件怎么分,它直接影响了资源的加载粒度、请求数量和内存占用。一个看似简单的配置选择,可能导致首屏多发十几个请求,也可能让翻译资源在内存里无限堆积。