internationalizaton vs. localizability

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

Now note that this does fit the model I had where I pointed out that localization presumed a good internationalization story, but it goes a little further than I would here....

I always called "giving an application the ability to be localized with reasonable effort" localizability rather than internationalization.

Localizability not only included "good internationalization" and "good typography" but it also included stuff like

Compare this with the items in Norman's list that I considered internationalization:

The difference between "localizability" and things under "internationalization" in my mind being that items in the "I" list are required even if a customer is going to use the product in its original user interface language. So if they want to consider the plain old English UI to be properly internationalized for them, they need all of those items to be correct. Even if it is never localized at all. And if the UI needs to be localized then it is much more expensive and difficult to do so if the items in the "L" list are not done. But items in the "L" list are technically not required if the product is never localized -- there is no real harm if they are done, but it is time that is only needed to prepare for good localization and if it is never done then the lack will not be noticed by a customer who is not looking at the localized version....

Perhaps I need to add a glossary here? People may or may not agree with my definitions, but listing them out in one place may save some time, like what I did with some keyboarding terms.... :-)

This post brought to you by "z" (U+007a, a.k.a. LATIN SMALL LETTER Z)
(A letter that knows it has a less prominent prominent placement if there were a UK localisation of internationalised software products!)

So glad you wrote this. I asked what you meant by internationalization in your International support as a developer tax (http://blogs.msdn.com/michkap/archive/2005/08/22/454561.aspx) post. To me, you are saying internationalization is making your program work across all locales. This is something that can be done without localizing and without even using Unicode if multilingual support is not a requirement of the program. Sometimes the best way to define terms is to distinguish them from other ones. Here internationalization is distinguished from localizability, and localization is the act of translating the program to a particular language (and locale?). And multilingual support being an option of internationalization. Is this pretty close?

I'm always amused by these discussions where people are focused so much on the interface they forget that a huge part of localization can have profound effects on your business logic.

I spent many years working on popular software for personal finance and small business accounting. From time to time, we made versions for markets other than our US base. Granted, the language issues were easy for the particular markets we targeted. The hard bits were making our program logic flexible enough to handle the sometimes surprisingly different requirements.

For example, in Canada, loan interest is compounded differently than it is in the US. That was a good warm-up problem. We learned to parameterize our calculations more thoroughly.

VAT-style taxes were a bit more of a re-work than our US-centric sales tax model.

Our small-business products were specifically designed to allow users to go back and correct transactions that were incorrectly entered. It was a decision to make our product more accessible to non-accountants. (Strict accounting would prohibit changing the mistaken transactions and instead require adding an adjustment transaction to offset a mistake.) When we tried to enter a new market, we ran into problems getting an accounting certification that meant we'd be overlooked by most of our target customers.

And the one that drove me nuts was the fact that the length of A4 paper was not a multiple of 1/6 of an inch. Many continuous (tractor-feed) printers can only handle pages that are a multiple of 1/6 of an inch. Many of the paper manufacturers understood this limitation and compensated by making their tractor-feed stock a tad longer than true A4. But many Windows printer drivers refused to believe this false A4 size. The discrepancy was minor, so if you printed a 20-page report from Word, you'd hardly notice the drift. But when you're trying to center values in boxes on pre-printed invoices, your customers will start calling by page 10. Of course, once we solved that, our supplies group changed forms providers who didn't cheat the form length.

So I'm not sure whether anyone would characterize these issues as either internationalization or globalization or localization. But it's an often-overlooked hard part of the job, whatever you call it.

Your definition for localizability is very accurate but please take a look at http://www.microsoft.com/globaldev/getwr/steps/wrg_g11n.mspx):
and you'll see that your definition for internationalization departs noticeably from the current Microsoft terminology. In the chart you'll see that internationalization actually includes localizability (and a few other things, even more if you add Customizability and Market Customization into the picture, e.g., see "The High-level View" in http://www.microsoft.com/globaldev/gddc2004/1-A-1_files/Default.htm).

I had pretty much the same comment to
"Its not localization, really" (not noticing the newer post).
This is something quite fuzzy for many, and the industry does not help too much. Sometimes ppl go overboard. Just read this:
http://blogs.msdn.com/drintl/archive/2005/06/07/426289.aspx

I would separate this (quick) into:
i18n = "is what developers do"
l10n = "is what translators do"
g11n = "is what companies do" (when the "go global"), meaning marketing, local partners, open branches, etc.

This was the traditional meaning for gloabalization, and still is for managers. Using it for software will confuse them (and others). See also http://en.wikipedia.org/wiki/Globalization

I always wanted to write sometimg about this, but I think I will really have to :-)

About "i18n without l10n" I agree. But "i18n without unicode" no. Because it contradicts this: "program work across all locales" If I run an English application on an English system with the locales set to Japanese, I cannot get proper time/date/currency formats if I am not Unicode.
I don't consider "if multilingual support is not a requirement", because it basically anulates everything. i18n is all about multilingual support. Otherwise we are back to the 80s, where you can just use US date/time/sort, and i18n is meaningless (if I don't need multilingual support and don't need localization).