文案变更需触发翻译流程
别名: 本地化持续集成 · 翻译状态机 · 文案提取 · translation lifecycle
概念解释
源文案变更触发的本地化工作流（source-change-triggered localization workflow）把用户可见文案的新增、删除或语义修改视为需要传播的工程事件。事件从代码或内容系统中的稳定消息标识出发，依次驱动提取、翻译管理系统建单、翻译、语言审阅、界面验收与发布，而不是等上线前人工寻找改过的句子。每个语言版本都应关联源文案修订版和明确状态；“从未翻译”的 missing 与“已有译文落后于新源文案”的 stale 是两种不同状态。
机制
若源句本身充当键，哪怕改一个标点也可能同时制造新键和孤儿译文；若流水线只比较文件是否存在，又会把旧译文误判为可发布。稳定消息 ID、源修订号或内容哈希以及占位符、复数规则、使用位置和截图上下文，使系统能判断一次变更影响哪些目标语言。源变更事件先验证消息结构，再将对应目标从 approved 转为 stale，或为新消息建立 missing 任务；翻译完成后仍需经过语言审阅和真实界面中的上下文验收，才能进入可发布状态。删除或拆分消息也要形成可追踪事件，避免目录长期保留已失去调用方的译文。
怎么研究
可从版本历史重放新增、措辞微调、占位符变化、复数分支变化、消息拆分和删除，检查每类事件是否生成正确任务与状态迁移。过程指标包括提取延迟、各状态停留时间、目标语言积压、审阅退回率、源文案在翻译期间再次变化的比例，以及发布后由上下文错误引起的缺陷。比较团队或版本时需控制变更量、语言数量、发布频率和消息风险；较长周转时间可能来自必要的法律或领域审阅，不能直接解释为流程低效。抽样追踪一个源修订到所有发布包，能检验记录是否真的可追溯，而不只是看 TMS 中任务已关闭。
边界
代码注释、分析事件名或不呈现给用户的内部标识不应误触发翻译；反过来，远程配置、邮件模板、帮助内容和服务端错误也属于用户可见源文案，不能因不在客户端代码中而漏提取。排版或元数据变化未必使译文失效，但占位符类型、语气、法律含义和操作后果变化即使字面很小也可能需要重审。机器翻译可以生成候选，不等于自动获得 approved 状态。紧急修复可以采用预先定义的降级或延后发布路径，但不能绕过记录，让团队事后无法知道哪些语言仍是旧语义。
怎么落地
- 为每条消息使用不随源句改写而变化的 ID，并保存源修订、内容哈希、描述、使用位置、占位符与复数/性别分支；提取器对重复键、无主键和消息结构破坏直接报错。
- 将源仓库、内容系统和 TMS 接成事件链，把
missing/translated/reviewed/approved的翻译审阅状态与unpublished/published的部署状态分开。源再次变化时，任何仍绑定旧 source revision 的目标版本都转为stale或superseded，即使它已经发布；任何迁移都记录操作者、时间、规则版本和对应源修订。 - 按风险设置发布门：关键交易、安全、隐私或法律消息必须由授权审阅者针对当前源修订批准；低风险文案可进入有时限的积压，但必须执行已声明的回退策略。
- 在候选构建中生成逐语言清单，列出 missing、stale、占位符不兼容、孤儿消息和未完成审阅；用一次跨代码、TMS、审阅和发布包的追踪测试确认源变更能完整到达终点。