Huan-Lin's Blog

檢視全文：http://huan-lin.blogspot.com/2008/04/domain-specific-development-domain.html

搬新家時曾想過，要一篇一篇把文章搬到新家會花不少時間，尤其包含附加檔案、圖片、和程式碼的文章，移轉時特別麻煩。可是萬一舊站關閉了，網友從 Google 搜尋結果連過來時，那些連結都是無效的，如此一來，唯一的辦法就只剩下 Google 的「庫存頁檔」了。

就在公佈部落格的新家之後，「點部落」的站長（同時也是 ASP.NET MVP）Dotjum 與我聯繫，表示願意提供空間存放「Huanlin 學習筆記」舊站的文章，以免有些文章就這麼消失了。這個提議正好解決了我擔心的事。

因此，依 Dotjum 的提議，我在「點部落」申請了一個部落格：Huan-Lin 學習筆記 on DotBlogs。也承蒙 Dotjum 大力協助，幫我把一些新舊文章移轉過去，十分感謝！

由於我在 Google Blogger 的新家才剛設定好，因此未來發布新文章時，我應該還是會以 Blogger 的新家為主，「點部落」那邊則傾向採用文章轉貼的方式。

等兩個新家順利運作一陣子，我可能會先修改這個部落格的網頁，讓它自動把 user 重新導向到新家，以解決從 Google 搜尋結果連過來找不到網頁的問題。再等一段時間（或許三四個月），應該就可以放心關閉這個部落格了吧。總之，再觀察一段時間。

文章貼在這裡：
http://huan-lin.blogspot.com/2008/05/domain-specific-languages.html

順便公告搬家訊息：

這幾天換了硬碟，想想這幾年換了兩次硬碟，部落格架在自己家裡似乎挺傷的（電費也是），所以打算搬家了。

之前曾經嘗試將部落格轉換到微軟的 Window Live Space，發現不怎麼喜歡，這次則改換到 Google 的 Blogger，嘗試把幾篇舊聞轉貼到 Blogger 網站，感覺還不錯，而且有不少支援工具，自訂模板的部份也挺好。唯一麻煩的是附加檔案，這個部份我是將檔案上傳到別的免費網路硬碟來解決。

新家一樣叫做 Huan-Lin 學習筆記。往後新的文章會張貼到新家，然後在這裡轉貼連結。如此試行一兩個月看看，如果感覺 OK，這裡就逐漸不會增加新的內容，但由於很多舊文章無法全部轉到新家，所以舊的部落格還會持續運作一陣子，再看情況調整。

好心人 Chuck 整理的：blog roll: Visual Studio Team System Development Team

這裡更多：Visual Studio Team System Blogs

BugNET 這套問題追蹤工具除了具有免費、容易安裝設定等優點，個人用到現在也都沒碰到什麼大問題（目前用在約 20 人的團隊），挺穩定的，而且一直都還持續更新，功能也愈來愈強。最近對目前參與的專案有一些軟體品質方面的疑慮，想要從平日登錄到 BugNET 的資料抓出一些統計數據，這才發現 BugNET 提供的統計圖表並不是很夠用。所幸它提供了一個 view，從這個 view 取出的資料，幾乎已經能夠滿足我的需要了，剩下的只是如何產生圖表而已。這篇就大概介紹一下我從這個 view 取出哪些資料，以及利用 Excel 產生的圖表，同時扼要說明一下這些圖表的用途。

BugNET 提供的 view 名稱叫做 BugsView。以下分別介紹用來產生統計圖表的 SQL 命令、圖表範例、以及用途說明。由於 BugNET 本身已經有提供的問題狀態統計圖（一張圓餅圖，顯示已結案、處理中、重新提出...等各種問題處理狀態各佔多少百分比），所以這裡就不列出了。

要先說明的是，有些 SQL 命令看起來很冗長，我也沒特別花時間去查是否還有更精簡的指令，基本上只求能達到我的目的。此外，這裡的圖表範例，都是先利用 SQL 命令得到資料，然後直接貼到 Excel，稍作加工（修改欄位標題、加總等等），再使用 Excel 的插入圖表功能即可完成。當然你也可以撰寫程式將這些產生圖表的動作自動化，方便隨時查閱。

1. 每個月的問題數量

SQL 命令：

SELECT     STR(YEAR(ReportedDate), 4, 0) + '/' + STR(MONTH(ReportedDate), 2, 0) AS RptYYMM,
  COUNT(YEAR(ReportedDate) + MONTH(ReportedDate)) AS Cnt
  FROM         BugsView
  GROUP BY YEAR(ReportedDate), MONTH(ReportedDate)
  ORDER BY RptYYMM

