先讲为什么：这是在解决什么问题
想象一下同时跑十几个语种的本地化项目，文本频繁修改、设计文档被反复覆盖、翻译记忆没被复用、上线前才发现大量译文冲突。版本控制与变更追踪就是为了解决这些痛点：避免翻译重复劳动、明确谁改了什么、什么时候发布、以及如何安全回滚。
几个核心目标
- 可回溯：每处翻译能追溯到原始提交和需求工单。
- 一致性：术语表与TM在不同语言间保持统一。
- 效率：自动化抽取/回写减少手工对接。
- 质量管控：静态校验、术语检查、双向QA嵌入流程。
核心概念与工具选型
先把名词讲清楚，免得后面听着云里雾里。
常见术语（简要）
- 源仓库（Repo）：存放源语言与项目资源的版本库，通常用 Git。
- 分支策略：如何使用主干、功能分支、发布分支和热修复分支。
- XLIFF / JSON / YAML：常用的可抽取、可回写的本地化文件格式。
- CAT / TM：计算机辅助翻译工具与翻译记忆库，用于复用译文。
- CI（持续集成）：自动化抽取字符串、触发翻译、回写与构建的流水线。
工具建议（按职责）
- 版本控制：Git（配合平台：GitHub/GitLab/Bitbucket），便于分支与PR流程。
- 本地化平台：支持XLIFF/JSON同步、TM导入导出、自动字符串分配的SaaS或自托管平台。
- CAT工具：支持TM与术语库的Trados、MemoQ或在线编辑器。
- CI/CD：Jenkins/GitLab CI/GitHub Actions，用于自动化抽取、导入、回写与构建。
推荐的版本控制与变更追踪流程（步骤化）
下面是一个可落地的流程，从准备到上线、回滚都有覆盖，按步骤走会清晰很多。
1. 规范化资源与目录
- 把可翻译资源集中目录管理，按平台（Web、iOS、Android）、功能模块分层。
- 使用键值对（key:value）而非整段翻译在代码里，以便差分与抽取。
- 统一文件格式，Web优先JSON/i18n，移动端用strings/xliff，文档说明写清楚。
2. 建立分支策略（示例）
选择适合团队的分支模型，常见两种：
| 策略 | 适用场景 | 优点 | 缺点 |
| Trunk-based（主干开发） | 频繁小发布、快速迭代团队 | 合并冲突少、发布快 | 需要更严格的自动化测试与审查 |
| GitFlow（功能分支+发布分支） | 较稳定发布节奏、大型项目 | 发布与维护分离，便于回滚 | 分支管理复杂，合并频率高 |
对翻译团队来说，常见做法是：主干保留最新上线代码，功能分支负责新增文案，发布分支打包向本地化平台同步。热修复走独立 hotfix 分支并优先合并。
3. 提交流程与变更元数据
- 每次提交必须关联工单 ID（例如 JIRA-1234）并使用约定式提交信息（Conventional Commits），如: feat(i18n): add login error keys #JIRA-1234。
- 提交信息包含：变更类型、模块、受影响语种、回滚注意。
- PR 模板应包含：变更摘要、受影响字符串列表（keys）、是否影响已有译文、TM建议。
4. 自动化抽取和回写（CI 流水线）
把人工环节自动化会把效率提升好几档，推荐的流水线步骤：
- 触发点：当某个分支合并到 main / release 时触发抽取任务。
- 步骤顺序：抽取 -> 打包 XLIFF/JSON -> 上传到本地化平台 -> 通知译员/触发机器翻译 -> 翻译完成后回写 -> 自动校验 -> 创建 MR/PR 并通知开发。
- 在回写前做一次术语和占位符检查（占位符丢失是常见错误）。
5. 变更追踪的细粒度做法
- 对每个翻译单元（string）赋予唯一 ID，与原始提交/句子索引绑定。
- 把翻译单元变更记录到变更日志（changelog）并关联工单。
- 版本号策略采用语义化版本（SemVer）并在发布说明中列出受影响语言与译文责任人。
示例：一次从代码改动到上线的完整周期
走一遍流程就明白了。
- 开发在 feature/login-text 分支增加了错误提示文本，提交信息：feat(i18n): add login error keys #PROJ-88。
- 合并到 release 分支后，CI 抽取出新增 keys，生成 XLIFF，上传到本地化平台并触发机器翻译与翻译者任务分配。
- 译员完成后平台进行 QA（术语、占位符、长度溢出检测），若有问题则在翻译任务中回退给译员或在 PR 中提出评论。
- 合格的译文回写到 release 分支对应的 locale 文件，CI 运行集成测试并生成构建包，发布候选环境供产品与本地化校对。
- 若上线出现问题，团队通过 PR 记录的提交 ID 回溯，使用 git revert 或 hotfix 分支快速回滚并修复。
变更追踪表单样例（用于记录每次译文改动）
| 字段 | 说明 |
| 工单ID | 关联的需求或缺陷编号（必填） |
| 字符串ID | 唯一键，用于在TM中定位历史译文 |
| 改动类型 | 新增/修改/删除 |
| 影响语种 | 列出受影响的所有目标语言 |
| 译者 | 责任人 |
| 回滚策略 | 是否允许自动回滚或需人工确认 |
实践建议与容易犯的错误
- 不要把翻译文件当成设计稿来改：译文回写必须由流程驱动，避免直接在生产分支上手动改译文。
- 统一占位符格式：例如使用 {username} 或 %s，团队内达成一致并自动校验。
- 及时更新 TM 与术语表：把批准的译文同步回 TM，减少重复工作。
- 注意长文本与UI适配：某些语言长度会超出设计，需在PR中标注并在发布前进行视觉校验。
- 二进制文件慎用版本控制：如设计稿或音视频，考虑外部资产管理并在变更日志中记录引用版本。
常见问题（FAQ）
如何处理紧急修复（Hotfix）？
建立 hotfix 分支，先在该分支做最小改动并通过快速回归测试。翻译改动尽量在本地化平台做小批量优先级处理，并在修复合并回主干后，再把翻译合并到长期分支。
如果翻译周期赶不上代码节奏怎么办？
两条策略：一是优先把关键文案标记为必须翻译并走加急通道；二是采用逐步发布（feature flag）让未翻译语言暂时隐藏或回退到默认语言，等译文就绪后再打开。
如何保证翻译质量？
组合方法最有效：术语库 + TM + 自动校验（占位符、格式、长度）+ 人工校对（双检）+ 线上监控（用户举报/反馈）。
小贴士：让流程更顺手的细节
- PR 模版里自动列出受影响字符串，减少手工统计。
- 把翻译任务与 CI 状态挂钩，只有当翻译 QA 通过才允许合并到发布分支。
- 对长期项目保持周期性的 TM 清理和统计，识别常用短语以提升复用率。
- 定期做回溯会议，追踪未通过 QA 的常见原因并在流程中修补。
流程搭好了只是开始，实际运作中会遇到各种小磕碰：术语争议、占位符出错、某些语言爆行长导致布局崩塌——这些都需要产品、开发与本地化三方在PR里多说几句，慢慢磨合出最符合团队节奏的版本控制与变更追踪方式，接着你会发现，翻译不再是上线前的噩梦，而成了可管理的常态。