本文目录导读：
设计一个高效、可靠的开源项目翻译审校流程，需要平衡质量、效率和社区贡献者的参与度，以下是一个通用的、可定制的流程设计，结合了业界最佳实践（如 Crowdin、Weblate 等平台的经验）。
核心原则
- 版本一致性： 翻译必须与源代码保持同步（字符串冻结、锁定期）。
- 上下文优先： 译者必须能查阅屏幕截图、代码注释、术语表。
- 低门槛： 人人都能贡献建议,但审核权需分级。
- 自动化辅助： 利用机器检查（拼写、占位符、长度限制）减少人工负担。
角色与权限定义
清晰的角色分级是流程的基石：
| 角色 | 权限 | 来源 |
|---|---|---|
| 管理员 (Maintainer) | 最终发布、添加语言、管理审核员、配置规则 | 项目核心团队 |
| 审核员 (Proofreader/Reviewer) | 批准/拒绝翻译字符串、修改译文、管理术语表 | 资深贡献者、核心成员 |
| 译者 (Translator) | 提交新翻译、编辑未锁定的字符串、参与讨论 | 社区任何人 |
| 建议者 (Suggestion Provider) | 仅能提出翻译建议（平台模式） | 匿名用户、初学者 |
详细流程步骤（建议采用工单/PR + 平台混合模式）
阶段 1：准备与同步（通常是自动化）
- 源码提取： 开发者从代码库提取最新字符串（如 en.json）。
- 推送至平台： 通过 CI/CD 将新字符串推送到翻译管理平台（如 Crowdin、Weblate、GitLocalize）。
- 自动冻结： 锁定即将发布的版本字符串，禁止新翻译,避免版本错乱。
- 术语库更新： 管理员同步核心术语表中的新增词汇。
阶段 2：翻译（建议者 - 译者）
- 认领任务： 译者在平台上选择自己擅长的语言和文件模块（分散工作量）。
- 上下文辅助：
- 查看截图（Source Screenshot）
- 查看机器翻译（供参考）
- 查看术语库（高亮显示）
- 提交翻译：
- 译者直接提交翻译译文（替换原始字符串）。
- 或者建议者提出一项建议（草稿）。
- 自动检查： 平台自动运行 QA 检查（占位符匹配
%s、{0}、HTML 标签完整性、长度限制）。
阶段 3：审校（审核员）
这是流程的核心,通常有两种模式：
模式 A：单级审校（通用，适合中小项目）
- 审核员收到待审队列通知。
- 逐条审核：
- 语言正确性： 无错别字、符合地域习惯（如“你” vs “您”）。
- 一致性： 与术语库一致,与同一文件内其他部分风格匹配。
- 上下文适配： 不能仅直译（如英文的动词变为中文的名词）。
- 操作：
- 批准： 翻译进入“已批准”状态,等待发布。
- 拒接 + 反馈： 在评论区写理由（如“术语错误，请参考术语库第5条”）。
- 直接修改： 审核员可以直接在平台修改译文并批准（常用于纠正小错误）。
模式 B：双级审校（严谨，适合复杂/安全项目）
- 初级审校（Linguistic Reviewer）： 检查语法、术语、可读性。
- 技术审校（Technical Reviewer）： 检查占位符格式、转义字符、UI 显示是否换行、长度溢出,一般由核心开发者担任。
阶段 4：集成与发布
- 锁定期： 在发布前 X 小时,冻结所有翻译。
- 同步至仓库：
- 管理员手动或通过自动化 CI 将已批准的翻译文件（如
zh_CN.json） Pull Request 到项目 GitHub/GitLab 仓库。 - 重要： 触发 CI 构建，确保翻译文件格式无误（JSON 合规、YAML 缩进）。
- 管理员手动或通过自动化 CI 将已批准的翻译文件（如
- 最终审查： 项目维护者合并 PR,翻译随代码一起发布。
- 用户反馈： 建立链接（如在项目文档标明“报告翻译错误”）收集用户反馈。
关键工具与协作
- 翻译管理平台：
- Crowdin: 社区配合度高，有截图功能,适合大流量。
- Weblate: 开源、支持版本控制深度集成,适合自托管。
- GitLocalize: 轻量级，直接基于 GitHub PR 工作流。
- 术语管理：
- 在平台内维护一个
术语表（Glossary），包含禁止使用的词（Bas/Blacklist）。
- 在平台内维护一个
- 沟通渠道：
- 每个翻译字符串下方的讨论区（最有效）。
- 项目 Slack/Discord/Telegram 中设立
#i18n-chat频道。
质量保障机制（自动化）
强制性的 CI/CD 拦截 规则：
- 占位符完整性：
%1$s和{0}必须与源文字符串一一对应,数量要一致。 - 格式约束： 如日期格式
DD/MM/YYYY必须转为本地化格式YYYY-MM-DD。 - 无效转译： HTML 标签
<br>必须保留。 - 长度警告： UI 元素若限定 20 字宽度，翻译超过 30 字则标记为“可能导致界面截断”,需人工确认。
- 重复项： 检查同一个术语（如 “Save”）是否被不同译者翻译成不同中文词（“保存” vs “存储” vs “存档”）。
特殊场景处理
- 翻译冲突： 当两位译者对同一字符串有不同意见时,审核员介入投票或裁定。
- 紧急修复： 在发布前 1 小时发现严重错误。
- 允许审核员通过“绕过队列”直接编辑最终文件并推送热修复（需记录在案）。
- 新贡献者入门：
- 设置“翻译测试”（如翻译 5 条字符串并审核通过）后才能成为正式译者。
- 发放徽章（如 Crowdin 的 “Certified Translator”）。
反馈与迭代
- 定期评审： 每月或每季度检查翻译错误率。
- 质量报告： 哪些语言错误多？哪些是共性问题（如省略了冠词、性别错误）？
- 奖励机制： 在 README 或贡献者名单（CONTRIBUTORS.md）中显著列出活跃的翻译和审校人员。
一个推荐的简化流程
[开发者提交代码]
↓
[自动提取新字符串] → 推送到翻译平台
↓
[译者认领并翻译] → 自动 QA 检查
↓
[审校员逐条审校] → 批准 / 拒接并评论
↓
[审校员或管理员合并批准批次]
↓
[自动生成翻译 PR] → 触发 CI 构建 → 合并 → 发布
↓
[社区用户] → 反馈错误 → 维护者进入下一轮修改通过这样的流程，可以最大程度地确保开源项目翻译的一致性、准确性和时效性,同时让社区贡献者有明确的参与路径。
