Re: localename: Fix gettext test failures on mingw

[Eli Zaretskii]

> From: Bruno Haible <address@hidden>
> Cc: address@hidden
> Date: Sat, 24 Nov 2018 21:32:58 +0100
> 
> > We could have gettext work without LC_MESSAGES, by using native
> > Windows calls instead, couldn't we?
> 
> That was the way it was done before Gnulib. Remember how, up to ca. 2001,
> porting a program to run on DOS or Windows meant to add #ifs all over the
> place?
> 
> Then Gnulib came along, with Paul's idea to implement POSIX API emulation
> on non-POSIX systems. The result is successful:
>   - Porting a program to run on native Windows nowadays means that 70%
>     of the work is done by selecting a set of gnulib modules and adding
>     a gnulib-tool invocation to the package's build system.
>   - Many packages have been ported this way, with comparatively little
>     #ifs.

I'm saying that LC_MESSAGES are in the 30% that cannot be fixed like
that, because the results are not better, and sometimes worse than
leaving LC_MESSAGES undefined on MS-Windows.  See below for one
example.

> > But LC_MESSAGES has additional impacts on systems that support it,
> > beyond message catalogs and gettext, doesn't it?
> 
> While any application _can_ use LC_MESSAGES for any purposes it likes,
> I haven't seen any which uses for purposes other than
>   - messages
>   - strings that appear in UIs
>   - regular expressions that govern the validation of user input
>     (yesno, rpmatch),
> and all these are commonly implemented through message catalogs.

The problems I describe are not theoretical, I actually bumped into
them when porting Guile 2.0.x.  I can understand how the above could
be "good enough" for closed applications, but Guile isn't such an
application.  It defines symbols based on LC_MESSAGES and exposes them
to Scheme.  Once you've done that, the genie is out of the bottle, and
you have no control whatsoever on where and how it will be used.

There were also other issues.  One of them, AFAIR, was that
LC_MESSAGES was defined to a large arbitrary value, but LC_MAX was not
updated to cover that, which can also bite one further down the line.

> > If such calls are possible (e.g., for those who are not ardent enough
> > in reading the documentation), perhaps they should be caught by Gnulib
> > and flagged as errors, if they aren't already?
> 
> Such calls, e.g. setlocale(LC_ALL, "de_DE.UTF-8") on native Windows,
> are possible but fail, i.e. produce the return value NULL.

Yes, and so this locale "translation" is useless at best, because it
causes serious problems in the i18n area.  In particular, you cannot
pass any locale definition with UTF-8 as the codeset to the Windows
setlocale, it will always fail.

> A compile-time error or warning is not possible. So what else would you
> expect or suggest?

I don't know.  Abort, perhaps?  Anything is better than having a
dysfunctional program that silently does nothing.

> > > Programs that call 'setlocale' and want to consider locale names given
> > > by environment variables usually do so by calling
> > >    setlocale (LC_something, "");
> > 
> > Which doesn't work as expected with Windows' 'setlocale', of course.
> 
> Which is precisely why the setlocale function that Gnulib provides to
> applications has code to support this. (See gnulib/lib/setlocale.c
> lines 832..1005.)

This support can never be complete enough, unless you completely
replace setlocale in the Windows runtime.

All in all, I find this area as unfixable by Gnulib methods, because
the result is full of subtle issues, and I'm not sure it improves the
situation.  I understand that it lets package maintainers relax and
think they have MinGW covered, but MinGW users get subtly broken
programs, and fixing them IME involves undoing the LC_MESSAGES
emulation and the Posix locale names, because using them doesn't allow
to support on Windows the same or equivalent features as on Posix
platforms.

I understand that you disagree (not the first time, and probably not
the last), but I think it's important to share my experience here,
which led me to believe that this are cannot be fixed well enough, and
therefore should not be fixed by Gnulib.  Instead, applications that
need these facilities should adapt according to their needs by using
the Windows native facilities.