Bug 12250

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.