V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
shintendo
V2EX  ›  前端开发

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

  •  
  •   shintendo · 2022-07-08 10:07:55 +08:00 · 2530 次点击
    这是一个创建于 871 天前的主题,其中的信息可能已经有所发展或是发生改变。

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

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

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

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

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

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

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

    10 条回复    2022-07-12 15:02:32 +08:00
    66beta
        1
    66beta  
       2022-07-08 10:14:57 +08:00   ❤️ 1
    目前维护的系统不是我搭的,所以我只能说说使用的感受:
    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
        2
    fov6363  
       2022-07-08 11:05:52 +08:00   ❤️ 1
    文章可以看这个: 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
        3
    murmur  
       2022-07-08 11:07:28 +08:00
    i18n 其实挺扯淡的,除非是技术型网站,可以用 i18n ,真正的商业 i18n 是几乎重做前端的,雷区太多了
    ychost
        4
    ychost  
       2022-07-08 11:08:20 +08:00
    key + 文件就行了,别整太复杂,文件可以考虑放 CDN ,通过前缀版本来管理,服务端下发配置版本,这样的好处是方便灰度和回滚
    cyrbuzz
        5
    cyrbuzz  
       2022-07-08 11:10:37 +08:00   ❤️ 2
    之前刚做了一轮 i18n 的替换,说下经验。

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

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

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

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

    5. 个人感觉复用可以,但不要追求。
    wunonglin
        6
    wunonglin  
       2022-07-08 11:28:18 +08:00   ❤️ 1
    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
        7
    chenzhe  
       2022-07-08 12:26:16 +08:00
    我之前是用中文 key+翻译的方式来做的。
    shintendo
        8
    shintendo  
    OP
       2022-07-08 13:48:54 +08:00
    @66beta key 这么分散的话,就是几乎每一处文本都是单独的 key ?会不会很繁琐
    shintendo
        9
    shintendo  
    OP
       2022-07-08 13:50:04 +08:00
    @murmur 是管理后台,中文为主,少数的英文用户
    66beta
        10
    66beta  
       2022-07-12 15:02:32 +08:00
    @shintendo 繁琐也没办法,要么你直接引入 google 网页翻译?
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   1848 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 1162ms · UTC 16:28 · PVG 00:28 · LAX 08:28 · JFK 11:28
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.