On Saturday 26 March 2005 16:31, Dimitri wrote:
Hi,
> I will let the explanation to you but if I call it like in the
doc example
> it will generate an error of:
>
> error: no matching function for call to
> `QLocale::setDefault(QLocale::Language, QLocale::Country)'
> /usr/local/qt-new/include/QtCore/qlocale.h:472: note: candidates are:
> static void QLocale::setDefault(const QLocale&)
> make: *** [qlocale.o] Error 1
You're correct, implicit constructors are called with single arguments
only. This is a documentation or API error.
I'm just saying that plain "ar" and "es" are not part of the list
of
available locales.
You are right in Fedora they are not part of available locales; In Mandrake
they are part of them.
I don't know what the system is supposed to do when
the locale is set using the language only as in "es", "ar", or "
fr"
instead of a supported language/country pair.
Do you have any documentation on this? This is not very clear from
the
documentation I have seen so far,
You mean a documentaion on what the system is supposed to do when locale is
set using the language only? I think it would depend on political issues and
this could generate a war nowadays ;) Still in your link it's mentioned
language[_territory][.codeset]
which let me feel the 'territory' and 'codeset' is optional, no?
but the Single Unix Specification
seems to support your claim that there's a bug with the locales on
Fedora Core 3:
http://www.opengroup.org/onlinepubs/007908799/xbd/envvar.html#tag_002_002
> # LC_ALL=ar date
> س مار 26 01:38:25 AST 2005
I'm afraid I don't see that on my Fedora Core 3 system, it's as if it
Sorry, I chroot'ed to another Mandrakelinux instead of Fedora. I checked now
and the arabic locales files are not completely translated in Fedora. I will
take care of this.
$ LC_ALL=ar date
Sat Mar 26 11:11:11 CET 2005
$ LC_ALL=ar_SA date
Sat Mar 26 11:11:11 CET 2005
$ LC_ALL=ar_SA.UTF-8 date
Sat Mar 26 11:11:11 CET 2005
$
> With
> QLocale ar;
> QString s1 = ar.toString(1.571429E+07, 'e');
> QLabel *label = new QLabel(s1);
> label->show();
>
> Calling this code with LC_ALL=en, LC_ALL=en_US, and LC_ALL=en_US.UTF-8,
> all still give the same result => an Arabic localazied numbers!
>
> Calling with LC_NUMERIC=en_US.UTF-8 did the trick but I understand that
> LC_ALL should overwrite LC_NUMERIC.
You're correct as far as I know. LC_ALL has precedence over individual
LC_* settings which in turn have precedence over LANG:
http://www.opengroup.org/onlinepubs/007908799/xbd/envvar.html
http://publib.boulder.ibm.com/infocenter/pseries/topic/com.ibm.aix.doc/aixp
rggd/nlsgdrf/locale_env.htm
This looks like a bug - or maybe a limitation of the Qt locale system.
It looks like Qt sees the locale as a whole (as represented by LC_ALL)
and cannot break it down into individual components. The locale is
initialized using wrong precedence rules, maybe as a consequence of this
confusion:
QLocale QLocale::system()
{
const char *s = 0;
#ifdef Q_OS_UNIX
s = qgetenv("LC_NUMERIC");
if (s == 0)
s = qgetenv("LC_ALL");
Nice catch! It should be
s = qgetenv("LC_ALL");
if (s == 0)
s = qgetenv("LC_NUMERIC");
right?
--
Munzir Taha PGP Key available
gpg --recv-keys --keyserver
www.mandrakesecure.net F0671821
Telecommunications and Electronics Engineer
Mandrake Club Member
Maintainer of the OpenBugs project page at
http://www.arabic-fedora.org/munzir/OpenBugs.html
Maintainer of Fedora Arabic Translation Project
https://listman.redhat.com/mailman/listinfo/fedora-trans-ar
CIW Designer, ICDL, MOUS, Linux+, LPI 101
New Horizons CLC, Riyadh, SA