> From: lrn1...@gmail.com
> 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)
retval = gl_locale_name_posix (category, categoryname);
if (retval != NULL)
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
> 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.
> I'm currently thinking what to do about this. Maybe GetThreadUILanguage()
That function is available only since Vista, so IMO it cannot be used
unconditionally, and some fallback should be available when it isn't.
> OTOH, date, time, number, currency formats and days-of-the-week names
> should probably continue to be obtained from intl.cpl (directly or
> i'm not sure whether C runtime functions do that, but there are W32 APIs for
> that, such as GetLocaleInfo(), and i remember seeing them being used in a
> nl_langinfo() implementation back in the day; gnulib uses strftime() for
> and it seems to be working, so that could be expanded too, i guess).
Programs that mix CRT functions, such as setlocale, and Win32 APIs,
such as GetLocaleInfo and GetThreadLocale, are IME asking for trouble,
and people who do that should know very well what they are doing,
because such mixtures have various subtle issues.
On balance, I think using setlocale whenever possible is a good way of
getting Posix-like behavior that programs supported by Gnulib expect.
It isn't perfect, because using other APIs it might be possible to
provide some enhanced features, but OTOH using those APIs could lose
big time in other situations. So I think Gnulib is correct in using
setlocale whenever possible, and only falling back on other APIs if
setlocale somehow fails.
It's possible that you bumped into some specialized situation where
this defaults is somehow inappropriate, which is why I would ask you
to kindly describe your use case in more detail.