[Gelistirici] Pardus teknolojilerindeki katarlar için öneriler

[Necmettin Begiter]

Merhabalar,

Son günlerde yoğun şekilde Pardus'a özgü yazılımların çevirilerine
odaklanma fırsatı buldum. Her ne kadar programların kaynak kodlarıyla
doğrudan uğraşmasam da, insan katarların çevirileriyle uğraşırken
katarların kullanım yerleri hakkında genel bir fikir ediniyor ve
birbirleriyle ilişkili katarları tahmin edebiliyor. Bu birkaç gün
içerisinde bir yandan çevirilerle ilgilenirken bir yandan da
uygulamalarda kullanılan katarların tutarlılığı ile ilgili bazı notlar
da tuttum. Kaynak kodlarımızda belirli kurallar uyguladığımız gibi
katarlarda da (=mesajlarda, iletilerde) belirli maddelerden oluşan bir
tutarlılık kılavuzu işimize yarar diye düşünüyorum. Liste biraz uzun
gelebilir, gereksiz derecede küçük şeylerden bahsettiğini
düşünebilirsiniz, ama bu yazdıklarımın çoğunun temel düzeyde
geçerliliği olan kurallar olması hepimizin işini kolaylaştıracaktır ve
tüm arayüzleri daha tutarlı hale getirecektir. Eleştiri ve
değerlendirmelerinize sunuyorum.

Yeri gelmişken ufak bir feragatname: Verdiğim örnekler sadece
örnektir, kimse programının ya da programcının - kendisininüstüne
alınmasın ;)

1. Programın ya da teknolojinin ismi tüm katarlarda aynı olmalı.
Örneğin, bir yerde Çomar, başka bir yerde COMAR, başka bir yerde CoMar
olmamalı.
2. Belirli kavramlar için belirli karşılıklarımız olmalı. İşin bu
kısmı biraz bana düşüyor, şu anda çevirilerimizde kullanacağımız
karşılıklarla ilgili kendi çapımda bir çalışma yapıyorum, hazır
olduğunda buraya bildireceğim. Fakat çoğu uygulama yazarımız Türkçe'ye
çevirme işini kendisi yaptığı için olsa gerek, programlarımızda kavram
karşılıkları konusunda bir tutarlılık olmadığı göze çarpıyor.
3. Grafik arayüzde çalışacak uygulamalarda etiketleri (label) ve
konsolda çalışan uygulamalarda gruplayıcı ifadeleri mümkün olduğunca
kısa tutun. Örneğin, "Extra dependencies of the selected package(s)
that are also going to be installed" yerine "Additional dependencies"
 ya da "Show Installable Packages - Show Installed Packages - Show
