Globalization, localizability, locatization in software testing – part 2

Formatting Issues

From the user’s perspective, formatting issues are the primary source of discrepancies when working with applications originally written for another language or culture/locale. Developers should use the National Language Support (NLS) APIs in Windows or the System.Globalization Namespace to handle most of these issues automatically. For more information, see National Language Support and System.Globalization Namespace.





Paper Sizes

Telephone Numbers


Units of Measure


There is no standard address format, so input fields and the routines that process address information should be able to handle a variety of formats.

For example, a common mistake is to require visitors to enter text in a field labeled "State". While this makes sense to people located in the United States, it confuses visitors from other regions where "State" is not part of an address.

You must also be flexible when performing validity checks of the data entered by a user. For example, do not assume that the ZIP-code or postal code has a particular format or length, or that it is comprised of only digits.

For example, Canadian postal codes consist of two groups of three characters, such as "M5R 3H5"; a French postal code is a five-digit number, as in 92300. In some regions, a region code may precede the postal code (e.g., F-92300).


Currency formatting must take into consideration these following elements:

  • Currency symbol — This can be a pre-defined symbol like the European Euro ‘€’ or a combination of letters like the use of ‘DM’ for Germany’s Deutsch Mark.
  • Currency symbol placement — It can be either placed before or after the digits.
  • Negative-amount display — Several of the ways to display negative amounts are:

Formatting Convention


The negative sign before both the currency symbol and number.

United Kingdom

The negative sign before the number but behind the currency symbol.


The negative sign after the number.


The use of parentheses.

United States

Most currencies use the same decimal and thousands separator as the numbers in the culture/locale. However, in some places in Switzerland for example, the period is a decimal separator for Swiss francs (Sfr. 127.54), but the comma is the decimal separator everywhere else (127,54).


Date formatting is not uniform throughout the world. Although each date displays the day, month, and year, their presentation-order and separators vary greatly. In fact, there can be many differences between regions within the same country.

To help illustrate this, look at two basic date formats:

  • Long Date (Tuesday, October 12, 1954)
  • Short Date (10/12/54)

Compare the long date format between, English (U.S.), Spanish (Spain), and Japanese:


Long Date Format

English (U.S.)

Wednesday, March 07, 2001

Spanish (Spain)

miércoles, 07 de marzo de 2001


Obviously, the names of the months and days-of-the-week differ from one culture/locale to another. However, in Spanish (Spain), the day precedes the month, all characters are lowercase, and the article "de" appears before the month and year. In Japanese, long dates do not display the day of the week, and the translations for day, month, and year act more like separators.

Compare the short date format between, English (U.S.), Spanish (Spain), and Japanese:


Short Date Format

English (U.S.)


Spanish (Spain)




In the short date, we see again that in Spanish (Spain), the order is day/month/year as compared to English (U.S.) where it is month/day/year. In Japanese, the order is year/month/day. This can cause some real confusion if not watched carefully.

For example, depending on which language you are using, the date 07/04/01 could mean:



English (U.S.)

July 4th, 2001

Spanish (Spain)

April 7th, 2001


April 1st, 2007

These examples show why you should use the date APIs when dealing with dates. Not only will they handle the correct format, but they will also display the correct translations for the long dates saving you translation costs.

In addition to date formatting, you may need to adapt your application to function with a variety of calendars. Although the Gregorian calendar is in widespread use, some editions of Windows support other calendars, such as the Hijri calendar.


There are six major considerations when dealing with numeric values:

  • Thousands separator — In the United States, the character is a comma (,). In Germany, the character is a period (.). Thus one thousand twenty-five is displayed as (1,025) in the United States and (1.025) in Germany.
  • Decimal separator — In the United States, the character is a period (.). In Germany, the character is a comma (,). Thus one thousand twenty-five and seven tenths is displayed as (1,025.7) in the United States and (1.025,7) in Germany.
  • Displaying negative numbers — Instead of the negative sign (-) appearing at the beginning of the number, the negative sign (-) may instead appear at the end of the number. Alternatively, you can display the number with parentheses around it or even in a color such as red. Thus a negative five hundred fifty-eight could be displayed as:

