locale drift（区域版本漂移），指的是本地化内容随着它所翻译的源内容变化，慢慢地失去对齐。英文页面改了价格，德文页面没改。产品里某个功能改了名，你八种语言里有三种还用着旧名字。单看每一处改动都不严重。但跨市场、跨发布周期加总起来，就变成各语言版本说的不再是同一件事。

漂移很少是翻译质量问题。它是工作流问题：源内容不停变化、传导靠手动、没人负责让各版本同步。这意味着它是可以预防的——但只能靠工作流里的控制，而不是靠更好的单篇翻译。

locale drift 为什么会发生

几乎所有漂移都来自四个条件：

• 源内容不停变化，更新往往先在一种语言上线。
• 没有单一事实来源——内容散在 CMS、几张表格、若干邮件里，没人说得清哪个是当前版本。
• 传导靠手动——得有人注意到改动，并记住它需要在每种语言的每个地方都体现。
• 归属不清——当每个人都负责让某个语种保持最新时，就没有人真正负责。

五道控制，把它挡住

1. 建立单一事实来源。 每个内容项有一个权威版本，并清楚记录哪个是当前的。下游都从它本地化。如果你连”这个页面现在线上是哪个版本”（针对重点市场）都答不上来，先修这个，别的都往后放。

2. 强制术语，不要交给个人偏好。 标签上、UI 里、帮助中心、官网上用的术语，必须在每种语言里都是同一个词。这需要一份维护中的术语表，在每个任务上强制套用——而不是每个译者各自选。

3. 按语种明确审校归属。 每种语言都该有指定负责人或审校路径，让一处改动有明确的通道去被审、被批准，而不是悬在半空。

4. 把更新传导内建进工作流。 源内容一变，应该由工作流（而不是某个人的记忆）把每种语言里所有受影响的资产找出来、按期限派去更新。大部分漂移，其实是在这一步被挡住的。

5. 保留可审计的版本记录。 记录什么内容、发布在哪、什么时候发布。在受监管品类这是合规要求；在其他地方，它让你在漂移出现时能诊断，而不是靠猜。

一个快速自检

对你的多语言内容问三个问题：

• 你能说出任一页面在所有市场的当前版本吗？
• 是有一份强制术语表，还是术语因译者而异？
• 源内容一变，有没有东西自动找出每一处受影响的译文？

只要有一个答案是”否”，那个缺口就是漂移的入口。把它堵上，几乎总是比事后一遍遍对齐版本更省钱。

在源内容持续变化时让本地化内容保持对齐，正是把网站本地化当作工作流、而非一次性任务的核心。上面这些控制落在哪，见我们如何构建这套工作流。