Subject: Re:[Thuban-list] pt_pt error messages

From: "Serviopa" <[email-masked]>
Date: Tue, 26 Jul 2005 20:31:47 -0300

>I think, we must first concentrate on where this "pt_pt" comes from.
>Does it appear on the list when you type
>$ locale
>?

No, I got this:

$ locale
LANG=pt_BR
LC_CTYPE=pt_BR
LC_NUMERIC=pt_BR
LC_TIME=pt_BR
LC_COLLATE=pt_BR
LC_MONETARY=pt_BR
LC_MESSAGES=pt_BR
LC_PAPER=pt_BR
LC_NAME=pt_BR
LC_ADDRESS=pt_BR
LC_TELEPHONE=pt_BR
LC_MEASUREMENT=pt_BR
LC_IDENTIFICATION=pt_BR
LC_ALL=

Also, here is the list of the pt* locales in my system:

$ls /usr/share/locale/pt <TAB>
pt/                pt_BR.ISO-8859-15/ pt_PT.ISO-8859-1/
pt_BR/             pt_BR.UTF-8/       pt_PT.ISO-8859-15/
pt_BR.ISO-8859-1/  pt_PT/             pt_PT.UTF-8/

And the i18n file:

$ less /etc/sysconfig/i18n

SYSFONTACM=iso01
LANGUAGE=pt_BR:pt_PT:pt
LC_ADDRESS=pt_BR
LC_COLLATE=pt_BR
LC_NAME=pt_BR
LC_NUMERIC=pt_BR
LC_MEASUREMENT=pt_BR
LC_TIME=pt_BR
LANG=pt_BR
LC_IDENTIFICATION=pt_BR
LC_MESSAGES=pt_BR
LC_CTYPE=pt_BR
LC_TELEPHONE=pt_BR
LC_MONETARY=pt_BR
LC_PAPER=pt_BR
SYSFONT=lat1-16
LESSCHARSET="latin1"

However, thuban install created this directory:

/usr/local/lib/thuban/Resources/Locale/pt_pt/

---

From: Jan-Oliver Wagner <[email-masked]>
Date: Wed, 27 Jul 2005 07:01:00 +0200

> /usr/local/lib/thuban/Resources/Locale/pt_pt/

thats not good.
For a test, can you rename this directory to
pt or pt_BR and try again?

Best 

	Jan
-- 
Jan-Oliver Wagner               http://intevation.de/~jan/
Intevation GmbH                      http://intevation.de/
Kolab Konsortium               http://kolab-konsortium.de/
FreeGIS                                http://freegis.org/

---

From: Bernhard Herzog <[email-masked]>
Date: Thu, 28 Jul 2005 15:29:43 +0200

> $ less /etc/sysconfig/i18n

Is this also the value of your environment variable LANGUAGE?  If so,
that's the origin of the problem.  This looks like a bug in Python
(details below).  As a workaround, try

export LANGUAGE=pt_BR.ISO-8859-1:pt_PT:pt

   Bernhard

The rest of this post are the details on the python bug.  Feel free to
skip it :)

The real problem behind all this is that there's no reliable way to
determine the encoding to use.  Python's locale module tries to deduce
it from the locale settings and on linux that means to deduce it from
the locale name.  To do this it looks at following environtment
variables in that order: 'LANGUAGE', 'LC_ALL', 'LC_CTYPE', 'LANG'

The value of the first of these variables which actually has a value is
then used to determine the encoding.  The value is "normalized" which
replaces ":" with "." among other things.  The normalized value of
"pt_BR:pt_PT:pt" is 'pt_BR.pt_pt'.  In the normalized value, the
encoding is assumed to be the text after a "@" or a ".", so in your case
that's "pt_pt", which is obviously incorrect.

The bug in Python is that it doesn't take into account that LANGUAGE can
be a colon-separated list of locales.  This appears to be present in the
current CVS version of Python as well.  If I find the time, I'll try to
make a least a bug report for it.

   Bernhard

-- 
Intevation GmbH                                 http://intevation.de/
Skencil                                           http://skencil.org/
Thuban                                  http://thuban.intevation.org/

---

From: Bernhard Reiter <[email-masked]>
Date: Mon, 26 Sep 2005 17:51:00 +0200

> make a least a bug report for it.

There already seems to be one:
http://sourceforge.net/tracker/index.php?func=detail&aid=1158490&group_id=5470&atid=105470

[ 1158490 ] locale fails if LANGUAGE has multiple locales