圖表範例：

說明：

從這張統計圖可以看出哪些月份的問題數量比較多，以發現數字背後所隱藏的事件或原因。例如 2007 年 10 月可能有某個新系統上線，而使用者對該系統反映的問題較多，因此數量明顯增加；2008 年 2 月份由於經過一次年假，問題的數量就少得多。當系統完成驗收之後，系統應該會逐漸穩定，因此這張統計圖的問題數量應該呈現逐漸減少的趨勢，若非如此，專案經理就得進一步了解實際的原因。

2. 問題的優先等級分布

SQL 命令：

SELECT     PriorityName, COUNT(PriorityName) AS Cnt
FROM         BugsView
GROUP BY PriorityName

圖表範例： 

說明：

在登錄問題時，必須根據問題的嚴重或緊急程度做分級（triage）。在所有提出來的問題當中，我們比較有興趣的是「緊急」跟「很重要」的問題佔多少比例，因為我們將這類問題定義為較具急迫性的問題，開發團隊必須在指定的期限內處理完畢。如果這類嚴重問題的數量很多，要不是軟體的品質水準太低，就是登錄問題的人員對於問題的分級不確實，比如說，可能每次登錄時都希望問題盡快獲得解決，就一律歸類為緊急問題。

3. 問題數量與軟體品質的關係

SQL 命令：

SELECT     TypeName, COUNT(TypeName) AS Cnt
FROM         BugsView
GROUP BY TypeName

圖表範例： 

 說明：

BugNET 的問題類型也可以自行指定。我把問題的類型分成 Bug、改進意見、新增需求、需求變更、待討論、以及無效問題等六類。Bug 代表軟體的設計錯誤，包括設計不符合使用者的需要、無法執行特定的功能、以及執行結果不正確等等；改進意見代表功能雖然可正常執行，但是在易用性、穩定性、效能等方面有待加強之處；以上兩項均代表軟體的品質，若其總和數量偏高（例如：超過事先定義的警戒線），專案經理就要特別注意。新增需求與需求變更皆屬於需求異動的部份，開發團隊可以從這兩項數據得知使用者是否經常提出需求變更，以了解需求蒐集和系統分析階段是否有需要改進的地方是，例如：需求誘導技巧是否需要改進、每一項需求是否皆經過使用者的同意即確認、或使用者是否傾向於事後（上線後）才提出新需求等等。屬於「待討論」的項目代表該問題的範圍或定義尚未釐清，主要是讓開發人員可以紀錄一些尚未確定的需求或議題（後來發現這項並不實用）。「無效問題」則是開發人員實際測試後，發現是使用者對系統操作方式不熟悉，或者其他環境因素所造成。

4. 各子系統的品質

SQL 命令：

SELECT     ComponentName, TypeName, COUNT(*) AS Cnt
FROM         BugsView
GROUP BY ComponentName, TypeName
ORDER BY ComponentName, TypeName

圖表範例： 

說明：

BugNET 可讓我們設定系統有哪些 Components，也就是說，你可以自行定義子系統及各項元件，這樣在登錄問題時才能夠特別指明該問題是發生在哪個子系統，將來也才能夠得到比較詳細的統計數據。當整個系統的 Bug 數量偏多，你可以從這張圖進一步看出各個子系統／元件的品質。例如圖中的人事系統光是 Bug 和改進意見的數量加起來就有 171 個，佔整個系統問題數量（689）的 25%，專案經理可能要針對這個子系統特別研究一下是哪裡出了問題。

P.S. 以上圖表都沒有標示時間範圍，它們都是同一個專案的 current stat，也就是從一開始登錄問題到目前為止的狀態統計。

P.S. 以上圖表除了子系統名稱被我換掉，其餘皆是真實資料的統計數據。

結語 

有時候，我們從最近 user 的反應「感覺」最近系統好像很多毛病，並將此意見反映給開發團隊時，經常得到的答案是：「程式的品質並沒有太大的問題，很多都不是 bugs，而是 user 的需求一直變更和新增。」此時解決爭議的最好辦法，就是拿出數據，這也是我製作這些圖表的用意：讓數字說話。 

