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:

libintl_dcigettext (domainname=0x45e3718 "gedit", address@hidden, 
address@hidden <__FUNCTION__.74302+47> "", 
address@hidden, address@hidden, address@hidden, 
address@hidden)
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

does a number of getenv() calls, all fail, so it returns NULL, so back to 
guess_category_value()

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

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