What happened to the Windows 2000 "Set default language setting for the system" button?


Last time, we looked at the evolution of the control panel settings which control the language groups for which Windows will install fonts, code page information, and other support collateral. This was in the context of a customer who was trying to migrate from Windows 2000 to Windows XP, and the customer wanted to convert their workflow to the new operating system.

They made the appropriate changes, and... the problem was not fixed.

At this point, the customer liaison decided to tell us what the actual problem was. (I don't know whether the information was originally withheld by the customer or the customer liaison, so I intentionally phrased the situation vaguely.)

The customer's original workflow involved installing Bulgarian language support, and from your explanation it appears that Bulgarian language support is installed by default on Windows XP. But we still have the problem where if they run one of their internal programs, the text comes out incorrectly unless they also set the Language for non-Unicode programs to Bulgarian.

It took two days before the penny dropped and I figured out what the customer's actual problem was and what they were trying to do.

Even though the customer's original question was asking what happened to "selecting multiple languages from the Language settings for the system" section of the control panel, their actual question is "What happened to the Set default... button that appears below the list box?"

The Set default... button moved to the Languages for non-Unicode programs section of the control panel.

Selecting Bulgarian from the dropdown is equivalent to clicking the old Set default... button and picking Bulgarian.

Back in 2000, some wiseguy named Michael Kaplan walked through the old Windows 2000 control panel and explained what each piece means.

The customer liaison reported back that they could get their program to behave the way they wanted, but for only one language at a time. Reportedly, under Windows 2000, once they added support for Bulgarian and Slovak, they could use the program in both Bulgarian and Slovak mode. But in Windows XP, they have to pick one or the other. If they pick Bulgarian, then the Slovak mode comes out garbage, and vice versa.

The customer's application is Web-based, so the problem may be in the way the program performed language negotiation with the server. But the customer hasn't done any actual debugging; they're just running around fiddling knobs hoping that one of them will magically solve the problem.

What the customer really needs to do is start debugging: For example, they can capture a network trace of the communication between the client and the server on a Windows 2000 machine, and compare it to the trace they get on a Windows XP machine. If there are differences, that may guide the next level of investigation. (And if there aren't any differences, then the problem is strictly on the client.)

Comments (3)
  1. cheong00 says:

    Emmm… Web. Maybe the customer liaison should redirect the request to the IE team to make more sense.

    Strange… I remember there was already plenty of online resources on creating i18n enabled website at the time around IE5.

  2. So in Windows 2000 IE used Regional options for determinating Accept-Language http header? Now it's in "Internet Options"-Common-Languages.

  3. cheong00 says:

    @Macrosofter: The web application may/may not process Accept-Language header. In fact, most websites at that time haven't migrated to Unicode yet, so very few website would add code to process it (except at initial visit if the website have multiple version)

    I think their trouble is on missing "Content-Type HTTP header" or "Content-Type meta tag". Since IE5/6 have to support system that have no Unicode support, I think they use their own routine to draw strings for displaying web pages on codepage not supported on the system. As long as any of these two were set, even if an unsupported language is needed to be shown, IE would have prompt the user to download required language addons.

    When these header/tag were missing, IE would just use the default language to display it.

    This is the information that I think the customer needed.

Comments are closed.

Skip to main content