不過，在運用這些圖表時，務須牢記一件事：無論是問題統計圖表還是其他專案度量結果，其提供的資訊可能只偏單一面向，專案經理在獲得此初步資訊之後，應進一步蒐集其他相關資訊，以提供問題的佐證，或者向團隊詢問，如此方能確定問題的根源，並提出正確的解決方案；如果單憑某個單一數據就驟下結論，而向團隊質疑或提出指控，不僅容易做出錯誤的決策，將專案開發工作引導至錯誤的方向，也很容易造成團隊成員的反感。

還有一種統計圖我很想看到卻沒有做的，就是問題的成長速度 vs. 問題的解決速度。因為有些問題實在花很多時間才解決掉，對於 bugs，我們特別關心它的平均處理時間。

以上有不少想法和觀念均來自《軟體工程與 Microsoft Visual Studio Team System》。我不時會回頭參考這本書，每每覺得這本書寫得真好，因機緣巧合而能夠翻譯此書，實在是沾了作者的光。希望 Guckenheimer 在 Rosario 問世之後也能更新這本書的內容。呃......大概只是奢望。

1. Introduction
2. Roles of the Software Architect
3. Software Architecture and the Development Process
4. Example System Overview
5. UML Quick Tour
6. System Context and Domain Analysis
7. Component Design and Modeling
8. Subsystem Design
9. Transaction and Data Design
10. Process and Deployment Design
11. Applying the Viewpoints

 

 

先自首，這標題下得有點過頭了 :)

偶然看到「親類別」這個詞，有點好奇，於是到 Google 搜尋關鍵字「parent class 親類別」，才知道原來 parent class 也有人翻譯成「親類別」。但......這是什麼時候開始的呢？印象中以前都沒有看到過。我還真是後知後覺。

就個人的印象，parent class 一般譯為「父類別」，我也從沒想過為什麼不翻譯成「母類別」，不知道是不是我的潛意識裡還有大男人沙文主義在作怪。不過，這也給了我一個機會，可以認真想一想 parent class 該如何翻譯。畢竟，翻譯最容易出錯的地方往往是那些看似不起眼的小地方，愈有把握，愈容易錯。

Parents 常見的意思是「父親與母親」，中文可簡稱為「雙親」。那麼，「親類別」的「親」會不會就是指雙親呢？

Collins COBUILD Dictionary 對 parent 的解釋為：

1. Your parents are your mother and father.
2. An organization's parent organization is the organization that created it and usually still controls it.

注意第一個解釋的 parents 是複數。再看看 Longman Dictionary of Contemporary English 的解釋：

1. the father or mother of a person or animal
2. something that produces other things of the same type
3. a company which owns a smaller company or organization

Macmillan English Dictionary 對 parent 的第一個解釋則為：

1. a mother or father

也就是說，parent 意指父親或母親，而加了 s 的複數則是雙親的意思。（呼～有點像在上英文課 @_@）

因此，parent class 既是單數，翻譯成「親類別」時，其中的「親」應該就不是指「雙親」，否則就真是誤譯了。

那麼，剩下來的問題便是 parent class 該翻譯為「父類別」還是「母類別」了。如果選「父類別」，好像有性別歧視之嫌，可是如果用「母類別」，似乎又有點不對勁。

就像有人認為，為了避免性別歧視，寫作時若要指稱不明性別的第三者，應該寫成「他／她」。可是也有人不贊成，認為這是多此一舉，有損文氣。

我不知道「親類別」是不是在這樣的為難之下做出的取捨。這種譯法確實能避開性別的問題，只是在閱讀時，感覺卻不是那麼直達原義，有點隔靴搔癢的味道。

我的想法是，「父類別」既已約定成俗，「母類別」又覺得怪怪的（或許女性朋友認為 OK？），不妨沿用。創新詞總是要耗掉比較多成本，而且，很奇怪的，或許是中了周華健的毒，看到「親類別」就讓我想到「親親我的類別」，所以，我應該是不會這樣用啦。

翻譯時碰到不少跟 typing 有關的術語，其中有容易的，也有碰到比較麻煩的，這裡一併順手記下。

Typing 這個字在不同場合需要不同的譯法，不能一概都翻成「型別」，否則容易跟 type 混淆。以下整理幾種 typing 的譯法，當然，只限定於軟體開發領域，一般的字義，如「打字」等不在此列。

譯成「型別」的例子：

• strong typing：強型別
• weak typing：弱型別
• dynamic typing：動態型別
• static typing：靜態型別

有的譯為「型別機制」可能會比較恰當，例如：

The idea of conformance is central to the notion of typing.

相符性是型別機制的核心概念。

有的地方既不好翻譯為「型別機制」，也不能簡單地譯為「型別」，例如：

