源内容变更检测让翻译审核更可靠

翻译可以是正确的，但仍然可能已经过时。

当编辑在翻译开始后修改源条目时，就会发生这种情况。本地化草稿仍然反映最初的快照，但审核界面显示的可能是最新的源内容。除非工作流标记出这种差异，否则审核者可能会批准两份实际上从未真正进行过比较的内容。

源内容变更检测可以防止这种隐蔽的不匹配进入发布流程。

翻译始于一个快照

每个翻译请求都有一个源边界：即某一时刻的一组字段、值和富文本结构。

这个快照应当与请求一起保存。它说明了模型接收到的内容、审核者正在评估的内容，以及为什么目标草稿会写成现在这样。

重新获取源内容用于展示是有用的，但它绝不能替代历史快照。工作流两者都需要：

• 用于生成草稿的源内容
• CMS 中当前的源内容

没有前者，草稿就没有可靠的来源依据。没有后者，团队就无法看到页面内容已经发生了变化。

不是每一次变更都会让一切失效

单靠时间戳可以告诉你某个条目发生了变化，但不能告诉你翻译是否已经过期。

编辑可能更新了一条内部备注、向非本地化字段添加了一个资源，或者修正了一个未包含在请求中的字段。这些变更不一定应该阻止本地化草稿继续使用。

应该在已翻译字段这一层进行比较。如果源标题变了，就将标题草稿标记为过期。如果只有正文变了，就保留已审核的标题不变，并让正文重新进入处理范围。

精细化的失效判定可以保留已经完成的工作，同时明确暴露剩余风险。

向审核者展示实际差异

“源内容已变更”是一种警告，不是一项决定。

审核者需要看到原始快照与当前值之间究竟发生了什么变化。对于纯文本，词级 diff 可能已经足够。对于富文本，比对还应显示结构性变化，例如链接被移除、新增了一个列表项，或者嵌入的条目发生了变化。

真正有用的问题，不只是字符串是否不同，而是已批准的目标内容是否仍然准确表达了当前的源内容。

为团队提供有意识的选择

当某个已翻译的源字段发生变化时，工作流可以提供一小组清晰的处理路径：

1. 当变更不影响含义时，保留当前翻译
2. 手动编辑本地化草稿
3. 仅重新生成受影响的字段
4. 当变更范围较大时，将请求退回翻译阶段

应当记录所做的选择以及审核者信息。一个可以在没有审计痕迹的情况下被忽略的“已过期”警告，在发布压力下很容易被无视。

推送前重新检查

审核可能在源内容一致的情况下开始，却在另一次编辑提交后结束。

在推送到 CMS 之前，立即再次运行源内容比对。最后这次检查可以弥合批准与交付之间的空档。它应当使用与审核界面相同的字段级规则，并且只阻止受影响的写入操作。

对于自动化发布，这项检查更为重要。自动化消除了人工暂停，因此系统必须精确判断自己愿意发布的是哪一个已批准的快照。

要点总结

只有当被审核的源内容正是生成草稿的源内容时，翻译审核才值得信赖。

保存原始快照，将其与 CMS 中的当前值进行比较，按字段识别变更，并让审核者有意识地处理有意义的差异。源内容变更检测不会拖慢本地化速度。它能防止团队满怀信心地把昨天的答案发布到今天的内容上。