Re: Default Windows locale for localename.c

[lrn1986]

On 12.03.2018 20:20, Eli Zaretskii wrote:

From: lrn
Date: Fri, 9 Mar 2018 01:51:44 +0300

Currently localename.c (which is used by gettext, so it's really everywhere)
calls GetThreadLocale() to get current locale identifier (if LC_* or LANG are
not set).

That's not entirely accurate, at least not wrt the version in the
Gnulib Git repository.  There we have this:

   const char *
   gl_locale_name (int category, const char *categoryname)
   {
     const char *retval;

     retval = gl_locale_name_thread (category, categoryname);
     if (retval != NULL)
       return retval;

     retval = gl_locale_name_posix (category, categoryname);
     if (retval != NULL)
       return retval;

     return gl_locale_name_default ();
   }

GetThreadLocale is called from gl_locale_name_default, which is the
last resort.  Before that, the function calls gl_locale_name_thread,
which on MS-Windows calls setlocale, as you wanted.

So I'm not sure what problem did you have and why.  Or maybe I'm
missing something.

I've re-traced this, here's how it works:


at gettext-0.19.7/gettext-tools/../gettext-runtime/intl/dcigettext.c:667

guess_category_value (categoryname=0x61ed714d "LC_MESSAGES", category=1729)
at gettext-0.19.7/gettext-tools/../gettext-runtime/intl/dcigettext.c:1561

_nl_locale_name_posix (category=1729, categoryname=0x61ed714d "LC_MESSAGES")
at gettext-0.19.7/gettext-tools/../gettext-runtime/intl/localename.c:2815

_nl_locale_name_environ (category=1729, categoryname=0x61ed714d "LC_MESSAGES")
at gettext-0.19.7/gettext-tools/../gettext-runtime/intl/localename.c:2819



_nl_locale_name_default ()
at gettext-0.19.7/gettext-tools/../gettext-runtime/intl/localename.c:2941

libintl_dcigettext (domainname=0x45e3718 "gedit", domainname@entry=0x0, msgid1=msgid1@entry=0x6887f8af <__FUNCTION__.74302+47> "", msgid2=msgid2@entry=0x0, plural=plural@entry=0, n=n@entry=0, category=category@entry=1729) does a number of getenv() calls, all fail, so it returns NULL, so back to guess_category_value() which in the source code is called gl_locale_name_default() (so i guess this is gnulib name mangling in action? Come to think of it, all other "_nl" function above also have "gl" prefix in the source code), which just calls GetThreadLocale () immediately.

Because of this gettext-using programs tend to pick the wrong default locale
when running on Windows.

Could you please describe the situation where this happens in detail?
And what exactly do you mean by "the wrong default locale", given that
a locale could be used for different purposes, and on Windows, as you
correctly point out, there are several "kinds" of default locales.

My Windows installation is in English (i.e. this is the language of the installer and the UI language for all applications and system software), but i have Russian regional settings (time, date, weekday names, currency, number formatting). Because of this any program using gettext is in Russian, unless i deliberately set LANG or LC_*. Note that the "Language for non-Unicode programs" setting (also in intl.cpl) does not affect the value that GetThreadLocale() returns. The only thing that matters is what you select in the "Format:" dropdown list at the "Fromats" tab. Even if you go ahead and rearrange all specific formats to something completely different afterwardы, the item selected in that list will define the value that GetThreadLocale() returns.

I'm currently thinking what to do about this. Maybe GetThreadUILanguage()
instead?

That function is available only since Vista, so IMO it cannot be used
unconditionally, and some fallback should be available when it isn't.

Well, that was just a shot in the dark. First i'll need to verify that the function(s) in question actually return(s) the right things (which means running test programs on different Windows versions with different UI languages (with or without using MUI) and regional settings).

signature.asc
Description: OpenPGP digital signature