Typing is the enforcement of the class of an object, such that objects of different types may not be interchanged, or at the most, they may be interchanged only in very restricted ways.

很明顯的，這裡的 typing 特別強調型別指派的動作，若譯為「型別」或「型別機制」讀起來都怪怪的。這是我花比較多時間考慮的地方。

最後我採用的譯名是「定型」，於是前面的例句可譯為：

定型（typing）就是強制指定物件所屬的類別，如此一來，不同型別的物件就不能互相交換，或者頂多只能在符合特定條件的情況下才能互換。

這樣的話，strong/weak typing 也可以譯為強定型／弱定型。不過，好像沒人這樣做，那就還是沿用習慣的譯法吧，反正並不會造成理解上的困擾。

曾想過用「型別指派」或「鑄型」，前者略嫌囉唆，後者的「鑄」又帶有製造的涵義，反倒像是定義型別，而不是指派型別了。

精誠（恆逸）資訊的講師們推出了 Visual Studio 2008 全系列書，預計 3 月 13 日到 3/14 日上市，對研究新技術有興趣或工作上有需要的朋友可以參考看看。

至於我自己，等收到米米貓友情贈送的這套書之後，恐怕得先把手邊的翻譯書籍工作處理完，才有時間練功了。感謝米米貓（Vivid 老師） :)

以下是各講師的部落格：

• 米米貓學開發
• Anita的.NET世界
• John的技術文件
• 遺忘技術的角落
• Sophie: KISS.NET

Updated 2008-03-28：今晚收到書了，內頁還有講師親筆簽名，感動! 多謝 Vivid、John、Anita、Adams、and Sophi  :)

大部分的字典都可以查到，super 是「超級」的意思，但是如果 super 是跟其他單字連用的前綴詞（prefix）時，其意義就不見得是「超級」了，superclass 就是一個例子。

在 Collins COBUILD Dictionary 中可以查到，當 super 當作前綴詞用時，其意義為：

Super- is used to form adjectives which indicate that something is at a higher level than something else.

這個解釋正好可用在 superclass，因為 superclass 就是在類別階層中屬於較高層次的類別。

有人將它翻譯為「基礎類別」（base class），有人翻譯為「父類別」（parent class），個人覺得都好，雖然它們跟別的術語衝突，但基本上意義是相通的。

另外還有「超類別」，雖然不建議使用，倒也還可以接受。可是，如果把 superclass 翻譯成「超級類別」，雖然只比「超類別」多了一個字，但這意義感覺上就差遠了，好像它是個無所不包的超強類別似的，跟原義卻是恰好相反。毫厘千里，還是得計較一番。

近日的空檔時間幾乎都在處理跟翻譯有關的事，下午出門活動一下，順便到書店晃晃，無意間撇見一本書：《優使性2.0網站經驗設計與使用者研究》，好奇之下翻開看了幾頁，以了解作者為什麼要以「優使性」這個詞彙來取代 usability 原有的譯名。這篇主要是說一下自己不用「優使性」的理由。

本書作者 Max 在自己的網站上也有解釋為什麼要採用「優使性」，主要的原因包括：

• Usability 的意涵不只是可用、易用，更包含了將整體設計優質化的概念。
• Usable 可譯為〝可用的〞但Usability卻不適合譯為可用性，因為Usability已成為一個專門且獨立的概念，並不能泛指所有事物的〝可用〞程度，譯為優使性可使其成為獨立的專有名詞，如此將有利於華文之相關研究，且不影響其〝可用〞之意涵。
• 優使性的中文發音與英文原文發音相近。

我也不贊成將 usability 翻譯成「可用性」，因為這樣容易和 availability 混淆，但我們還有「易用性」可以選擇，倒不一定非得創造新詞不可。 其次，在名稱中加了一個「優」而塑造成新詞彙「優使性」，或許可以點到「優質設計」的涵義，但是「易用」的部份是否就因此而削弱甚至犧牲掉了？

換個角度想，usability 這個詞彙是否在一開始出現的時候就有這麼豐富的定義？還是隨著時代與環境的變遷，而逐漸有了更豐富的衍申意義？

我們可以看一下 ISO 9126 (1991) Software Engineering Product Quality 對 usability 的定義：

A set of attributes that bear on the effort needed for use, and on the individual assessment of such use, by a stated or implied set of users.

到了 1998 年的 ISO 9241-11 Guidance on Usability 中的定義是：

The extent to which a product can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use.

