傳統上，翻譯與文學的關係很近。說起翻譯，許多人首先想到的是「文筆要好」。近年來隨著信息交流的發展，實用型文本尤其是科技文獻的翻譯越來越顯得重要，許多科技領域的從業人員也有興趣或有動力翻譯科技文獻，並取得了大量成果，突出表現之一就是IT類書籍的翻譯質量有了很大的提升，這背後的功臣很多都是IT界的「翻譯票友」。

科技翻譯是大大繁榮了，科技翻譯自身的學問卻沒有相應的進展，各種翻譯教程和經驗總結仍然側重於一般的翻譯或文學翻譯。然而深入了解翻譯的人都知道，不同文體、不同領域的翻譯，是各有特點的。比如新聞翻譯追求簡潔、準確、吸引眼球，文學翻譯更強調完整、流暢、意境貼切。這種差異貫徹到翻譯實踐當中，產生了很多講究，所以新聞才能譯得像新聞，小說才能譯得像小說。同樣的道理，科技翻譯也不能完全照搬普通翻譯的做法，要想做好它，還必須了解其自身的特點。根據我的總結，科技翻譯大致有以下幾個特點。

第一，科技文獻通常是用來講道理的，所以譯者必須準確理解文字表達的道理。

這裡說的「講道理」不是狹義的「說理」，而包括講解原理、研究論證、實驗分析等等，換句話說，科技文獻的內容是可以用理性分析的客觀現實，所以讀者的理解也應該可以客觀衡量。文藝作品沒有這個特點，經常是「言有盡而意無窮」，可以「一千個讀者就有一千個漢姆雷特」，科技文章則要求「有九分把握不說十分話」，必須「一千個讀者只能有一個漢姆雷特」。所以，科技文獻的譯者不但要懂得原文，還必須準確理解原文。以前有幾家出版公司的IT類翻譯圖書之所以被大家痛罵，很大程度上並不是因為譯者的文字水平不夠好，而是因為譯者根本不懂也不願意弄懂作者在說什麼，這樣的譯文會被讀者痛罵。

科學技術本身有客觀標準可循，所以科技文獻的意思理解起來反而比文學作品更容易，因為譯者不必拘泥於原文。假設原文先講了甲乙兩個演算法，然後下了比較的結論，譯者如果不能確認作者的褒貶，完全可以根據之前的講解進行邏輯推理，甚至可以親自動手編程實踐。要知道，邏輯和程序是絕不會因人而異的。推而廣之，譯者完全可以獨立驗證自己的理解是否準確，而理解準確恰恰是譯文合格的前提條件。所以我建議，科技文獻的譯者在翻譯完成之後，應當拋開原文閱讀譯文，想想是否能明白作者要講解的知識、原理、規律，如果做不到，那麼譯文多半不合格。

第二，科技翻譯的譯者完全可以適當改動原文。

上文已經說過，科技文獻的一大特點是其論述內容有客觀標準可循，所以譯者可以藉助「文字之外」的信息來驗證自己的理解。這可以算科技翻譯的獨門優勢，而且這點優勢相當有價值。因為科技文獻的作者往往不是專門的文字工作者，不能奢求他們有很高的寫作水平，某些片段可能講解晦澀，難以理解，或者原作者並沒有為譯文讀者考慮（實際上這種情況相當普遍），使用了一些專屬於某些文化的典故、俚語。如果是文學翻譯，遇到這樣的問題會非常麻煩，摸不準原作者到底是什麼意思。科技翻譯則沒有這種問題，譯者一旦確認自己理解了原文的內容和邏輯，就可以大膽改動譯文讀者難以理解的片段，避免譯文讀者在同樣的問題上浪費精力。

我曾在技術文章中見到作者評價某種做法的難度「和拯救麻風病人一樣」。根據上下文猜測，這裡大概是說難度不小，不過非要理解為難度很小似乎也說得通，因為現在麻風病似乎很少見了，也很少聽說治療很麻煩，所以我不敢確認。譯者尚且如此，見不到原文的讀者估計就更難以確認了。於是我專門去查了資料，原來這裡作者指的是在斯里蘭卡的非政府組織、慈善機構、公共關係公司、衛生部門為拯救麻風病人的進行了長期的艱苦努力，那麼意思當然是難度大了。所以最終翻譯為「和拯救麻風病人一樣非常艱難」，這樣就確保讀者不會誤解。

再舉一個例子，有篇譯文講的是如何用正則表達式匹配獨立的單詞，原文是「so, if inline appeared in the sentence, the regular expression will match not in but inline」，翻譯為「這樣處理，如果句子中出現了inline，表達式匹配的是inline，而不是in」卻不夠恰當。英文本身就是以詞為單位的，所以閱讀原文時當然知道其中的inline、in都是指的「單詞」inline、in，而不是「字元串」inline、in。但中文的辭彙之間並沒有形式分隔，所以讀者有可能把「這句話包含inline」理解為「這句話包含字元串inline」。如果譯者大膽將「單詞」兩個字增補進去，譯為「這樣處理，如果句子中出現了單詞inline，表達式會匹配單詞inline，而不會匹配其中的in」，這樣讀者就不會有誤解了。

以上兩處改動都出自譯者之手，目的都是為了保證讀者的正確理解，保證「一千個讀者只有一個漢姆雷特」，且譯者這麼做有足夠的底氣這麼做。當然，如果譯者覺得應當盡量避免改動原文，也可以保留原文，輔以注釋說明，這個道理相當簡單——發布有缺陷需要用戶自己打補丁的軟體，與發布官方已經打好補丁的軟體，顯然大家都喜歡後者。

