一、方案选型
为提高工作效率，选用其他部门在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的时候其实本人也是采取了替换，确保单一变量的方法但没有坚持，耽误了时间。去请教大牛，其也是采用了同样的方法，但其注意每一个提示的细节，搞清楚为什么不的原因，最终搞定。印证了老罗的一句话“天才的一半也是勤奋，只是这一半隐藏的比较深而已”。