我們可以發現，單單一個 usability 術語，不同的時空背景、環境中會有些微不同的定義，但是其最初的核心意義並沒有太大的變化，也就是使用者用起來的感覺是否方便、好用（如果效能差當然就覺得不好用、不滿意）。那麼，我們是否有必要因為後來的衍生或附加意義，再創造一個新詞來取代既有的詞彙呢？新的詞彙在表達原文涵義方面的廣度及深度，是否真的優於既有的詞彙，且足以讓我們拋棄習慣用語？此外，如果外國人（英美籍人士）可以在不創造新詞的情況下，繼續對 usability 賦予更豐富的意涵（滿意、優質、有效率、高效能...），又不至於混淆，那麼為什麼翻譯成中文時就一定要創造個新詞出來呢？繼續使用既有的詞彙並賦予更豐富的解釋，似乎是更省力的選擇。

再看 Wiki 英文版對 usability 的定義：

Usability is often associated with the functionalities of the product (cf. ISO definition, below), in addition to being solely a characteristic of the user interface (cf. framework of system acceptability, also below, which separates usefulness into utility and usability). For example, in the context of mainstream consumer products, an automobile lacking a reverse gear could be considered unusable according to the former view, and lacking in utility according to the latter view.

從這段定義可以發現，其主要意義是圍繞在「可用（有用）」與「功效」上面；沒有倒退排擋的汽車，從 usability 的觀點來看，是既不可（好）用，又欠缺該有的功能。

其實我們可以在網路上找到更多有關 usability 的相關定義，其中甚至包含了 learnability、memorability、accessiability...等等。如果能找到一個詞彙能夠涵蓋所有的涵義，自然是很好的，可是就目前看來，即使是「優使性」也無法達到這個目的，或者有明顯優於其他譯法之處－－除了它的發音跟英文比較相近之外。

個人以為，「易用性」還是比較適當，不只因為它易懂、一般人皆已熟悉，它也能夠呈現 usability 的主要涵義。只要在此基礎之上賦予它更詳細的定義跟解釋（就像 ISO 或 Wiki 那樣）應該就夠了。人們似乎並不會因為那個名詞容易懂，或比較偏向某個核心意義，就單純認定只有那個涵意。我想，這應該是定義是否清楚完整的問題，而不是名稱上面要不要展現所有涵義的問題（除非原有的詞彙真的離原意太遠，甚至造成混淆或誤導），否則我們恐怕有好多術語都得再創新詞了，例如：scalability、abstraction、framework....等等。

總之，個人看法是「優使性」這個詞彙的 usability 並沒有優於「易用性」，故不建議使用。至於它將來是否會取代既有詞彙而成為標準的譯法，就靜觀其變吧。若將來有官方的標準翻譯（何時才會有呢？），無論個人看法如何，還是應該遵循官方標準。

以上意見無關那本書的內容好壞，事實上，我覺得討論 usability 方面的中文書籍太少，而這本書適時填補了這個空隙，對軟體開發人員是有幫助的。

附註：

我後來發現，中文維基百科原本的「易用性」詞條，被某位網友改成了「優使性」，而且其中的內容都改得跟英文維基百科的 usability 完全不同了。變更後的內容，包括定義、採用該譯名的理由等，大部分都和《優使性2.0網站經驗設計與使用者研究》書中的內容相同。於是我又多事的動手修改了那個詞條（職業病+固執？），將名稱還原成本來的「易用性」，並依照英文版的內容做了部分翻譯，希望能還它本來的面貌。不過，現在到 Google 查「易用性」，還是會出現「優使性」的維基百科詞條，還要再等一段時間讓 Google 更新統計資料吧。

這是在 survey 翻譯輔助工具時的意外「收獲」：

哪個系所英文版介紹來自翻譯網站？

該文講的是嘉南藥理科技大學醫藥化學系的英文網頁，竟是用翻譯網站直接翻譯的結果。我照那篇文章自己實驗了一遍，果真如此。網站的設計者敷衍了事到這種程度，而且還是大學的系所網站，實在令人驚訝。就算網頁是外包的，至少學校方面也應該有承辦人負責把關一下吧。

這裡還有一篇討論：有英文網頁才丟臉的時候

驚訝之餘，多事寫了封信給該校的網站管理者，或許再過幾天，那個英文網頁就會換掉了吧－－如果真有人在乎的話。

後記 (2008-02-05)：今天晚上 7:00 以後，該學系的英文網頁已經變成空白一片了，中間留了一行「Under construction」。
後記 (2008-03-06)：事隔一個月，再去看該學系的英文網頁，已經有新內容了 。（我還真愛管閒事啊 @_@）

