我的科技翻譯經驗總結

按:以前我寫過一本電子書《翻譯漫談》,主要是總結自己的翻譯經驗。沒想到這麼多年過去了,早已經免費開放閱讀,仍然有朋友找我討要、討論這本書。我去豆瓣閱讀看了下,大家的評價還挺讓人欣慰,而且不斷有新的反饋。所以我修訂擴充了原書的一些篇章,發在這裡。


我的科技翻譯經驗總結

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

我的科技翻譯經驗總結

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

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

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

科學技術本身有客觀標準可循,所以科技文獻的意思理解起來反而比文學作品更容易,因為譯者不必拘泥於原文。假設原文先講了甲乙兩個算法,然後下了比較的結論,但只是說“一個算法比另一個好幾倍”。單純從文字來看,很難知道到底是哪個好,哪個不好,但這個問題難不住科技翻譯的譯者,因為他可以親自動手編程實踐。要知道,邏輯和程序是絕不會因人而異的。推而廣之,譯者完全可以獨立驗證自己的理解是否準確,而理解準確恰恰是譯文合格的前提條件。

類似的例子還有:

喬布斯是很有能力的工程師,和沃茲尼亞克不可相提並論

“不可相提並論”當然是說兩者大不相同,但這裡到底要表達的是什麼意思呢,誰的水平更高?在我看來,如果一定要讀者熟悉蘋果早期的創業故事,才能讀懂這個句子,那麼譯者是不合格的。譯者完全可以也應當根據自己對背景知識的瞭解,澄清這一點,改譯為

喬布斯也是很有能力的工程師,但遠比沃茲尼亞克遜色
我的科技翻譯經驗總結

這個例子我只是看了譯文覺得有點彆扭,翻了原文才知道“不可相提並論”的原文是not in the same league,本身就有“遠遠不如”的意思。嚴格說起來,譯文在這裡是有瑕疵的,起碼原文的轉折意思沒保留。

我建議,科技文獻的譯者在翻譯完成之後,應當拋開原文來讀讀,想想是否能明白作者要講解的知識、原理、規律。如果做不到,那麼譯文多半不合格。

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

上文已經說過,科技文獻的一大特點是其論述內容有客觀標準可循,所以譯者可以藉助“文字之外”的信息來驗證自己的理解。這可以算科技翻譯的獨門優勢,而且這點優勢相當有價值。因為科技文獻的作者往往不是專門的文字工作者,不能奢求他們有很高的寫作水平,某些片段可能講解晦澀,難以理解,或者原作者並沒有為譯文讀者考慮(實際上這種情況相當普遍),使用了一些專屬於某些文化的典故、俚語。

如果是文學翻譯,遇到這樣的問題會非常麻煩,摸不準原作者到底是什麼意思。科技翻譯則沒有這種問題,譯者一旦確認自己理解了原文的內容和邏輯,就可以大膽改動譯文讀者難以理解的片段,避免譯文讀者在同樣的問題上浪費精力。

我曾在技術文章中見到作者評價某種做法的難度“和拯救麻風病人一樣”。根據上下文猜測,這裡大概是說難度不小,不過非要理解為難度很小似乎也說得通,因為現在麻風病似乎很少見了,也很少聽說治療很麻煩,所以我不敢確認。譯者尚且如此,見不到原文的讀者估計就更難以確認了。

於是我專門去查了資料,原來這裡作者指的是在斯里蘭卡的非政府組織、慈善機構、公共關係公司、衛生部門為拯救麻風病人的進行了長期的艱苦努力,那麼意思當然是難度大了。所以最終翻譯為“和拯救麻風病人一樣非常艱難”,這樣就確保讀者不會誤解。

再舉一個例子,有篇譯文講的是如何用正則表達式匹配獨立的單詞,原文有

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,翻譯為“數據送來了噪音”就是嚴重的錯誤,只能譯為“數據是和噪音混在一起來的”,這是取“信”而棄“順”。儘管看起來比較直白簡陋,但很多技術文獻本身就是直白簡陋的,翻譯時一味追求譯文的“順”,不但喪失了科技文章看重的準確信,即便從翻譯本身來說,也有塗脂抹粉、文過飾非的嫌疑。

要補充的是,“信”和“順”捨棄一定要在“信和順無法調和”的前提下進行,“信而不順”絕不是不動腦筋硬譯的藉口。即便是堅持信而不順的魯迅先生也說過:信而不順,絕不是捨棄“跪下”而保留“用膝蓋站立”,不是捨棄“銀河”而保留“牛奶路”,不是捨棄“創刊”而保留“發行了第一期”,也不是捨棄“火箭筒”而保留“火箭推進榴彈發射器”。實際上,大量科技文章都是非常淺顯直白的,譯文對譯文讀者的要求不應當高過原文對原文讀者的要求,尤其是不應當人為抬高對讀者文字理解能力的要求。

第四,科技翻譯時,譯者應當對譯文專業領域有所瞭解。

這方面最明顯的例子就是關於武器的。眾所周知,英文裡的“槍”和“炮”都可以用gun,比如機槍是machine gun,加農炮是cannon gun。簡單說,在英文裡gun有許多種,“槍”和“炮”都是之一。然而在中文裡,“槍”和“炮”的定義是截然分明的:口徑在20mm以下的是“槍”,口徑在20mm以上的叫“炮”。所以正常來說,你看到的應該是 7.62mm步槍,12.7mm機槍,20mm機關炮,75mm榴彈炮等等。

