書摘:《知識的騙局》

9/20/2007

中文書名:知識的騙局
英文書名:Fashionable Nonsense
作者:Alan Sokal, Jean Bicmont
翻譯:蔡佩君


翻譯這本書想必極為不易,其難度一部份來自於內容本身所涉及的專業知識領域,一部分則來自引用其他學者在其論述中使用的晦澀詞句。即使翻譯成中文,許多詞句對於像我這種未接觸過相關領域(精神分析、科學哲學、知識論、後現代主義、相對主義等等)的人來說,閱讀起來還是有些吃力,目光老是在同一個段落的文字間反覆遊走,試圖捕捉看似毫無關聯的詞彙之間組合起來的意義。在沒有原文對照的情況下,有時也不易分辨究竟是原文就這麼難懂,還是因為翻譯成另一種語言的緣故(除了那些帶有特定科學術語的敘述,這些肯定是我自己的專業素養不足)。不過,還是有極少數明顯是中文語句不通的情形,例如第五章開頭的第一句:「路希‧伊莉嘉萊的著作處理的很廣泛主題,從精神分析、語言學到科學哲學。」

這本書我只認真看了前面兩章,到後面我的腦袋已經被各種科學術語和理論搞得頭昏腦脹,無法保持閱讀的興趣了。因此,以下的書摘僅包含前面兩章的部分。

========================================
ch01: 導言

我們必須強調,不懂微積分或量子力學並不是可恥的事。我們所要批判的是某些著名知識分子的虛矯,假裝能未他們所瞭解的複雜主題提供深刻的思考,但他們的瞭解頂多只是在通俗的層面。 (p.13)

不論是物理學、生物學、或社會科學,以象徵符號或公式來包裝半調子的理論(half-firnykated theory),於事無補。

注:以上點出了作者撰寫本書的動機,以及對學術道德的看法。

任何一種介入的(intervention)的知識價值,是由其內容所決定,而不是由發言者的身分,更不是他的文憑。 (p.18)

注:「介入的(intervention)的知識價值」?


......一般說來,一個領域的實質知識愈豐富的話,對文憑的關心就愈低,而對內容的關心也愈高,這樣說似乎是公平的。 (p.19, 註11)

注:當我們看到一篇立論精妙的文章,對作者大感佩服時,如果有人告訴你,作者在該領域並沒有碩士、博士的文憑或顯赫的頭銜時,是否會立刻減損你對他的評價?甚至開始質疑,作者有什麼資格談論些主題?


ch02: 雅克‧拉岡

拉岡對數學的偏好,在他的作品中絕非無足輕重。1950 年代時,他的書寫中就滿是圖表、公式、和「算式」。為了加以說明,讓我們摘錄 1959 年講座中的一段:

『我在寫註解的時候腦中出現一些公式,如果你們允許我使用其中之一--人的生命可以定義為一個微積分,其中零是無理數(irrational number)。......』

在這段引文中,拉岡將無理數和虛數混淆,還宣稱是「確實的」。 (p.31)

