Merhaba,
* Nilgün Belma Bugüner [2005-06-17 15:55:13+0300]
> Şimdi sınamayı olması gerektiği gibi yapmışsınız.
Gorebildigim kadariyla Serdar sizin icin tekrar bir sinama falan
yapmadi, sadece bir onceki iletisinde sunmus oldugu sonuclara
tarafinizdan gelen (ve benim de dogrusu algilamakta gucluk cektigim)
asiri reaksiyonunuza mukabilen nazik bir dille sonuclari tekrar etti.
> Teşekkür ederim. Bu sınama benim savımı doğruluyor.
Nilgun hanim, saviniz "KDE altinda UTF-8 kullanilmasi" ise eger,
kimsenin bu "sav"la ilgili bir degerlendirme yaptigi yok, dolayisiyla
tesekkur edilecek birsey de yok. Benim ve yazdiklarindan kolayca
anladigim sekilde Serdar'in derdi bu degil. Sistem sizin sisteminizdir;
istediginiz dosyayi silin, degistirin, ne yaparsaniz yapin, bu bizi
ilgilendirmez. Ama "bu ayarlar boyle yapilmalidir nokta" derseniz
yanlis buldugumuz taraflari da soylemek durumundayiz.
> KMail tr_TR.ISO-8859-9 yerelinde yanlış dönüşüm
> yaparken, tr_TR.UTF-8 yerelinde doğru dönüşüm
> yapıyor. Bu tamamen KDE'nin yerel ayarı ne olursa
> olsun, UTF-8 kodlama kullanmasından kaynaklanıyor.
> Uygulama yazarları da bu önkabule göre yazılımlarını
> geliştiriyor olmalılar ki, yerelimizi UTF-8
> kodlamayı kullanacak şekilde ayarladığımızda
> yanlış dönüşüm sorunlarıyla karşılaşmıyoruz.
Tekrar ediyorum, meselenin beni ilgilendiren tarafi KMail'in UTF-8
altinda canavar gibi calistigi degil. Kmail ISO yerelinde bir hataya
sahip ve bu hata, belirtileri itibariyla onceki iletilerde yeterince
bahsettigim Turkce "I/ı" tuzagina dusmelerinden kaynaklaniyor. UTF-8
yerelinde bu problemin neden olusmadigi konusunda gayet ihtiyatli bir
dille ifade ettigim tahminlerim var sadece, bu tahminlerin aman aman da
arkasinda olmadigimi her firsatta belirttim.
> Konu dağılmasın diye aşağıdaki iletiden alıntı
> yaparak kafa karışıklığınızı gidermeye çalışacağım.
>
> Bu, yerelin UTF-8 kodlama kullanacak şekilde ayarlandığında
> KMail'in kodlama tercihleri listesi:
>
> > Composer -> Karakter kumesi icerisinde;
> >
> > us-ascii
> > iso-8859-1 <====================
> > utf-8 (locale)
> > utf-8
>
> Dikkat edin yerel tr_TR, kodlama UTF-8 ve I/i dönüşümü *doğru*
> Eğer sizin savınız doğru olsaydı o satırın ıso-8859-1 olması
> gerekmez miydi?
Hayir orada donusum falan kullanilmamis, onceki soyledigim "built-in"
liste lafi dogru. 12 MB'lik kdepim kaynagini da indirttiniz ya bana :-)
[EMAIL PROTECTED]:~/tmp/kdepim-3.3.2/kmail$ grep iso-8859-1 *
configuredialog.cpp: // KCharsets::codecForName("us-ascii")
// returns "iso-8859-1" (cf. Bug #49812)
kmkernel.cpp: cfg->writeEntry("pref-charsets",
"us-ascii,iso-8859-1,locale,utf-8");
kmmsgbase.h: Base64 ("=?iso-8859-1?b?...?=") and quoted-printable */
Bakin asagidaki kod da composer yapilandirmasini hazirlayan islevden alinma:
void ComposerPage::CharsetTab::slotVerifyCharset( QString & charset ) {
...
if ( charset.lower() == QString::fromLatin1("locale") ) {
charset = QString::fromLatin1("%1 (locale)")
.arg( QCString( kmkernel->networkCodec()->mimeName() ).lower() );
return;
}
"%1 locale"deki %1 argumani sistem yereline ait karakter kodlamasindan
lower() ile kucuk harfe donusturulerek aliniyor. Icinde "I" gecen
"ISO-8859-9" ile bu harfi icermeyen "UTF-8" arasindaki farka dikkat
cekerken boyle bir sey kastettim. 'networkCodec' kmail/kmkernel.cpp'de
bir yerlerde ayarlaniyor. Surasi muhtemelen (KMKernel constructor'i):
KMKernel::KMKernel (QObject *parent, const char *name) :
DCOPObject("KMailIface"), QObject(parent, name),
mIdentityManager(0), mConfigureDialog(0),
mContextMenuShown( false )
{
...
if ( QCString(QTextCodec::codecForLocale()->name()).lower() == "eucjp" )
{
...
} else {
netCodec = QTextCodec::codecForLocale();
Problem 'QCString( kmkernel->networkCodec()->mimeName() ).lower()'
satiri civarinda gozukuyor. Tabii sunu bilmiyorum: Composer'in karakter
kumesini gosterirken kullandigi string ile MIME kodlama yaparken
kullandigi karakter kumesi ayni lower() kiskacindan mi geciyor? Bunlari
ayrintili incelemek icin vaktim yok, Baris ve Uludag ekibindeki
arkadaslar bu problem uzerinde calistiklarindan buna yapmama gerek de
yok. :-)
> Özellikle ayırarak yazdım: yerel tr_TR, kodlama UTF-8.
> yerel ile kodlamayı aynı şey gibi düşünmek, UTF-8
> kodlama kullanan yerellerin olmadığı zamanlardan (aslında
> yakın geçmiş) kalma yanlış bir varsayım. Biz pek ala
[...]
Bu tartisma boyunca boyle bir sey diyen olmadi. Ama tr_TR dediginizde
bu bir yerel etiketidir ve ontanimli olarak ISO-8859-9 kodlamali _ISO_
yerelini tanimlar, bunu da gozden kacirmayin:
grep tr_TR /etc/locale.alias
turkish tr_TR.ISO-8859-9
grep ^tr_TR /usr/share/i18n/SUPPORTED
tr_TR.UTF-8 UTF-8
tr_TR ISO-8859-9
> /etc/environment dosyasındaki ayarlara sistemin
> ihtiyacı yok. Hangi karakter kodlamasını kullanırsanız
[...]
Debian BTS'e hata bildirimi yapin o halde.
> /etc/environment dosyanızda yerel ayarları ile ilgili
> satırlardan başka bir şey yok. /etc/profile dosyası
> ise tüm kullanıcılar için öntanımlı yapılanmayı
> içerir. Kullanıcı bunları ~/.profile dosyasında
/etc/profile POSIX uyumlu kabuk programlarinin giris (login) tipinde
ilklendirmelerinde okunan baslangic dosyasidir. Yani (1) O dosyanin
etkin olmasi icin (login) giris tipinde bir kabuk acmaniz gerekir, (2)
Ayarlanan ortam degiskenleri _sadece_ kabuk programi ve onun cocuk
prosesleri tarafindan taninir. Bu kapsama girmeden yasam dongusune
baslayacak _cok sayida_ program, proses ornegi verilebilir. Bir ekran
yoneticisi ile X Window'a girip herhangi bir X programi calistirin,
bakalim o 'profile'deki ayarlar etkin mi?
> değiştirebilir (bu işlemin ingilizcesi: overriding).
> /etc/environment PAM içindir diyorsunuz ama gdm'de
> gidip o dosyaya bakıyor ve yerel ayarınızın ne
> olduğuna bakmaksızın yereli orada yazdığınız gibi
> tr_TR yapıyor. Nerede kaldı sizin ~/.profile dosyasında
> yaptığınız seçim?
Hanimefendi kimsenin bizim urettigimiz ~/.profile dosyasina kalmisligi
yok. 'language-env' paketini kurmus ve betigi calistirmissaniz o betik
brute force bir yontem kullanarak kullanicinin sectigi dilde herhangi
bir problem yasamamasi icin gerekli ayarlari yapmaya _calisir_ (yapar
demiyoruz). Bu bir _hack_dir. language-env paketi benim paketim degil
(gelistiricisi bir Japon arkadas), Debian'da yerellestirme islerini
uhdesinde tutan muthis onemli bir paket de degildir. Paketin varlik
nedenini anlatmak uzun surer, isin icinde Debian Policy'nin de oldugu
bir takim onemli hususlar var. Tomohiro KUBOTA'nun yazdigi Rationale
olmali bir yerlerde, Google'da aratirsaniz cikar.
> Bu iki nedenle /etc/environment dosyasını *silin* diyorum.
cat /etc/hosts.deny:
# /etc/hosts.deny: list of hosts that are _not_ allowed to access the system.
# See the manual pages hosts_access(5), hosts_options(5)
# and /usr/doc/netbase/portmapper.txt.gz
#
# Example: ALL: some.host.name, .some.domain
# ALL EXCEPT in.fingerd: other.host.name, .other.domain
#
# If you're going to protect the portmapper use the name "portmap" for the
# daemon name. Remember that you can only use the keyword "ALL" and IP
# addresses (NOT host or domain names) for the portmapper. See portmap(8)
# and /usr/doc/portmap/portmapper.txt.gz for further information.
#
# The PARANOID wildcard matches any host whose name does not match its
# address. You may wish to enable this to ensure any programs that don't
# validate looked up hostnames still leave understandable logs. In past
# versions of Debian this has been the default.
# ALL: PARANOID
Butunuyle aciklamalardan ibaret bu dosyaya da ihtiyac yok, hadi silelim
onu da.
> İhtiyaç olmadığı gibi sorunlara yol açıyor. Savunduğunuz
> gibi masum bir dosya değil o. Yerel ayarı bir yerde
> tr_TR, başka bir yerde tr_TR.UTF-8 olmaz. Hepsi aynı
> olmalıdır.
Tamam iste hepsi ayni yerde olsun diye o dosya secilmis :-). Butun
ilklendirmeler icin gecerli o tek dosya /etc/profile veya ~/.profile
_olamaz_ (bk. yukaridaki aciklama). Mesele su, bir UN*X kullanicisinin
sistem mesaisi, kimligini dogruladiktan (authentication) sonra baslar.
Bu "yetkilendirme" islemi sistemde calisacak butun sureclerin yasam
dongusune girmeden onceki erken donem dogum asamasidir ve PAM tarafindan
idare edilir (bk. /etc/pam.d/login). Demek ki ne oluyor, PAM'a sadece
yetkilendirme isi degil, gorev yaptigi surenin uygunlugu dikkate
alinarak yerel ayarlari gibi butun sureclerin ortak sekilde ihtiyac
duydugu bilgilerin ilklendirilmesi gorevi de veriliyor. Bu secimi sIk
bulmazsiniz (ki ben boyle dusundugumu bir cok defa ifade ettim) ayri
konu, fakat Debian GNU/Linux'da sistem geneli yerel ayarlari boyle
yapiliyor, ulemanin bir zamanki ittifaki boyle olmus.
> Sistem belgelerini okumuşsanız /etc/environment dosyasının
> atıl olduğu bir yerlerde yazıyor. O kadar çok belge
> okuyorum ki, yerini şu an hatırlamıyorum.
/etc/environment'in tarihcesiyle ilgili birseyler yazmistim zamaninda:
http://lists.debian.org/debian-l10n-turkish/2004/05/msg00024.html
> Bu, /etc/environment dosyasını silmemin 3. sebebi.
Yanlis gerekceler, ama kendi kararinizdir. Fakat bunu tavsiye etmeyin
lutfen.
> Sonuç olarak, ayarlarınızı nasıl yaparsanız yapın,
> KDE kullanmak ve sorun yaşamak istemiyorsanız,
> yereliniz tr_TR.UTF-8 ya da en_US.UTF-8 olmak zorunda.
Bu tartismanin benim icin odagi UTF-8'in tercih edilme gerekliligi
degil, onu bir baska baslik altinda konusuruz. UTF-8'in GNU/Linux'da
cok onemli ve siddetle ihtiyac duydugumuz bir gecis oldugunun
suurundayim, ama Red Hat'in yaptigi gibi oyle pata kute bir gecise de
karsiyim. Ben cok basit olarak Kmail'de de var olan "I/i" hatasi
etrafinda laf ediyorum, ve bu, kullanilan kodlamadan _bagimsiz_ bir
hata.
Sevgilerimle,
--
roktas
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
