在計算機領域啦逆，大部分優(yōu)秀的資料書籍都是英文寫成的夏志。當它們被譯成中文后，翻譯的質量是參差不齊沟蔑。經常能看到在豆瓣書評上瘦材，大家對于某本書翻譯質量的吐槽厅须。自己在初期也讀了一些中文版的，總的來說食棕，大部分是不影響知識的理解朗和。但是有些翻譯，確實比較糟糕簿晓。遇的多了眶拉，發(fā)現這些錯誤也有一些規(guī)律。
語法錯誤
曾經讀過一篇介紹正則表達式背后遞歸思想的文章[1]憔儿，看前半部分的時候并沒有覺得有什么不妥镀层，但是看到了下面這句，整個人當時就懵了。
Rob告訴我遞歸不是那么清晰的設計決策唱逢，緣于其如何逼近問題的方式：考慮一個匹配模式和一段文本吴侦，寫出匹配函數坞古，該函數轉而又需要一個“匹配這 里”的函數备韧，等等。
先不說這個翻譯是否流暢痪枫，單就意思來說织堂，“遞歸不是那么清晰的設計決策”，這是什么情況奶陈？ 要知道這是一篇介紹遞歸思想的文章易阳，通篇都是在說遞歸好處，怎么會突然來這么一句吃粒。于是便去看了原文的表述[2]：
Rob has told me that the?recursion was not so much an explicit design decision as aconsequence of how he approached the problem: given a pattern and a text, write a function that looks for a match; that in turn needs a "matchhere" function; and so on.
問題就出在對于“ not so much ...as" 這個短語的理解潦俺，這個短語的意思是“與其說是...不如說是...”,所以原文翻譯后應該是“Rob告訴我，與其說是遞歸是一種（主觀選擇的）清晰的設計決策徐勃，倒不如說是他解決問題的過程自然形成了這種遞歸的結果.......”
用法差異
英語基礎好一點的話事示，類似的語法錯誤還是比較容易避免的，最后翻譯出來的內容僻肖，大致上也能還原文章的主旨肖爵。但是英語和漢語畢竟是不同的語言，在使用習慣上會有一些細微差異臀脏，這些差異在翻譯時若是沒處理好劝堪，也會成為閱讀的障礙。比如說揉稚，在中文世界里幅聘，我們通常通過一些副詞如“非常” “很”來表示強調窃植，帝蒿，而英語中雖然也有對應的副詞和用法，但是在表達強調的時候巷怜，一般都是通過句式的變化葛超。把想要的部分提前。
在《flask web開發(fā)》的中文版里延塑，有這么一句話：
處理URL和函數之間關系的程序稱為路由绣张。
當時讀到這句的時候，按照中文的意思关带，我便把路由認為成一個程序侥涵。在隨后的閱讀中沼撕，便開始了苦苦的尋覓谢揪，這段程序究竟在哪里徙缴？后來路由這個詞匯又出現了幾次卸耘，可是出現時的語境感覺好像跟之前理解“程序”不太一樣斩祭，隨后就去看了原版的內容。
The associationbetween a URL and the function that handles it is called a route.
根本就沒有“程序”這個單詞库北！在文中我們看的association這個詞铣揉，它的中文意思是“關系”窜骄，而這個單詞被提前娶牌，顯然是要強調某種關系奔浅，如果翻譯的話，應該是“ URL和處理URL的函數诗良，這兩者間的關系稱為路由”汹桦。說實話，這個翻譯看起來也很別扭（如果有好的翻譯方式鉴裹，歡迎留言）舞骆，這本質是因為英文與中文表達方式差異造成的。翻譯的作者可能也是為了便于讀者理解壹罚，“好心”加上了“程序”這個詞葛作，這反而造成了糟糕的影響寿羞，讓讀者注意力都放到了程序上猖凛，而不是“關系”。
內容流失
翻譯過很多技術書籍的李松峰绪穆，在一次訪談中提到有兩樣內容在翻譯過程中容易流失[3]辨泳，一是原文的形式，二是原文的風格玖院。其中對于“原文的形式”——原文的文字組織和語句結構菠红，他認為在把意思翻譯出來后，這些形式輔助意思表達的使命就完成了难菌。我認為他對于什么是造成流失的判斷是正確的试溯，但是原文形式不只是用來輔助意思的表達，形式本身也蘊含著意思郊酒。在《JavaScript權威指南》的原文中有這么一句話遇绞，
JavaScript allows us toscript the HTML content and CSS presentation of documents?in web browsers,but it also allows us to define behavior for those documents with eventhandlers.
雖然只有一句話，但是蘊含的內容十分豐富燎窘。從字面意思去看摹闽，這句話闡述了JS有兩個作用，操作文檔和定義行為褐健。轉折句式的運用付鹿，表明了作者認為定義行為的作用更重要，更能體現JS的價值。?再去細看句中的用詞舵匾，會發(fā)現這句話也理清了HTML CSS JS 三者的定位及關系俊抵。HTML負責內容 （content） CSS負責表現（presentation) ?JS負責行為 （ behavior) ， HTML和CSS屬于文檔（document), JS可以操作（script)文檔纽匙，也可以通過 （event handlers)給這些文檔定義行為务蝠。而這些詞語之所以能蘊含這么多的內容，除了用詞精確的原因外烛缔，原文的形式起了很大的作用馏段。比如“script document”與 “define behavior”的對應，使JS的作用突顯出來践瓷。 “…and..of…”說明了HTML與CSS的并列關系及所屬范圍院喜，“HTMLcontent”名詞修飾名詞的方式突出了其性質content，在回過頭來看看中文版的翻譯晕翠，只會覺得是一句平淡的話喷舀。
可以通過JavaScript來操Web瀏覽器中的HTML內容和文檔的CSS樣式，同樣淋肾，也可以通過事件處理程序（event handler) 來定義文檔的行為硫麻。
以上列舉的內容只是對翻譯中出現的一些問題的總結，并不是說一定要去讀英文原文樊卓。畢竟我們閱讀中文速率還是會更高一點拿愧，而且也有很多的譯著也是不錯的。在閱讀前碌尔，關注一下譯著的出版社浇辜、譯者背景、相關書評唾戚，可以讓我們避免大部分的坑柳洋。不過學好英語還是很重要的，因為有時候翻譯的不準確叹坦，可能是有意而為之熊镣。去找找《黑客與畫家》中這段的原文，你就會發(fā)現不同之處了募书。
無論在物質上绪囱，還是在社會地位上，技術好像都縮小了富人與窮人之間的差距锐膜，而不是讓這種差距擴大了毕箍。如果參觀雅虎、英特爾道盏、思科的辦公室而柑，會看到每個人都穿著差不多的衣服文捶，有著同樣的辦公室（或者小隔間）、同樣的家具媒咳，彼此直呼對方的名字粹排，不加任何頭銜或敬語。表面看大家沒什么差距涩澡，但如果看到每個人銀行戶頭上的余額差別如此之大顽耳，一定會感到震驚不已。
[2]A Regular Expression Matcher Code by Rob Pike
[3]淺談技術翻譯
