[Fedora-trans-ar] Re: coflicting declaration in qlocale.html

[Munzir Taha]

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