项目国际化的难点痛点是什么

如果有做过项目国际化的应该了解, 国际化的工作项大概包括以下几项:

【词条相关工作】

  • 文本包裹翻译函数,如 $t
  • 提取翻译词条到 json 文件里
  • 翻译并更新 json 文件

【三方库相关工作】

  • 组件库的国际化配置,如 element-ui 组件库
  • 其他有词条场景的三方库的国际化配置

【图片、文件相关工作】

  • 图片里出现中文时,需要准备国际化的图片资源
  • 文件里出现中文时,需要准备国际化的文件资源
    • 通常是表格导入导出的 excel 文件、用户声明和软件协议等 pdf 文档或静态 html 文件

【样式相关工作】

  • 国际化后的文本可能会出现显示溢出、截断、乱换行、排版错乱、未对齐等场景,
    • 需要针对不同语言处理不同样式,互不影响

如果没有相关经验的,经常会以为国际化只有词条相关工作项,这就是第一个坑点:工作量的评估过于乐观,遗漏其他工作项

但当你真正去开发一个国际化项目后,你会发现,国际化的难点、痛点、坑点远不止表面看到的这些,尤其是后期维护,痛点更大

相反,词条工作可能都是最轻松的工作了,因为圈子里有各种各样的自动化脚本工具来辅助你完成

下面我们就来聊一聊国际化里的各种痛点

如果你经历过,欢迎一起来吐槽补充

如果你没经历过,希望这些痛点可以帮助你在将来如果遇到国际化工作时,可以更有准备的做好评估工作

词条相关工作的痛点

痛点:词条出现在各种各样的地方

这里以 vue2.x 项目为例,词条有可能存在于 vue 文件的 template 里,script 里,甚至 style 里;也可能存在于 js 文件里,html 文件里。出现在不同地方,需要使用的翻译函数可能都不一样,如:

<template>
  <div>
    <div>{{ $t("这里是中文") }}</div>
    <div :label="$t('这里也是中文')"></div>
  </div>
</template>
<script>
const ZH_KEY = window.$t("这里也可能有中文,还用不了this上下文");
export default {
  props: {
    label: {
      type: String,
      default: window.$t("这里的中文也用不了this上下文"),
    },
  },
  data() {
    return {
      label2: this.$t("这里中文就用得上this.$t全局函数"),
    };
  },
  mounted() {
    setTimeout(function () {
      // 异步回调函数不使用箭头函数,导致 this 指向丢失,内部也无法访问 this
      this.$t(
        "这里使用 this.$t() 会抛异常,因为没有使用箭头函数,this指向不是当前vue组件实例对象"
      );
    });
  },
  methods: {},
};
</script>
<style lang="scss" scoped>
.main {
  &:empty {
    content: "暂无数据";

    // 这里的中文只能通过样式优先级来覆盖掉,用不了翻译函数
    [lang="en"] & {
      content: "No Data";
    }
  }
}
</style>

如果你没仔细看上述代码里的中文词条出现的场景的话,可能你会下意识的觉得,vue 里面出现中文的不就 template 模板代码和 js 代码里吗,给 vue 挂个全局翻译函数如 $t,包裹下出现的词条不就好了吗

正常场景下的确是这样没错,但毕竟前端太灵活了,每个人能力水平和习惯不同,如果团队有规范要求可能还可控点,如果没有规范要求,或者又是个历史久远经手 N 多人的项目的话,你没法保证代码里会出现什么样的写法

比如,有人甚至通过 :empty 伪类选择器来填充文本,那这种场景你要么改造掉,要么就只能用 css 优先级覆盖来解决国际化问题,因为 css 里用不了 js 的函数

比如,有人传给一些异步操作的回调函数就不使用箭头函数,非使用原始的 function() {} 声明,这就导致回调函数内部的 this 指向不是当前 vue 组件实例,所以你在里面使用 this.$t() 的话会导致程序异常。这时候要么改造成箭头函数,要么就是旧时代还没有箭头函数时的解法(在函数声明前先把 this 保存下来 const self = this,函数内部再通过 self 当前 this 使用)

比如,有人习惯把表单的校验函数,或者一些静态变量声明在 script 标签内,这里的 js 是运行在模块作用域内,this 指向也不是当前 vue 组件实例。这时候要么把代码下沉至 vue 内部,要么就使用 window 全局函数

