locales, nls - supportable or not?

Ken Moffat zarniwhoop at ntlworld.com
Thu Nov 16 14:01:04 PST 2006


On Wed, Nov 15, 2006 at 09:55:01AM +0500, Alexander E. Patrakov wrote:
> Hello,
> 
> there was a thread on blfs-support that really made me think that all my 
> efforts of adding locale support to the book were in vain. See 
> http://archives.linuxfromscratch.org/mail-archives/blfs-support/2006-November/061520.html
> 
> The problem is that the wrong answer is given to the original poster by 
> TWO editors, and nobody corrected them. On this basis, I declare that 
> locale issues are not really supportable (and DIY is right in ignoring 
> them), and demand immediate removal of all UTF-8 related patches and 
> instructions from LFS and BLFS (and putting back the words like "UTF-8 
> does not work and requires substantial undocumented modifications to the 
> build process"). It is better to be honest and don't claim non-existent 
> support.
 Sorry for the delay in replying, I was trying to fix an issue on
ppc64 bclfs (/me frowns at Jeremy for putting ppc64 into clfs ;)

 AFAIK. we don't claim to support all problems, whether from locales
or from anything else - over time, the community's knowledge
increases, and people get better support.

 In the meantime, you want us to go back to ncurses with the
ugliness of the screen in the kernel's 'make menuconfig' ?  There
are many facets to i18n, and I'm sure it will take a long while to
get it all working - since I can see from the i18n archives that you
know a lot more about it than I do, I'm not going to attempt to drag
you down to my level by arguing.  For many of us, what we have now is
a lot better than what we had a year ago.

> 
> Now, the correct answer to the thread mentioned above.
> 
> >nls_utf8 doesn't seem to be used, but I don't know it this right
>
[ snip useful pointer to the book, and es example - thanks for that ]
> 
> >Only one question: how do you set utf-8 for X and, say, iso-8859-15 
> >for console?
> 
> You don't - this is an inherently broken setup. If you do this, in the 
> console you won't be able able to read documents that were created in X, 
> and the other way round. You want es_ES.UTF-8 in both places. And the 
> latest kernel even doesn't need patches for this to work (but that's 
> only because your keymap doesn't produce characters outside of Latin-1 
> using dead keys).
> 
 I thought I had pointed out in my reply that not all characters
would work, particularly the € (euro) symbol.  I don't have any
keyboards other than gb, so I can't test if the rest work, but if
someone who does have such a keyboard wants to *try* variations
which mostly support the characters they are likely to use, I don't
see the harm.  Certainly, the console can never show more than a
subset of all the available unicode glyphs, but that might be
adequate for some uses - it's not a decision _I_ can make.

 Anyway, you've now suggested a working console setup.

ĸen
-- 
das eine Mal als Tragödie, das andere Mal als Farce



More information about the blfs-dev mailing list