· -558

· 558-

· (558)

· 558

  • Shape or correspondence — The numbers may be shaped differently or not have a one-to-one correspondence. For example, Japanese has one more digit than English; the last digit shown here represents the number 10:
  • Digit grouping — The sizes for each comma-delimited group of digits to the left of the decimal can also vary. For example:

· United States: 123,456,789

· Hindi: 12,34,56,789

  • Percentages — Because you can write it several ways, you should never assume that you can hard-code the percent sign. For example:

· 98%

· 98 %

· 98 pct

· %98

Paper Sizes

The U.S./Canada paper sizes (letter, legal, and so on) do not satisfy the needs of all the users in the world market. For example, most regions in Europe and Asia use a slightly larger standard known as A4 (297 x 210 mm), which is a little longer and narrower than the U.S./Canada letter size (279 x 216 mm).

If your application needs to print, you should make it possible for the default paper size to be configurable.

Telephone Numbers

The formatting of telephone numbers, along with address, varies widely among geographic regions. Thus, input fields and the routines that process telephone numbers should be able to handle various formats.

For example, the table below displays different formats used throughout the world:


Telephone Number Format


1234 5678




(12) 345.67.89


123 4567


(01) 234-5678 or (012) 34-5678

United Kingdom

0123 456 7890 or 01234 567890

United States

(123) 456 7890

Notice that there are different separators ("-", ".", spaces), groupings (2, 3, 4, 5, & 6 digits/group), and number of digits (7-11). In addition, the examples above do not include country codes, which could add one to three digits.

The ISO standard for the number of digits in a telephone number is 15. Remember that this does not include space for things like:

  • PBX exit numbers (that is, prefixing a 9 to obtain an outside line)
  • Long-distance access codes
  • Passwords
  • Credit card numbers

Thus, when designing and coding for display and storage of telephone numbers, do not assume one given format, but leave it very free flowing.


Consider the following issues when displaying time:

  • The use of either a 12-hour or a 24-hour clock — Most European and Asian cultures/locales use the 24-hour clock instead of the 12-hour AM/PM model used in the United States. In addition, some regions render the AM/PM designation in the language of the region, and it may precede or follow the time.
  • The character used to separate hours, minutes, and seconds — Although the colon (:) is the character most often used in separating the hours, minutes, and seconds, some Asian DBCS languages use idiographic characters. In addition, some cultures/locales require ‘h’, ‘m’ and ‘s’ as part of the display.
  • The storage and display of time zones — A common way to display the time zone is to display GMT (Greenwich Mean Time) or its modern replacement, UTC (Coordinated Universal Time), as the base followed by a positive or negative number indicating the offset for the time zone in hours and minutes (some time zones use 30 or 45 minute offsets). For example, GMT -8:00. An alternative is to use the local time zone names. If using local time zone names you must take into account:

· Not all regions use local names.

· Time zone abbreviations are not unique.

· Not all areas use daylight savings time and daylight savings does not start and end on the same day in every region.

· One time zone can have many different names depending on the region and the language.

Units of Measure

Throughout the world things are measured using different units and scales. The most popular system is the metric system (e.g., meters, liters, grams, etc.). Whereas the United States still uses the imperial system (e.g., feet, inches, pounds, etc.). The kind of measurements may be lengths, weights, area, volume, temperatures, paper sizes, angle notation, and so on.

Thus, you must make sure that your application can display measurements in different systems. Also, make sure it is clear to the user which system the application is using for display.

String-Related Issues

String resources include the text that appears in an application’s user interface. This refers to, but is not limited to, menus, dialog boxes, and messages (informational, alert, and error messages).

When you are developing a world-ready application, you must consider differences among languages, especially as those differences relate to strings. During the localizability process, you should verify which strings require localization, ensure your application makes it possible for strings to grow, and ensure your application does not rely on string concatenation.

