『質量』很好, 到底是質好還是量多

很多與我一樣的 5 年級生會不習慣對岸的用詞, 這倒不一定是對岸的用詞一定不好, 而是有些詞用起來就是很混淆。舉例來說, 『質量』一詞就很怪, 因為『質』與『量』是兩件事, 但是對岸口語上講的『質量』通常是指『質』, 例如, 『A 選手這一球質量很高, B 選手雖然接到了球卻無法回擊』, 不如就直接講『A 選手這一球力道很強』。『質』『量』不分, 實在很有問題。

被誤解的亞里斯多德--爛翻譯的可怕

之前看到這一篇文章《提倡寫故事，貝佐斯禁止開會用PPT》時, 只覺得這是一篇誤會 PowerPoint 的文章, 你的投影片上只有條列項目, 當然效果差。不過今天老婆看到同一篇文章, 問我文章裡面提到亞里斯多德說：

有說服力的論據必須有效的3個要素，分別為精神、標誌和悲觀情緒

是什麼意思？一看直覺就是這一定是譯者亂翻, 找到原來的文章 Jeff Bezos Banned PowerPoint in Meetings. His Replacement Is Brilliant一看, 原來這三個要素是 "ethos, logos, and pathos.", 我會翻譯為『中心思想、邏輯與感染力』, 譯者顯然把 "logos" 當成 "logo+s", 所以翻成『標誌』, 也把 "pathos" 隨便查字典就譯為『悲觀情緒』, 完全不顧邏輯性, 真的是用自己的翻譯打臉自己的譯文。

附記：數位時代的文章是從科技新報而來, 但顯然沒有人審稿。

callback 到底應該怎麼翻？

由於現在越來越多程式語言或是框架 (framework) 強調非同步技術, 使得 callback 躍登熱門詞彙, 不過這個詞倒底要怎麼翻成中文, 可有點傷腦筋。過去有的人不翻, 有的翻為「回呼函數」, 這我個人認為無法達意；我也看過有作者翻成「回撥函數」, 這取材自回撥電話的意思 , 意思是到了, 但是在程式設計的語句中唸起來就是怪怪的。前幾天讀何孟翰先生寫的《超強圖解 前進 App Store!iOS6 SDK 實戰演練》一書, 他譯為「回應函數」, 我覺得真不錯, 既能達意, 夾在文句中唸起來也不會繞口, 趕緊記下來, 往後就用這個說法。

詞辨：constant 與 literal

閱讀原文書時, 常會被 literal 這個詞搞混, 其實 literal 的意思很簡單, 就是將某個值使用文字直接表示出來, 這段文字就稱為 literal。舉例來說, 如果有這一行程式：

int a = 20;

這個 "20" 就稱為是一個 literal, 也就是在程式中直接用文字描述 20 這個值, 因為如此, 我會建議將 literal 譯為「字面值」, 取其從字面就可以得知資料值之意。

有些中文書會把 literal 稱為「常數」, 這基本上就誤會了兩個詞彙的意思。constant 指的是某個東西具有不變的值, 例如圓週率, 大家都知道的它的值是固定不變的, 這時候我們會說「圓週率是一個常數, 它的值是 3.14159.......」。在程式語言中, 常數 (constant) 就是指一個具名但內容不會變動的資料, 例如：

const int pi = 3.1415976;

這時我們說 pi 是個常數, 它的值為 3.1415976, 而非 3.1415976 是個常數。這就像是以下這段程式：

int a = 30;

你會說 a 是一個變數, 而不是 30 是個變數。

詞辨：parameter 與 argument

閱讀程式設計的文章時, 常會看到 parameter 與 argument 兩個詞, 在中文中可能都會被翻譯為「參數」或是「引數」, 不過這兩個詞嚴格來說, 是有不同的意義的。追本溯源, 這兩個詞來源自數學中的函數, parameter 指的是在定義函數時給定的變數, 而 argument 指的是使用該函數時實際傳遞給函數的資料。轉換到程式設計中也是一樣, 假設有個 foo 函數, 定義如下：

