2013年到如今，已經翻譯了3本書了，其它雜七雜八的文章也很多。其中有一些經驗和教訓，勢必要總結一下。程序員
將譯稿歸入版本管理
沒有版本管理的代碼修改起來是戰戰兢兢地，而譯稿也相似。我習慣在GitHub上建立一個私有的倉庫（我是GitHub的會員），把與該書相關的內容都放置上去，每翻譯一點就遷入一次，保證任何修改均可以追蹤。編程
建立一個詞條文檔
在翻譯書的過程當中，不免會遇到不少專業詞彙，有些專業詞彙有統一的翻譯，而有些則沒有，須要本身權衡後給出一個翻譯結果。最好把這些詞彙都放置到一個獨立文檔中，這尤爲對多人合做翻譯的情形至關有用。能夠保證整本書對專業詞彙翻譯的一致性，也便於之後修正某個詞條的翻譯。多線程
權衡信、達、雅
信、達、雅是青末啓蒙思想家嚴復提出的概念。」「信」指意義不背原文，便是譯文要準確，不歪曲，不遺漏，也不要隨意增減意思；「達」指不拘泥於原文形式，譯文通順明白；「雅」則指譯文時選用的詞語要得體，追求文章自己的古雅，簡明優雅。我所翻譯的都是一些技術性書籍，信確定是佔首位。而英文被動句較多，長短句結合，要經過「達」的方式來變換句式，符合中國人閱讀習慣。「雅」則注重用詞的準確性，是個比較難達到的標準。線程
第一遍粗譯，第二遍細譯，第三遍校審
通常在翻譯時我是按段落爲單位的。先看一個段落，看懂了之後再把整個段落翻譯出來。其中遇到不是很懂的句子先空下來，等到整章或整節翻譯完成之後再回頭看。這是由於我發現翻譯時也有2/8原則。全文有80%的內容很好翻譯，而20%的內容則比較難翻譯。若是在翻譯的過程當中碰到20%難翻譯的地方就努力攻克的話，會把翻譯的時間的打散，進度會很慢。而第一遍粗譯，跳過難以翻譯的地方，第二遍時再補譯的好處是，因爲你已經翻譯了整章，創建了良好的上下文關係，對付1，2句話那還不是小意思。此外還有心理因素，整章只有幾句話沒翻譯，內心比較輕鬆，也更容易激發靈感。第二遍所有翻譯完畢後，第三遍就是仔細校審了，這時候主要注意力就是句式的結構調整、詞彙調整了。翻譯
天天堅持翻譯，日積月累
通常翻譯一本書編輯會給出時間限制的。而我翻譯只能利用業餘時間，能夠說時間很是有限。若是三天打魚、兩天曬網，很容易堆積到最後，因爲趕工而影響質量。因此養成良好的翻譯習慣是很是必要的。能夠天天至少翻譯兩頁，週末多翻譯一些，這樣聚沙成塔，水滴石穿，遇到節假日再突擊一下，這樣利用時間纔是最合理的。本身也不會感受有壓力。設計
翻譯技術類書籍，自身實力要過硬
我翻譯的三本書，一本是關於JavaScript的，一本是關於HTML5和CSS3的，另外一本是關於C# 多線程編程的。雖然這方面我以前都有所涉獵，可是爲了保證翻譯的質量和技術術語詞彙的準確性，我會通讀不少與之相關的書籍。以《Effective JavaScript》這本書爲例，在翻譯這本書以前我已經讀過好幾本與之有關的書了，可是爲了保證翻譯的質量，這畢竟是我翻譯的第一本書，我不只閱讀了Effective系列的其餘書籍（好比《Effective Java》），也閱讀了大量與JavaScript有關的書（好比《JavaScript高級程序設計》,《JavaScript語言精粹》,《JavaScript權威指南》等）。經過大量的閱讀與練習，我對原文的理解更加輕鬆，對詞彙的翻譯也更加準確。ip
翻譯技術類書籍其實不難，有志於此的程序員們能夠先將英語練好，多讀幾本英文技術類書籍，而後找一些本身喜歡的文章練練手，說不定有一天哪本譯做上就有你的大名。文檔