回應 "增值翻譯"

侯捷

2002/08/21


這個話題,緣起於  2002/05/04 增值翻譯  與 譯者的自由

茲後 DrCmm 網友 以非常認真嚴謹的態度寫下了:

增值翻譯系列談 (1) http://www.csdn.net/Develop/article/14/14723.shtm

增值翻譯系列談 (2) http://www.csdn.net/Develop/article/14/14727.shtm

增值翻譯系列談 (3) http://yeka.xilubbs.com/

來信詢問我的意見。所以我簡單寫下我的看法。

 

我對翻譯的態度

關於這個題目,我已經寫過很多文章。大略搜尋了一下侯捷網站,比較有代表性的幾篇文章是:

1995/08 二十年目睹之怪現象

1995/12 噢 1995

1999/06/28 技術引導乎?文化傳承乎?

1999/07/31 討論串 : 給侯捷先生及愛書人

2000/06/24 翻譯與著作 孰重

2001/12/08 科技翻譯面面觀

 

的看法

我曾經在 05/04 增值翻譯  與 譯者的自由 中這麼說:

> 增值翻譯非常好。不但這種作法很好,你這個詞也很好(我向你學習了 :))。

當時不知道 DrCmm 對於增值翻譯的實際作法和尺度。我以為,不被字面(ex. 英文)侷限,而以標的語言(ex. 中文)的文化和語文習慣出發,並甚至(在技術性書籍中)適當加入一些譯者補充(必須明確標示以為區隔),斯為「增值」之意。

看了  DrCmm 的增值翻譯系列談 (1)(2)(3),以下簡單列出我的看法。

1. 我不認為譯者有權力大改原作。如果我是作者,我不會授權給這樣的譯者(或出版社)。很多地位崇高的大師,他們對他們的作品的翻譯授權的要求是,譯本必須經他們過目同意(雖然他們看不懂譯本 — 我猜),你認為是為什麼 :) 至於小範圍的文字更動,本來就在翻譯範圍內。

2. 我不贊成譯者大改原作又不明白標示。如果我是讀者,我不會購買這樣的譯本。因為我無法區分我讀到誰的作品。技術性作品需要一個信賴度,我常因作者之名而買書(甚至是我工作領域之外的其他技術性書籍),我不能接受一個我還不信賴的譯者的擅自改動(尤其是刪減)。就算是我信賴的譯者,我也希望他明白標示(區隔)他所增補的部分。

3. 翻譯的價值,在於儘量精準地讓讀者快速閱讀有語文隔閡的作品。譯品的價值體現在「精準」和「快速」兩字。你讓讀者消化中譯本的時間,比消化原文本節省10倍,精準度又能達到原文本的 95%以上,你這譯本就有極高價值。這樣對讀者而言就是絕大的增值

4. 上述說的是「儘量精準地讓讀者快速閱讀」而非「讓讀者儘早接觸」。所以我說,在計算機技術方面,翻譯主要是為了教育、不是為了科研。搞科研還不看全球資訊,沒救了。最近我在臺灣論壇上看到我的朋友(一位計算機教授)說,他絕不讓中文書出現在他的課堂上。這固然是因為中文技術書籍(不論著譯)普遍表現太差,但我認為話也講得不夠全面(除非這就是他的本意、全意)。我在「 2001/04/24 唯堅持 得成功」那場對交大學生的演講中曾經回答同學的一個問題:
Q: 您贊不贊成學生在課程中使用您的中譯本?
A: 完全贊成。因為我有足夠的信心,你將因此多出10倍的時間來消化書中的技術,而且技術精準度絕不會比閱讀原文本的同學差。很多人認為應該以閱讀英文書來提昇英文程度,我贊成,但你有太多這樣的練習機會。既然遇到值得信賴的好譯本,那麼值得把練習英文的機會讓給其他科目。

關於「讓讀者得以大幅加快閱讀速度」,我舉幾個例子(見1999/06/28 技術引導乎?文化傳承乎?,亦見《C++ Primer》侯捷譯本「導讀 p7」)。以下未能呈現上下文脈絡,也缺乏特殊字形輔助,單單閱讀孤段,不好做出正確理解。但各位多少能夠體會一下這些長句子對中國人的閱讀難度。有的句子過長、倒裝句或連接子句過多;有的代名詞一大堆,不知誰指誰,有的隱含技術過於深澀,沒有內行人(譯者)為你指點迷津,不知伊於胡底。我曾經拿這些文字給我的好朋友看過,他在美國讀書兩年,工作八年(計算機專業),他說他看這些句子,撇開技術不談,他也覺得吃力,需得停頓下來花點時間分析分析句型。

