Red Hat Bugzilla – Bug 641
Please add ru_RU.KOI8-R locale
Last modified: 2008-05-01 11:37:48 EDT
The de-facto standard for Russian Cyrillics on Linux (and other Unices) is a KOI8-R encoding while virtually nobody uses ISO-8859-5 for Russian. But the glibc RPM includes /usr/share/locale/ru_RU directory with ru_RU.ISO-8859-5 and does not include ru_RU.KOI8-R locale
The glibc rpms are including the KOI*-R support, but under the name of ru_SU. You can either use ru_SU instead of the ru_RU or just replace the contents of the ru_RU dirs/locale files with what is found in ru_SU Needless to say, the "international standard" is the ISO-8859-5 crap for ru_RU and we can not diverge that easily from the standards... Now, if the ru_SU thing is busted then I am taking patches, my russian is *so* limited... :-)
/usr/share/locale/ru_SU seems OK, I just did not know it was KOI8-R But there is a big problem with ru_SU - /usr/X11R6/lib/X11/locale/locale.alias defines ru_SU to be ru_RU.ISO-8859-5 One way to make everything work consistently (and without any deviation from standards) is to run cd /usr/share/locale localedef -ci ru_RU -f KOI8-R ru_RU.KOI8-R mv ru_RU.koi8r ru_RU.KOI8-R and to use LC_ALL=ru_RU.KOI8-R after that. Another way is to add ru_RU.KOI8-R ru_SU line to /usr/share/locale/locale.alias and to change ru_SU to be ru_RU.KOI8-R in /usr/X11R6/lib/X11/locale/locale.alias One of the problems with the second approach is that neither locale.alias file is a %config file
*** Bug 641 has been marked as a duplicate of this bug. *** Traditionaly, *the standard* locale for UNIX in Russia was KOI8-R. This is broken in RedHat - ISO is set by default. To fix: 1. ru_RU must select KOI8-R (same in /usr/X11R6/lib/X11/locale/locale.alias) 2. ru_RU.<charset> must reference respective charsets 3. ru_SU must be an alias for ru_RU
ru_SU now properly selected KOI8-R. The X situation has been rectified as well.
correction: for 6.1, ru_SU is gone. ru_RU selects ISO-8859-5. ru_RU.KOI8-R selected the KOI8-R encoding, and ru_RU.ISO-8859-5 selects the 8859-5 encoding as well (obviously). We are fully in line with all standards for this.