| Date: | June 9, 2004 / year-entry #228 |
| Tags: | other |
| Orig Link: | https://blogs.msdn.microsoft.com/oldnewthing/20040609-00/?p=38963 |
| Comments: | 34 |
| Summary: | A reader asked, I was wondering why it's common for some Microsoft products to have a directory called "1033" within it's program directory installation location? What does it mean? This reader was probably from the United States, because 1033 is the locale identifier for "English (United States)", whose hexadecimal value is 0x0409. You may also... |
A reader asked,
This reader was probably from the United States, because 1033 is the locale identifier for "English (United States)", whose hexadecimal value is 0x0409. You may also find directories called "0409". Some programs use hex codes and some use decimal. Go figure. Here is a list of a whole bunch of locales and their identification numbers, both in decimal and hexadecimal. Now you too can become an expert in locale identifiers. The value of a locale identifier is given by the formula + 1024 * sub-language For example, Swiss German is LANG_GERMAN + 1024 * SUBLANG_GERMAN_SWISS = 7 + 1024 * 2 = 2055. So why would a program create a directory named after a language code? Many Microsoft products support a multilingual user interface. This means that the same program can be used to display its user interface in multiple languages. Office and Windows are the two biggest examples. Language-specific resources need to be broken out into their own directories so they won't conflict with resources corresponding to some other language. (For fun, I installed the Swedish language pack on my computer at work, so all strings - including the error messages - are in Swedish.) |
Comments (34)
Comments are closed. |
Sounds like an overcomplication of a simple technique typical of MS products.
Why not use "en_US" style locale codes like in Java, Linux and everywhere else ?
Win32 uses language code numbers (LCIDs) instead of language strings, so if you’re a program, it’s much easier to use numbers too.
You’ll get 1033 if you’re in any English locale, because Microsoft don’t produce localised English versions of their software.
People in 2057 find it hard to decide whether to follow US spellings as recommended by the various style guidelines or to use our own language.
If you look at the whole list of locales, they do have a "short-string" field that is similar to the normal "en_US" system. "en-us", "fr-ca", etc. I don’t know where you would use that though.
My big question: Is the Office implementation of this homegrown, or did Microsoft ever discuss or publish a DLL or at least design guidelines for using directory-based localization? In the products I’ve worked on, we have kept parallel .RC files, and at app load time we compose the filename to load the appropriate resource DLL. I like this directory approach, since you don’t have to do name mangling. But, I’m not sure how I’d use it with our existing MFC code, and its "LoadString", "LoadBitmap", etc. calls.
Use AfxSetResourceHandle() to tell MFC the HMODULE to look for resources in.
I think the .NET localisation model uses the short string names, e.g. it will create folders named "de", "de-DE", "fr", "fr-FR", etc. for storing localised resources.
I agree with Oleg. Using numbers might be a little easier for PROGRAMS, but I don’t think it’s much easier for PROGRAMMERS. This is another example of Microsoft’s crufty software designs favor obscured, short-sighted technical "advantages" over transparency of code and data.
Were Microsoft’s LCIDs invented before or after the IETF’s "en_US"-style locale abbreviations?
Now, excuse me, I’m gonna rant for a while :)
Here in Russia, computer users are divided into two distinct groups. There are ordinary users, who prefer software translated. And there are those who argue that the native language for software is (US) English and any attempt to translate makes it less understandable.
So the first install localized versions of Windows. And the second install the original and set the locale to Russian so that they have Cyrillic support in non-Unicode programs.
And then, here’s a description of my experience installing Ahead Nero Burning Rom 6.0.
Download. Install. Start CD Speed. It startleds me with its translated UI.
First reaction: “Sh*t! What’s this, make it back like it has always been!” (searching the menu and the options dialog)
Second reaction: “Whadd’ya mean it’s not customizable! Make it customizable or I’m not responsible for my actions!”
The Options dialog doesn’t give any means to set the language. If the translation were /any/ good, I might understand. But it’s /bad/, and this I can neither understand nor forgive.
Browse to sysinternals.com, download Registry Monitor. Start CD Speed. See many registry accesses, and among them one QueryValue on HKCUsoftwareAheadCDSpeedGeneralLanguage . What if…
[HKEY_CURRENT_USERSoftwareAheadCDSpeedGeneral]
"Language"="ENG"
Ahh. Much better. Let’s write to the vendor about the problem and the solution.
The question is, why wouldn’t they use GetUserDefaultUILanguage to decide which UI language to use by default? This call has been around since ME and 2000, it’s time to stop basing such decisions on the user’s locale…
…and it really should have been available since the very beginning in 95, because then people wouldn’t need to invent ways to guess (incorrectly).
oleg: Microsoft’s Locale IDs predate the whole "en-us" IETF way of doing things.
Centaur, I couldn’t agree more. As a student of Spanish, I have much of my comptuer set to display Spanish-style dates, times, etc., but I made sure that my language and location were set to English and the Untied States. Still, I get some programs that default to Spanish or even some that are a mix of both (like WinDVD Creator, which is in English with help files in Spanish).
Centaur,
Thanks for the rant. It’s an eye opener to me. I confess I use the same strategy in our apps: Look up user locale lang id. If that translation is not available, lookup system locale.
( But we do provide a menu item to override the default choice ! ;-) )
To the lights of your comment, I realize I should do it the other way around.
Actually, the user language should override the system language. On MUI-based systems, the system language is English but the user language is whatever language the user specified as "the language I want to see my menus and dialog boxes in" (regional settings control panel).
I’m not quite sure what Centaur wants here. I’m assuming Centaur’s user default UI language is Russian – so why complain when you get Russian dialog boxes and menus? Isn’t that what you asked for?
From what I gather, Centaur is using a non-MUI, English version of Windows, but with a Russian code page so that he can work with Cyrillic characters in non-Unicode programs.
In this case, GetUserDefaultUILanguage will still return 0x0409, so programs should be displaying English dialogs, not Russian.
He may also have set his locale to a Russian one, but even that should not have any impact on the languages used for dialogs. (Beginning with Windows 2000, "locale" and "language" are totally separate concepts.)
Raymond Chen tells….
And all of Raymond’s internal email replies today have SV: instead of RE: since he installed that language pack!
Me, and most of my fellow work-with-computers-everyday friends, use English as the language. Sometimes I even use an american keyboard layout on my swedish keyboard to find the []{};:/ and a bit quicker. From my parents computer (and phone calls) I know that the message reads "Programmet har utfört en felaktig åtgärd" in Swedish, but that is what you get for running Office 97 in XP since the Office XP (which they have bought and paid for) looks different.
Yes, I am using a non-MUI English version with Russian locale. The rant was primarily directed at those who check locale instead of language.
For the record, I believe the sequence should be:
0. Try to GetProcAddress of GetUserDefaultLanguageID in kernel32.dll.
1a. If it fails, we are on NT4 or Windows 98 or earlier. We cannot make any assumptions on user’s preferred UI language, so display a dialog listing possible choices.
1b. If GetProcAddress at step 0 succeeded, we are on Windows Me or 2000 or higher. Call the returned address and use that as the default language. For extra points from advanced users, display a language selection dialog with that language preselected. For extra points from not-so-advanced users, just get on with the installation.
2. In the program UI, provide an option to change the UI language. If the user never touches it, follow the UI language of the OS. Otherwise, always use the selected language. For extra points, give a “System Default” choice in the list which restores the follow-OS behavior.
2 Raymond Chen
I agree with "Centaur". Advanced users needs russian locales (for corect data handling), but wants english UI – menus, dialogs etc. Have you ever tried to read MSDN (or other) docs in English and make those commands in russian UI ?! :) I whould assure you that translators have funny imaginations ;) It is almost impossible to find out what is the correct russian menu item is
for corresponding english one.
Just an example "Explorer" translated as "Provodnik" which has those meanings: 1. train attendant, 2. electric(al) conductor.
;)
KC Lemson and I had an interesting discussion about the SV: thingy when I noticed it last week. It’s non standard, and IMHO a bug in outlook in Exchange mode (and in Exchange < 2000) :)
Go figure :)
The Locale information was added in DOS 3.3, along with codepages, as Simon pointed out, it predates the ISO internationalized naming conventions by many years.
Centaur,
If NT4 or <=98, you can still look up the system locale, which in your case would return English (correct?).
> The rant was primarily directed at those
> who check locale instead of language
BTW, Aren’t you mixing locale and language ? There is a system locale and a user locale. Each locale contains a language id (+ sort id)
see GetSystemDefaultLangID() and GetUserDefaultLangID()
Larry,
German is famous for translating re: as well. (to aw: IIRC)
Serge Wautier
> If NT4 or <=98, you can still look up
> the system locale, which in your case
> would return English (correct?).
Incorrect.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/intl/nls_9rec.asp says so:
> System locale
> How users can change: Regional Options (Control Panel item)
> Windows XP: Regional and Language Options
So, a user who has installed English NT4 can (and will) use Control Panel to change the system locale to Russian, so that console and ANSI applications use Cyrillic code pages. This has nothing to do with the user locale, which “determines default sort order and the default settings for formatting dates, times, currency, and numbers”.
> Aren’t you mixing locale and language?
I was using the word “language” to mean “UI language”. Sorry for not being specific.
> There is a system locale and a user locale.
There are the system locale, the user locale, thread locales, input locales, system default UI language and user UI language. Of them, the system UI language and user UI language are relevant to UI language selection. The system locale is relevant only in case your application is not fully Unicode, because your ANSI and OEM code pages will be dictated by the system locale and certain characters required by your UI language may be displayed incorrectly.
I second Mike Dimmick’s points about Microsoft using US LCIDs for ALL English locales. Too few folks at Microsoft understand the difference between locales and (orthographically different) languages. I’ve even noted that Microsoft Office webpages maintain that updates for their English language tools are only for US English users. There are many places where this English=US mentality produces problems, mainly due to ignorance, but there seems little interest in learning.
Non-US English is probably the least officially tested environment at Microsoft (and that includes UK, Canada, Austraia, NZ, South Africa, Singapore, etc etc) – in my years at Microsoft I used to find many crashing or recall-class bugs simply by setting my user locale or keyboard language to a non-US version of English. If Microsoft was actually serious about this HUGE market, then it would test software on it properly (rather than rely on employee dogfooding) and produce UIs with non-US spellings. The long-time proliferation of US spellings in MS products breeds resentment in our schools for Microsoft’s "imperialist" tactics. For once, I’m inclined to agree.
Oh, btw, for Longhorn, I noticed that my MUI files are being put in an en-US folder. So at least on todays Longhorn builds (and presumably the other public releases) the MUI files are being put in ISO-named folders.
I don’t know if it makes a difference one-way or another, the en-US vs en-UK (or fr-FR vs fr-CA if you’d rather) issue that Michael mentioned doesn’t change if the locale is represented as 0409 or en-US.
Btw, Michael, I don’t believe that Microsoft localizes for sub-languages (like en-UK or fr-CA), which explains why there are dialect related spelling errors. I may be wrong however, internationalization isn’t my strong point and it’s a notoriously tricky issue (an astoundingly tricky issue – see http://weblogs.asp.net/oldnewthing/archive/2003/08/22/54679.aspx for a very simple example).
I was very familiar with localization processes as I was international PM for a few products (and an int’l software evangelist back to 1995) and typically had to fight the same old battles with management with each release. I could list off a number of horror conversations I had with Test Managers, GPMs and GMs and their attitude to large foreign markets e.g. in 1999: "We are not going to doing anything for them even if the roof caves in" would be one of the nicer quotes.
MS doesn’t localize UI for "sub languages" but it is supposed to be internationally sufficient on all these languages. My point re non-US English is that the company invests more time testing for markets with very small populations than the very large population of English writers outside the US. That would largely be a matter of taking those markets for granted.
Right, German Outlook will also "translate" the "Re:" into an "AW:". I don’t know if you would consider this a bug, but it is at least part of a bug. A normal MUA will not add another "Re:" to the subject line when replying. Outlook will even remove an existing "Re:" before adding its version of the reply indicator.
With a little imagination you can already see what’s coming.
The problem is that Outlook will only remove a "Re:". But it will always add the localized version of it. The result is a subject line which will eventually look like this:
AW: AW: AW: AW: AW: AW: AW: AW: AW: AW: AW: AW: AW: Whazzup?
I hate that! It’s stupid, ugly, obnoxious and counter-productive.
The good news is that you can teach a German Outlook to use the English abbreviations in the subject line.
Florian, that’s explicitly why RFC2822 specifies that the only legal subject prefix is "Re:" – it’s explicitly to get rid of the AW: problem.
Interestingly enough, I believe that Outlook in internet mode does the right thing, as does the Exchange SMTP service, it’s just internal emails that have the AW: (or SV:) issue.
And if you’re using Exchange’s MAPI client, then Exchange handles subject prefixes differently – the AW: is the PR_SUBJECT_PREFIX property on the message, everything to the right of the AW: is the PR_NORMALIZED_SUBJECT property on the message. If you retrieve PR_SUBJECT, you get the concatenation of PR_SUBJECT_PREFIX and PR_NORMALIZED_SUBJECT. When you reply to a message, Outlook sets PR_SUBJECT_PREFIX to "AW:" and PR_NORMALIZED_SUBJECT to the original PR_NORMALIZED_SUBJECT.
That prevents the AW: AW: AW: problem.
I don’t think it does the right thing in Internet mode. Afterall I get AW: AW: subject lines outside the office when mailing with friends over the Internet.
And I am not sure I followed you on how Exchange’s MAPI prevents that. If everything right of the AW: includes an AW: then we’ll end up with an AW: AW: again, won’t we?
Maybe part of the problem is that not everybody uses Outlook but there are people which happen to use a different MUA. One, which does only Re: and not AW:. Or, that not everybody is German or Swedish. What happens is this:
I send an email with subject "Whazzup". My Outlook-using friend replies, we get the subject "AW: Whazzup". Now, once in a while I forget to fix the subject line when replying so we end up with a subject of "Re: AW: Whazzup". My friend replies and, guess what, we have: "AW: AW: Whazzup". Rinse, repeat.
(It gets even more interesting when you add more nations to the mix. Google for "SV: AW:".)
But since you said that RFC2822 does only allow Re: as a legal subject prefix I’d think that should probably Outlook drop the unnecessary subject prefix translations alltogether and sticks with only Re:, agreeing that this is definitely a bug. Yes, I think that would make me a little bit happier. (Same for was:/war: and the others.)
I use English Windows XP, but during instalation, I chose: Standards and formats = Slovak (I want Slovak dates, currency symbol,…), Location = Slovakia (that’s where I am), Language for non-unicode programs = Slovak (I need non-unicode programs to display filenames and like stuff in CP1250; such programs are usually unable to access files with special characters in their names unless this is set).
But the interface is still English. When the whole system talks to me in English, I probably want everything in English, because I like it so. If I wouldn’t, I would use a localized version of Windows. I surely don’t some applications in Slovak and some in English.
Now my facourite is nVidia’s driver. Somehow it decides I would like it to speak Slovak to me and you can’t persuade it not to. Not only is the control panel in Slovak, not only every window’s system menu has additional options in Slovak (so you get a mixed English/Slovak menu), the worst thing is that their translation is really awfull — perhaps as awful as my English :)
Localisation is nice, but if you don’t do it properly, don’t do it at all.
Have you ever wondered why a lot of Microsoft products have directories called ‘1003’? The wonderful blog, The Old New Thing, has the answer….
PingBack from http://www.martingordon.org/blog/2007/01/23/the-more-you-know-microsoft-and-1033/
一直搞不清楚MS诸多产品中，如Offices/VisualStudio/…，安装目录下为什么总有个名为1033或者2052目录，黑早的时候以为是版本号——那也太猛了吧，进化这么快？
…
PingBack from http://riteshhowto.wordpress.com/2008/09/19/what-is-1033/