MJOS勘誤表

MJOS出版了，拿到譯者贈書。這本校得不夠，不順的地方就算了，只是錯誤不能不抓。

• 59頁2段6行尾起: 「賓州大學」=> 「杜克大學」
• 88頁到數2段３行：履歷上更加醒目

另外編輯一直把「不過」後面加逗號，愈看愈不爽。

近譯兩篇

不知道在誰那裡看到在台灣產生矽谷的可能，想到之前在Paul Graham那裡看到的文章，順手譯了兩篇。已通知原作加入連結，但不知何時才會加上。

譯：新創公司何以在美國凝結集中

新創公司何以在美國凝結集中 Why Startups Condense in America
原作：Paul Graham
譯：Paul May

（本文源於一場在Xtech的演講。）

新創公司有群聚效應。矽谷和波士頓有很多新創公司，在芝加哥或邁阿密則很少。想要新創公司的國家，或許也必須複製這種群聚形成的原因。

我之前聲稱矽谷的秘方在於一所偉大的大學，以及受聰明人喜愛的鄰近城鎮。如果你美國境內安排好這些條件，新創公司將會自然而然地成形，就像凝結在低溫金屬片的水滴一般。不過當我考慮要如何才能在其他國家重現矽谷時，才發現美國顯然是個特別潮濕的環境。在這裡新創公司更容易凝結。

這絕不表示想在其他國家建立矽谷註定失敗。絕對有機會與矽谷抗衡甚至超越。不過如果想達成這個目標，就必須了解在美國創業的優勢。

譯：如何成為矽谷

如何成為矽谷 How to be Silicon Valley
原作：Paul Graham
譯：Paul May

（本文源於Xtech的一場演講。）
你能在其他地方複製矽谷嗎？或者說矽谷有何獨異之處呢？

在其他國家難以複製矽谷並不足為奇，畢竟在美國大多數區域也做不到。究竟需要什麼才會讓矽谷在這裡誕生呢？

它需要有對的人。如果你能讓那正確的一萬人離開矽谷搬到布法羅，布法羅就會成為矽谷。[1]

這與過去的經驗差異甚大。一直到數十年前，都是由地理位置決定城市的命運。所有大城市都接近水道，因為城市靠貿易賺錢，而水路是運送物資唯一經濟的方法。

現在只要能讓對的人搬進來，就可以在任何地方建立一個偉大的城市。所以創造矽谷就轉變成另一個問題：誰是對的人？要如何讓他們遷入？

「程式員」或「程式設計人員」

有點囉嗦了，另開一篇：

# 4/26：收到公關書了，去他他的，把「程式員」全域換成「程式設計人員」了。混蛋...寫了一封信給編輯：

...
我必須說, 我對你們把[程式員]全部替換成[程式設計人員]非常不滿.
我想你們表達的意思我很明白了, 的確是你們要怎麼改, 我是沒辦法的.

More JS就照這個原則吧, 我也不需要這麼用力.

# 編輯回信：

...
關於「程式設計人員」的翻譯，我們各有立場，
我也詢問過一些電腦工程師，關於這個名詞，他們也大多會說「程式設計」或是「程式設計師」
但是他們還是覺得乾脆就直接叫「Programer」.....

# 4/27：我火了，再回信：

你是找[其他電腦工程師]翻譯, 還是找我翻譯呢?
既然他們說是[程式設計], 那怎麼不把所有[程式員]都代換成[程式設計]呢?

我知道結果不會有變, 既然第一本用了這個詞, 第二本也只能照用. 但是我覺得非常不受尊重, 我想找你們總編抗議. 看要怎麼處理.

# 編輯回信約時間討論，今天上班前談了半個小時。
我提出若出版社執意要用程式設計人員，希望在第一次出現時加譯註，表達譯者不同的意見。總編不希望把這種懸而未決的結果呈現出來，想要再找大家都能接受的用語。但是在我堅持之下，下一本應該會用我所希望的「程式員」。

