cahier lukhnos

OpenVanilla 0.7.2 (beta) 發表了。

外表上的變動不大：程式核心不變，架構上也沒有什麼革命，不若0.6到0.7時，API翻天覆地，加入了「輸出模組」這種新想法等等（API更動是OV是否能進一個大版本的依據）。不過，我自己覺得，就版本發表所做準備工作的份量，這可以算一個主要版本了。

先說功能上的變化好了，OpenVanilla從0.7.2版開始列名在「Unicode輸入法」中，在系統表列中再也不是歸類在「繁體中文輸入法」。這個變化的意義，既是象徵性的，也是實質上的：OpenVanilla有一定數量的簡體中文使用者，說不定還有其他語言的使用者（例如藏文、閩南語白話字等等），這一版也正式將UIM-Anthy日文輸入法支援給包裝進去了，再怎麼說來，OpenVanilla都不該只是「繁體中文」的輸入法架構。改列Unicode名下，既爭得面子，也有裡子：用Microsoft Word等會接收語系訊息的文書處理軟體，終於不會有字型亂換的情況了。

另一個重要的功能，自然是實驗性的「詞彙管理模組」。簡單說呢，這是一個「超越輸入法」或者「跨在輸入法上」的新模組。我們把這一類模組取了個抽象名詞，叫「鍵碼前置處理器」（key preprocessors）──是的，繼「輸出轉換模組」（output filter）之後，我們又在「輸入法」的設計理念上搞怪了。目前詞彙管理模組能做的事很簡單：記錄你打出的詞，將之存入資料庫。等你下次要用的時候，只要按下啟動模組的快鍵，敲進當時存入時聯結上的關鍵詞，噹噹，就可以叫出一大串字。這東西不依存在任何輸入法裡面，因此不管你打倉頡還是注音、五筆還是雙拼，都可以叫出這個管理模組來。更棒的是底層的資料庫是SQLite，因此你儘可對這資料庫做任何增刪動作，不一會兒轉到別的視窗，又可以輕鬆劈哩趴啦打出一串新加入的詞。詳細的使用方法，唔…… 我還要再找時間發表到#osxchat blog上。不過，有圖有真相，hlb已經幫我把想說的話給說了，大家就先去那邊看兩張圖（順便再幫他升升page rank？）吧。

其他像是修正錯誤、增加效能等等。不過，真正讓我覺得這陣子的工作，有如準備一個主要版本（major release），還是因為許多內在的工作。

像是重新整理程式碼、網站搬家、寫新文件、做軟體包裝等等。

本來兩週前，想趁每天工作的空檔，一一完成上面那些工作的。結果哪想得到竟然一做就是兩週，而且每一天都在跟做「工作」之間掙扎（就不說我還有兩個deadline要趕了）。實情是，每一件「重整」工作都龐大得不得了。

例如重新整理程式碼這事，先從為每個程式碼加上版權宣告的檔頭，還要問每個模組的作者要不要用這個或那個授權──是的，這實在是很「務虛」而不「務實」的事，可是我總認為這種抽象制度面層次的整理，畢竟還是有必要的。

又好比，OV的”build system”──也就是大家說的那個”make ; make install”的部份──也因為有一段時間了，需要加以整理和更新。有些目錄配置不太合宜的也該大幅搬動。目前的問題是因為檔案搬家幅度太大，Linux/FreeBSD/Windows版本想必是編不出來了。這一點可能要由關心以上兩種版本發展的朋友來接手了。

至於網站搬家和寫新文件，也同樣是龐大得不得了的事。從評估要用哪一套網站系統、測試安裝、熟悉、點點點（剛裝起來MediaWiki的繁體中文翻譯檔時，實在是…… 只能用「點點點」來形容），到後來的建置內容、搬家、比對，也都是相當花時間的事。

最後當然是「包裝」這件事最花時間。因為OS X的輸入法很特殊，每一次改完新版本、做好安裝包，就得先清掉自己系統內原來裝好的程式，重開機，然後測試安裝、重開機、測試結果…… 如果一切順利，那就可以轉到第二階段，用另一顆硬碟上裝的「空白」OS X開機、安裝、重開機、測試結果…… 其中免不了要看看檔案是不是裝對了，顯示的說明有沒有錯字（還得看英文、繁體中文、簡體中文三個版本）。

於是，因為這樣的過程，讓我開始對那些寫手冊、作網站、作包裝（installer）的人，開始佩服起來。我猜這些功夫大體上不脫一個「磨」字，不是主角，可是卻是把主角（軟體）推上桌面的重要陪襯或過場。

到最後呢，覺得每一件事情都有其收獲，像是網站搬家的事讓我對MediaWiki有多一些認識，至於包裝過程則是讓我發現原來OS X的磁碟映象檔（.dmg）裡還有這麼多花招或包裝時要注意的地方。

就這樣，這一階段的「新版發表工作」終於完成。其實我們2005年11月17日的時候，在mailing list上就覺得可以開始進行0.7.2版的工作了。實際情形是…… 兩者之間，有整整八週的距離啊。

我們網頁的家也搬完／「重新裝潢」好了，英文版網頁也有了個簡單的概要說明，捐款贊助活動也持續進行。希望大家都能繼續有好用的輸入法能用囉。

最後，最後：照過去的習慣，每次一有版本發佈，我都會有好幾天時間，不時盯一下OV新版有多少人download。不過讓我好奇的是，自從去年八月發佈0.7.1後，那個安裝套件竟然有超過6,400次下載…… 讓我非常好奇：到底有哪些人在用OpenVanilla呢？如果你有在用OpenVanilla、有在看我的blog，先前沒有在我的blog上留過言，又有興趣浮上水面的話，就，出個聲吧！

lukhnos :: Jan.19.2006 :: tekhnologia 技術或者藝術 :: 4 Comments »

近來為了在重整openvanilla.org wiki的內容，也同時順便survey了一下通行的幾套wiki系統。MediaWiki是Wikipedia的核心系統，最大的好處是具有相當成熟的多語系支援，包括了多語系的介面，以及許多配合多語系網站所需的功能（例如：在頁面左側，顯示這篇文章還有哪幾種語言的版本）。

我認為openvanilla.org至少必須要有三種語言版本：繁體中文、簡體中文，以及英文。事實上繁體中文又可分為台灣繁體中文及香港繁體中文，簡體中文以中國大陸為主，新加坡也有一些特殊用語。但以openvanilla.org的詞彙使用範圍，有繁體中文及簡體中文，應該就相當合用，英文版當然是為了非中文使用者的需要（例如不會講中文的藏文使用者、希望拿OpenVanilla拿協助歐語輸入的西方使用者，或是看英文較快的中文使用者等等）。延伸來看，做為一個從中文世界起源、而服務性質不限於中文使用者（也許姑且套用中國大陸的構句法，叫「具有面向世界的服務性質」），這樣一個網站，的確應該要至少有中文及英文兩種版本，而中文如果能支援繁體及簡體，自然是更貼心的。

MediaWiki的優點及問題

如果我們暫且忽略Wikipedia過去在中文議題上採取的官方立場^[1]，純粹就MediaWiki這套軟體而論，有很多技術上的設計的確有可取之處，例如自動詞彙轉換可以節省不少文章寫作及編輯校對的力氣。

但是，如果直接拿MediaWiki的正式安裝套件來用，就會發現，簡繁轉換功能，包括了在版面的導覽列上顯示「繁體版」與「簡體版」兩個tab，必須要在語系設為「中文」（zh）的情形下才能使用。而這裡的「中文」，hélas! 指的是「簡體中文」。再仔細往裡面的程式碼探，才更可以發現在物件組織上，程式也都是繞著簡體中文組織的，甚至包括內文以及搜尋的內部工作碼，也都是先轉成簡體中文進行的。

就我來看，這是個「程式碼反應組織意識型態」的案例研究。

實際上的需要

回到務實層面，openvanilla.org的服務對象，最大宗者仍是繁體中文使用者，就比例原則而論，預設（而非「默認」或「缺省」）的語系設定及工作語言，包括內部資料編碼及搜尋，自然應該以繁體中文為主。而，就組織層面而論，MediaWiki的多語網站，是以「一個主要工作語言建一個網站」為原則來鋪設的。就此兩者，我們應該建立的是一個「具有繁簡轉換功能、但以繁體中文為主的中文網站」以及一個英文網站。就此目標來說，MediaWiki是令人稍微傷了點心。

當然幸好多拜MediaWiki有開放的程式碼，我們在此針對MediaWiki的繁體中文語系物件（定義於LanguageZh_tw.php）做修正，依循簡體版的作法，開啟語言轉換功能，並且將預設的內部工作語言改為繁體中文。為了方便，這次的修正暫時省去了香港與新加坡的體例（variants）。如果使用者選用了簡體中文作為預設顯示介面及工作介面，簡體中文也一樣具有繁簡轉換功能，這點是沒有改變的。

我們做的修正

我們順便修正了MediaWiki繁體中文語系檔中，一些與台灣使用習慣差異過大的詞，例如「登錄、退出」改為「登入（或註冊）、登出」，「文件、文檔」一律改為「檔案」，「電郵」展開為「電子郵件」等等。更進一步的修正有賴大家共同雞蛋裡挑骨，至於程式碼的部份則也許有必要再多修正（主要是更改物件繼承及原始碼相依賴結構）──原先的程式碼中，LanguageZh.php（繼承自LanguageZh_cn.php）將LanguageZh_tw.php視為下屬（subordinate）、被引入（include）的對象，我們這版修正中則讓LanguageZh_tw.php引入LanguageZh.php，使得LanguageZh_tw.php成為繼承結構的終端點。

怎麼放到我家的MediaWiki裡？

以上所提及的種種修正，都可以從從這裡取得。安裝方法是：

1. 將該.tgz檔解開（”untar”）
2. 參考LangugageZh_tw.php中，所有標有”MW-SPECIFIC”字樣的句子，將之修改以符合合各別需要；其中有一些「硬塞」（hard-coded）進入、與Wikipedia本身相關的詞句──一共有四處：首頁名（有些人也許希望第一頁文章名稱不要叫「首頁」）、副標（「自由的百科全書」）、著作權警示（目前硬寫進入的是GNU文件授權，這部份應比照英文版，改從LocalSettings.php讀目前授權）以及更動記錄（”recentchangestext”這個key指涉的字串）的政策性文字。
3. 將這幾個.php檔蓋寫至MediaWiki的languages/目錄下（你可能會想要先做一份備份）。

以上的修正檔會不定時更新。我們已在諸如OpenFoundry開設計劃網頁，以來公開發佈這份修正檔（可用svn取得所有修正檔原始碼）。我們也針對詞彙的部份，到MediaWiki的Bugzilla回報系統裡，做了初步的修正建議。

至於新版的openvanilla.org，將在裝潢階段告一段落後開張。:)

致謝

本地化工作（localization; l10n）沒有許多眼珠盯著，就不可能有所做為。感謝以下朋友：pcchen (for MediaWiki), hlb (for terms and testing), Jedi (terms), mjhsieh (for his hawk eyes)。

註解

1. 我不曾參與過所有跟中文Wikipedia現行政策相關的形塑過程與討論。為了避免有簡繁兩種版本（或甚至是台港星中四種版本）而使用各種轉換及城府深厚（sophisticated）的轉換標記，好讓所有文章活在同一個中文Wikipedia的名稱下。為了節省重覆發明輪子而在制度及技術上做許多扳扭（contortion），所費的努力值得敬重。但是是否有必要讓中文變成這麼大一把意義的涵蓋傘，我認為應該仍要有討論及變化的空間。

lukhnos :: Jan.15.2006 :: tekhnologia 技術或者藝術 :: 2 Comments »

2005/12/31舉行的FSCI 2在跨年聲中圓滿結束。OpenVanilla這次出了四個講題。我負責的兩個講題，投影片可由這裡取得：如何應用及部署 OpenVanilla 個別的輸入法模組以及 OpenVanilla Linux Loader移植過程簡介，都是PDF格式。要說明的是，這兩份投影片都是以配合講者口白而做的，平均播放速度是3-5秒一張，所以其實並不是給人看來得到資訊的啦。

三句話的心得報告：(1) gcin某種近似monolithic的架構，在快速增加core feature上有優勢（plug-in架構是增加模組有優勢，但core feature就不見得了）；(2) 試用了Arne Götje（高盛華）製作的台灣閩南語（Holo）字型及他帶的台語注音輸入法計劃，相當有意思──我們當天將資料轉成了OV能用的.cin格式，但因為該輸入法有特殊需要，所以還是得找個時間來寫點code；(3) bluebat講倉頡輸入法演變，投影片上的「倉頡」拼成 CangJei，讓我有一種所謂什麼不孤必有什麼鄰的感覺。XD

lukhnos :: Jan.05.2006 :: tekhnologia 技術或者藝術 :: 9 Comments »

本來一直覺得2006年的第一篇blog應該寫一些特別有意義的東西，結果越是慎重其事越是寫不出東西來（人生似乎常常面臨類似的情境）。結果意外的在今天學到了每日一字。有朋友突然冒出來問：「維他命發泡錠的英文要怎麼講？」就是那種泡在水裡溶解喝掉的。他這麼一問，我才想起家裡可以是有實物的，雖然是德製品，但上面至少會告訴你這東西的「德文」怎麼講吧…… 好，這東西叫Brausetabletten，Brause，查乃德文陰性名詞，發泡飲料，茲茲響的東西是也，可是英文怎麼用soda, sprinkle + vitamin 找，就是找不著正確的圖片（是的，google image是拯救中文翻譯水準的生命線），結果找大一點的德文字典，天哪！Brausetabletten竟然英文叫effervescent tablet，按effervescent意思是「發泡」，也可以拿來形容人朝氣蓬勃貌。拿這詞一查，還可以查到類似止痛藥飲料片一類的藥品，看來是正式的藥品包裝名稱了（錠劑、針劑那一類的）？

另一種說法是fizzy vitamin。這種東西果然沒有在講英文的地方長期生活是不行的啊。

好了，今天的每日一字就到這裡告一段落（我和另一朋友曾討論，這年代如果還要再拍《每日一字》──哪怕是《每日一字》podcasting也行──可以找誰當主持人，想來能夠取代李豔秋的似乎只有雷光夏，可是後者的聲音似乎已經賣了太多房子跟房車了，所以竟然還是只能找李豔秋？此事屬後話，擇日再來漪拉撥纍忒〔elaborate〕一下）。

… 以上。</陽明春曉>

lukhnos :: Jan.05.2006 :: litteris 字與詞 :: 5 Comments »

TOSSUG（台北開放原始碼軟體使用者社群，a.k.a. 「土虱」）在今年（2005）年末，要舉辦「第二次中文輸入自由軟體工作坊」（連結），OpenVanilla團隊也有成員應邀出席，主要有移植OV-IME（Windows版的OV）kanru及pcman（同時也是Windows版酷音輸入法的移植者）以及我。pcman將講解「Windows IME簡介」一題，kanru則講述「OpenVanilla 的 win32 移植」。

除此之外FSCI 2還有許多中文處理相關的講題。歡迎對此一議題有興趣（在這裡，尤其是對 OV/中文輸入法開發有興趣）的朋友共襄盛舉。

我將要講的兩個講題如下，一場主打，一場代打：

講題1 ：如何應用及部署 OpenVanilla 個別的輸入法模組

