  
During runtime, the country specific resource only DLLs are
in the same directory as the main module.
At build time, the convention is to place the country
specific resource only DLLs directory under the module being serviced.
Here is an example of the module Base and where its
supported localization DLLs will reside.
+--Path+
+--Base+
+--BaseDEU
+--BaseENG
+--BaseESN
+--BaseFRA
+--BaseJPN
+--BaseITA
There are two basic methods for determining the locale,
directly reading the registry and through a Win32 call.
The string value sLanguage in subkey HCU\Control
Panel\International contains a three character string value which specifies the
current language.
The current locale can be determined programmatically
through the use of GetLocaleInfo. GetLocaleInfo is an exceedingly useful, if
somewhat confusing, function. It returns localization information on just about
any aspect of a locale.
This is an example of getting the numeric locale:
DWORD dwLocale;
GetLocaleInfo(LOCALE_USER_DEFAULT, LOCALE_ILANGUAGE | LOCALE_RETURN_NUMBER, (LPTSTR)&dwLocale,
sizeof(dwLocale) );
Programmers, being the inventive things that they are, will
have a tendency to do things their own way. It just so happens that there are
enough little issues involved in getting locale specific values and converting
between UTF8 and Unicode that these enterprising little devils will have a
tendency to write classes to handle the petty details. If you have four
programmers then you are going to end up with 16 utility classes. It is more
cost effective to just go ahead and define a custom class from the start to
assist in locale specific operations such as
- Conversion of a locale ID into the three character
language code
- Conversion of a numeric value into a string
- Conversion of a date-time into a string
- More conversion helpers as are deemed useful
| 
.
