The Old Blog Archive (Traditional Chinese), 2004-2009

Archive for January, 2006

的確,我不

本網誌不參與任何串聯寫作活動。

前進了一個小數點後:OpenVanilla 0.7.2 (beta)

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上留過言,又有興趣浮上水面的話,就,出個聲吧!

針對 MediaWiki 中文繁簡轉換所做的修正

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

我認為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),所費的努力值得敬重。但是是否有必要讓中文變成這麼大一把意義的涵蓋傘,我認為應該仍要有討論及變化的空間。

更新:12/31 FSCI 2的OpenVanilla投影片

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

開年的每日一字:effervescent tablet

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

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

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

… 以上。</陽明春曉>