choose.md

主题：Kubernetes 中文本地化翻译分支的选型讨论

议题: 基于 Master 分支的任务流 时间: 2019年12月15日

议题1：基于 Master 任务流的方案选择

早期基于 Google 表格以 Master 分支翻译无法满足多语言多版本的需要，目前引入多语言、多版本的 Github issue 翻译流也有一定的问题，主要的问题是：

• 老旧的文章并不能呈现最新的翻译效果,对新人引导很不好
• 工作流问题 - master 老旧的，并不能呈现最新效果
• 老旧版本的 issue 实质是没有什么价值的
• 基于 release 分支，带来上游文档的合并问题

为解决上述问题，经讨论决议一致以 Master 分支为变更对象，基于 Master 分支目前也有两个方案：

方案一：

直接向 Master 分支提交翻译 PR

• Master -> Pr

由于直接向 master 提交 PR ，首先时效性比较好，其次不需要管理者向 master merge PR，有更少的人力介入，对译者而言，不需要关注不同的版本提交，不需要关注版本细节，更友好。

由于 master 冻结 release 之后，翻译状态也冻结了，对于具体版本重要文章的翻译可能中断，因此需要引入另外的修复方案，后期可以考虑使用 github 的项目功能，将一些具体版本翻译更新的文章，以项目形式将任务呈现出来，再安排具体人员来支持-此作为后续优化选项。

方案二(目前韩国/日本使用的方案,通过 slack 协作)：

基于 Release 分支 checkout Dev 分支，以 release Dev 分支提交翻译 PR 两周之后再将翻译分支的内容 merge 加 Master 主分支

• Master -> Dev -> Pr -> (2 week -> PR Master Merge )
  • 人为介入
    • 对译者而言要关注不同的 release 版本提交
    • 对管理者而言 Merge 成本相对比较高
    • 基于最新 Release Dev 分支，时效性要差（因为目前 website 是以 master 分支呈现的）

最终方案选择

经过讨论决议，使用方案一，即直接向 Master 提交 Pr

工作内容安排

Task1. 初始化中文文档状态 (已完成)

在一周以内会提交三个 Pr - by 刘对

将 release-1.16-temporary 分支 zh 中文内容同步到下面三个分支上面..

• 1.16 zh -> 1.16 zh
• 1.16 zh -> 1.17 zh
• 1.16 zh -> master zh

Task2. 基于1.17/1.16 英文差异生成新的翻译任务 (进行中)

1. 在每次 release 冻结版本时，根据英文文档差异生成 issue （create/update/delete）
2. 对每周的报表生成进行自动化管理- 引入 github CI/CD 流程进行自动化维护
3. 手动对齐 Release 内容(翻译状态冻结) - 后续优化
   • 1.17 -> 小的变更
     • 建 project 对具体冻结版本的翻译状态进行处理 - 优化