Fwd: case-convertion problems with locale-dependent functions

Ingo Klöcker kloecker at kde.org
Sat Nov 20 21:31:54 GMT 2004


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.


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

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


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:


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;

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

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.


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

best regards,
Baris Metin

-------------- 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>

More information about the kde-core-devel mailing list