Add locale.exe option for querying Windows UI languages

Corinna Vinschen
Sat Oct 8 15:04:00 GMT 2011

Hi Andy,

On Oct  8 10:24, Andy Koppe wrote:
> The attached patch adds a --interface/-i option to locale.exe that
> makes the --system/-s and --user/-u options print the respective
> default UI language instead of the default locale.
> 	* Add --interface option for printing Windows default UI
> 	languages.
> For background, here's what Windows' various default locales and languages do:
> - LOCALE_USER_DEFAULT: This reflects the setting on the Formats tab of
> the (Windows 7) Region&Language control panel, which affects the
> format of times, dates, numbers, and currency.
> - LOCALE_SYSTEM_DEFAULT: This reflects the "Language for non-Unicode
> programs" on the Adminstrative tab of Region&Language control panel,
> which also determines the ANSI and OEM codepages.
> - GetUserDefaultUILanguage(): This is the current user's Windows UI
> language, also called display language. On Windows installs with
> multiple UI languages, a setting for this appears on the "Keyboards
> and Languages" tab of the Region&Language control panel.
> - GetSystemDefaultUILanguage(): The is the system-wide UI language
> used for things that aren't user-specific, e.g. the login screen. As
> far as I know it's determined at Windows install time and can''t be
> changed.

I like the idea of the patch, but I'm wondering if this is the right
approach.  I wasn't aware of the difference between the LOCALE_FOO_DEFAULT
values and what the GetFooDefaultUILanguage functions return, otherwise
I would have probably used the GetFooDefaultUILanguage functions right from
the start.

What I mean is this.  The locale -u/-s functionality was supposed to be
used to set the $LANG value preferredly.  Since LANG means language in
the first place, the UI language is a much more natural choice for the
default -s/-u functionality, isn't it?

Therefore, afaics, it would be better if we change locale to use the
GetFooDefaultUILanguage functions by default, and we add a modifier
(-r/--region?) to switch to LOCALE_FOO_DEFAULT.

Either way, the usage output will have to be improved.  Maybe we should
explicitely state that the values printed refer to the Windows values,
and that one of them is the UI locale and the other is the... hmm...
how to say it..., maybe the "region settings locale" or so.

> Looking at those, and if we wanted to base the Cygwin locale settings
> on the Windows ones, I think LC_NUMERIC, LC_TIME, and LC_MONETARY
> should be determined by LOCALE_USER_DEFAULT, but LC_MESSAGES should be
> determined by GetUserDefaultUILanguage(). Not sure about LC_CTYPE and
> LC_COLLATE, but I suppose it would make sense for character
> classification and sorting to match the UI language.

The system should not set the LC_xxx values at all.  From my POV the
system should only default to some $LANG, while setting the LC_xxx
values is the job of the user if the $LANG value doesn't suffice.
However, if the user wants to do that, we will have the new flag.


Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

More information about the Cygwin-patches mailing list