What needs to be localized?
Issue 8, May/27/2009
When you translate a program, website or just a text document, you need to remember that just translating the text from one language to the other may not be enough.
In this article, we'll cover things that need to be adapted to different languages and even countries.
Localization checklist
- Currencies (and amounts)
- Number format
- Dates
- Units
- Phone numbers and addresses
- Time zones
Currencies
If your English brochure (for US clients) says "$19.95", what can this mean for people outside of the US?
Do you mean US Dollars, maybe Canadian Dollars or even Argentinian Pesos? Tough to tell...
The solution specify the currency using its name.
The cost would be crystal clear, to anyone in the world if you write "$19.95 USD". Then, when translators work on your brochure, they'll also know what it means and be able to translate it properly.
Which currencies?
Although the USD and Euro zones include many people, there are still many other currencies in the world. Have a look here for a full reference - http://en.wikipedia.org/wiki/List_of_circulating_currencies.
Number formats
In English, you would write number like 1,324.98. However, in German, it would be 1.324,98 - can you notice the difference? To make you text appear as native German, you should change number formatting. If it's plain text, your translator would take care of that, but if a program is generating these numbers, the number format needs to be adapted.
Dates
Many programs and websites display dates. Blogs, for example, normally display the publish date for posts. May sites also display the current time.
Date format changes between languages. Not only the names of months and days but also their order. In the US, people normally use Month/Day/Year. In Europe, it's Day/Month/Year.
To handle this correctly, programs normally implement a special function for displaying dates. This function would take into account the locale and display the date as it should.
Some date formatting examples
- US: %Y-%m-%d
- Europe: %d-%m-%Y
- Japan: %Y-%m-%d
%Y - year, %m - month, %d - day
For further reading, visit the ISO page - http://www.w3.org/QA/Tips/iso-date.
Units
Supposing your doing a recipe application and you need tell tell the cook to use one pound of cream. How would a French chef feel about it? In Europe people don't use pounds, inches or feet. They use the Metric system. Your recipe should ask for half a Kilo of cream (or more precisely, 453.6 grams).
Just like dates, numbers with physical units should go through a special routine which adapts their display for the selected locale.
Wikipedia has a great page about different unit systems and where in the world they're used - http://en.wikipedia.org/wiki/Units_of_measurement.
Phone numbers and addresses
We're not going to suggest that your phone number is different when dialed from Australia, but maybe it needs to be displayed slightly different.
When you display phone numbers inside the US, you normally start with the area code and omit the country code (+1). If you need foreign clients to call you, the country code should be included too. You can also go the extra mile and find out how they normally dial foreign numbers.
Same thing goes for the address. Make sure it ends with your country.
And, if your application needs to input and process user phone numbers and dates, make sure that you support their format. Some countries have states, some have districts (or provinces) and some don't have any.
Time zones
Some programs need to do certain things at given times. For instance, if you're doing online trading, your program depends on the stock market and its local time.
When you display the time, remember to also display the time zone. It's going to be very helpful for many people if your program could switch back and forth from your time to their.
Conclusions
Most of the items we covered are best handled by writing specialized routines for displaying values. It's also important that the program store the all values in a way that permits conversion. For example, you can store dates as a string, or as seconds since epoch (see http://en.wikipedia.org/wiki/Unix_time). Saving the date as an integer will greatly simplify adapting it to different locales.
Managing the visual formatting in one place has many advantages:
- Test once, works for all.
- Easy to maintain (like adding a new language).
- Flexible - can be adapted to any specialized display needs.
The obvious cost is that all this has to be taken into consideration when writing the program or building the website. Like in many other cases, taking the long road usually helps get there faster.