在平時的工作中，我們都會經常查閱一些英文文件來解決平時遇到的問題和拓寬視野。看到好的文章或者書籍有沒有想要和小夥伴分享的衝動，那麼我們一起來翻譯吧～
翻譯主張 “信 達 雅” 。“信”指意義不悖原文，即是譯文要準確，不偏離，不遺漏，也不要隨意增減意思；“達”指不拘泥於原文形式，譯文通順明白；“雅”則指譯文時選用的詞語要得體，追求文章本身的古雅，簡明優雅。身為非專業翻譯人員，要達到以上三點不是很容易的，但是我們要儘可能往這個方向上努力。一是提高自己的表達水平和閱讀能力；二是能夠讓讀者更加的明白作者本來的思想。有句話說得好：當把別人講明白的時候，自己才算是真正的理解了。
2017 年 6 月 5 日，iKcamp 開始翻譯第二本書 —— 《JavaScript 輕量級函數語言程式設計》。如果你看過 iKcamp 最近在掘金、知乎或者公眾號上發過的關於這本書的文章，應該對本書有一個大致的瞭解，本書的作者是火爆全球的 《你不知道的 JavaScript》 一書原作者 。旨在探索函數語言程式設計的核心思想，但是並不會使用大量複雜的概念來詮釋，所以稱之為“輕量級函數語言程式設計”。“輕量”並不意味著本書是一本“入門級”的書籍，相反，本書包含各種複雜的細節，深入探討每個知識點，希望可以讓讀者對函數語言程式設計有一個更深的理解。
身為這次翻譯專案的 Master，在這個過程中學會了如何組織一次翻譯專案，如何定製翻譯計劃。秉承著 iKcamp 的分享精神，下面介紹一下我們這次翻譯的流程、遇到的一些問題、解決的方式以及待優化的點。希望大家看了之後可以對組織翻譯專案有一定的理解，然後也可以提出自己的建議或者解決方案，也可以應用在自己的專案中。
專案詳情：
- 書名：《Functional-Light JavaScript》
- 作者： Kyle Simpson
- 文章數量： 21 篇
- 參與成員： iKcamp 中的 17 名童鞋
- 預計完成時間： 2 個月
需要考慮的問題：
在開始翻譯之前，有很多問題都需要考慮好，下面幾點也是我在專案開始之前都考慮的問題，列出來和大家探討一下：
- 如何確保翻譯質量
- 如何讓每位成員都熟知翻譯流程和翻譯規範
- 如何確保翻譯進度
- 成員之間的聯絡方式
解決方案
1、如何確保翻譯質量
翻譯專案自然是翻譯質量最重要，那麼如何在成員還不算少的情況下確保翻譯質量和翻譯進度呢？
和小夥伴 Au 商量一番之後，我們決定採用分組制的策略。Master 對接組長，組長對接組內成員，組長由有翻譯經驗的小夥伴擔當。分組的好處有以下幾點。
- 由於組長已經參加過翻譯計劃，就能更好的解答組內小夥伴的疑問
- 組長有更自由的職責分配和更多的權利來掌控組內成員的翻譯進度和翻譯質量
- 由組長把控組內的翻譯質量，繼而再由 Master 管控小組的翻譯質量
2、如何讓每位成員都熟知翻譯流程和翻譯規範
如果讓每位成員都熟知翻譯流程和翻譯規範，那麼就要滿足下面的幾點要求：
- 要有一個文件，上面清晰的寫著如何走完整個翻譯流程。
- 這個文件要方便開啟，並且支援各個系統，沒有格式的阻礙。
- 每位小夥伴都可以隨時訪問到。
基於以上幾點要求，我們最終採取的策略是在 GitHub 上新建一個倉庫，用 Markdown 的形式，以讀者的視角把整個翻譯流程展示出來。具體連結可以戳這裡。
3、如何確保翻譯進度
其實這個是很頭疼的一點，因為參與的小夥伴可能來自不同的公司和不同的部門，那麼他們的時間也是不確定的。可能有時候忙一些，有時候閒一些，怎麼才能在確保翻譯進度的前提下讓小夥伴高質量的完成翻譯呢？
我當時想的辦法是給每一個流程規定一個 deadline，這個 deadline 是根據專案進度來說能給的最寬裕的時間，然後在認領翻譯的時候，小夥伴可以根據自己最近時間的寬裕程度來決定翻譯完成的時間，只要在這個 deadline 之前都可以。下面是我們認領時候的一張截圖。
基本格式為：認領型別（翻譯／校對認領）- 截止時間。
這樣就可以不用強制每個人的進度，讓小夥伴自己來掌控進度。時間是自己選的，哈哈，那就要在規定的時間完成咯。
4、成員之間的聯絡方式
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前端高效開發實戰》已在亞馬遜、京東、噹噹開售。
iKcamp最新活動
報名地址：http://www.huodongxing.com/ev…
與
“天天練口語”小程式總榜排名第四、教育類排名第一的研發團隊，面對面溝通交流。