Add locale.exe option for querying Windows UI languages

Andy Koppe andy.koppe@gmail.com
Sun Oct 9 10:31:00 GMT 2011


On 8 October 2011 16:03, Corinna Vinschen wrote:
>
> 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.
>>
>>       * locale.cc: 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?

Makes sense.

> 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.

How about having one option for each of the Windows settings, and
dividing the help output into groups, like so:

POSIX locale options:
  -a, --all-locales    List all available supported locales
  -c, --category-name  List information about given category NAME
  -k, --keyword-name   Print information about given keyword NAME
  -m, --charmaps       List all available character maps

Windows locale options:
  -u, --user-lang      Print user default UI language
  -s, --system-lang    Print system default UI language
  -f, --format         Print user format setting for times, numbers & currency
  -n, --non-unicode    Print system locale for non-Unicode programs
  -U, --utf            Attach ".UTF-8" to the result

Other options:
  -v, --verbose        More verbose output
  -h, --help           This text


>> 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.

Not sure about that, but it's not really worth discussing unless we do
decide to follow the Windows setting(s) by default.

Andy



More information about the Cygwin-patches mailing list