比如,即使是在 vue 内部里的一些地方,也访问不了 this,比如 props 里面声明的组件输入参数的默认值,如果是中文,这里也访问不了 this.$t,比如 beforeRouteEnter 生命周期内也访问不了 this。这种场景只能使用挂载在 window 全局上的翻译函数了

所以你看,只是在 vue 组件内的代码,中文词条就有可能出现在各种各样的地方,不同地方的上下文还都不一样,还得分场景处理,得注意是否可以访问 this 等等问题

更何况,还有 .js.html 文件的场景

js 文件场景可能还好说,无非就是使用 window 上的全局翻译函数,或者手动 import 进来一个翻译函数给当前 js 模块代码使用

html 文件里,纯原生的 html 里你怎么搞,这里又不是 vue,没有模板语法可以让你在 html 里调用 js 函数,那么你只能使用 jQuery 时代的那种思想,手动去操作 dom 进行修改了,举个例子:

<!DOCTYPE html>
<html>
  <head>
    <title>这里是中文标题</title>
  </head>
</html>

这里的中文,你只能通过 js 来操作 dom,如 document.title = 'xxx',如果不是 title 标签,而是其他标签,得先获取到对应 dom,再做相对应的处理。虽然这种场景不多,但你没法保证没有,谁知道这个老项目以前的前辈会怎么写

所以,给词条包裹个翻译函数的工作,也不轻松,坑也很多。即使是各个大佬在推崇的各种自动化插件、脚本工具,这些场景也仍旧需要去关注、小心

痛点:动态拼接的词条

中文词条有可能是固定的词条,也有可能是动态拼接而成的词条,举个例子:

<template>
  <div>
    本次批量操作{{ total }}条,其中,成功{{ success }}条,失败{{ error }}条
  </div>
</template>
<script>
export default {
  data() {
    return {
      total: 10,
      success: 3,
      error: 7,
    };
  },
  mounted() {},
  methods: {
    removeItem(item) {
      this.$confirm("确认是否要删除【" + item.name + "】吗?");
    },
  },
};
</script>

动态拼接的场景其实也非常常见,比如在一些表格的敏感操作提示、批量操作结果显示、或者接口报错提示原因等等场景,都需要根据用户的行为来动态的拼接上一些业务数据来呈现

那么,这种动态拼接场景要怎么解决?

注意:各种推崇的国际化的自动化插件或脚本,局限之一就是无法解决这类动态拼接的场景,基本都只能人为处理

如果每个中文词条片段都各自独立包裹翻译函数,如 this.$t("确认是否要删除【") + item.name + this.$t("】吗?"),这样翻译出来很容易会翻译错误,而这种解法又基本都是自动化工具脚本的解法,因为脚本无法区分一句话是否结束了

这种场景目前我能想到的就是人为去处理,有经验了之后,或许编写代码就会下意识的避免写出这种代码

人为的处理就是利用翻译函数的占位符替换功能,给翻译函数动态传参方式,如:

  • <div>{{ $t("本次批量操作{0}条,其中,成功{1}条,失败{2}条", [total, success, error]) }}</div>
  • this.$confirm(this.$t("确认是否要删除【{0}】吗?", [item.name]));

所以,动态拼接词条的场景,处理不难,但工作量大,基本没法靠自动化脚本完成

痛点:词条非得标红加粗关键字显示

关键词高亮这种场景其实跟动态拼接词条场景类似,一句完整词条被其他东西被迫拆分成多个片段组成。

常见的场景就是搜索结果里对关键词高亮处理,如百度的搜索结果:

实现方式上,无非就是把需要标红加粗高亮的关键词用其他标签包裹起来,单独设置样式,如:

  • <div>这句话里<span style="color: red">我</span>要标红显示</div>

注意:跟动态拼接词条相同,这种关键词高亮场景也是自动化插件或脚本的局限之一,需要靠人为处理

至于解决方案,其实有两种,一种是直接把带有 html 标签代码的一整句话当作词条,丢给翻译组去翻译,但需要跟人家解释说明清楚,毕竟她们不懂代码
另一种是参考动态拼接词条的解法和 v-html 来解决,因为要让 span 标签被正确当前 html 代码解析而不是字符串显示,如

  • <div v-html="$t('这句话里{0}我{1}要标红显示', [`<span style='color: red'>`, '</span>'])"></div>

