個人寫譯近況

TASS, TIJ2, TCSL, Co-translation, Education.

侯捷

2002/08/20


今年上半年陸續完成三本重份量書籍:《STL源碼剖析》(著)、《C++ 標準程式庫》(譯)、《Thinking in Java》2e 中文版 (譯)。合譯的書稿也陸續進來了,目前正展開後續的技術檢閱、文字修潤、版面安排工作。七月份起並開始陸續為業界開一些課程。稍後我將談談這些書籍,這些合譯計劃,以及一些授課心得。

有趣的是,邀課單位絕大多數都是大型硬體公司,鮮少軟體公司(註1),而我所講的 C+/Java/OOP/ OOD, Win32 API programming model, MFC Programming model...,卻是絕對的「軟」。這代表什麼呢?(1) 首先表示硬中帶軟,大型硬體公司也都有自己的軟體部門(非指MIS),而且亟欲從傳統的 assembly/C/Procedural-based 過渡到 C++/OO-based(根據行業特性,他們大概不會選擇 Java)。(2) 以取樣分析的角度來看,這是否意味軟體公司大多不怎麼賺錢,或軟體公司的規模大多不足以花錢辦這類員工內訓? 當然還有另一種可能是,(3) 軟體公司把這些講題視為基礎必備的行當,員工都應該已經熟練或自我學習。最後一個可能是 (4) 其實軟體公司也常有公司內訓,只是侯捷孤陋寡聞。

註1這兩年的邀課公司,印象所及有宏痋B華邦、凌陽、鴻海...,都是大型硬體相關公司;工研院則是軟硬兼施;唯一純軟體公司是思源,不過這家公司比較特殊,軟中帶硬:他們做 EDA(Electronic Design Automation)產品,客戶是 IC 設計公司。IC 設計大賺錢,他們當然也獲利豐厚 :)  另一個比較特殊的邀課單位是東軟,這是大陸赫赫有名的大型集團(員工 5000人),雖然名稱帶「軟」,但並非純軟體公司,他們也做「核磁共振機」等醫療設備。

這些書籍和課程,把我的時間排得滿檔。被我保留的讀者來函(準備將來整理於侯捷網站)已經累積  697 封了。我很喜歡整理讀者來函並擇件回覆,但工作使我暫時抽不出時間來做這些事 :(

 

●關於《STL源碼剖析》
TASS : The Annotated STL Source

曾有讀者拿著書,指著書中的圖,問我怎麼畫出來的。答案是:以 PowerPoint 為工具一筆一線畫出來的。除了「逐筆逐線的苦工」,還會有其他答案嗎 :)

這些圖的確是 TASS 的驕傲,我滿懷欣慰。一張示意圖的完成,表示我對一個概念的徹底理解。把一個個概念化為一張張圖形,這件近乎藝術的工作永遠令我快樂。

然而這本書讓我又愛又怕。

愛的是,書裡頭的圖片,讓我在今天回憶某個資料結構或某個演算法於 STL 中的實作技術時,可以快速進入狀況;書裡頭的程式註解,亦讓我在今天想以 SGI STL 源碼為基礎做點自己的東西時(例如即將於2002/09發表的《 2002/09 池內春秋 memory pool 的設計哲學和無痛運用》),可以快速掌握關鍵。

怕的是,讀者寫來的勘誤與討論,每每極為深入。為融入本書所討論的這些複雜的資料結構和演算法的情境之中,我常得屏氣凝神,排除一切雜務。最近為驗證讀者寫來的 TASS 勘誤,花了三個整天,正務全部擱下。

說到勘誤,我要由衷感謝一直以來寫信給我挑我毛病的熱心讀者們。您們使我的作品有邁向卓越的機會。這次整理 TASS 勘誤表的過程中,我尤其有這種體會。在此我要特別感謝勘誤表中出現的幾位常客,您們的來信使我膽戰心驚,又使我溫暖無比。有時候我問自己,是什麼驅使讀者在熟讀一本繁複如斯的書之後,還願意花大量寶貴時間把其中的錯誤或疑問以工整的格式寫出來,甚至附上豐富的討論,寄給作者?每念及此,我真的感覺各位對我情誼深重。

