. Home Feedback Contents Search

Best Practices 

Back Up Next

Best Practices for Globalization and Localization

The following are bullet points for globalization and localization best practices as defined by Microsoft.

Technical Issues

  • Use Unicode as your character encoding to represent text.
  • Consider designing the UI to offer the option to change to other languages.
  • Watch for Windows messages that indicate changes in the input language, and use that information for spell checking, font selection, and so on.
  • Test your application on all language variants, using all possible cultures/locales. Windows supports more than 120 cultures/locales.

Cultural and Political Issues

  • Avoid slang expressions, colloquialisms, and obscure phrasing in all text. At best, they are difficult to translate; at worst, they are offensive.
  • Avoid images in bitmaps and icons that are ethnocentric or offensive in other cultures/locales.
  • Avoid maps that include controversial regional or national boundaries. They are a notorious source of political offense.

Additional User Interface Issues

  • Isolate all user interface elements from the program source code. Put them in resource files, message files, or a private database.
  • Use the same resource identifiers throughout the life of the project. Changing identifiers makes it difficult to update localized resources from one build to another.
  • If used in multiple contexts, make multiple copies of the same string. The same string may have different translations in different contexts.
  • Only place strings requiring localization in resources. Leave non-localized strings as string constants in the source code.
  • Allocate text buffers dynamically since text size may expand when translated. If you must use static buffers, make them extra large (perhaps doubling the length of the English string) to accommodate localized strings.
  • Keep in mind that dialog boxes may expand due to localization. For example, a large dialog box that occupies the entire screen in low-resolution mode may require resizing to an unusable size when localized.
  • Avoid text in bitmaps and icons, as these are difficult to localize.
  • Do not create a text message dynamically at run time, either by concatenating multiple strings or by removing characters from static text. Word order varies by language, so dynamic composition of text in this manner requires code changes to localize to some languages.
  • Similarly, avoid composing text using multiple insertion parameters in a format string because the insertion order of the arguments changes when translated to some languages.

Localization Preparation

  • Determine the working language set
  • Engineer your application to use resource-only libraries (DLLs)
  • Prepare help content
  • Find a localization vendor

Isolating Localizable Resources

  • Localizable resources - Separate localizable resources from source.
  • Non-localizable resources - Resources that do not require localization should be kept separate from those that do.
  • User Interface (UI) – Dialogs, forms, etc., can usually be localized.
  • Product adaptation – Query the underlying platform for currency, date, etc formats.
  • Debug - Resources that should not be localized since it is unlikely that you will ship a debug version of your application.
  • Functional - Resources such as strings that cannot be localized without a loss of functionality.

Preparing the User Interface for Localization

  • Size the UI to accommodate the largest localized version of the content.
  • Do not mingle strings with controls, such as placing a text box in the middle of a sentence.
  • Avoid hiding or overlapping UI controls with other UI controls. Makes it harder for localizers.
  • Avoid placing button text in a string variable.
  • Avoid culture-specific images.
  • Avoid showing flesh, body parts, or gestures.
  • Beware of gender-specific roles and stereotypes in other cultures.
  • Avoid religious preferences.
  • Avoid political symbols.
  • Avoid text in graphics.

Preparing Help Content for Localization

  • Keep the writing style used in help content simple. Most localization vendors charge by the word and complex sentence structures are more difficult to translate.
  • Follow basic writing style principles, such as using consistent terminology.
  • Respect cultural and local sensitivity. Create content that does not incorporate slang, jargon, colloquial expressions, or culture-specific metaphors.
  • Write for easy recycling and reduced localization costs. For most localization vendors, reusing common sentences results in reduced localization costs since the sentence is only translated once.
  • Respect cultural sensitivity in art and multimedia. As with the UI considerations above, help content should not use art or multimedia that does not have global meaning.
  • Design the help system with global functionality. The help system software should be designed with the same global considerations as the application it supports.

Language Issues

  • Use locale sensitive string functions.
  • Font names and sizes – don’t hard code.
  • Input Method Editors (IME) –IME is used in Japanese to enter data. Application must support IME messages or supply own IME.
  • Line and Word Breaks are radically different in Japanese.

Formatting Issues

  • Addresses
  • Currency - Currency symbol, Currency symbol placement, Negative-amount display, formatting
  • Dates
  • Numerals
    • Thousands separator
    • Decimal separator
    • Displaying negative numbers
    • Shape or correspondence
    • Digit grouping
    • Percentages
  • Paper Sizes
  • Telephone Numbers
  • Time
  • Units of Measure

String-Related Issues

  • Use locale sensitive string functions, not C runtime.
  • Gender Issues – string resources must be complete enough to handle gendered articles.
  • Word-Order Issues – can’t dynamically construct strings from fragments
  • Translation issues – string source must have a context so translators can choose proper working
  • String Growth – English strings are almost always shorter than the localized string.
  • String Sorting and Comparison – must use locale sensitive sorting and compare functions
  • Strings and Resource Files – Localizable strings go into resource only satellite DLLs. Non- localizable don’t.

User Interface Issues

Common User Interface Components to Consider

  • Messages
    • English text strings are usually shorter than text strings in other languages.
  • Menus and Dialog Boxes
    • When localizing the application, menus and dialog boxes may also grow.
  • Icons and Bitmaps
    • Avoid using bitmaps that are not an international standard.
    • Avoid using bitmaps that contain text.
  • Access and Shortcut Keys
    • Make sure shortcut key exists in locale
  • UI Controls
    • Never hide one control behind another.
    • Never use UI controls as part of a sentence.

Back Up Next

Hit Counter