Bug 47247 - Xlib's locale.alias missing en_GB.ISO-8859-1
Xlib's locale.alias missing en_GB.ISO-8859-1
Status: CLOSED RAWHIDE
Product: Red Hat Linux
Classification: Retired
Component: XFree86 (Show other bugs)
7.3
All Linux
high Severity medium
: ---
: ---
Assigned To: Mike A. Harris
David Lawrence
:
: 51169 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-07-03 23:36 EDT by Owen Taylor
Modified: 2007-03-26 23:46 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-08-08 18:31:01 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 Owen Taylor 2001-07-03 23:36:10 EDT
/usr/X11R6/lib/X11/locale/locale.alias doesn't have an entry
for the three locales en_GB.ISO-8859-1, en.ISO-8859-1, en_GB.ISO-8859.1
However, these are used by GDM's default config file for
the languages displayed in its menu. Users choosing the
corresponding languages will get a non-functioning setup
once they log into X. (All other locale names used by
GDM are already in locale.alias)

(Note that each entry is in X11's locale.aliase twice, once 
with and once  without a :, the second one is the one
actually used!)

We could also change GDM's config, but since there are
entries for fr_FR.ISO-8859-1 etc of this form, and ISO-8859-1 
is the most accepted form of the charset name, adding
these entries to locale.alias seems sensible.

The _real_ fix would be to make Xlib work like GLIBC and 
canonicalize the charset to iso88591 before looking it up
in its locale.alias file....
Comment 1 Mike A. Harris 2001-07-05 16:12:34 EDT
The reason for dual entries in the file is backward compatibility, and the two halves must be kept in sync.
What entries need to be added?

en.ISO-8859-1:               en.ISO8859-1
en_GB.ISO-8859-1        en_GB.ISO8859-1

I don't see any reason for adding the following, because there are no existing entries in that form:
en_GB.ISO-8859.1        en_GB.ISO8859-1

Does that look right?  I think adding missing entries that are common to other locales is ok, but I don't
want to just add random permutations unless they are truely deemed necessary.  IOW, what specific
apps would break without foo..  The top two make perfect sense however.

Comments?
Comment 2 Glen Foster 2001-07-13 18:15:52 EDT
This defect considered SHOULD-FIX for Fairfax gold-release.
Comment 3 Mike A. Harris 2001-08-08 14:18:11 EDT
Owen,

I've looked much deeper into this, and I disagree that they
should be added.  There are few existing locale aliases in this
form, and adding more just promotes the usage of broken aliases.
In XFree86, the standard form of locale is:
xx_YY.ISO8859-n
That is what applications should be using IMHO, and all locales
should be unified to use that.  Patching the locale.alias is
a huge PITA all the time as it has to more or less be done one
piece at a time and synced in 2 places in the file.  I discourage
the addition of new aliases unless they are widely used and missing
for a given locale, or some other critical reason.  I would prefer
that the application gdm be patched to use what XFree86 and glibc
use as the default:  ISO8859-n format

However, since I am open minded about this, I will leave the
decision up to you.  If you insist on the change I will make it
with a few grumblings.  <grin>

I am going to hack X sometime to automatically canonicalize all
stupid aliases into the expected format sometime as this really
really really sucks and is incredibly tedious.

If you agree with me, please close it WONTFIX, if you feel like dropping
me into a pit of lava, then say "DOITNOWXBOY".  ;o)

Seriously though, I would really like to see the aliases minimalized
and see apps start to head towards common standard set by X and/or glibc.
Comment 4 Owen Taylor 2001-08-08 17:20:32 EDT
ISO-8859-1 is the standard name for this charset in GNU libc,
and on linux. What's in the Xlib locale.alias files is
fairly irrelevant. The C library defines locale names, not
the X library.

While adding canonicalization code would be nice, we definitely
NEED to fix this for 7.2. The 3 locales I mentioned
in my mail are the only ones that are absolute requirements.



Comment 5 Jonathan Blandford 2001-08-08 18:30:57 EDT
*** Bug 51169 has been marked as a duplicate of this bug. ***
Comment 6 Mike A. Harris 2001-08-14 04:02:38 EDT
Ok, I have been convinced.  ;o)  I've added it to 4.1.0-0.9.13 for now.

XFree86 CVS just recently got a new checkin to automate the syncing
of the two halves of the locale.alias at build time, so in the
future this might get easier to deal with.  I'm still planning
on canonicalization tho.. at somepoint.

Thanks.

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