开源项目的翻译审校流程如何设计

本文目录导读：

1. 核心原则
2. 角色与权限定义
3. 详细流程步骤（建议采用工单/PR + 平台混合模式）
4. 关键工具与协作
5. 质量保障机制（自动化）
6. 特殊场景处理
7. 反馈与迭代
8. 一个推荐的简化流程

设计一个高效、可靠的开源项目翻译审校流程，需要平衡质量、效率和社区贡献者的参与度，以下是一个通用的、可定制的流程设计，结合了业界最佳实践（如 Crowdin、Weblate 等平台的经验）。

核心原则

• 版本一致性： 翻译必须与源代码保持同步（字符串冻结、锁定期）。
• 上下文优先： 译者必须能查阅屏幕截图、代码注释、术语表。
• 低门槛： 人人都能贡献建议,但审核权需分级。
• 自动化辅助： 利用机器检查（拼写、占位符、长度限制）减少人工负担。

角色与权限定义

清晰的角色分级是流程的基石：

详细流程步骤（建议采用工单/PR + 平台混合模式）

阶段 1：准备与同步（通常是自动化）

1. 源码提取： 开发者从代码库提取最新字符串（如 en.json）。
2. 推送至平台： 通过 CI/CD 将新字符串推送到翻译管理平台（如 Crowdin、Weblate、GitLocalize）。
3. 自动冻结： 锁定即将发布的版本字符串，禁止新翻译,避免版本错乱。
4. 术语库更新： 管理员同步核心术语表中的新增词汇。

阶段 2：翻译（建议者 - 译者）

1. 认领任务： 译者在平台上选择自己擅长的语言和文件模块（分散工作量）。
2. 上下文辅助：
   • 查看截图（Source Screenshot）
   • 查看机器翻译（供参考）
   • 查看术语库（高亮显示）
3. 提交翻译：
   • 译者直接提交翻译译文（替换原始字符串）。
   • 或者建议者提出一项建议（草稿）。
4. 自动检查： 平台自动运行 QA 检查（占位符匹配 %s、{0}、HTML 标签完整性、长度限制）。

阶段 3：审校（审核员）

这是流程的核心,通常有两种模式：

模式 A：单级审校（通用，适合中小项目）

1. 审核员收到待审队列通知。
2. 逐条审核：
   • 语言正确性： 无错别字、符合地域习惯（如“你” vs “您”）。
   • 一致性： 与术语库一致,与同一文件内其他部分风格匹配。
   • 上下文适配： 不能仅直译（如英文的动词变为中文的名词）。
3. 操作：
   • 批准： 翻译进入“已批准”状态,等待发布。
   • 拒接 + 反馈： 在评论区写理由（如“术语错误，请参考术语库第5条”）。
   • 直接修改： 审核员可以直接在平台修改译文并批准（常用于纠正小错误）。

模式 B：双级审校（严谨，适合复杂/安全项目）

1. 初级审校（Linguistic Reviewer）： 检查语法、术语、可读性。
2. 技术审校（Technical Reviewer）： 检查占位符格式、转义字符、UI 显示是否换行、长度溢出,一般由核心开发者担任。

阶段 4：集成与发布

1. 锁定期： 在发布前 X 小时,冻结所有翻译。
2. 同步至仓库：
   • 管理员手动或通过自动化 CI 将已批准的翻译文件（如 zh_CN.json） Pull Request 到项目 GitHub/GitLab 仓库。
   • 重要： 触发 CI 构建，确保翻译文件格式无误（JSON 合规、YAML 缩进）。
3. 最终审查： 项目维护者合并 PR,翻译随代码一起发布。
4. 用户反馈： 建立链接（如在项目文档标明“报告翻译错误”）收集用户反馈。

关键工具与协作

• 翻译管理平台：
  • Crowdin: 社区配合度高，有截图功能,适合大流量。
  • Weblate: 开源、支持版本控制深度集成,适合自托管。
  • GitLocalize: 轻量级，直接基于 GitHub PR 工作流。
• 术语管理：
  • 在平台内维护一个 术语表（Glossary），包含禁止使用的词（Bas/Blacklist）。
• 沟通渠道：
  • 每个翻译字符串下方的讨论区（最有效）。
  • 项目 Slack/Discord/Telegram 中设立 #i18n-chat 频道。

质量保障机制（自动化）

强制性的 CI/CD 拦截 规则：

1. 占位符完整性： %1$s 和 {0} 必须与源文字符串一一对应,数量要一致。
2. 格式约束： 如日期格式 DD/MM/YYYY 必须转为本地化格式 YYYY-MM-DD。
3. 无效转译： HTML 标签 <br> 必须保留。
4. 长度警告： UI 元素若限定 20 字宽度，翻译超过 30 字则标记为“可能导致界面截断”,需人工确认。
5. 重复项： 检查同一个术语（如 “Save”）是否被不同译者翻译成不同中文词（“保存” vs “存储” vs “存档”）。

特殊场景处理

• 翻译冲突： 当两位译者对同一字符串有不同意见时,审核员介入投票或裁定。
• 紧急修复： 在发布前 1 小时发现严重错误。
  • 允许审核员通过“绕过队列”直接编辑最终文件并推送热修复（需记录在案）。
• 新贡献者入门：
  • 设置“翻译测试”（如翻译 5 条字符串并审核通过）后才能成为正式译者。
  • 发放徽章（如 Crowdin 的 “Certified Translator”）。

反馈与迭代

• 定期评审： 每月或每季度检查翻译错误率。
• 质量报告： 哪些语言错误多？哪些是共性问题（如省略了冠词、性别错误）？
• 奖励机制： 在 README 或贡献者名单（CONTRIBUTORS.md）中显著列出活跃的翻译和审校人员。

一个推荐的简化流程

[开发者提交代码]
       ↓
[自动提取新字符串] → 推送到翻译平台
       ↓
[译者认领并翻译] → 自动 QA 检查
       ↓
[审校员逐条审校] → 批准 / 拒接并评论
       ↓
[审校员或管理员合并批准批次]
       ↓
[自动生成翻译 PR] → 触发 CI 构建 → 合并 → 发布
       ↓
[社区用户] → 反馈错误 → 维护者进入下一轮修改

通过这样的流程，可以最大程度地确保开源项目翻译的一致性、准确性和时效性,同时让社区贡献者有明确的参与路径。