Bug 58070 - No en_US locale with iso-8859-15 charset
No en_US locale with iso-8859-15 charset
Status: CLOSED NOTABUG
Product: Red Hat Linux
Classification: Retired
Component: glibc (Show other bugs)
7.2
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-01-07 15:01 EST by diego.santacruz
Modified: 2016-11-24 10:20 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2002-01-07 15:01:47 EST
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 diego.santacruz 2002-01-07 15:01:42 EST
Description of Problem:

There is no (as of glibc-2.2.4-19.3) en_US locale that uses the iso-8859-15
charset. This is necessary for Euro support. There are such locales for some EU
countries, but I guess that people in the US might also want to use the Euro
symbol ;-)

It would be necessary to create more @euro locales, such as en_US@euro and
en_GB@euro, or to make the western locales use the iso-8859-15 charset instead
of the iso-8859-1 charset. Or maybe create en_US.iso-8859-15 and similar
locales? Don't know what is the best fix, but it is currently cumbersome to try
to use Euro font support. Any solution would also require updating
/usr/X11R6/lib/X11/locale/locale.{alias,dir} accordingly.

For the time being I'm using the en_IE@euro locale, but it's far from being the
best solution.

Version-Release number of selected component (if applicable):
glibc-2.2.4-19.3

Actual Results:

Cannot use Euro symbol with a en_US locale.

Expected Results:
Be able to use the Euro symbol in a en_US locale

Additional Information:
Comment 1 Jakub Jelinek 2002-01-09 05:58:08 EST
en_US@euro, en_GB@euro etc. don't make sense, those are locales where
LC_MONETARY currency is EUR, which is not true for US or GB.
As for en_US.ISO-8859-15 etc. locales:
a) you can create them yourself, just run localedef(1) to create them
b) there is en_US.UTF-8 locale which is the way to go (but admitedly not
   all apps are UTF-8 ready yet)

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