第三，在「順」與「信」發生衝突時，科技翻譯選擇信而不順。

「順」和「信」的取捨，是老一輩翻譯家非常關注的問題。所謂順，指的是文字通順、流暢，所謂信，指的是準確、忠於原文的形式。因為語言習慣不同，所處的文化不同等原因，翻譯時難以「形神兼備」的情況是時常出現的。要譯文流暢，可能就要對原文做較大改動；要盡量不改動原文，文章又無法流暢。對這個問題，不同的文體有不同的處理。

在「信」與「順」之間，文學翻譯更偏向「順」，如the night breeze came with pleasant guitar，原意是「晚風和好聽的吉他是一起來的」，但這樣表達很彆扭，故改為「晚風送來美妙的吉他」，這是取「順」而棄「信」。但如果科技文章中出現the data come with noise，翻譯為「數據送來了噪音」就是嚴重的錯誤，只能譯為「數據是和噪音一起來的」，這是取「信」而棄「順」。儘管看起來比較直白簡陋，但很多技術文獻本身就是直白簡陋的，翻譯時一味追求譯文的「順」，不但喪失了科技文章看重的準確信，即便從翻譯本身來說，也有塗脂抹粉、文過飾非的嫌疑。

要補充的是，「信」和「順」捨棄一定要在「信和順無法調和」的前提下進行，「信而不順」絕不是不動腦筋硬譯的借口。即便是堅持信而不順的魯迅先生也說過：信而不順，絕不是捨棄「跪下」而保留「跪在膝上」，捨棄「銀河」而保留「牛奶路」。實際上，大量科技文章都是非常淺顯直白的，譯文對譯文讀者的要求不應當高過原文對原文讀者的要求，尤其是不應當抬高對讀者文字理解能力的要求。

第四，科技翻譯時，譯者應當對加倍小心應對專有名詞（術語）。

專有名詞是科技文章中大量用到的辭彙，專用來指涉一些約定俗稱的概念。因為科技行業的發展水平不同，現代科技專有名詞的大部分都來自西方國家，所以必須翻譯出來。物理、生物等領域的專有名詞許多都是組合而成，翻譯相對容易，如magnetic field翻譯為「磁場」，haemoglobin翻譯為「血紅蛋白」（希臘文的haima「血」和拉丁文的globin「球」）。

不幸的是，IT行業的情況特殊，這個行業許多人心態很年輕，思維很開放，很多術語是從生活中借鑒而來，翻譯起來反而麻煩。比如buffer和cache兩個詞，本來buffer指的是「逃生氣墊」，cache指的是「隱匿的存放處」，引申出計算機里的「緩衝」和「緩存」是非常形象自然的。中文的「緩存」和「緩衝」屬於針對具體領域專門創造的術語，雖然已經約定俗成，畢竟割斷了原來的形象感，所以很多初學者見到「緩存」和「緩衝」以為是全新發明的東西，甚至會混淆這兩個名字相近的概念，也需要花很多時間去記憶「緩存是透明的」，卻不知道cache本來就有「隱匿存放」的意思。

可見，術語的翻譯一定要加倍小心。這方面好壞例子都很明顯。好的例子如表示空氣污染級別的beyond index翻譯為「爆表」，即便不認識beyond index的人，一看「爆表」也知道意思。壞的典型比如case-sensitive翻譯為「大小寫敏感」——據我觀察，幾乎沒有初學者能想明白「大小寫敏感」的什麼意思，了解之後不少人還以為IT行業的術語就是這個怪調調。其實，真正的原因是這個譯名造錯了。查閱詞典可知，sensitive除去表示「感覺上的敏銳」，還有一個意思是「有能力區別和分辨」，所以case-sensitive的真正意思應當是「能區分大小寫」（「敏感」和「有能力識別」有一定聯繫，但區別很大：「不識好歹」不等於「好歹不敏感」，「是非分明」也不能說成「是非敏感」）。譯者不夠謹慎造錯一個術語，會影響到無數後來者的學習。所以這樣說來，我覺得cookie不翻譯反而是好事，有人非要翻譯為「小甜餅」反而畫蛇添足，因為中文世界裡大多數人都不知道「小甜餅」是什麼，有什麼作用，也不知道HTTP Cookie其實來自magic cookie，所以直接說cookie反而更好。

即便一些專有名詞已經有了譯名，譯者也應當記得，這些譯名一般只適用於狹窄的領域內，不是放之四海而皆準的譯法。比如plug and play，大家都知道這是「即插即用」，如果在講解程序的文章里出現，比如Having these code snippets, are you ready to plug and play? ，翻譯為「即插即用」就不合適了，因為這裡作者是調侃性地借鑒硬體的「即插即用」，談的並不是硬體標準，而是「把代碼直接拿過來用」的做法。所以不妨翻譯為「即抄即用」，這樣保留了願意，讀音也接近「即插即用」，便於讀者理解，甚至原文的一點點幽默感也保留下來。如果譯者想不到「即抄即用」，至少也應當在「即插即用」外面打個引號。

類似的例子還有正則表達式中的character class，許多譯者一看到class，就立刻想到「類」，所以character class就翻譯為「字元類」。但是「類」這個詞在IT知識體系里有專門的意思，它表示某種類型的對象定義變數和方法的原型，是對現實中一類有共同特徵的事物的抽象。character class翻譯為「字元類」，就會讓讀者聯想到「對象」等等一系列概念，在有的語言中甚至真的有類名叫Character，這就更容易混淆了。其實character class里的class只表示「組合/集合」，類似表示「班級」的class，所以應當翻譯為「字元組」更合適。

節選自《翻譯漫談》

推薦閱讀：