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

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

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

2017 年 6 月 5 日，iKcamp 開始翻譯第二本書 —— 《JavaScript 輕量級函數(shù)式編程》。如果你看過 iKcamp 最近在掘金、知乎或者公眾號上發(fā)過的關(guān)于這本書的文章，應(yīng)該對本書有一個大致的了解，本書的作者是火爆全球的 《你不知道的 JavaScript》 一書原作者 。旨在探索函數(shù)式編程的核心思想，但是并不會使用大量復(fù)雜的概念來詮釋，所以稱之為“輕量級函數(shù)式編程”?！拜p量”并不意味著本書是一本“入門級”的書籍，相反，本書包含各種復(fù)雜的細(xì)節(jié)，深入探討每個知識點，希望可以讓讀者對函數(shù)式編程有一個更深的理解。

身為這次翻譯項目的 Master，在這個過程中學(xué)會了如何組織一次翻譯項目，如何定制翻譯計劃。秉承著 iKcamp 的分享精神，下面介紹一下我們這次翻譯的流程、遇到的一些問題、解決的方式以及待優(yōu)化的點。希望大家看了之后可以對組織翻譯項目有一定的理解，然后也可以提出自己的建議或者解決方案，也可以應(yīng)用在自己的項目中。

書名：《Functional-Light JavaScript》

作者： Kyle Simpson

文章數(shù)量： 21 篇

參與成員： iKcamp 中的 17 名童鞋

預(yù)計完成時間： 2 個月

在開始翻譯之前，有很多問題都需要考慮好，下面幾點也是我在項目開始之前都考慮的問題，列出來和大家探討一下：

如何確保翻譯質(zhì)量

如何讓每位成員都熟知翻譯流程和翻譯規(guī)范

如何確保翻譯進(jìn)度

成員之間的聯(lián)系方式

翻譯項目自然是翻譯質(zhì)量最重要，那么如何在成員還不算少的情況下確保翻譯質(zhì)量和翻譯進(jìn)度呢？
和小伙伴 Au 商量一番之后，我們決定采用分組制的策略。Master 對接組長，組長對接組內(nèi)成員，組長由有翻譯經(jīng)驗的小伙伴擔(dān)當(dāng)。分組的好處有以下幾點。

由于組長已經(jīng)參加過翻譯計劃，就能更好的解答組內(nèi)小伙伴的疑問

組長有更自由的職責(zé)分配和更多的權(quán)利來掌控組內(nèi)成員的翻譯進(jìn)度和翻譯質(zhì)量

由組長把控組內(nèi)的翻譯質(zhì)量，繼而再由 Master 管控小組的翻譯質(zhì)量

如果讓每位成員都熟知翻譯流程和翻譯規(guī)范，那么就要滿足下面的幾點要求：

要有一個文檔，上面清晰的寫著如何走完整個翻譯流程。

這個文檔要方便打開，并且支持各個系統(tǒng)，沒有格式的阻礙。

每位小伙伴都可以隨時訪問到。

基于以上幾點要求，我們最終采取的策略是在 GitHub 上新建一個倉庫，用 Markdown 的形式，以讀者的視角把整個翻譯流程展示出來。具體鏈接可以戳這里。

其實這個是很頭疼的一點，因為參與的小伙伴可能來自不同的公司和不同的部門，那么他們的時間也是不確定的?？赡苡袝r候忙一些，有時候閑一些，怎么才能在確保翻譯進(jìn)度的前提下讓小伙伴高質(zhì)量的完成翻譯呢？

我當(dāng)時想的辦法是給每一個流程規(guī)定一個 deadline，這個 deadline 是根據(jù)項目進(jìn)度來說能給的最寬裕的時間，然后在認(rèn)領(lǐng)翻譯的時候，小伙伴可以根據(jù)自己最近時間的寬裕程度來決定翻譯完成的時間，只要在這個 deadline 之前都可以。下面是我們認(rèn)領(lǐng)時候的一張截圖。

基本格式為：認(rèn)領(lǐng)類型（翻譯／校對認(rèn)領(lǐng)）- 截止時間。
這樣就可以不用強制每個人的進(jìn)度，讓小伙伴自己來掌控進(jìn)度。時間是自己選的，哈哈，那就要在規(guī)定的時間完成咯。

iKcamp 的小伙伴來自不同的公司和不通的部門，但是現(xiàn)在共同參加了一個翻譯項目。那么如何可以讓小伙伴都能明確的知道目前項目的進(jìn)度以及一起討論問題呢？這里我們就需要一個平臺，可以可視化目前項目的進(jìn)度，還需要一個可以交流的平臺。
當(dāng)時我想到了一下幾種工具：

