在計(jì)算機(jī)領(lǐng)域，大部分優(yōu)秀的資料書(shū)籍都是英文寫(xiě)成的。當(dāng)它們被譯成中文后，翻譯的質(zhì)量是參差不齊。經(jīng)常能看到在豆瓣書(shū)評(píng)上，大家對(duì)于某本書(shū)翻譯質(zhì)量的吐槽。自己在初期也讀了一些中文版的，總的來(lái)說(shuō)，大部分是不影響知識(shí)的理解。但是有些翻譯，確實(shí)比較糟糕。遇的多了，發(fā)現(xiàn)這些錯(cuò)誤也有一些規(guī)律。

語(yǔ)法錯(cuò)誤

曾經(jīng)讀過(guò)一篇介紹正則表達(dá)式背后遞歸思想的文章[1]，看前半部分的時(shí)候并沒(méi)有覺(jué)得有什么不妥，但是看到了下面這句，整個(gè)人當(dāng)時(shí)就懵了。

Rob告訴我遞歸不是那么清晰的設(shè)計(jì)決策，緣于其如何逼近問(wèn)題的方式：考慮一個(gè)匹配模式和一段文本，寫(xiě)出匹配函數(shù)，該函數(shù)轉(zhuǎn)而又需要一個(gè)“匹配這 里”的函數(shù)，等等。

先不說(shuō)這個(gè)翻譯是否流暢，單就意思來(lái)說(shuō)，“遞歸不是那么清晰的設(shè)計(jì)決策”，這是什么情況？ 要知道這是一篇介紹遞歸思想的文章，通篇都是在說(shuō)遞歸好處，怎么會(huì)突然來(lái)這么一句。于是便去看了原文的表述[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.

問(wèn)題就出在對(duì)于“ not so much ...as" 這個(gè)短語(yǔ)的理解，這個(gè)短語(yǔ)的意思是“與其說(shuō)是...不如說(shuō)是...”,所以原文翻譯后應(yīng)該是“Rob告訴我，與其說(shuō)是遞歸是一種（主觀選擇的）清晰的設(shè)計(jì)決策，倒不如說(shuō)是他解決問(wèn)題的過(guò)程自然形成了這種遞歸的結(jié)果.......”

用法差異

英語(yǔ)基礎(chǔ)好一點(diǎn)的話(huà)，類(lèi)似的語(yǔ)法錯(cuò)誤還是比較容易避免的，最后翻譯出來(lái)的內(nèi)容，大致上也能還原文章的主旨。但是英語(yǔ)和漢語(yǔ)畢竟是不同的語(yǔ)言，在使用習(xí)慣上會(huì)有一些細(xì)微差異，這些差異在翻譯時(shí)若是沒(méi)處理好，也會(huì)成為閱讀的障礙。比如說(shuō)，在中文世界里，我們通常通過(guò)一些副詞如“非常” “很”來(lái)表示強(qiáng)調(diào)，，而英語(yǔ)中雖然也有對(duì)應(yīng)的副詞和用法，但是在表達(dá)強(qiáng)調(diào)的時(shí)候，一般都是通過(guò)句式的變化。把想要的部分提前。

在《flask web開(kāi)發(fā)》的中文版里，有這么一句話(huà)：

處理URL和函數(shù)之間關(guān)系的程序稱(chēng)為路由。

當(dāng)時(shí)讀到這句的時(shí)候，按照中文的意思，我便把路由認(rèn)為成一個(gè)程序。在隨后的閱讀中，便開(kāi)始了苦苦的尋覓，這段程序究竟在哪里？后來(lái)路由這個(gè)詞匯又出現(xiàn)了幾次，可是出現(xiàn)時(shí)的語(yǔ)境感覺(jué)好像跟之前理解“程序”不太一樣，隨后就去看了原版的內(nèi)容。

The associationbetween a URL and the function that handles it is called a route.

根本就沒(méi)有“程序”這個(gè)單詞！在文中我們看的association這個(gè)詞，它的中文意思是“關(guān)系”，而這個(gè)單詞被提前，顯然是要強(qiáng)調(diào)某種關(guān)系，如果翻譯的話(huà)，應(yīng)該是“ URL和處理URL的函數(shù)，這兩者間的關(guān)系稱(chēng)為路由”。說(shuō)實(shí)話(huà)，這個(gè)翻譯看起來(lái)也很別扭（如果有好的翻譯方式，歡迎留言），這本質(zhì)是因?yàn)橛⑽呐c中文表達(dá)方式差異造成的。翻譯的作者可能也是為了便于讀者理解，“好心”加上了“程序”這個(gè)詞，這反而造成了糟糕的影響，讓讀者注意力都放到了程序上，而不是“關(guān)系”。

