Bug 12250 - Keyboard layout chosen in install should probably be written to /etc/sysconfig/i18n
Keyboard layout chosen in install should probably be written to /etc/sysconfi...
Status: CLOSED RAWHIDE
Product: Red Hat Linux
Classification: Retired
Component: distribution (Show other bugs)
7.1
i386 Linux
low Severity medium
: ---
: ---
Assigned To: Brent Fox
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2000-06-14 05:50 EDT by Pekka Savola
Modified: 2008-05-01 11:37 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2002-06-19 01:38:53 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Pekka Savola 2000-06-14 05:50:25 EDT
Keyboard layout I chose probably should be written appropriately as
LC_CTYPE to /etc/sysconfig/i18n.  There is only 'LANG=en_US' there.
Comment 1 Pekka Savola 2000-06-30 01:53:00 EDT
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)
Comment 2 Pekka Savola 2000-06-30 01:54:16 EDT
Oh shoot, bugzilla doesn't support special chars. 'd' in lc_test and the output
was really 'a' with two dots.
Comment 3 Glen Foster 2001-01-11 16:17:43 EST
This defect is considered MUST-FIX for Florence Gold release
Comment 4 Pekka Savola 2001-01-11 16:25:56 EST
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.
Comment 5 Brent Fox 2001-01-15 16:05:15 EST
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.

Comment 6 Pekka Savola 2001-01-15 16:29:00 EST
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.  



Comment 7 Brent Fox 2001-01-17 11:32:30 EST
I think that's a bigger change than we want to make at this time.
Comment 8 Aleksey Nogin 2002-01-03 12:28:52 EST
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...
Comment 9 Trond Eivind Glomsrxd 2002-01-23 12:56:12 EST
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).
Comment 10 Christian Rose 2002-01-23 13:57:42 EST
> 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;
}
Comment 11 Michael Fulbright 2002-02-11 14:58:48 EST
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.
Comment 12 Brent Fox 2002-06-19 01:38:47 EDT
teg, I must admit that I don't fully understand the issue here.  What would you
recommend that I do for this report?
Comment 13 Brent Fox 2002-08-01 14:20:46 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.