Google Docs

Teambition

GitHub

微信

當(dāng)時覺得用 Teambition 還不錯，可視化，而且能清楚的看到項目目前的進(jìn)度，可是后來對比了一下 GitHub 的方案，發(fā)現(xiàn)其實這些 GitHub 也能做到，比如說用 GitHub 的 label，給每個流程的 label 命名也能很清晰的看到目前項目的進(jìn)度，而且 GitHub 相對于技術(shù)人員更專業(yè)一些。關(guān)于討論問題這方面，就要找到一個讓大家都能參與進(jìn)來，而且很方便的工具。所以最后就選用了 GitHub 來可視化項目的進(jìn)度，用微信群來討論。

解決了上面的問題，那其實準(zhǔn)備工作就做的差不多了，下面就按照流程一步一步的來就好啦。

翻譯大概可以概括為以下幾步：

準(zhǔn)備工作

以小組的形式自愿認(rèn)領(lǐng)翻譯文章

翻譯，校對

整合

Master 把每篇文章提一個 issue，并且每個 issue 附上相對應(yīng)的 label，用 label 可以很直觀的來確認(rèn)文章目前的進(jìn)度。我把 issue 的 label 分為 8 種：

不同的 label 對應(yīng)著目前的文章進(jìn)度。在 issue 的下方附上對應(yīng)原文的地址，這樣可以讓譯者更方便的找到對應(yīng)的原文去翻譯，還是上面的那張圖片：

分好小組之后，下面開始以組為單位認(rèn)領(lǐng)翻譯文章。每個小組內(nèi)的小伙伴會商量一下想翻譯哪些文章，然后再以組為單位到 label 為翻譯認(rèn)領(lǐng)的 issue 下面認(rèn)領(lǐng)文章。

組長到對應(yīng)的 issue 下面留言“認(rèn)領(lǐng)翻譯”之后， Master 會把 issue 的狀態(tài)由 “翻譯認(rèn)領(lǐng)” 切換為 “正在翻譯”。

分配好小組，認(rèn)領(lǐng)完文章之后，會留時間讓大家認(rèn)真的閱讀翻譯流程和翻譯規(guī)范。磨刀不誤砍柴工，這些都是翻譯工作開始之前的基礎(chǔ)，熟悉了這些之后，能夠避免很多錯誤和減少校對的工作量。

在翻譯的過程中，難免會遇到很多描述不太清楚的專有名詞，一個辦法是小組內(nèi)進(jìn)行討論，最后商量出來結(jié)果，小組內(nèi)統(tǒng)一翻譯?？墒沁@樣有一個不好的地方就是：小組內(nèi)雖然統(tǒng)一了，可是組與組之間并沒有統(tǒng)一。所以在這里，我們建了一個函數(shù)式編程專有名詞庫，把在翻譯過程中遇到的專有名詞及其翻譯都添加到這個庫中，這樣大家翻譯的時候遇到不太明白的就可以在此庫中查找，統(tǒng)一了大家的翻譯，不會出現(xiàn)一詞兩譯的情況。

因為本書的主題是函數(shù)式編程，所以這個名詞庫里大部分都是函數(shù)式編程相關(guān)的專有名詞。大家可以按照項目的不同來決定名詞庫的主題，也可以把翻譯過程中遇到的所有名詞都放在一起，這個就看你們的需求啦。

小伙伴完成翻譯之后，要在 GitHub 上發(fā)起 Pull request，然后在 PR 下留言寫上對應(yīng)的 issue 鏈接。這樣 PR 和 issue 就關(guān)聯(lián)起來了。之后的工作就主要在 PR 下留言完成。

下面為發(fā)起 Pull request 的兩種方式：

點擊按鈕之后，會出現(xiàn)下面的頁面，在圖中可以看到，先選擇目標(biāo)分支，然后選擇翻譯時自己建的分支，此時就會產(chǎn)生文件的對比，然后點擊下方的 Create pull request 綠色按鈕，就成功的發(fā)起了一個 Pull request。

到目前為止，翻譯流程已經(jīng)結(jié)束了，翻譯過程可以概括為下面的幾步：

當(dāng)譯者完成翻譯發(fā)起 Pull request 之后，在對應(yīng)的 Pull request 下方會有譯者的提交記錄。

