Fwd: case-convertion problems with locale-dependent functions

[Ingo Klöcker]

Hi,

this is a kde-core issue. I've removed the kdepim-specific patch. FWIW, 
I propose to call the function kasciistricmp (instead of kstricmp) 
because it's only useful for making case-independent comparisons of 
ASCII strings.

Regards,
Ingo

----------  Forwarded Message  ----------

Subject: [Kde-pim] case-convertion problems with locale-dependent 
functions
Date: Saturday 20 November 2004 12:31
From: Baris Metin <baris at uludag.org.tr>
To: kde-pim at kde.org

Hello,

I've filled two bugs[1] concerning the case-conversion problems in
Turkish locales.

I'll try to explain the problem for Turkish only but, problems arise in
Turkish (tr_TR, tr_TR.UTF-8), Azeri latin (az_AZ) and newly proposed
tr_CY locales.

In respect to English's i,I characters Turkish has four characters
(i,I,İ,ı) lowercase and uppercase forms of dotted and dottless I.

Moreover case-conversion of these characters in Turkish is different
than it is in English. Uppercasing i produces "I with a dot above" and
lowercasing I produces "i without the dot above". In fact there is a
document[2] describing the situation better than I do.

Now  I've found one more bug which is related to this problem.

In Turkish locale Kmail can't handle multipart messages if the
Content-type header is defined with uppercase letters like this:

Content-Type: MULTIPART/MIXED;
 BOUNDARY="8323328-1440130431-1099506467=:4576"

Kmail simply shows the message as text/plain ignoring the multipart.
The problematic character is again 'I'. When I change the header, just
lowercasing the 'I's it works.

Content-Type: MULTiPART/MiXED;
 BOUNDARY="8323328-1440130431-1099506467=:4576"

I think the problematic functions are  in kmail/bodypartformatter.cpp,
KMail::BodyPartFormatter::createFor( const char * type, const char *
subtype ) and DwStrcasecmp in mimelib.

    case 'M':
      if ( qstricmp( type, "multipart" ) == 0 )
        return createForMultiPart( subtype );

In Turkish (and some other) locales MULTIPART and multipart are not the
same.

As you can see from the bug reports, my first solution was
straightforward which simply changes the LC_CTYPE locale to C before
the conversion and sets back to system's locale after the conversion.
But in kde-devel mailing list David Faure suggested a better solution,
"a locale-independent kstricmp function."

As this is a problem for all KDE applications we thought we should
place this function in kdelibs. And replace problematic qstricmp with
it in kdepim/kmail.

But as mimelib also has a function called DwStrcasecmp. mimelib doesn't
have a kdelibs dependency, so I've put the kstricmp function in
mimelib/dw_mime.cpp. But maybe all mimelib files should use this?

I've prepared the attached patched for KDE 3.3.1. Tested in 2 machines
and saw that they work fine. Please apply the attached patches as
without these (and the ones proposed in bug reports [1]) kmail's some
of the functionality is simply not useable in some locales.

1.
http://bugs.kde.org/show_bug.cgi?id=91089
http://bugs.kde.org/show_bug.cgi?id=93433

2. http://www.i18nguy.com/unicode/turkish-i18n.html

best regards,
--
Baris Metin
http://www.metin.org

-------------------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kdelibs-3.3.1-kstricmp.patch
Type: text/x-diff
Size: 1346 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20041120/8fefdb73/attachment.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20041120/8fefdb73/attachment.sig>