void foo(int n)
{
    .....
}

那麼 n 就是 parameter, 而在呼叫此函數時, 可能是這樣：

foo(20)

或是

foo(x)

此時 20 或是 x 就是 argument。

在某些程式語言中, 也會把 parameter 稱為 formal parameter, 而將 argument 稱為 actual parameter, 前者表示只是形式上的參數, 告訴程式呼叫此函數時, 需要傳入的資料個數與型別, 而後者表示實際上傳給函數的資料。如果要中文化, 這還真是難倒我了, 但若是 formal parameter 譯為「形式參數 」、actual parameter 譯為「實際參數」, 倒還可以, 但要想兩個詞彙分辨 parameter 與 argument , 還真是有點難啊！目前較通用的翻譯是 parameter 為「參數」、argument 為「引數」, 姑且可以看成「參考格式」、「實際引用」的意思吧。

[英文]does what it says on the tin

今天讀 The Rough Guide to Men's Health 一書簡介時，讀到了這一段：

The fifth section, Reference,pretty much does what it says on the tin.

其中 "does what it says on the tin" 大概可以猜出意思，但很好奇這句話是怎麼來的？後來在Wiki上看到，原來這句話是源自於英國某個產品的電視廣告，強調其產品內容、時效完全就如同其錫罐上的文案，童叟無欺，演變到後來，即便這家公司的產品不一定採用錫罐為容器，也都一樣在廣告上套用這句話，而因為這個廣告太出名了，甚至變成了一般人的常用句，表示真實內容就如同文字一樣，沒有用文字誇大不實之處。

[英文]ride off into the sunset

在閱讀 Building iPhone Apps with HTML, CSS, and JavaScript 這本書的前言時，作者提到他看到 App Store 時，想到他之前已經寫了一堆 iPhone 上的 web 應用，所以認為：

Some of my web apps were already somewhat popular, and I figured I’d just rewrite them as native apps, put them in the App Store, and ride off into the sunset on a big, galloping pile of money.

這裡頭的 "ride off into the sunset" 本來一直搞不懂文意，後來看了《CNN新聞關鍵用語：英語詞彙語用策略實例》一書〈典故〉篇，原來這句話是從西部電影來的，西部電影通常結尾都是主角騎著馬在落日餘暉下遠去，所以 "ride off into the sunset" 就演變成形容退場、結束的意思了，因此之前提到的那一整段就是說：

我寫的web應用中有些已經很紅了，所以我發現只要重新寫成原生應用，上架到 App Store，就可以海賺一票離開了！

看來，英文還是得加強啊！

日文中H18.2.1原來是指平成18年2月1日

跟譯者討論日文書內容時，遇到一個和日期有關的「H18.2.1」，討論了半天猜不出來，還是請出Google大神來，輸入「H18.2.1」，只跑出一條檢索結果：


照著連過去後，咦，怎麼找不到「H18.2.1」？

這一頁剛好也只有一篇文章，看到日期欄2006/2/1，就想會不會原來H18.2.1就是2006/1/1？再請出Google大神，找一下日本年號，果然，平成是從1989年開始的，若H18是指平成18年的話，那換算過來就是2006年了。

還好是網路世界，不然這難題要去哪裡問啊！

翻譯名詞：render

render這個名詞在程式設計的原文書中很常出現，本來我一直想這個詞要怎麼譯才會達意，剛好譯者劉祖亮先生在翻譯《Essential WPF》一書時提供了一個好的譯法：演算上色（我不確定是否有其他地方已經這樣翻譯），覺得非常恰當，因為render通常只的並非一般的上色，而是要先經過依據特定的規則運算，來決定某一個位置的顏色，然後在將該顏色繪製到該位置上，譯為「演算上色」既簡單又明白。

日文翻譯的陷阱

