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
Yesterday, in response to my post Its not localization, really, regular reader CornedBee commented:
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."
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
- making sure there is space in controls for reasonable text expansion that may be found in other languages (up to 40% or more in some languages)
- having string insert tokens defined in a way that allowed their order to be changed
- allowing properties that may need to be changed by localizers such as control position, font selection, alignment, and such to be easily altered in the localization process
- not allowing the localization process to easily break application functionality
- good system for providing context for strings that need to be translated so that appropriate translations can be made
Compare this with the items in Norman's list that I considered internationalization:
- compatibility with existing codepages (and other existing encodings)
- the ordering of fields in dates (year at the beginning or at the end)
- the ordering of time fields (am/pm indicator at the beginning or the end)
- rules for sorting lists
- anything else that's needed for communication with humans in various cultures
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!)
# Ben Bryant on 9 Sep 2005 11:08 AM:
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?
# Michael S. Kaplan on 9 Sep 2005 11:17 AM:
Very close, Ben!
# Michael S. Kaplan on 9 Sep 2005 11:23 AM:
Sorry Ben, I should say more than that. :-)
I think your words cover the basic issues here and how to distinguish the various categories....
# Adrian on 9 Sep 2005 12:57 PM:
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.
# Eusebio Rufian-Zilbermann on 9 Sep 2005 2:07 PM:
# Mihai on 9 Sep 2005 2:24 PM:
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:
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).
# Ben Bryant on 10 Sep 2005 12:36 AM:
Thanks Mihai, that's an excellent point about multilingual support not a requirement. It is always required for internationalization if you are going to support a default user locale that has a different code page than that of the default system locale, e.g. English Language for Non-Unicode Programs but Japanese Standards and Formats.
go to newer or older post, or back to index or month or day