|
| |

The following are bullet points for globalization and
localization best practices as defined by Microsoft.
- 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.
- 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.
- 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.
- 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.


|