Its not localization, really

by Michael S. Kaplan, published on 2005/09/09 02:30 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2005/09/08/462765.aspx


Recently in the newsgroups, Robert asked:

I'm just trying to understand that an encoding is a way to represnt numbers UTF-8/16 - a codepage is a mapping of numbers to characters - a localization is a ....

the localization is the bit I'm have trying to understand.

He got a few answers and then Norman replied in a slightly different way:

UTF-8, UTF-16, codepages, and other encodings are all encodings.  National standard encodings developed after corporate-developed encodings but before international standard encodings.  UTF-8 and UTF-16 are designed to support larger collections of characters than individual national standards supported, and they are intended to support all characters that were included in national standards plus some additions besides.  But of course the Unicode codepoints (numeric values of the encodings) for most characters have to differ from the codepoints that were used in national standards and codepages and most existing databases.

Localization includes compatibility with existing codepages (and other existing encodings), and translations of words and sentences, and the ordering of fields in dates (year at the beginning or at the end) and time fields (am/pm indicator at the beginning or the end), rules for sorting lists, and anything else that's needed for communication with humans in various cultures.

Now I have to say that the definition of localization he gave does not sit well with me.

Traditionally, most of what is listed there is known as internationalization, not localization. And this is not just my opinion, it is one shared by myself and many of my colleagues -- all of whom consider internationalization to be one of the largest aspects of our actual jobs.

The same opinion is shared by many of our colleagues who work in localization, too!

Now, I do not want to minimize the important kernel of truth in Norman's words here. If you do a poor job of providing internationalization support for a language, than your efforts to localize into it will pretty much be wasted. One could say that good localization presumes good internationalization.

But that does not mean they are the same thing -- after all, in order for the localization to be of good quaality you need good font support. But no one considers typography to be localization. For that matter, the localization efforts are wasted if your laptop does not have the appropriate AC adapter for your market, yet no one considers power management to be a part of localization, either.

The simple fact is that a lot of what happens in computer software involves dependencies -- and a quality localization presupposes good internationalization and typographical support upon which to build. There is simply no other way to be sure that you have a product that can be accepted by a customer.

And of course they won't even get there if the power management folks don't have their act together yet....

 

This post brought to you by "A" (U+0041, a.k.a. LATIN CAPITAL LETTER A)

 


# CornedBee on 9 Sep 2005 5:53 AM:

I always defined internationalization as "giving an application the ability to be localized with reasonable effort," and localization as "adapting an application to local language, appearance and similar issues."

referenced by

2007/09/01 We're confusing internationalization and localization, AGAIN

2005/09/10 You work in NLS? How many languages do you speak?

2005/09/09 internationalizaton vs. localizability

go to newer or older post, or back to index or month or day