6.1 release branch, /etc/profile locale specification

Alexander E. Patrakov patrakov at ums.usu.ru
Tue Apr 5 19:49:17 PDT 2005


Alexander E. Patrakov wrote:

> Matthew Burgess wrote:
> 
>> Alexander E. Patrakov wrote:
>>> So it's better to change the book to say "ISO-8859-1".
>> 
>> Hmm, but as Ken pointed out, 'locale -a' (which we point out on that
>> same page) lists 'en_GB.iso88591', so I've a feeling us setting it to
>> 'ISO-8859-1' may just confuse folks.  If there's stuff out there that
>> incorrectly expects something else, it needs reporting as a bug IMO.
>> 
>> So, are there any compelling reasons for us not setting it to
>> 'en_GB.iso88591'?
> 
> Nothing wrong with it now (when UTF-8 is not supported), as long as we
> mention that en_GB.iso88591 and en_GB.ISO-8859-1 are synonims (so that
> people see both forms). But when we add support for UTF-8, we will have to
> say that "en_GB.UTF-8" is the only correct variant ("en_GB.utf8" confuses
> at least ncurses).
> 
Found a better solution (but please reword so that I know that you understand 
it).

====================
The list of all locales supported by Glibc can be obtained by running the 
following command:

locale -a

Locale names returned by that command (like en_GB.iso88591) are recognized by 
Glibc, but some applications may require different spelling of the character 
encoding name. To find out the canonical name of the character encoding, 
execute the command like the one below:

LC_ALL=en_GB.iso88591 locale charmap

It will print: ISO-8859-1. Therefore, the preferred name of that locale is 
en_GB.ISO-8859-1. Glibc treats that as a synonim for en_GB.iso88591.
====================

There is, however, one more issue I want to have fixed.

On glibc page, we have two variants of locale installation commands: one is 
"make localedata/install-locales", the other is a series of "localedef" 
commands. I want to express the fact that the second variant is the preferred 
one if the reader knows exactly the list of locales he needs. The reason is 
the unfixed portion of 
http://blfs-bugs.linuxfromscratch.org/show_bug.cgi?id=909

-- 
Alexander E. Patrakov



More information about the lfs-dev mailing list