+++ This bug was initially created as a clone of Bug #2002734 +++ There is a movement towards C.UTF-8 for small images (containers and VMs). C.UTF-8 has both size and performance improvements over the more traditional en_US.UTF-8 locale. (The performance improvement is currently in upstream glibc only, but we plan to bring it to rawhide and Fedora 35 shortly.) However, in a world where glibc-langpack-en (or glibc-all-langpacks) is not installed on target systems, logging in over SSH does not result in a viable locale if the client use en_US.UTF-8 (or any other locale except C or C.UTF-8). This causes a severe degradation in user experience. It's not only that UTF-8 output does not work, there are also frequent warning messages from various tools. Some may even refuse to run completely. Most distributions send locale environment variables by default: SendEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES SendEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT SendEnv LC_IDENTIFICATION LC_ALL LANGUAGE SendEnv XMODIFIERS And accept them on the server side: AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT AcceptEnv LC_IDENTIFICATION LC_ALL LANGUAGE AcceptEnv XMODIFIERS (Some distributions also use LC_* wildcards.) Now that servers often use minimal installations which only support a small set of locales (C, C.UTF-8), it makes sense to discontinue this practice.
This bug appears to have been reported against 'rawhide' during the Fedora 36 development cycle. Changing version to 36.
Implemented in rawhide (F37).