At least one EMC customer has reported issues with running VSI 4.0 on a system with a non-English locale. Unfortunately that is to be expected. I mentioned in a tweet a few days ago that VSI 4.0 does not currently support non-English locales at this time, and I’d like to take the opportunity to explain why.
For those of you not familiar with the process of creating internationally-useable applications, there are two distinct steps: internationalization (commonly abbreviated as i18n) and localization. The first step, i18n, is the process by which you prepare your application for the second step, localization. Preparing an application for localization involves several steps:
- You must move all of your application’s strings, images, and even some visual formatting elements to one or more resource files. This decouples your application’s or assembly’s codebase from the information that may need to differ based on the culture of the user’s system running the application.
- Additionally, not all cultures read from left-to-right. While it may be better to use a box/flow layout for designing user interfaces (UIs) in order to more easily support right-to-left layouts, this alternative to a fixed layout takes a substantially greater amount of development time.
- While many cultures employ a phonetic alphabet, there are still many that rely on logographic languages. One such example is Nipponese where the word tree may be represented by a single symbol. So a warning message that consumes 100 pixels in England may in fact take up 300 pixels in Japan due to the width-additive nature of logographic scripts.
The above steps are just three of the many areas where developers must be conscious of i18n compatibility. And making an application i18n compatible is not even half of the story. Next comes the process of localization.
Localizing an application is straight-forward if the i18n process was handled with care (although there are some nasty issues you can run into). Ideally localization involves creating resource files for each locale that you want to support. Each of these resource files should contain the appropriate, localized values for the same keys in your default resource file. For example, if the key “WelcomeText” contains a string value of “Hello”, then the key “WelcomeText” in the file Resources.fr.resx would contain a string value of “Bonjour.” However, while the process of creating the localized resource files is fairly trivial, it adds a substantial amount of testing time.
For every locale supported, a full test regiment must be developed to ensure that the correct strings are in place, layouts are correct, and that all of the formats used do not cause any exceptions. So while moving localizable resources into resource files does make localization much easier, it does nothing to relieve the burden of the testing that must occur for every locale.
As you can see, i18n has a fairly set cost, but the cost of localization increases with every locale you support. The resources must be translated and tested. This means having a specialized team of people who speak many different languages and have knowledge of many different cultures in order to properly handle localization. Or you can out source the task to teams around the world. Regardless of how it is accomplished, it is not free.
And yet, VSI 4.0 is free. Free to all EMC customers in fact. We have tried extraordinarily hard to produce software that will make managing your EMC storage devices from the vSphere Client as simple as possible. And as much as it pains us to not support all of the locales of the world, it is not something we had the bandwidth to accomplish in tis one release cycle. It is the stated goal of our team to continue to not only produce outstanding software, but also move forward with localization efforts. We are working with management to make sure that EMC customers on every continent can enjoy the wonderful software that is VSI 4.0!