日文因為使用了大量的漢字，所以對於我們來說，有了幾分的親切感。不過也正因為如此，埋藏了許多陷阱，有時候不知道對應的適當中文詞彙時，很可能就會直接用日文漢字草率了事，但實際上中文讀者看到了這個由漢字組成的詞彙時，卻無法從漢字聯想到真正的意思。我自己不懂日文，以下斗膽舉例，如有謬誤，還請指導。

有些詞彙雖然和中文不同，但還可以猜出意思的，例如「16進制」，中文通常說「16進位」。但有些詞彙單看日文，就比較難猜出意思。比方說，在CSS的書籍中，會出現「段組レイアウト」。「レイアウト」是外來語layout的日語拼音，在CSS中自然指的是版面設計，那麼「段組」是什麼呢？「段」是colunm的意思，「組」就是排版，整個「段組レイアウト」指的就是多欄版面設計。如果直接用日語譯為「段組版面」，大概就很難讀懂意思了。

當然，有些詞彙因為崇日風尚，大家習以為常，也就懂意思了。像是濫用程度最高的「達人」、「殘念」、「萌」等等，雖然如此，使用上我認為還是有斟酌之處，因為許多詞彙我們未必真的理解日文精確的含意，比方說「達人」和「玄人」是有差異的，如果人人皆稱「達人」，可就怪了，哪有那麼多「達人」？

最可怕的是那些讀起來好像完全正確，但其實意思錯誤的日文漢字，譬如說日文中橫的稱為「行」、直的稱為「列」，與中文的直行橫列相反，如果翻譯時不細心，直接照用，那就麻煩了。這特別是在資料庫或是Excel等大量出現表格的文章時最為嚴重。

你可以說我古板、或者民族情結作祟，我很不喜歡中日文夾雜，用在書名一兩個字勉強也就罷了，如果內文行文之間，充斥日文詞彙，我總是覺得渾身不舒服，讀起來腦筋不斷打結。當然，我不排除也許有些詞彙日文其實是真正保留了中國古文，而我們現代的用法才是瞎搞，這就很難說了。

詞辨：type selector與class selector

type selector與class selector也是很容易因為翻譯之後而弄混的兩個詞，有些人不知不覺中就把這兩個詞都翻譯為「類別選擇器」，使得文章讀來意思完全混淆。

若是依照這兩個詞的原意，type selector是依據HTML標籤（tag）種類來選擇要套用樣式的元素、而class selector是依據class屬性值來選擇要套用樣式的元素，其中HTML標籤可以當成是元素的資料型別（type），因此我個人建議type selector可以譯為「型別選擇器」，而class selector就譯為「類別選擇器」。

當然，您可能會覺得型別和類別不是也容易混淆？但首先，使用兩個不同的詞彙，至少在同一篇文章中可以明確表示這是兩個不同的東西。其次，如果以人來比例，你可以用膚色來分類，也可以依據個性來分類，因此「型別」就可比擬為「膚色」，而「類別」則可比擬為「個性」。所以每一個人只會屬於某一種膚色，但卻可以歸屬於多種個性，就如同頁面上的某個元素只會屬於某一種標籤型別，但卻可能歸屬於多種類別一樣。

合約到期的注意事項

在之前的文章（圖解最後一刷後半版稅計算法）中曾經提到合約到期時的議定處理方式對於作者或是譯者的版稅收入有影響，一般的作法會在合約到期前另外簽訂一份終止合約書，載明合約到期時各項處理事務。今天朋友在整理文件的時候，剛好看到某出版商一份大約七年前的終止合約書，上面有一條條文很有意思，特列列出來給大家參考：

...
三、滯銷書之販售：乙方（指作者）同意甲方（指出版商）得繼續販售本著作物至完全售完為止；惟該剩餘未販售之滯銷書版稅歸甲方所有。
...

簡單的來說，意思就是合約到期後，剩下來所有的書都可以繼續賣，而且不用給作者版稅。這個條款有幾個問題：

