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
--
roktas
Attachment:
signature.asc
Description: Digital signature