前言

最近在做一个老项目的国际化改造。按理说，

项目跑了很多年。页面多、业务多、历史写法也多。我们先用脚本扫了一遍，需要处理的中文大约有几万处。老实说，

看到这个数字。第一反应很容易是：多安排几个人，把中文都换成 t再补几份语言包不就行了吗？

真动手之后才发现，事情远没有这么简单。不过，

有些中文只是按钮上的字。直接翻译没问题，有些中文却被拿来做判断、传接口、存缓存。还有一些藏在动态菜单、公共组件、异步任务、导出文件名和打印模板里。按理说，

如果不先把这些情况分清楚。直接全局替换，页面可能是英文了业务却悄悄坏了。

这篇文章不讲某个具体项目，也不会放真实业务代码。主要想聊一聊这方面，面对一个约有几万处中文、还在持续迭代的老项目。我们是怎么把国际化从“翻译任务”变成“架构改造”的。

文中的代码都是重新写的通用示例。虽然示例用了常见前端写法，但整体思路不依赖 Vue、React 或其他具体框架。

一、总设计思路

. 最难的不是翻译。而是把文字和业务拆开

先看一段老项目里很常见的代码：

const orderStatusList =
if {
openReviewDialog
}

表面上看，待审核 是一段展示文案，它还参与了业务判断。

如果只把列表里的 name 翻译成 Pending Review判断就会失效，而且控制台不会报任何错。

痛点： 逻辑失效往往只有在真实使用者操作后才暴露，比漏翻一个按钮更危险。

判断要使用稳定的 id/code/key

const orderStatusList =
if {
openReviewDialog
}

三个字段各做各的事：

• code: 给业务逻辑使用；
• nameI18nKey: 给界面翻译使用；
• name: 暂时保留，给老页面和异常情况兜底。

. 万处中文不能直接等于万个翻译任务

扫描工具只能告诉我们哪里有中文，不能判断中文是做什么的。

const title = '订单管理'
const colorName = '中国红'
const fileName = '订单列表'
const userRemark = '使用者自己填写的中文'

它们的处理方式完全不同：

• title
• colorName
• fileName
• userRemark

第一阶段的观点是。先搭底座，再跑一个完整试点

从第二阶段来看，按业务模块逐个迁移 ...

难点？

. 共享枚举不能直接改成 t

// 不建议在共享模块里直接这样写
export const orderTypeList =

...

三、具体怎么落地？

四、万处中文怎么分批推进？

五、怎么判断一个模块真的改完了？

做完这轮设计后我对老项目国际化最大的感受是：

• 万处中文只是表面上的工作量，真正的难度是这些文字已经和业务代码一起长了很多年。怎么说呢，
• 如果只把它当翻译任务…
，