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