所以,关键词加粗高亮的场景,处理起来更麻烦,能怼掉这需求就怼掉吧,实在不行,跟翻译人员解释下

幸好这种场景在项目里应该不多,比动态词条拼接场景会少很多

痛点:后端接口返回的未翻译词条

理论上,前端的词条前端翻译,后端的词条后端翻译。接口返回的词条理应由后端去翻译就好了

遇到这种场景,能怼回去就怼回去吧

真的由于各种原因,后端就是改不了,非得前端来翻译,那就专门准备一个 json 文件来维护后端没翻译的这类词条场景吧

然后找到使用接口返回字段的地方,在呈现前,先用 $t 包裹翻译处理下,主要是找代码的工作量,其他都还好

痛点:中文做 key 值怎么办

还是那句话,每个人的能力水平习惯不同,老项目经手 N 多人,什么牛鬼神蛇的代码都有可能存在

用中文做 key 值也就不奇怪了,这里说几种场景:

  • if (type === '其他') { // ... }
    • 用中文做判断
  • const map = { 折线图: 'line', 饼图: 'pie' }
    • 用中文做对象的 key 值

用中文做判断的话,如果确保国际化下 type 的赋值也能正确被翻译的话,那其实应该还好,因为两边都翻译了,只要翻译是一样的,那判断逻辑还是能够正常执行,但怕就怕翻译不一致,或者 type 根本没翻译

毕竟你只有去确认过逻辑才能保证有没有问题,那确认逻辑这个工作量就特别大了。或者也许可以这么处理:

  • if (this.$t(type) === this.$t('其他'))
    • 两边都翻译了再进行判断,可能某些场景下会出问题,比如误翻译
  • if (type === '其他' || type === this.$t('其他'))
    • 多加个判断条件,这样总有一个判断能满足,但也怕会误伤,不过应该还好

至于用中文做对象 key 值的场景,就要去区分这个中文能不能被翻译了,万一不能被翻译但却给翻译了,就会引起取数匹配不到,导致业务功能异常,如果可以翻译,那么加个 [] 就能调用翻译函数,如:

  • const map = { [this.$t('折线图')]: 'line', [this.$t('饼图')]: 'pie' }

所以,中文做 key 值,最大的问题就是要去梳理确认逻辑,到底这个中文能不能被翻译处理,而且这种场景很难主动发现,因为不好找,通常发现时已经是被测出功能故障来了

不同技术栈项目的痛点

痛点:jQuery 老项目的国际化

vue 项目通常是用 vue-i18n 作为国际化方案基础,那非 vue 项目呢,比如以前的 jQuery 项目呢?

不同项目都有各自的国际化框架,虽然框架不一样,但本质上基本都是一样的,无非就是翻译函数和词条文件

区别可能是翻译函数名不一样,词条文件不一样

比如 vue-i18n 是用 json 来维护词条文件,而 jquery.i18n 是用 properties 来维护词条文件

你可以不同项目直接用不同方案去实现、维护国际化,但这个可能对能力有些要求,有些新人可能转不过来,因为出现过带的一些新人平时不关注国际化底层实现原理,只会用,导致换了个不同技术栈的老项目就完全不知道怎么搞了,教了就忘

针对这种场景,我们实践出来的解决方案就是开发个抹平不同框架的自动化 node 脚本,虽然框架不同,但大家都是基于 node

当然,对于一些老项目,还需要扩展下原国际化框架的能力,尽可能让它在使用、维护上跟其他框架保持一致

比如扩展下 jquery.i18n 框架能力,让它也支持用 json 文件来维护词条文件

自动化脚本我会再写篇文章介绍,本篇主要是讲痛点和解决方案思路

样式相关工作的痛点

痛点:相互影响,修复完中文样式、英文出异常

样式的工作经常是会被遗漏掉的工作项,不同语言的对齐、宽度、间距、换行等是有可能需要不同的处理的,尤其是在表单的 label 宽度上,通常需要单独设置

而且样式的处理上,影响点其实很大的,很容易不经意间就相互影响了

而测试又默认不影响,所以可能会导致测试没覆盖到而引发生产口碑问题了

比如你改了一个英文样式问题,但却影响到了中文时的呈现,但测试关 BUG 时又只验证了英文的,这就容易出问题了

纯 css 代码样式问题修复就还好,加个作用域,再配合语言切换时往 body 上挂个属性上去,就能限制影响范围,如:

.input {
  width: "220px";
  work-break: break-all;
  // 加个作用域,限制生效范围,非 en 语言下就不生效。
  [lang="en"] & {
    width: "300px";
    work-break: break-word;
  }
}

但如果是模板代码或者 js 代码里,就需要使用到判断逻辑来分场景处理了,这里建议是用对象取值方式替换掉三元运算符,这样方便后续再扩展其他语言,如:

<template>
  <!-- 推荐 -->
  <el-form :label-width="{ en: '150px' }[lang] || '80px'"></el-form>

  <!-- 不推荐 -->
  <!-- <el-form :label-width="lang === 'en' ? '150px' : '80px'"></el-form> -->
</template>

所以,样式工作主要是影响点,注意宣讲到位,测试到位,避免将问题遗漏到生产上

三方库相关工作的痛点

项目里通常会使用到一些三方的基础组件库,国际化就需要按照对应组件库的国际化方案来进行相对应配置

这个难度不大,主要问题也是容易被遗漏

痛点:三方库不支持国际化怎么办

但如果项目里使用到了不支持国际化的三方库,这时候,没办法了

只能是魔改源码,改造成直接引入 js 的方式替换掉 package.json 里的依赖构建模式了

图片、文件相关工作

这个场景也是经常容易被遗漏的工作项,有时甚至都不知道原来国际化还要处理图片、文件这类场景

经历多了后,以后在评审高保设计图时,就尽量让设计人员不要设计带中文文案的图片了,如果非要带,就连同其他语言的图片一起出了,省得后期找不到人出图

至于文件场景,现在基本都是后端维护,交给后端去处理就行

有些老项目是把文件放前端资源里直接下载的,注意下也有这种场景就像

维护相关工作的痛点

除了开发阶段有一堆痛点外,其实后续的迭代维护,也是一个大痛点

痛点:经常有遗漏的未翻译词条

当你的项目已经完成了国际化了,然后又经历了一次新的需求迭代开发,有多个人一起参与,新增了很多功能,也在原有功能上做了很多改动。

好,问题来了。

你如何确保你们这么多人在这次迭代的改动里,新增或修改的代码里的词条都进行了国际化处理呢?

相互 review? 自测一轮?

这也是种解决方案,但需要投入资源成本,而且本身这次迭代开发里除了正常需求开发工作量外,也需要投入国际化处理的工作量
注:国际化事项就是文章开头列出的事项,每次迭代基本都需要处理

最完美的解决方案应该是自动化脚本,让脚本来解决这种问题,下篇会介绍下团队大佬开发的自动化脚本

痛点:如何在 json 里增量式捞取未翻译的词条

跟上一个痛点是一样的背景,在一次迭代里新增或修改的代码里多少会引入、修改、删除中文词条,那么如果增量式的更新到 json 文件中去呢?

靠人工手动去更新,工作量大,而不靠谱稳定

而且,我们词条翻译不是通过机翻,而是需求把词条捞出来提供给翻译团队进行翻译

那我怎么在上万条词条里面,把那些未翻译的捞出来呢?

一条条过吗,太不现实了,还不如在迭代开发写代码过程中就一条条记录下来

但仍旧是需要耗费大量工作,而且一旦这个步骤忘记,后续再想手工捞取工作量只会更大

而且就算你是机翻,难道每次都把所有词条,包括已经翻译好的词条都丢给机器吗,嫌钱不够花嘛

最完美的解决方案还是自动化脚本,一切重复、耗时的工作都可以让脚本来替代

痛点:如何把翻译好的词条更新回 json 文件里

还是跟上一个痛点是一样的背景,当从翻译组拿到了这次迭代里那些词条的翻译后,怎么更新回 json 文件里呢

尤其跟翻译组的往来文件有可能是 excel 文件,并不是 json 文件

所以,完美的解决方案还是自动化脚本,脚本去解析 excel,然后回填到 json 文件里,工作效率提升百分百,一键式就搞定

痛点:json 越来越庞大,甚至导致编译时撑爆内存

项目只会越来越大,如果把整个项目的翻译词条都放到一个 json 文件里维护,那这份 json 文件只会越来越大,万级别,甚至百万千万级别,那到时就非常考研设备性能,开发维护都是个问题,因为我们已经遇到过一些老项目上构建时直接撑爆了内存,导致构建失败,都没办法进行热更新开发调试了

所以,json 还是要按模块,拆分成多份维护

而这个工作,仍旧可以交给自动化脚本来处理

痛点:多人多分支时,合并时的大量冲突

这也是国际化项目容易出现的问题,不同分支如果都进行了国际化,就会导致基本每个文件每行代码都发生变更,如果两个分支并行了,那合并时就会是个灾难

我今年经过过 N 次这种场景,领导根本不关注是不是国际化,只关注说几个月前某个分支不是已经国际化做完了,现在合并到 xx 分支上就好了,为什么还需要这么多天的工作量

但其实这个合并工作量巨大,而且风险很大,因为是人为一个个解决冲突,代码还不是就一个人开发,但合并就一个人合并

至于解决方案,怼吧,这种分支管理不合理

要国际化就尽量不要并行

要么就是分支就只单纯国际化,不要做其他需求开发了,这样借助脚本,还能直接在新分支上跑下脚本,然后同步下样式或者动态词条处理这些场景的代码变更就行

总之,这个场景没有想到好的解决方案,只能从管理上,从规范流程上尽量去避免

痛点:翻译函数的 key 值如果不是中文词条,维护代码成本可能会增大

有些国际化方案里会单独为每个词条定义一个 code,然后代码里是使用这个 code,而非中文词条,在根据不同翻译文件对每个 code 进行翻译

element-ui 组件库的国际化就是这种方案,它提供了一份内部所有词条的 code,然后我们根据需要,传入不同 code 语言的翻译文件就行

这种方案不是说有问题,而是其实不适用到每个项目里,组件库这种是比较稳定不怎么变更的项目,而且没有业务性质的项目,可以使用这种方案

但在真实的业务项目里,如果把每个业务页面里的中文词条都换成一个唯一的 code 值,这其实是非常降低阅读性的

而且你想想,一个项目上百个页面,上千个代码文件,我不可能对每个代码文件都很熟悉,很多时候的迭代开发或者故障排查,都是基于特定页面开始在项目里找代码,因为我也不知道在哪里

那通常都是根据界面上的中文词条或者路由等信息找到代码文件后,开始梳理逻辑

中文作为我们的母语,自然是直接看到夹带着中文的代码会更容易阅读和理解,如果是 code 的话,还得特意去转换一遍

效率非常低下

至少我们有个老项目就是用 code 这种方式,导致我们阅读、维护都非常费劲

而且,都是 code 的话,也非常不利于自动化脚本的工作,因为自动化脚本需要根据一定的规则来捞取词条,本来中文就是最好捞取规则了,现在整成 code,还得定义系列规范跟代码含义区分开

综上,我们团队一致建议翻译词条就直接用中文做 key 值,就像文章开头给出的实例代码


最后

网上好多关于国际化的文章不是介绍类似 vue-i18n 框架的使用,就是推崇下一些自动化工具脚本

但当经历过国际化工作后,尤其是一些老项目,才发现,国际化工作里,除了词条相关工作外,还有其他很多方面的工作项

而且就算是词条工作,也存在各自各样的场景要处理,坑很多,痛点也很多

不是一个自动化脚本就能完全搞定的,脚本只能帮忙把重复、低效的手工工作替换掉,但脚本没法完成的仍旧需要我们自行去完成

所以本篇才想汇总来聊一聊国际化工作中,我所遇到的各种痛点

但是啊,自动化脚本还是不能少的哈,它至少能提效 50% 以上的效率

曾经它帮我把两周的工作量直接节省到 1 天内搞定

所以,下篇就想来聊一聊国际化的自动化脚本

热门相关:现代隐士高手   写给鼹鼠先生的情书   隐身侍卫   凤逆天下:战神杀手妃   美食供应商