☉C++ Primer 3e p443(這一句是這裡面最簡單的)

A typedef name provides an alternative name for an existing data type;
it does not create a new data type. Therefore, two function parameter
lists that differ only in that one uses a typedef and the other uses
the type to which the typedef corresponeds are not different parameter
lists.


☉C++ Primer 3e p559(這一句需要的技術背景多些)

The process by which compound statements and function definitions
exit because of a thrown exception in the search for a catch clause
to handle the exception is called stack unwinding

As the stack is unwound,the lifetime of local objects declared in the
compound statements and in function definitions that are exited ends.

☉C++ Primer 3e p688(這一句很長)

The resolution of names used in the body of the member functions of
a local class are first looked up in the complete scope of
the class before the enclosing scopes are searched
.

☉C++ Primer 3e p730(這一句可得好好分析語法)

This is particularly inappropriate in a copy assignment operator
that first frees a resource currently associated with the class in
order to assign the resource associated with the class being copied
.

☉C++ Primer 3e p849(三個 in which,真不好看)

As is the case with class types, in which a class definition must be
provided in every file in which the class members are used,
the compiler instantiates a class template for a
particular type in every file in which this instantiation is used in
a context that requires a complete class definition.

☉C++ Primer 3e p1021(那麼多 'to',真累人)

RTTI allow programs that manipulate objects as pointers or references
to base classes to retireve the actual derived types of the objects
to which these pointers or references refer
.

5. DrCmm 文中出現「傳統翻譯」一詞,並認為目前走入困境。「傳統翻譯」是指什麼?是指相對於「增值翻譯」嗎?我認為「傳統翻譯」一點問題也沒有,有問題的是執行者的水準。「傳統翻譯」並非等同於字譯(直譯),它本來就該是意譯(義譯)。事實上,在不偏離原書用字太遠的情況下,稍微調整一下句型、加上幾個啣接語氣,就能夠以十分順暢的標的語言重新描繪原始語言(我指的是技術書籍。技術書籍之內鮮少文學)。

6. 翻譯單位應該是「句子」還是「小節」?這是 DrCmm特別向我提出的問題。我以為,翻譯單位應該是句子(一或二個句子),極少數情況下才該以小段為單位重寫。至於小節,no way。以下試舉一例:

☉C++ Primer 3e p107

if we were to assign ri a new value, we would not change davl but would instead change temp. To the user, it is as if the change simply did not work (and it doesn't for all the good it does the user).

const references don't exhibit this problem because they are read-only. Disallowing non-const references to objects or values requireing temporaries in general seems a better solution than to allow the reference to be defined but seem not to work.

沒頭沒腦地列出一段技術文字,各位看不懂很自然。我要說的是,即使你循著該書脈絡看到這裡,上述第二段對 const reference的說明還是很不好理解。我的翻譯如下:

const references 並不會出現這樣的問題,因為它們是唯讀的。所以, (1) 不允許 non-const references 代表那些「需要暫時替代品」的 objects 或數值,或是 (2) 允許 reference 被定義但卻無法有效運作,哪一種作法比較好?當然前者才是好的解決方案。

我想你不太挑得出來翻譯大毛病,而且我已經加上文字修潤了。但它(從技術的角度)還是很不好理解,原因出在本質:原書此段的邏輯根骨就已經差了,對 const reference 的解釋角度不佳,文字結構亦不佳。這種情況下才適合由譯者將整段重新改寫(但譯者得有把握寫得更好才這麼做),或仍把它像上面那樣翻譯出來,後面加註一小段譯者補充(我以為這種作法更好)。(:不過,抱歉,兩種辦法我都沒做,我就是只把它譯成上述那樣)

7. 能夠不模稜兩可拐彎抹角的時候,我儘量不模稜兩可拐彎抹角。因此,對於 DrCmm 的「增值翻譯」,我直截了當地說:沒有空間,沒有市場,不具可操作性(在付出與獲得之間,願意做那麼大幅度增值的人不知有幾)。當然,這只是侯捷個人的看法,更重要的是原作者的授權、出版社的信賴,和讀者的接受度。

8. 我對 DrCmm的嚴謹和沉穩很欣賞。你總是認真地寫下一大篇一大篇的見解,以做學問的態度旁徵博引,足見功夫。你總是不那麼急呼呼地到論壇上和人針鋒相對(仿彿要一別短長,一較死生),而是以另一大篇完整文章回應。我雖不贊同你的見解,但我欣賞你這種作法與態度 :)