過去很長一段時間裡,書籍勘誤非常麻煩,最主要的麻煩在於如何將勘誤訊息送到讀者手中。Internet 興起後,一切有了答案。現今任何一位成熟的讀者都應該知道,買了書要先上支援網站找勘誤表。現今任何一位成熟的作者也應該知道,書籍的勘誤不是售後服務,它是一種根本的負責態度。

大陸計算機書籍過去以來少有勘誤。經過了衝擊,經過了比較,現今讀者比較幸福,知道書籍該有勘誤。但是據我觀察,似乎衍生出一些誤會。有些書籍甫一出版,讀者便忙不迭地上網詢問「勘誤在哪兒」;有些讀者很熱心地臚列了一些勘誤,卻貼到網絡論壇上載浮載沉。這都不是適當的態度和作法。

1. 勘誤來自讀者。書剛出版哪有勘誤?勘誤是靠讀者找出來的(作者自己也可能找出一些,但數量相對極少)。

2. 勘誤應由作者(或譯者)親自維護。也只有作者(或譯者)才有能力維護勘誤(出版社能夠維護的,只是錯別字之類的勘誤,那是傷害性不大、很容易就被發現的非關鍵性錯誤)。勘誤必須集中一處;如果沒有一個長久的「官方網址」,那些載浮載沉、呈發散狀態、未經作者(譯者)驗證的勘誤,是沒有太大價值的。讀者看到書中疑點,應該發信給作者,不是發到論壇上你一言我一語。

3. 來自讀者的勘誤,是對作者的一種信賴。讀者要的絕不是勘誤表上的感謝(侯捷勘誤表上的感謝,值幾兩錢?),要的是作(譯)者和出版社慎重其事的態度。如果讀者發出的勘誤函,沒有受到重視,他們下次不會再做這種「浪費個人時間的蠢事」。作(譯)者和出版者,也就少了一群能夠幫助你(的作品)邁向卓越的卓越讀者。關於這一點,十年來我的感受非常深刻。每一封勘誤信(不論內容對誤與否),都是對我的一次信任投票。實際操作上我無法看到一個勘誤就急呼呼地把自己融到情境之中(尤其是難度較高的題目),總得稍微有個收集整理的時間(相信讀者能夠理解),但我永遠懸念在那上頭,永遠不會視如不見。

 

關於《Thinking in Java》2e 繁體中文版  
TIJ2 : Thinking in Java, 2e

這本1128頁大部頭書籍終於完成。我真的鬆了一口氣。

書籍出版後,在 BBS 論壇的 CoopBook 版和 Java 版引來很多討論。對於原文書本身和譯筆(技術和文字),我沒有聽到一句批評的話。但有很大一堆批評集中在兩點:(1) 版面的美觀 (2) 術語的用法。

1. 關於版面,我已經在譯序中明言,這次完全使用原書版式(我直接以 TIJ2 的 WORD 檔為基礎進行排版 — 任何讀者都可以從 Bruce Eckel 的網站上取得這個英文版檔案)。11號體比我慣用的 9.5號體的確大了不少。比起我以前的著譯作品,這版面的確比較擠一些。但我自己感覺還舒服。版式是個極為主觀的話題,我無意改變讀者的看法或說服讀者什麼。也許我應該高興 — 我的讀者對於我的書籍的版面已經非常習慣了,不能接受任何改變 :)

2. 關於術語。不少讀者提到,不喜歡我把 programming 說成「編程」,不喜歡我把 clone 譯為「克隆」。從而對我的這些譯詞衍生出奇怪的「動機論」、不忍卒睹的「保護論」、偏激的「敵我論」。我告訴各位,我選用大陸慣用的「編程」一詞,動機只有一個(one and only one):我認為它比「程式設計」好(註2)。但某些場合「編程」一詞太過僵硬不順,我會換為「程式編寫」。此外,我選用「編程」一詞已逾數年,並非始自今日 :)