=========================

順便記一下這次 survey 的幾個翻譯輔助工具：

• Trados
• WordFast
• WordFisher

這些都是屬於 TM（translation memory）類型的輔助工具，其中以 Trados 的價格最「高貴」，WordFisher 則是完全免費。

快速爬了一下網路上的文章以及這些工具的說明文件，發現似乎要花不少時間學習才能上手（有人花了兩年才敢說自己熟悉 Trados：我們真的需要 Tados 嗎？）。可是，自己手邊的翻譯進度都趕不及了，哪還有時間學工具呢？這不禁讓我想到〈何時磨利鋸子〉這則寓言故事：

某人很吃力地在鋸一堆木頭，因舊的尚未鋸完，新的又送來，致愈堆愈多，不得已只有再三延長工作時間。
有人好心提醒他：「因為鋸子鈍了，所以效率甚差，只要將鋸子磨利，即可改進日益惡化的情況。」
該人頭也不回答: 「工作都忙得做不完了，那有時間磨鋸子？！」
好心者仍不死心，問道：「那你何時有空磨利鋸子？」
該人有氣無力應道：「等我鋸完這堆木頭再說。」

我似乎也成為寓言故事中的那名鋸木工人了 @_@ 

簡介 

《等效翻譯探索（增訂版）》是由翻譯家金堤先生所著，這本書原為簡體版，後來才在台灣發行繁體中文版。閱讀時很順暢，沒有明顯感覺簡體書的影子，想必繁體中文版已經針對兩岸用語差異的部份做過一番調整了。

等效翻譯理論強調譯文不僅要能準確傳達原文語意，同時要盡量維持文句的通順。其基本原則是「同一信息，用兩套不同的語言，接受者不同，卻要產生基本相同的效果。」作者指出，古人早就提過等效翻譯的概念，如玄奘說的「既需求真，又需喻俗」，而作者所提出的等效論，看起來似乎是基於奈達的「功能對等」理論（最初發表時的名稱是「動態對等」），加以調整並融合自己的經驗與理念所發展而成。無論起源為何，重點在於這套理論「對兩千年來西方翻譯家們相持不下的直譯與自由譯之爭，提供了一個令人信服的答案。」其中的自由譯，即所謂的「意譯」。

義大利有句諺語說：「翻譯就像女人，漂亮的，可能不忠實；忠實的，又可能不漂亮！」換句話說，就是直譯與意譯兩相衝突，好比魚與熊掌，不可兼得，因此譯者只好在「寧信而不順」與「寧順而不信」之間擇一為之。但是等效理論認為這是不正確的觀念：「順」與「信」二者並非互斥，實為一體之兩面，應該同時並存。而且，一旦走上意譯的路子，等於為譯者開了方便門，在碰到難處時，譯者可能更容易採取閃躲、任意刪改原意的「變通」辦法，而不是盡力突破眼前的困境。

以下分別整理等效翻譯理論的重點概念、書摘、以及一些感想。

三個核心概念

• 接受者概念：譯文必須被讀者接受，翻譯過程才算有效。要讓讀者接受，首先必須了解原文的對象是什麼樣的人，從原文的語言、文化當中掌握正確的語感，並充分理解原文；接下來，要產生譯文時，則須排除原語的干擾，以譯入語的語感創造出原文同樣效果的譯文。
• 效果概念：效果指的是譯者傳遞的訊息必須對接受者（讀者）產生作用（impact），此作用就是接受者獲得的一切理解和感受，包括：主要精神、具體事實、意境氣氛。這裡的效果，跟奈達所提出的「動態對等」理論所說的效果有些差異，奈達認為，讀者除了有感覺，還要做出實際的反應，例如：讀了聖經就真的去受洗。
• 對等概念：翻譯所需之對等「是一個相對概念，並不是要求達到完全相同的效果，而是達到可能範圍內最接近原著對原文讀者所產生的效果。」簡單地說，就是譯文必須通達。這裡「通達」跟奈達主張的「自然」（nature）概念不同，奈達認為，如果讀者因為文化、環境、或時空背景等因素而無法體會原文要表達的意境，譯者應該調整譯文，讓讀者讀起來感覺比較自然；這看起來更像是犧牲原文的意境而屈就讀者，等效論並不贊成這種作法。 

三個翻譯階段 

作者建議的翻譯步驟分為三個階段，共九個步驟： 