注:論文是否一定要有密密麻麻的數學公式和眼花撩亂的圖表,才稱得上好論文?不過,拉岡把人生定義(應該只能說類比吧)為一個微積分的創舉,就個人膚淺的觀點來看,卻再合理不過--我恐怕永遠都搞不懂人生,就像我永遠都搞不懂微積分。(彷彿又聽見吾友 Twgif 對我說:「這就是人參。」Ick!


......但在兩頁之後,拉岡回到同樣的主題:

『......這就是為什麼我冒著招來輕蔑眼光的風險,指出我在使用數學算式時將之扭曲到什麼程度:根號負1 的符號--在複數理論中仍被寫成「i」--顯然只是因為它在後來的用法中沒有主張自動性,因而擁有正當性。
......
因此,豎立起來的器官變成象徵快感的地方,不是在它自身,或甚至在一個意向的形式上,而是作為在欲求意象中匱缺的一部分:那就是為什麼它等同於上面所產生的表意過程的根號負1,快感的根號負1,是它藉由它的陳述對於意符(-1)匱缺之函數的係數而回復的。』(拉岡 1977b,317-320 頁)

坦白說,看到我們豎立起來的器官等於根號負1,實在令人苦惱。 (p.33)

注:雖然我看不懂拉岡這段話在講什麼,但是「快感的根號負1」,還真是一整個歡樂啊!無厘頭的程度恐怕連周星馳也自嘆不如。作者對拉岡這段話的評論,也頗令人莞爾。


長久以來,拉岡的書寫愈趨神秘--這是許多宗教聖典的共同特色--結合了文字遊戲和破碎的文法,好讓他的門徒虔誠地做註經的工作,恰好適合作為基礎。人們或許會想知道,究竟我們面對的,是不是一種新的宗教。 (p.47)

注:為了塑造自己擁有博大精深學問的形象,論文變成造神的工具,而許多信徒也努力試圖解釋那些看似謎團、夢囈般的論述。此時,科學竟成了另一種形式的宗教信仰,甚至迷信。

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

有些人真正發現了一些東西,並將他的發現寫成論文;有些人以為他發現了一些東西。而其他人,或許只是企圖說服別人他真的發現了一些東西?

專業術語一定要翻譯成中文嗎?

8/06/2007
上回寫了一篇關於 property 和 attribute 如何翻譯的問題,這次要記錄的則是自己在翻譯時碰到的另一個問題:專業術語是否一定要翻譯成中文?

一般來說,翻譯專業術語有個通則,即第一次碰到時採用中英並陳的方式呈現,例如:設計模式(design patterns)。往後再碰到就一律直接以中文表達,不再列出原文。

但有些術語用中文表達時會覺得很生硬(個人主觀上認定),例如:session、callback、code-behind....等。對這些術語,我在翻譯時則傾向採用不同的處理方式,也就是第一次碰到時採中英或英中並陳,例如:「callback(回呼)」,往後再碰到時則一律只寫英文。因此,剛才舉的幾個例子,實際上第一次碰到時可能會這麼寫:

session(工作階段)
callback(回呼)
code-behind(程式碼後置)

記得之前曾與幾位朋友討論過類似的問題,彼此各有不同的看法。有的認為,既然是中文版,當然要負起翻譯的責任,盡量讓讀者看中文,否則難免有不用功、偷懶的嫌疑(喂!我花錢買中文版就是要看中文哪...)。

而我個人是比較在意大家平時是怎麼溝通的,閱讀時是否順暢,以及會不會造成誤解。至於是否要 100% 譯成中文,個人倒覺得其次,尤其是 IT 類的書籍。也就是說,哪一種方式讀起來順,就用哪一種--當然啦,這仍脫離不了個人的主觀想法及先入為主的習慣

IT 類的書籍中,很多術語在實際溝通時仍然是以英文為主,例如:瀏覽器的 "cookie",在溝通時很少聽人說:「小餅乾」(除了帶點開玩笑的、非正式場合的討論)。雖然翻譯書籍的本意就是要讓讀者更快吸收原文書的內容,可是有些術語用中文講就硬是覺得怪怪的,甚至可能造成誤解,或令讀者在閱讀時再翻譯回原文(有時還得用猜的),這樣反而失去了翻譯的本意。

要採用哪一種表達方式,恐怕還是見仁見智的問題,每個作者/譯者心中自有定見吧。因此,在翻譯時只好依照自己平日接觸的、以及個人習慣的方式來做主觀上的考量了(當然也還得看編輯大人是否同意)。


後記(2008-5-16):

朱子兄也對此議題發表了更深入的看法,文章的網址是 http://thoughspace.blogspot.com/2008/04/blog-post_10.html


如何翻譯 Property、Attribute 才適當?

7/27/2007
手邊正在翻譯的書籍裡面,property 和 attribute 的出現頻率很高,對翻譯的人來說實在是一項困擾,因為這兩個術語一般都是譯為「屬性」。

舉例來說,提到類別的屬性,這裡用的英文是 property;提到 HTML/XML 的元素屬性,用的則是 attribute。在討論不同主題時,讀者可能很容易辨認中文的屬性指的是 property 還是 attribute,可是如果碰到兩個字同時出現的段落,就有點麻煩了,例如:

「簡言之,ScriptPath 屬性讓你可以從指定的路徑載入外部指令碼檔案,而 Path 屬性則能夠蓋過全域的 ScriptPath 設定,以指定個別的指令碼參考路徑。」

其中的 ScriptPath 和 Path,一個是類別的 property,一個是 ASP.NET 標記的 attribute,如果不明白標示原文,恐怕很難避免讀者誤解。這樣好多了:

「簡言之,ScriptPath 屬性(property)讓你可以從指定的路徑載入外部指令碼檔案,而 Path 屬性(attribute)則能夠蓋過全域的 ScriptPath 設定,以指定個別的指令碼參考路徑。」

但問題不只如此,另一個更讓人頭疼的,是 .NET 的 attribute 語法(微軟線上文件也將它翻譯為「屬性」),以下是個 C# 語言的範例:

namespace Huanlin.WebServices
{
[ScriptService]
public class BookService : System.Web.Services.WebService, IBookService
{
...
}
}

其中的 ScriptService 就是 attribute,如果同一個段落中同時提到 HTML/XML 標記的 attribute 和 .NET attribute,翻譯時就更頭大了,若不適時加注,放眼望去全是一堆屬性,讀者不頭暈也難。

一種方式是碰到 .NET attribute 語法時就維持原文,這是我個人比較喜歡的方式。另一種方式是將 attribute 語法也翻譯成屬性,再以括弧加注,如:屬性(attribute),個人覺得這樣不僅囉唆,對讀者也沒有太大的幫助。也曾經看過有人把它翻譯成「特徵項」,個人也覺得是不錯的辦法。在翻譯時,我可能會採用「特徵項」吧!

Use Case 的擴充(extension)關係

12/07/2006
在最近 reivew 的一個 Use Case Diagram 裡面,發現有用到 Use Case 的擴充關係。那張圖看起來類似這樣:



這張圖得第一個問題,是它看起來還是以功能切割(funtional decomposition)的方式來思考,只是以 Use Case Diagram 的方式呈現。

另一個值得注意地方,是圖中使用了 Use Case 的擴充關係(<>),也就是標示為 "延伸" 的 stereotype(這張圖是用 IBM RSA v6 畫的,它把 <> 翻譯為 "延伸")。就 <> 關係的定義來看,用在這裡並不恰當。以下是我從書中節錄出來有關擴充關係的定義和使用時機:

  • <> 關係可以在現存的使用案例中插入新的行為片段。
  • 就基本使用案例而言,在設計時對於擴充使用案例的內容其實是一無所知的,基本使用案例只是標示出可與擴充使用案例介接的點。實際上,基本使用案例即便沒有介接任何的擴充使用案例,本身的流程也已經非常完整,這點和 <> 關係非常不同。包含關係的基本使用案例若沒有內含使用案例時,本身是不完整的。進一步來說,就是擴充點事實上並不存在於基本使用案例的事件流程中,甚至,擴充點比較像是一層薄膜覆蓋在事件流程的上面。
  • 基本使用案例的的流程並不會知道(或不擔心)哪裡是可以擴充的,所以可以使用 <> 來任意地擴充基本使用案例中的流程。
  • 擴充使用案例(Extension Use Case)一般來說都不是完整的使用案例,也因為如此,所以擴充使用案例是不能具體化的,它們通常擁有多個行為片段,並且是要插入其他使用案例的步驟中。
  • 請你在你覺得有需要時才寫出擴充使用案例,對大家來說,擴充使用案例是很難理解或維護的。不過,在兩種情況下我們可能會需要用到擴充使用案例。最常見的情況是:在某個使用案例中,使用者可能會用到許多非同步或中斷性服務,這些服務都不該影響到基本使用案例。......另一種情況是你希望在已確定不改的需求文件中增加一點東西。
  • 我們之所以發明擴充關係,第一個原因是因為不想修改之前系統的需求文件。

以上文字摘自這兩本書:趙光正翻譯的《使用案例寫作實務:寫作指南、秘訣與範本》,以及邱孝賢康凱雄合譯的《UML 物件導向系統分析與設計》。如果你的工作需要撰寫 Use Case,或者想要學習物件導向分析設計,這兩本書應該會有不少幫助。

話說回來,如果前面的例子不適合用擴充關係,那應該用什麼關係?繼承?應該不至於。<> ?從語意來看,可以解釋為「經費申請」包含另外三個子 Use Case,似乎說得通。但 Use Case 的 <> 關係比較像是函式呼叫的動作,個人是不會這樣用。在不使用新的 stereotype 的前提下,我會把[經費申請]底下的三個 Use Cases 獨立出去,成為另一個「目標等級」(註1)較低的 Use Case Diagram。

註1:在《使用案例寫作實務:寫作指南、秘訣與範本》當中,Cockburn 把 Use Case 的目標等級分為三種:
  • 目標摘要等級
  • 使用者目標等級
  • 子功能目標等級

遠景還是願景?訥兒 (null) 還是怒兒 (null)?其他還是其它?

6/12/2006
遠景還是願景,這個問題已經在腦袋裡待很久了,一直沒去查證。因為從學生時代開始的印象,就是「遠景」。可是後來看到新聞報導,記者說ㄩㄢ、景時,字幕都是打「願景」,而且報紙也都是這麼寫。由於有了先入為主的看法,因此總是覺得不習慣。我常常想,是不是記者諸公們自己覺得「遠」唸成四聲很不習慣?還是認為觀眾只要聽到四聲ㄩㄢ、就會想到「願」?還是創始人用注音輸入法時打錯字,將錯就錯下去?總覺得這是多此一舉的產物....

到 Google 搜尋了一下,原來早就有人發出同樣的疑問,從這些討論可看出一些端倪:

黑白開講:遠景?願景?

玩的就是詞藻(11): 原來Vision是願景

還有人把遠景和願景同時放在一篇文章裡面,並刻意區分兩者的差別(有必要這樣嗎?)。如果那是一篇講稿,不知道聽眾聽到的時候,是否能會意過來,或者以為演講者舌頭打結了?

Null 也是,從唸書的時候就有兩種唸法,我每次聽到就去查一次不同的字典,查了應該有十次以上了吧,卻沒有一本字典的發音是「怒兒」,都是「訥兒」。可是為什麼大家還是唸「怒兒」?還是有哪一種發音系統是唸「怒兒」?若有這樣的字典,請告訴我一聲,我真的想知道。

退一步想,其實不管哪一種唸法都聽得懂,就彼此溝通而言,也就夠了。既然聽得懂,也就沒必要一直去糾正別人了。只是當有人指正我應該唸「怒兒」時,我告訴他字典的發音以後,結果他還是繼續「怒」下去...

只能說,習慣的力量真大。

另外,我通常也只用「其他」而不用「其它」。有一篇文章可參考:http://www.pep.com.cn/200503/ca648420.htm

Responsibility 與 Accountability

5/31/2006

Responsibility 與 Accountability 兩者的意思看起來很接近,都跟"責任"有關,不過如果在同一個句子裡面看到這兩個字,如果都當作「責任」解,恐怕就不大恰當了。在網路上找到大陸網站的一個討論串,把其中一帖我覺得不錯的見解轉帖在這裡,以便日後參考(不過第一段的最後一句我實在不懂是什麼意思):

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

作者:川人 - 1999/11/19 20:08:22 ***

大家都知道,「accountability」和「responsibility」不一樣,在很多情況下不能簡單翻譯成負責或責任制。沒有 accountability 的身負重要 responsibility 的人難道見得還少麼?

「Accountability」的意思是要有人負責,或要對別人負責,出了岔子要有人拿來是問。英文裡常說:「the buck stops here」,就是說,責任最後由我來負。而這句話後面的概念,就是「accountability」。比如說,「There should be accountability in the management of funds」,言外之意,如果查起帳來,要有人出來解釋、承擔責任。萬一都是呆賬、死賬,問起來互相踢皮球,那就是沒有 accountablity 了。

話是這麼說,但「accountability」這個字的譯法只應根據上下文而定,不應為其硬性定出省事的固定譯文。這是因為咱們中國從前沒有與「accountability」相應的概念,所以唯一的辦法是在翻譯時隨機應變,用各種辦法準確地表達出原文作者在上下文中要傳達的資訊。

幾個例子:
1. There should be accountability in the management of funds.
應該有專人對資金的管理承擔責任。

2. To establish accountability in the newgovernment.
給新政府規定出一套責任究問制度。

3. The accountability for the behavior of the soldiers rests with the commander.
對於士兵們的行為要拿指揮官是問。或,指揮官要對士兵的行為負責。

說完「accountability」,想起另外一個有關的話題。

低層次的翻譯,原文一個字或一個片語都有一個或幾個固定的譯法。比如「mutual fund」都翻成共同基金。但好翻譯的難度在於隨機應變,用各種辦法譯出那些沒有固定譯法的字或片語,準確說出原文的意思。而且在很多情況下,一些詞或片語不翻出來反而更能表達原文的意思。

比如說:「To set up a time frame for the completion of the process」。有太多人把「time frame」翻成「時間框架」,其實只要說:「為這項工作定出完成時
間」就夠了。

川人
=============================================

轉貼來源:這裡的accountability怎麼翻?

技術提供:Blogger.
回頂端⬆️