Skip the typical software localization beginner's traps

Dates

You should never hard-code date values. Besides different date separators the date order differs between countries. In the short date format, the USA uses mm/dd/yyyy where m is the month, d is the day, and y is the year. Germany uses dd.mm.yyyy. If you do not take care of this, for example, in Visual Basic, a date string like 12/9/2006 can be interpreted as 9th December or 12th September.

If you use medium or long date formats, the day and month names must also be translated. If you use format routines, you should ensure that your development system supports date format in the way that you require.

If you need to calculate with dates, store them in a format that is system independent like the ISO 8601 format yyyy-mm-ddThh:mm:ss; you can also convert the dates to a system-independent date number format, such as date serial. This makes dates sorting easy.

What you need to do

Be sure to store dates internally and in files without using a format. Use the data type for your programming language. If you allow user input, collect the day, month and year in separate fields, and internally build a date data type from these fields.

When you display dates, format them with the right system settings. The Windows API provides functions to get the appropriate values. In .Net, check the culture name space. When you allow user input, make sure that the user knows which format is required.

Software localization traps

• Overview
• Languages
• Character sets
• Code pages
• Numbers
• Currencies
• Dates
• Time
• List separator
• Measurements
• Paper format
• Phone number
• Sort order
• Tax
• States
• Other traps
• Conclusion