淺談計算機圖書的翻譯——“增值翻譯”的幾個參考例子 (轉)

淺談計算機圖書的翻譯——“增值翻譯”的幾個參考例子 (轉)[@more@]

我的一篇文章，請大家提提意見（ to:w-gao@263">w-gao@263.net )，筆者的小小心願是將“增值翻譯”發展成一門可操作性極強的理論，:-)

－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－

淺談圖書的翻譯——“增值翻譯”的幾個參考例子

作者：高巍（網名DrCMM），地址。本文歡迎轉載，歡迎大家來信交流討論。轉載時請保留本宣告，謝謝。

今年5月，我就個人對科技翻譯的一些粗淺認識向技術作家侯捷先生請教。在給侯捷先生的電子中我提出了“增值翻譯”的想法，強調應該改變傳統翻譯中以原文和原作者為中心的做法，而要“以讀者為中心”，給譯者以自由。侯捷先生隨後以《“增值翻譯”與“譯者的自由”》一文回覆，鼓勵後學。

“增值翻譯”的概念實際上很簡單，就是在保證原文技術實質的前提下，儘量有助於讀者對技術內容的理解。在我接觸的國外技術圖書中，除了少數幾個如C++之父Stroustrup，原作者的文筆一般並無過人之處。而且，我想，讀者閱讀一本技術圖書的目的並不是瞭解原作者的寫作筆法和敘述風格，相應地，譯者在翻譯時的重點也不應該是儘量符合原書的文字。今天，大量譯作中隨處可見的洋腔洋調、彆扭句式就是傳統翻譯理論帶來的直接後果，影響了讀者的閱讀體驗。

有關翻譯我是一個門外漢，自己的工作也與翻譯完全無關，應該說只是“外行看熱鬧”，對於該領域沒有置喙評論的資格。我對翻譯的一點淺陋認識主要來自以下幾個方面：

（一）個人讀書經歷
做員的，難免要讀到一些翻譯過來的技術圖書。讀得多了，特別是當好不容易弄懂了一個問題再回過頭來看時，常常不免發出這樣的感慨，“挺好懂的一件事情，幹嗎要說得這麼晦澀彆扭，如果換一種說法，完全不必要讓讀者費那麼大勁才能弄明白。”
久病成良醫。良醫不敢當，但是再讀到別人的譯著時，起碼敢說一句，“沒吃過豬肉，還沒見過豬跑嗎？”

（二）作家王小波
如果能夠勉強攀關係，我與王小波先生還是校友兼系友。我非常贊同王小波先生關於閱讀體驗應該“有趣”的提法，對於內容本來就難的技術書籍，譯者更應該體諒讀者，不要在文字上為難讀者，而要儘量降低讀者在文字方面的困難，可以將主要精力用於理解和吸收技術知識。

王小波先生在《我的師承》一文中，這麼寫道：
“假如中國現代文學尚有可取之處，它的根源就在那些已故的翻譯家身上。我們年輕時都知道，想要讀好文字就要去讀譯著，因為最好的作者在搞翻譯。這是我們的不傳之秘。”
“到了將近四十歲時，我讀到了王道乾先生譯的《情人》，又知道了小說可以達到什麼樣的文字境界。道乾先生曾是詩人，後來做了翻譯家，文字功夫爐火純青。他一生坎坷，晚年的譯筆沉痛之級。”

因此，因了王小波先生的介紹，我得以接近傅雷、王道乾和宗白華等先生的譯文。

（三）《性心理學》
科技著作方面的翻譯，潘光旦先生（曾任清華大學校長）譯、英國藹理士原著的《性心理學》是我認為最佳的譯本，三聯書店版。潘光旦先生的譯本，原文和潘先生的譯註篇幅接近一半對一半的比例，潘先生從中國古代的史籍、方誌、筆記叢刊中整理了大量佐證材料，使得讀者閱讀興味盎然。
在過去那個精神極度空虛和苦悶的年代，一個青年想了解性知識，同時又要拒絕那些下三濫的東西以及避開政治上的風險，他很自然地會發現這本書是一個的選擇（畢竟，有三聯的牌子和清華校長的身份）。當然，現在的青年就很“幸福”了。

（四）《21世紀經濟報導》和《經濟觀察報》
大學的時候隨喜眾人，去考TOEFL和GRE，聽說閱讀Economist（《經濟學人》）、New Republic（《新共和》）、Foreign Affairs（《外交季刊》）能長英文的功力，所以不管讀不讀得懂還是硬著頭皮去讀。雖然，後來GRE終於沒有去考，但是閱讀的習慣卻留了下來。

