On 12.03.2018 23:50, Eli Zaretskii wrote:
From: LRN
Date: Mon, 12 Mar 2018 23:23:21 +0300

    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", domainname@entry=0x0,
msgid1=msgid1@entry=0x6887f8af <__FUNCTION__.74302+47> "",
msgid2=msgid2@entry=0x0, plural=plural@entry=0, n=n@entry=0,
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

This shows that guess_category_value calls gl_locale_name_posix
directly, instead of calling gl_locale_name.  So the question now
becomes why does gettext do that, and whether it should do something
different at least on MS-Windows.

Try git blame? I don't have a git clone of gettext at hand.

Also note that LC_MESSAGES is not supported by the Windows setlocale,
so either gettext should use some other category, or it will have to
invent stuff out of thin air, something I don't recommend.

Don't know about gettext (i'm not an active participant there), but glib has #ifdefs for this, and a special function to call to get message locale on W32, instead of passing LC_MESSAGES to setlocale(). A side-note: that special function also calls GetThreadLocale(), so i clearly have my work cut out for me...

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_*.

Which in general sounds quite reasonable to me, btw, given the
description of your setup.

Well, on one hand, i agree that it's a setting that a user can change easily enough (no extra data needed, no admin privileges, no need to re-login), and it is kind of related to user locale.

On the other hand, this clashes with the actual language used by the OS. I mean, *everything* (text in all GUI and commandline programs that come with the OS) is in English. That can be changed by downloading a language pack (formerly known as a MUI pack), installing it, and then switching the language (control panel -> language -> Options (for a language in the list; add one if it isn't in the list) -> Override display language. This is the MS-blessed language-changing procedure, and this is how you are supposed to change the system UI language after installation (the OS has a pre-set language used during the installation; it's also the language used by the OS if it's pre-installed on your PC).

The Formats language setting is more about *where you are*: how dates are written here, which decimal separator is used, what's the local currency, how the time is displayed, what are the names of the days of the week - even if you know multiple languages, it's easier to have these set in a way that matches the things used at your location.
UI language is the W32 equivalent of LC_MESSAGES, i guess.

It seems that proprietary programs follows the UI language setting, not the formats locale (that said, i'm not the best person to ask, since i don't really have much to do with proprietary apps). MSDN [1] explains the multiple language situation in Vista+ (which is what we should aim to use; XP can just keep using GetThreadLocale() for all i care; that said, GetUserDefaultUILanguage() is claimed to be 2000+, so we could use that) and that GetUserDefaultUILanguage()/GetUserPreferredUILanguages() return the UI language(s) for the user.

MSDN [1] also lists per-process and per-thread language functions, but these either default to empty return string or explicitly fall back to more generic User/System/Install language.

And what does setlocale(LC_ALL,NULL) return on that system?

It returns "C".


Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to