• 此份合約並未載明剩餘書的數量。
• 通常這種不付版稅的銷售應該是折價出售的商品，求的只是回本，但此份合約也沒有對於售價有任何限定。
• 如果以小人之心度君子之腹，若是這本書是長銷書，那麼合約到期前再多印一些，甚至到期後還偷印，又不用給版稅，豈不是太棒了？

詞辨：child selector / descendant selector

在CSS中，child selector與descendant selector在翻譯的時候很容易弄混，許多人會把descendant selector翻譯為「子」選擇器，這就和child selector混在一起了。如果從原意來看，child是選擇指定元素的直接子元素，而descendant selector則是包含了指定元素的子元素、子元素的子元素、....，比如說：

div > p {...}

就是child selector，會將後面的CSS樣式套用在直接包含在div內的p元素上，div與p之間不能夾有其他層的元素。也就是說，只會套用在像是<div><p>...</p></div>這樣的p上。但如果寫成這樣：

div p {...}

就變成是descendant selector，會將後面的CSS樣式套用在所有包含在div內的p元素上，不論p元素與div之間有沒有夾著其他層的元素。也就是說，即便是<div><span><p>...</p></span></div>這樣中間夾了一層span，樣式也會套用到最裡頭的P上。

因此，在翻譯時我比較建議要將這中間的差別區分出來，最簡單的方法就是將child selector翻譯為「子代元素選擇器」，而將descendant selector翻譯為「後代元素選擇器」。

專職翻譯活的好嗎？

有朋友問我如果想專職翻譯，到底收入好不好？如果你看過圖解翻譯稿酬一文，那我們就來作個簡單的計算。 首先，我個人認為以資訊技術翻譯書來說，要遇到暢銷書本來就不容易，本本都要暢銷更是難，所以我們先把版稅的方式排除掉，專門看稿費的作法。

拿稿費其實就很像是去工地搬磚塊，賺多少就看你能搬多少。假設你一天可以翻譯5頁，每頁稿費200元，一個月粗略估算是20個工作天，那麼整個月理論上的收入就是5X200X20=20,000元。所以如果你可以增加產量，每天翻10頁，就會變成40,000元；如果更厲害些，每天翻15頁（相信我，如果你真的要好好的翻，一天15頁大概是個瓶頸），就會變成60,000元。

聽起來似乎不錯，不過您得注意以下幾件事：

• 你得自行負擔所有的業務成本，電費、保險、網路、參考書籍等等。
• 和工地搬磚塊不一樣的是，你不會每個月結算翻譯稿費，得視各家出版社而定，也許全部譯完後、也許多少份量結算一次。
• 和工地搬磚塊一樣的是，你不一定總是有書可以翻譯。
• 最重要的是，不會每一本書都是你很感興趣的主題，也不會每本書都寫的好。

當然啦，最後我還是要說，如果你可以樂在其中，這樣的收入其實還不算差，有興趣嗎？趕快來！

延伸閱讀：

• [我的神經病.之五]倦勤者言──論不可拿翻譯當正職的 N 個理由
  

圖解最後一刷後半版稅計算法

許多朋友看過上次的圖解翻譯稿酬之後，可能都有一個疑問，就是不就永遠都有最後一刷的後一半數量沒有付版稅嗎？為了解釋這一點，我特別又畫了一張圖解末刷後半版稅支付流程，說明大概的方式：


所以你可以發現，合約上對於到期時所議定的處理方式，會影響末刷後半的版稅支付，我看過最扯的合約是連有效期限都沒有約定的，真的！

稿費、辦稅收入怎麼報稅？

許多作譯者都有這樣的疑問，稿費或是版稅怎麼報才省錢？另外，許多作譯者也對於給付稿費或版稅時被預扣所得稅耿耿於懷，好像少領了錢。事實上，根據各類扣繳所得標準的規定：

給付稿費、版稅、樂譜、作曲、編劇、漫畫、講演的鐘點費等執行業務報酬，所得人如果是境內居住的個人，按給付額扣繳10%，但是如果每次應扣繳稅額不超過新台幣（以下同）2,000元的話，可以免予扣繳。

