[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Default Windows locale for localename.c
From: |
lrn1986 |
Subject: |
Re: Default Windows locale for localename.c |
Date: |
Mon, 12 Mar 2018 23:23:21 +0300 |
User-agent: |
Mozilla/5.0 (Windows NT 10.0; WOW64; rv:59.0) Gecko/20100101 Thunderbird/59.0 |
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
- Default Windows locale for localename.c, lrn1986, 2018/03/08
- Re: Default Windows locale for localename.c, Eli Zaretskii, 2018/03/12
- Re: Default Windows locale for localename.c,
lrn1986 <=
- Re: Default Windows locale for localename.c, Eli Zaretskii, 2018/03/12
- Re: Default Windows locale for localename.c, lrn1986, 2018/03/13
- Re: Default Windows locale for localename.c, Eli Zaretskii, 2018/03/13
- Re: Default Windows locale for localename.c, lrn1986, 2018/03/13
- Re: Default Windows locale for localename.c, Eli Zaretskii, 2018/03/15
- Re: Default Windows locale for localename.c, lrn1986, 2018/03/15
- Re: Default Windows locale for localename.c, Eli Zaretskii, 2018/03/15
- Re: Default Windows locale for localename.c, lrn1986, 2018/03/15
- Re: Default Windows locale for localename.c, lrn1986, 2018/03/13
- Re: Default Windows locale for localename.c, Eli Zaretskii, 2018/03/15