On Thu, Jan 15, 2026 at 03:55:53AM +0100, [email protected] wrote: > On Mon, Jan 12, 2026 at 10:05:58PM +0000, Gavin Smith wrote: > > On Mon, Jan 12, 2026 at 10:26:54PM +0100, [email protected] wrote: > > > On Mon, Jan 12, 2026 at 06:21:55PM +0000, Gavin Smith wrote: > > > > > > > > I don't understand the reasons but the conclusion seems to be that we > > > > have to use this round-about way of setting the locale, which we've > > > > come to after some amount of trial and error. > > > > > > I tested something similar in Perl on OpenBSD 7.8, and it does not work. > > > With LC_MESSAGES it did not work at all, with LC_CTYPE the switch to the > > > locale happens, but there is no translation. Here is the code I tested > > > (at the beginning of _switch_messages_locale: > > > > Would it be possible to check the value of POSIX::setlocale(LC_MESSAGES) > > on OpenBSD and find if there is any way to set this to a different value? > > > > The "set and retrieved" part of that implies that this should be possible. > > I have tried setting environment variables LC_ALL and also calling > POSIX::setlocale (LC_ALL, ""), as well as other mossibilities, setting > LC_CTYPE, calling POSIX::setlocale (LC_ALL, "en_US.utf8") but a > POSIX::setlocale(LC_MESSAGES) call (as in libintl-perl) always returns > C. > > I do not see any way to have it work. It actually means that > libintl-perl cannot do anything on OpenBsed 7.8, unless I missed > something. Maybe I could report that to the libintl-perl maintainer and > see what he thinks?
I couldn't make it work either. I don't know what is going on with the POSIX::setlocale function in Perl. I tried running a test program in Perl with the "ktrace" program and a setlocale function didn't appear to be called. According to the Perl documentation, setlocale may not be called: Starting in Perl 5.28, on multi-threaded perls compiled on systems that implement POSIX 2008 thread-safe locale operations, this function doesn't actually call the system setlocale. Instead those thread-safe operations are used to emulate the setlocale function, but in a thread-safe manner. https://perldoc.perl.org/perllocale#The-setlocale-function Elsewhere on that page, it says that "thread-safe locale operations" can be detected by checking a variable: You can tell if using locales is safe on your system by looking at the read-only variable ${^SAFE_LOCALES}. The value is 1 if the perl is not threaded, or if it is using thread-safe locale operations. On the system I am checking this on (cfarm231), this variable indeed had the value 1. So it seems to be an issue with Perl. perl --version reports the version is 5.40.1. On the other hand, the corresponding function in C did behave as expected: #include <locale.h> #include <stdio.h> int main (void) { char *locale = setlocale (LC_MESSAGES, "en_US.UTF-8"); printf ("locale is %s\n", locale); } This prints "locale is en_US.UTF-8". I also tested older versions of Texinfo and at least this problem is not new in this release - it was a problem at least as early as the last release, 7.2, where we called POSIX::setlocale the same way.
