Eli Zaretskii wrote:
> > as explained in [1].
>
> So the problem is that, unless the locale is pushed into the
> environment, libintl cannot be sure to know about the modified locale?
Unless the locale name is pushed into the environment, libintl cannot
do its job properly.
> If so, I understand why setenv must be used to push the locale into
> the environment when the program uses libintl. But I still don't
> understand why after doing so, programs must call
> setlocale (LC_ALL, "") and not setlocale (LC_ALL, the-new-locale) --
> shouldn't that be equivalent?
Both should be equivalent, yes.
The GNU gettext manual [2] suggests to use setlocale (LC_ALL, "")
for two reasons:
1) Most programs should take their locale from the environment.
Hardly any program should invoke setenv ("LC_ALL", some_locale, 1);
maybe 'makeinfo' is one of the few programs that needs this.
2) If we suggested to use
setenv ("LC_ALL", some_locale, 1);
setlocale (LC_ALL, some_locale);
the question would immediately come up "what if these two some_locale
arguments are not the same?" But we don't want complicated narratives
at this point.
> And since the Windows setlocale ignores
> the environment, the latter is actually preferable (at least on
> Windows)?
At most in Emacs on Windows, because Emacs on Windows does things specially.
In all other packages, the <libintl.h> file that is needed for invoking
bindtextdomain and textdomain also includes a setlocale() override that
solves the issue, similar to what Gnulib does [3].
Bruno
[2] https://www.gnu.org/software/gettext/manual/html_node/Triggering.html
[3] https://www.gnu.org/software/gnulib/manual/html_node/setlocale.html
