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

讀書筆記：邏輯思考的技術

書未讀完，前四章筆記以圖解方式紀錄，如果您有這本書，希望這張圖也對您有用處：



延伸閱讀：

• 邏輯思考的技術
  

推：IBM提供Many Eyes資料視覺化服務

如果您像我一樣對於資料的視覺化有高度的興趣，那麼IBM推出的Many Eyes服務絕對是最大的福音。只要註冊IBM網站帳號，就可以使用這個網站的服務。您可以上載資料，然後選擇想要呈現的視覺化方式，套句Steve Job的口頭禪，Boom，漂亮的視覺化圖形就秀出來了。更棒的是，同樣的資料可以任意選擇多種方式呈現，而且因為是使用Java Applet，所以還可以對視覺化的結果操作（例如加總等等）。

舉例來說，以下就是以之前的文章提到的《政府機構軟體開發環境問卷調查》中整合開發環境問題問卷結果做出的Treemap：



相同的一份資料，可以用另外一種方式呈現氣泡圖：



對於每一個視覺化的呈現，都提供有Blog this按鈕，會幫您產生可以放在您文章的HTML碼，方便您刊登在自己的網站上。另外，網站也提供回應的功能，可以讓網友針對每一個視覺化圖形的意義進行交流（這也表示您所發佈的每一個視覺化圖形都是公開的）。

延伸閱讀：

• Treemap 簡易教學示範
• Treemap製作簡易教學二部曲：使用Treemap軟體
  

書介：HTML Dog: The Best-Practice Guide to XHTML and CSS

如果您已經在使用HTML/CSS設計網頁，但想回頭好好學學HTML或是CSS，卻被市面上許多大堆頭的書所嚇到，那麼就該買下這本書，我保證你絕對不會後悔。

本書和市面上大部分HTML＋CSS的書不同，以採用Web Standard為出發點，所以不會浪費時間和篇幅教你一大堆HTML標籤，然後回過頭來告訴你這個標籤最好不要用、那個標籤不應該用。而是從頭開始就只教你能夠表現文件結構的標籤（其實也就是XHTML），所有以外觀為目的的標籤一律不會出現，也因為如此，所以一開始就是使用CSS調整外觀，照著這本書的路走，要不符合標準也難。

簡單的來說，這本輕薄短小（如果扣除附錄，只有205頁，而且排得很寬鬆）的書非常適合好像已經學過HTML/CSS，但卻又覺得不是學得很踏實的網頁設計人員，只要利用很短的時間，就可以從這本書上補足所有你可能欠缺的根基，絕對划算。

延伸閱讀：

• 本書作者的網站
• 相關書籍《跨平台網頁設計--使用Web標準技術》
  

專職翻譯活的好嗎？

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

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

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

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

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

延伸閱讀：

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

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

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


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

從《The State Of Web Development 2006/2007》看網頁開發概況

Sitepoint發表了一份 The State Of Web Development 2006/2007 的調查報告，在這份2006年6/15~7/15的期間針對5,000位網頁開發人員的問卷結果中，可以看到網頁開發技術平台的現況大概是這樣（這份報告要價不斐，我當然沒有財力購買，以下的Treemap圖都是從這份報告的Preview版本中推演而來，圖中區塊大小與顏色都代表佔比，越亮綠佔比越大、越紅佔比越小，越接近白色越接近中間值）：

• 你可以看到PHP獨占鰲頭，比整個MS（微軟）平台的技術加總還高。
• 最近火紅的Rails雖然只佔了一小塊，但卻接近ColdFusion。我推估到了現在，過了半年後，Rails的版圖應該大有斬獲。
• 如果單看微軟平台，會發現ASP與兩個版本的ASP.NET大概各分1/3，但從顏色上可以看出來ASP（白色）略高於.NET（淡粉紅色），顯然升級到.NET平台的行銷工作微軟還有一段路要走。
• JSP只與ASP.NET的單一版本佔比相近，得加油了。
• Opensources（JSP沒算在內）佔住了半邊天，還有明日之星蓄勢待發，前景可期。
  

如果問到接下來的12月內可能會考慮採用哪一種技術，那麼佔比的Treemap如下（這裡區塊大小代表佔比，顏色則是把這個問題的數據當成未來實際的市場狀況時，與上一張圖同一技術佔比的差距，越亮綠表示成長、越紅表示衰退、白色持平）：

• 這裡可以看到，Rails最受青睞，這和這半年來看到或聽到的狀況相符。
• 可能是Rails帶起的效應，Python也獲得不少注目。
• 微軟平台則是ASP.NET 2.0最受到用戶的期待，準備採用。
• PHP反而有流失的現象，其餘技術則大多持平。

報告上也提到了在考量新技術時，大致上可看出的板塊移動如下圖所示：

很明顯可以看出來，Opensource與MS各自為政，互不侵犯，兩方的開發人員不會轉換陣地，但在各自的版圖中，則有相當的變動。如果從另一個問題的調查結果來看，更可以看出未來可能的趨勢，以下是針對希望哪些技術有更多的資源得到的佔比分配（區塊大小與顏色的意義同第一張圖）：