國內的新對國外媒體的抄襲和剽竊是一個公開的秘密，但有翻譯的好、抄的巧妙的，也有翻譯的差，抄都不會抄的。相對來說，《21世紀經濟報導》和《經濟觀察報》是抄襲和剽竊得比較成功的，起碼翻譯的質量比較高。從這兩份流行報紙上，我常常毫不驚訝地發現Economist、Wall Street Journal上熟悉的文字，當然也學到了一些比較高明的翻譯技巧，特別是一些比較好的歐化句式。這些歐化句式，對於英語中的一些長句、難句，特別是那些句子成分較複雜，又多倒裝、插入語、同為語和從句的句式，往往有獨到的功效。

 

“增值翻譯”是一門實踐的藝術，空談理論無益，如果不自己動手做一做，很可能是眼高手低的尷尬情形。我對“增值翻譯”的觀點是，

“原文僅僅是一個blueprint，譯者可以根據讀者的水平範圍、閱讀興趣，大膽的增刪調整（儘量少刪，而以“注”和“評”為主），使得譯本更適合特定目標讀者物件群體。”

這個觀點究竟讀者是否接受，多大程度上接受，對於一個標榜“以讀者為中心，而不是以原文為中心”的翻譯理論而言，是非常關鍵的。特別是，如何把握增刪調整的度，更是一個敏感的問題，侯捷先生就對“刪”持很謹慎的態度。因此，我嘗試著對一些經典技術著作的名家譯本中的若干段落給出自己的譯文，主要選自潘愛民先生譯的《The C++ Primer》，裘宗燕先生譯的《The Design and Evolution of C++》，以及侯捷先生譯的《Refactoring》、。希望大家能夠比較一下，多提意見，使我能夠繼續不斷使得“增值翻譯”更具可操作性。（個人一點私心和一點宏願，請大家體諒。）

自己決沒有與這些尊敬的譯者比較的意思，只是希望願意與對技術翻譯感興趣的朋友們交流，獲得一些啟發和提示，使作為讀者的我能夠有幸讀到一本又一本優秀的譯著，更加有利於技術的普及。CSDN的孟巖（myan）先生曾經作憤激之語：讀者能夠讀到優秀的譯著是一種幸運。我更希望，讀到優秀的譯著是讀者對於譯者最起碼的期待和要求。

侯捷先生非常重視讀者的意見。希望本文能夠成為來自一個普通讀者對國內技術翻譯界的一點有益反饋。

例子1：《C++ Primer》的前言關於Primer名稱由來的一段
此段在CSDN論壇的技術書籍版曾經引起過爭議。為什麼一本Advanced級別的書要取Primer做名？我認為把這段譯好，從商業角度而言非常重要。即使這本書正文是張麗譯，但前言至少應該是潘先生所譯。試想，如果這本書不是侯捷先生極力推薦，有多少讀者會因為Primer而顧名思義，錯過一本好書！
（1）原文：
C++ Primer provs a comprehensive introduction to the International Standard on C++. It is a primer in the sense that it provides a consciously tutorial approach to describing the C++ language. (It is not a primer in the sense of providing a simplistic or "gentle" description of the language.) Programming ects of the language, such as exception handling, the container types, -oriented programming, and so on, are presented in the context of solving a particular problem or programming task. Language rules, such as the resolution of an overloaded function call or the type conversions supported under object oriented programming, are given extensive treatment that may initially seem out of place in a primer. We believe that the coverage is necessary to a practical understanding of the language, and we view the material as something one goes back to rather than digests at one sitting. If you find it initially overwhelming or simply too dry, put this material aside until later — we identify such sections with the following convention:

（2）潘愛民先生譯文：
C++ Primer 為C++國際標準提供了一個全面的介紹。在這種意義上，它是一個初級讀本（primer），它提供了一種指導性質的方法來描述C++語言。（但是，它也為C++語言提供了一種簡單而溫和的描述，從這個角度來看，它不是一本初級讀物。）C++語言的要素，比如異常處理、容器型別、物件導向的程式設計等等，都在解決特定問題或程式設計任務的上下文環境中展示出來。C++語言的規則，比如過載的解析過程以及在物件導向程式設計下支援的型別轉換，也都有廣泛的論述，這看起來就超出了一本初級讀本的範疇。我們相信，為了加強讀者對於C++語言的理解，覆蓋這些內容是必要的。對於這些材料，讀者應該不時地回頭翻閱，而不是一次消化了事。如果開始的時候你發現這些內容比較難以接受或者過於枯燥，請把它們放到一邊，以後再回頭來看。我們把這樣的章節加上特殊的記號：※。