聯想(與上文無關,純粹跳躍思考下的聯想)

※ 翻譯,需要加上譯者自身母文化和母語的修潤。這是根本不必說的道理。那種硬梆梆的直譯產品,不夠格稱翻譯,只能說是「字面轉譯機」、「會說兩種語言的鸚鵡」。

IT 技術書籍的真正關鍵,是和 IT 技術直接或間接相關的文字,那就必須精準(所以譯者要有足夠的技術功底)。其他部分流暢即可。把時間和精力放在與技術不太相關(甚或只是作者閒談)的文字上字字推敲,有點兒捨本逐末。把美國作品中的密西西比河改為中國黃河,會讓我興起「這外國作家怎麼這麼了解中國,真突兀,數據對嗎」的想法。中國難道鎖國了嗎?中國讀者難道連看幾個外國人名、地名都無法接受了嗎?不會的。當然,如果涉及文化認知,尤其是流行文化、生活文化,最好來點小譯註。

教育型的東西和實業界的東西,考量點不一樣。東西太大對教育反而有害。把整個城市搬到月球上固然好,但太空船只那麼點大。是的,需要定位,需要取捨。取捨之間便見作品的訴求對象,和作者的功力。

學習過程中,不同階段需要不同教材。若說某某領域只需一兩本書就夠,那便是還處於學習的幼稚階段中。若純粹從個人需求去抨擊不同定位的書,那便是處在本位主義的狹隘框框裡。真要鑽研某個技術領域,首先需要一兩本全貌性書籍,然後便是各類專著。

※ 讀書,需要實踐,這是根本不必說的道理。多讀書,絕對好過少讀書;少讀書,絕對好過沒讀書。至於讀死書,死讀書,不在討論之列。

沒有萬變不變的手法,只有萬變不變的宗旨和本質。所以學習要從本質學起。 toy program 如果設計良好,便是 real program 的縮影。小型(但優秀)的 toy program,當然比大型的 real program 有比較好的教育效果。

想站在巨人的肩膀上看得更遠,首先要能夠站到巨人的肩膀上。

程式不一定都得自己寫出來。精讀名家源碼,知道「實際上怎麼寫」,也等於自己寫了這些東西 — 前提是「精讀而徹底理解」。

「謀定而後動」顯然比「在錯誤輪迴中不斷修正」更從容。寫程式,適當的速度是要的,但無需比快。物理向來是我的拿手,高中物理、大學聯考、研究所動力學考試,我都是超高標準。到現在我都很奇怪怎麼能在(高中物理月考)60分鐘內算出 50個不太容易的題目。愛因斯坦恐怕也通不過臺灣的聯考(和大陸的高考),但我連愛因斯坦的一根汗毛也比不上。

有一種說法頗為流行:「優秀的程序員寫程式很快,…通過速度上的優勢,在與別人相同的時間內重構精練其程式,達到 good 甚至 excellent 的境界」。這種說法大約對 99% 的優秀程序員成立,但不能說「」。比例較低的一種人,通過另一種鍛鍊方式來加強自己的軟體開發或掌握能力。這種程序員博覽群書,把精力花在思考與融會貫通,以及對好作品的透徹理解上。他們不再需要多寫程式(但曾經寫過許多程式),他們寫起程式來可能較慢,但無人敢否定他們的優秀。這種人並不是光說不練一型,也不是眼高手低一型。他們已經練過了,高過了,現在以一種更從容更有價值的方式來陶養自己。只要能成為一個優秀程序員(軟體人員),兩種過程都很好,後者看起來可能更從容,理論基礎更雄厚。

-- 侯捷 (jjhou), 2002.08.21 臺灣.新竹