干货｜人人都是翻译项目的Master

摘要：开始翻译函数式编程专有名词库在翻译的过程中，难免会遇到很多描述不太清楚的专有名词，一个办法是小组内进行讨论，最后商量出来结果，小组内统一翻译。因为本书的主题是函数式编程，所以这个名词库里大部分都是函数式编程相关的专有名词。

在平时的工作中，我们都会经常查阅一些英文文档来解决平时遇到的问题和拓宽视野。看到好的文章或者书籍有没有想要和小伙伴分享的冲动，那么我们一起来翻译吧～

翻译主张 “信 达 雅” 。“信”指意义不悖原文，即是译文要准确，不偏离，不遗漏，也不要随意增减意思；“达”指不拘泥于原文形式，译文通顺明白；“雅”则指译文时选用的词语要得体，追求文章本身的古雅，简明优雅。身为非专业翻译人员，要达到以上三点不是很容易的，但是我们要尽可能往这个方向上努力。一是提高自己的表达水平和阅读能力；二是能够让读者更加的明白作者本来的思想。有句话说得好：当把别人讲明白的时候，自己才算是真正的理解了。

2017 年 6 月 5 日，iKcamp 开始翻译第二本书 —— 《JavaScript 轻量级函数式编程》。如果你看过 iKcamp 最近在掘金、知乎或者公众号上发过的关于这本书的文章，应该对本书有一个大致的了解，本书的作者是火爆全球的 《你不知道的 JavaScript》 一书原作者 。旨在探索函数式编程的核心思想，但是并不会使用大量复杂的概念来诠释，所以称之为“轻量级函数式编程”。“轻量”并不意味着本书是一本“入门级”的书籍，相反，本书包含各种复杂的细节，深入探讨每个知识点，希望可以让读者对函数式编程有一个更深的理解。

身为这次翻译项目的 Master，在这个过程中学会了如何组织一次翻译项目，如何定制翻译计划。秉承着 iKcamp 的分享精神，下面介绍一下我们这次翻译的流程、遇到的一些问题、解决的方式以及待优化的点。希望大家看了之后可以对组织翻译项目有一定的理解，然后也可以提出自己的建议或者解决方案，也可以应用在自己的项目中。

书名：《Functional-Light JavaScript》

作者： Kyle Simpson

文章数量： 21 篇

参与成员： iKcamp 中的 17 名童鞋

预计完成时间： 2 个月

在开始翻译之前，有很多问题都需要考虑好，下面几点也是我在项目开始之前都考虑的问题，列出来和大家探讨一下：

如何确保翻译质量

如何让每位成员都熟知翻译流程和翻译规范

如何确保翻译进度

成员之间的联系方式

翻译项目自然是翻译质量最重要，那么如何在成员还不算少的情况下确保翻译质量和翻译进度呢？
和小伙伴 Au 商量一番之后，我们决定采用分组制的策略。Master 对接组长，组长对接组内成员，组长由有翻译经验的小伙伴担当。分组的好处有以下几点。

由于组长已经参加过翻译计划，就能更好的解答组内小伙伴的疑问

组长有更自由的职责分配和更多的权利来掌控组内成员的翻译进度和翻译质量

由组长把控组内的翻译质量，继而再由 Master 管控小组的翻译质量

如果让每位成员都熟知翻译流程和翻译规范，那么就要满足下面的几点要求：

要有一个文档，上面清晰的写着如何走完整个翻译流程。

这个文档要方便打开，并且支持各个系统，没有格式的阻碍。

每位小伙伴都可以随时访问到。

基于以上几点要求，我们最终采取的策略是在 GitHub 上新建一个仓库，用 Markdown 的形式，以读者的视角把整个翻译流程展示出来。具体链接可以戳这里。

其实这个是很头疼的一点，因为参与的小伙伴可能来自不同的公司和不同的部门，那么他们的时间也是不确定的。可能有时候忙一些，有时候闲一些，怎么才能在确保翻译进度的前提下让小伙伴高质量的完成翻译呢？