第一階段：以理解原文為主的準備階段。基本上單純使用原語思維。此階段盡量不用雙語字典，而用原語字典或其他原語參考資料。

• Step 1: 仔細閱讀原文，勿試圖翻譯。
• Step 2: 研究作者及作者的其他著作。
• Step 3: 徹底了解即將動手翻譯的原文，包括內容、形象、細節、暗藏含義。

第二階段：雙語雙軌工作的具體翻譯階段。

• Step 4: 使用譯入語創造自己的譯文。此時要注意避免受到原語的干擾。
• Step 5: 譯稿完成後，逐句核對原文。
• Step 6: 將譯稿放置一段時間不去理他，以便「冷卻」。

第三階段：單純使用譯入語來複合譯稿。

• Step 7: 用冷卻後的眼光審閱譯稿，讓自己盡量成為客觀的讀者。
• Step 8: 請不懂原語的讀者閱讀定稿，以找出讀起來彆扭的地方。
• Step 9: 仔細考慮讀者意見，對譯稿做最後潤色。

書摘

初學翻譯的人往往以為藝術就是華麗的詞藻，千方百計拼湊四字詞語和所謂的文學語言，結果不僅損害了內容也破壞了藝術。 (p.8)

有些人在發現原文「講不通」的時候，不是回頭去懷疑一下自己的理解有什麼差錯......，而是盯著他們認為「講不通」的詞句，「根據上下文」對這些詞句作「靈活」的處理，沒有想到這個「上下文」實際上是他們自己頭腦中的錯誤認識，而這樣的「靈活」實質上就是「寧順而不信」的一種表現形式。 (p.37)

因著意傳神而忽略事實，這是許多翻譯作品及評論中可以看到的一個傾向，其特點一是在傳神的過程中忽視事實，二是在追求文字美的時候忽視真正的傳神。 (p.39)

我們常說好的翻譯應該讀起來不像翻譯。但是「讀起來不像翻譯」的作品，如果沒有起到翻譯應做的傳遞正確信息的作用，還能算是好翻譯麼？這正是問題的核心所在。 (p.39)

只要承認翻譯的目的是給別人看或聽的，就不能不同意「信」和「順」二者之間不但沒有不可克服的矛盾，而且是必須共同存在的條件，是一個統一體的兩面。 (p.42)

感想

我是個半路出家的業餘譯者，翻譯對象也只限定在「硬梆梆」的軟體開發類書籍，不過，我相信多了解一些翻譯理論，對於從事翻譯工作還是很有幫助的。本書除了闡述等效翻譯理論，也有提到譯者經常面臨的困境以及常犯的毛病，與自己的翻譯經驗（雖然很貧乏）對照之下，確實也得到一些印證和警惕。讀完本書，翻譯時在兩種語言文字進出之間的拿捏，自覺也有了更加明確的準則。

值得一提的是，譯家馮亦代先生曾對作者翻譯的《尤里西斯》提出多處批評，而本書最後也收錄了金教授對這些抨擊的回應文。金教授不僅逐條比對不同譯法，也詳細說明了當時為什麼會這麼譯，馮先生的批評又是錯在哪裡。我們不僅能夠從這篇回應文看到等效翻譯理論的明證，也看到一位翻譯名家的風範，例如文中有一段話：

「我感謝馮先生費心寫這兩篇文章，尤其是他用對比方法，使我有機會比較深入地談一談我的具體原則和思路，便於廣大的讀者和專家看清問題所在，給我更具體的幫助。」

這無疑是誠心的感謝，因為透過金教授的回應，確實充分展現了等效理論的實用性，以及他在翻譯《尤里西斯》時所秉持的認真態度。然而，馮亦代的譯評卻幾乎都不正確且不負責任，例如馮的譯評開頭便說他沒有對照原文書，原來他是光憑另一個譯本的比較，就認定金教授的譯本在十頁內有 36 處誤譯。

面對這種批評，金教授的回應是不慍不火，不卑不亢，實在令人欽佩。然而，轉念一想，自己從前也曾批評過別人的翻譯，又有多少是未經深思熟慮和查證就貼在部落格上的呢？想來真是汗顏。網路上也不乏因為翻譯而引發的爭論（例如這裡和這裡），在評論別人的譯作時，又怎麼能不多加謹慎呢？！

最後，引用電影《料理鼠王》片尾的一句話，藉以警惕自己：

