Re: [bug-gettext] [patch] LC_MESSAGES default locale for Windows

[LRN]

On 29.03.2018 0:38, LRN wrote:
> 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.
> 
> [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
> 

Reading gnulib source code a bit closer i've see that it name-drops gettext,
i.e. its implementation mirrors gettext in a lot of ways. Therefore i think it
would be more appropriate to start here, and then come back to gnulib devs
about this.

So here's an updated version of the patch. I've separated the part that applies
to libintl from the part that applies to gnulib, for easier reading. Also, this
patch is cleaner (turns gl_locale_name_default() into a special case of
gl_locale_name_default_for_category() instead of the other way around), which
also makes it easier to read. I've also reduced the scope to only affect
LC_MESSAGES categories. It might result in somewhat weird cases where strings
are sorted and/or upper/lower-cased in unexpected ways, because LC_CTYPE or
LC_COLLATE do not match LC_MESSAGES, but at least it would be consistent
(MSVCRT setlocale() does know about LC_COLLATE and LC_CTYPE, and now we do not
override it).

I've also helpfully changed the subject to include the word "patch", to
indicate that there is indeed a patch here. Hope that helps.

Note that the base gnulib and gettext patches normally would have the same file
name, since they have the same commit message. I've renamed them for clarity.

How to test:
0) Run intl.cpl, set Format to a language that does not match the ui of
intl.cpl itself (i.e. if it says "Format", then choose non-English language)

1) Build patched gettext
2) Build unpatched gettext
3) Run an environment where correct PATH is set, but LANG (or any other
variable used by gettext) is unset

4) Install unpatched gettext
5) Run any program that uses gettext for localization (and has localization
files for both the system UI language and the language chosen in (0))
6) Observe that it uses the language chosen in (0)

7) Install patched gettext
8) Run any program that uses gettext for localization (and has localization
files for both the system UI language and the language chosen in (0))
9) Observe that it uses the system UI language

0001-gettext-Use-GetUserDefaultUILanguage-instead-of-GetThreadLoc.patch
Description: Text document

0001-gnulib-Use-GetUserDefaultUILanguage-instead-of-GetThreadLoc.patch
Description: Text document

0002-Use-gl_locale_name_default_for_category-in-tests.patch
Description: Text document

signature.asc
Description: OpenPGP digital signature