0

前端的 i18n 有什么最佳实践/风格规范吗

 1 year ago
source link: https://www.v2ex.com/t/864843
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.

V2EX  ›  前端开发

前端的 i18n 有什么最佳实践/风格规范吗

  shintendo · 3 小时 4 分钟前 · 368 次点击

搜了一圈没有搜到类似的东西,有点奇怪。

比如手写 key 加上翻译文件是目前的主流做法吗?那种自动抽取文本进行转换的工具实用度如何?

key 的命名风格,大写还是小写?单层还是嵌套?中文 key 是否可行?

一句删除提示语的 key 应该是"DELETE_CONFIRM"这样还是"DO_YOU_REALLY_WANT_TO_DELETE_THIS_RECORD"这样?

多个 key 对应相同文本是否应该避免?

相似文本是否应该考虑复用,比如删除 A 资源的提示语和删除 B 资源的提示语?

好多疑问搞不明白,网上却找不到系统的指南 /讨论文章,有没有大佬指点一下。

7 条回复    2022-07-08 12:26:16 +08:00
66beta

66beta      2 小时 57 分钟前

目前维护的系统不是我搭的,所以我只能说说使用的感受:
1. key 按你怎么舒服怎么来,比如 page.login.title, page.login.desc, form.login.username, form.login.password
2. key 尽量分散、不要复用,不然后买改起来麻烦,比如 form.login.password, form.resetPassword.password 分开
3. React 项目一般就用 react-intl
4. 原始数据可以用一个 csv 维护,写一段脚本生成到各个 locale.json

csv 的好处是,你把 key 填好,再填一个英文 /中文,其他的就留空转成 excel 发出去了,拿到翻译后也是直接复制黏贴回来
fov6363

fov6363      2 小时 6 分钟前

文章可以看这个: https://zhuanlan.zhihu.com/p/386164280
技术方面可以使用 https://www.i18next.com/

1. 手写 key+翻译文件是主流做法;自动抽取文本进行转换的工具实用还不错,优点是编写简单,不需要考虑这个文案是否已经有了,缺点是代码中是有规则的编号,比如 no_1 ,不利于阅读(除非再开发一个 vscode 插件)
2. key 的命名风格看项目,中文利于阅读,但不是所有的模板渲染引擎都支持中文,而且中文里有标点符号处理起来会比较麻烦
3. 无所谓,命名能看懂就行,个人建议短一行
4. 这是一个核心问题,如果你在变更时希望所有相同文本都变那就用一个 key ,如果只希望某个地方变就用多个 key 。我的最佳实践是:和代码走,代码是复用的就一个 key ,代码如果不复用,就是多个 key
5. 复用与否取决于需求,如果需求不 care ,尽量复用呗
murmur

murmur      2 小时 4 分钟前

i18n 其实挺扯淡的,除非是技术型网站,可以用 i18n ,真正的商业 i18n 是几乎重做前端的,雷区太多了
ychost

ychost      2 小时 4 分钟前

key + 文件就行了,别整太复杂,文件可以考虑放 CDN ,通过前缀版本来管理,服务端下发配置版本,这样的好处是方便灰度和回滚
cyrbuzz

cyrbuzz      2 小时 1 分钟前

之前刚做了一轮 i18n 的替换,说下经验。

1. key+翻译应该是主流了,不过没有手写,写了脚本。自动抽取替换的转换得根据具体业务代码进行改造,可以完成 90%,然后配合 eslint 在手动搞定剩下的大部分,最后有一些只能看到之后再改了(提交之前一个个文件校验)。

2. key 怎么舒服怎么来,不过最好有一些语义方便维护项目的时候搜起来方便(可搜索性),中文 key 的好处是维护代码的时候成本不会提升。

3. 这个应该还要结合 UI 来看,有些地方替换之后会存在文字长度问题导致 UI 变形。

4. 这个可能得结合实际替换,一般用 i18n 插件好像只有追加没有查重,人工写的话纯文本应该不会有重复的,带模板的可能重的多些。

5. 个人感觉复用可以,但不要追求。
wunonglin

wunonglin      1 小时 44 分钟前

1 、文本替换,https://angular.io/guide/i18n-overview ,然后通过 LOCALE ID 配合 pipe 可以达到国际化与本地化的效果。(缺点是不能动态切换各种语言)
2 、还有一种就是 https://github.com/ngx-translate/core ,根据 josn 等文件的 key ,去动态更改文本。

第一种我个人觉得是挺不错的,因为不用去想 key 值,还能有备注说明这个是要如何翻译,和 angular 结合比较好。

再动态切换语言的场景下,因为第一种是编译时文本就替换了,而不是运行时替换的,所以只能部署多套语言,根据 path 路由到不同页面,举例:
默认语言(英文):/
中文:/zh-Hans
日语:/ja
韩语:/ko-KR

不过其实还好,因为 localStorage 和 cookie 在同一个域名下可以通用,缺点就是要部多套而已。

然后就是相关的 editor 没什么好用的,目前是用 Poedit 这个,自动翻译还要订阅才行。
chenzhe

chenzhe      46 分钟前

我之前是用中文 key+翻译的方式来做的。

About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK