級別: 中級
徐 亞玲 (xuyal@cn.ibm.com), 軟件工程師, IBM 中國開發(fā)試驗室
2007 年 10 月 18 日
在全球經(jīng)濟一體化的今天,網(wǎng)絡讓大家可以共享同等的信息。世界是平的,在這個變平的世界里,我們?nèi)匀恍枰朔Z言和文化的差異, 如果軟件如果能夠做到全球化,以不同的語言和文化提供信息,那么無疑這個全球化的軟件也是讓這個世界變平的力量之一。
Eclipse已經(jīng)成為大家耳熟能詳?shù)拈_發(fā)環(huán)境和架構(gòu)平臺。現(xiàn)在IBM越來越多的客戶端產(chǎn)品移植到Eclipse RCP平臺,本文將介紹基于Eclipse RCP的產(chǎn)品的全球化實現(xiàn)。
Eclipse的文章很多,那么我們就來總結(jié)一下關(guān)鍵詞:開放的可擴展的IDE -> 可插入插件的開發(fā)環(huán)境 -> 帶標準插件集(Java Development Tool, JDT)的JAVA開發(fā)環(huán)境 ->可開發(fā)插件的開發(fā)環(huán)境(Plug-in Development Environment, PDE)-> 開放的可擴展的應用平臺。
Eclipse的開放和可擴展究其根源是運行時組件模式的架構(gòu)(runtime component module),我們可以從C++的純虛基類到COM原理來解釋這些動態(tài)可加載原理,從他們的似曾相識來認知多年來我們不變的追求。Eclipse 使用 OSGi 作為插件系統(tǒng)的基礎(chǔ),OSGi,Open Services Gateway Initiative是一個基于Java語言的服務(業(yè)務)規(guī)范,該規(guī)范和核心部分是一個框架,Eclipse框架采用Lazy loading,提供了運行時可擴展的擴展點模式。
Eclipse Rich Client Platform, RCP, 在Eclipse platform的基礎(chǔ)上增加了GUI的特性,它當然也具備Java的跨平臺特性,是由可構(gòu)建桌面應的最小的一組插件組成的運行平臺。這里面的關(guān)鍵詞/ SWT, JFace,Workbench。首先,Standard Widget Toolkit,SWT最顯著的特點是體現(xiàn)了系統(tǒng)平臺即操作系統(tǒng)的UI的特性,是平臺相關(guān)的套件集合。基于SWT開發(fā)的UI體現(xiàn)了操作系統(tǒng)平臺的UI特征。 JFace在SWT上提供了更高層的封裝,提供了功能強大的界面組建,菜單,工具條,狀態(tài)條等等。 Workbench: 提供了更高層的可擴展可管理的UI, 包括editors, views 和 perspectives。
Eclipse RCP 結(jié)構(gòu)圖片示例
您談到軟件的國際化支持,我們通常會從對字符集,文化習慣和對翻譯的支持也就是對本地化的支持三個方面來考慮。
對于前兩個方面,我們知道現(xiàn)在通過UNICODE字符集來支持全球字符,而文化習慣包括日期,時間,貨幣,地址等等,盡管不同的國家地區(qū)千差萬別,但它的實現(xiàn)通常并沒有我們想象的那么復雜,可以通過調(diào)用支持全球化的組件來實現(xiàn)對字符集和文化特性的支持。例如IBM 中國開發(fā)中心的Globalization團隊就推出過基于SWT的支持文化特性的套件,這些套件可在基于RCP平臺的應用中被重用。所以,在以下的段落中我們會重點來談如何實現(xiàn)Eclipse RCP 軟件對本地化的支持,也就是軟件的可翻譯性。
我們將從以下幾方面探討軟件的可翻譯性:
- 界面布局
- BIDirection
- 可翻譯資源外部化,即資源與代碼分離及資源文件的管理
通常,在傳統(tǒng)開發(fā)中,界面布局問題一直是困擾本地化開發(fā)過程中比較大的問題,由于文本翻譯后引起長度的擴展,導致了界面布局的截斷,對齊和遮蓋問題。如下圖,在翻譯為Greek語言后,出現(xiàn)了很多截斷問題。

圖形界面的布局調(diào)整是一項工作量非常大的工作,我們知道傳統(tǒng)開發(fā)是以矩形來定位控件的布局,即通過坐標值和長度及寬度來描述控件的位置和大小,通常在英文產(chǎn)品開發(fā)過程中,會通過預留一定的擴展空間來解決這個問題,但是翻譯的過程中存在著很多偶然性,經(jīng)常會有一些翻譯過長的字串還會出現(xiàn)截斷問題,同時所有語言共享統(tǒng)一的留有擴展的界面布局降低了界面的友好性,在英文和CJKT這些擴展較少的語言上,我們會覺得界面上有太多的空白空間。
SWT中的Layout manager很好的解決了這個問題。layout manager會管理界面的布局,SWT提供了四種layout manager,在這四種layout manager中,功能最強大,最復雜,也最有實用性的是GridLayout。GridLayout用網(wǎng)格來控制布局。關(guān)于layout manager 有最經(jīng)典的介紹文章,大家可以通過這些文章來了解layout manager的工作原理。本文則是要強調(diào)一定要用layout manager來解決本地化過程中界面的布局問題,在布局設計時要想到本地化后引起的擴展問題,在這種前提下開發(fā),會將布局問題減少到最小,我們在測試Sametime7.5 等RCP的產(chǎn)品過程中發(fā)現(xiàn),布局這一困擾本地化開發(fā)的問題得到了根本的解決。
在SWT的示例程序中,我們可以看到layout manager在本地化過程中是如何自動調(diào)整布局的, 在AddressBook這個例子中采用了Fill Layout 布局管理器,當我們擴展這些界面上要翻譯的字符串時,我們看到界面的布局也隨之自動的擴展變化。


SWT套件允許設置為從右到左RTL,但BiDi的支持與平臺有關(guān),BiDi支持正擴展到所有Windows平臺和GTK的linux平臺。如果產(chǎn)品考慮支持BiDi,需要調(diào)研你使用的SWT版本對BiDi的支持。
大家都知道在Java程序中使用Resource bundle來處理locale相關(guān)的資源文件, 所有要翻譯的資源保存到按照locale命名的properties文件中,通過resource bundle來調(diào)用。Locale這個詞一直沒有很好的翻譯,我們可以理解為語言+地區(qū),我們命名properties文件也會以locale作為擴展,例如中國的簡體中文文件,我們會命名為address_zh_CN.properties, 而臺灣的繁體中文文件會命名為address_zh_TW.properties, 當在中文中國locale下時,程序設計會依順序查找address_zh_CN.properties,然后是 address_zh.properties,最后fall back到address.properties,而在中文臺灣locale下則會查找address_zh_TW.properties,找不到會是地域不同但語言相近的address_zh.properties,最后是英文的address.properties。
如果你在編程時沒有這樣的遠慮,可以使用Eclipse提供的wizard來完成這項工作,這部分也有很多技術(shù)資料可參考。同時我們更應該從程序設計開始就做好資源文件的規(guī)劃,下面我們來介紹一下資源文件的管理,注釋,翻譯和檢查工作。
在一個項目中如何有效的定義,創(chuàng)建和管理資源文件?首先我們會對資源進行分類,按照資源的類型我們會分為User Interface,UI界面資源和User Assisant, UA幫助資源,從最終使用者的角度,資源可分為普通用戶資源和IT用戶的資源。
我們把用戶分為普通用戶和IT用戶,普通用戶是指用戶的領(lǐng)域并非IT領(lǐng)域,例如銀行柜員,盡管他熟悉他所使用的業(yè)務系統(tǒng),但他并非IT專職人員,而IT用戶則特指如程序員,網(wǎng)絡管理員等IT從業(yè)者。從最終用戶來區(qū)分資源,我們可以根據(jù)資源的使用者來確定是否要翻譯這部分資源。通常普通用戶的資源翻譯級別較高,而IT用戶的資源翻譯級別較低,例如一些專業(yè)的調(diào)試出錯信息,IT用戶可能更傾向于使用英文原文信息。
在JAVA項目中,通常UA幫助文件會以html的形式存在,所以我們通常以不同語言命名的文件夾下面。而對于UI文件,正如我們前面介紹的,通常存為filename_{locale}.properties 的文件。
在這里,我們在創(chuàng)建資源文件時要同時創(chuàng)建filenames.properties和filenames_en.properties文件,在filenames_en.properties中存放要翻譯的字串而在filenames.properties中存放版權(quán)信息和不需要翻譯的資源。通過這個簡單的拆分法,我們可以得到很多開發(fā)的方便之處:
- 首先可以保證只有要翻譯的資源被送出去翻譯,而不需翻譯的資源保留在本地不會被改變;
- 當需要翻譯的資源開始翻譯,因而不可以繼續(xù)修改時,不需翻譯的資源文件filenames.properties還可以繼續(xù)更新;
- 首先可以保證只有要翻譯的資源被送出去翻譯,而不需翻譯的資源保留在本地不會被改變;
- 當需要翻譯的資源開始翻譯,因而不可以繼續(xù)修改時,不需翻譯的資源文件filenames.properties還可以繼續(xù)更新;
- 同時我們作偽翻譯測試和資源文件檢查時,也可以有效的判斷哪些是語言相關(guān)的資源和文件。
- 在生成安裝包時,我們可以動態(tài)的將filenames.properties 文件加到filename_{locale}.properties中,而將filenames_en.properties加到filenames.properties中,形成最終的properties文件組。
偽翻譯測試是測試軟件可翻譯性的最有效的手段,通常我們測試軟件的可翻譯性可通過偽翻譯或pilot翻譯來測試。偽翻譯的過程是利用工具將產(chǎn)品中需要翻譯的部分隨機或按照一定規(guī)則進行轉(zhuǎn)換,以這種轉(zhuǎn)換來模仿翻譯的過程,而pilot翻譯則是在英文產(chǎn)品開發(fā)的同時,選擇某種語言例如德文進行同步翻譯。通過產(chǎn)品開發(fā)過程中的偽翻譯或pilot翻譯,測試下面幾類問題:
1.是否有需要翻譯的字符串被硬編碼。當所有的資源文件中的資源被偽翻譯為某種字符,例如全部被轉(zhuǎn)換為圓點符號,那么界面上仍舊顯示為英文ASCII原文的字符串就有可能是硬編碼在代碼中,沒有被偽翻譯的字符串。這些字符串需要被resource out, 才會被正確的翻譯和顯示。
2.對字符集的支持在偽翻譯過程中,我們會把原ASCII字符偽翻譯為風險字符來測試產(chǎn)品對這些特殊字符的支持。關(guān)于風險字符,如果大家感興趣,我會單獨寫一篇介紹文章,每個語言的風險字符不同,另外比如歐元,GB18030字符都是容易出現(xiàn)問題的風險字符。如下給出了一段將ASCII碼轉(zhuǎn)化為重音字符的腳本代碼,基于這種轉(zhuǎn)換,不但可以測試對西歐中歐重音字符的支持,同時保證了程序的可讀性。
ASCII碼轉(zhuǎn)化為重音字符的腳本代碼示例

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

3.界面布局的可翻譯性我們可以選擇按一定比例,例如30%,擴展原文的偽翻譯方式,如果偽翻譯后界面出現(xiàn)截斷,不對齊等問題,說明界面的設計不具備可翻譯性。由于語言的翻譯有很多偶然性,可以隨機的把一些字符串加長,來測試界面對可翻譯性的支持。
4.串聯(lián)字符串在偽翻譯的過程中,我們會通過給每句要翻譯的文本在首尾加上分割符例如[]來發(fā)現(xiàn)這類問題。當一個完整的句子是由幾個片斷拼湊起來的話會為翻譯帶來很大的困擾,例如:
Strings_OutOfOffice = I will be out of the office
Strings_StartTime= starting {0}.
在實際運行環(huán)境中的顯示為:I will be out of the office starting 2007-8-17.
我們可以通過定義在句首加“[”,句末加“]”的偽翻譯規(guī)則,這樣在偽翻譯后:
Strings_OutOfOffice=[I will be out of the office]
Strings_StartTime=[starting{0}]
在實際運行環(huán)境中的顯示為:[I will be out of the office][ starting 2007-8-17.] 如果在一個整句中發(fā)現(xiàn)“][”,則是有串聯(lián)情況出現(xiàn)。
這句話整句翻譯成中文:我從2007-8-17日起不在辦公室。
Strings_OutOfOffice=我不在辦公室
Strings_StartTime=從{0}.
當在資源文件中被分為兩個斷句分別翻譯在進行組合時,翻譯變?yōu)?#8220;我不在辦公室從2007-8-17日”,顯然,這不符合中文的翻譯習慣。所以,在翻譯的過程中,由于不同語言間的文化特性有很大的不同,語序經(jīng)常會出現(xiàn)變化,只有保持句子的完整性,才能保證翻譯的準確性。
以上從開發(fā)和全球化測試的角度介紹了 Eclipse RCP 上的國際化,軟件的本地化是一個比較復雜的工程,在開發(fā)中充分考慮對本地化的支持,使用自動化工具來進行管理會使這個工程更加更加規(guī)范有序
