Summary: | All KDE Applications Are Fail With The Turkish Language When Changing Case of A Turkish (i/ı) Character | ||
---|---|---|---|
Product: | [Unmaintained] kdelibs | Reporter: | S.Çağlar ONUR <caglar> |
Component: | qt | Assignee: | Thiago Macieira <thiago> |
Status: | RESOLVED LATER | ||
Severity: | normal | CC: | baris, ismail |
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | Gentoo Packages | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: |
Description
S.Çağlar ONUR
2005-03-10 01:37:48 UTC
By the way, all system locales are set to "tr_TR.UTF-8" and KDE's Language is Turkish. Does Qt provide any locale-dependent uppercasing function? If not, then it is a Qt bug and should be reported to them. We should not be the ones to include the uppercasing tables. Neither QString not QChar provides other transformation methods than upper() and lower(). Where can we go from here? Reported to trolltech. Thank you very much for your quick response. In fact upper() and lower() functions are locale-dependent. But they can't handle a change of a byte-count change in case conversions. It was the same problem with gawk (GNU AWK), which we fixed. Bug reports are in Turkish but maybe patch can help understanding the problem. (http://bugs.uludag.org.tr/attachment.cgi?id=13&action=view) This is a serious problem for Turkish and Azerbeijani locales. This simply makes applications (most parts of them) useless in these locales. Case conversions and chage in the byte-count is documented in glibc documentation, but very few program implement this right :(. Do we have any thing to do for bug to fixed more quickly? On Thursday 10 March 2005 18:54, Baris Metin wrote:
> Do we have any thing to do for bug to fixed more quickly?
Work with trolltect is better than here. I reported the issue to them, an I
hope they take it seriously, and follow this issue. But I can't know.
-anders
I'm sorry, but your assessment is not correct. upper() and lower() should be locale-dependent, but they are not. They use the standard rules in the Unicode tables, and do not factor into the algorithm the exceptions. I have just read the code in qunicodetables_p.h to confirm that. There's also no problem with byte count, since all characters are 2-byte Unicode codepoints (UTF-16). Nothing inside the Basic Multilingual Plane can case-fold to outside it. But, you are right: uppercasing, lowercasing and titlecasing are *string* operations, not *character* operations. The QChar::upper() & family functions should not be used. The issue here lies with Qt. Has anyone reported this to them? If not, I will do so. If you have, please point them to this bug report. Assigning to null isn't nice. You are right Thiago. I think my assessment is true for only QCString, which call toupper/tolower directly ( if Qt doesn't do some function overloading for these ). We have reported the problem and I think Andres did too. On Friday 11 March 2005 03:09, Thiago Macieira wrote:
> The issue here lies with Qt. Has anyone reported this to them? If not, I
> will do so. If you have, please point them to this bug report
I repeat, I have mailed qt-bugs about this.
-anders
Ok, record here the Qt Issue numbers that Trolltech assigns to you. I have also confirmed that Qt4 suffers from the same problem. I am closing the bug report with LATER because there's nothing we can do right now (that doesn't mean we can't discuss). Fixed in Qt4 (tested with Qt 4.0.1) using QByteArray which replaced QCString. |