bug-texinfo
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Setting locale for document string translation with libintl-perl


From: Gavin Smith
Subject: Setting locale for document string translation with libintl-perl
Date: Sat, 28 Nov 2020 23:10:15 +0000
User-agent: Mutt/1.9.4 (2018-02-28)

I'm trying to upgrade the bundled libintl-perl to version 1.32 for
texi2any but am hitting a problem.  It's due to a fix for this bug:

https://rt.cpan.org/Public/Bug/Display.html?id=81315

The result is that after upgrading the library, there are test
failures due to untranslated strings.  The problem is that the
tests run under the C locale for consistent results but that
strings won't be translated if the locale is C.  LC_MESSAGES or
LC_ALL need to be set for the translation.

However, I'm not sure what to set LC_MESSAGES to, because the same
locales won't exist on all systems.  The following fixes the tests
(for example "perl -w t/languages.t simple"):

diff --git a/tp/Texinfo/Report.pm b/tp/Texinfo/Report.pm
index 19a207238..04185eeec 100644
--- a/tp/Texinfo/Report.pm
+++ b/tp/Texinfo/Report.pm
@@ -232,6 +232,8 @@ sub _encode_i18n_string($$)
   return Encode::decode($encoding, $string);
 }
 
+use POSIX qw(setlocale LC_MESSAGES);
+
 # Get document translation - handle translations of in-document strings.
 # Return a parsed Texinfo tree
 sub gdt($$;$$)
@@ -244,6 +246,7 @@ sub gdt($$;$$)
   my $saved_env_LC_ALL = $ENV{'LC_ALL'};
   my $saved_LANGUAGE = $ENV{'LANGUAGE'};
 
+  setlocale(LC_MESSAGES, 'en_GB.utf8');
   Locale::Messages::textdomain($strings_textdomain);
 
   # FIXME do that only once when encoding is seen (or at beginning)

but obviously this is not right because not everybody with have
the en_GB.utf8 locale.  Changing it to en_US.utf8 still works, although
I don't think I have that locale installed (it's not listed in the output of
"locale -a").  Other attempts like fr_FR.utf8 or en_XX.utf8 lead to failure.

Does anybody know what should be done?  Is there something special
about en_US.utf8 that would make this always work?  Patrice, do
you remember the details from when you originally reported the bug
linked above?



reply via email to

[Prev in Thread] Current Thread [Next in Thread]