bug-gettext
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug-gettext] LC_MESSAGES default locale for Windows


From: LRN
Subject: [bug-gettext] LC_MESSAGES default locale for Windows
Date: Thu, 29 Mar 2018 00:38:09 +0300
User-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:59.0) Gecko/20100101 Thunderbird/59.0

There's a problem, i think, with the way gettext determines default locale for
LC_MESSAGES. Because setlocale() implementation that gettext uses comes from
gnulib, i've contacted[0] gnulib devs. Sadly, they have not been very receptive.

The crux of the matter is that with LC_* and LANG environment variables being
unset gnulib guesses locale name for LC_MESSAGES from the output of
GetThreadLocale(). For all other LC_* categories it uses the result of 
setlocale().

GetThreadLocale() usually returns the generic catch-all locale setting that the
user set up in the OS configuration (Control Panel -> Clock, Language, and
Region -> Region). That configuration applet has more specific settings that
correspond to some LC_* values, but GetThreadLocale() returns only based on the
item selected in the "Format:" combobox.

The problem here is that on Windows this locale setting affects everything
*except* LC_MESSAGES, because Windows has no concept of LC_MESSAGES in its C
runtime. Conceptually, LC_MESSAGES describes "the language used in the user
interface for message translation"[1]. Windows has a separate setting for
changing UI language (Control Panel -> Clock, Language, and Region -> Language).
It's slightly more difficult to change than the Region Format, as it requires
admin privileges to download localization data, and requires the user to log
out for the changes to take effect, but in the end it changes the UI language
for all system software (both GUI and commandline).

Usually Region Format and UI Language are the same, but some people (me
included) prefer to set them up differently. For example, i have UI language
set to English (US) (since i know it well enough, and it's more convenient for
all IT work to have UI in English), but Region (and, therefore, all other
locale settings) set to Russian (RU) (since that matches my physical location
and the time & date format used locally).

In the end the current reliance on GetThreadLocale() makes all free software
applications that i have to, by default, run with Russian UI, which does not
match the language of the UI on the rest of my system.

My proposition was to use GetUserDefaultUILanguage() to get the UI language
identifier, specifically for LC_MESSAGES. I've also attached a patch[2],
though, after thinking a bit on it, i suppose that it isn't very
well-implemented (it might have been better to make LC_MESSAGES a special case,
not the other way around). Still, i thought it would make for a good
conversation starter - except that it actually had the opposite effect and
ended the conversation.

The fact that glib doesn't call gl_locale_name(), but invokes
_nl_locale_name_thread_unsafe(), _nl_locale_name_posix() and
_nl_locale_name_default () manually should also be factored into the solution.

[0]: https://lists.gnu.org/archive/html/bug-gnulib/2018-03/msg00024.html
[1]:
https://www.gnu.org/software/libc/manual/html_node/Locale-Categories.html#Locale-Categories
[2]: https://lists.gnu.org/archive/html/bug-gnulib/2018-03/txtJLdP531yht.txt

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]