OpenVanilla自2004年年底推出以來，已經成為許多Mac OS X使用者不可或缺的套件──包括台灣、香港，甚至中國大陸都有使用者。2005年OV也推出了與SCIM的橋接套件，讓OV許多輸入法模組也能初步在SCIM上使用。另外OV也有了 Windows上的初步移植，這部份會由kanru來為我們介紹。

目前看來，OV對Linux/FreeBSD使用者的最大價值，其實不在於做為一個取代 xcin/gcin/SCIM等「輸入法框架」的計劃（這不是OV的priority），反而是希望能提供一些xcin/gcin/SCIM支援未臻理想的輸入法，例如：行列、POJ，或是SQLite-based的泛用輸入法模組等等。

其實，因為OV的設計，個別輸入法模組的獨立性相當高，也可以個別拿出來部署（deploy）使用──OV的Windows實驗，也是在這樣易於部署的設計下誕生的。也就是說，OV的價值毋寧是，提供了一些經過使用者測試、完整度相當高的個別輸入法模組。

因此，這一次的講題，我將主要介紹「怎麼去使用單一的輸入法模組」：使用模組的人需要提供或實作哪些介面──其實說穿了就是如何實作OpenVanilla.h裡定義的抽象類別（abstract classes）──以及有哪些需要注意的地方。希望經由這次的介紹，能讓更多好用的輸入法模組，普及於更多平台或框架上。

講題2：OpenVanilla Linux Loader移植過程簡介

這是我代打的講題。OV 的 Linux Loader 其實嚴格說來是一個 SCIM 的輸入法模組，這個輸入法模組負責去載入 OV 的其他輸入法模組。最早的 OV-SCIM bridge 是從 scim-chewing 「借殼上市」而來的，後來經過 vgod 的努力研究 autotools，而後有了初步可用的 OV-SCIM，後來更有 Debian package 跟 RPM 的出現。

這次講題我會簡單介紹這個「借殼上市」的過程，為何挑選 SCIM 當 bridge 對象，以及 vgod 設計的 OV-SCIM bridge 是怎麼構成的。我會同時利用這個講題，來介紹組成 OV 兩大部份的另一部份──platform-dependent loader（另一部份是上一個講題的 platform-independent modules/IM algorithms）。由於 OV-SCIM 只算是初步的版本，還有兩個很大的部份未實作出來（configuration management以及encoding conversion service），因此 OV-SCIM 目前只能滿足諸如行列及 POJ 使用者的需求。OV 是否能在Linux/FreeBSD 上有後續的發展，端看是否有朋友願意從事這三個領域的工作：(1) 繼續開發 OV-SCIM 或是 (2) 為 OV 尋找新的 bridge 對象，以及 (3) 根基於 (1) 或 (2) 的結果去維護 package（這其實是件相當花時間、相當重要、貢獻絕不亞於程式源頭開發者的工作──deployment）

（P.S. 如果 OV 講題還有時間，lukhnos 會示範〔可能會〕在 OV 0.7.2 出現的「詞彙管理模組」第一版──一個跨越輸入法的詞彙輸入模組。Well, it’s NewYearsEvesEasterEgg. :p）

lukhnos :: Dec.29.2005 :: tekhnologia 技術或者藝術 :: Comments Off

這算是老話題了。Source code到底該譯為「原始碼」還是「源碼」？有不少open source社群的朋友認為，「源碼」比較符合source一詞的本意（來源、源頭）而「原始碼」恐有跟著作權法上的original work的「原始」概念混淆之嫌。

Well，我還是比較喜歡用「原始碼」。以下是我今天在 Tossug mailing list 上列出的理由：

1. 台灣中文裡稱「原始碼」的由來已久，大家看到「原始碼」就會想到source code，而且「原始碼」也已經是通例了。
2. 英文稱source code ，最早與「來源」或「源頭」一點關係也沒有。「原始碼」是相對於「目的碼」（target code）而來的〔ie. 比較接近原始材料 source material 的概念而不是引用出處 information source 的概念〕。
3. 「源碼」一詞每次都要跟人解釋，而且又得扯到source/origin之區分，抑或是著作權法上原始作品（original work）的區別……（但見 (2)，近來年在要中文裡區分 source/origin 的嘗試，我認為是不瞭解 source 相對於 target 所造成的）我認為「原始碼」一詞本身涵義反而清楚明確。

基於 (1)(2)(3) 以及歐康剃刀（Occam’s razor）原則，解釋越短的概念越好（請參見茱蒂佛斯特主演的《接觸未來》一片 :p），因此我支持「原始碼」。

Anyway, it’s just my 0.02 USD.

不過，在從事寫作或翻譯時，我還是會依照收稿機構的慣例。如果是使用「源碼」的機構，我出的文件就會使用「源碼」。理由和跟投稿英國期刊雜誌寫 centre 跟 colour 是一樣的。至於我自己的「內碼」則是「原始碼」。

同樣的事情也出現在「繁體中文」與「正體中文」的區分，不過那又是另一回事了（我使用「繁體中文」）。

PS. ping在mailing list上說，他看到「原始碼」就會想到「原始人」。不過，「原始人」既然不會是 source (wo)man^* 或 original (wo)man^*，那也就用不著擔心「原始碼」被被翻回 “original” code 了吧……

lukhnos :: Dec.27.2005 :: litteris 字與詞 :: Comments Off

其實只是不經意脫口說出「OV為了某宇宙二元檔改了 Makefile，在 FreeBSD 上編就爛了」，結果某人跟某長輩發現這實在是個不錯的教派名字…… 所以兩位，要創黨了嗎？XD

lukhnos :: Dec.24.2005 :: litteris 字與詞 :: 1 Comment »

那時候教拉丁文的神父跟我們說，「拉丁文學了就是要忘的」(Latin is a language you learn to forget)。倒是偶爾他會跟我們說，在哪裡不期而遇見到以前的校友，他或她頭一句話是那第一名詞詞尾變化的口訣：a ae ae am a… 有的學長姐比較厲害，還會背誦凱薩《高盧戰記》或西塞羅《抗卡帝利納書》的「頭一句」話。想想那時打混修的課，的確剩下不多的記憶，但偶爾還是會冒出那時神父半唱半唸的口訣，才真的知道他們教會教人外語，還是很有一套的：音樂和音律比字詞意義更容易長遠地印在記憶中。

像是有首不會忘記的歌，是聖誕節時一定會唱的 Adeste fideles：

Adeste Fideles
Laeti triumphantes
Venite, venite in Bethlehem
Natum videte
Regem angelorum
Venite adoremus
Venite adoremus
Venite adoremus
Dominum

（英文翻譯和 midi 檔可以參閱這裡）

其實蠻好奇想知道這首歌的中文（Mandarin）怎麼唱，以及中文名字叫什麼，有朋友可以指點一下嗎？

今年的我亂七八糟的，對待許多朋友都疏忽了。請讓我說聲抱歉。並利用 blog 跟大家問候一聲，祝大家都平安喜樂。

lukhnos :: Dec.23.2005 :: bon vivant 活 :: 4 Comments »

上週四（12/15）時去旁聽了淡江大學德語系所舉行的一場演講，講者是北京外國語大學德語系的副主任王建斌教授。王教授是海德堡大學博士，中國著名的德語口譯，多年來一直在德國與中國的經貿談判場合（其中包括引進上海Transrapid磁浮列車系統的一系列談判）、國際會議以及兩國領導人會談時擔任口譯工作。這場一個半小時的演講，主要是講述一個同步口譯者（中國稱「同傳」）在專業工作上所需有的心理素質和準備。

王教授演講開頭，以戴高樂（Charles de Gaulle，1890-1970，註）口譯員的故事開場。一次領袖會議場合（中國稱「首腦會談」），戴高樂的隨身口譯臨時生病，由外交部派了一個年輕人上場頂替。臨行前，戴高樂問口譯員：「您對您的工作，做好了一切必要的專業準備了嗎？」戴高樂在意的不是口譯員的服裝、儀表，而是專業的準備──這便是王教授這場演講的重點所在。

王教授提到，在國際政治場合，口譯員在政治人物眼中，多半只是個「孩子」。就算如王教授經驗豐富者，以四十出頭的年紀，為已達知耳順之年、甚至年紀更大的政治人物工作，這其中仍有二三十年閱歷上的差距。而，一個人來到語境陌生的場合，其自然的心理反應必定是不安以及不信任（「這年輕人是否能正確地理解、表達我因閱歷所得的觀點？」是政治人物心中會問的問題）。這樣的不安，加上於對口譯員的不信任，便是口譯員工作的大環境──如果口譯員自身也因能力的不足、準備不夠而連帶地表現出對詞語的不安甚或是不信任，其工作結果便更不易臻於理想了。

於是，口譯員最大的挑戰便在於「如何讓他人信任我們的翻譯」。這問題分成兩個面向，一個自然是口譯的能力、對題材的理解掌握，另一個自然是口譯員的職業倫理（Berufsethik），包括了為雙方（不單只是雇主一方）守密的保持緘默義務（Schweigspflicht）、無論對任何人──尤其是新聞界或外交界的朋友──都不可以透露今日工作內容的至高原則，以及即使會談另一方沒有支付酬勞，仍應蓼力服務等等──王教授認為翻譯這一行無異便是一項「服務業」（Diensleitsung），因此信任與口碑更是禁不起破壞。

在演講的後半，王教授討論了較多技術細節的問題。其中諸如中國外交部和歐洲外交單位，對於外語事務（Sprachdienst）態度的差別：例如在歐洲，從事外事語言事務的人員，可以將口筆譯當做終生職業，因此「高齡」的口譯員在外交場合處處可見，但在中國，往往一個優秀的口譯員在三四十歲之際，主管便會建議其轉任主管職或甚至擔任外交官，這對外交的翻譯工作並不見得是件好事（蓋因此行乃經驗至上）。又好比在歐洲，口譯員都以外語譯母語為主（聯合國也是如此：即便是雙語人，總還是有一個語言的active competence勝於另一個──這是沒有辦法的事），但語言單位仍要求譯者在母語和第一外語之外，還要能通曉至少兩種工作用的外語──起碼要對此二外語有一定的passive competence以備不時之需。除此之外，王教授也透露了一些專業口譯員的辛酸（例如首腦拍新聞照時，要自動識趣地閃一邊，或是國宴上翻譯沒飯吃，要自備巧克力繼續工作等等），以及如何建立自己的詞彙庫等工作上的小竅門等等，才不會在遇到需要翻譯「無罪推定」（Unschuldsannahme）這種詞時傻了眼。

王教授在個人背景上著墨不多，倒是透露了他是八歲時就被選去由中國外交部辦的外語小學，一路念至北京外國語學院（根據網頁，是共產黨建立的學校），然而一直到中學唸完前，所接觸的德語教材，全是俄國人油印的──王教授說他平生學的頭兩句德語，一句是 “Es lebe der Vorsitzende Mao!” （毛主席萬歲），另一句叫 “Lernen nach dem Beispiel vom Kameraden Lei Fong” （向雷鋒同志學習）。當王教授唸到這兩句時，除了在場教授覺得很逗，台下德文系的同學倒是沒什麼特別的反應。

註：我曾在柏林的德國歷史博物館看到一部短片，那是二次戰後戴高樂訪問德國的新聞短片，戴高樂對德國人的演講，是用幾乎沒有法國口音的德語進行的！

lukhnos :: Dec.20.2005 :: litteris 字與詞 :: 2 Comments »

click圖片可以看到比較大尺寸的版本。再更細節一點的版本在這裡。嗯，那個朱墨……

lukhnos :: Dec.02.2005 :: litteris 字與詞 :: 1 Comment »