註2: 如果programming 是程式設計,那麼 program design 是什麼?雖然無處不是設計,但 program design 通常指的是架構(architecture)上的大設計,programming 指的是細部實作上的小設計,兩者層次遠不相同 — 除非你說的是廣義的 programming。

兩岸術語,各有優點。我欣賞大陸的軟件、硬件、X 件、網絡(network)...,我欣賞臺灣的物件(object)、類別(class)、型別(type)、巨集(macro)...。有些術語深植人心,短時間難以撼動。但是依我的個性和我的理念,將來時機成熟(註3)的某一天,如果侯捷的繁體版書籍上出現「軟件」、「硬件」,侯捷的簡體版書籍上出現「物件」、「類別」,絕不奇怪。當然,鈔票在讀者手上,讀者有絕對的選擇權,而我一點也沒有勉強各位的意思 :)

註3:我無意在這種事上做逆勢之舉。我說的是「時機成熟的某一天」。

下面引 TIJ2 讀者來函數封,以及我的回覆:

★傳送日期: 2002年8月5日 AM 10:43
主旨: 關於 Thinking in Java 2/e 中文版

侯先生:

昨天在逛天瓏書局的時候,終於看到 Thinking in Java 2/e 中文版的上市,
二話不說,拿了就買.
侯先生的譯作或著作,向來具有高品質.
侯先生的人頭註冊商標,是一種品質保證.
回家後,隨即翻了幾頁,頓時有些失落.
侯先生的文筆依舊高水準,無話可說.
可是,頁面的排版,好生不習慣.
第一:不知是否是為了體恤讀者疲憊的眼睛,字太大了.字大是好事,可是,太大就有點奇怪.
第二:文字與書緣的寬度太小,這是由於字體大的關係,所以,寬度就顯得不足.

不知侯先生是否也有此感覺?

●侯捷回覆:謝謝您的意見。我和您有一樣的感覺。

然而如同我在譯序最後所言,本書的字型、版面、頁數,和原文書完全一樣,這的確和我慣用的 9.5 號字型不同。因此乍見之下的不習慣的確可以想像 :) 至於開本(大小)略小於一般國際開本,也是因為原書大小本就略小。我個人也覺得字型、版式、開本都值得再改善,不過這些東西在真正成書之前難有實際體會(小量試印數頁所得感覺和整本書呈現的感覺還是不同);成書之後卻又已無法更改。如於新的刷次中更改,會大幅增加成本,我實在不能(也無權力和立場)要求出版社這麼做,而且這些都是當初我點頭後才成書的,所以責任在我,不在出版社。(將來如果仍由我製作 TIJ3,我會改變版式,把字降低一號,把行距拉大一些,並採用國際開本)

我自己也長長久久經常要翻閱這本 TIJ2。我給自己的一個安慰是,此書厚達1128頁,份量繁重,字型大一點對眼睛有益 :)    老實說最近我就習慣多了。但願您不要認為這是我的推託之詞,這確實是我的感受 :)

感謝您時常寫信提供意見(我已經記住了您的名字 :)),有督促之功。好作者和好出版社,最需要您這樣的好讀者。


★傳送日期: 2002年8月6日 AM 01:37
主旨: clone!!
侯老師您好
嗯…不知道身為一個您翻譯書的愛好者有沒有資格這樣建議您,
就是,我覺得clone實在沒有必要翻譯,況且翻譯成”克隆”和使用原文並
沒有太大的差異.(一樣是外來語)誠如您所說,
簡單而且可以朗朗上口
讀者應該認識的原文
譯後可能失掉原味而無法完全彰顯原味者
那,您又何必翻譯clone?
我已經被您寵壞了,所以看到這個字,實在很礙眼 : )
感謝您的翻譯style,他讓我習慣原文!