點進(jìn)去，就會看到譯者的改動點，把鼠標(biāo)放到你認(rèn)為需要修改的那一行，會出來一個深藍(lán)色的加號，點擊加號，會出來一個文本框，在里面輸入你的建議，點擊綠色按鈕 Start a review 即可。

第一輪校對是組內(nèi)校對，組內(nèi)成員之間交換文章，檢查基本的語法和格式問題并修改。這樣在進(jìn)行第二輪校對的時候就減輕少了一些工作量。

一校完成之后，相當(dāng)于每篇文章都符合基本的格式規(guī)范，都能夠表達(dá)出來作者的基本思想了。下一步就要開始進(jìn)行“真正的”校對 —— 二校。二校主要校對文章句子的準(zhǔn)確度和順暢度，還有格式。

和認(rèn)領(lǐng)翻譯的文章一樣，不做任何限制，組內(nèi)成員商量想要認(rèn)領(lǐng)的文章，然后到 label 為校對認(rèn)領(lǐng)的 PR 下面留言認(rèn)領(lǐng)校對。

每次校對完成之后，翻譯此文章的小伙伴都要根據(jù)校對者的意見進(jìn)行一次修改。在修改過程中可以把一些想法和建議丟到小組內(nèi)商量，如果和校對者意見不一致的地方，也可以在校對者的留言下方進(jìn)行回復(fù)商量。最終確定修改的方案。

經(jīng)歷了一次翻譯、兩次校對和兩次修改之后，文章整體都差不多了，不過還差最后一步，就是作為一名讀者去真正的閱讀文章：切身的去體會讀者的感受；句子讀著是否順口；有沒有格式錯誤影響閱讀體驗。所以接下來就是最后一輪校對 —— 終校。每位小伙伴可以選擇自己感興趣的文章進(jìn)行校對。同時也鼓勵大家，有哪些看不懂的地方就在下方留言，我們一同討論解決辦法。

在此大家可能會有一個誤會，就是校對比翻譯更輕松一些。其實我并不是這樣認(rèn)為的。我覺得翻譯和校對同樣重要，他們的時間比重應(yīng)該是大差不差的。校對者要確保文章的表達(dá)力度、格式及能否被讀者所理解，付出的時間也和翻譯相當(dāng)或者更甚。所以，我們的校對不止進(jìn)行了一遍。盡量做到能清楚的表達(dá)作者的意思，而且容易讓讀者理解。
在此次的翻譯中，我也為大家留了充足的時間去校對，文本格式、表達(dá)意思都會去斟酌，相信付出的時間和成果是成正比的。

文章有很多互相引用的地方，比如第 6 章會引用第 2 章的段落標(biāo)題。由于在翻譯過程中譯者對于作者的思想和上下文的語境可能理解的不是很透徹，所以我們把這一步放在了最后。在最后一步我們統(tǒng)一修改引用的地方，確保上下文一致。

整個翻譯項目大致是上面介紹的這些，流程可以概括為下圖：

歷經(jīng) 2 個月，在 iKcamp 小伙伴的熱情和堅持下本書順利完成。我相信，iKcamp 的小伙伴在本次翻譯中也收獲頗豐，同時也克服了很大的困難。在工作壓力大的情況下，還能保質(zhì)保量的完成本書的工作，不僅是熱情，還有責(zé)任感在推動著我們完成本書的翻譯工作。在此特特別的感謝 ikcamp 的全體成員。也歡迎有興趣的小伙伴加入到 iKcamp 中來，我們一起玩技術(shù)～

不過對于翻譯項目的 Master 來說，道路還很遙遠(yuǎn)，因為是第一次擔(dān)任翻譯項目的 Master，很多地方還是欠缺經(jīng)驗，在這個過程中多虧了 Au 還有周媽媽以及小伙伴們的幫忙和配合才完成了此書的翻譯。這次翻譯流程還有以下需要優(yōu)化的點，之后大家在組織翻譯項目的時候可以想一些更有趣的方法。

在翻譯和校對階段的無縫銜接

保持項目進(jìn)度

翻譯的統(tǒng)一性

JavaScript 輕量級函數(shù)式編程

函數(shù)式編程專有名詞庫

翻譯規(guī)范 —— 包含翻譯流程文檔、排版規(guī)則和校對規(guī)范。

iKcamp原創(chuàng)新書《移動Web前端高效開發(fā)實戰(zhàn)》已在亞馬遜、京東、當(dāng)當(dāng)開售。

報名地址：http://www.huodongxing.com/ev...
與“天天練口語”小程序總榜排名第四、教育類排名第一的研發(fā)團(tuán)隊，面對面溝通交流。