（3）高巍譯文：
C++ Primer全面地介紹了ISO標準C++。正因為涵蓋的內容如此廣泛，為了方便讀者掌握C++，本書特意按照學習教程的形式來組織和安排全書的結構。在這個意義上，它是一個“基本教程”。（但是，本書針對的是C++的初學者而不是程式設計的初學者，因此對C++語言的講解不同於一般C++教程的冗長繁瑣，在闡述形式上追求簡潔和雅緻，所以有別於通常意義上的基礎讀本。）對於C++語言中和實踐有關的部分，如異常處理、容器型別、物件導向的程式設計等等，本書贊同“在戰爭中學習戰爭”的態度。鑑於C++初學者一般缺乏大型專案開發的，因此，本書是透過分析實際程式設計中一個個具體的問題和任務來匯入這些語言特性。基於同樣的原因，一般基礎讀本中通常並不涉及的內容，諸如過載函式呼叫的決議以及物件導向程式設計中所支援的型別轉換等C++語言規則，本書也給予了充分的關注。作者相信，涵蓋上述主題有助於讀者從程式設計實踐的角度深入理解C++語言。當然，對於這些較深的技術主題，讀者應該不時回頭翻閱，而不是過一遍了事。如果開始的時候你發現這些內容難於接受或者過於枯燥，可以暫時跳過這些章節，留待日後再讀。我們為這些章節都標註了特殊的記號：※。

（4）多說幾句：
primer：有關該詞英文釋義的關鍵是elementary，譯成“基本教程”比“初級讀本”更適宜。

tutorial：有關該詞英文釋義的關鍵是instruction，譯成“指導”不適宜。聯想到 的指令稱為Instruction，因此tutorial有cookbook，“手把手教”的意思，這裡譯為“學習教程”。

gentle：理解成“溫和”文意不通，而且與Simplistic不能對應。做過GRE填空題的人，肯定不會這麼譯！

前言的第二段有“The book is intended as a first book on C++; it is not intended as a first book on programming!”，正好用來在本段加入“本書針對的是C++的初學者而不是程式設計的初學者”。

例子2：《The Design and Evolution of C++》第1章第3節
這一節非常重要，正如裘宗燕先生在《譯者序》中所言，“提出了他在從事科學技術工作中的人文思考”。我就此專門給Stroustrup先生髮電子郵件請教，Stroustrup先生回郵如下：
“At the time where I wrote that, I did give a thought to Russian programmers.”
如果明白Stroustrup為什麼在《The C++ Programming Language》中講到C++名稱的由來時提到了喬治.奧威爾的《1984》，而且明白《1984》在反對極權主義歷史上的重要意義，我們會對C++更增加一種語言之外的感情。
強烈建議讀到這篇文章的朋友，看看《1984》！用搜一下，很多地方提供電子版。

（1）原文：
My preferences in literature have reinforced this unwilliess to make a decision based on theory and logic alone.In this sense,C++ owes as much to novelists and essayists such as Martin A.Hansen,Albert Camus,and George Orwell,who never saw a computer,as it does to computer scientists such as David Gries,Don Kunth,and Roger Needham.Often,when I was tempted to outlaw a feature I personally disliked,I refrained from doing so because I did not think I had the right to force my views on others.I konw that much can achieved in a relatively short time by the energitc pursuit of logic and by ruthless condemnation of "bad,outdated and confused habits of thought."However,the human cost is often high.A high degree of tolerance and acceptance that different people do think in different ways and strongly prefer to do things differently is to me far preferable.

（2）裘宗燕先生譯文：
對文學的熱愛更增強了我的認識：僅根據理論和邏輯做決策是沒有希望的。在這個意義上說，C++由小說家和散文家那裡得到的東西也很多，例如馬丁.漢森、阿爾伯特.加繆以及喬治.奧威爾等。他們根本沒有見過計算機，但對於C++的貢獻卻與電腦科學家如David Gries，Don Kunth，Roger Needham一樣大。經常地，如果我試圖取締一個我個人不喜歡的語言特徵時，我總抑制住自己這樣做的慾望，因為我不認為自己有權把個人觀點強加給別人。我知道透過強力地推行邏輯，毫無同情心地譴責“思想中壞的、過時的、混亂的習慣”，是可能在相對短的時間裡有更多的建樹。但是，人的代價總是最高的。不同的人們確實會按不同的方式思考，喜歡按不同的方式做事情，對於這些情況的高度容忍和接受是我最願意的事情。

