吳信儀(Mark Wu)
開放原始碼專案dotProject中文化負責人,同時也是LifeType部落格系統的開發團隊。


dotProject是一套以PHP撰寫的專案管理系統,日前甫釋出2.1版RC1中文化版本,同時支援正體、簡體中文。

吳信儀(Mark Wu)是中文化的負責人,在這次修改dotProject過程中,遇到不少開放原始碼在中文化過程中常見的問題,而過程絕非僅只「翻譯」兩字就能概括。因此我們請吳信儀縱談中文化實務的經驗,藉此了解進行中文化時需要的技術與心態。

問:這次進行dotProject中文化過程中,遇到哪些問題?
答:由於dotProject在設計時,沒有考慮像中、日、韓這些多位元組字串(multi-byte string)的使用環境,因此有些程式就會出現問題。

以日曆為例,不管是月份或是星期,英文環境有使用全寫和縮寫的習慣,因此系統會去抓取全寫的前三碼當作縮寫,但中文的星期標示是「星期一」、「星期二」這種方式,而且一個中文字是由二個字節所組成,因此抓取時等於抓到「星」字和半個「期」字,在顯示時就會變成亂碼,就算不是亂碼,抓出來的字也不具意義。

問:你如何著手改善系統不支援多位元組字串的狀況?
答:首先必須先了解程式是如何顯示這些亂碼,再一步步往回追蹤其中牽涉的函式。找到源頭後,果然發現dotProject是採用抓取字串的方式取得縮寫,因此就必須加上一個判斷變數,讓它偵測到多位元組語系後,去指定的縮寫陣列讀取資料。修正這個問題之後,不只是中文,連日文、韓文都可以納進這個架構。

問:在你的部落格上曾經提到,dotProject使用中文,會造成圖形無法正常顯示?
答:這個問題是出在甘特圖上。dotProject開發團隊寫出繪製甘特圖的程式,利用JpGraph函式將文字「畫」上甘特圖,而它需要有字型的支援,才能正常運作。之前會出錯是因為系統缺乏預設的中文字型。

這個部分原本是只要找到支援的中文字型就可以,例如說BIG-5碼常用的細明體,或是簡體字常用的仿宋字型(Simsun.ttc),不過為了能夠將正體、簡體中文同時同時顯示在一個畫面上,系統編碼就必須採用UTF-8,字型也就得找支援UTF-8的,最後就採用Firefly字型來對應,於是順利解決甘特圖顯示失敗的情況。

問:像Windows中文版作業系統,採用BIG-5碼作為預設編碼,許多應用程式也是如此,為什麼不採用BIG-5碼呢?
答:第一個考量點,當然是希望能同時讓正體、簡體中文,呈現在同一個畫面上,而這只有UTF-8能辦得到。

其次是當初BIG-5碼在編碼時,使用到ASCII碼上的一些控制碼符號,像是「\」或是「|」這些符號,而有所謂的「許、功、蓋」問題。許(0xA55C)、功(0xB35C)、蓋(0xB35C)的低元碼便是用到「\」(0x5C)控制碼,而被拿來作為這類問題的概稱。

當用戶端將這些字傳到伺服器時,系統會自動再加上一個「\」,才會被視為文字,但是不見得所有的應用程式都能處理這樣的作法,因此有時是顯示文字時多了「\」符號,有時是根本無法正常顯示。如果採用BIG-5,這些問題就會層出不窮,像dotProject也會抓取作業系統的環境變數,而使得顯示上發生問題,因此根本解決之道是使用UTF-8。

企業如果採用新系統,應該盡量使用UTF-8編碼,不但可以讓正體、簡體同時顯示,也可以避開「許、功、蓋」問題。不過如果是既有的系統,要不要從BIG-5碼轉換成UTF-8就要慎加考量,沒有人能保證轉碼過程中不會出現問題。

問:在你開發LifeType時,也會遇到這些中文化的問題嗎?
答:很有趣的是,全世界有兩個地方語系相當多,一個是亞洲,一個是歐洲,因此只要是這個兩個地方釋出的程式,多半會有良好的國際化(I18N)架構,可以支援許多語系,雖然不見得中文都沒問題,不過至少在架構上會好很多。相對來說,美國人開發出來的程式有時就比較不注重國際語系的問題。而Lifetype是由西班牙人所設計,因此在中文化上問題少很多。

問:你覺得開發人員參與開放原始碼中文化有什麼意義?
答:其實中文化不只是翻譯,在中文化的過程中,必須去讀別人的程式碼,去修正因為語系不同而產生的Bug,這些問題會讓中文化的過程變得有趣,可以當作在練功。一旦找到問題回報給開發社群,對開發專案、社群也都有實質的幫助。整理⊙黃天賜

熱門新聞

Advertisement