乾貨｜人人都是翻譯項目的Master

做者：萌萌 本文爲原創文章，轉載請註明做者及出處

全本 | iKcamp翻譯 | 《JavaScript 輕量級函數式編程》

在平時的工做中，咱們都會常常查閱一些英文文檔來解決平時遇到的問題和拓寬視野。看到好的文章或者書籍有沒有想要和小夥伴分享的衝動，那麼咱們一塊兒來翻譯吧～

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

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 來可視化項目的進度，用微信羣來討論。

解決了上面的問題，那其實準備工做就作的差很少了，下面就按照流程一步一步的來就好啦。

開始翻譯

翻譯大概能夠歸納爲如下幾步：

• 準備工做
• 以小組的形式自願認領翻譯文章
• 翻譯，校對
• 整合

1、準備

Master 把每篇文章提一個 issue，而且每一個 issue 附上相對應的 label，用 label 能夠很直觀的來確認文章目前的進度。我把 issue 的 label 分爲 8 種：

不一樣的 label 對應着目前的文章進度。在 issue 的下方附上對應原文的地址，這樣可讓譯者更方便的找到對應的原文去翻譯，仍是上面的那張圖片：

2、主要翻譯流程

認領文章

分好小組以後，下面開始以組爲單位認領翻譯文章。每一個小組內的小夥伴會商量一下想翻譯哪些文章，而後再以組爲單位到 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 章的段落標題。因爲在翻譯過程當中譯者對於做者的思想和上下文的語境可能理解的不是很透徹，因此咱們把這一步放在了最後。在最後一步咱們統一修改引用的地方，確保上下文一致。

3、結尾

整個翻譯項目大體是上面介紹的這些，流程能夠歸納爲下圖：

歷經 2 個月，在 iKcamp 小夥伴的熱情和堅持下本書順利完成。我相信，iKcamp 的小夥伴在本次翻譯中也收穫頗豐，同時也克服了很大的困難。在工做壓力大的狀況下，還能保質保量的完成本書的工做，不只是熱情，還有責任感在推進着咱們完成本書的翻譯工做。在此特特別的感謝 ikcamp 的全體成員。也歡迎有興趣的小夥伴加入到 iKcamp 中來，咱們一塊兒玩技術～

不過對於翻譯項目的 Master 來講，道路還很遙遠，由於是第一次擔任翻譯項目的 Master，不少地方仍是欠缺經驗，在這個過程當中多虧了 Au 還有周媽媽以及小夥伴們的幫忙和配合才完成了此書的翻譯。此次翻譯流程還有如下須要優化的點，以後你們在組織翻譯項目的時候能夠想一些更有趣的方法。

• 在翻譯和校對階段的無縫銜接
• 保持項目進度
• 翻譯的統一性

本次翻譯項目產出的成果

• JavaScript 輕量級函數式編程
• 函數式編程專有名詞庫
• 翻譯規範 —— 包含翻譯流程文檔、排版規則和校對規範。
• 全本 | iKcamp翻譯 | 《JavaScript 輕量級函數式編程》

iKcamp最新活動

報名地址：www.huodongxing.com/event/54099…

與「每天練口語」小程序總榜排名第4、教育類排名第一的研發團隊，面對面溝通交流。

全本 | iKcamp翻譯 | 《JavaScript 輕量級函數式編程》

---

2019年，iKcamp原創新書《Koa與Node.js開發實戰》已在京東、天貓、亞馬遜、噹噹開售啦！