我当时想的办法是给每一个流程规定一个 deadline，这个 deadline 是根据项目进度来说能给的最宽裕的时间，然后在认领翻译的时候，小伙伴可以根据自己最近时间的宽裕程度来决定翻译完成的时间，只要在这个 deadline 之前都可以。下面是我们认领时候的一张截图。

基本格式为：认领类型（翻译／校对认领）- 截止时间。
这样就可以不用强制每个人的进度，让小伙伴自己来掌控进度。时间是自己选的，哈哈，那就要在规定的时间完成咯。

iKcamp 的小伙伴来自不同的公司和不通的部门，但是现在共同参加了一个翻译项目。那么如何可以让小伙伴都能明确的知道目前项目的进度以及一起讨论问题呢？这里我们就需要一个平台，可以可视化目前项目的进度，还需要一个可以交流的平台。
当时我想到了一下几种工具：

Google Docs

Teambition

GitHub

微信

当时觉得用 Teambition 还不错，可视化，而且能清楚的看到项目目前的进度，可是后来对比了一下 GitHub 的方案，发现其实这些 GitHub 也能做到，比如说用 GitHub 的 label，给每个流程的 label 命名也能很清晰的看到目前项目的进度，而且 GitHub 相对于技术人员更专业一些。关于讨论问题这方面，就要找到一个让大家都能参与进来，而且很方便的工具。所以最后就选用了 GitHub 来可视化项目的进度，用微信群来讨论。

解决了上面的问题，那其实准备工作就做的差不多了，下面就按照流程一步一步的来就好啦。

翻译大概可以概括为以下几步：

准备工作

以小组的形式自愿认领翻译文章

翻译，校对

整合

Master 把每篇文章提一个 issue，并且每个 issue 附上相对应的 label，用 label 可以很直观的来确认文章目前的进度。我把 issue 的 label 分为 8 种：

不同的 label 对应着目前的文章进度。在 issue 的下方附上对应原文的地址，这样可以让译者更方便的找到对应的原文去翻译，还是上面的那张图片：

分好小组之后，下面开始以组为单位认领翻译文章。每个小组内的小伙伴会商量一下想翻译哪些文章，然后再以组为单位到 label 为翻译认领的 issue 下面认领文章。

组长到对应的 issue 下面留言“认领翻译”之后， Master 会把 issue 的状态由 “翻译认领” 切换为 “正在翻译”。

分配好小组，认领完文章之后，会留时间让大家认真的阅读翻译流程和翻译规范。磨刀不误砍柴工，这些都是翻译工作开始之前的基础，熟悉了这些之后，能够避免很多错误和减少校对的工作量。

在翻译的过程中，难免会遇到很多描述不太清楚的专有名词，一个办法是小组内进行讨论，最后商量出来结果，小组内统一翻译。可是这样有一个不好的地方就是：小组内虽然统一了，可是组与组之间并没有统一。所以在这里，我们建了一个函数式编程专有名词库，把在翻译过程中遇到的专有名词及其翻译都添加到这个库中，这样大家翻译的时候遇到不太明白的就可以在此库中查找，统一了大家的翻译，不会出现一词两译的情况。

因为本书的主题是函数式编程，所以这个名词库里大部分都是函数式编程相关的专有名词。大家可以按照项目的不同来决定名词库的主题，也可以把翻译过程中遇到的所有名词都放在一起，这个就看你们的需求啦。

小伙伴完成翻译之后，要在 GitHub 上发起 Pull request，然后在 PR 下留言写上对应的 issue 链接。这样 PR 和 issue 就关联起来了。之后的工作就主要在 PR 下留言完成。

下面为发起 Pull request 的两种方式：

点击按钮之后，会出现下面的页面，在图中可以看到，先选择目标分支，然后选择翻译时自己建的分支，此时就会产生文件的对比，然后点击下方的 Create pull request 绿色按钮，就成功的发起了一个 Pull request。

