Patrice Dumas wrote on 2026-01-13:
> in Texinfo, we do not really care
> about the handling of locales in OpenBSD much, as we use the
> libintl-perl Perl module as Gavin explained. So it is not an issue if
> the messages are untranslated in the OpenBSD C library/libintl, as we do
> not use it, but, again as reported by Gavin, we need to have a call,
> with $category = LC_MESSAGES that returns something else than 'C' or
> 'POSIX' in the libintl-perl gettext_pp.pm __load_domain function:
>
> $locale = POSIX::setlocale ($category);
>
> With POSIX::setlocale being (I have not checked the code, but I am
> pretty sure about it) a wrapper around the platform C library setlocale
> function.
Gavin Smith wrote on 2026-01-24:
> There is a trick that appears to work:
>
> diff --git a/tta/perl/Texinfo/Translations.pm
> b/tta/perl/Texinfo/Translations.pm
> index 65808a7e86..f6c9cd5a78 100644
> --- a/tta/perl/Texinfo/Translations.pm
> +++ b/tta/perl/Texinfo/Translations.pm
> @@ -33,6 +33,10 @@ use strict;
> use Encode;
> use POSIX qw(setlocale LC_ALL LC_MESSAGES);
> use Carp qw(cluck confess);
> +
> +sub fake_setlocale { return "en_US.UTF-8"; }
> +BEGIN {*POSIX::setlocale = \&fake_setlocale; }
> +
> use Locale::Messages;
>
> use Storable qw(dclone);
>
> If we override the "setlocale" locale in the POSIX:: namespace before
> the Locale::Messages module is loaded, then all of the calls will go
> to our overload instead.
>
> With this, translations do occur in the output.
Hmm, that sounds like an integration problem with the 'libintl-perl' package.
However, there is an integration test of 'libintl-perl' within GNU gettext
(test case gettext-tools/tests/lang-perl-2). Do you see this unit test
fail on OpenBSD, when you build gettext 1.0? (Probably I have only ever
tested it on GNU/Linux systems...)
Bruno
