重新思考文档翻译：将翻译视为有版本管理的软件资产

在大型文档库中，翻译问题很少会大声失败。相反，它们默默地失败并随着时间积累。最近，我们在Co-op Translator处理翻译的方式上做出了一个根本性的设计决策。

翻译现在被视为**“有版本的软件资产”**，而不仅仅是静态输出。

当翻译默默成为负担时

在大多数项目中，翻译一旦完成即被视为有效，直到有人明确注意到问题。然而，随着源文本的演变和代码示例的变化，即使翻译内容阅读流畅，也会变得过时。这不再是翻译质量问题；这是一个维护问题。

我们不得不改变核心问题：

• “这个翻译正确吗？”（X）
• “这个翻译仍与当前源文本同步吗？”（O）

决策：将翻译视为版本化资产

从Co-op Translator 0.16.2开始，我们刻意将翻译定义为有版本的资产。这不仅适用于Markdown文件，也适用于图片、笔记本及任何其他翻译产物。

我们没有发明新的机制，而是借鉴了如pip、poetry和npm等软件依赖管理工具。当一个依赖过时时，它不是“错误”的——只是与当前版本不同步。我们将同样的逻辑应用于文档。

关键变化和好处

1. 从嵌入标记到显式状态

以前，翻译元数据存在于文件中的注释里，导致碎片化且容易遗漏。现在，我们使用语言范围内的JSON状态文件来跟踪源版本、翻译产物及其同步状态。翻译状态现已成为仓库中第一类可检查的部分。

2. 扩展到图片和笔记本

同样的模型适用于非文本资产。如果源图片更改，则翻译版本会立即被标记为“不同步”。这确保了仓库内所有内容类型的一致性。

3. 可观察的维护

此设计实现了：

• 显式漂移检测： 不再猜测哪些文件过时。
• 一致信号： 文本、图片和笔记本都遵循相同的同步规则。
• 可扩展性： 维护从被动响应任务转变为可观察、可管理的工作流程。

结论

通过将翻译建模为软件资产，模糊消失了。状态变得可见，维护变得可控。问题不再是翻译漂移是否存在，而是：“你能看到它吗？”

---

参考链接：

• Co-op Translator GitHub 仓库
• 微软技术社区原创文章