SetThreadLocale
-
I am developing an application that is available in multiple languages. Currently we set the UI language for the application using an installer which means that you can run in German on any language OS. However there is one problem and that is with Microsoft dialogs and wizards. They seem to want to load the resources based on the current locale. An example is: OS is English, Locale is France, and you install German application. This results in French resources being used for property sheets while German is used everywhere else. There are two ways that I have found to stop this. One was to create a seperate DLL for each language. However the company I was hired to do localization work for seems to still be in afterthought mode and there is too much resistance for this. Not to mention if I had unlimited time to really do localization right there are many problems to fix. The second way was to call SetThreadLocale(). This loads the wizards correctly, however I keep seeing that SetThreadLocale() is a bad function and should never be used. Is this true? We already use our own version printf() to allow different non-standard tokens to be used in strings. So I also overwrote this so the use of formatting numbers, dates, and other localization settings is already preserved based on user locale. I just wanted to make sure I would or wouldn't be making a huge mistake using SetThreadLocale because I didn't know all the reasons it has been blacklisted. Thanks If you start a fire for a man, he will be warm for a day. If you start that same man on fire, he will be warm for the rest of his life.
-
I am developing an application that is available in multiple languages. Currently we set the UI language for the application using an installer which means that you can run in German on any language OS. However there is one problem and that is with Microsoft dialogs and wizards. They seem to want to load the resources based on the current locale. An example is: OS is English, Locale is France, and you install German application. This results in French resources being used for property sheets while German is used everywhere else. There are two ways that I have found to stop this. One was to create a seperate DLL for each language. However the company I was hired to do localization work for seems to still be in afterthought mode and there is too much resistance for this. Not to mention if I had unlimited time to really do localization right there are many problems to fix. The second way was to call SetThreadLocale(). This loads the wizards correctly, however I keep seeing that SetThreadLocale() is a bad function and should never be used. Is this true? We already use our own version printf() to allow different non-standard tokens to be used in strings. So I also overwrote this so the use of formatting numbers, dates, and other localization settings is already preserved based on user locale. I just wanted to make sure I would or wouldn't be making a huge mistake using SetThreadLocale because I didn't know all the reasons it has been blacklisted. Thanks If you start a fire for a man, he will be warm for a day. If you start that same man on fire, he will be warm for the rest of his life.
Localization / Internationization is not a simple task. It will be more complex if your application is not UNICODE app & need to support asian languages (eg. Traditional/Simplified Chinese / Japanese / Korea). Use SetThreadLocale() is fine if it solves your problem. But in my experience, it didn't. MS Press has a good book for that but I cannot find the name. There is a new book "Internationalization and Localization Using Microsoft .Net" which I havn't read.