Some months back, I was talking to my brother about a presentation that I was about to give on globablization to my team and he asked me if I had read Friedman! Then it struck me that globalization may be a very common concept within Microsoft but it sure wasn’t so common outside!
So, what is globalization? There are millions of people all over the world who do not know English or may not be comfortable speaking/writing it. Of course, several of them are very techie and computer savvy. Thanks to all the different languages that operating systems are available in, we have now democratized choice of language for developers all over the world. A Chinese developer need not write or even read a single word in English to develop any app on his system. Likewise a Spanish developer might choose to develop his apps in Spanish rather than in English. MS Windows is released in several languages – Japanese, Korean, French, Italian, German, Spanish, Traditional Chinese, Simplified Chinese, Arabic, Hindi and many more. Whew! That is a large list.
Ok – so I have an OS in Hindi. But what about my products? Of course I would prefer that my applications and products I use be in Hindi too, but it would not be very realistic to expect every single software in the world to be developed in all possible languages. So, sometimes developers do settle for English products, but install it on localized Operating Systems. Of course, I expect this to work. This leads us to the definition of globalization. Designing software for the input, display, and output of a defined set of supported language scripts and data relating to specific geographic areas is the process of globalization of software.
But, shouldn’t software work by default on whatever your OS language is? How does it even matter whether I use Hindi or Japanese on the OS? Ah! How I wish this was the case…it would rid me of half my testing work! There are several things dependent on the OS – stuff like currency, date/time, number formatting, bidi awareness, mirroring, IME support, etc (which we will go into detail in later blogs) The product we build should respect settings for all of the above factors and should be flexible enough to behave in a way that the current OS expects it to behave. As a simple example, suppose I have a Japanese system, then dates are rendered in yyyy/mm/dd format whereas on normal English-US machines, this would be mm/dd/yyyy. If my product displays dates, it should display in the former format on a Japanese machine and the latter on an English machine. Suppose your product takes filenames as input. It should work fine even when I provide filenames in Hindi. This calls for internationally aware code to be written while developing the product. In my coming blogs, we will explore how .NET supports this kind of internationalization automatically in their APIs.
Right. I have a German OS on my machine. What use is this to me if I do not have my products in German too? Yes, of course we realize that and that’s why we are shipping VS in German 😉 Coming to the definition of localizability then. Designing software code and resources such that said resources can be localized and presented in other languages thus making it usable in other languages is called localizibility of software.
Er – what was the difference between globalization and localization again? Let me cite an example. Suppose you have a Japanese OS installed on your machine. Now you install an English word processor software on your system. Note that the menu options and the word processor itself will be in English. If I can type a Japanese document and save the file and re-open appropriately, then the word processor software is globalized. Now, if I install a Japanese version of the word processor, where the menu options and the help are all in Japanese and obviously I can type, save and re-open a document in Japanese, then the processor software is said to be localized.
At Microsoft, we test the product we ship throughout the product cycle in several stages. We have concerted efforts on globalization testing and localization testing in every milestone. More on how we do that in coming blogs.
Till then, let me end my globalization blog with a localized goodbye 😀