Re: konudisi - yeni turk lirasi



Selam,

Pazar 3 Ekim 2004 17:07 sularında, Baris Cicek şunları yazmıştı: 
> Size gercekten inanasim gelmiyor, efsane diye nitelendirmek istiyorum
> artik. Para birimi koymak zorunda degiliz zaten. Ancak sayi gosterirken
> hala yanlista israr etmenin anlami yok. strfmon tabi ki farkli calisacak
> cunku int_decimal_point dogru belirtilmis yani (,). Fakat unutmayin
> cikti alinirken finans ile alakali islevlerin kullanimi printf ya da
> digerlerine kiyasla yok denecek kadar azdir. Bazi diller icin para
> ondalik ayiraci ve sayi ayiraci farkli olabilir (ama Turkce icin degil.
> Yore dosyasinda farkli belirtilmesinin nedeni cesitlilik olsun diye
> degil, zaten farkli oldugu icin. Turk yore dosyasi icin durum da bariz
> bir sekilde hatadir. Insanlar rakamlari neden nokta ile goruntulesinler
Bu konudaki yanıtım bugzilla'da var.
Dikkat ederseniz reddetmedim.

Ancak, yakın geçmişte, listelerde dönen Q türkçe klavyenin kaldırılma denemelerine
verdiğim yanıtı da hatırlarsınız.

Yazılım içinde yereli değiştirmeden ondalık ayraç için istenirse nokta
istenirse virgül kullanmak için bir çözümün olmasının faydası mı var
zararı mı var. Birinde strfmon birinde printf kullanılacak sadece.
Yereli nerede değiştirmiştim diye backtrace'ler yapmak zorunda
kalmayacaksınız. Olayı biraz da yazılım geliştirenler açısından
düşünürseniz, mevcut durumu değiştirmenin pek de akıllıca olmayacağını
görürsünüz.

Ayrıca masaüstü paketlerinde (GNOME, KDE gibi) kullanıcının bu ayraçları
özelleştirme imkanı da var.

Bu nedenle bir kaşık suda fırtına koparıyorsunuz diyorum.

Bu evreye artık yanıt vermeyeceğim.

Esen kalın,
Nilgün



> ki dogru kullanimi mumkun iken? Neyse zaten patch gosterilmis umarim
> commit ederler, senelerden beri var olan yanlislikta duzelir. Etmezlerse
> bir daha bir daha hata bildiriminde bulunuruz sorun degil.
>
> On Sun, 2004-10-03 at 16:48, Nilgün Belma Bugüner wrote:
> > Selam,
> >
> > Bir de strfmon ile deneyin. �zelikle para gösterimleri için daha
> > marifetlidir.
> >
> >
> > Esen kalın,
> > Nilgün
> >
> > Pazar 3 Ekim 2004 13:07 sularında, Baris Cicek Å?unları yazmıÅ?tı:
> > > `man 3 printf`
> > >
> > >        "For  some  numeric  conversions  a radix character (âdecimal
> > > pointâ) or thousandsâ grouping  character  is  used.  The  actual
> > > character  used depends on the LC_NUMERIC part of the locale. The POSIX
> > > locale uses â.â as radix character, and does not have a grouping
> > > character.  Thus,
> > >                    printf("%â.2f", 1234567.89);
> > >        results in â1234567.89â in the POSIX locale,  in
> > > â1234567,89â in  the nl_NL locale, and in â1.234.567,89â in the
> > > da_DK locale."
> > >
> > > Simdi tr_TR locale'i icin demek ki cikti ne imis, "1234567.89". Peki
> > > olmasi gereken ne? Tabi ki "1234567,89". Bu sekilde olmasinin sebebi
> > > peki nedir? LC_NUMERIC'de decimal_point'in <U002D> olmasi yani '.'.
> > > Duzeltmek icin gerekeni de daha onceden soyledim. Umarim yeterli
> > > olmustur 'gerekliligini' anlatmak icin.
> > >
> > > Durumu anlatan kod ekte. Ciktisi da:
> > > $ gcc -o test test.c && ./test
> > > Secili yore en_US, gosterim: $ 1,543,423.75
> > > Secili yore tr_TR, gosterim: 1543423.75 TL
> > > Secili yore fr_FR, gosterim: 1543423,75 EUR
> > > Secili yore da_DK, gosterim: kr 1.543.423,75
> > >
> > >
> > > 'Gereksiz' cikis yaptigim icin de ozur dilerim.
> > >
> > > On Sun, 2004-10-03 at 03:30, Nilg�¼n Belma Bug�¼ner wrote:
> > > > Cumartesi 2 Ekim 2004 23:46 sular�±nda, Y�¼ksel �ZCAN �unlar�± yazm�±�t�±:
> > > > > Selamlar,
> > > > >
> > > > > Bir muhasebeci olarak bir kac ekleme yapmak istiyorum;
> > > > > Yeni turk lirasinin Sembolu YTL ve yeni Kuru$un sembolu de YKr'dir.
> > > > > rakamin yaziyla yazildigi fatura basan programlar icin yaziyla()
> > > > > gibi olan bi fonksiyonun kuru$u da goz onune alarak duzenlenmesi
> > > > > gerekir, Diger bir nokta da glibc'deki sorun, acikcasi bir ondalik
> > > > > ayirac(kuru$ ayiraci) na sahip oldugumuz icin $ansliyiz :) cunku
> > > > > bir "bin (thousand seperator) ayiraci"miz yok. Sembol olayina
> > > > > gelince, bi kac sene sonra
> > > >
> > > > Binlik ayrac�±m�±z var. Siz parasal g�¶sterimi
> > > > kullanm�±yorsunuz anla��±lan. Parasal g�¶sterimi
> > > > kullan�±rsan�±z binlik ayrac�±m�±z oldu�unu
> > > > g�¶r�¼rs�¼n�¼z. Konu ile ilgili adresi dikkatle okursan�±z
> > > > neyi nas�±l
> > > > kullanman�±z gerekti�ini �¶�renebilirsiniz (t�¼rk�§edir):
> > > > http://belgeler.org/glibc/glibc-Locales.html
> > > > Glibc i�§ hesaplamas�±nda ondal�±k ayra�§ olarak nokta
> > > > kullan�±r ve binlik ayra�§ yoktur. Sadece bi�§imli
> > > > �§�±kt�± alma a�amas�±nda yerel g�¶sterim o da siz �¶yle
> > > > isterseniz kullan�±l�±r.
> > > >
> > > > Say�±sal g�¶sterimdeki ondal�±k ayrac�±n virg�¼l m�¼
> > > > nokta m�± olaca��±n�±n bir �¶nemi yok. �nemli olan parasal
> > > > g�¶sterim ki, onda zaten sorun yok; binlik ayra�§ nokta,
> > > > ondal�±k ayra�§ virg�¼ld�¼r. Say�±sal g�¶sterim olarak
> > > > parasal g�¶sterimi se�§mek m�¼mk�¼n oldu�una g�¶re (zaten
> > > > ba�ka �§aresi de yok) say�±sal g�¶sterimin farkl�± olmas�±
> > > > sadece bir �§e�itlilik yarat�±r.
> > > >
> > > > Ayr�±ca glibc'de say�±sal g�¶sterimin nas�±l se�§ilece�i
> > > > de belli de�il. Yani say�±sal g�¶sterim sadece dosyada var,
> > > > �§�±kt�±laman�±n �§aresi yok! Yerel dosyas�±nda, glibc
> > > > i�levleri ile g�¶sterimi m�¼mk�¼n olmayan o kadar �§ok
> > > > tan�±m var ki, bu da onlardan biri. Yani, asl�±nda �¼zerinde
> > > > kopart�±lan f�±rt�±naya de�ecek bir�ey yok ortada.
> > > >
> > > > > "Yeni Turk Lirasi" tanimindaki "Yeni" ibaresi buyuk ihtimalle
> > > > > kaldirilacak, bakanlar kurulu bu yetkiyi kendine vermi$, fakat bu
> > > > > "yeni"
> > > >
> > > > B�¼y�¼k ihtimalle de�il, 2006'da kalkacak. YTL sadece ge�§i�
> > > > a�amas�±nda 1 y�±ll�±��±na ge�§erli. Bu nedenle glibc
> > > > yerelinde deÃ?iÃ?iklik gerekmiyor. Zaten para sembolleri
> > > > uluslaras�± bir standarda g�¶redir (ISO 4217). Glibc yerelinde
> > > > TRL yerine ba�ka bir para birimi gerekiyorsa, �¶nce devletin bu
> > > > standartta gerekli de�i�ikli�i yapt�±rmas�± laz�±m. Birileri
> > > > istedi diye glibc yerelindeki tan�±mlar de�i�mez.
> > > >
> > > > Bunlar�± a�§�±klamak ihtiyac�±n�± duydum �§�¼nk�¼
> > > > glibc tr_TR yerelinde bir deÃ?iÃ?iklik istenirse onlar da bana
> > > > soruyor. Onlar�± kafamdan uydurmad�±m, hemen hepsinin bir
> > > > standard�± ya da ge�§erli bir nedeni var.
> > > >
> > > > > ibaresini kaldirma i$inin 2005 icinde olabilecegini sanmiyorum,
> > > > > cunku 2005'te her iki para birimi birlikte kullanilacak, "Yeni"
> > > > > ibaresinin kalkmasi telafisi mumkun olmayan hatta Merkez Bankasini
> > > > > iflas ettirebilecek duzeyde sorunlara sebep olacaktir, sadece
> > > > > YTL'nin tek basina kullanilmaya baslanacagi donem 01.01.2006'dan
> > > > > itibaren baslayacak, bunu da goz onune alirsak, 1 yilligina
> > > > > glibc'de degisiklik yapilmasi oturup ta dusunulmesi gereken bir
> > > > > mesele. Diger bir konu da muhasebe programlarinin uygulamada
> > > > > karsilasacaklari sorunlar; YTL ile ilgili mevzuat $oyle diyor;
> > > > > en du$uk para birimi 0.01 YTL yani 1 YKr dir; durum boyle olunca
> > > > > bir faturanin en du$uk bedeli en az 1 Yeni Kuru$ olacak demek,
> > > > > diger taraftan halen yurt di$ina yapilan ihracatlarda ve yurt
> > > > > di$indan yapilan ithalatlarda $unu oldukca sIk goruyorum;
> > > >
> > > > Toplamlarda kuru� 2 hane olmak zorunda, sadece d�¶viz
> > > > kurlar�±nda 4 ya da 5 hane olacak ama al�±�veri�lerde
> > > > ondal�±k ayrac�±n sa��±ndaki hane say�±s�± yine 2;
> > > > �§�¼nk�¼ kuru�tan k�¼�§�¼k para yok.
> > > >
> > > > Buradan �§�±kan sonu�§ birim fiyatlarda kuru� hanesi
> > > > kalabal�±k olabilir ama ana toplamda 2 hane olmak zorunda.
> > > >
> > > >
> > > > Esen kal�±n,
> > > > Nilg�¼n
> > > >
> > > > _______________________________________________
> > > > GNOME-Turk ePosta listesi
> > > > GNOME-Turk gnome org
> > > > http://mail.gnome.org/mailman/listinfo/gnome-turk
> >
> > _______________________________________________
> > GNOME-Turk ePosta listesi
> > GNOME-Turk gnome org
> > http://mail.gnome.org/mailman/listinfo/gnome-turk



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]