科技翻譯的特點
傳統上,翻譯與文學的關係很近,說起翻譯許多人首先想到的是“文筆要好”。近年來隨著資訊交流的發展,實用文字尤其是科技文字的翻譯越來越顯得重要,許多科技領域的從業人員也有興趣或有動力翻譯科技文章,並取得了大量成果,突出表現之一就是IT類書籍的翻譯質量有了很大的提升,背後的功臣很多都是IT界的“翻譯票友”。
科技翻譯大大繁榮了,科技翻譯本身的學問卻沒有相應的進展,各種翻譯教程和經驗總結仍然側重於一般的翻譯或文學翻譯。然而深入瞭解翻譯的人都知道,不同文體、不同領域的翻譯,是各有特點的。比如新聞翻譯追求簡潔、準確、吸引眼球,文學翻譯更強調完整、流暢、意境貼切。這種差異貫穿在翻譯過程中,產生了很多講究,所以新聞才能譯得像新聞,小說才能譯得像小說。同樣的道理,科技翻譯也不能完全照搬普通翻譯的做法,要想做好它,還必須瞭解其自身的特點。根據我的總結,科技翻譯大致有以下幾個特點。
第一,科技文獻通常是用來講道理的,所以譯者必須準確理解文字表達的道理。
這裡說的“講道理”不是狹義的講解原理,而包括講解原理、研究論證、實驗分析等等,或者換句話說,科技文獻討論的內容是相對客觀的,所以讀者的理解也應該可以客觀衡量。文藝作品沒有這個特點,經常是“言有盡而意無窮”,可以“一千個讀者就有一千個漢姆雷特”,科技文章則要求“有九分把握不說十分話”,必須“一千個讀者只能有一個漢姆雷特”。所以,科技文獻的譯者不但要懂得原文,還必須準確理解原文。以前有幾家出版公司的IT類翻譯圖書之所以被大家痛罵,很大程度上不是因為譯者的中文不夠好,而是因為譯者根本不懂也不願意弄懂作者在說什麼,這樣的譯文當然只能落得讓讀者痛罵的下場。
科學技術本身有客觀標準可循,所以想要準確理解科技文獻的意思反而比文學文章更容易,因為譯者不必拘泥於原文的文字。拿IT類圖書來說,如果原文先講了甲乙兩個演算法,然後下了結論,譯者如果不能確認作者的褒貶和選擇,完全可以根據前文的講解進行邏輯推理,甚至可以親自動手程式設計實踐——邏輯和程式是絕不會因人而異的。推而廣之,譯者完全可以獨立驗證自己的理解是否準確,而理解準確正是譯文合格的前提條件。所以我建議,科技文獻的譯者在翻譯完成之後,要拋開原文,只看譯文,想想是否能明白作者要講解的知識、原理、規律,如果做不到,那麼譯文多半不合格。
第二,科技翻譯的譯者有信心理解原文,也完全可以適當改動原文。
上文已經說過,科技文獻的一大特點是,其論述內容有客觀標準可循,所以譯者可以藉助“文字之外”的內容來判斷自己的理解是否準確。這可以算科技翻譯的獨門優勢,而且這點優勢相當有價值。因為科技文獻的作者往往不是專門的文字工作者,不能奢求很高的寫作水平,某些片段可能講解晦澀導致難以明白,或者原作者並沒有為譯文讀者考慮(實際上這種情況相當普遍),所以使用了一些專屬於某些文化的典故、俚語。如果是文學翻譯,遇到這樣的問題會非常麻煩,摸不準原作者到底是什麼意思。科技翻譯則沒有這種問題,譯者一旦確認自己理解了原文的內容和邏輯,就可以大膽改動譯文讀者難以理解的片段,避免譯文讀者在同樣的問題上浪費精力。
我曾在某篇技術文章裡見到作者評價某種做法的難度“和拯救麻風病人一樣”。根據上下文猜測,這裡的意思大概是說難度不小,不過非要解釋為難度不大似乎也說得通,因為現在麻風病似乎很少見了,也很少聽說死人,所以我不敢確認。那麼,見不到原文的讀者估計就更難以確認了。為了謹慎起見,我專門去查了資料,原來這裡作者指的是在斯里蘭卡的非政府組織、慈善機構、公共關係公司和衛生部門為拯救麻風病人的艱苦努力,那麼意思當然是難度大了,所以我翻譯成“和拯救麻風病人一樣非常艱難”,這樣就確保讀者不會誤解。
再舉一個例子,有篇譯文講的是如何用正規表示式匹配獨立的單詞,原文翻譯過來是“這樣處理,如果句子中出現了inline,表示式只能匹配inline,而不會匹配in”。原文並沒有錯,因為英文字身就是以詞為單位的,所以閱讀原文時當然知道其中的inline、in都是指的“單詞”inline、in,而不是“字串”inline、in。但中文並沒有從形式上分詞表示,所以讀者有可能產生誤解,有時大家說的“這句話包含in”的意思就是“這句話包含字串in”。為了避免誤解,翻譯時就應當大膽將“單詞”兩個字增補進去,譯為“這樣處理,如果句子中出現了單詞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不翻譯反而是好事,因為中文世界裡大多數人都不知道“小甜餅”是什麼,有什麼作用,直接保留為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,所以應當翻譯為“字元組”更合適。
相關文章
- 大資料有何特點?_光點科技大資料
- GAN做影象翻譯的一點總結
- GAN做影像翻譯的一點總結
- 具有中國文化色彩那點詞的翻譯
- Yurii談翻譯(五)怎樣翻譯更地道:so…that…的翻譯
- Solr--schema.xm要點翻譯Solr
- Yurii談翻譯(九)怎樣翻譯更地道:冠詞a的翻譯
- Yurii談翻譯(十)怎樣翻譯更地道:最高階的翻譯
- 翻譯的未來:翻譯機器和譯後編譯編譯
- 互動科技展廳的應用都有哪些特點
- 科技互動沙盤的六大技術特點
- Yurii談翻譯(六)怎樣翻譯更地道:“as somebody said…”的翻譯AI
- Yurii談翻譯(十三)怎樣翻譯更地道:It is…that…句型諺語的翻譯
- Yurii談翻譯(十四)怎樣翻譯更地道:否定句的翻譯
- 皮特陳,這個是中文的不必翻譯啦。 (7千字)
- 翻譯出版那點事兒【轉載】
- 有趣的翻譯
- 痛苦的翻譯
- 關於 blog文集和翻譯的一點想法
- 翻譯
- 4大特點解析華為雲資料湖“黑科技”
- 如何完成中文翻譯日文線上翻譯
- Yurii談翻譯(四)怎樣翻譯更地道:翻譯如鋪路
- [翻譯]JavaScript的成本JavaScript
- Symbol 的作用[翻譯]Symbol
- Before的翻譯
- Google翻譯的APIGoAPI
- 本人翻譯的文件
- 偶翻譯的小說
- Ubuntu安裝劃詞翻譯軟體Goldendict 單詞翻譯 句子翻譯UbuntuGo
- Draft 文件翻譯 - 高階主題 - 管理焦點Raft
- 人工翻譯的分類 安睿傑線上翻譯平臺
- 蝴蝶書-task2: 文字推理、摘要、糾錯 transformers實現翻譯 OpenAI翻譯 PyDeepLX翻譯 DeepLpro翻譯ORMOpenAI
- 科技愛好者週刊(第 153 期):機器翻譯是對譯者的侮辱嗎?
- Nginx翻譯Nginx
- [翻譯] TransitionKit
- 翻譯篇
- OllDbg翻譯LLDB