Martin A.Hansen，1909－1955，丹麥小說家和散文作家。——譯者注。

Albert Camus，1913－1960，法國小說家、散文家和劇作家，1957年獲諾貝爾文學獎。——譯者注。

George Orwell，1903－1950，英國作家和社會批評家。——譯者注。

（3）高巍譯文：
我在文學方面更偏愛馬丁.漢森、阿爾伯特.加繆以及喬治.奧威爾等的作品，這種文學風格方面的閱讀偏好使得我更不情願僅僅根據理論和邏輯作出決定。從此意義上說，這些散文家和作家，雖然從未見過計算機是什麼，但是他們對於C++的貢獻可以說和電腦科學家如David Gries，Don Kunth，Roger Needham一樣大。很多時候，當我試圖取消一個我個人不喜歡的語言特性時，我總是儘量控制住自己不要這樣做，因為我不認為自己有權把個人觀點強加給別人。我也清楚，如果全力追求邏輯上的完美，毫不留情地譴責那些“壞的、過時的、混亂的思維定勢”，C++可能在相對更短的時間內取得更大的成就。但是，這樣做會造成很高的人力代價。C++語言應該有著高度的包容性，允許不同的人們按照各自喜歡的不同方式思考和行事，這是我更傾向於的看法。

Martin A.Hansen，1909－1955，丹麥小說家和散文作家。在丹麥被德國佔領期間，他為丹麥抵抗運動組織大量著文，呼籲丹麥人民奮起反抗侵略者。他的文章大量使用意向符號，與魯迅的散文詩集《野草》風格類似。Stroustrup也是丹麥人，Martin A.Hansen對其的意義正如魯迅對我們的意義。——譯者注。

Albert Camus，1913－1960，法國小說家、散文家和劇作家，1957年獲諾貝爾文學獎。作品有：《反面和正面》,《婚禮集》,《局外人》,《米諾託或奧蘭的逗留》，《鼠疫》,《戒嚴》,《正直的人們》，戲劇：《誤會》、《加利居拉》等。——譯者注。

George Orwell，1903－1950，英國作家和社會批評家。他最重要的兩部作品是政治寓言《1984》和《動物莊園》，對極權主義和烏托邦思想進行了深刻的諷刺。——譯者注。

（4）多說幾句：
preference是指作者在文學方面的好惡取捨，不是簡單熱愛文學，而是熱愛文學的某些風格流派（genre）。

馬丁.漢森、阿爾伯特.加繆以及喬治.奧威爾，我認為裘宗燕先生在譯註中應給以更多介紹。否則，讀者很難理解為什麼他們甚至連都沒摸過，為什麼對C++的貢獻卻與電腦科學家們一樣大。這是理解本段內容的關鍵！

“我知道透過強力地推行邏輯，毫無同情心地譴責“思想中壞的、過時的、混亂的習慣”，是可能在相對短的時間裡有更多的建樹。”這段話，裘宗燕先生的譯文太晦澀。而且，“強力地”在原文中找不到依據，energetic pursuit並沒有“強力”的意思。

整個第1章第3節，因為涉及人文方面內容較多，裘宗燕先生譯的都不令人滿意。建國後理工科培養出來的教授學者人文素養之差，令人驚歎！在北大物理系讀書時，教我們課的老教授深情地回憶解放前清華大學物理系要求學生必須修讀朱自清先生的中國文學課，真是令人感傷而神往！

