开源文档与电子书的多语言治理：Crowdin、Weblate 与 Git 分支选型及防脱节指南

大家好，我是小秦。最近在整理一个开源电子书项目的国际化（i18n）流程，发现长篇文档的多语言治理中，最头疼的永远不是“初始翻译”，而是“源版本迭代几次后，译文悄无声息地脱节”。

梳理了一下目前社区里常见的几种协作流：

• 方案 A：Git 原生架构（单仓语言目录 / 独立语言分支）
  典型出处：早期 React 官方文档翻译、各语言版本的 Rust Book
  痛点：完全依靠 PR 审查，源文件段落增删后，译者很难快速定位具体的变更 diff，容易漏更。
• 方案 B：云端翻译平台（Crowdin）
  典型出处：Vue.js 文档、VS Code 插件生态
  痛点：对排版格式复杂的长篇 Markdown 切割有时不够自然，且重度依赖外部 SaaS。
• 方案 C：开源自托管平台（Weblate）
  典型出处：Fedora、Godot 引擎文档
  痛点：支持 Git 双向持续同步，版本控制更纯粹，但需要团队承担部署与维护成本。

想请教各位经常维护文档和开源书的朋友：

1. 针对长文本（非单纯的 UI 词条），大家是如何做**变更追踪（Outdated Notice）**的？是借助平台机制，还是自研了基于 Git Commit SHA 校验的 CI 提示脚本？
2. 如果兼顾“外部贡献者的参与门槛”和“长期版本对齐”，目前你们最推荐哪种治理方案？

欢迎大家分享正在运行的项目实践，我也顺便做个归纳，整理一份参考方案供社区查阅。