As Michael Kaplan, our very own i18n guru noted in my previous blog, localizability is not the same as localization.
Designing a software's code and resources such that they can be localized and presented in other languages thus making it usable in other languages is called localizability. This means, I need to design my product in a way that if tomorrow I want an international developer to use it, the software must be easily lendable to localization. Localization is the actual process of localizing the resources used in the software, thus making the product ready in a new language.
Umm...imagine I weave a yard of cloth. Suppose I want to make strips of different colors from the cloth. I will have to ensure that the cloth is actually ready to be dyed. I have to check if the cloth has been weaved with the right consistency and has an even surface that lends itself to dying. I might want to soak it in water and dry it once just to ensure it absorbs the dye well. Then when the cloth is ready to take color, I go ahead and dye the cloth in different colors. The process of making the cloth ready to take dye properly is analogous to localizability whereas the process of actually dyeing the cloth in different colors is analogous to localization. Suppose I had made the cloth out of a material that cannot be dyed, then I have chosen the wrong raw material. It means that in order to make a blue piece of cloth I have to weave a separate cloth with blue thread and a pink piece of cloth a separate cloth from pink thread! I cannot dye a blue cloth pink or a brown cloth blue. There is no common cloth that I can use to create different colored clothing at the end of weaving! This is indicative of an unlocalized product where the core code cannot remain constant while the presenting language changes.
Time for an illustration. Imagine a simple winforms app where I have a button and a textbox. The button has text called "Please Click" and then the string "Hello World" appear on the text box upon clicking the button. Suppose I hardcode the strings "Hello World" and "Please Click" in my win forms code. The app will work fine when you expect English strings. But what if I want a Japanese developer to use my app? I want to display the 2 strings in Japanese. What do I need to do? Go back to my code, change the hardcoded strings to Japanese strings and recompile my app. But wait, then this wont work for English developers. Oh! What a mess. Imagine if real world products like VS would have to do this with millions of strings hardcoded in their sources...
But hang on...I have a plan. What if I moved these strings to resource files? Then I just need to include separate strings for each language I want to localize my product in and selectively pick up the right resource while displaying the form. That way, I do not need to rebuild my app each time I want to see my app in a different language either. That sounds cool. That is one aspect of what localizability is. Designing your software such that localization of resources becomes very easy and does not require source code to change is what localizability is. Later, when you go and actually translate all of the strings that you use in your product to other languages and include those strings in resource files, you are actually doing localization of your product.
Obviously localization requires the localizer to be fluent in both the source and target languages. So, we cannot have the product team doing localization of their products for all given languages we want to ship in simply because we may not have folks on the team who are fluent in all of those languages. So, at MSFT we have a separate localization team that does the actual localization of resources. Albeit, it is the job of the product team to ensure that the product is localizable. We have to run localizability tests on the product to ensure that all localizable resources are moved to a separate resources file that is marked for localization and no localizable strings are hard coded in the product code. We also need to check if UI has been designed in a way that if larger fonts used in other languages or longer strings that might be the equivalent of shorter English strings can be properly accomodated and rendered.
I guess that draws a little clearer line between localizability and localization. :)