例子3：《Refactoring》前言第一段
（1）原文：
"Refactoring" was conceived in Smalltalk circles, but it wasn't long before it found its way into
other programming language camps. Because refactoring is integral to development,
the tecomes up quickly when "frameworkers" talk about their craft. It comes up when they
refine their class hierarchies and when they rave about how many lines of code they were able to
delete. Frameworkers know that a framework won't be right the first time around—it must evolve
as they gain experience. They also know that the code will be read and modified more frequently
than it will be written. The key to kee code readable and modifiable is refactoring—for
frameworks, in particular, but also for software in general.
（2）侯捷先生譯文：
重構（refactoring)這個概念來自Smalltalk圈子，沒多久就進入了其他語言陣營。由於重構是（framework）的開發中不可缺少的一部分，所以當框架開發人員討論自己的工作時，這個術語就誕生了。當他們精煉自己的類別層次體系時，當他們叫喊自己可以刪除多少多少行程式碼時，重構的概念慢慢浮出了水面。框架設計者知道，框架不可能一開始就完全正確——它會隨著設計者的經驗成長而進化；他們也知道，程式碼被閱讀和被修改的次數，遠遠多於它被編寫的次數。保持程式碼易讀、易修改的關鍵就是重構（refactoring）——對框架而言如此，對一般軟體也如此。
（3）高巍譯文：
重構的概念源自Smalltalk社群，最初是在應用程式框架（Application Framework）的開發過程中形成，後來逐漸在其他程式設計語言中也得到了採用。一般而言，應用程式框架是一個完整的程式“模板”，其具備標準應用軟體所需的基本功能，如存取、列印預覽、資料動態等，還包括了支援這些功能的圖形介面元素。應用程式框架由一組內聚力相當強的類庫組成，類之間的靜態層次結構關係和隱含的邏輯聯絡對於應用程式框架至關重要，而這些靜態關係和隱含的邏輯聯絡往往相當複雜，程式設計者不可能採取傳統的“自頂向下”設計（Up－Front Design），而只能採取所謂的演化式設計（Evolutionary Design），逐漸調整和精化紛繁複雜的類之間的層次結構關係。在演化式設計中，一個應用程式是在設計人員多次反覆，“認識－設計－再認識－再設計”這樣的迴圈過程中透過“無情地重構”逐漸完成的。從軟體生命週期的角度來看，程式碼編寫僅佔整個軟體生命週期的很小部分，大多數時間進行的工作是測試和維護，因此程式碼的易讀性與可理解性也就尤為重要。重構，就是在保持程式碼的外在行為的前提下，改善程式碼的質量（特別是程式碼易讀性與可理解性）的一個有效方法。因而，重構不僅有助於應用程式框架的開發者，對於一般軟體的開發者而言也是有益的。

 

例子4：《Refactoring》前言第二段
（1）原文：
So, what's the problem? Simply this: Refactoring is risky. It requires changes to working code that can introduce subtle s. Refactoring, if not done proy, can set you back days, even weeks.
And refactoring becomes riskier when practiced informally or ad hoc. You start digging in the
code. Soon you diver new opportunities for change, and you dig deeper. The more you dig,
the more stuff you turn up…and the more changes you make. Eventually you dig yourself into a
hole you can't get out of. To avoid digging your own grave, refactoring must be done
systematically. When my coauthors and I wrote Design Patterns, we mentioned that design
patterns provide targets for refactorings. However, identifying the target is only one part of the problem; tranong your code so that you get there is another challenge.

（2）侯捷先生譯文：
好極了，還有什麼問題嗎？很明顯：重構具有風險。它必須修改運作中的程式，這可能引入一些幽微的錯誤。如果重構方式不恰當，可能毀掉你數天甚至數星期的成果。如果重構時不做好準備，不遵守規則，風險就更大。你挖掘自己的程式碼，很快發現一些值得修改的地方，然後你挖得更深。挖得愈深，找到的重構機會就越多……於是你的修改也越多。最後你給自己挖了個大坑，卻爬不出去了。為了避免自掘墳墓，重構必須化地進行。我和另外三位（協同）作者在《Design Patterns》書中曾經提過：design patterns（設計樣式）為refactoring（重構）提供了目標。然而，“確定目標”只是問題的一部分而已，改造程式以達目標，是另一個難題。

（3）高巍譯文：
但是，重構也存在風險。風險之一就是對程式碼的改動導致程式無法正常工作，如果同時又缺乏完善的版本控制和管理機制，常常導致幾個工作日甚至數週的努力付諸東流。風險之二就是開發人員往往過度“沉溺”於重構之中，採取的是一種隨意無序的工作方式。這裡改動一段程式碼，那裡改動一段程式碼，而且不時發現有更多地方需要改動，最後開發人員越陷越深，不可自拔。重構並不是過去那種“修修補補式”（Code－Fix）無序開發方式的一個好聽的代名詞。實際上，重構有著它的原則和最佳實踐，是一個有紀律（Disciplined）的改善現存程式碼質量的軟體工程方法。例如，優秀的設計就為重構提供了一個程式碼改進的方向和目標。當然，有了方向是一回事，如何透過重構接近這個方向就是另外一回事。