.
|
|
|
|
So, you went out and created this wonderful little gem of a program that works just great and all of the big wigs in the company came down and they all patted you on the back and sang your praise. Then it happened. Some bright spark in marketing popped up and said, "You know, this would be just the thing our customers in Germany are looking for. Put together a German version by the end of day so that we can take it to a trade show. If that isn't enough time, have it by end of day tomorrow." Localization of a project is one of those things that we don't normally think of during the development and the development environment we're most used to doesn't really go out of its way to encourage us to think of development in international terms. With a little planning ahead of time, localization isn't as big a pain as you might think. Another name for localization is I18N and, by this, we mean making a program work in a country other than the US. For the most part, the program logic doesn't change just because the machine that is hosting your wondrous work of art is perched half way up a slope in the Himalayas instead of on a laptop poolside a Miami hotel. The UI, on the other hand, is going to be wicked out of whack. Somehow, you want your program to change its skin in a fashion that is appropriate for the locale of the machine on which it is running. The easiest way to do this is to stuff the localizable UI elements in a resource only DLL, one DLL for each locale. At run time, the program figures out what country it is in and loads the appropriate resource DLL. Thereafter, any time that a string, dialog or any other UI element is required, it is loaded from the resource DLL. Simple, right? Rules to keep in mind when making a locale sensitive program. Here's some detailed information on how to create localized resource only DLLs.
|
|
|
