Techopedia: Proper Localization of Software is Crucial to Succeed in Other Locales
 |
| Localization. Collage: Baltic Media |
Even
though the world is a lot smaller thanks to the internet these days, there are still a
lot of differences that software developers need to take into
account when trying to reach an increasingly global audience. Aside from the
obvious language issues, they'll have to design applications that can adapt to
different measurements and conform to local laws as well. Localization and internationalization will only become more important as
more applications move into the cloud and can be accessed from anywhere in the
world. (To learn about using your IT skills internationally, see IT Skills: Your Passport to Adventure.)
Language
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.
Naming Conventions
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.
Dates
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.
Units
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 latest
anime, 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.
Regulations
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.
Conclusion
Converting
software for other countries can be daunting, but some foresight when designing
software can make the task much easier in the long run.
Comments
Post a Comment