Re: In coreutil 9.11, translations are not displayed in locales other than English

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