本來並不覺得這兩個詞有太大的差異，這幾天想想加上和廖討論，發現這樣一改，其實很多味道都跑掉了，覺得傷害很大。六個字實在太長了，而且感覺起來像通稱，用來指稱特定人時怪怪的。跟編輯討論時，拿「好程式員還有壞程式員」作例子，換成「好的程式設計人員和壞的程式設計人員」時，一口氣都快唸不完了。

不管如何，嚕了這幾天，總算有個可以接受的結果。
=== end ===

重譯心得

四年前不上班時曾經想過順便找出版社，還找到Apress的email去聯絡，回覆譯者版權已經賣出，我只把當整件事就此結束，繼續慢譯。

沒想到機緣巧合，這幾年過去還是實現了。

翻譯依然很有趣，不過還是有點辛苦，而且出版社條件愈來愈糟，公關書兩本，感覺字數也有點取整數，不過由於太多數早已譯好，也不想多說什麼。這次照編輯的建議一次付請，不領版稅。

網路上的翻譯計畫很多人熱心參與，不過我都是以當初自留的譯稿為起點，麻煩點但希望爭議也少一點。

副標也順便譯了，不過應該不會用：

And on Diverse and Occasionally Related Matters That Will Prove of Interest to Software Developers, Designers, and Managers, and to Those Who, Whether by Good Fortune or Ill Luck, Work with Them in Some Capacity

軟體開發者、設計者與經理，以及那些幸或不幸與其共事者會感興趣的雜論與時事。

處理到一半時廖逛到對岸譯者的網站，幫助很大。只是當看到有人引經據典，我就不行了。像這一位先生的站起初也有訂閱，想看看能不能得到些什麼，看了幾篇後就放棄了。這純粹是我個人的障礙，倒也不是其他人的問題。

跟編輯的來往也挺有趣：

