Keyboard layout I chose probably should be written appropriately as LC_CTYPE to /etc/sysconfig/i18n. There is only 'LANG=en_US' there.
Extension: LC_COLLATE="fi_FI" should be written too. Else e.g. the following will break with really many locales with special chars by default: file lc_test: ---- a d o ---- really many locales (e.g. fi_FI, swedish, norwegian, etc.) want the output of sort lc_test to look like: ---- a o d ---- But instead, it's the default one: ---- a d o ---- If LC_COLLATE (and LC_CTYPE for some other apps) isn't written to i18n at setup, the default configuration will be broken for those locales. This needs testing, so I wouldn't leave it to the last minute (priority/severity changed up)
Oh shoot, bugzilla doesn't support special chars. 'd' in lc_test and the output was really 'a' with two dots.
This defect is considered MUST-FIX for Florence Gold release
Note: LC_COLLATE is rather controversial. Most experienced guys are used to the 'long unix tradition' setting. However, there should be zero problems in defining LC_CTYPE.
The big problem is that if you do a graphical install, then /etc/sysconfig/i18n contains LANG="en_US" no matter what language you choose. This has been fixed now in our internal builds. I think that other settings like LC_COLLATE and LC_CTYPE are inherited from LANG. If that's correct, then LANG is all we need to set.
I have to disagree. Foreign people who don't want to change the OS language select English. However, they still select local keyboard setting to get the keys right. The closest match to LC_CTYPE is what your keyboard supports, and what's shown on screen when you type those characters. Not what language your system has been translated into. LC_COLLATE is problematic because the default 'C' and 'en_US' behave very differently when it comes to e.g. '.' in a word. This is probably a 'major' change.
I think that's a bigger change than we want to make at this time.
Can we revisit this? I agree that LC_CTYPE should match the keyboard config, no matter what LC_MESSAGES (inherited from LANG) does. This should probably be done when keybord is chosen from both anaconda and kbdconfig. Hopefully now is a better time for such "big" changes...
I disagree. I have a US keyboard, and run Norwegian locale (as many programmers in Norway do, the placement of {}[] are awkward on native keybaords).
> Can we revisit this? I agree that LC_CTYPE should match the keyboard > config, no matter what LC_MESSAGES (inherited from LANG) does. This should > probably be done when keybord is chosen from both anaconda and kbdconfig. Any special reason for this? I don't think it should be "no matter what", for the reasons that teg specified. There are users that are using local locale but English keyboards (although they are very few in my experience), and these users need LC_CTYPE to match their locale since applications will otherwise display some characters wrongly, or not at all. My proposal in some sort of pseudo-code: if ((language == "english") && (keyboard_layout == "en_US")) { LC_CTYPE = "en_US"; } elsif ((language == "english") && !(keyboard_layout == "en_US")) { LC_CTYPE = locale_for_the_selected_keyboard_layout; } else { /* This handles both situations with local language and local layout and situations with local language and English layout. */ LC_CTYPE = locale_for_the_selected_language; }
The opinion internally was that there was no good way to handle this generally. It is better handled by having a mechanism to configure LANG different than LC_TYPE post-install. I'll assign this bug to the author of the first boot config utility so he can handle it.
teg, I must admit that I don't fully understand the issue here. What would you recommend that I do for this report?
Hopefully this has been resolved with the new keyboard tool, redhat-config-keyboard. If it has not, please open a new bug against that tool.