【VC++开源代码栏目提醒】:网学会员在VC++开源代码频道为大家收集整理了“国际化软件编程规范(c&c++&Delphi&C++Builder&Java版意见征求稿) - 综合课件“提供大家参考,希望对大家有所帮助!
国际化软件编程规范 (意见征求稿) 中兴通讯股份有限公司重庆研究所软件开发部 本文中的所有信息归中兴通讯股份有限公司所有,未经允许,不得外传 第 2 / 36 页 前 言 国际化软件编程规范的目的是为了统一公司国际化软件编程风格,提高软件源程序的可读性、可靠性和可重用性,提高软件源程序的质量和可维护性,减少软件维护成本,最终提高软件产品生产力。
本规范是针对GUI的编程规范,适用于所有产品的后台软件,同时考虑到不同产品和项目的实际开发特性,本规范分成规则性和建议性两种:对于规则性规范,要求所有软件开发人员严格执行;对于建议性规范,各项目编程人员可以根据实际情况选择执行。
本规范的内容包括:基本原则、界面风格、界面元素、交互设计、国际化、帮助文件等。
涉及的语言有C/C/JAVA。
规范最后给出了附录及模板供软件人员参考。
附录中介绍目前在主流开发工具下的具体操作方式和反例。
本规范起草部门:网络事业部重庆研究所软件开发部。
本规范主要起草人:国际化软件编程规范小组。
本文中的所有信息归中兴通讯股份有限公司所有,未经允许,不得外传 第 3 / 36 页 前 言 ......................................................................................................................................................... 2 1 范围 ......................................................................................................................................................... 4 2 术语和定义 ............................................................................................................................................. 4 2.1 原则 ......................................................................................................................................... 4 2.2 规则 ......................................................................................................................................... 4 2.3 建议 ......................................................................................................................................... 4 2.4 说明 ......................................................................................................................................... 4 2.5 正例 ......................................................................................................................................... 4 2.6 反例 ......................................................................................................................................... 4 3 基本原则 ................................................................................................................................................. 5 4 应用程序的国际化 ................................................................................................................................. 7 5 应用程序的国际化处理细节 ........................................................................................................ 12 6 界面的考虑 ........................................................................................................................................ 16 7 对文本/文档内容的要求 ................................................................................................................ 22 8 附录A
VC开发工具下的国际化方案及实例 ..................................................................... 25 8.1
VC国际化原理与原则 ........................................................................................................ 25 8.2
VC国际化规则 .................................................................................................................... 26 8.3 MFC类型程序实现步骤(以usmn工程为例) .............................................................. 26 8.4 SDK类型程序实现步骤 ...................................................................................................... 35 9 附录B CBuilderampDelphi开发工具下的国际化方案及实例 .................................................... 36 10 附录C Java Eclipse开发工具下的国际化方案及插件 ......................................................... 36 本文中的所有信息归中兴通讯股份有限公司所有,未经允许,不得外传 第 4 / 36 页 1 范围 本标准规定了国际化软件的开发规范,主要包括基本原则、界面风格、界面元素、交互设计、国际化、帮助文件等。
本标准适用于所有产品具有国际化需求的软件。
2 术语和定义 下列术语和定义适用于本标准。
2.1 原则 编程时应该坚持的指导思想。
2.2 规则 编程时必须遵守的约定。
2.3 建议 编程时必须加以考虑的约定。
2.4 说明 对此规则或建议的必要的解释。
2.5 正例 对此规则或建议给出的正确例子。
2.6 反例 对此规则或建议给出的反面例子。
本文中的所有信息归中兴通讯股份有限公司所有,未经允许,不得外传 第 5 / 36 页 3 基本原则 国际化软件的开发需要对软件开发人员、测试人员进行国际化开发和测试的培训。
管理人员需要正确估计开发国际化
软件需要的工作量和人力成本,在软件的需求阶段,SE和管理人员应当作出该软件版本是否要进行国际化开发,并明确写入软件需求说明书,正确的决定以免版本后期再进行适应国际化需求的改动。
一般来说,对于UI比较多的应用程序,且有海外应用需要的程序,界定为需要进行国际化开发的软件,而对于后台服务程序等,则一般不需要进行国际化开发。
为了创建运行良好的全球可用软件,在开发伊始就创建一个可作为各种语言版本基础的单一二进制、全球可用的内核,将使开发工作更具有成效。
这类价值的投资包括以下一些方面:设计用户界面、功能集以及设计对产品的大多数可能的语言版本都具有足够通用性的代码库。
当然,定制必不可少,但是国际化版本所需的修改越少,则产品的发布就越快。
全球可用的单一二进制程序的优势如下: × 为所有平台和各种语言版本发布一个功能核心的二进制程序,这将大大减少开发投入和代价; × 条件编译不再必不可少 × 不需要维护几份独立的源代码,也无需保持几个项目开发团队。
同一个补丁 × 所有语言版本几乎可以同时发布 软件国际化过程可以用下图来描述 【原则1-1】管理层人员确认开发的软件有国际化的需求。
【建议1-1】确认需要国际化软件开发的一般原则。
【原则1-2】单一开发国际化软件的目标:全球可用的单一二进制程序。
【原则1-3】国际化过程是一个渐进的过程。
本文中的所有信息归中兴通讯股份有限公司所有,未经允许,不得外传 第 6 / 36 页 一般来讲,开发人员不是语言专家,不可能精通其他国家语言。
在软件具有全球可用性后,再委托外包公司或本地公司进行本地化开发。
但首要条件是软件从开始就是进行国际化开发的,并具有本地化能力后,才能称为具有全球可用性。
在此基础上,才能进行本地化。
通常,设计过程从需求开始,在规范中,需要识别所有将有助于全球可用性的条件。
编写
设计文档时需要考虑的问题包括全球化、定制功能特征、设计可全球化的用户界面UI、法律问题以及功能特征的易用性; 硬编码是指:字符串放入代码之中而不是放入外部文件,基于假设的字符串长度。
设定数值常量,或者代码中混合关于语言特定或者文化特定方面的任何假设。
这些都可能会在本地化中造成问题,反过来需要修改
源代码文件,进而又会对已有的语音版本进行重新测试; 注意各国对软件产品的一些法律限制,包括
文档、广告、算法限制等; 使软件全球可用的目标就是:对世界上尽可能多的人都易于使用; 创建全球可用的核心代码的主要动机是:不必编译源文件就可以本地化你的程序。
如果通过【原则1-4】识别规范中的全球可用需求。
【原则1-5】避免在程序中进行硬编码。
【原则1-6】研究法律
问题。
【原则1-7】保持功能特征的易用性。
【原则1-8】消除编译关联性。
本文中的所有信息归中兴通讯股份有限公司所有,未经允许,不得外传 第 7 / 36 页 避免硬编码字符串和常量,或者避免把可本地化的资源放在头文件中,消除了编译关联性,那本地化过程就要快得多。
为了处理因语言版本不同而不同的那部分代码,将创建把核心代码和本地化资源的各个语言版本分离开的目录结构,每组资源都可以置于单个目录下,翻译人员只需要访问包含本国语言文件的目录,以及它们所负责的本地化文件。
多语言构建过程可以合并来自于适合的语言目录下的资源文件,并把结果文件放在该语言的lang目录下。
4 应用
程序的国际化 应用程序的国际化包括实现全球可用的单一二进制文件和各种资源文件的处理。
本章分为三部分:C/C,
Delphi/C Builder和
Java,各部分分别针对WIN32平台的不同开发语言做出说明。
Unicode 事实上包含了现在计算机广为使用的所有字符,它至少可以处理110万个编码点,它提供了8位、16位、32位编码形式。
16位作为缺省编码。
Unicode的编码点位置是无序的,而且Unicode也没有提供编码的字体信息。
由于Internet的全球性要求能够适用于所有语言的解决方案,所以Unicode特别适合于Internet时代。
Unicode是被所有计算机公司接受的,事实上的字符编码标准。
把软件构建在Unicode标准的基础上是国际化过程的一个步骤,还需要编写与文化参数设置或语言规则相适应的代码。
记录日志和调试信息时统一使用英文记录。
便于在中英文环境下都能正确显示。
国际化版本中文件名可能需要翻译。
【原则1-9】国际化版本目录结构。
【原则4-1】使用Unicode。
【规则4-2】使用英文记录应用程序的日志和调试信息。
【规则4-3】采用中英文双语注释配置文件。
〖建议4-4〗避免在程序中直接使用文件名。
本文中的所有信息归中兴通讯股份有限公司所有,未经允许,不得外传 第 8 / 36 页 首先,澄清需要翻译的字符串的意义,最好通过源文件中给出注释或通过单独的文件来做到这一点。
如果某个特别的字符串不需要翻译,那么尝试将它放在翻译人员甚至不会看的单独的资源文件中。
或者使用标准的名字标识符,例如:可以给不应该翻译的调试信息加上前缀标识符:IDS_DBG或_IDS;防止出现俚语等含混不清的词汇; 防止各界面字符串前后不一致的情况发生。
对以前的版本考虑逐步改进。
国际化小组对推荐
方案进行持续研究并阶段性发布研究成果。
避免出现字符串不正确的情况。
这部分应用可以不考虑国际化,统一直接采用英文。
避免所调用第三方包或类对国际化支持方案不一致,带来额外的开发维护代价。
以便及早暴露和发现问题。
资料和应用程序词汇不统一会降低产品的可操作性和用户对产品的印象。
【原则4-5】减轻翻译人员的负担。
【建议4-6】避免出现多个含义相同的资源串。
【原则4-7】设计开发多语言版本的应用时,应根据应用特点,使用国际化小组推荐方案之一。
【建议4-8】当翻译后出现字符串超长的现象时,可采取缩写TIP方式,并在帮助中注明。
【建议4-9】对无界面显示的服务程序或显示界面很简单的应用,采用英文字符显示。
〖建议4-10〗第3方工具软件,
开源代码的引用,需要注意国际化一致性。
【原则4-11】多语言版本做单元测试或集成测试时必须在所支持的对应语言环境中进行。
【原则4-12】随机资料(包括帮助文档)中专用词汇翻译必须和用用程序显示统一。
本文中的所有信息归中兴通讯股份有限公司所有,未经允许,不得外传 第 9 / 36 页 C/C4-134-23 确定被声明为char或char 的哪些变量是文本而不是指向缓冲区或二进制字节数组的指针。
把这些类型修改为TCHAR和TCHAR,或者修改为_TCHAR,在TCHAR.H中定义。
一定要检查所有局部变量和返回值类型,使用通用数据类型是不错的移植策略,因为你既可以编译程序的ANSI版本,又可以编译Unicode版本,而不用牺牲代码可读性,然而不用把通用数据类型用于始终为unicode的数据。
或者总是用于某个代码页内的数据。
例如调用_tcslen而不是strlen,使用WIN32API SetWindowText而不是SetWindowsTextA。
EXT宏有条件地在字符常量或字符串常量定义前加字母’L’。
使用转义符要小心,例如win32资源编译器把L/” 解释为表示16为unicode双引号的转义序列,而不是解释为Unicode字符串的起始字节。
应该基于UNICODE编译时标志,正确地处理结构中的字符串或字符域类型定义。
如果编写自己的字符串处理和字符处理函数,或者带字符串参数的函数,那么需要创建这些函数的UNICODE版本。
并为它们定义通用原型。
当想要构建应用程序的unicode版本时,应该同时定义win32编译时标志-DUNICODE和C运行库编译时标志D_UNICODE。
在确定字节数时(例如为字符串分配内存时),把字符串长度和sizeofTCHAR的结果相乘。
计算字符数时,用字符串长度除以sizeofTCHAR。
C确保++和――算符按照数据类型的大小来增加或减少。
必须需要改假设字符值总是小于256的代码(例如,把字符值作为索引,对大小为256项的表进行索引的代码),确保定义的NULL的长度为16位。
【规则4-13】修改代码,以使用通用数据类型。
【规则4-14】修改代码,以使用通用函数原型。
【规则4-15】把所有字符或字符串常量放在TEXT宏中。
【规则4-16】创建数据结构的通用版本。
【规则4-17】修改构建过程。
【规则4-18】调整指针算法。
【规则4-19】检查假设字符长度总是一个字节的代码。
本文中的所有信息归中兴通讯股份有限公司所有,未经允许,不得外传 第 10 / 36 页 在定义和不定义UNICODE标志的两种情况下这样作,一些在基于代码页的环境中也许可以忽略的警告造Unicode的情况下可能会引起问题。
如果源代码在打开类型检查功能的情况下能干净地编译,则导入导出就更容易了。
警告信息将帮助确保没有把错误的数据类型传递给宽字符数据类型。
使用win32国家支持API(NLS API)或者等价的C运行库调用来取得字符键入和排序信息。
不要试图创建自己的逻辑来处理区域特定类型检查。
正例:下面的unicode版本范例完成从资源中装载了一个字符串: g_szTempMAX_STR LoadStringg_hInst IDS_SAMPLE g_szTemp MAX_STR MessageBoxNULL g_szTemp TEXTquotThis is a Unicode message box.quot MB_OK ExtTextOuthDC 10 10 ETO_CLIPPED NULL g_szTemp g_szTemp NULL 例如:发送到不支持Unicode的浏览器中显示的内容,或者在不支持Unicode的
网络和服务器上发送的内容时使用UTF-8。
某些语言之中字符之间的交互操作要求对这些语言有专门的了解。
应当使用大多数以Unicode表示的语言开发并测试系统接口。
否则将数据规模加倍,并且这样进行处理的结果难以预料。
Delphi/C Builder4-244-29 【规则4-20】过启用编译器的类型检查功能调试。
【规则4-21】把UTF-16选作应用程序文本的基本表示方法。
只有需要交互操作时才使用UTF-8 【规则4-22】避免逐个字符处理,并且只要有可能就使用现有的系统接口和资源。
【规则4-23】不要仅为了避免代用处理而使用UTF-32。
【规则4-24】修改代码,以使用通用函数原型。
本文中的所有信息归中兴通讯股份有限公司所有,未经允许,不得外传 第 11 / 36 页 例如调用函数MessageBox或Application.MessageBox,不使用ShowMessage。
直接组合变量和字符串会造成翻译困难和语法错误等问题。
显示指明各参数位置有利于翻译人员准确把握各参数代码的含义,在翻译时调整词序,以符合目标语言的使用习惯。
第 1:d 页 共2:d 页 ‘第’ iPageNo ‘页,共’ iPageCount ‘页’ Unicode 事实上包含了现在
计算机广为使用的所有字符,它至少可以处理110万个编码点,它提供了8位、16位、32位编码形式。
16位作为缺省编码。
Unicode的编码点位置是无序的,而且Unicode也没有提供编码的字体信息。
由于Internet的全球性要求能够适用于所有语言的解决方案,所以Unicode特别适合于Internet时代。
Unicode是被所有计算机公司接受的,事实上的字符编码标准。
把软件构建在Unicode标准的基础上是国际化过程的一个步骤,还需要编写与文化参数设置或语言规则相适应的代码。
可以减轻翻译的
工作量,并保证用词统一。
需要写入数据库或进行比较时例外。
Java4-304-34 【规则4-25】复合消息采用Format函数进行处理,禁止直接组合变量和字符串。
且定义资源串时,必须显式指出各参数的位置。
【原则4-26】统一使用UNICODE编码保存资源文件。
【建议4-27】显示动态消息时需要引用界面标签文本时,直接访问该控件的对应属性。
【建议4-28】日期时间、货币类型的数据显示应与客户端区域设置一致。
【建议4-29】使用统一的风格定义快捷键,界面翻译前注明快捷键的翻译要求。
本文中的所有信息归中兴通讯股份有限公司所有,未经允许,不得外传 第 12 / 36 页 可使用JDK自带的native2ascii.exe,通过命令行方式转换。
采用集成到IDE的工具会更为方便具体参见见附录C. 系统日志的查看者主要是
系统管理和维护人员,一般都能理解英文描述。
5 应用程序的国际化处理细节 引言:通用编码只是全球化软件的一个方面,另一个方面是区域意识。
也就是说,应用程序必须遵守用户选定的语言规则和文化惯例,以与用户的语言、文化和国家标准匹配的方式表示时间、货币、数字、地址和电话号码等。
在Win32程序设计环境中,NLS API提供了从应用程序中消除区域特定假设的合适的工具,能够以符合由区域IDLCID所标识的当前选定用户区域的格式来表示数据。
由于所有允许进行区域特定格式化操作的API和函数都能接受应该为其进行数据格式化的区域标识和文化名称作为参数,因此编写具有区域意识软件的第一步就是检索正确的区域。
GetDateFormat API 。
这个API允许根据当前选定的默认日历类型和日期格式,把任何给定的日历格式转化为 任何支持的区域格式。
【原则4-30】对于界面类程序如果同时支持多语言需在设计阶段指明通过自动检测客户端设置还是由用户选择,如果选择后,支持保留本次选择,下次不再选择。
【原则4-31】对资源信息存放形式(数据库还是文件)或位置设计时需明确指出,统一处理。
【原则4-32】资源文件使用Unicode格式。
【原则4-33】复合消息采用MessageFormat类处理,不允许直接通过字符串组合产生。
〖建议4-34〗系统日志统一为英文,一般只提供错误类型和错误代码,供事后分析。
【规则5-1】调用系统API,实现日历的自动翻译,避免采用硬编码方式 本文中的所有信息归中兴通讯股份有限公司所有,未经允许,不得外传 第 13 / 36 页 正例:下面的代码范例,演示了这个API的工作方式: TCHAR g_szBufMAX_STR GetDateFormatLOCAL_USER_DEFAULT //正在为哪个区域格式化数据 DATA_LONGDATE //日期格式(长,短….) NULL //要格式化的日期 NULL //日期格式化的风格 g_szBuf MAX_STR GetTimeFormat— 正例:下面的代码范例,
演示了这个API的工作方式: TCHAR g_szBufMAX_STR GetTimeFormat LOCAL_USER_DEFAULT //正在为哪个区域格式化数据 0 //日期格式(长,短….) NULL //要格式化的日期 NULL //日期格式化的风格 g_szBuf MAX_STR 显示货币时,涉及到不同国别有不同的符号,例如这个符号可以是像英镑“£”一样的预定义符号,或者像用于罗马利亚列尹的”lei”一样的字母组合,除此之外,还涉及到.