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.
Created attachment 14452 [details] Fix
Would you please post the fix to libc-alpha? It's probably the best fix we have for now. Please reference the older bug 16621 in the commit message. Thanks. *** This bug has been marked as a duplicate of bug 16621 ***
The fix was posted to https://sourceware.org/pipermail/libc-alpha/2022-November/143432.html But it was incomplete. Part 2 has been posted to https://sourceware.org/pipermail/libc-alpha/2023-September/151463.html