摘要：開始翻譯函數式編程專有名詞庫在翻譯的過程中，難免會遇到很多描述不太清楚的專有名詞，一個辦法是小組內進行討論，最后商量出來結果，小組內統一翻譯。因為本書的主題是函數式編程，所以這個名詞庫里大部分都是函數式編程相關的專有名詞。

在平時的工作中，我們都會經常查閱一些英文文檔來解決平時遇到的問題和拓寬視野。看到好的文章或者書籍有沒有想要和小伙伴分享的沖動，那么我們一起來翻譯吧～

翻譯主張 “信 達 雅” 。“信”指意義不悖原文，即是譯文要準確，不偏離，不遺漏，也不要隨意增減意思；“達”指不拘泥于原文形式，譯文通順明白；“雅”則指譯文時選用的詞語要得體，追求文章本身的古雅，簡明優雅。身為非專業翻譯人員，要達到以上三點不是很容易的，但是我們要盡可能往這個方向上努力。一是提高自己的表達水平和閱讀能力；二是能夠讓讀者更加的明白作者本來的思想。有句話說得好：當把別人講明白的時候，自己才算是真正的理解了。

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...
與“天天練口語”小程序總榜排名第四、教育類排名第一的研發團隊，面對面溝通交流。