●侯捷回覆:謝謝您的建議。主要是因為 clone在那數章中頻繁出現,不譯的話會出現大量的中英夾雜,版面上很難看。就像 "copy" 這個字如果不譯為「拷貝」(或「複製」或「副本」或「影印」),到處都出現英文,會被說話的。而且我儘量只保留英文名詞,不保留英文動詞

這中間很難作人。總有人不滿意 :)

以我個人經驗,當我看到異樣風格時,如果我無法改變它,而我又需要閱讀它,我便改變自己接受它。這是我勉勵自己的方式。或許給你參考。

也有讀者批評我將programming 譯為編程,以為有商業(大陸市場)考量。這是錯誤的推論。我的書的簡體版自有大陸技術編輯轉譯為大陸術語,繁體版售出到大陸的極少,絲毫不構成商業規模。我譯為「編程」,是因為我喜歡這樣的譯法,我認為比「程式設計」簡潔有力,意義又好。當然,讀者有權利表達任何看法。任何讀者意見都是寶貴的,我都非常感謝。

clone譯為「克隆」,其來有自,以下是網友 urd724 的補充:

會譯為克隆很可能譯者是星際大戰迷喔。clone war在舊版星際大戰(20年前的那一版)被翻成克隆戰爭。現在星際大戰二部曲裡被譯為 "複製人戰爭"。

此外我在 TIJ2 繁體版 xxxii頁有如下說明:

copy和clone在臺灣皆謂之「複製」。然而事實上兩者之間有所不同。clone, cloneable, cloneability且為一種Java技術概念。因此,為求區別,本書將copy譯為「複製」或「拷貝」,將clone譯為「克隆」(音譯,取乎「拷貝」之譯法。見p1018)。「克隆」在中國大陸是一個被普遍使用的詞。

TIJ2 繁體版 1018頁亦有如下說明:

譯註:clone和copy的意義都是「複製」。但它們的深層意義並不相同。為加以區分,我把clone譯為克隆。克隆之於clone,就像拷貝之於copy一樣,都是一種外來詞。雖然臺灣不流行說「克隆」,但是這個字眼在大陸是被普遍接受的。


★傳送日期: 2002年8月6日 PM 11:01
主旨: RE: clone!!
侯老師您好:
首先 謝謝您撥冗回答小子的疑問.
若是因為版面不得不譯,那我就只好接受了,因為這是出版社的考量.
另外,我不會因此,而放棄一本好書,畢竟,這只是習慣問題,並不會造
成閱讀上的障礙,祇是有想要追求完美的慾望而已 : )
最後,想跟侯老師告罪的是,由於BBS論壇上有討論到這本書,因
此,未經您首肯,我擅自將您的回信轉錄於板上,乞以原諒.


●侯捷回覆:你把我的回覆帖到BBS上,無妨,但最好事先知會我一聲。記名式的公開回覆,和私下回覆,畢竟在用詞上都需更加謹慎,這是我對自己的要求。你們都用 ID,誰也不識誰,我卻是連名帶姓,能不慎乎 :)

另外,如果你要公開,請將你的來信一併公開,我的回覆才有脈絡可尋。

> 若是因為版面不得不譯,那我就只好接受了,因為這是出版社的考量

這不是出版社的考量,這是我的決定。整本書從小到大全都是我的決定。也許讀者會發現,電子檔看起來滿舒服的,印出來卻有點擠。然而事實上電子檔和紙本書的版面完全相同。所以,我(以及出版社)和大家一樣,都是在製版打樣之後才感覺「似乎擠了點」(事前列印數頁的感覺和整本書的感覺是不一樣的),那時木已成舟。1128頁的製版成本是很大的數字,眳p已是很用心於高階書籍的少數出版社之一,我不能只因稍許美觀上的問題,就要求他們重新製版。

我自己的情況是,這幾天看下來,我已經頗為習慣這種字的大小和版面,並感覺它對眼睛帶來的壓力紓解。我並不(也從不)打算說服任何人購買我的書籍;購買與否完全在於個人的決定和鑑賞力。

