Re: Kdepim ve Turkce sorunlari hakkinda -- uzunca ileti
Selam,
Yani özetle, yerel tr_TR.UTF-8 olduğunda, IMAP heapları
kullanmayan kullanıcılar açısından Kmail'de sorun yok.
O kadar ki, tr_TR yerelini kullananlara da bu çözümü
öneriyorsunuz.
Ben de aksini iddia etmedim. Ben hiç IMAP kullanmadım.
IMAP ile ilgili sorunun varlığı ya da yokluğu hakkında da
hiçbir şey yazmadım. Ama bir IMAP sunucusu gösterirseniz
onu da denerim. ISO-8859-9 için sorun çıkmadığına göre
onda da sorun çıkmaması lazım, ancak denemek isterim.
Esen kalın,
Nilgün
Çar 22 Haz 2005 23:49 sularında, Recai Oktas şunları yazmıştı:
> Herkese merhaba,
>
> Bundan bir sure once kdepim suitindeki programlarin Turkce hatalariyla
> ilgili bazi degerlendirmelerde bulunmustuk.[1] Turkce yerel altinda
> Debian Sarge'da (kararli surumde) KDE'yi tercih eden butun kullanicilari
> ilgilendirmesinden ve biraz da konunun yanlis kanaatlerin olusmasina
> hizmet edecek yonlere gitmesinden dolayi bir bilgilendirme yapmam uygun
> olur. Turkce konusan/yazan her kullanicinin bu konulardan haberdar
> olmasinda yarar var. Once bu problemlerle ilgili gecici cozumleri de
> iceren kisa bir ozet yapayim. Problemler (baslicalari):
>
> * Surum < 3.4.1: Debian Sarge'daki surum 3.3.2, ontanimli yerel tr_TR.
> Ontanimli yapilandirmayla kararli surumu takip eden butun kullanicilar
> bu problemlerden etkileniyor.
>
> + tr_TR yereli
> 1. Kmail IMAP sunucularina baglanamiyor (paket: kdepim-kio-plugins).
> (Hatayi daha acik halde gormek icin bir IMAP hesabi olusturup, bu
> hesaba ait guvenlik sekmesinden "Sunucunun neyi destekledigini
> kontrol et" butonuna tiklayin.) Nedeni: "IMAP" "imap" kucuk /
> buyuk harf duyarsiz karsilastirmasi basarisiz.
>
> Gecici cozum secenekleri: Turkce yerel yapilandirmasinda mevcut
> degil.
>
> 2. Kmail'la gonderilen ve Turkce karakter iceren postalarda Mime
> kodlama dogru sekilde yapilamiyor. Postalarin konu basliklari
> bozuluyor. Aralarinda Debian listelerinin de oldugu bazi
> sunucular bu postalari kabul etmiyor. Nedeni: "ISO-8859-9"
> karakter kumesi taniminin yanlis bir yaklasimla yerel altinda
> kucuk harfe donusturulmesi ve bu sozcugun "ıso-8859-9" halini
> almasi.
>
> Gecici cozum secenekleri (Serdar Aytekin'den alinti):
> - Kmail karakter kumesi yapilandirma ekraninda hatali olan kume
> taniminin elle duzeltilmesi.
> - Hatali olan yereli silip ("Xso-8859-9") bunun yerine "iso-8859-9"
> olarak yeni bir karakter kumesi girilmesi.
> - Asagida bahsedilen yamalanmis Debian paketlerinin kurulmasi
> (guvenlik guncellemesi veya herhangi bir garanti vadedilmiyor.)
> - ISO yereli yerine tr_TR.UTF-8 yereli kullanilmasi (fakat bk. ilk
> sorun)
>
> + tr_TR.UTF-8 yereli
> 1. tr_TR yereli problem (1) (3.3.2'de testlerinden genelleme).
>
> Gecici cozum secenekleri: Turkce yerel yapilandirmasinda mevcut
> degil.
>
> * Surum = 3.4.1: Bu iletinin yazildigi tarih itibariyla Experimental
> depodaki surum.
>
> + tr_TR yereli
> Surum < 3.4.1 ile ayni.
>
> + tr_TR.UTF-8
> Problem yok.
>
> Bu problemlerin dogasini ilgili yazismalarda kismen aciklamistim.
> Sorunu cozen iki farkli yama hazirladim:
>
> http://kirkambar.net/patches/05_ascii_strings_3.3.2_backport.diff
> http://kirkambar.net/patches/05_ascii_strings_3.4.1_backport.diff
>
> Bunlardan ilki kararli surum 3.3.2, digeri ise bir sure sonra kararsiz
> arsive yuklenecek olan 3.4.1 icin. Ilk yama Baris Metin'in cabalariyla
> 3.4.1'e giren duzeltmeleri de iceriyor. Son yamadaki duzeltmeleri henuz
> ust gelistiriciye iletmedik, Baris'in bu konuyla ilgilenecegini tahmin
> ediyorum.
>
> Yukarida verdigim yamalarla hazirlanan paketleri kisa bir sure icinde
> hizmete girecegini umdugum debian-tr arsivine yukleyecegim. Dileyenler
> (duyurusu yapildiktan sonra) paket arsivinden guncelleme yapabilirler.
>
> Kissadan hisse, bazi onemli sonuclari aktarmak isterim:
>
> * Mesele bazilarinin iddia ettigi gibi KDE'nin UTF-8'i sevmesi ve ISO
> yerelinde muzmin tepkiler vermesi degil. Kmail (< 3.4.1)'in (1) nolu
> IMAP hastaligi UTF-8 yerelinde de *mevcut*. Diger problem ise, _bir
> yonuyle_, tahminimde ifade ettigim, "UCS (Universal Character Set)
> Transformation Format 8" kisaltmasina karsi dusen "UTF-8" sozcugunde
> "I" harfinin bulunmamasindan ve asagida acikladigim QCString::lower
> metodunun beklenen sekilde davranmamasindan kaynaklaniyor. Yani bu
> kodlamanin ismi, akla gelen makul bir ihtimal olarak, "International
> Character Set ..."e karsilik "ITF-8" olsaydi _ve_ QCString::lower
> beklenildigi gibi calissaydi benzer sorunlar yasayacaktik! :-)
>
> * Peki (1) nolu problem 3.4.1 surumunde UTF-8 yerelinde olusmuyor da ISO
> yerelinde neden ortaya cikiyor? Bu durumda "KDE UTF-8 ister" mi
> diyecegiz? Asagida acikladigim gibi boyle bir yargi filin hortumunu
> hissetmekten hareketle yilan tuttuguna hukmetmektir. Biraz genelleme
> yaparak, UTF-8'de calisan programlarin ISO kodlamasinda cuvallamasi
> ikircikliginin (Glibc'ye kadar uzanan) temel nedenini irdeleyecegim:
>
> QT kitapliginda iki tip karakter dizisi (string) sinifi var: QString
> ve QCString. Bu siniflara ait metodlarin yerel altindaki davranisi
> QT API belgelerinde aciklanmis ama ben kestirmeden Lars Knol'dan
> alinti yapayim (kendisi QT esrafindan oluyor):
>
> From: Lars Knoll <lars@xxxxxxxxxxxxx>
>
> > QString::lower() and friends in Qt3 are locale-dependant.
>
> They never were. Why do you think they are?
> [...]
> I agree that QCString is locale dependent (which is probably a mistake).
>
> Yani "ISO-8859-9" gibi 'I' iceren anahtar kelimelerde QCString::lower
> metodunu kullanmissaniz yandiniz, cunku bu metodun resmi (belgelenen)
> davranisi 'I'yi 'ı'ya cevirmek! Ama QCString beklenen bu davranisi
> ISO yerelinde sergilerken, UTF-8 yerelinde farkli davraniyor. Cunku
> QCString '\0'la sonlandirilmis bir byte'lik C tipi karakter dizilerini
> idare etmek icin tasarlanmis Unicode duyarsiz bir sinif ve isaret
> ettigim bu "tutarsizlik"in kokeni (tolower uzerinden) Glibc'ye kadar
> iniyor. Bazi test sonuclari:
>
> QCString server_response("CAPABILITY IMAP4REV1 LOGIN-REFERRALS");
>
> setlocale(LC_ALL, "");
> cout << server_response.lower().data()
>
> tr_TR'de sonuc: "capabılıty ımap4rev1 logın-referrals"
> ^^^
> tr_TR.UTF-8'de sonuc: "capabIlIty Imap4rev1 logIn-referrals"
> ^^^
>
> Sonuc: QCString yerel bagimli donusumleri UTF-8 ve ISO kodlamalarinda
> farkli yapiyor! ISO'da her karakter bir byte ve donusturulen karakter
> de bir byte, UTF-8'de ise 'I' kucultuldugunde elde edeceginiz karakter
> 'ı' artik bir byte'la temsil edilemiyor ve (saniyorum bilincli olarak,
> zira burada bir "tasma" var) donusturulmeden birakiliyor. Yani UTF-8
> altinda calisan programin ISO kodlamasinda cuvallamasi ikircikliginin
> temel nedeni Glibc'de de ornegini gordugumuz durum. Bu tutarsizliktan
> dogan (veya hasbel-kader dogmayan, fakat gelecekte bir gun dogacak)
> cok sorun var. Once kendimizden baslayarak, gelistiricileri bu
> inceliklerden haberdar etmek durumundayiz.
>
> Turkce'nin "I/i" talihsizligi tum zamanlarin en irkci tasinabilirlik
> sorunlarindan birini olusturuyor. :-) UTF-8 Turkce'nin bu problemine
> cozum sunmaz, birtakim sonuclara (olgulara) bakarak boyle birseye
> hukmetmek dogru degil. QT ornegiyle anlattigim ve cok ilginc buldugum
> ISO/UTF-8 farkliliginda oldugu gibi, problemler bir kodlamada kaybolmus
> gibi gorunuyorsa da, bu (onceden planlanmayan) hasbelkader bir durumdur.
>
> [1] http://lists.debian.org/debian-user-turkish/2005/06/msg00608.html
>
Reply to: