國際化方案的思考——方案選型的重要性

前言

中文版功能實作以後，根據部門進度要求要實作英文版（除簡體中文外的系統都設定為英文）。個人最初的了解，無非是将供客戶使用的部分（界面、提示資訊）由中文改為英文，無非是工作量的問題。但實際操作3周發現，遠遠比我想象的要複雜很多。

一、方案選型

 為提高工作效率，選用其他部門在Linux系統下已經實作過的成熟的方案gettext抽取替換方案，詳見

http://www.gnu.org/software/gettext/

。

gettext方案原理如下：

第一步：從源程式中提取出中文字元，包含檔案路徑、行号、中文字元。如下：D:TestDemoTestDemo.cpp:52  “提示資訊”；

第二步：用gettext官網提供的處理方式，将中文字元生成po檔案，可以以一個工程為一個機關或者多個工程一個機關生成；

第三步：用gettext官網工具将po檔案中的中文，對應翻譯為英文；

第四步：将po檔案生成為mo檔案，mo檔案能夠被工程運作時候識别，并能将翻譯的英文在對應的程式位置替換中文串。

二、中途發現方案遇挫

貌似gettext方案天衣無縫，我們團隊很快按照步驟一到步驟四展開。前期提取中文字元、轉換也花費了幾天時間。但是，當基本生成mo檔案測試的時候發現，部分中文替換成功，部分顯示為亂碼。

究其部分為什麼沒有轉換成功的原因，可供參考的也隻有gettext官網windows部分的解釋文檔，大緻是下載下傳gettext源碼在windows下調試，需要搞清楚gettext源碼實作部分的原理，難度較大。并且由于英文版時間有限，不能在此處糾結太久，是以導緻gettext方案擱淺。

三、重選方案

衡量下核心供使用者顯示的中文串的數量，分到每個人身上也就有不到1000個中文字元串需要處理。Windows程式主要分布在源碼（.c/.cpp/）、rc檔案、打封包件nsi中。并且Windows的rc檔案手動複制就可以選擇語言，由中文變為英文，如下圖所示，然後修改對應rc檔案即可（用nodepad++處理會更快捷）。

核心的cpp或者c程式檔案的中文串，可以通過單獨提取出中文串，存儲到rc檔案中，中文、英文各一份，用到中文的地方通過Loadstring來加載就基本能搞定。用法可參考msdn, 如：LoadString(hInstance, IDS_APP_TITLE, szTitle, MAX_LOADSTRING)。

該方案看似老土，但對windows程式能確定在英文系統、繁體系統下不會有亂碼，一勞永逸。

四、方案選型思考

1、“心急吃不了熱豆腐”，方案選型着實非常重要。對于方案可能的風險也要在前期有一定的評估，才能確定方案的正确性、可行性。

2、方向的确很重要，方向如果出錯，前期大量的時間都會是無用功。

3、在調試bug的時候其實本人也是采取了替換，確定單一變量的方法但沒有堅持，耽誤了時間。去請教大牛，其也是采用了同樣的方法，但其注意每一個提示的細節，搞清楚為什麼不的原因，最終搞定。印證了老羅的一句話“天才的一半也是勤奮，隻是這一半隐藏的比較深而已”。

作者：銘毅天下

轉載請标明出處，原文位址：

http://blog.csdn.net/laoyang360/article/details/23618877