讀者往往只挑剔,不道好。這是很正常的人性現象,我完全能夠理解,也不會有情緒反應 :) (我站在讀者立場時,也多半如此)。翻譯品質好不好,尤其是技術細微處的精準正確與否,還需細讀後才有體會,這裡也不說了。我要提醒各位,看看此書的印刷和紙張,非常精美。這些都是眳p的用心。臺灣計算機技術書籍出版,走到今天,由於市場大小的關係,愈走愈窄;眳p是很用心的一家出版業者,持續進步。大家若有心,或許不只看缺點,也看看優點並給予鼓勵。

印務以外的一切,都是我做的決定,所以責任都是我的 :)   建興是初譯者,有很大的貢獻,不過印務以外的一切都由侯捷拍板定案,一切風格都是侯捷主導的,所以所有責任都是侯捷的 :)

* * * * * * * * * * * * * * * * * *

在一長串的 TIJ2 中文版討論之中,唯一讓我情緒有些波動的,是一位網友對於我所加上的  xxxiii 頁「Java環境設定」的批評。他不滿意其中只提到 Windows 98 上的環境設定,沒有提到XP:

侯捷加的那一篇「Java環境設定」..
寫得很簡略..也只講了windows下的設定..
若是用XP的初學者可能也找不到那個DOS視窗去加上他的 jdk13.bat
覺得很不用心..

如果要寫..就要寫清楚..把各種常見的情形寫出來..
不然就乾脆不要..

這樣的讀者在七月酷暑中為我帶來陣陣寒意。首先,這是譯者譯作中為了體恤許多讀者連第一個Java程式都編譯不出來,而加上的一份環境設定說明,是「多出來的」,卻得到如此回應。其次,雖只三頁,該講的都講了,step by step,一點也不簡略。你提到「把各種常見的情況寫出來」,是不可能辦到的,也是我不願意去做的。一個學習 programming 的人,如果連舉一反三的意願都沒有,我還教你什麼?你缺乏舉一反三的能力沒關係,你可以拿著這樣一個 hint,找你週圍的朋友幫忙。書上給的是「在某個環境下完整的case」,你不在那環境下,那麼對你而言那是個 hint。誰能給你世上所有作業系統下的 Java 編譯環境設定?

後來一位網友的回應,讓我很有感觸:

這樣是不是太極端了呢?
人家願意花點時間寫出來,是讀者的福氣,
花時間整理的東西,還要被讀者講成這樣.
我聽一個作家朋友的朋友說,
讀者只要花幾百塊就可以侮辱作者,
難怪好的作家都消失了.

感觸頗深。但別擔心,侯捷不會消失。侯捷有鋼鐵般的意志 :)

還是那句話(蔣濤兄特別喜歡的一句):讀者有選擇作者的權利,作者卻沒有選擇讀者的機會

我但願有!

* * * * * * * * * * * * * * * * * *

william 非常熱心地在論壇上回覆了關於在 XP 環境下的設定動作,謝謝:

按滑鼠右鍵, 在 [內容/捷徑/目標] 欄內,
在 %SystemRoot%\system32\cmd.exe 字串後面加上批次檔參數即可。

譬如:

mingw: %SystemRoot%\system32\cmd.exe /k d:\bin\prog\mingw.bat
cygwin: %SystemRoot%\system32\cmd.exe /k d:\bin\prog\cygwin.bat
jdk13: %SystemRoot%\system32\cmd.exe /k d:\bin\prog\jdk1.3.1.bat
jdk14: %SystemRoot%\system32\cmd.exe /k d:\bin\prog\jdk1.4.0.bat

其他請依此類推。

看不懂 cmd.exe 命令列參數的話, 請 RTFM: cmd.exe /?

此外, 我建議下列的批次檔:

set PATH=c:\jdk1.3\bin;C:\WINDOWS;C:\WINDOWS\COMMAND

改成以下這種寫法: 

set PATH=c:\jdk1.3\bin;%PATH%

侯捷回應:我刻意不採用 %PATH% 寫法,為的是讓這個環境純淨一些。許多軟體安裝過程中會以這種寫法來「加設」它所需要的路徑。於是路徑可能會一長再長,最後超過環境變數的容許大小(我不知道現今作業系統對於環境變數的大小是否有所放寬,以前 Windows 95 時代只有 256 bytes)。我的這個環境只用於編譯 Java程式(我是這麼用它),所以無需附加原始路徑。其他編譯環境(VC, GCC, CB, Qt...)都另設有純淨的 console。

 

關於《C++標準程式庫》 
TCSL : The C++ Standard Library

很少有一本中譯書的整體(製作)觀感能夠勝過其英文兄弟。我以為這本就是。

到目前為止竟然沒有人寫勘誤信來。多麼不尋常的事呀,令我深感不安。究竟是(1) 本書的製作至這般嚴謹程度,或根本是 (2) 市場反應太差,沒人買?可這是每一位運用 C++ 標準程式庫(註4)的程式員的一本案頭必備工具呀。我告訴自己,一定是第一個原因。

註4誰如今寫 C++ 程式還沒開始運用 C++ 標準程式庫,請讓我知道,我一定推薦本書救贖他 :)


遠距教學、錄影教學

九月份我將為鴻海公司講課。這個案子頗有意思,我將在鴻海竹北廠對當地工程師以及廣東深圳的臺灣團隊和大陸團隊上課。這是我第一次嘗試遠距教學,很感新鮮。以鴻海的規模,我想一定是兩端拉有專線,以線上(online)會議的方式進行。如果頻寬足夠,兩端即時互動,那麼這樣的上課方式和面對面也沒什麼區別了。真正有無遠弗屆的感覺。

這讓我聯想到將來可能發展的訓練模式。大陸幅員廣大,兩岸隔著黑水溝,在在都需要遠距教學。即便在臺灣這麼小的島上,我都覺得頗有市場,畢竟沒人願意舟車勞頓去上課 :) 從高雄坐自強號(臺灣最高級的火車級別)到台北也得 4 小時呢。臺東到台北,呃,大概再加四小時(含轉車時間)。

此外,目前我在
凌陽開課,人資部門告訴我,有一種軟體,可將電腦上的一切動作,連同畫面並收音,記錄下來(或許還可以剪輯)。這麼一來,記錄下來的東西就是一份教學錄影帶。雖然老師沒有出現在畫面上,但重要的不是老師的人頭,而是電腦螢幕的畫面;只要老師經驗豐富,知道怎麼對螢幕講課(『現在我們看看左上角框框中的第二行...』或『現在我們看螢幕上端程式碼第5行...』),那麼老師的人頭出不出現其實無所謂。

說來這不算新聞,而且臺灣早有自行研發的優良產品。這東西足以讓我設計教學錄影帶了。教學錄影帶的用途很多,想聽課而沒機會的人,可以買一份來慢慢聽,慢慢揣摩課中的技術和老師的講解。有機會聽課的人,一樣可以買一份來慢慢聽,慢慢揣摩課中的技術和老師的講解。我們都有這樣的經驗,恨不得長出八隻手來做筆記;有了這東西,上課時就不必手忙腳亂,可以集中心力於課程內容的理解和思考(也就有從容發問的可能),而非集中心力「抄錄筆記」。

但是數位產品怕盜拷(密碼是不管用的,密碼一樣可以無遠弗屆)。因此這種東西如果要生存,就實際面而言,大約只能用於培訓業者的教育訓練中心內,大門不出,二門不邁;不出售,不開放,不流於市面。

目前臺灣有些培訓公司,招生作法是「一次繳費 / 多次上課」。臺灣培訓業基本上還停留在補習班層次,還沒有高階課程。高階培訓課程的老師難找,並且不易常態性、流水式的開課。因此這種「專用於培訓業者的教育訓練中心內」的教學錄影帶,便可取代常態性、流水式的開課,讓學員有「回娘家複習」的 n 次機會(n 由業者自定)。如有學員願意以這種方式學習,也可以以較低廉的價格上這種課,並且不必苦等高階課程的開班。

只要教案設計良好,教師經驗豐富,這種錄影教學的效果不亞於面對面教學,因為它可以讓你反複聽講、快轉、慢轉、隨心所欲。唯一的缺點是不能與老師互動,無法發問。可咱們學生在課堂上不都秉持 三不政策:「不講話,不回答,不要問我」嗎?「不能發問」的缺點似乎影響不大 :)

可能有人問侯捷,『你一向自許教育者,為什麼不讓你的教學錄影帶廣為流傳,卻想出這什麼鳥辦法』?是的,我以教育為職志,但我不是聖人(也不要當聖人)。就像電子書可以大幅降低紙質書成本一樣,錄影教學可以大幅降低上課成本(甚至提昇學習效果),可以解決很多問題(距離問題、學生經濟問題、學習遲緩問題)。但若要求 free,no way !!(註5

可能又有人這樣說:『沒人這樣問你,你幹嘛自問自答?自作多情』。是的,因為一定會有人那樣問,所以我先一步這樣答(要求侯捷多多開放免費電子書的信件非常不少)。我不喜歡一問一答、針鋒相對式的網路交流,我一向自問自答,把自己的思路和一切可能的 challenges 一次交待清楚 :)

註5過去以來收過不少信件要求開放上課講義。我從未答應,也未回覆。這兒一併作答。在我眼中,講義只是課程內容的1/2,另 1/2 是課堂上的引導。講義只是課程的一個半成品,我不願意半成品流出。很多熱心讀者想幫我校稿,或希望在書稿早期時間點先睹為快,我從未答應 — 一樣的道理。

 

關於合譯計劃

2001下半年,我開始規劃一些合譯書籍,有單獨繁體的,有單獨簡版的,也有繁簡並備的。書目和合作者都載於侯捷網站。目前大部份書籍都接近 50% 的完成量,有望於2002年底全部和大家見面。

我對合作者的選擇只有幾個原則:(1) 技術基礎要夠(先有技術,而後有技術文字)(2) 文筆尚可(我只要求初譯;任何文字最終都會被我修潤為侯捷風格)(3) 是我的讀者(對侯捷有基本認識,不必再費唇舌。你若對我沒有信服感,我如何領導你?)(4) 認真負責

夠條件的人當然非常非常多。目前合作的幾位,我要說,是我們有緣。

我對合譯的態度和作法,一直以來就像這樣(以下摘自1999出版的《泛型程式設計與STL》譯序):

一般所謂合譯是「你譯一半,我譯一半,兩不相干」,這是我最詬病的一種方式。本書由俊堯完成全部初稿,再由我完成全部的技術檢閱與文字修潤。

從來沒想到,居然有人認為這不叫作「合譯」。當我看到大陸論壇對於愛民的《C++ Primer》(簡體中文版,合譯)口誅筆伐的瘋狂狀態,真真讓我瞠目結舌,嘖嘖稱奇。許多讀者對兩位譯者之間的分工,興趣似乎大過對書籍本身。很多人似乎以為敲下一個字又一個字,才有資格稱譯者。最近我在臺灣論壇上也看到對 TIJ2 有類似的討論。

嗨,不是這樣的,你們各位。請看看《梓人傳》。你認為你住的房子是砌牆砌磚的人蓋的嗎?如果你一定要說是,那就是吧,他們也有貢獻。但難道你認為你的房子不是總設計師、總建築師蓋的嗎?你不會這麼認為,是吧。

傳統以來大家把「尸位素餐、等因奉此、敷衍了事」想成了「檢閱、修潤」的同義詞,所以對於「檢閱、修潤」工作有了誤會(這和做這些事、掛這些名的人長久以來的工作態度分不開關係)。我不知道別人的情況怎麼樣,在我,每一本合作書籍的每一個字都在我的檢核、修潤、掌控之下。是的,這種合作書籍的第一遍初譯的每一個字都不是我敲下產出的,但是讀者能夠指出的任何一個細節(除了印務,以及我授權給編輯的可能微小修改),都是我做的最後決定,都是我的風格,都是我的責任。