到目前为止，翻译流程已经结束了，翻译过程可以概括为下面的几步：

当译者完成翻译发起 Pull request 之后，在对应的 Pull request 下方会有译者的提交记录。

点进去，就会看到译者的改动点，把鼠标放到你认为需要修改的那一行，会出来一个深蓝色的加号，点击加号，会出来一个文本框，在里面输入你的建议，点击绿色按钮 Start a review 即可。

第一轮校对是组内校对，组内成员之间交换文章，检查基本的语法和格式问题并修改。这样在进行第二轮校对的时候就减轻少了一些工作量。

一校完成之后，相当于每篇文章都符合基本的格式规范，都能够表达出来作者的基本思想了。下一步就要开始进行“真正的”校对 —— 二校。二校主要校对文章句子的准确度和顺畅度，还有格式。

和认领翻译的文章一样，不做任何限制，组内成员商量想要认领的文章，然后到 label 为校对认领的 PR 下面留言认领校对。

每次校对完成之后，翻译此文章的小伙伴都要根据校对者的意见进行一次修改。在修改过程中可以把一些想法和建议丢到小组内商量，如果和校对者意见不一致的地方，也可以在校对者的留言下方进行回复商量。最终确定修改的方案。

经历了一次翻译、两次校对和两次修改之后，文章整体都差不多了，不过还差最后一步，就是作为一名读者去真正的阅读文章：切身的去体会读者的感受；句子读着是否顺口；有没有格式错误影响阅读体验。所以接下来就是最后一轮校对 —— 终校。每位小伙伴可以选择自己感兴趣的文章进行校对。同时也鼓励大家，有哪些看不懂的地方就在下方留言，我们一同讨论解决办法。

在此大家可能会有一个误会，就是校对比翻译更轻松一些。其实我并不是这样认为的。我觉得翻译和校对同样重要，他们的时间比重应该是大差不差的。校对者要确保文章的表达力度、格式及能否被读者所理解，付出的时间也和翻译相当或者更甚。所以，我们的校对不止进行了一遍。尽量做到能清楚的表达作者的意思，而且容易让读者理解。
在此次的翻译中，我也为大家留了充足的时间去校对，文本格式、表达意思都会去斟酌，相信付出的时间和成果是成正比的。

文章有很多互相引用的地方，比如第 6 章会引用第 2 章的段落标题。由于在翻译过程中译者对于作者的思想和上下文的语境可能理解的不是很透彻，所以我们把这一步放在了最后。在最后一步我们统一修改引用的地方，确保上下文一致。

整个翻译项目大致是上面介绍的这些，流程可以概括为下图：

历经 2 个月，在 iKcamp 小伙伴的热情和坚持下本书顺利完成。我相信，iKcamp 的小伙伴在本次翻译中也收获颇丰，同时也克服了很大的困难。在工作压力大的情况下，还能保质保量的完成本书的工作，不仅是热情，还有责任感在推动着我们完成本书的翻译工作。在此特特别的感谢 ikcamp 的全体成员。也欢迎有兴趣的小伙伴加入到 iKcamp 中来，我们一起玩技术～

不过对于翻译项目的 Master 来说，道路还很遥远，因为是第一次担任翻译项目的 Master，很多地方还是欠缺经验，在这个过程中多亏了 Au 还有周妈妈以及小伙伴们的帮忙和配合才完成了此书的翻译。这次翻译流程还有以下需要优化的点，之后大家在组织翻译项目的时候可以想一些更有趣的方法。

在翻译和校对阶段的无缝衔接

保持项目进度

翻译的统一性

JavaScript 轻量级函数式编程

函数式编程专有名词库

翻译规范 —— 包含翻译流程文档、排版规则和校对规范。

iKcamp原创新书《移动Web前端高效开发实战》已在亚马逊、京东、当当开售。

报名地址：http://www.huodongxing.com/ev...
与“天天练口语”小程序总榜排名第四、教育类排名第一的研发团队，面对面沟通交流。