String Concatenation

String Growth

String Sorting and Comparison

Strings and Resource Files

String Concatenation

When you try to reduce the size of a string, one possible approach developers try to use is string concatenation. However, this method will significantly limit the localizability of your application and you should not use this method. In this section, you will see several reasons why string concatenation is a hazard to localizability and why you should avoid this practice.

Gender Issues



String1: one after the other

String1: un après l’autre

String2: The controls will be deleted

String2: Les contrôles seront supprimés

String3: The forms will be deleted

String3: Les feuilles seront supprimées

Taken separately, String1, String2, and String3 are easily localizable. If your code concatenates String2 and String1 or String3 and String1, the resulting English string looks fine. The localized strings, however, are likely to be wrong. In the French column, for instance, String3 + String1 would be wrong, because in French grammar, forms (feuilles) is a feminine word. Thus, String1 should be "une après l’autre" and not "un après l’autre." The same situation will be true in many other languages.

You can easily fix this problem by avoiding string concatenation and using complete strings in a resource file.

Word-Order Issues

In the preceding example, the order of the words that make up the sentence is the same in English as it is in French. However, the word order is generally not the same from one language to another. (For example, in both German and Japanese the verb generally appears at the end of the sentence.) The following example illustrates this:



String1: DLL

String1: DLL

String2: Missing Data Access

String2: Accès aux données manquante

String3: Missing OLE

String3: OLE manquante

If your code concatenates String2 + String1 and String3 + String1, localized versions are incorrect because the order of the two strings produces a message that does not make sense.

You can easily fix this problem by avoiding string concatenation and using complete strings in a resource file.

Translation issues

Finally, it is also important to know that identical words or sentences in English may require translation into different words or sentences when localized. Consider the following example:



String1: Setup program

String1: Programme d’installation

String2: ‘String1’ did not complete successfully.

String2: String1 a échoué.

In the English version, String1 is the setup program’s banner string. It is also used as part of an error message in String2. In the French version, String1 works perfectly as the stand-alone banner string. However, it needs to become "Le programme d’installation" when used with String2.

You can easily fix this problem by avoiding string concatenation and using complete strings in a resource file.

String Growth

In most cases, translated strings are usually longer, such as when you translate strings from English to German.

The following table shows the additional average growth for strings beyond initial length. This data is from past Visual Basic localization projects and describes an average growth rate:

English length (in characters)

Additional growth for localized strings

1 to 4


5 to 10


11 to 20


21 to 30


31 to 50


Over 50


String Sorting and Comparison

Although we may think that sorting criteria are universal, users of world-ready applications might disagree when sorting in another language. Not only does alphabetical order vary among languages, but conventions for sequencing items in dictionaries and phone books can also be quite different.

In Swedish, some vowels with diacritics sort after Z. However, in other European languages, the same diacritic vowel sorts right after the non-diacritic vowel. Languages that include characters outside the Latin script have special sorting rules. For example, the Icelandic character ð sorts between D and E. Asian DBCS languages have several different sorting orders depending on phonetics, radical order, number of pen strokes, and so on.

String sorting and casing are language specific. Even within Latin script based languages, there are different composition and sorting rules. In only a few languages (including English) does the sort order match the code point (A [65] comes before B [66]). However, that only works if you normalize text to either uppercase or lowercase before sorting. So, do not rely on code points to do proper sorting and string comparisons.

Strings and Resource Files

Designing your application with localization in mind and separating string resources from code from the beginning of your project is more efficient than revising your finished application to meet the requirements of an international audience later in the development process.

Although it might be more work for the person writing the application, no user-interface elements should be present in the application’s code. Instead, the string resources should be in a separate file from which the application will load them at run time. This file, called a resource file (.resx in managed code and .rc in Visual C++), contains all the localized strings, bitmaps, and icons.

The teams working on localizing the application should work exclusively on the resource file to develop all the different language versions of the application. This approach has the following advantages:

  • Efficiency Developing a new international version of the application only involves creating a new international resource file because each version has the same code block. This streamlines the creation of multiple language versions of your application.
  • Greater security Whether you decide to localize your application in-house or to use an external company, you will not need to access source code to develop international versions of your application.
  • Less testing This approach dramatically reduces the amount of testing required to ensure the quality of your application’s international version.
  • Better localization By placing all relevant string resources in one file, you ensure a more efficient localization process and reduce the chance of leaving some strings un-localized.

One resource you should consider using is the glossary for all Microsoft localized products. Individual glossaries for 31 languages are available for download from the glossary directory on (

When building resource files that contain localizable strings, the data block should only include strings that require localization. Conversely, it is also fundamental to make sure all the resources that need to be localized are actually present in these resource files. The code block consists of hard-coded items not requiring localization.

User Interface Issues

The issues associated with designing a user interface (UI) for your world-ready application are varied and complex. This topic provides information only about the most important and commonly used features of almost any user interface.

Common User Interface Components to Consider

You should pay special attention to the design of the following UI components:

  • Messages
  • Menus and dialog boxes
  • Icons and bitmaps
  • Access and shortcut keys
  • UI controls

English text strings are usually shorter than text strings in other languages. The growth rate, which is especially acute in short strings, becomes less of a problem as string length increases. For example, for strings that are from one to four characters in English, the rate of growth when localized to another language can be about 100 percent. For strings longer than 50 characters, the rate of additional growth is about 10 Percent. When designing the UI, consider these growth ratios and make it possible for text in localized messages to wrap to subsequent lines.

Menus and Dialog Boxes

When localizing the application, menus and dialog boxes may also grow. For example, if you were to develop an automated teller machine application that would run in English and in Spanish, extra space would be required in the dialog box to make it possible for text expansion. Therefore, you must plan your interface to prevent the need for resizing controls or other elements after localization. In menus and dialog boxes, avoid crowding status bars. Even abbreviations might be longer or simply not exist in other languages.

Icons and Bitmaps

Icons and bitmaps usually depict certain functionality without using text. Consider the following rules when working with icons and bitmaps:

  • Avoid using bitmaps that are not an international standard. For example, a bitmap that represents a rural-style mailbox in the United States looks like something else to residents of other cultures/locales. Europeans typically interpret this particular bitmap as a tunnel.
  • Avoid using bitmaps that contain text. They take time to redraw, and text growth might become an obstacle. It is also important to ensure that bitmaps and icons are culturally sensitive. What may be acceptable in one culture/locale may be inappropriate or even offensive in another.
Access and Shortcut Keys

Different cultures/locales have their own keyboard layouts and some characters do not exist on all keyboard layouts. When developing your application, make sure all access-key and shortcut-key combinations are available on international keyboards. One simple method to verify that your keyboard assignments work properly for the targeted cultures/locales is:

  • Review the desired keyboard layout from Control Panel or the keyboard layout pictures, which some reference manuals contain
  • Determine if the access-key and shortcut-key combinations exist

Certain access-key and shortcut-key combinations are not available for certain cultures/locales or they are reserved for system use by some editions of Windows. Avoid these keys when developing your application. Here are some examples of characters to avoid:

@ $ {} [] \ ~ | ^ ‘ < >

One way to work around this limitation is to use numbers and function keys (F1, F2, and so on) instead of letters in shortcut-key combinations. These may be less intuitive but they do not require any localization because virtually all keyboard layouts include numbers and function keys.

Note   Shortcut keys cannot consist of characters from the double-byte character set (DBCS).

UI Controls

Although UI controls (e.g., buttons, combo boxes, list boxes, etc.) are the building blocks of dialog boxes, you should follow these rules:

  • Never hide one control behind another. Due to language expansion issues, hiding a control behind another may not work when you localize the application. For example, a button hidden behind another button in an English language application may extend beyond the covering button when you localize the application in German. For more information, see String Growth.
  • Never use UI controls as part of a sentence. By using controls as part of sentences, the sentences suffer the same problems as concatenated strings. For more information, see String Concatenation.

Testing for Globalization and Localization

Ensuring the world-readiness of an application requires three phases of testing: globalization testing, localizability testing and localization testing.

Globalization Testing

The goal of globalization testing is to detect potential problems in application design that could inhibit globalization. It makes sure that the code can handle all international support without breaking functionality that would cause either data loss or display problems. Globalization testing checks proper functionality of the product with any of the culture/locale settings using every type of international input possible.

Proper functionality of the product assumes both a stable component that works according to design specification, regardless of international environment settings or cultures/locales, and the correct representation of data.

The following must be part of your globalization-testing plan:

Decide the priority of each component

To make globalization testing more effective, assign a testing priority to all tested components. Components that should receive top priority:

  • Support text data in the ANSI (American National Standards Institute) format
  • Extensively handle strings (for example, components with many edit controls)
  • Use files for data storage or data exchange (e.g., Windows metafiles, security configuration tools, and Web-based tools)
  • Have had many globalization problems in the past
Select a test platform

So, which operating system (OS) should you use for your international testing platform? The first choice should be your local build of Windows 2000 with a language group installed. For example, if you use the U.S. build of Windows 2000, install the East Asian language group. This combination gives you complete international support for the language selected without imposing requirements on the testers’ language skills.

Even if you target a broader range of operating systems, Windows 2000 should be your primary test platform. Earlier operating systems do not give you the same flexibility with local settings and native support for the broadest range of languages and cultures/locales.

You may also use other platforms that differ from your local build of Windows 2000:

  • MUI (Multilanguage User Interface) Windows 2000 — especially useful if your code implements multilingual UI and it must adjust to the UI settings of the OS. This approach is an easier implemented alternative to installing multiple localized versions of the OS. To further enhance multilingual support, Microsoft offers a separate Windows 2000 MultiLanguage Version, which provides up to 24 localized language versions of the Windows user interface. For more information, see Multilanguage User Interface (MUI).
  • Localized build of the target OS — German or Japanese are good choices. Remember it might be harder to work with them if you do not know the operating system’s UI language. This approach does not have significant advantages over the solutions above.

Most globalization problems found by testing occur when East-Asian-languages support is active or when the OEM code page differs from the ANSI code page for a given culture/locale. For example, you can select the following cultures/locales in the U.S. build of Windows 2000 to test for potential globalization problems:

  • Japanese
  • German
  • A combination of both (one selected for the System locale and another for the User locale) whenever possible to cover multilanguage support

You can achieve the most complete coverage if you install all the language groups, rotate the cultures/locales, and run "globalized" tests as described below.

Create the test environment

To perform globalization testing, you must install multiple language groups and ensure that the culture/locale is not your local culture/locale. As mentioned above, executing test cases in both Japanese and German environments, and a combination of both, can cover most globalization issues.

Essentially, the steps to create a world-ready test environment using Japanese and German environments are:

1. On your local build of Windows 2000, install Japanese (or any other East-Asian region) and German language support, if not already installed (the U.S. build of Windows 2000 installs German language support by default).

2. Set the culture/locale on the test machine to different cultures/locales from your local culture/locale (Japanese or German).

3. Set up a distributed network with a mixed environment of your local build of Windows 2000 systems with some set to the Japanese culture/locale and others set to the German culture/locale.

Testing with Japanese as the system default culture/locale verifies double-byte character set (DBCS) handling in ANSI (non-Unicode) components. Testing with German as the system default culture/locale ensures that ANSI and OEM code pages are handled properly when text conversion is required. Having a distributed mixed network environment verifies that data can be successfully passed between different cultures/locales.

Execute tests

After the environment has been set for globalization testing, you must pay special attention to potential globalization problems when you run your regular test cases:

  • Put greater importance on test cases that deal with the input/output of strings, directly or indirectly.
  • Test data must contain mixed characters from East Asian languages, German, Complex Script characters (Arabic, Hebrew, Thai), and optionally, English. In some cases, there are limitations, such as the acceptance of characters that only match the culture/locale. It might be difficult to manually enter all of these test inputs if you do not know the languages in which you are preparing your test data. A simple Unicode text generator may be very helpful at this step.
Recognize the problems

The most serious globalization problem is functionality loss, either immediately (when a culture/locale is changed) or later when accessing input data (non-U.S. character input).

Some functionality problems are detectable as display problems:

  • Question marks (?) appearing instead of displayed text indicate problems in Unicode-to-ANSI conversion.
  • Random High ANSI characters (e.g., ¼, †, ‰, ‡, ¶) appearing instead of readable text indicate problems in ANSI code using the wrong code page.
  • The appearance of boxes, vertical bars, or tildes (default glyphs) [□, |, ~] indicates that the selected font cannot display some of the characters.

It might be difficult to find problems in display or print results that require shaping, layout, or script knowledge. This test is language-specific and often cannot be executed without language expertise. On the other hand, your test may be limited to code inspection. If standard text-handling mechanisms are used to form and display output text, you may consider this area safe.

Another area of potential problems is code that fails to follow local conventions as defined by the current culture/locale. Make sure your application displays culture/locale-sensitive data (e.g., numbers, dates, time, currency, and calendars) according to the current regional settings of your computer.

The Regional Options in Control Panel does not cover all culture/locale-specific functionality. For example, you cannot see the current sort order there. Thus, it is important to have a test plan covering all aspects of functionality related to culture/locale before you start your test.

Localizability Testing

Localizability testing verifies that you can easily translate the user interface of the program to any target language without re-engineering or modifying code. Localizability testing catches bugs normally found during product localization, so localization of the program is required to complete this test. As such, localizability testing is essentially a hybrid of globalization testing and localization testing. Successful completion of localizability testing indicates that the product is ready for localization. You can use pseudo-localization to avoid the time and expense of true localization. Pseudo-localization is perhaps the most cost-effective way of finding localizability bugs and is performed as follows:

Run a pseudo-localized version of a program

The most effective way to perform pseudo-localization is to modify the program’s resources automatically. For example, here is what English-speaking localizers do when they translate a program’s UI:

  • Replace English text with text containing non-English characters. It is advisable to keep the text readable. For example, make your translation algorithm replace English characters with non-English symbols of a similar shape. For example:

· For a, use à or å

· For c, use ĉ or ç

· For n, use ń or ñ.

  • Add extra characters to your resource strings. In many cases translated text is longer than the English original ("some string" becomes "+++some string+++").
  • Stretch your dialog boxes. Localizers usually do this when the string length grows due to localization.
  • Mark the beginning and the end of each resource string. These markers help you identify when the application displays text at run time — a potential source of localizability bugs.
  • Make your substitution using multi-lingual Unicode (as resource strings are stored as Unicode anyway). This will help you find places where the program utilizes ANSI functions to process or display text.

After you pseudo-localize your program, test its functionality. Pseudo–localized applications should function no differently than the original version.

An area often forgotten in localizability testing is mirroring testing. If you want to distribute your software to markets where the text and UI of the programs display from right-to-left (RTL), you will want to know how your application looks when it is mirrored. This test may be implemented as a part of the pseudo-localization of your product. As a result, your text displays in your chosen language, but the application mirrors windows and text alignment.

Perform code review

Be sure the code meets the following requirements:

  • Write all resources in standard Windows resources format and do not hard-code strings in the source code.
  • Do not use pointer arithmetic for string-length calculations, access to string elements, or string manipulations.
  • Do not build strings at run time by stripping or concatenation.
  • Resources do not make assumptions about string buffer length.
  • Do not position UI controls at run time.
  • Icons and bitmaps do not contain text.
  • No assumptions exist on drive and folder names or registry keys.
Perform UI and documentation review

Make sure the terminology used in the UI and support documentation is clear, consistent, and unambiguous. Localizers can get confused when the UI and the documentation refer to the same features by different names or when the text contains excessive technical jargon.

Localization Testing

Localization translates the product UI and occasionally changes some initial settings to make it suitable for another region. Localization testing checks the quality of a product’s localization for a particular target culture/locale. This test is based on the results of globalization testing, which verifies the functional support for that particular culture/locale. Localization testing can be executed only on the localized version of a product. Localizability testing does not test for localization quality.

The test effort during localization testing focuses on:

  • Areas affected by localization, such as UI and content
  • Culture/locale-specific, language-specific, and region-specific areas

In addition, localization testing should include:

  • Basic functionality tests
  • Setup and upgrade tests run in the localized environment
  • Plan application and hardware compatibility tests according to the product’s target region.

You can select any language version of Windows 2000 as a platform for the test. However, you must install the target language support.

The localization testing of the user interface and linguistics should cover items such as:

  • Validation of all application resources
  • Verification of linguistic accuracy and resource attributes
  • Typographical errors
  • Consistency checking of printed documentation, online help, messages, interface resources, command-key sequences, etc.
  • Confirmation of adherence to system, input, and display environment standards
  • User interface usability
  • Assessment of cultural appropriateness
  • Checking for politically sensitive content

When shipping a localized product, ensure that localized documentation (manuals, online help, context help, etc.) is included. Items to check include:

  • The quality of the translation
  • The completeness of the translation
  • Terminology is used consistently in all documents and application UI

Best Practices for Globalization and Localization

The following best practices provide a checklist of the issues associated with developing world-ready software.

Technical Issues

Developers can reduce their development time on almost any international application by considering the following issues prior to the start of the development cycle:

  • Use Unicode as your character encoding to represent text. If you cannot use Unicode, you will need to implement DBCS enabling, bi-directional (BiDi) enabling, code page switching, text tagging, and so on.
  • Consider implementing a multilingual user interface. If you design the user interface to open in the default UI language and offer the option to change to other languages, users of the same machine who speak different languages reduce down time related to software configuration. This may be a particularly useful strategy in regions such as Belgium with more than one culture/locale and official language.
  • Watch for Windows messages that indicate changes in the input language, and use that information for spell checking, font selection, and so on.
  • If you are developing for Windows 2000, test your application on all language variants of Windows 2000, using all possible cultures/locales. Windows 2000 supports the languages used in more than 120 cultures/locales.
Cultural and Political Issues

Sensitivity towards cultural and political issues is an especially important topic when developing world-ready applications. In general, these items would not prevent your application from running; instead, they are items that may create such negative feelings about the application that customers may seek alternatives from other companies. Political issues, such as disputes related to maps, can induce governments to prevent distribution in entire regions. The following are areas in which problems commonly occur:

  • 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

You can localize well-designed software to any of the languages supported by Windows 2000 without changes to the source code. In addition to the guidelines mentioned above, you should also consider the following:

  • 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.
  • If localizing to a Middle Eastern language, such as Arabic or Hebrew, use the right-to-left layout APIs to lay out your application right-to-left.
  • Test localized applications on all language variants of Windows 2000. If your application uses Unicode, as recommended, it should run fine with no modifications. If it uses a Windows code page, you will need to set the culture/locale to the appropriate value for your localized application and reboot before testing.

Retirado de


Deixe uma Resposta

Preencha os seus detalhes abaixo ou clique num ícone para iniciar sessão:

Logótipo da

Está a comentar usando a sua conta Terminar Sessão / Alterar )

Imagem do Twitter

Está a comentar usando a sua conta Twitter Terminar Sessão / Alterar )

Facebook photo

Está a comentar usando a sua conta Facebook Terminar Sessão / Alterar )

Google+ photo

Está a comentar usando a sua conta Google+ Terminar Sessão / Alterar )

Connecting to %s