On Sun, Jan 18, 2026 at 11:26:39AM +0000, Gavin Smith wrote: > On Sun, Jan 18, 2026 at 12:11:11PM +0100, Bruno Haible wrote: > > Patrice Dumas wrote: > > > > On Debian 13 GNU/Hurd x86_64 I see 4 test failures: > > > > > > > > FAIL: test_scripts/formatting_documentlanguage_cmdline.sh > > > > FAIL: test_scripts/layout_formatting_fr.sh > > > > FAIL: test_scripts/layout_formatting_fr_info.sh > > > > FAIL: test_scripts/layout_formatting_fr_icons.sh > > > > > > I setup a VM and could not reproduce these failures. One possible issue > > > could be that there are no locales at all in your host, maybe? > > > > Oh, indeed: In my VM, there is no French locale. > > > > $ locale -a > > C > > C.utf8 > > POSIX > > > > I guess the desired outcome in this situation is that the 4 tests get > > SKIPed, not FAIL ? > > > > Bruno > > In a way, they are valid failures, as it shows that translation of document > strings won't work.
> texi2any needs a locale other than C, C.UTF-8 or POSIX to translate document > strings when outputting in languages other than English. (It does not have > be a French locale to translate to French - any locale, like en_US.UTF-8, > would do.) The reason why the translations do not work can be linked to a set of conditions that could be considered as somewhat independent of document output strings translations, as these are about translated error messages. And also are somewhat outside of Texinfo perimeter, as they may correspond to other software messages. If locales are missing because one do not want to have translated error messages, it is unclear to me that not having translated strings in output document is actually a failure. We have this implementation constraint that link those two subjects together, but then it could make sense to accept not to have translations in output documents if it means having to install translations for error messages. It could also be possible to consider that translated output strings are not needed, if none of the manuals use @documentlanguages. In that case, translations of document strings may not work while the conversion is as expected. In most cases, however, having no other locales than POSIX/C could be an oversight/unfinished installation. Also the failure could be unrelated to the will to install locales translated messages, in that case we would want to catch that failure. All in all I remain unsure on this subject, as I said before about the warnings output if no locale is found for the switch. That being said, I doubt that we can detect easily if we are in a situation where there are no locales that we can use. A possible workaround, that I do not like much, would be to add a configure switch to skip all the tests that require some output string translations. But I do not like the idea of configure switches for tests only. We could also consider documenting this somewhere if we do not already, although this also could be considered as an implementation detail. -- Pat
