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.
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 Region The negative sign before both the currency symbol and number. United Kingdom
The negative sign before the number but behind the currency symbol. Denmark The negative sign after the number. Netherlands 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:
|Region||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:
|Region||Short Date Format|
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|
|Japanese||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:
- 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 pct
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.
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:
|Region||Telephone Number Format|
|Thailand||(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
- 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.
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.