|Localization. Collage: Baltic Media|
The most obvious difference between countries when localizing software is language. With over 6,500 languages spoken around the world, software localizers and translators have their work cut out for them.
Tom Scott demonstrates just how difficult changing an app to support different languages can be, with developers having to cope with not just different languages but different cultural concepts as well.
Developers have to contend not with just different languages but also differences among dialects of the same language. The nuances of language and the differences among language make it difficult to translate text from one language to another.
There’s nothing more personal than someone’s name, and there’s a surprising amount of variance in how people’s names are structured, at least for people in English-speaking countries.
Most people in the English-speaking world are familiar with names that have a first name, middle name and a last name, but in other parts of the world, that’s not necessarily a given.
With Spanish naming conventions, people tend to have a given name and two last names in Spain. In Latin American countries, people usually have two given names in addition to two surnames.
If you thought having two last names was tough, what about people who don’t have last names at all? Iceland is famous for its patronymic naming system, where people are identified by the first name their fathers, with a “-sson” or “-dottir” appended, depending on if a child is a son or daughter, respectively.
What does all this business about naming have to do with software? A number of applications are moving online, and that means that they’ll have to have some kind of registration form. Developers who want international reach will have to be aware of naming conventions in countries they want to support and avoid hard-coding their own ideas about how names are structured into their applications.
Naming conventions also affect how databases are structured. Wanting to support different naming standards later on will require a radical restructuring of a company’s databases, which can be very difficult, time-consuming and expensive. It’s best to be aware of this problem early on.
The other major pitfall for localization is date formats. In my native U.S., dates are structured month/day/year. For example, 5/20/2016 is May 20, 2016. In the United Kingdom, it’s the day that comes first, instead of the month. There are also other numerous subtle differences around the world, and it’s important for developers to be aware.
Another major difference around the world is which units should be used for measurement. Fortunately, it’s pretty easy to support as the world, with a few exceptions, has long since settled on the metric system, though there are exceptions. (Once again, my native country, the U.S., is one of them.)
It’s pretty trivial to convert between imperial and metric units for countries that still use them. Even the United Kingdom, where metric is widely used, still uses some imperial measurements and units nobody else uses, such as weighing people in “stone.”
Other Locale Information
There are lots of other smaller details that people localizing applications will have to be aware of. Currency is an obvious one. Developers offering services for sale will not only have to make sure that the currency is correct, but that the price in the target currency is fair.
Another issue is time format. Some countries express time using the 24-hour clock, and some even take it further. If you’re in Japan staying up to catch the latestanime, a program that airs at 2:00 a.m. might be shown in TV schedules as airing at 26:00.
The Unicode Consortium maintains an extensive database of locale information, the Common Locale Data Repository or CLDR.
Along with currency and time, another thing to deal with when expanding internationally is the legal environment. Although any halfway competent business will have legal counsel familiar with local laws, software developers may run into trouble. Google is dealing with the European Union’s “right to be forgotten” law and Yahoo has run into trouble in France over online auctions of Nazi paraphernalia. China’s infamous “Great Firewall” of internet censorship is enough of an issue that it probably warrants its own article. (For more on internet censorship, see Freedom of Speech on the Internet? It's Complicated.)
Dealing with Localization
So if you want to localize your applications for international markets, what are some best practices?
The best thing to do is to avoid doing as much of the hard work by yourself if you can. There are plenty of libraries out there that can handle things like converting units or currency.
Machine translation is another option, even though a human translator will be able to capture some important differences. Any encounter with Google Translate shows that machine translation still has a long way to go.
Supporting different languages will be easier if programmers support Unicode from the start. The days of programmers assuming one character equals one byte are long gone in our globalized world.
Developers also need to test their applications, preferably on people from the target country, to uncover any mistakes with translations or units.
In a nutshell, developers will have to think about supporting different countries at the outset.
Converting software for other countries can be daunting, but some foresight when designing software can make the task much easier in the long run.