Re: coflicting declaration in qlocale.html
by 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
19 years, 1 month
Re: coflicting declaration in qlocale.html
by Munzir Taha
On Friday 25 March 2005 20:02, Dimitri wrote:
> Hi,
>
> > It's also mentinoned there:
> > "It is initialized with a country/language pair in its constructor..."
> > Shouldn't this better be:
> > "It is initialized with a language/country pair in its constructor..."?
>
> Yes, that would be better.
>
> > Also in that same page:
> > void setDefault ( const QLocale & locale )
> > ...
> > QLocale::setDefault(QLocale::Hebrew, QLocale::Israel);
> >
> > I believe
> > setDefault needs a 'const QLocale&' not a 'QLocale::Language,
> > QLocale::Country', am I wrong?
>
> That's true, but a QLocale is implicitly constructed from the
> language/country pair:
> http://doc.trolltech.com/4.0/qlocale.html#QLocale.3
I will 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
>
> > Finally, it's also mentioned that:
> > "If a QLocale object is constructed with the default constructor, it will
> > use the default locale's settings"
> >
> > I thought the default locale should be that stored on LC_ALL, but calling
> > LC_ALL=xx ./myapp seems to ignore it, am I missing something?
>
> What is the actual value of 'xx'? To get the list of supported locales:
> locale -a
I tried LC_ALL=en_US
> For example on a Fedora Core 3 system LC_ALL usually needs to be set to
> a language/country pair:
Then I would consider this a bug in es locale in Fedora. For Arabic it works
properly (without the country part) with my Fedora 3 installation
# LC_ALL=ar date
س مار 26 01:38:25 AST 2005
> $ export LC_ALL=es
> $ date
> Fri Mar 25 11:11:11 CET 2005
> $
# uname -a
Linux localhost 2.6.10-1mdk #1 Fri Jan 14 14:31:03 CET 2005 i686 AMD
Athlon(tm) 64 Processor 3200+ unknown GNU/Linux
# locale
LANG=en_US.UTF-8
LC_CTYPE=en_US.UTF-8
LC_NUMERIC=ar_SA.UTF-8
LC_TIME=en_US.UTF-8
LC_COLLATE=en_US.UTF-8
LC_MONETARY=ar_SA.UTF-8
LC_MESSAGES=en_US.UTF-8
LC_PAPER=ar_SA.UTF-8
LC_NAME=ar_SA.UTF-8
LC_ADDRESS=ar_SA.UTF-8
LC_TELEPHONE=ar_SA.UTF-8
LC_MEASUREMENT=ar_SA.UTF-8
LC_IDENTIFICATION=ar_SA.UTF-8
LC_ALL=
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.
--
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
19 years, 1 month
arabic-fedora.org on Orbit TV channel
by Munzir Taha
Salaam Dears,
Some days ago I was interviewed at Orbit TV channel. The program is around 15
minutes and I was told not to speak technical things as much as possible so
don't expect a lot. Frankly speaking, with this being a new experience to me
and being one of those shy guys ;) I was afraid that words would escape from
my mouth with my hard heart beats. However, things has gone well except of a
very cold weather inside that can hardly let me think of anything besides why
didn't I brought my coat ;)
It's worth mentioning that it's just by chance that I spoke in a rather public
meeting where there was a guy from Orbit and another from Riyadh Newspaper
and later they asked me to give this interview.
You can see the interview on http://arabic-fedora.org/munzir/munzir.rm and
don't forget to comment ;)
--
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
19 years, 1 month
Re: coflicting declaration in qlocale.html
by Munzir Taha
> > QString s2 = egyptian.toString(10);
> > int s2 = egyptian.toInt(s2);
> >
> > Shouldn't declaring s2 as a 'QString' and then as an 'int' cause a
> > conflict?
>
> Fixed, thanks.
Thanks Dimitri
It's also mentinoned there:
"It is initialized with a country/language pair in its constructor..."
Shouldn't this better be:
"It is initialized with a language/country pair in its constructor..."?
Also in that same page:
void setDefault ( const QLocale & locale )
...
QLocale::setDefault(QLocale::Hebrew, QLocale::Israel);
I believe
setDefault needs a 'const QLocale&' not a 'QLocale::Language,
QLocale::Country', am I wrong?
Finally, it's also mentioned that:
"If a QLocale object is constructed with the default constructor, it will use
the default locale's settings"
I thought the default locale should be that stored on LC_ALL, but calling
LC_ALL=xx ./myapp seems to ignore it, am I missing something?
--
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
19 years, 1 month
Re: Arabic issue #3: Qt::AlignAuto doesn't align according the language!
by Munzir Taha
On Yaum al-Arbi'a 22 Thu al-Hijjah 1425 5:10 pm, Lars Knoll wrote:
> >
> > If you check the documentation for QTextEdit::setAlignment() then it
> > states that only the following alignments are actually valid:
> >
> > "Valid alignments are Qt::AlignLeft, Qt::AlignRight, Qt::AlignJustify
> > and Qt::AlignCenter (which centers horizontally)."
> >
> > AlignAuto is not one of them, thus this is not expected to work.
Check it here: qt.html#AlignmentFlag.enum
> As a short comment to this:
>
> We removed the AlignAuto from Qt and hopefully replaced it with a more
> consistent and intuitive approach.
>
> AlignLeft is actually to not confuse the english speaking people. In a BiDi
> context it means AlignLeading; left if the string is LTR, right if the
> string is RT). AlignRight is the opposite (AlignTrailing).
>
> In addition we have AlignLeft|AlignAbsolute if you really want to force it
> to be always left.
>
> By default, text inherits the widgets direction, so when you start an app
> with -reverse everything is right aligned. You can switch the direction of
> a string using the Shift+Ctrl combination (if you enabled it in qtconfig).
>
> Please try it with tonights snapshot. I think it comes much closer to the
> behaviour one would expect intuitively than the Qt 3 way.
Thanks Lars for the clarification, I will check it. Did you remove it from the
docs?
--
Munzir Taha PGP Key available
gpg --recv-keys --keyserver www.mandrakesecure.net F0671821
Telecommunications and Electronics Engineer
Mandrake Club Member
Maintainer of the Open Arabic Bugs Project at
http://wiki.arabeyes.org/OpenBugs
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
19 years, 1 month
OpenBugs
by Mohamed Eldesoky
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Sherif,
I see the link in the site is very long for people to remember.
Does the site use CPanel ??
I believe we can redirects (mod_rewrite) to use a better name, such as
arabic-fedora.org/opebbugs to redirect to the real place.
- --
Mohamed Eldesoky
Systems Engineer
RedHat Certified Engineer
TE Data
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFCHapX2FHsOWMJBKMRAsqkAJ0R69ocag4QcGVoyqCWHBuS2qz4/ACdFfNO
wAExt9OQIyv5eP7g7PRnHhg=
=Jtts
-----END PGP SIGNATURE-----
19 years, 1 month
Arabic issue #30: Word ligatures from Arabic Presentation Forms-A don't render properly in Qt
by Munzir Taha
Qt 4.0.0-b2-snapshot-20050308
System: Linux 2.6.10-1mdk i686 AMD Athlon(tm) 64 Processor 3200+ GNU/Linux
Example:
The word ligature
FDF2 ARABIC LIGATURE ALLAH ISOLATED FORM
<isolated> U+0627 ARABIC LETTER ALEF U+0644 ARABIC LETTER LAM U+0644
ARABIC LETTER LAM U+0647 ARABIC LETTER HEH
DESCRIPTION:
When typing those isolated characters, they should be substituted instantly by
the word ligature FDF2 if available in the font (I used KCharSelect and
gucharmap to verify the existence of the glyph in the font Tahoma) as is the
case now in my kmail composer of KDE release 3.3.2. An OpenType feature?
Even if I copy that word from my kmail to a QTextEdit/QLineEdit widget the
HARAKAT and the nice shaping disappears. Below you can see the correct
ligature in Arabic
الله
The SHADDA and the small ALEF is not typed by me but appeared automatically.
Now take that, paste it in QTextEdit and see how they disappear.
--
Munzir Taha PGP Key available
gpg --recv-keys --keyserver www.mandrakesecure.net F0671821
Telecommunications and Electronics Engineer
Mandrake Club Member
Maintainer of the OpenBugs Wiki page at
http://arabic-fedora.org/
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
19 years, 1 month
