[Bug libc/29777] New: LANGUAGE interpretation in C.UTF-8 locale is not like in C locale

["bruno at clisp dot org" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=29777

            Bug ID: 29777
           Summary: LANGUAGE interpretation in C.UTF-8 locale is not like
                    in C locale
           Product: glibc
           Version: 2.35
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: libc
          Assignee: unassigned at sourceware dot org
          Reporter: bruno at clisp dot org
                CC: drepper.fsp at gmail dot com
  Target Milestone: ---

The C.UTF-8 locale was introduced in glibc 2.35, see
https://sourceware.org/pipermail/libc-announce/2022/000033.html

Unfortunately, it is undocumented. As a fallback, I assume that the wiki page
https://sourceware.org/glibc/wiki/Proposals/C.UTF-8 , which carries the marker
"Merged for glibc 2.35", describes the intention.

This wiki page states "Setting LC_ALL=C.UTF-8 will ignore LANGUAGE just like it
does with LC_ALL=C. See guess_category_value() in intl/dcigettext.c and how it
checks "C" for more details."

But this is not how it behaves.

How to reproduce:
In a Fedora 36 installation:

$ /lib64/libc.so.6 --version

tells me that I'm using glibc 2.35.

$ locale -a | grep ^C
C
C.utf8

This shows that the C.UTF-8 locale is installed.

$ LC_ALL=C.UTF-8 LANGUAGE=fr ls --help
shows a help text in French, taken from
/usr/share/locale/fr/LC_MESSAGES/coreutils.mo .

But the expected output, per the wiki page above, is the English (untranslated)
help text.

The attached patch fixes it for me, when applied to gettext's libintl library,
with an 'ls' binary that links against libintl. I expect this patch will work
in the same way from within glibc.

-- 
You are receiving this mail because:
You are on the CC list for the bug.