§ ¶Thanks, but only my computer speaks Japanese
Due to some recent testing, I currently have the system locale on my Windows 7 x64 system set to Japanese, but with location and language settings still set to US English. I haven't changed it back because I'm too lazy to reboot.
Imagine my surprise when I tried to get help from the Open Watcom disassembler:

Needless to say, this is less than helpful considering the only Japanese words I can read are those for OK, cancel, yes, no, item, attack, save, and idiot.
I'm pretty sure that you are not supposed to use the ANSI code page (GetACP) or otherwise system locale setting for language selection. Sadly, a quick search over MSDN reveals that Microsoft's guidance is less than clear.
Comments
Comments posted:
I have set my system to English as the UI language and German as the locale for quite a while now. It's astonishing how many programs consider the locale the thing to look for when determining the language in which to display the UI.
But even with guidance in MSDN being less than clear I think it should be fairly obvious to distinguish »Stuff for formatting dates, time and numbers as well as sorting order« and »UI language«. This distinction exists for over a decade now on Windows and still people get it wrong.
I think Unix conflates both in a number of environment variables (from LANG to LC_WHATEVER) and in many environments the locale is easy to get but the language is not. Gettext as a popular open-source library for i18n making this mistake is probably not a big help either.
Johannes - 03 09 12 - 20:43
This is so ridiculous. At home I have a German version of Windows, configured to use English language and location set to Sweden.
There are applications that manage to make the user interface use all three languages, I just don't get it how it is possible to mess it up to that degree!
Of course the iOS AppStore (as just one example not involving Windows) is just as incompetent: Having the language set to English, using a Swedish credit card (and thus Swedish store - so if you change credit cards be prepared to learn a new language along with it) while being in Germany results in just the same mess.
Reimar - 03 09 12 - 21:26
And concerning Unix: it is quite clear. LC_MESSAGES is the message language. LANG should never be used directly, it just gives the defaults for all LC_* that are not set, and LC_ALL overrides any other LC_*. Functions like setlocale figure it out for you.
Nevertheless I am quite sure there are programs that get it wrong, but I am also quite sure gettext gets it right.
Reimar - 03 09 12 - 21:31
> Gettext as a popular open-source library for i18n making this mistake is probably not a big help either.
AFAIK, they do this intentionally, because apparently changing Windows UI language is so hard compared to changing the locale (or something like this). It doesn't help that there's no mapping between LCID and ISO language code before Vista, so programs which use gettext, but want to do the right thing have to resort to something like this:
(oh, and apparently Metro^H^H^H^Hodern UI apps can't decide what to use either - even some Microsoft's own...)
ender - 04 09 12 - 03:51
Silly blog ate my URL:
http://git.gnome.org/browse/gimp/tree/ap..ender - 04 09 12 - 03:51
> But even with guidance in MSDN being less than clear I think it should be fairly obvious to distinguish »Stuff for formatting dates, time and numbers as well as sorting order« and »UI language«. This distinction exists for over a decade now on Windows and still people get it wrong.
That's what I thought, until I reviewed the Control Panel and the MSDN docs. Here's the problem. In Region and Language on Windows 7, I have four drop-downs with settings that vaguely look like a language setting. We'll cross the Location one first as the least applicable. The one under Keyboards and Languages mentions "input language" instead of "language" so we'll give that one a pass. That leaves the Format drop-down on the Format tab and the Language for non-Unicode programs on the Administrative tab. Care to guess which one you're supposed to change? While IMO most would pick the one on Admin, that's the one that sets the system locale (ACP) and counterintuitively it's the Format one that GetUserDefaultLCID/GetUserDefaultLocale() returns. The Format setting is also the only one of the two that non-administrator users can set. It's not clear at all.
Even more confusingly, there is a separate per-user UI Language setting in current versions of Windows, but apparently it's tied to MUI, so if you don't have multiple language packs installed on Windows you don't even get the drop-down to change it. Kind of fun when you get instructions to change a setting that inexplicably doesn't even show up on your system!
What is needed to sort this out is a set of diagrams showing how the various fields in the Control Panel map to the various APIs and what values are returned for common but edge case setups. I didn't see this in MSDN. IIRC Thai is a fun one on Windows due to the way it's default set up as a kind of hybrid US English system.
Phaeron - 04 09 12 - 16:39
I have my default locale set to Russian, but the language to English. It is really annoying when programs that can't even display Russian (such as some NVIDIA drivers of old) try to be extra-helpful and guess the language from the locale.
Alexey - 05 09 12 - 01:25
Yeah, the language selection UI not appearing when no MUI packs are installed is somewhat annoying. It's even more annoying that Microsoft limited MUI packs to the most expensive editions of Vista and 7...
ender - 06 09 12 - 08:01
I can't think of a multi-language system I've used where I *haven't* seen an example of this. Stuff loading in Japanese (for the same reason as mentioned in the post) on Windows, Unix software testing against the wrong variables, XBox 360 games testing the console's region instead of the selected UI language...it just goes on and on.
Whether it's due to lack of resources, foresight, or people/organizations simply not considering it to be important, localization seems to nearly always be an afterthought. (And the problem is hardly limited to software!)
mdl - 10 09 12 - 02:16
I hate programs which decide on their own which language they will be using. Not only translations can be really crappy, but if you get an error message, you often have no chance finding relevant info on the internet unless you get lucky guessing what it might have been if it were in english.
Kasuha - 10 09 12 - 09:52
Looks like your disassembler is using the -FU switch by default. I hear that in the future they will be supporting an -upyours switch as well.
(I hope you got a good laugh, sorry the comment was a little "blue")
Kris - 20 09 12 - 11:19
I had similar problems with blogspot detecting that I was in Japan, and assuming that I suddenly spoke Japanese. Livejournal may be older, but in that case at least, it definately works better.
The thing is, they must be plenty English-only speaking people in Japan, so I wonder how they manage.... I was hoping there would be a nice flag thingy to click on and change back to English, but no joy.
I suspect they're too many web APIs to detect locale, as well. Would be fun to find out how many and how to do it, though.....
Bajan13K (link) - 25 09 12 - 01:41
There's exactly 1 web API to select the language: the HTTP Accept-Language header, which tells the webserver all the languages that the user expects, and their order of preference. Of course, some webmasters know better.
ender - 26 09 12 - 07:33
@Phaeron:
Michael Kaplan (
http://blogs.msdn.com/b/michkap/) is the right guy to ask about localization issues with Windows and applications. If you relay your concerns to him perhaps he could at least push some documentation changes through.
I am also very annoyed with programs and installers auto-detecting UI language they think I want to use based on my regional settings.
I am ever more annoyed when badly written programs crash because they use localization APIs in a wrong way:
http://blogs.msdn.com/b/michkap/archive/..
Every developer should be extremely carefull when they have to use localization APIs, because now even decimal separator for numbers and currency may be different, not to mention other details -- it is really much more complex than it seems at first glance.
Igor Levicki (link) - 28 09 12 - 02:52