On 25/08/2026 06:43, ribbon wrote:
Some messages output by programs in GNU coreutils 9.11 are not being translated.
When the --help option is specified, a help message is displayed, but
some messages remain in English. Specifically,
Report bugs to: [email protected]
Print machine architecture.
GNU coreutils home page: <https://www.gnu.org/software/coreutils/>
are not translated. The rest of the text translates without any issues.
I did a little investigating.
The messages mentioned above are found in `emit_bug_reporting_address()`
in `lib/version-etc.c`,where `gettext()` is used to output the messages.
Just before outputting the message, I used `printf` to check the current locale,
and it matched the locale of the running environment. However, when I tried
adding other
messages to the source code, they also remained in English.
However, I tried copying the `emit_bug_reporting_address()` section to `uname.c`
and running it as `emit_bug_reporting_address1()`.
As a result, the message was output correctly in the locale of
the running environment.Therefore, it appears that neither the gettext
functionality nor the message catalog is the issue.
It seemed that when there was a message using gettext in
`emit_bug_reporting_address()` in `lib/version-etc.c`,
the conversion did not work properly.
I’d like to investigate this issue a bit further—is there a
good way to do that?
I think this is due to the separation of the gnulib and coreutils
translation domains.
The last gnulib translations release was in 2024:
https://ftp.gnu.org/gnu/gnulib/gnulib-l10n-20241231.tar.gz
That correlates on my Fedora system:
$ rpm -q gnulib-l10n
gnulib-l10n-20241231-2.fc44.noarch
The separation was discussed for Fedora in:
https://bugzilla.redhat.com/2393892
You can see the different calls in:
$ DEBUGINFOD_CACHE_PATH=/ ltrace -e '*gettext*' true --help >/dev/null
true->dcgettext(nil, "Usage: ...
...
true->dcgettext("gnulib", "Report bugs to: ...
Note the DEBUGINFOD_CACHE_PATH is to avoid an ltrace bug where it
seems to mishandle cross-file DW_AT_abstract_origin yielding an invalid
dcgettext() prototype. Note without DEBUGINFOD_CACHE_PATH it works for _some_
binaries if the entry appears in a DW_TAG_partial_unit, which it skips,
then falling back to libc.so.conf to get the correct signature.
I can't seem to look at any software recently without finding bugs :/
Anyway since we're also including these translations, we have the option
to use our translations, which are probably more complete.
The gnulib-tool docs state this can be done by us adding
the following to configure.ac:
AC_DEFINE([GNULIB_TEXT_DOMAIN], [PACKAGE])
The following languages don't have gnulib translations
on my Fedora 44 system at least:
$ for l in git/coreutils/po/*.gmo; do
la=$(basename $l .gmo)
echo $la | grep -q _ || la=${la}_
locale -a | grep "^$la.*utf8$"
done |
while read loc; do
LC_MESSAGES=$loc env true --help |
grep -q 'Report bugs to' &&
echo "$loc"
done |
cut -d_ -f1 | sort -u | fmt -w$COLUMNS
af ar be ca cs da el et eu ga gl hr hu ia id ja kk ko lg lt ms nb sk sl ta
tr vi
cheers,
Padraig
