Version: 1.7.1 (using KDE KDE 3.3.1) Installed from: Unspecified Linux Compiler: gcc (GCC) 3.3.4 OS: Linux In Turkish (and some other like Azeri latin) 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 );
I've filled two bugs (91089 and 93433) concerning the case-conversion problems in Turkish locales before. 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 (http://www.i18nguy.com/unicode/turkish-i18n.html) describing the situation better than I do. 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.
Created attachment 8391 [details] locale-independent kstricmp function for kdelibs patch adds a new funtion to kdelibs (3.3.1)
Created attachment 8392 [details] kdepim patch for kstricmp kdepim patch for using kstricmp.
confirming.
Ingo suggested to rename it to kasciistricmp - and I think this makes sense. Can you rename it in your patches? I'll then apply them. Thanks.
Great. Renamed the function and ported to CVS. I've prepared the mimelib as a separate patch and instead of coping kasciistricmp to dw_mime.cpp, added a new dw_strasciicasecmp function and modified DwStrcasecmp() to use that. I think this is a better way.
Created attachment 8398 [details] locale-independent kasciistricmp function for kdelibs
Created attachment 8399 [details] kmail patch for kasciistricmp
Created attachment 8400 [details] mimelib dw_strasciicasecmp patch
We must also solve bug #91089 for kmail to work and bug #93433 for konqueror to work properly in these locales (tr_TR, tr_TR.UTF-8, az_AZ).
CVS commit by faure: Provide an implementation of kasciistricmp in kdepim, in case CVS-HEAD kdelibs isn't used. CCBUG: 93770 A kasciistricmp.cpp 1.1 [LGPL] A kasciistricmp.h 1.1 [LGPL] M +1 -1 Makefile.am 1.6 --- kdepim/libemailfunctions/Makefile.am #1.5:1.6 @@ -2,5 +2,5 @@ noinst_LTLIBRARIES = libemailfunctions.la -libemailfunctions_la_SOURCES = email.cpp idmapper.cpp +libemailfunctions_la_SOURCES = email.cpp idmapper.cpp kasciistricmp.cpp libemailfunctions_la_LDFLAGS = $(all_libraries) -no-undefined ## Since this is a noinst library, in case of --enable-closure we need
Both mimelib and kmail/bodypartformatter.cpp seem fixed. Closing, please re-open if current cvs still makes trouble in this regard.
Yes, this one is fixed.