如何翻譯一本計算機書籍？
首先，恭喜你從吐槽方變成了被吐槽。
為什麼你不應該翻譯計算機書籍？
開始之前，我想一點潑冷水。畢竟，翻譯不是一個好差事——費力不討好，也不是一項適合每個人的 “工作”。
除卻不討好讀者這一點，還在於時間投入產出的問題。翻譯書是一個又長又累的活，一，我們可能一兩星期才能翻譯一章，二，獲得的報酬與我們的時薪比有較大的差距。所以，若是為了賺錢，那麼請不要考慮這種方式。一本兩百頁左右的書，兩個人投入兩三個月的時間，大抵各自只能賺上四五千塊錢。
可要是，你想提升自己的能力：表達、翻譯、時間管理——翻譯是一個二次寫作的過程 ，又或者是提升業內影響力，那倒是可以試試翻譯。
為什麼翻譯一本書？
嗯，既然，翻譯是一件 “吃力不討好的事”，可為什麼我們還是想翻譯本書呢？
成就感。對於自己而言，相當於是 GET 了一個新的成就。年老的時候，這個成就便會變成：我年輕的時候翻譯了一本書；我在你這個年紀的時候，翻譯了一本書……。
影響力及沉澱相關領域。如餘晟是《精通正則表示式(第3版)》（出版於 2012 年）的譯者，而後他寫了一本《正則指引》也是相關領域非常不錯的書籍；同樣的例子，還有喬樑在 2011 年翻譯的《持續交付:釋出可靠軟體的系統方法》，隨後在 2019 年也寫了一本《持續交付 2.0 業務引領的 DevOps 精要》。當你翻譯了一本書，在某種程度上，你也成為了這個領域的專家。再通過持續的練習和關注，也和沉澱出自己的內容。
更自信。如果你翻譯了一本書，那麼我想你已經有了寫一本書的自信了。這也是我寫了我的第一本書《自己動手寫物聯網》來的信心——這麼簡單的內容，我也會寫。然後我就掉坑裡了，大抵是出不來了。從某種程度上來說，對於我而言，在有了程式碼和大綱之後 ，寫一本書的時間和翻譯一本書的時間差不多。反而，因為不需要 Google Translate 和百度翻譯來幫助我，我可能寫得更快——也錯得更多。
既然，你已經下決心翻譯一本技術書籍，那麼就閱讀一下我的相關經驗。
翻譯前：試水
在我們進入正式的翻譯工作之前，我們有一堆的 “準備” 工作：
- 選擇合適的書籍
- 試譯
- 尋找合夥人
選題：選擇合適的書籍
翻譯之前，自然而然地是要去尋找相關的書籍：要麼從出版社找對應的書；要麼從書去找對應的出版社，再讓出版社去獲取版權 。兩種方式相比，最簡單的就是直接找出版社的編輯，通過編輯來尋找到書單，從中再去挑選合適的書籍。。
在挑選書籍的過程中，可以稍微注意這麼幾個點：
- 時效性。技術書籍存在一定的時效性，等你翻譯完 Node.js 9 之後，Node.js 10 已經出來了……
- 好評度。看看它們在 Amazon.com 上的評論，及相關的評價。
- 厚度。厚的英文書很考驗人性，如果你的性子不好，請換本書。
我的個人感受是：
首先，一定一定一定一定要找一本你感興趣的書。一旦不喜歡，那你可能要痛苦幾個月了，而且你可能沒有多少收穫。
其次，還要找擅長的領域或者身邊有擅長的人，萬一遇到幾句不懂的，還可以問問。
最後，臥槽，我愛極了滿篇程式碼，還有到處插圖的書了——翻譯的時候，並不是按真正的字數算報酬的，而是估算，諸如 1200字/頁。時間一久，我產生了一種幻想，有沒有一本書全是程式碼呢？
試譯
試譯是一個特別重要的步驟，它決定了你能不能翻譯這本書 。相應的有一些建議，翻譯完後：
- 自己讀一遍，看語句是否通順
- 找幾個文字好的人過一遍，比如學中文的人（如我就是找 @花仲馬）
- 多次校對幾遍，以確保沒有問題
在試譯的過程中，請確保、確保、確保翻譯的質量要儘可能地高 。要是如果沒有相關翻譯經驗，而直接去翻譯一本書，便是一次大的挑戰。我第一次直接翻譯書時，就有這樣的感受。當然了，要是你的英語好、中文也好的話，那麼問題就不大了。那麼，在你決定翻譯一本書之前，可以先嚐試去翻譯一些文章。
試譯完之後 ，你一定會懷疑人生的——我媽你媽，這幾十年的語文都學到哪裡去了 。It's very very good，你已經要走出舒適區。我翻譯第一本書的時候，由於我是英文版的審閱者，也因此沒有試譯。不過呢，在早期嘗試試譯圖靈的一本敏捷相關書籍時，試譯失敗。
試譯成功後，出版社便會和你討論出版相關的事宜，包含相關的出版合同 。
合夥人
考慮到投入產出的問題，我建議你還是找個人合夥，一起去幹這一票。在你有了信心之後，就可以繼續你的翻譯之旅。除此，一個可怕的事實是：廣大的男程式設計師們，普遍 表達能力沒有女程式設計師好。所以，要是能找到個女同胞合夥，那還是對提升文字水平，大有幫助的。
至於工作量上的分配，我覺得按章數直接分配是一個不錯的 idea，如：我和同學小兵，翻譯第一本書的時候，是以單雙章的形式分開的；我和同學小兵、朋友陳福，我翻譯的是前面一兩章，和後面的一兩章。
最後，難免你們會討論相關的酬勞分配、署名的問題。
- 酬勞。對於酬勞來說，按頁數來分配，是一個不錯的主意。畢竟，原書的頁數就那麼多，有的章節內容少，有的章節程式碼多，有的章節圖少。程式碼和圖的分配，在單雙章上也傾向於一個合理的水平。
- 署名。針對於署名來說，署在前面的那個人，往往是更需要對書質量負責的人。他/她可能是翻譯的發起者，也可能是翻譯得最多的人……。總之，活幹得最多的，放在前面也是蠻合理的。
至於公不公平，那都是相對的。
翻譯時
翻譯與交稿模式
從某種模式上來說，翻譯也可以分為兩種 “開發流程”：
- 瀑布模式：翻譯完整本書的內容，再交給編輯
- 敏捷模式：翻譯完每一個章節後，就交給編輯
兩種模式都各自有特點。如敏捷模式更容易讓書出版，只是對於編輯來說可能並沒有那麼友好。而瀑布模式會導致出版變長，但是各自可以集中精力。
制定翻譯計劃：時間管理
翻譯是一個相當漫長的過程，我們需要為翻譯工作騰出一定的時間。在我翻譯前兩本書的時候，我根據交稿時期，制定了一個非常簡單的計劃，一週翻譯一章 。隨後，再把這部分的工作分配到每天裡，一天幾頁，週末再校對一遍即可。無論是寫書還是翻譯，我都習慣在每天的早上和中午 來翻譯書籍，這樣我仍然可以擁有晚上的時間，可以去做自己喜歡做的事情。
一旦，我們為翻譯和寫作騰出了一定的時間後，便會發現一天中的可用時間特別多——如果你和我一樣不加班的話。
翻譯週期：興奮期 -> 厭倦期 -> 穩定輸出期
翻譯書，大抵和做專案是類似的：
興奮期。剛來到一個新的專案，那可是相當的興奮，恨不得一天就能翻譯完這本書（PS：記住：要久，而不是快），但是我們的進度相當的慢。
厭倦期。經歷了一段時間後，便覺得專案、翻譯是一件無聊的事，恨不得從坑裡出去。
穩定輸出期。隨著會發現，最後一部分翻譯出來的質量，遠比之前要高。堅持過了無聊期之後，我們便能保持穩定的輸出狀態，即能穩定地翻譯，也能穩定地寫程式碼。那麼，如果你是以瀑布型交付的稿件，再回到前面的章節裡，把前面的章節重新較對一票。
最後，你還是堅持下來，太棒了。
翻譯後：反饋
從交稿到書的最終出版，還需要一個相當長的時間，從幾個月到一年左右都有可能。也因此，這個過程可能會比翻譯的時間更長。
交稿完之後，便相當於是在稿件的反饋週期裡。那時，還需要與編輯保持緊密的聯絡。
注意事項
編輯器及版本管理
我習慣用的結合是：
- Git + GitHub 用來作版本管理
- 使用 Markdown 來編寫內容
- 編輯器，使用的是Phodit
一來，Markdown + Git 適合多個的文字管理，二來，Phodit 相當的適合於寫書，哈哈哈~~
多個翻譯軟體
相信我，Google 不懂中國，還有中文。笑~
我的意思是，與國內的翻譯軟體相比，Google 的優勢並不是太大。所以，若是遇到一些 Google Translate 有問題的句子，換成百度翻譯、網易有道、金山詞霸，你可能就會有一種豁然開朗的感覺。
音譯 xx 意譯
翻譯的過程中，我們還到怎樣翻譯才會更好的問題，也就是音譯好還是意譯好。
音譯是一種以原語言讀音為依據的翻譯形式，一般根據原語言內容的發音在目標語言中尋找發音相近的內容進行替代翻譯。
若是直接音譯，就會有一股濃濃的翻譯腔，轉而我們就需要採取一定的意譯：
意譯，是指是通過換句話，重述一個文字或段落。[wiki_yy]
並且，相信我，你可能會遇到那種作者也沒有寫好的書。這個時候，採用意譯會比音譯好多了。
英語那又長又複雜又不容易分割的語句
斷句，讀沒有標點符號的古書時，根據文義停頓或同時在書上加上圈點。
要是你之前沒有翻譯相關的經驗，那這個問題就值得注意一下。英語的語句一般是這樣的：
Tourism doesn't care about the destination, but care about the way people and things and those wonderful memories and scenery.
然後，金山詞霸翻譯成了這樣：“旅遊不在乎終點，而是在意途中的人和事還有那些美好的記憶和景色。”句子的後半句，還是太長了，中間可以中個逗號。改個：
“旅遊不在乎終點，而是在意途中的人和事，還有那些美好的記憶和景色。”
從某種程度上來說，這樣的短句更容易讀懂。而英語中，還充滿了各種又長又臭的倒裝。
知識庫（詞表）
一些技術上的關鍵詞，我們需要建立一個相關的知識庫——特別是多人協作翻譯的時候，可以用於統一相關的關鍵詞。如我們在寫相關文章的時候，使用英語反而更容易理解，相似的，在翻譯的時候，也記得標註一下，第一次使用時，如微服務應該帶上相應的 “微服務（microservices）”而不是微服務，這種閱讀體驗，對於讀者來說，相當的痛苦。
提升文字水平
當我在寫書的時候，我會閱讀大量地文學書籍。以此，來新增一些相關的用詞。
應對詞窮
要是缺少大量文學相關的內容，大抵在翻譯書的時候，會出現大量地相似語句。這些語句在我們翻譯的時候，總會覺得很煩。如我們習慣的連線詞：首先，其次，最後，對應的英文便是：First,... Then,... Finally。可是呢，英語可以這樣寫一個句子：First, Then, Then(n), Then, Finally。
對應的有不同的形式：
- 首先，其次，然後，最後
- 首先...接著...再接著...最後...
- 先......然後......再......又......接著......最後……
同樣的一個詞，可以有多種不同的表現形式諸如，除了、除卻、除掉。而諸如本身，又可以換成好比、比方、例如、譬喻~。這也算是我們在過程中，能找到一樂趣之一。
還有 “如下程式碼”、“程式碼如下所示”，“看看這裡的程式碼”，“程式碼很簡單”——哈哈哈~
應對錶達能力不好的作者
如果，我是說如果，你遇到作者的表達能力也不好，那麼你陷入困境了。請及時與編輯聯絡，你可能得加入一些自己風格的翻譯了。
還有技術
末了，請不要忘記，你接觸的是該領域的最新知識——至少在我寫這篇文章的這會兒，國內的最新技術書籍的出版時間，還是落後於國外的時間。
所以，請不要單純以翻譯為目的，練習一下其中的技術吧。
結論
你呢，還有什麼溫馨提示。
外傳：原版 vs 譯版
我仍然是一個喜歡看中文書籍的人，英文書籍於我而言，一來是貴，二來是閱讀速度慢。
貴的這一點，也不需要我多說，而身為一個創作者呢，看盜版書籍也是對自己的不尊重——自己尚且如何，更何況別人呢。
對於閱讀速度的問題，不同的人有不同的看法，有的人喜歡精讀、細讀。而我則喜歡先粗讀，而後在需要的時再回來讀這本書。我這腦子記不住太多的東西，一不用就忘了。於是，精讀於我便是有些浪費時間的味道——除非，我非常迫切需要一本書。可很少存在這種情況，我就是一個書蟲，還沒用到，就已經讀了——好書，都值得一讀，不是嗎？
而英語書經常翻譯之後，價格上降了 N 倍，又能快速閱讀。對於幾大計算機出版社的書來說，哪怕是一本書翻譯得再差，它也遠遠比 Google Translate 或者百度翻譯更好。