GNU bug report logs -
#79382
patch needed after gnulib changed
Previous Next
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
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
<https://bugzilla.redhat.com/show_bug.cgi?id=2393892>.
(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
<https://cgit.git.savannah.gnu.org/cgit/gnulib.git/commit/?id=2b2bcdbc3bf3de2838a4b5051e32366e9a94f1e3>.
(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).
[0001-maint-use-need-formatstring-macros.patch (text/x-patch, attachment)]
[0002-cmp-improve-LC_MESSAGES-test.patch (text/x-patch, attachment)]
[0003-maint-remove-po-en.po.patch (text/x-patch, attachment)]
[0004-build-update-gnulib-submodule-to-latest.patch (text/x-patch, attachment)]
[0005-maint-use-our-textdomain-for-Gnulib.patch (text/x-patch, attachment)]
This bug report was last modified 3 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.