In many ways, the work of a critic is easy. We risk very little yet enjoy a position over those who offer up their work and their selves to our judgment. We thrive on negative criticism, which is fun to write and to read. But the bitter truth we critics must face, is that in the grand scheme of things, the average piece of junk is more meaningful than our criticism designating it so.

「評論家的工作很輕鬆，我們不必冒什麼風險，卻擁有評論他人及其作品的權力。我們吹毛求疵批評別人，樂此不疲。但坦白說，大部分被罵得一文不值的作品都比我們的評論有價值。」

這是我的翻譯學書單（也算是推薦）：

1. 等效翻譯探索（增訂版）。金堤 著，書林 (1998)。（等效翻譯的理論闡述與翻譯技巧討論）
2. 翻譯研究。思果 著，大地 (2005)。
3. 翻譯新究。思果 著，大地 (2001)。
4. 翻譯教程—翻譯的原則與方法。Peter Newmark 著，賴慈芸 譯，朗文 (2005)。
5. 英漢翻譯理論與實踐。葉子南 著，書林 (2004)。
6. 齊向譯道行。金聖華 著，三民 (2008)。（翻譯心得類，散文體）
7. 新編譯藝譚。黃邦傑 著，書林 (2006)。
8. 余光中談翻譯。余光中 著，中國對外翻譯出版公司 (2002)。（簡體，無繁體中文版）
9. 翻譯實務。周兆祥 著，台灣商務印書館 (1995)。（入門書）
10. 因難見巧。金聖華 著，三民 (1996)。
11. 翻譯論集。劉靖之 編，書林 (1989)。

在原文書中碰到 orthogonal 時，總是會讓我停下來，想想作者要表達的意思到底是什麼。我在 Collins COBUILD Advanced Leaner's Dictionary 2006 和 Longman Dictionary of Contemporary English 4th Edition 都查不到這個單字，但是分別在以下網路資源中找到這個單字的中文翻譯：

• 顏元叔網路辭典：(幾何)長方形。
• Yahoo! 奇摩字典：【數】直角的;矩形的。
• 中文維基百科：正交。

另外，從 Google 也可以查到一堆採用 "正交" 作為對應中文的例子。

試將這些查到的中文詞彙套用到以下例句：

Alternately, we can cut across the system in an entirely orthogonal way.
譯：我們還可以用另一種完全正交（矩形、直角）的方式切割系統。

However, the fact remains that we cannot construct a complex system in both ways simultaneously, for they are completely orthogonal views.
譯：然而，事實上我們無法同時用兩種方式建構系統，因為它們是完全正交（矩形、直角）的觀點。

上述例句摘自 Grady Booch 的 Object-Oriented Analysis and Design with Applications 3rd Edition，前後文主要是在討論演算法分解（功能分解）與物件導向分解這兩種分割系統的方式。即使有完整的上下文，看了這種直接對號入座的譯法恐怕也是讓人摸不著頭腦。

中文的資源不夠用，最好的辦法就是找原文的解釋了。以下解釋摘自英文維基百科（在該字的 Derived Meanings 小節）：

Orthogonality is a system design property facilitating feasibility and compactness of complex designs. Orthogonality guarantees that modifying the technical effect produced by a component of a system neither creates nor propagates side effects to other components of the system. The emergent behavior of a system consisting of components should be controlled strictly by formal definitions of its logic and not by side effects resulting from poor integration, i.e. non-orthogonal design of modules and interfaces.

以下則是 SearchStorage.com  的解釋：

In geometry, orthogonal means "involving right angles" (from Greek ortho, meaning right, and gon meaning angled). The term has been extended to general use, meaning the characteristic of being independent (relative to something else). It also can mean: non-redundant, non-overlapping, or irrelevant. In computer terminology, something - such as a programming language or a data object - is orthogonal if it can be used without consideration as to how its use will affect something else.

從以上的解釋可以發現，orthogonal 有許多衍生意義，而用在前面舉的兩個例句時，比較適合的翻譯應為「無關」、「互不影響」（「正交」一詞反而讓人覺得涉及的事物彼此有關、有交集）。根據這些線索，試將前二例句重譯如下：

Alternately, we can cut across the system in an entirely orthogonal way.
譯：我們還可以用另一種截然不同的方式切割系統。

However, the fact remains that we cannot construct a complex system in both ways simultaneously, for they are completely orthogonal views.
譯：然而，事實上我們無法同時用兩種方式建構系統，因為它們是完全不同的觀點。

這裡我將 orthogonal 均譯為「不同的」，主要是希望在不離原意太遠的前提下，讓句子讀起來更順。也許您有更好的譯法？