Re: Use LC_MESSAGES instead of LANGUAGE for translations?

[Gavin Smith]

On Sat, Dec 21, 2024 at 08:31:35PM +0100, Patrice Dumas wrote:
> > Then the call to switch_messages_locale is not actually needed as 
> > LC_MESSAGES
> > is set.  This means we don't have to go looking for a working LC_ALL
> > setting.
> > 
> > Any thoughts if we should adopt this approach for Alpine Linux and musl
> > and even by default?
> 
> If the documentlanguage is fr_FR, we set LANGUAGE=fr_FR:fr.  I guess
> that this would not work with LC_MESSAGES.  We could use LC_MESSAGES
> on musl but still use LANGUAGE on other platforms for that feature?

This would be an issue for Portuguese which has translations in both
pt_BR and pt:

https://translationproject.org/domain/texinfo_document.html

There isn't an easy check for musl (by design AFAIK).

Setting LC_MESSAGES may be enough for musl, and could be simpler if it
works, but with further testing I found it wasn't enough on glibc/Linux,
if a locale of the given name wasn't installed.  For example, as I
have "de_DE.UTF-8" installed,

  setenv ("LC_MESSAGES", "de_DE.UTF-8", 1);

would give the correct translation, but

  setenv ("LC_MESSAGES", "de", 1);

wouldn't.  So on these systems (possibly everything but musl), LANGUAGE
appears to be the only way to access arbitrary *.mo files.

I also found this post from 2017:

https://www.openwall.com/lists/musl/2017/11/08/2

  One notable issue is that, right now, we rely on being able to set
  LC_MESSAGES to an arbitrary name even if there's no libc locale
  definition for it; this is because gettext() relies on the name of the
  current LC_MESSAGES locale to find (application-specific) translation
  files that might exist even without a libc translation. I'm not sure
  how we would best keep this working under changes similar to the
  above.

(Again, I don't know if they ever made the change they were discussing.)

I'm inclined just to mention the --enable-xs-perl-libintl workaround
in the INSTALL file at this stage.  As I remember you saying in another
message, it is not particularly easy to run a configure test to test for
gettext functionality as it requires reliable access to a translation
file.