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

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

          中文版功能实现以后,根据部门进度要求要实现英文版(除简体中文外的系统都设置为英文)。个人最初的理解,无非是将供客户使用的部分(界面、提示信息)由中文改为英文,无非是工作量的问题。但实际操作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

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

©️2020 CSDN 皮肤主题: Age of Ai 设计师:meimeiellie 返回首页