Then of course there is a crucial note that hints at some more underlying complexity:

Note: This function is also used by the operating system to identify languages that are safe to use on the Windows console.

Then if you look at the info on the flags parameter you have MUI_COMPLEX_SCRIPT_FILTER and MUI_CONSOLE_FILTER and MUI_RESET_FILTERS and if you pass any of them you have to pass NULL for the parameters where you would set the list.

And if you look in the notes it talks about the various interactions that go on here with the various combinations of things.

There's a lot going on here in what is arguably an important setting. And a helluva lot of ways to call it.

Including a reset switch, apparently for if you have confused something in previous calls? :-)

Many people will make mistakes here, something I know indirectly because of the number of times that people ask me about how they should be calling it, often after having something not behave the way they expected it would.

Okay, off the soapbox, let's get back to Brian's question.

The simplest answer is NO and the reason is because that is what Windows does but that isn't very satisfying, is it?

A fuller answer (I've known Brian for years now, enough that I feel self conscious about the fact that he asked the question a month ago and I didn't notice that fact until yesterday and therefore a better answer than BECAUSE I'M THE MOMMY is indicated for a whole host of reasons.

Now if they do keep in mind that the rules for what a "safe" console language massively changes and SetThreadPreferredUILanguages with MUI_CONSOLE_FILTER doesn't really keep track of it as entirely effectively as one might wish, according to several who have tried it out after reading that blog. Though their language may be a bit less polite of course!

But that is not why Windows does not automatically call SetThreadPreferredUILanguages(MUI_CONSOLE_FILTER, NULL, NULL).

The reason Windows does not automatically call SetThreadPreferredUILanguages(MUI_CONSOLE_FILTER, NULL, NULL) is that not all console applications restrict the work they do to what they show in the console window! Some of them create huge log files, some of them send messages to other parts of the system or set registry keys, and so on. All operations that write data to places that can accept date in Thai or Telugu or Tamil or Tibetan or even languages that don't start with T that don't work so well in the console UI.

Automatically changing the behavior out from under all console applications would break any number of people who have been working under the rules that have existed for years.

Including the one group most interested in things not changing their behavior -- the sysadmins who live in the console with their hundreds or even thousands of scripts that run console applications....

In their view, changing behavior is the professional equivalent of killing puppies, really cute puppies. And there is no upside for that....

Perhaps my question does not directly relate to the blog post (if so then I apologize).

I wanted to understand in brief, the significance of calling functions like SetThreadUILanguage and SetThreadPreferredUILanguages in an application. Will calling these functions cause the "OK" and "CANCEL" captions on the MessageBox function to automatically show in the set language? Are these functions mainly for Windows UI captions to display in the language set on the thread?