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.