在這種情況下,任何人想剝奪我的譯者地位,我可不允 :)

這和責任編輯、技術編輯、檢閱者,有什麼不同?不同的地方很大。責任編輯、技術編輯、檢閱者只能站在建議的立場(註6),主權、風格確定權、技術核定權都在作譯者身上。而我,以上所說的我,做為(合)譯者的我,就是風格確立者,就是技術核定者,就是最終定案人。

註6是有那種以己意志強加書稿身上,忘記自己職責(或可說過份強調自己職責)的編輯。臺灣早期就有這麼一位出版人,作譯者拿到和他合作的書之後才發現,呀,怎麼少了這一段,怎麼多了那一段,文字風格怎麼變了。那家公司經營不到兩三年,倒閉了。

一直不願多談這個,因為如果講得不夠清楚,會傷害合作者的心,以為我把他們視為砌牆砌磚者。嗨,小子們,經過長時間的相處,你們知道我不是那樣,我對你們是有所寄望有所期許的。所以現在我寫下這些話。除了教導那些奇怪的心靈以一些道理,也希望你們有一天都成為總設計師,總建築師,總工程師。

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

 


傳送日期: 2002年8月22日 AM 10:49
見信好﹐

你認為你住的房子是砌牆砌磚的人蓋的嗎?如果你一定要說是,那就是吧,他們也有貢獻。但難道你認為你的房子不是總設計師、總建築師蓋的嗎?你不會這麼認為,是吧。

這是侯sir關於“合譯”問題中的一段評論﹐但是我覺得此言差矣。因為我從不會關心我住的房子是誰砌的﹐也不在乎是誰設計的。而房子的開發商是誰﹐開發商的信譽如何﹐售後維護又到底如何才是我關心的。相信侯sir買房的時候也不會太在意房子究竟是誰設計的﹐事實上普通住宅的設計人是誰往往也沒什麼差別。當然﹐侯sir出身土木工程﹐可能會關心設計者:)

所以說對於普通住宅﹐我只會在乎開發商。而對於一本書﹐我最關心的卻是作者是誰﹐至於出版社是哪一家﹐也會考慮一些﹐但絕對不會起決定性的作用。也正因此大家才會認定侯sir﹐而不會在乎是華中還是機工出版TIJ。

至於各譯一半的方式﹐自然是毛病多多。但是侯sir的two pass方式似乎也有不盡如人意之處。首先侯sir在其中起的作用與一個Consulting Editor就很難區分﹐而editor和作者之間的差別是不言而喻的。再者出版社往往借重的也是侯sir的大名﹐至少在各網絡書城的關於TIJ介紹中﹐鮮見關於另一譯者的報導﹐甚至在作者一欄中也常常僅見“侯捷”二字。所以許多讀者會對此產生不滿。

歸根結底大家還是對合譯的另一方不放心﹐我想這也很正常﹐特別是當兩個合譯者的信譽資歷差的太多的時候﹐更容易引起人們對掛x頭賣x肉的猜忌。two pass的合譯方式只有在合譯人是同一數量級的情況下﹐才能為讀者信服。

●侯捷回覆:

謝謝來信,您的每一個問題在我的原文中皆可找到我的答覆。

不論我挑選了誰做為合譯者,掛上侯捷名字的東西,品質就和「全部由侯捷一個字一個字敲出來」完全一樣,因為我會一個字一個字看,一個字一個字改潤,一個技術一個技術地檢核。我就是最後定案人。如果合譯的某些地方有誤,那麼侯捷獨譯結果也會是那樣。採用合譯方式,是為了加快產出速度(另一個因素是希望培養寫譯人才,但那陳義過高,對一般讀者也無甚意義,就不提了)。

讀者可以說「這譯本經過合譯模式之後,品質降低了,我決定以後不要再買這樣的書」,但不應該說「某某某沒有資格掛譯者之名」:)

-- the end