所以預扣是守法的，不預扣的你得注意這家公司，並且留意扣繳憑單上的所得分類是否為稿費、版稅、鐘點費這一類，否則會影響你報稅。

至於稿費、版稅的報稅，大部分作譯者都知道有18萬的免稅額，不過根據所得稅法規定，扣除18萬之後的所得，還可以扣除30%作為成本：

個人取得稿費、版稅、樂譜、作曲、編劇、漫畫、講演的鐘點費等類的收入，每人每年合計不超過18萬元時，可以全數免稅，超過18萬元的話，如果是屬於自行 出版的部分，可以就超過部分檢附成本和費用的憑證核實減除或直接減除75%的成本費用，以餘額申報執行業務所得。其他不是自行出版的部分，可以減除30% 的成本費用以後，用剩下的金額申報執行業務所得。

也就是說，如果稿費版稅收入全部30萬元的話，可以先扣除18萬元免稅額，剩下的12萬可再扣除30%，也就是3.6萬元為成本，所以實際上要計入所得的部份就是8.4萬元，這可能就可以讓您少跳一級稅率哩！

延伸閱讀：

• 財政部稅務入口網國稅問與答所得稅區
• 圖解翻譯稿酬
  

圖解翻譯稿酬

常常有人問，翻譯的收入如何？我特別製作了一張稿酬東西軍圖表，讓大家可以自己算一算翻譯這一行到底划不划算？



延伸閱讀：

• 老貓學出版網站的（歡迎討論：適當的譯稿費用計算法）
  

詞辨：element、tag

如果查閱W3C對於XML檔案結構的說明 ，會清楚看到XML文件是由多個element所組成，而每一個element可以是以下兩種形式：

• empty-element-tag：也就是像是<img src="http://www.w3c.org/head.hpg" />這種沒有content的element。
• start-tag content end-tag：也就是以一對起始標籤/結束標籤所界定範圍所組成，像是<a href="http://www.w3c.org/">W3C</a>這樣。

因此，element與tag並不相同，不過綜觀市面上的一些書籍，有些已經把element與tag混為一談，譬如當我讀到Professional ASP.NET 2.0的第13章時，就看到以下這段話：

The third line, , is the root element or document entity of the XML document. An XML
document can have only one root element. The last line in the document is the matching end element
.

很顯然的，依據W3C的說法，這一段話裡頭的"root element"應該改成"start tag of root element"；而"end element"應該改成"end tag"才是正確。不過這本書這樣寫是情有可原的，因為如果回頭查閱微軟.NET的說明文件，會看到XmlReader對於整個XML結構樹的每一個節點，有以下的種類（原文件請看這裡）：

• Element：項目。 XML 範例：
• EndElement：結尾項目標記。XML 範例：

可見微軟的文件中就是把tag當成是element，因此許多書也這樣寫就再自然不過了。

翻譯名詞：attribute、property

在大多數的書或是文章中，對於attribute與property兩個詞一律都翻譯為「屬性」，雖然在語意清楚的情況下，自然可以分辨，但還是常常會容易混淆。如果要分辨清楚，就得回頭看看物件導向的起源--ADT（Abstract Data Type）。

ADT是由表示資料的data與行為能力的operation所組成，落實在程式語言的層面，當我們用class來描繪一個ADT時，就將代表資料的data稱為attribute、而operation稱為method。在某些程式語言中（如C++），就將attribute稱為member variable、而method稱為member function。不過在其他種類的程式語言（像是C#）中，也把attribute稱為field。 實際上，在許多書中，可能也都沒這麼考究，幾個詞彙可能交替互用，而沒有細分。

