Skip to content

Latest commit

 

History

History
123 lines (78 loc) · 8.34 KB

翻译流程详细说明.md

File metadata and controls

123 lines (78 loc) · 8.34 KB
Raw

翻译流程

为什么我们需要有流程？

下面是没有流程会导致的问题:

  1. 译者不知道哪些文章正在翻译，导致多人翻译同一篇
  2. 校对不知道哪些文章需要校对，哪些文章已经完成校对
  3. 发布不知道哪些文章可以发布

之前的流程存在的问题

翻译组目前使用过三个流程，简单列举如下：

  1. Tower 管理文章，在 Tower 认领任务，改变状态的方式是拖拽任务到不同的状态列表（比如翻译中、校对中），校对完毕后上传新文件
  2. GitHub Issue 管理文章，使用 Issue Assignee 认领任务，通过标签表示状态，校对直接在 Issue 进行
  3. GitHub Issue 管理文章 + GitHub Pull Request 校对，使用 Issue Assignee 认领任务，不同流程的负责人把 Assignee 设置为自己，通过标签表示状态，校对使用通用的 code review 流程

1 -> 2 的原因是 Tower 使用比较麻烦，毕竟是独立的网站，每次都要登录。

2 -> 3 的原因是 Issue 做校对不方便，也不方便译者对比改动内容，所以采用标准的 Code Review 流程

那 3 存在什么问题？

3 的问题在于，标签和 Assignee 的改动其实是多余的，流程本身已经能解决我们遇到的问题，加上标签和 Assignee 反而增加了无用操作，而且可能漏改，造成其他人误解。

去掉标签和 Assignee 改动之后，不同角色要做的操作如下：

文章收集

目前使用 zapier 每个月自动发提醒邮件，因此不需要主动查看，收到邮件之后去检查即可。

目前设置的是每个月 9 号发送提醒邮件，如果换人负责文章收集，请联系 @numbbbbb 添加负责人的邮箱。

任何人如果发现某个来源站有未收录的新文章想要翻译，可以按照下面步骤 3 创建 Issue，并联系 @numbbbbb 或 @Nemocdz 更新该来源站的最后收录文章

定期遍历我们的来源站，对比查看是否有新文章，过滤掉过时或者太初级的文章，把剩下的加入 Issue 列表。

什么是过时的文章？举例：现在已经到了 Swift 5/iOS 13，文章讲的是 Swift 3/iOS 8 的特性。

什么是太初级的文章？举例：教你如何创建一个 TableView；教你如何声明一个函数。换句话说，随便搜索就有一大堆的入门内容，我们尽量不花时间翻译，价值不大。

说明：这里不去衡量文章本身的好坏，只过滤掉确定没价值的内容。文章的好坏由译者去判断。如果一篇文章加入 Issue 超过半年都没人认领，就说明文章不适合翻译，从 Issue 中删除。

具体步骤：

  1. 查看 来源站记录，对比每个来源站，如果在最后检查日期之后有新文章，进入步骤 2，如果无更新，进入步骤 5
  2. 判断新文章是否适合翻译
  3. 如果适合，创建新 Issue，标题是文章篇幅 + 文章标题，内容按照 Issue 的模板填写，需要填写原文链接、作者、原文日期
  4. 更新来源站的最后收录文章，填写原文链接和 Issue 号码，便于回溯
  5. 更新来源站的最后检查日期，填写你检查当天的日期，便于下次查看时对比

翻译

  1. 查看 Issue 列表，从 Assignee 为空的文章中寻找自己感兴趣的文章（如果要翻译 NSHipster 的文章，请参考 这个说明）
  2. 确定要翻译的文章之后，点击打开 Issue，在右侧的“Assignees”栏点击“assign yourself”
  3. 开始翻译。翻译的文章统一放在网站对应的文件夹下，例如 appcode 站点的文章放在 appcode 文件夹下。文件命名方法：原文日期_原文标题.md，比如 20160726_simple-barcode-reader-app-swift.md。如果不确定文章放在哪里，群里问@BigNerdCoding
  4. 翻译的时候要注意格式，尤其是中英文和代码，可以参考 这个说明
  5. 根据之前的经验，我们总结了 翻译常见问题，内容很短，请译者在翻译之前阅读本文。如果翻译过程遇到新问题，在群里提问，如果是常见问题会更新到本文中。
  6. 翻译过程中，文章头部需要添加通用头部，具体格式可以参考 这个说明，还有 这个例子
  7. 翻译完成后，在进行下一步之前务必自查这三件事：1. 文章头部格式符合文档要求，2. 文章内容格式符合文档要求，3. 翻译完成后，至少间隔一天，重新阅读整篇译文，从读者角度阅读，出声阅读，把所有读着别扭、不通顺的句子都修改好
  8. 完成上一步之后，按照 这个说明 创建 Pull Request，在 Pull Request 的内容里关联对应的 Issue，关联方式：把 Issue 页面的网址复制到 Pull Request 信息中，或者直接在 Pull Request 信息中评论 #11，11 是对应的 Issue 号

下面是关联方式的图解：

校对

  1. 查看 Pull Request 列表，选择有“review required”标识的 PR 进行校对（详细说明见下图）
  2. 校对过程中，发现问题就直接评论在对应行（鼠标移动到对应行，行首会出现一个蓝色加号，点击之后可以写评论，写完点绿色的“Start a review”）
  3. 校对结束后，点击页面右上角的“Review changes”，如果需要译者修改就勾选“Request changes”，如果不需要译者修改就勾选“Approve”，然后点击“Submit review”
  4. 等待译者修改完毕再次提交后，要再去校对，直到你发现的所有问题都被修复才可以选择“Approve”

校对的注意事项：

  1. 如果原文有很多问题，比如大量的格式错误、翻译错误、不通顺语句，说明译者自查不够，通知译者重新自查，在 PR 下方评论说明，自查完成前不进行校对
  2. 校对的重点是确认翻译正确，并且语句通顺。首先对比原文，找到翻译错误的地方；然后抛开原文从读者角度阅读译文，找出读着别扭不通顺的地方

第 1 步的 PR 说明如下图：

注意：校对不需要修改 Issue 和 PR 的 Assignee，按照上面四步流程操作即可。

发布

  1. 查看 Pull Request 列表，选择有“Approved”标识的 PR（详细说明见下图）
  2. 打开 PR，点击底部“Merge”按钮旁边的小三角，选择“Squash and merge”，然后点击“Squash and merge”按钮，执行合并操作（操作说明见下图）；这样做的目的是把这个 PR 的所有 commit 合并成一个并 merge，让 repo 的 commit 记录更加简洁
  3. 发布文章
  4. close PR 对应的 Issue，表示文章已经发布结束

第 1 步的 PR 说明如下图：

第 2 步的操作说明如下图：

新流程是否解决问题？

新流程去掉了标签，也不需要再根据阶段更改 Assignee。我们来看看，新流程是否解决了我们的问题。

首先，我们要解决的问题是：

  1. 译者不知道哪些文章正在翻译，导致多人翻译同一篇
  2. 校对不知道哪些文章需要校对，哪些文章已经完成校对
  3. 发布不知道哪些文章可以发布

对应的，新流程的解决方法：

  1. 译者通过 Issue 的 Assignee 可以判断文章是否有人认领
  2. 校对可以通过 PR 状态判断哪些需要校对，哪些完成校对
  3. 发布可以通过 PR 状态判断哪些文章可以发布