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

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

詞辨：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 為「引數」, 姑且可以看成「參考格式」、「實際引用」的意思吧。

詞辨：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翻譯為「後代元素選擇器」。

詞辨：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？

URI、URN、以及URL？

在大部分的書上，可能會出現URI與URL，而且在許多地方已經把URI與URL視為等價的兩個詞彙，不過如果追本溯源，就會發現這兩個名詞涵義並不相同。

根據Wikipedia，簡單的來說，URI（Universal Resource Identifier）是 泛指任何可以識別出某項資源（某個東西、某個人、某個....）的項目，這又可區分為兩種，一是大家較不常用的URN（Universal Resource Name），是指能夠識別出某項資源的名稱，比如說「Wikipedia」就是URN；另一種URI就是最常用的URL（Universal Resource Locator），除了能識別出某項資源外，還能指出資源所在的位置，比如說 http://www.wikipedia.com/ 就是URL。

因此，嚴格來說，URL是URI，但URI並不一定就是URL，這是在使用詞彙時必須注意的事情，否則對於某些讀者就可能會造成誤會。

翻譯名詞：object, instance

object與instance可能是困擾程式設計類書籍譯者最多的名詞，在大部分的文章中，一旦翻譯成中文之後，即使將object或是instance都譯為「物件」，在語意上多半不會造成困擾（我自己也常這樣做），但如果細究起來，我認為其實object與instance是有所不同的。

object應該是泛指某一物件；而instance通常是特別指某一類的其中之一個。也就是說，出現instance的場合多半都會指明所屬的類別，比方說"a instance of Car class"；而出現object的場合，多半不會特別指明其所屬類別，或者無法指明所屬類別，比方說"delete all objects in the collection"。

好，如果是這樣，那麼object與instance究竟應該如何翻譯呢？我個人的建議是object就簡單翻譯為「物件」，這也和一般稱「物件導向程式設計」相符；而instance如果審視上下文，有必要區別出來時，就翻譯為「某某類的（一個）實體」，否則可以一樣翻譯為「物件」即可。