• AJAX是大熱門，不過調查的時間是去年六月，現在AJAX的資源應該已經算是氾濫了。由AJAX效應帶起的就是JavaScript和JavaScript Library的需求，目前看來JavaScript Library書很缺，應該是可開發的方向。
• 值得注意的是XHTML/CSS，同一份調查中發現有25%的開發者會堅守HTML檔必須驗證通過，而有近60%的開發者會驗證自己的HTML檔，但不一定會修正錯誤，另外有近70%的開發者主要採用CSS做版面配置，因此對於XHTML/CSS的需求自然是趨勢。如果將美國的情況視為台灣的前哨站，那麼台灣今年應該會展現一波需求才是。
• PHP雖然已經有許多豐富的資源，但這裡的需求仍然很高，很可惜沒有進一步調查，不然我挺好奇大家的需求是什麼？
  
• 你也可以看到Opensource總和的需求極高，一方面反應前面看到Opensource佔市場一半的局面，另一方面可能也展現了Opensource的技術文件量的問題。
• 另外可以發現到Flash的需求也不小，尤其Flex聲勢不小，其實還蠻值得開發人員去瞧瞧，而不只是把Flash當成網路動畫的技術。

後記：我手上總共有兩個版本的Preview報告，一份有全部15個問題的結果，一份只有其中幾個問題，但加上了專家評論的內容，後來再嘗試去下載都只有後面這一份了。

延伸閱讀：

• 每季一次的 State of the Computer Book Market, Q4 06, Part 1, Overall Market Trend 來了，可以和這份報告交互比較。
• 之前寫的從《政府機構軟體開發環境問卷調查》看程式語言與整合開發環境市場佔比
  

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

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

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

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

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

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

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

延伸閱讀：

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

圖解翻譯稿酬

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



延伸閱讀：

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

Here Comes iPhone, Cool.

透過線上觀看Steve Jobs簡報已經是我近年來的大樂趣，昨天看的iPhone秀更是讓我悸動不已，我記得上一次讓我有這種感覺的產品是Google的GMail。整個秀（雖然該說是簡報，但實在像是一場秀）高潮不斷，讓我讚嘆的有以下這些：

• iPod部份
• 手指捲動清單的方式，這的確很類似我們用手指指著一串資料閱讀的手法。
  
• 翻弄唱片封套找唱片，相當符合一般人找CD的習慣，我想到的是現在的電子書閱讀器不知道能不能用這樣的方式作翻頁的效果，會更像是在翻書。
• Phone部份
• 加入類似GMail Conversation的SMS（簡訊）處理方式，的確很適合現在大量用簡訊的手機用戶，這項功能也是我個人覺得GMail最值得稱道的地方。
• 直接讀取特定的留言，不知道這是否需要系統商支援？如果並不需要，而只是現今的手機都沒做到，那真是奇怪了。
• Photo Album部份
• 用多觸點的觸控螢幕控制圖形縮放，真有一套，我想這應該會有更多用途，雖然目前只看到這個用法。
• Internet Navigator
• 有Safari Browser真好，最棒的是先以縮圖方式顯示完整的網頁，可自由選取區域放大閱讀點擊，而不會因為畫面實體的大小破壞網頁的外觀（像是瀏覽器中有虛擬桌面）。另外，透過Web Page Thumbnail選取頁面也可以解決tab太多無法分辨個別頁面的困境。我一直都希望可以有一個PDA大小的PC，只要能跑Firefox，加上Google的各式服務就是一個超讚的PDA，還不需要同步來同步去的哩。

隨便先記下這些，2008年亞洲才上市，好樣的，真會做生意！

對了，改天應該來談談Steve Jobs的簡報術。

延伸閱讀：

• The iPhone As An eBook Reader

Treemap製作簡易教學二部曲：使用Treemap軟體

要製作Treemap，除了使用上次介紹過的Microsoft Treemapper with Excel Add-In以外，還可以使用Treemap原創人Ben Shneiderman所領導以Java開發的跨平台軟體Treemap，目前的版本是4.1.1，需要Java 1.4的環境才能執行。只要下載回來，解開壓縮檔，執行其中的run.bat即可（這是指Windows平台，其他平台請自行閱讀readme.txt）。

不過再真正顯示treemap之前，必須先準備好原始的資料，Treemap軟體可以接受以tab分隔欄位的文字資料，您可以使用Excel製作原始資料，再另存成文字檔，例如底下就是和（Treemap 簡易教學示範）這一篇的範例同樣的資料，但依循Treemap軟體要求的格式：


要注意的有以下幾點：

• 量化的資料欄位要擺在最前面，並且與後面描述階層結構的欄位之間空一欄。
• 量化的資料可以必須標示資料的型別，可用的型別共有FLOAT、INTEGER、DATE、STRING四種，而且必須以大寫字母標示。

準備好這份資料後，就可以開啟Treemap軟體，選擇『File/Open...』開啟資料檔案，就會看到對應的treemap：


咦，奇怪，不但每個區塊看起來都一樣大，而且也沒有顏色標示？這是 因為我們還沒有告訴Treemap軟體要以那一欄量化資料代表區塊大小語言色，您可以在操作畫面右邊選取Legend頁籤：


分別在Size以及Color欄位選擇量化資料的欄位即可，結果如下圖：

這樣就顯示了我們所需要的Treemap（此圖中是以業績維區塊大小、業績成長率維顏色，越紅表示成長率越低、越亮的綠色表示成長率越高，黑色則是持平）。Treemap軟體可設定的選項繁多，此篇僅是簡單的入門，提供給大家參考。

延伸閱讀

• Treemap 簡易教學示範
• 從《政府機構軟體開發環境問卷調查》看程式語言與整合開發環境市場佔比

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