by Michael S. Kaplan, published on 2010/03/26 07:01 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2010/03/26/9982386.aspx
Over in the Suggestion Box, Ivo asks:
I am working on a software that has to support all languages available for Windows. When I install Traditional Chinese the system reports the language as "zh-HK" (using GetThreadPreferredUILanguages). So I added "zh-HK" to my list of languages and everything worked fine.
However few days ago a user of mine complained that it doesn't work on his system because his language is "zh-TW".
What is the difference between "zh-HK" and "zh-TW"? Is there really a zh-TW version of Windows, and if so, why isn't that language pack available for download?
I am going to be very precise in my language as I try to answer Ivo's inquiry.
To start....
The list of languages into which Windows is localized is much (much!) larger than the list of MUI Language Packs.
I mean, just as an example that I bring up often, there are the Language Interface Packs. By the time the ones in prior versions were done, they outnumbered the fuller localized versions!
Most languages can be in both kinds of packaging, and of course there are some languages that cannot be anything Microsoft ships at all, in any form, given current events and situations.
For this specific case, one can go to Microsoft's Taiwan home page (here) and perhaps click around a bit, watching the graphics if one does not know the language, to see that there are a wide array of Microsoft products, including Windows.
Now with all that said, the differences between zh-HK and zh-TW are not huge.
Some would argue that last statement has a flaw in it, that the real sentence might have been more accurate as:
Now the differences between zh-HK and zh-TW are not huge enough.
(This would be on the same basis as the lack of en-US/en-GB differences.)
Really the differences are minor and relate primarily not to actual language differences that would ordinarily suggest localization differences, but rather a little bit to the issues discussed in Sometimes, tech companies cannot take sides, and a lot to the general lack of effort to duplicate things that are only mostly duplicated more than anything else.
Because there is a certain importance in being both cost-effective and apolitical if one wants to sell products across as many borders as possible. And the actual business case that has to make for each type of download Microsoft puts up.
In the end, not every language will be available in every way, for all of these reasons and maybe even more.
Getting back to the original question...
Wait, what was the original question? :-)
When Ivo mentioned:
I am working on a software that has to support all languages available for Windows. When I install Traditional Chinese the system reports the language as "zh-HK" (using GetThreadPreferredUILanguages). So I added "zh-HK" to my list of languages and everything worked fine.
Was he referring to a desire to localize the software into every language into which Windows is localized?
If so, then let's not forget the LIPs, which will be streaming out kind of semi-continuously for the next year and beyond.
The other differences between zh-HK and zh-TW are more to do with the locales themselves, and those differences (not to mention the obvious fact they are both on the list!) are on every machine. Windows is being sold both places, and customers are hopefully getting what they are looking for.
So as long as you are doing the right thing in regard to globalization support users will see the correct results on their machines no matter what language version they have installed.
Other differences? Well, different sorts, different focuses on character support (HKSCS vs. CNS11643, etc.) in relatioin to font choices, and such. I have talked about these things in the past.
Some differences are missing from qall versions of Windows that might be useful to provide; for example there is not quite the Cantonese support (important for Hong Kong, not so much for Taiwan) that I would personally like to see, but I'm doing a little something there for a starter, and there are genuine companies stepping up with professional efforts as well.
The most important thing to take away from all of this? There can be:
Anyway, I hope that answers Ivo's question; if not I expect there will be a comment, presently.
Azarien on 26 Mar 2010 2:25 PM:
It's nice to see that Microsoft's Chinese and Taiwanese site use vertical text for the animated panels (the Silverlight applet). I can't comment Korean, but it seems really, really weird that Japanese site uses rotated text instead (like in English). It's perhaps the first time I see such text in Japanese.
(but I'm not a native speaker of any language involved in this post)
Daniel Cheng on 26 Mar 2010 5:12 PM:
Cantonese IME support is available in Chinese (Hong Kong) version of Office 2007. It use the TSF.
The sad thing is, Word does not support TSF well.
For example, if you press Ctrl-B (for bold) while typing, all characters in pre-commit buffer(?) are cleared.
Ivo on 26 Mar 2010 6:26 PM:
Thanks. That's pretty much what I suspected. But if the 2 languages are so close to each other, shouldn't one be like a fallback for the other? I was kind of hoping that the similarity between the languages is coded into GetThreadPreferredUILanguages, so it will return "zh-TW, zh-HK" on "zh-TW" systems.
I also (probably naively) expect it to return "en-GB, en-US" on a British Windows.
Let's say that my app is translated in French and English, and French is being the default. Now on a US system I will get the language name as "en-US" and show the English text. On a British system it will be "en-GB", and since it is not a language I recognize, the app will show French. I hope you see the problem I'm trying to describe. What is the correct way to pick the right language?
Michael S. Kaplan on 27 Mar 2010 2:18 AM:
Fallback doesn't tend to work that way, for any of the examples you give (other than the fact that all will often fall back to the "default" lang, like en-us being the "default" English).
The correct way to solve the problem is to set the preferred UI languages for your aspp which will then set the fallback list for your process since it is your custom results that have the kind of unusual requirements....
Ivo on 27 Mar 2010 8:29 AM:
Hmm... OK, forget about GetThreadPreferredUILanguages and fallbacks then. I'll try to state my question differently:
I have translations of my application for a set of languages. Lets say "English", "French", "Traditional Chinese" and "Arabic". For the sake of this discussion I'm talking about purely text assets and not locale differences like date/time, decimal sign, etc.
Given the name of the language I get from the system - "en-us", "ar-kw", "zh-tw", etc. how do I pick from the languages I support? If there is a "close enough" language I want to pick it. If not, I want English.
For example: I want "en-us" and "en-gb" to map to "English". I want "zh-hk" and "zh-tw" to map to "Traditional Chinese". But "zh-cn" can't map to "Traditional Chinise", so it will have to pick "Simplified Chinese" if I have it, or default to "English".
I can of course have a long table in my code that tells me to map "en-gb" to "en-us", "zh-tw" to "zh-hk", etc. But I have no idea how to create one. I know only English, Bulgarian, and some Russian. I don't have a clue if "ar-sa" is a suitable substitution for "ar-kw" for example. So is there something in Windows to help me, or am I on my own?
BTW, I'm working on a shell extension which integrates into Explorer. So picking the correct language is even more important than for regular applications. Ideally the language of the extension should match the language of the system, that's why I don't want to give the user the option to pick a language.
Michael S. Kaplan on 27 Mar 2010 8:45 AM:
Since the principle of "close enough" is one that is a matter of opinion, there is no Microsoft mechanism to make those guesses beyond what I have said -- therefore it is up to the app to decide (up to you)....
Cheong on 28 Mar 2010 7:05 PM:
If just for the sake of choose whether to use Trad. Chinese or Simp. Chinese, LCID can provide satisfactory answer:
Chinese - Hong Kong SAR 0c04 3076 1028 Chinese (Traditional)
Chinese - Macau SAR 1404 5124 2052 Chinese (Simplified)
Chinese - People's Republic of China 0804 2052 2052 Chinese (Simplified)
Chinese - Singapore 1004 4100 2052 Chinese (Simplified)
Chinese - Taiwan 0404 1028 1028 Chinese (Traditional)
The locale that displays Trad. Chinese returns 1028 and those display Simp. Chinese return 2052.
Cheong on 28 Mar 2010 7:18 PM:
Ok, I know that you don't want people continue to use LCID. But given that LCID provides correct answer for this question, I guess it doesn't harm to use functions like LocaleNameToLCID() or IMultiLanguage::GetLcidFromRfc1766() to help determine what language interface to use.
referenced by