前两天OTA WM客户端为了字符串资源的问题进行了激烈的交锋.
一派主张使用INI文件来定义字符串.
另一派主张使用VC的资源文件来定义字符串.
鉴于交锋很激烈,双方都很有道理.所以我在此就不点评了.直接抛砖引玉了.
在头文件中这样定义字符串数组:
const char* StrTab_Connecting[] = {
"正在连接..."
,"Connecting..."
};
const char* StrTab_Disconnection[] = {
"断开连接..."
,"Disconnection..."
};
const char* StrTab_Login[] = {
"正在登录"
,"Disconnection..."
};
const char* StrTab_Logout[] = {
"退出..."
,"Logout..."
};
.................................
这样使用字符串:
StatusNotify(StrTab_Connecting[Config::GetLanguage()]);
说明:其中 StatusNotify() 函数要求传入一个字符串做为参数
Config::GetLanguage()从配置中读取语言设置 0:中文 1:英文
That's all.就这么简单.
现在来说说这个方法的优点:
1, 用头文件定义,更符合C++程序员使用习惯.如果交由专业人员进行多语言的翻译工作,那么可以让他们直接修改
这个头文件,由上可见,这个头文件的格式还是很简单的,翻译人员应该可以理解,并且适应. 另外,翻译完的还要再编译
一次,可以由编译器检查出不小心造成的格式错误
2, 效率高!!这一点就不多说了.
3, 使用字符串处的代码简洁,可以省去很多的 if else switch case .....
以上,仅供参考.
另附上讨论意见:
这个方法确实不错,核心思路和ini文件的一样,就是把文字资源集中到一个非常规律
的文件中,使得翻译打包快速了很多, 不过似乎有一个致命缺陷,整个产品有多个工程
组成(exe,DLL),OTASecure有10个,为了使所有的进程和DLL 的文字都统一到这个文件
中,这个文件必须在基础的DLL中,其他工程依赖他,然后将其导出给其他所有工程用,
这些工程中的所有界面文件都包含他,这样没往里面添加一个字符数组,就会引发所有
的界面文件编译,每一次编译几十分钟。从而极大地增加了软件的开发周期。
可以考虑改进,将字符串的寻找选择封装在cpp中(给一个nRescurceID和nLanguageID)
在cpp中返回一个string。翻译时翻译这个cpp。
按你的使用方法是有可能会加长编译时间.但是应该也不至于到影响开发周期的程度.
另外,还有是办法避免你提到的问题的.
你可以建一个单独的DLL工程,这个工程只包含这些字符串的定义,然后导出所有的字符
串.要使用字符串资源的工程直接依赖它.这样如果新增一个字符串的话,只要编译这个工程
就可以了,其他的工程可以完全不用重新编译.而且可以在软件发布以后方法地单独升级语言.