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!)