On 2025-09-08 00:13, Bruno Haible wrote: > Paul Eggert wrote: >> I meant to not worry about platforms where the "C" (not "C.utf8") locale >> is multibyte. I don't know of how diffutils would misbehave in such >> locales (other than not be strictly POSIX-conforming in unusual cases >> where native tools aren't either), so I wanted Gnulib to not worry about >> the possibility. > > This possibility actually occurs on Android ≥ 5.0. Yes, and if it causes a real problem in diffutils we should fix that as it comes up. I don't offhand know why it'd be a real problem. > * hard_locale_LC_TIME assumes that no locale, not even the en_US locale, > uses the same internal format string for "%c" as the C locale. The assumption is a bit different: it's merely that only in the POSIX locale does "%c" produce that output for that particular date. Even if the other locale uses the same internal format string "%a %b %e %T %Y", in a non-English locale if it's quite likely they won't match POSIX's English-language abbreviations. I don't know of any platform where hard_locale_LC_TIME incorrectly returns false. However, even if it does, diffutils' behavior will still be OK: it'll conform to POSIX and users will surely understand the output. And if a user complains about this extremely minor glitch I assume we can fix that as it comes up. > - the translator will not translate "(C)" by "(C)", > - the user does not use LANGUAGE with a precedence list. Not quite following, but it's OK if in unusual cases the program outputs "(C)" when "©" would be better, so long as in ordinary cases "©" is output when it works, and so long as "©" is not output when it would display as gibberish. > * hard_locale_LC_MESSAGES assumes that > - diffutils.pot contains the strings from lib/version-etc.c > (which are now actually in gnulib.pot), Yes, that's a problem, and thanks for mentioning it. It stems from quite a comedy of errors: (a) diffutils' en translation is not installed. (b) cmp looks in the wrong catalog for the "(C)" message. (c) The gnulib.pot/gnulib.mo mechanism is not yet working widely even for packages other than diffutils. On current Fedora 42 if I run this shell command: LC_ALL=en_US.utf8 cat --version although I see "Torbjörn" in UTF-8 as desired, I also see "Copyright (C) 2025" which is wrong: it should be "Copyright © 2025". Worse, I see the exact same English message when I run this shell command: LC_ALL=fr_FR.utf8 cat --version This is because even though /usr/share/locale/fr/LC_MESSAGES/coreutils.mo is installed, there is no file /usr/share/locale/fr/LC_MESSAGES/gnulib.mo, and Fedora does not supply a gnulib.mo file in any package that I can see. I reported this newish bug to Fedora yesterday . (d) In response to that Fedora bug report, Lukáš Zaoral set in motion a fix. But he asked, "Since gnulib is meant to be bundled, how do you deal with the situation when the messages in the sources of the bundled gnulib and gnulib-i10n differ? Do you have some upstream policy to make sure that they don't diverge?" Do we have an answer for that? I'm not sure myself. (e) Even if Fedora started installing a gnulib.mo file, diffutils "make install" does not install such a file, so a standalone build of diffutils with './configure --prefix' would not work since it does not install gnulib.mo. Given all this configuration mess, for now I took the following conservative approach in Diffutils. (0) Update diffutils to use need-formatstring-macros when calling AM_GNU_GETTEXT. I discovered this issue while looking into the other problems. Perhaps need-formatstring-macros should be the only behavior nowadays? It hardly seems worth the hassle about worrying about older gettext versions. (1) Change cmp's hard_locale_LC_MESSAGES to test via setlocale, not via gettext. setlocale should work fine if ENABLE_NLS is nonzero in Diffutils. (2) Remove diffutils' po/en.po file. It is an unused revenant. (3) Stick with the longstanding approach of having the Diffutils message catalog translate all messages, including those taken from Gnulib. This has worked for decades, translators are used to it, and the Gnulib part of the catalog hardly ever changes. (4) Modify Gnulib to let Diffutils override the textdomain that Gnulib uses. Done via Gnulib commit . (5) Use this new Gnulib feature in Diffutils. I installed the attached patches to Diffutils to do this. An alternative to (4) and (5) would be to let config.h specify the "_" macro, and have Gnulib define this macro only if it is not already defined. This would make for slightly smaller executables. However, it would be brittler and more intrusive. Or perhaps you can think of a better way to do what is wanted in (3).