{"id":126,"date":"2008-06-10T16:20:48","date_gmt":"2008-06-11T00:20:48","guid":{"rendered":"http:\/\/www.curlybrace.com\/words\/?p=126"},"modified":"2010-12-15T19:56:13","modified_gmt":"2010-12-16T03:56:13","slug":"setthreadlocale-and-setthreaduilanguage-for-localization-on-windows-xp-and-vista","status":"publish","type":"post","link":"https:\/\/www.curlybrace.com\/words\/2008\/06\/setthreadlocale-and-setthreaduilanguage-for-localization-on-windows-xp-and-vista\/","title":{"rendered":"SetThreadLocale and SetThreadUILanguage for Localization on Windows XP and Vista"},"content":{"rendered":"

<\/p>\n

Simple Localization<\/h3>\n

In classic Windows programming, the quickest way to handle localized resources is to put all languages into the same resource file, then use SetThreadLocale<\/tt><\/a> to tell Windows that it should return resources tagged with the specified language identifier<\/a>. Subsequently, any attempt to load a resource by that thread will cause Windows to prefer resources corresponding to the specified language code.<\/p>\n

Vista Complications<\/h3>\n

As of Windows Vista, calling SetThreadLocale<\/tt><\/a> will appear<\/i> to work, but will have no effect. Your application will continue to use load resources using whatever language identifier is set as the user’s default.<\/p>\n

Under Windows Vista, SetThreadUILanguage<\/tt><\/a> must be called instead of SetThreadLocale. This function is in Kernel32.dll. It appears in Vista, Windows 2008, and some versions of Windows XP. Under Windows XP, this function will not<\/b> have the desired effect, and I have no idea what it does under Windows 2008.<\/p>\n

Since the function isn’t available on all systems, you will probably want to use GetProcAddress<\/a> to locate the function, and call it using a function pointer. However, since the function appears on Windows XP, but does not behave in the desired way, it’s important to only call it on Windows Vista.<\/p>\n

Resource Storage<\/h3>\n

To use the SetThreadLocale<\/tt> or SetThreadUILanguage<\/tt> methods, the resource file must first be populated with all required languages. Each translated resource file should be appended to the .rc<\/tt> file, each one following an appropriate LANGUAGE<\/tt> statement<\/a> and corresponding language identifier<\/a>. (note that you could use separate .rc<\/tt> files and include them, in which case there are gotchas<\/a>).<\/p>\n

Is it Vista?<\/h3>\n

This function should reliably indicate whether the current OS is Windows Vista. I use GetVersionEx<\/tt><\/a>. Note that, even though we’re using an OSVERSIONINFOEX<\/tt><\/a> structure, we have to cast its pointer so that it appears as a OSVERSIONINFO<\/tt><\/a> pointer. No guarantee of future compatibility is implied:<\/p>\n

\n
bool IsOSVerWindowsVista()\r\n{\r\n    OSVERSIONINFOEX osver;\r\n    ZeroMemory(&osver, sizeof(osver);\r\n    osver.dwOSVersionInfoSize = sizeof(osver);\r\n\r\n    if (!GetVersionEx((OSVERSIONINFO *)&osver))\r\n        return false;\r\n\r\n    \/\/ dwMajorVersion 6 and dwMinorVersion 0 means Vista or 2k8:\r\n    if ( (osver.dwMajorVersion != 6) || (osver.dwMinorVersion != 0) )\r\n        return false;\r\n\r\n    \/\/ wProductType of NT_WORKSTATION means it's Vista:\r\n    if (osver.wProductType != VER_NT_WORKSTATION)\r\n        return false;\r\n\r\n    return true;   \r\n}<\/pre>\n<\/blockquote>\n
Calling SetThreadUILanguage Dynamically<\/h3>\n
The trickiest part of using GetProcAddress<\/tt> to dynamically call a function at run-time is getting the function pointer declaration correct.  This type definition should work for SetThreadUILanguage<\/tt>:<\/p>\n
\n
typedef LANGID (WINAPI *FP_SetThreadUILanguage)(LANGID LangId);<\/pre>\n<\/blockquote>\n
Now, you have a function pointer type called FP_SetThreadUILanguage<\/tt> which can be used like any other type.<\/p>\n
This function pointer can be used to dynamically call any function within a loaded module (DLL).  SetThreadUILanguage<\/tt> lives inside Kernel32.dll.  Since Kernel32.dll is required by all Win32 processes, we can simply use GetModuleHandle<\/tt> to find it, we don’t have to use LoadLibrary<\/tt>.  A pointer to SetThreadUILanguage<\/tt> can therefore be retrieved like this (unnecessarily verbose code):<\/p>\n
\n
HMODULE hKernel32 = GetModuleHandle(_T("Kernel32.dll"));\r\nFARPROC pFn = GetProcAddress(hKernel32, "SetThreadUILanguage");\r\n\r\nFP_SetThreadUILanguage pSetThreadUILanguage = (FP_SetThreadUILanguage)pFn<\/pre>\n<\/blockquote>\n
The function can now be called through the function pointer variable:<\/p>\n
\n
LANGID langid = pSetThreadUILanguage(myLangId);<\/pre>\n<\/blockquote>\n
SetThreadUILanguage<\/tt> returns the LANGID<\/tt> which has been set.  If the call was successful, it will return the same LANGID<\/tt> that was specified.<\/p>\n
Constructing a Language Identifier<\/h3>\n
Use the MAKELANGID<\/tt> macro from Winnt.h<\/tt>, and supply LANG_Xxx<\/tt> constants from same.  For example, Simplified Chinese would require:<\/p>\n
\n
DWORD dwSimplifiedChinese =\r\n   MAKELANGID( LANG_CHINESE, SUBLANG_CHINESE_SIMPLIFIED );<\/pre>\n<\/blockquote>\n
Non-Vista Platforms<\/h3>\n
On non-Vista platforms, SetThreadLocale<\/tt> can be used.  Instead of a language identifier, it accepts a locale identifier.  To generate the locale identifier, simply pass your language identifier to the MAKELCID<\/tt> macro, and supply SORT_DEFAULT<\/tt> as the second parameter:<\/p>\n
\n
SetThreadLocale(MAKELCID(myLangId, SORT_DEFAULT));<\/pre>\n<\/blockquote>\n
This example unconditionally sets the thread locale to Simplified Chinese in a single line of code:<\/p>\n
\n
SetThreadLocale(\r\n   MAKELCID(\r\n      MAKELANGID(LANG_CHINESE, SUBLANG_CHINESE_SIMPLIFIED), \r\n      SORT_DEFAULT));<\/pre>\n<\/blockquote>\n
SetThreadLocale<\/tt> returns TRUE<\/tt> on success, FALSE<\/tt> on error.<\/p>\n
Reference<\/h3>\n