国际化软件技术分类解析

Kingson

国际化软件开发需要正确处理字符、多语言支持、区域、正则表达式、数据输入和输出、用户界面，以下是需要正确处理的技术。

• Character Manipulation
  
  • 
    Character classification tests, such as isalpha use the I18N library’s API.
  • Character transliteration requests, such as toupper use the I18N library’s API.
  • Characters used in code and templates are based on locale character code points, and not on hard-coded numeric values.
  • Word wrapping in scripts does not split multibyte characters (i.e. generating column lists in scripts.)
    Word wrapping in controls does not split multibyte characters.
  • Cursor must always fall on character boundaries and not byte boundaries.
  • Characters are selected and highlighted at the character boundaries and not the byte boundaries.
  • Character pointers are not moved using the ++, -- or arithmetic calculation.
  • String operations use the I18N library string functions.
  • Storage allocation requests account for MBCS characters.
    
• 
  Language enabling
  
  • 
    Prompt strings are clearly identified (as per the I18N specifications addendum.)
  • List of files containing prompts to enable has been provided to your Globalization representative.
  • Documentation on how to generate language specific prompts and environment information have been provided to your Globalization representative.
  • Source control system is ready to handle various language versions of resource/message files.
    
• Locale
  
  • 
    Locale precedence is handled as described in the I18n specifications
  • Date, time, numbers, currency, paper sizes, etc. are formatted according to the active locale.  
  • Sort order is consistent with the active locale.
  • Fractions can be displayed in decimal or as a fraction.
  • Rounding and math functions can be changed by locale.  
  • Dates can be displayed as DMY, MDY, and YMD or as any other locale specific format.  
  • Locale-dependent capitalization can be allowed on day or month names.  
  • Day, month abbreviation length is not constrained.  
  • Multiple calendars are supported as some countries restart the year on events like a new emperor taking the crown.  
  • Computations are locale independent.  
    
• Regular Expressions
  
  • Regular expression expansion uses the I18N library’s regular expression support.  
    
• Source Code
  
  • 
    Source code supports all character lengths (7-bit, 8-bit, MBCS).
  • Source code has been written such that recompiling for different target languages is not required.  
  • Source code does not use a single string or resource in different contexts.  
  • Strings, character or numeric constants, screen positions, order of parameters in a string, accelerator key values, filenames, or pathnames are not hardcoded.  
  • Lead-byte ranges for Far East codepages are not hardcoded.  
  • Buffer sizes have been expanded (~40%) to allow for text growth.  
  • No string is concatenated to form a sentence.
  • Plural of strings is not created by adding an "s".
  • In general, source code should support the IME (Input Method Editor) output. In Windows fields (dialog box areas) that don’t support double-byte data, the IME should be disabled.  
  • When applicable, encryption key length doesn’t violate export laws (in general, more than 40-bit encryption keys are not exportable.)
  • Third-party code complies with BMC I18N specifications.
    
• Stream and Formatted I/O
  
  • 
    File I/O containing I18N data uses the I18N library’s stream and I/O formatting functions.
  • No loss of information due to codeset differences exists when data is exchanged between applications, operating systems, and platforms.
  • Information is displayed in the target (end user) codeset regardless of its source codeset.
    
• User Interface
  
  • 
    Localizable strings are moved to resource/message files independent of the source code.  
  • Ambiguous localizable strings have comments to identify their usage.  
  • Strings or other constants that should remain in English are separated from the localizable elements in another file.
  • Text can be displayed and printed using the appropriate fonts for the target environment.  
  • Hyphenations and word/sentence breaks follow the grammar rules of user's locale in dialog boxes.
  • Sufficient white space has been added to allow for translated text growth at all supported screen resolutions.
  • Dynamically populated menu categories obtain strings from resource/message files, and not from INI files.
  • Menu and dialog box accelerators are unique.
  • Default accelerator keys are accessible from all international keyboards.  
  • Bitmaps/icons are free of any text, color, acronym, symbol that requires localization
  • Common icons use BMC GUI standard icons.
  • Sounds are acceptable to all locales.
  • Toolbar images are acceptable to any locale.
  • Slang or idioms are not used in user interface.
  • Common toolbar items use commonly known images.  
  • Tool Tips strings are kept in resource files.  
  • Statusbar text is kept in resource files.
  • Progress bar format is localizable.
  • Logged, validation errors and status messages are kept in resource/message files.  
  • Dialog management messages originate from string tables in resource files.  
  • Consistency among application terminology and target environment(s) is ensured.
  • Consistency among common messages across DBMSs is ensured.