大概是不少譯者不具備這種背景知識,所以翻譯時經常搞錯。英美國家一般使用英制單位而不是公制單位,所以口徑描述一般用.30或者.50。其中.30對應“0.30英寸”也就是7.62mm,.50對應“0.50英寸”也就是12.7mm。但是查閱相關譯文,經常出現“30mm步槍”和“50毫米機槍”的說法。

我的科技翻譯經驗總結

如果不熟悉.30或者.50的單位,把英寸和毫米搞混尚且情有可原,但“30mm步槍”和“50mm機槍”的說法就充分顯示了譯者對專業領域缺乏認知。即便不知道超過20mm口徑應當叫“炮”,按常識推斷,槍彈一般是食指粗細,30mm口徑有兩三指粗,成年人單手通常只能握一發,步槍能不能發射這種彈藥?彈匣會多大?普通士兵能攜帶多少發這樣的彈藥?依靠常識不難發現其中的問題。

第五,科技翻譯也需要了解基本文化知識。

我們經常說,好的專業文章也可以寫得“深入淺出”。要做到這一點,免不了借用一些日常生活中的經驗和例子。但是,不同文化的生活經驗可能是相差迥異的,如果譯者缺乏基本的瞭解,就很可能犯錯。

比如一篇以網絡通訊為主題的文章,借用了無線電通訊的場景來講解。在美國,也許私人電臺、無線電步話機很普遍,所以這種講解是很生動的。但是中國的情況與此不同,讀者和譯者可能並沒有太多的切身經驗,這時候就要加倍小心。遺憾的是,譯文裡就出現了

羅傑,準備發送下一批數據

好玩的是,之前和之後都沒有出現過“羅傑”這個人名。這個其實不用看原文就知道,“羅傑”的英文是roger,因為在句子開頭,所以首字母大寫,被譯者誤以為是人名。但是,如果留意過無線電通話就會知道,roger並不是人名,它的意思就是“收到”,是無線電通話中很常用的說法,所以正確的譯文應當是

收到,準備發送下一批數據

再比如,一篇協商系統的文章裡有這麼個場景:主持節點詢問所有參與節點,是否有反對意見。如果沒有反對意見,那麼主持節點就會說:

通過…通過…完成了

讀者看到這裡明顯會覺得奇怪,既然通過是確定的,為何要一再說“通過”,最後明明沒開始,為何說“完成了”?查閱原文,主持節點的信息是going…going…gone,這其實是借用了拍賣官在一錘定音時的行話,所以對應的譯文應當是

第一次…第二次…定了!

另外一個常見的翻譯錯誤是人名。英文裡經常有一些人名是代引號的,譯者大概不知道這是什麼意思,就直接照原樣翻譯過來了。類似下面這樣:

the commander is Virgil Ivan "Gus" Grissom指令長是維吉爾·伊萬·“格斯”·格里索姆;
the captain is Bernard “Bud” Kauderer,艇長是伯納德·“巴德”·科德羅

這都是不妥的,讀者會看得莫名其妙。因為正常人的名字不會打引號,父母給小孩取名時也不會弄一個帶引號的名字。

那麼這裡的引號是什麼意思呢?其實它的意思是“暱稱”、“諢名”、“愛稱”,通常是非正式但流行的稱呼,就等於我們熟悉的“大劉”、“老張”、“建平”之類——Virgil Ivan "Gus" Grissom是美國首批七位宇航員之一,如果你留意過相關的紀錄片或者電影,會發現大家都叫他Gus,雖然他正式的名字是Virgil Ivan Grissom。所以這類名字不妨這樣翻譯:

the commander is Virgil Ivan "Gus" Grissom指令長是“格斯”——維吉爾·伊萬·格里索姆;
the captain is Bernard “Bud” Kauderer,艇長是伯納德·科德羅,暱稱“巴德”

譯者如果平時沒有留意過這些文化細節,單純比照原文的文字,就容易犯下這類錯誤。不過它們也不難避免,如果譯者足夠留心,會發現“羅傑”也好,“通過…通過…完成了”也好,單純從文章來說也不通,和描述的場景衝突。如果能發現這點,對著原文多查資料,也可以避免這類問題。

第六,科技翻譯時,譯者應當對加倍小心應對專有名詞(術語)。

專有名詞是科技文章中大量用到的詞彙,專用來指涉一些約定俗稱的概念。因為科技行業的發展水平不同,現代科技專有名詞的大部分都來自西方國家,所以必須翻譯出來。物理、生物等領域的專有名詞許多都是組合而成,翻譯相對容易,如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,所以應當翻譯為“字符組”更合適。

總的來說,我認為科技翻譯的特點就是如此。它不會要求譯者有極高的文學造詣,但並不意味著放低了對譯者的要求。無論是從邏輯的嚴密、歧義的避免上,還是背景知識的理解和術語的準確性上,科技翻譯都有更高的要求,而且許多時候有成文、成型的習俗和規範,不像文學翻譯有那麼多自由發揮的空間。不過我相信,這些要求對負責任的譯者來說不是問題——須知道,科技行業工作,本身也離不開嚴謹、細緻的工作習慣。


分享到:


相關文章: