国际化方案的思考——方案选型的重要性

国际化方案的思考——方案选型的重要性

          中文版功能实现以后，根据部门进度要求要实现英文版（除简体中文外的系统都设置为英文）。个人最初的理解，无非是将供客户使用的部分（界面、提示信息）由中文改为英文，无非是工作量的问题。但实际操作3周发现，远远比我想象的要复杂很多。

一、方案选型

        为提高工作效率，选用其他部门在Linux系统下已经实现过的成熟的方案gettext抽取替换方案，详见http://www.gnu.org/software/gettext/。

       gettext方案原理如下：

       第一步：从源程序中提取出中文字符，包含文件路径、行号、中文字符。如下：D:\TestDemo\TestDemo.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的时候其实本人也是采取了替换，确保单一变量的方法但没有坚持，耽误了时间。去请教大牛，其也是采用了同样的方法，但其注意每一个提示的细节，搞清楚为什么不的原因，最终搞定。印证了老罗的一句话“天才的一半也是勤奋，只是这一半隐藏的比较深而已”。

2014-3-14 pm21:00 思于家中床前

作者：铭毅天下

转载请标明出处，原文地址：http://blog.csdn.net/laoyang360/article/details/23618877

如果感觉本文对您有帮助，请点击‘顶’支持一下，您的支持是我坚持写作最大的动力，谢谢！