• 對方對這些大概不熟吧，提到譯名必參考微軟的譯名標準。我去他他的微軟譯名標準，常用的也就算了，不常用的也還不是亂編一通。
• 譯文中全部都用全型括號，包住中文的還算正常，包住英文的全型括號真是醜。
• 「當掉」老是改成「當機」
• Programmer我譯成「程式員」（洗老師的遺毒嗎），編輯一直想要改成「程式師」或「程式設計人員」，被我半翻臉的拒絕了，不知道後來有沒有亂改。廖說喜歡「程式工」，不過這個詞另有用處，平常譯文裡還是用中性點的較好。
• 老是愛在「不過」、「其實」、「那麼」後面加逗號，我懷疑是為了灌水湊頁數。
• 跟「不可能」有仇, 一定要改成「無法」；和「等等」也有仇, 一定要拿掉一個；和「不過」也有過節, 老是改成「但」。
• 覺得「錯」太孤單, 一定要把[誤]抓來作陪。可以我覺得「錯」字其實比較喜歡自己獨處, 要配也要找「亂」來配啊
• 大概收了「範」的好處, 一定要拆散「例」和「子」, 好讓「範」上了「例」
• 廖：編輯會問「推導」是什麼意思 (難道她以為是推倒嗎?）
• 編輯有些遣詞用字很古典，可是竟然看到「提示」被改成「謎之音」，害我噗一聲當場笑出來了

接下來這件事也有點扯：對岸的雜誌要轉載某一篇，大概要取得譯者同意吧。編輯就表示「因為稿費不多，可否以出刊的雜誌來代替呢?」我就很不客氣的回答說，數字再少也應該讓我知道再決定。結果其實根本沒有稿費，早說嘛。或許編輯自有想法，不過令我更不信任出版社了。

結論呢? 就是編輯一定覺得我很嚕。

其實我覺得原作更嚕，譯他的東西挺痛苦的，每次想到那句Up the tata without a tutu就覺得怒。

這次翻譯和以往有些不同：

• 多了一點歷練之後，某些文字處理起來就比以往好一些。
• 網路資料愈來愈豐富，如果沒有wikipedia大概是翻不下去的。
• google譯者工具包是個好東西，雖然譯得很爛，幾乎每一句都是重譯，但是至少可以當字典用。而且更好笑的是，偶而看到某一段自動翻譯的結果非常好，自己覺得無法譯得更好，最後卻發現原來google參考到以前的譯文了...
• 不過前一檔上班前真的很用力在翻譯，有幾篇我覺得這次沒有翻得比較好。

=== end ===

譯者自介

編輯要譯者簡介，就生出這篇文章，既然註定會被亂改，就放在這裡吧...

機械系畢業，勉強混到在職資工碩士。在Windows平台上寫過一點應用程式，碰過一點點的驅動程式。曾與遊戲開發擦身而過，目前從事韌體工作。

很多年前初次看到JT這篇文章，當時興奮得想馬上轉給同事，只是考慮到各人的英文能力就作罷了。幾天下來還是捨不得，於是憑藉著幾年來兼職的一點點基礎，鼓起勇氣寫信給JS請求翻譯許可。JS很爽快地答應了，由於有很多梗看不懂，還陸續問了幾個問題，也都一一回答，我想當時JS比較有空吧。現在信件都已遺失，但是對照日期算算，或許自己是最初的譯者之一，不過這也沒什麼就是了。

譯稿起初放在公司內部的NT server，2005年JS在網站上開了一個專區(http...)，就把譯文陸續寄給他的助理(!)整理。或許因為維護太花工夫，後來JS就架設了一個譯者專用的WIKI，也就是現在的http...。2006年初沒有上班，定了一個小小目標要把紙本書的文章譯完，結果也真完成了。後來上班工作纏身，就完全忘了這檔事，偶而想到才會上去替其他人校對。收到XX文化的詢問其實相當驚訝，多年前結下的因緣竟然變成白紙黑字，腦海裡不禁想到某人在史丹佛演講的內容。

其實翻譯JS的文章常會讓我有點難過。並不是說他寫得不好，而是我個人感受到理想和現實間的差距太大，這麼多年了，所屬團隊的JT分數還不到八或九分，而這還是因為有送分題呢。

有位朋友說，JS的觀點當初的確令人耳目一新，但這些年來整個環境已經改變許多。這點我也同意，畢竟很多觀念一直在進步，其實JS本人也是一樣的。但是軟體界如此廣大，總是不斷會有人從中獲得啟發，希望讀者也能有所收獲。

=== end ===

翻譯

昨晚一時興起又去譯了半篇文章，邊做邊覺得自己還是挺喜歡翻譯的。

喜歡解譯另一種語文時的解謎感覺，喜歡看不懂或不確定時找資料找答案的過程，也喜歡寫成中文時反覆讀出順句的過程。這其實和寫程式也挺像的，如果是由神秘難解的規格開始的話。

那翻譯的過程中討厭些什麼呢？

討厭那重重疊疊的子句，怎麼翻都翻不通順。討厭自己看錯翻錯，更討厭的對文中所述不甚贊同，不想譯出還是得逐句寫下，彷彿違背自身意願般的。

如果是校稿的話，最討厭的當然是那種亂亂譯的句子。不過改正之後還是會因為小小的優越感而帶來小小的喜悅。
=== end ===

翻譯

最近其實很多東西想寫，偏偏就是沒有動手。是因為時間不夠嗎？是挺忙的，但還是應該騰得出空才對，主要原因還是對自己的時間掌握不佳。另外或許是姿勢不良或是使用過度，右手有酸麻的情形出現。靠電腦過活又習慣飛快打字，萬一要改用兩指神功，大概會生不如死吧，因此心中是很害怕的。不過想寫的還是要寫，只能多注意不要濫用，下星期找個時間去看看醫生吧。

自己真的很奇怪，坐在電腦前閒下來時就只會到處亂逛，不太能定下來寫想要寫的東西。而當人在外頭閒等，手上沒電腦可用時，東想西想後就會拿出筆記本用筆打草稿。目前為止較長或較完整的文字，大多都是這樣來的。或許電腦對我來說比較接近玩具或是殺時間工具吧。

雖然我自己的Joel on Software翻譯已告一段落，還是有其他人繼續在進行，而且有熱心人試譯並徵求志願者校稿。

既然有人翻好了，校稿相對上應該是輕鬆許多的，於是就趁前幾天的空檔進行。本來以為一個小時就能完成，結果卻用了四倍時間才搞定，不過還是比自己從頭翻譯輕鬆多了。做完再次體認到翻譯真是個需要耐心的工作，而且還要有像我這種處女座機車的特質。我把人家的譯稿改得面目全非，很怕傷害人家自尊心，但是明明譯錯的內容卻怎麼也不能放著不管。

有些人翻譯像翻譯機，結果看中文像看英文，倒裝、被動、子句樣樣都保留。這當然不好但卻不是最可怕的。一來我們現在的語句結構早已被英語文法影響，英文式中文雖不順暢但還有點熟悉。另外很多讀者在看這種譯文時，會很自然的轉換出英文原句加以理解。

比較可怕的是中文句子頗為通順，偏偏一路讀下來就是搞不懂。這表示你遇到了一位中文文字能力尚可，專業技能零分的譯者。他很可能用翻譯機翻一遍，然後運用尚可的中文能力把句子弄通順。看不懂內容？「我們本來就不懂這個東西！真正需要讀這種書的專業人士自然會懂的」。我看即使原作者懂中文，恐怕還是看不懂的。

這還不是最可怕的，我認為真正可怕的譯者是中文還不錯，技術也懂一點(比如會組裝PC，能在雜誌上寫顯示卡評比)。這種譯者會把文句順過後發現自己看不懂，於是就他的知識推敲出似乎合理的解釋。因為技術也懂一點，完全不會去google驗證一下。於是你得到一篇文句通暢又看得懂的東西，只是內容與原文完全不同。有時候因為子句結構看不懂，還會有意思完全相反的情況。

上次有這種感覺是好幾年前，當時替某本DirectX程式設計的書校稿。校了幾章就受不了，趕快請編輯聯絡譯者，然後很機車地教訓了人家一個多小時。現在回想起來實在有點後悔，或許當初看到前幾頁就該硬著頭皮跟編輯說我做不來，別人愛隨便翻是他自己的事。不過或許是處女座A型的缺陷吧，有的事會放過，但是當這種情況送到面前實在忍不住。

替別人校稿常發現這種問題，不禁擔心起自己的作品。其實我難免也會有這種情形，偶而發現就不禁汗顏。把原文和譯文對照重看一次並不困難，但是自己看是很難發現問題的。我相信這就像寫程式需要額外的測試人員一樣，因為自己就是會有盲點，就是不容易看出某些東西。由譯者和專業讀者組成的支援團體，再配合能原文譯文並呈方便校對的對照工具，或許是個可能的答案。

兩篇翻譯

翻譯了Paul Graham的兩篇文章：「創業的點子」和「不平等與風險」。

不過我還是沒有想要創業。
=== 本文結束 ===

Joel on Software譯稿：四個短篇

其實快翻完了，還剩下三長一短四篇文章。

五個世界 - Five Worlds
紙上原型製作 - Paper Prototyping
別讓架構太空人嚇到你 - Don't Let Architecture Astronauts Scare You
工匠技藝 - Craftsmanship

Joel on Software譯稿：絕不妥協的抓蟲行動

譯稿和原文

Joel on Software譯稿： 每日編譯(Daily Build)是你的好朋友

原本的範本文章區域太窄了，造成篇幅太長閱讀起來不方便，換了一個可能好一點的。
譯稿和原文
這個標題聽起來蠻像女性生理用品廣告的...

請幫我初校

最近都在翻譯，翻到人都暈了。
前面的都送出去了，麻煩各位就當逛網路幫我看看吧。
Unicode
這是原文。
我自己會再看，各位看到有錯也請告訴我。

翻譯

短期計劃裡最容易做的就是翻譯Joel on Software。

原本拿到錯誤的資料，以為要翻一百多篇。翻了四篇之後找到正確的目錄，才發現其實只要翻四十幾篇。不過份量上大概沒有差很多，因為能選進書裡的大都是較長的文章。

很久沒翻所以效率很差，一天好像翻不到一篇。這樣恐怕要兩三個月才能搞定吧。

發現我其實蠻喜歡翻譯的，看到不懂的東西可以去google查查知道些新玩意，看到搞不懂的長句子時仔細推敲好像在玩推理，整理文字調整句子好像在堆積木。不過翻譯是苦功，又難養家活口，當做善事吧。