內(nèi)容流失

翻譯過(guò)很多技術(shù)書(shū)籍的李松峰，在一次訪(fǎng)談中提到有兩樣內(nèi)容在翻譯過(guò)程中容易流失[3]，一是原文的形式，二是原文的風(fēng)格。其中對(duì)于“原文的形式”——原文的文字組織和語(yǔ)句結(jié)構(gòu)，他認(rèn)為在把意思翻譯出來(lái)后，這些形式輔助意思表達(dá)的使命就完成了。我認(rèn)為他對(duì)于什么是造成流失的判斷是正確的，但是原文形式不只是用來(lái)輔助意思的表達(dá)，形式本身也蘊(yùn)含著意思。在《JavaScript權(quán)威指南》的原文中有這么一句話(huà)，

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.

雖然只有一句話(huà)，但是蘊(yùn)含的內(nèi)容十分豐富。從字面意思去看，這句話(huà)闡述了JS有兩個(gè)作用，操作文檔和定義行為。轉(zhuǎn)折句式的運(yùn)用，表明了作者認(rèn)為定義行為的作用更重要，更能體現(xiàn)JS的價(jià)值。?再去細(xì)看句中的用詞，會(huì)發(fā)現(xiàn)這句話(huà)也理清了HTML CSS JS 三者的定位及關(guān)系。HTML負(fù)責(zé)內(nèi)容 （content） CSS負(fù)責(zé)表現(xiàn)（presentation) ?JS負(fù)責(zé)行為 （ behavior) ， HTML和CSS屬于文檔（document), JS可以操作（script)文檔，也可以通過(guò) （event handlers)給這些文檔定義行為。而這些詞語(yǔ)之所以能蘊(yùn)含這么多的內(nèi)容，除了用詞精確的原因外，原文的形式起了很大的作用。比如“script document”與 “define behavior”的對(duì)應(yīng)，使JS的作用突顯出來(lái)。 “…and..of…”說(shuō)明了HTML與CSS的并列關(guān)系及所屬范圍，“HTMLcontent”名詞修飾名詞的方式突出了其性質(zhì)content，在回過(guò)頭來(lái)看看中文版的翻譯，只會(huì)覺(jué)得是一句平淡的話(huà)。

可以通過(guò)JavaScript來(lái)操Web瀏覽器中的HTML內(nèi)容和文檔的CSS樣式，同樣，也可以通過(guò)事件處理程序（event handler) 來(lái)定義文檔的行為。

以上列舉的內(nèi)容只是對(duì)翻譯中出現(xiàn)的一些問(wèn)題的總結(jié)，并不是說(shuō)一定要去讀英文原文。畢竟我們閱讀中文速率還是會(huì)更高一點(diǎn)，而且也有很多的譯著也是不錯(cuò)的。在閱讀前，關(guān)注一下譯著的出版社、譯者背景、相關(guān)書(shū)評(píng)，可以讓我們避免大部分的坑。不過(guò)學(xué)好英語(yǔ)還是很重要的，因?yàn)橛袝r(shí)候翻譯的不準(zhǔn)確，可能是有意而為之。去找找《黑客與畫(huà)家》中這段的原文，你就會(huì)發(fā)現(xiàn)不同之處了。

無(wú)論在物質(zhì)上，還是在社會(huì)地位上，技術(shù)好像都縮小了富人與窮人之間的差距，而不是讓這種差距擴(kuò)大了。如果參觀雅虎、英特爾、思科的辦公室，會(huì)看到每個(gè)人都穿著差不多的衣服，有著同樣的辦公室（或者小隔間）、同樣的家具，彼此直呼對(duì)方的名字，不加任何頭銜或敬語(yǔ)。表面看大家沒(méi)什么差距，但如果看到每個(gè)人銀行戶(hù)頭上的余額差別如此之大，一定會(huì)感到震驚不已。

[1]解讀 Rob Pike 編寫(xiě)的正則表達(dá)式程序

[2]A Regular Expression Matcher Code by Rob Pike

[3]淺談技術(shù)翻譯