[gentoo-user] problem getting UTF-8 locale

[gentoo-user] problem getting UTF-8 locale

[Liviu Andronic]

[-- Attachment #1: Type: text/plain, Size: 766 bytes --]

Sorry for the double-sent message. Have just changed the subject.

Hello list,
>
> I have a slight problem with defining a en_US.UTF-8 locale. I tried the
> Gentoo Official Documentation on Localization and Syste-wide
> UTF-8, but I cannot make actually having en_US.UTF-8. Here are some commands I ran:
>
>
> The locales I have (nothing changes even after I run the rest of the
> commands.
> localhost ~ # locale -a
> C
> en_US.utf8
> POSIX
>
> localhost ~ # localedef -i en_US -f UTF-8 en_US.UTF-8
> localhost ~ # locale-gen
> * Generating 1 locales (this might take a while)
> * (1/1) Generating en_US.UTF-8 ... [ ok ] * Generation complete
> localhost ~ # locale -a
> C
> en_US.utf8
> POSIX
> localhost ~ # env | grep -i LC_
> LC_ALL=en_US.UTF-8
>
>
>
-- 
Liviu

[-- Attachment #2: Type: text/html, Size: 1264 bytes --]

[gentoo-user] Re: problem getting UTF-8 locale

[Liviu Andronic]

[-- Attachment #1: Type: text/plain, Size: 1914 bytes --]

Thanks for answering.


On 10/6/06, Bo Ørsted Andresen <bo.andresen@zlin.dk> wrote:
>
> On Friday 06 October 2006 13:29, Liviu Andronic wrote:
> > I have a slight problem with defining a en_US.UTF-8 locale. I tried the
> > Gentoo Official Documentation on Localization and Syste-wide
> > UTF-8, but I cannot make actually having en_US.UTF-8. Here are some
> > commands I ran:
> >
> > The locales I have (nothing changes even after I run the rest of the
> > commands.
> > localhost ~ # locale -a
> > C
> > en_US.utf8
> > POSIX

Please note that here locale -a doesn't show en_US.UTF-8, but
en_US*.utf8 *(case
change and missing dash).

Furthermore, I wouldn't have written on this matter if I didn't have
problems with an application. I use emelFM2 as file manager and it uses LC_*
variables to determine the encoding to be used for file names (if not
mistaking anything). Now, after having made changes to the locales (emelFM2
was using C locale before, including for it's configuration file), filenames
containing peculiar characters (Cyrillic and others) are illisible in the
filelist. Moreover, although in debugs emelFM2 determines correctly that
LC_ALL indicates en_US.UTF-8, it falls back (I believe) to using C locale
instead of the utf-8 one (reads from and saves to config-C instead of
config-en_US.UTF-8).


> localhost ~ # localedef -i en_US -f UTF-8 en_US.UTF-8
>
> localedef is not necessary. Use locale-gen instead.
>
> > localhost ~ # locale-gen
> > * Generating 1 locales (this might take a while)
> > * (1/1) Generating en_US.UTF-8 ... [ ok ] * Generation complete
>
> Which you did - with success.
>
> > localhost ~ # locale -a
> > C
> > en_US.utf8
> > POSIX
> > localhost ~ # env | grep -i LC_
> > LC_ALL=en_US.UTF-8
>
> And your current locale obviously is en_US.UTF-8. So... congrats...
> everything
> is fine. :)
>

Not quite. Please see comments above.


--
> Bo Andresen
>
>
>


-- 
Liviu

[-- Attachment #2: Type: text/html, Size: 2684 bytes --]

Re: [gentoo-user] Re: problem getting UTF-8 locale

[Bo Ørsted Andresen]

[-- Attachment #1.1: Type: text/plain, Size: 1537 bytes --]

On Friday 06 October 2006 20:51, Liviu Andronic wrote:
> Thanks for answering.

Was a mistake by me that I replied to the wrong mail of yours.. ;)

[SNIP]
> Please note that here locale -a doesn't show en_US.UTF-8, but
> en_US*.utf8 *(case
> change and missing dash).

That's expected. Not an error.

> Furthermore, I wouldn't have written on this matter if I didn't have
> problems with an application.

Yes, but we aren't mind readers. Knowing that you probably had a reason that you decided wasn't worth mentioning really isn't helpful...

> I use emelFM2 as file manager and it uses 
> LC_* variables to determine the encoding to be used for file names (if not
> mistaking anything). Now, after having made changes to the locales (emelFM2
> was using C locale before, including for it's configuration file),
> filenames containing peculiar characters (Cyrillic and others) are
> illisible in the filelist. Moreover, although in debugs emelFM2 determines
> correctly that LC_ALL indicates en_US.UTF-8, it falls back (I believe) to
> using C locale instead of the utf-8 one (reads from and saves to config-C
> instead of config-en_US.UTF-8).

As you may have noticed emelfm2 has been removed from the portage tree because it lacks a maintainer. The latest ebuild is on bug #90476 [1]. Unlike the latest ebuild in portage that actually has a unicode use flag. Did you use that one [2]?

[1] http://bugs.gentoo.org/show_bug.cgi?id=90476
[2] http://bugs.gentoo.org/attachment.cgi?id=97568

-- 
Bo Andresen

[-- Attachment #1.2: Type: text/html, Size: 2431 bytes --]

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-user] Re: problem getting UTF-8 locale

[Liviu Andronic]

[-- Attachment #1: Type: text/plain, Size: 3074 bytes --]

Hello Bo

On 10/6/06, Bo Ørsted Andresen <bo.andresen@zlin.dk> wrote:
>
> On Friday 06 October 2006 20:51, Liviu Andronic wrote:
>
> > Thanks for answering.
>
> Was a mistake by me that I replied to the wrong mail of yours.. ;)
>
> [SNIP]
>
> > Please note that here locale -a doesn't show en_US.UTF-8, but
>
> > en_US*.utf8 *(case
>
> > change and missing dash).
>
> That's expected. Not an error.
>
> > Furthermore, I wouldn't have written on this matter if I didn't have
>
> > problems with an application.
>
> Yes, but we aren't mind readers. Knowing that you probably had a reason
> that you decided wasn't worth mentioning really isn't helpful...
>
This was my mistake, to not have written all the problems.

> > I use emelFM2 as file manager and it uses
>
> > LC_* variables to determine the encoding to be used for file names (if
> not
>
> > mistaking anything). Now, after having made changes to the locales
> (emelFM2
>
> > was using C locale before, including for it's configuration file),
>
> > filenames containing peculiar characters (Cyrillic and others) are
>
> > illisible in the filelist. Moreover, although in debugs emelFM2
> determines
>
> > correctly that LC_ALL indicates en_US.UTF-8, it falls back (I believe)
> to
>
> > using C locale instead of the utf-8 one (reads from and saves to
> config-C
>
> > instead of config-en_US.UTF-8).
>
> As you may have noticed emelfm2 has been removed from the portage tree
> because it lacks a maintainer.
>
Are you saying that it lacks a maintainer for keeping emelFM2 up-to-date in
portage? Since this is one good two-pane dependency-less file manager,
I cannot understand why
portage doesn't provide users with it. Is there any way to ask
portage devels to update regularly
emelFM2 ebuilds? (As it can be seen in [1], there are people providing
ebuilds for each emelFM2 release; couldn't they help maintaining emelFM2 in
portage?). I've tested it on Gentoo and it works in a pretty stable manner
(so that ~x86 would largely suffice for version 0.2).


The latest ebuild is on bug #90476 [1]. Unlike the latest ebuild in portage
> that actually has a unicode use flag. Did you use that one [2]?
>
I'm novice enough to Gentoo to not yet master emerging from custom ebuilds.
So I build it from source (make && make install). I used version 0.2.

However, the problem isn't emelFM2 specific. It is more linked to GTK+2
applications. For example, Qalculate! isn't able to display the pi sign (the
unicode pi sign). Or Xfce cannot display corefonts (Arial, Tahoma, Verdana).
Instead of displaying a unicode character (my guess), it displays
an incomprehensible series of numbers.

My guess is that it has to be somehow linked to locale, but I cannot see
how. I have a fresh 2006.1 Gentoo installation, with a customised kernel
having nls_utf8 built-in. The only crucial change that I made was upgrading
Xorg to 7.1. I generally build all my applications with +nls flag.


[1] http://bugs.gentoo.org/show_bug.cgi?id=90476
>
> [2] http://bugs.gentoo.org/attachment.cgi?id=97568
>
> --
>
> Bo Andresen
>
>


-- 
Liviu

[-- Attachment #2: Type: text/html, Size: 5710 bytes --]

Re: [gentoo-user] Re: problem getting UTF-8 locale

[Bo Ørsted Andresen]

[-- Attachment #1: Type: text/plain, Size: 1846 bytes --]

On Monday 09 October 2006 15:03, Liviu Andronic wrote:
{SNIP]
> Are you saying that it lacks a maintainer for keeping emelFM2 up-to-date in
> portage? 

Yes.

[SNIP]
> Is there any way to ask portage devels to update regularly
> emelFM2 ebuilds? (As it can be seen in [1], there are people providing
> ebuilds for each emelFM2 release; couldn't they help maintaining emelFM2 in
> portage?).
[SNIP]

If one of them is willing to be a maintainer and he can find a dev who is 
willing to become proxy him, yes. Apparently noone did so far though.

> > The latest ebuild is on bug #90476 [1]. Unlike the latest ebuild in
> > portage that actually has a unicode use flag. Did you use that one [2]?
>
> I'm novice enough to Gentoo to not yet master emerging from custom ebuilds.
> So I build it from source (make && make install). I used version 0.2.

You just fetch the ebuild and the two patches it requires from the bug and 
place them in your local overlay. This should help you figure out how:

http://gentoo-wiki.com/HOWTO_Installing_3rd_Party_Ebuilds

> However, the problem isn't emelFM2 specific. It is more linked to GTK+2
> applications. For example, Qalculate! isn't able to display the pi sign
> (the unicode pi sign). Or Xfce cannot display corefonts (Arial, Tahoma,
> Verdana). Instead of displaying a unicode character (my guess), it displays
> an incomprehensible series of numbers.
>
> My guess is that it has to be somehow linked to locale, but I cannot see
> how. I have a fresh 2006.1 Gentoo installation, with a customised kernel
> having nls_utf8 built-in. The only crucial change that I made was upgrading
> Xorg to 7.1. I generally build all my applications with +nls flag.

Only suggestion I can think of is to follow this:

http://www.gentoo.org/doc/en/utf-8.xml

-- 
Bo Andresen

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-user] Re: problem getting UTF-8 locale

[Liviu Andronic]

[-- Attachment #1: Type: text/plain, Size: 1215 bytes --]

On 10/12/06, Bo Ørsted Andresen <bo.andresen@zlin.dk > wrote:
>
>
> > However, the problem isn't emelFM2 specific. It is more linked to GTK+2
> > applications. For example, Qalculate! isn't able to display the pi sign
> > (the unicode pi sign). Or Xfce cannot display corefonts (Arial, Tahoma,
> > Verdana). Instead of displaying a unicode character (my guess), it
> displays
> > an incomprehensible series of numbers.
> >
> > My guess is that it has to be somehow linked to locale, but I cannot see
> > how. I have a fresh 2006.1 Gentoo installation, with a customised kernel
> > having nls_utf8 built-in. The only crucial change that I made was
> upgrading
> > Xorg to 7.1. I generally build all my applications with +nls flag.
>
> Only suggestion I can think of is to follow this:
>
> http://www.gentoo.org/doc/en/utf-8.xml

Finally, I found the problem. It wasn't linked to the locale. As you said,
it was correctly
set. The problem with emelFM2 was that it was expecting LC_MESSAGES to
be explicitely set. This

is easily configurable.

However, I have a problem with the rendering of certain fonts. I'll start a
new thread for this (problem rendering unicode characters).

Thanks for the help.




-- 
Liviu

[-- Attachment #2: Type: text/html, Size: 2044 bytes --]