那麼property呢？我認為這個詞彙的流通，主要是component-based的程式語言或是整合開發環境（如VB、Delphi）興起之後才逐漸被使用，主要是指以一對分別用來儲存（setter）以及擷取（getter）的方法（method）所封裝的資料，由於是以方法來封裝，因此就可以在設定或是讀取資料的同時進行必要的運作，像是驗證新設定的值是否合理、或是因應新的值自動更改其他屬性的值等等。隨著property的流行，許多程式語言（像是C#、Ruby）本身就直接提供property的語法，Java則是要求程式員必須依循一定的命名規範，讓一對方法在整合開發環境中使用起來像是其他程式語言中的property。

在.NET中，事情又被複雜化了， 因為.NET使用attribute這個詞彙來表示物件在進行某種行為時的特性，比如說透過Serializable這個attribute，可以指定類別中哪些field在serialize時要儲存起來。這裡的attribute就跟前面所提到對應到ADT中data的attribute不同了。如果您查閱微軟的文件，會發現有些地方微軟把attribute翻譯為「自訂屬性」，雖然已經和「屬性」有所區別，但還是容易讓人誤會「自訂屬性」是「屬性」的一種，我個人比較建議將.NET中的attribute譯為「特性」，會比較達意。

了解了這一點之後，就可以知道在HTML/XML中attribute的意義了，依循的還是ADT中data的意思，所以譯為「屬性」並沒有太大的問題。

延伸閱讀：

• Realazy » attributes V.S properties，屬性還是性質？
• 4.1 Implementation of Abstract Data Types
• 是Attribute，還是Property？

書介：翻譯研究、翻譯新究

我有一個夢想，希望每一個來找我的譯者都好好的讀過思果先生的《翻譯研究》。

我相信這的確是每個編輯的夢想，否則就不需要花那麼多時間看稿，而是應該享受在閱讀的樂趣中。

這本書的焦點放在翻譯的結果究竟像不像中文？中國人讀了之後對於文句所要表達的意思會不會有直覺？以英文中常見的"one or more...."這樣的句子為例，大多數人會依據英文很直覺地翻譯成「一或多個....」，但中國人其實很少這樣說，閱讀起來一定覺得很拗口。道地中文的講法應該翻為「至少一個....」，才會像是中文，否則雖然意思也許讀者看得懂，但骨子裡卻不是中文。

但可別以為就這麼簡單，作者還期望譯者要能在翻譯結果中展現與原文一樣的語氣，比方說 "Well,I'll be there."，直譯就是「好，我會在那裡。」但一般人不會這樣說，大概會說「好，到時我在那裡等你。」或是「好，到時候見。」但如果說話的是文謅謅的老教授，也許就該翻成「好，到時我在那裡恭候。」。另外，同樣的事情發生在不同人身上，英文可能是一樣的，但中文卻不同，像是一般人與妻子離婚，換成了皇帝，就是「廢后」。

如果您看過其他討論翻譯的書籍，很容易就可以發現本書最大的特點，就是「實務中的理論」。書中所談到的內容或是實例，都是作者自己多年蒐集以及苦思、實作的心得，舉例來說，英文中常見的 "one of the best XXX" 這樣的句子就很困擾我，不花腦筋的譯法就是「XXX中最好的其中之一」，意思雖然能懂，但畢竟不像是中文，但看到書中的建議，恍然大悟，這就譯成「了不起的XXX」不就得了。

如果您有志從事翻譯，那麼我真誠的認為好好把這本書徹底研讀幾遍，一定會讓你的翻譯功力大有斬獲，但唯一的缺點是，鑑別力也會大幅增長，即便想要降低標準多騙點錢大概都沒法對自己放水。最後要提的一點是，本書雖然主要針對英文翻譯，但對於其他語言的翻譯，也會有很大的啟發，建議都不妨一讀，絕不會浪費時間。

後記：本書舊版本的編排比較適合閱讀，新版在版面上加上了一些托福應試類型書籍中會出現的圖樣，不但不利閱讀，也讓這本書的質感頓時跌落千丈，真不知出版商是怎麼想的。另外，作者還有一本《翻譯新究》，亦值得一讀。