翻译文件为什么总是不同步？

翻译文件之所以不同步，是因为两个系统拥有同一份数据，却没有哪一方说了算。代码仓库在开发者合并时变化，翻译文件却只在有人想起来时才更新。这是两套不同的时钟，二者之间的空档，就是缺失的键、孤立的键和过时字符串的藏身之处。globalize.now 是 AI 驱动的本地化基础设施，通过在代码编写处直接生成键和语言文件来填平这个空档——不再有第二套时钟可以落后。

语言文件不同步，究竟是什么原因？

只有一个文件是由人撰写的，其余的都只是在维护，而这是两种不同的工作。

开发功能的开发者会编辑 en.json，因为字符串就是要写进这个文件。其他 locale 是别人的事，按别人的节奏来。有位开发者在 DEV 上描述过这种模式的两种故障形态：键加进了英文文件却在其他文件里被遗忘，于是应用的一部分悄悄回退到英文；键在某个 locale 中被删除，却在另一个中保留下来，于是无用条目不断堆积。两种情况的发现方式，都是几周后收到的用户投诉。

这两种都不是翻译问题。没有任何内容被误译，只是这些字符串从未被送到任何地方。

这种故障模式经得起每一次工具升级，因为工具处在字符串产生之处的下游。字符串如果从未进入流水线，再好的流水线也无济于事。同样的根因在链条更靠前的位置也会出现：编码 Agent 写出的字符串压根没有生成翻译键。

为什么语言文件会产生这么多合并冲突？

因为它们是生成出来的数据，却被人手动编辑，而且格式本就是为机器写入设计的。

语言文件就是键到字符串的扁平映射。两个各自新增功能的分支，都会往这个映射里追加内容，通常位置相近，通常在字母序的同一片区域。Git 看到的是一个没有语义结构的文件里相邻行的两处修改，于是请人来解决。

来解决冲突的开发者往往看不懂目标语言。稳妥的做法是两边都保留，这就是重复键的由来；省事的做法是只留一边，这就是翻译被悄悄删掉的由来。

没人会手动解决 lockfile 中的冲突，大家都是重新生成。语言文件一旦不再是由人撰写的文档，也理应获得同样的对待。

翻译在评审中等待时，会过时到什么程度？

过时到不再对应产品本身，而且这一点在公开案例中可以量化。

DevOps.com 上发布的一份现场报告梳理了多个开源项目中的五个真实本地化 PR。其中最有代表性的是 Kilo Code PR #8377：自动检查全部通过，维护者的评审稍后才到，而仓库在此期间已经演进。这个 PR 最终被关闭，并邀请作者基于当前架构重新提交。同一份报告还记录了一个 OpenClaw issue：志愿者提供了西班牙语、日语、葡萄牙语、韩语、中文和越南语的翻译，维护者却表示无从接收。

这些应当被解读为延迟报告，而不是质量报告。翻译在写下时是正确的，只是在排队期间，界面变了。

这是对比本地化工具时没人去定价的成本。大家都在衡量翻译本身，几乎没人衡量字符串在途中停留了多久，也没人关注这期间界面发生了什么变化。

来回往返到底要付出什么代价？

协调上的成本比翻译本身更高，这也是账单永远解释不了这份痛苦的原因。

看得见的成本按词、按键或按席位计费，每月在账单上出现一次。看不见的成本是：开发者要问“该改哪个文件”，另一位开发者要在看不懂的语言里解决冲突，第三位发现德语构建缺了 11 个键，而功能的原作者还要被问起五周前自己写的某个字符串。

这些都不会出现在定价对比里。但它们每个 Sprint 都在消耗开发者的时间，按开发者的成本计价。一个标价很低的工具，如果每周让两名工程师搭进去一天，就一点也不便宜。

成本的来源是这一来一回的流转。字符串在一处产生、在另一处翻译，文件在两地之间搬运，这一步最贵，而且无论你选哪家供应商都一样。这也是为什么本地化正不断前移到开发循环中。

如果键在写代码的地方直接生成，会有什么不同？

第二套时钟消失了，不同步也就无从产生。

流程不再是：开发者写下硬编码字符串，过后有人发现它，有人给它加键，有人把文件发出去，有人翻译，有人再把结果取回来。而是：字符串在功能的同一次提交里，就以带值的键的形式写好，翻译随后跟进。

在 globalize.now 里，这从一次性转换开始。你在应用中连接仓库，现有的硬编码字符串会一次性提取为键和语言文件。之后，Agent Skill 会让 Cursor、Claude Code 等编码 Agent 从一开始就写带键的字符串，而不是硬编码；推送任务则会在新的目录单元出现时自动翻译。

关键词是“一次”。转换是最难的部分，而它只发生一次。之后的环节原本都靠手动，现在与代码走在同一条时间线上——这正是把它放进开发工作流，而不是放在工作流旁边的意义。

运行时库不受影响。i18next 和 next-intl 读取语言文件的方式与之前完全一致，翻译的分发方式没有任何变化。变的只是谁来写这些文件。

如何区分漂移和真正的翻译问题？

问一句：有没有翻译人员见过这个字符串？

如果德语文件缺了一个键，并不是翻译人员失职，而是这个字符串根本没送到他们手上。这是流转路径的问题。再增加审核环节只会更糟，因为这个流程本来的毛病就是延迟，审核只会再添一段排队时间。

如果德语文件里有这个键，但措辞不适合当前语境，那才是真正的翻译问题，需要一位懂德语、能看到字符串渲染位置的人来处理。这样的问题值得花时间。

大多数团队遇到的前一类问题远多于后一类，却把两者当成同一个问题，所以本地化才显得永无止境。把它们分开，工作量就会下降，因为流转这一半根本不再需要人工。团队越小，这个区分越重要，这也是它在快速交付的独立开发者和小团队身上体现得最明显的原因。

一个实用的检验方法：数一数最近十个本地化 bug 里，有多少是措辞错误，有多少是内容缺失。如果大多是缺失，那你面对的不是翻译问题，而是管道问题。管道问题可以自动化，判断力则不行。在你盘算本地化究竟该花多少钱时，同样适用这个逻辑。

语言文件漂移是披着翻译问题外衣的流转问题。连接一次仓库，流转就不再需要你操心。