Upgradable Packages" yerine "Not Installed - Installed - Upgradable"
gibi kısa fakat anlaşılır katarlar daha kullanışlı olacaktır, çünkü 1)
Metin ne kadar kısa, okuması / taraması o kadar kolay, 2) Bir süre
sonra o mesaj kullanıcı açısından gereksiz hale geliyor, 3) Tüm
açıklamaları programların içine gömmek programın arayüzünü gereksiz
derecede kalabalıklaştırıyor.
4. Arayüzlerde kısaltma kullanmayın ya da kısaltma kullanacaksanız her
zaman kısaltma kullanın (ki tüm programlarımızda aynı politikayı takip
etmek adına birincisini tercih ederim). Örneğin bir yerde "repo",
başka bir yerde "repository" tutarsız oluyor.
5. Hata mesajları dahil hiçbir yerde "!" kullanmamayı öneriyorum.
Kullanıcıların (ki hepimiz aynı zamanda kullanıcıyız ama biraz daha
farklı bakıyoruz programlara) ünlem işareti görünce çok kötü birşey
olduğunu düşüneceklerini anlayabilirsiniz. Bence "kernel panic"
dışında hiçbir yerde "!" kullanılmamalı.
6. İster grafik ister konsol uygulaması olsun, ekrana basılan öğeleri
aynı hizada tutmak için ek boşluklar (#32) kullanılmamalı. "Kullanıcı
adını girin :" gibi bir katar, özellikle grafik arayüzde gerçekten
garip duruyor.
7. Birden fazla satıra yayılan seçim kutularının (select box) ilişkili
olduğu etiketlerde select, choose ya da pick gibi "seçin"e karşılık
gelen fiiller kullanmayın. O öğe zaten seçim yaptırmak için orada.
Aynı şekilde tek satırlık bir metin kutusunun önüne write ya da input
yazmayın (konsol uygulaması buna bir istisna elbette). Kullanıcıya
"sıfır kilometre kullanıcı" muamelesi yapmaya devam edersek
kullanıcılarımız hep o düzeyde kalır, daha üst düzey olanlar
dağıtımımızı amatör bulur (geçmişte aldığımız bazı eleştirileri
hatırlayınız).
9. Kullanıcıdan girdi beklenen durumlarda "please" kullanmayın.
Abartarak söylüyorum, kullanıcıya yalvarmanın bir anlamı yok (bunu
katarlarda gördüğümü hatırlamıyorum ama not almışım, genel bir kural
olarak not etmiş olayım.)
10. Cümle tamamlayan noktalama işaretlerinden önce boşluk kullanmayın
(?, !, .), "kapatan" noktalama işaretlerinden (]") vb) ve
benzerlerinden önce boşluk kullanmayın, sonra kullanın, açanlardan
önce boşluk bırakın ve sonra bırakmayın (anlatım abuk oldu ama
anladığınıza eminim). Örneğin: "Gerçekten bu öğeyi silmek istiyor
musunuz ?" ve "Dosya açılamadı !" ya da "Dosya bulunamadı .(Erişim
izniniz var mı ?)" kullanımları tutarlılığı bozuyor.
11. Genel bir kural olarak, bir "iş" için kullanılan öğelerde fiil,
diğerlerinde isim [tamlaması] kullanmaya çalışın, metinleri de kısa
tutmaya çalışın. Örneğin "Install Selected Packages" yerine "Install"
gayet yeterli.
12. Mümkün olduğu nispette %s'ler yerine %1 %2 .. kullanın. Aksi
durumda Türkçe çevirileri bazen abuk oluyor.
13. Sadece pencere başlıklarında İlk Harfler Büyük kullanın.
14. Bir yerde "clear" dediğiniz şeye başka bir yerde "clean" demeyin.
15. Mümkün olduğunca öğelere klavye kısayolu atayın. Ya da birine
atadıysanız hepsine atayın ya da hiçbirine atamayın. Örneğin, "&Add
New Repository" - "Remove Repository".
16. Etiketlerin (label) başlarında ve sonlarında gereksiz boşluklar
kullanmayın. O boşluk öğeleri hizalamak için olmamalı, hele grafik
ekranda.
17. Kelimeler arasında iki boşluk kullanmayın. Genel, basit ve
görüntüyü düzenli tutan bir kural.
18. Eğer bir mesaj bir işlemin tamamlandığını gösteriyorsa, o mesajda
"başarılı" - "successfully" demeye gerek yoktur. Aslında başarıyla
tamamlanan işlemleri raporlamak bile çoğu durumda gereksizdir.
19. İletilerde mümkün olduğunca cümle kullanmayın, cümle kullanmak
zorundaysanız da kısa tutun. Özellikle grafik ekranda. Zorunlu
olmadıkça lüzumsuz bir kalabalık oluşturuyor. Örneğin "Currently your
basket is empty." (ki "Your basket is currently empty." daha güzel)
cümlesindeki ilk iki kelime atılabilir ve hiçbirşey kaybedilmiş olmaz.
20. Çok zorunlu olmadıkça cümleleri birden fazla parçaya bölmeyin.
Yolda oluşturulanlar başka tabii. Ama o zaman da o katarlara açıklama
eklemek gerekir.
21. Birbirleriyle aynı grupta olan iletiler birbirleriyle tutarlı
olsun. 12 mesaj varsa ve 10 tanesi cümleyse diğer ikisi de cümle olsun
ve lütfen hepsi noktayla bitsin, çoğu programlarımızda bir sürü yerde
cümle kullanmışız ama büyük çoğunluğu noktayla bitmemiş. Ya da altı
tanesi hata bildiriyor, bunların dört tanesi ünlemle bitiyorsa diğer
ikisi de ünlemle bitsin (bu örnekten çok var).
22. Cümle kullanıyorsanız zamanları ve kipleri ('tense'leri) aynı
olsun, ikisinde "couldn't" kullandıysanız üçüncüsünde "can't"
kullanmayın.
23. Eğer bir katar programda birden fazla kez tekrarlanıyorsa bir kez
yazılması yeterli olmalı. (Özellikle PiSi ActionsAPI'de bu durumu net
olarak görebilirsiniz.)
24. Gömülü kalabilen düğmelerde fiil kullanmayın. Buna verebileceğim
en güzel örnek PM'deki "Show Installable Packages / Show Installed
Packages / Show Upgradable Packages". Web sitelerinde gruplama
amacıyla kullanılan üst sekmelerde, ve menülerdeki işaretlenebilir
öğelerin çoğunda (ki bu konuda KDE'yi hiçbir zaman anlamadım) basılı
kaldıkları için, fiil (gördüğüm kadarıyla) kullanılmaz örneğin.
25. Mümkün ve gerekli olduğunca katarların kullanım yerleriyle ilgili
açıklamalar bulundurun, özellikle tek kelimeden oluşan ifadelerde
programı açmadan o ifadenin nerede olduğunu anlamak zorlaşıyor (ve,
takdir edersiniz, çevirmenden programı açmasını beklememek lazım, hadi
programı açtı diyelim, her ekranı gezmesini beklememek lazım).

İlgisiz bir soru, belki konuşuldu ama ben kaçırdım; programlarımızda
"(c) 2009 TUBITAK/UEKAE" ya da "(C) 2009 TUBITAK/UEKAE" yazıyor,
TÜBİTAK olması gerekmez mi, Türkçe klavyesi olmayanlar sıkıntı
yaşamasın diye mi böyle yazıyoruz?

Necmettin