Kod ve Kaynak Ayrımı: Yazılımda Metin Neden Ayrı Dosyada Durur?

Bir programın ekranında okuduğunuz her menü başlığı, her uyarı ve her hata mesajı aslında iki ayrı yerde yaşar. Bir yanda programı çalıştıran kod vardır, diğer yanda o metnin saklandığı kaynak dosyası. Kod ve kaynak ayrımı, yazılım yerelleştirmesinin üzerine kurulduğu temel mimari karardır.

İçindekiler

Bu ayrım olmasaydı her dil için ayrı bir program derlemek gerekirdi. Ayrım sayesinde tek bir kod tabanı, çalışma anında doğru dildeki metni dışarıdan çağırır. Çevirmen kodun mantığına dokunmaz; yalnızca dizelerin bulunduğu dosyayla çalışır. Sektörün iş bölümü de büyük ölçüde bu sınırdan doğar.

Aşağıda ayrımın nasıl kurulduğunu, dize kimliklerinin ne işe yaradığını, ayrım bozulduğunda hangi hataların ortaya çıktığını ve açık kaynak yazılımda tablonun nasıl değiştiğini anlatıyoruz.

Yazılım yalnızca koddan ibaret değildir

Yazılım denince akla önce kod gelir. Oysa yaygın tanımlar yazılımı, bir bilgisayar sisteminin çalışmasıyla ilgili programlar, yordamlar ve rutinlerin tamamı olarak tarif eder. Sommerville bir adım daha ileri gider: programların doğru çalışması için gereken bütün belgeler ve yapılandırma verileri de yazılımın parçasıdır (Sommerville 2010).

Bu geniş tanım, yerelleştirme açısından önemlidir. Mevcut tanımları tarayan bir çalışmada yazılımın bileşen listesi epeyce uzar: görseller, videolar, ses dosyaları, yapılandırma dosyaları, veritabanları, yazı tipleri, işaretleme dosyaları, kullanıcı kılavuzları ve sistem belgeleri. Lisans metinleri, telif uyarıları ve patent bildirimleri de aynı kümededir.

Microsoft bu iki büyük kümeyi “kod bloğu” ve “veri bloğu” diye adlandırır. Yerelleştirme projelerinin neredeyse tamamı veri bloğunda geçer. Çevirmen programın çalışma mantığını değiştirmez; kodun çalışma anında çağıracağı metinleri hazırlar. Bu basit ayrım, kimin neye dokunacağını da belirler.

Kaynak kod ile nesne kodu: derleyicinin iki yakası

Kaynak kod, geliştiricilerin üzerinde çalıştığı ve insanın okuyabildiği koddur. C++, Python, Java, PHP gibi bir programlama dilinde yazılır. Düz metin düzenleyicide, görsel programlama yetenekleri olan bir geliştirme ortamında (IDE) ya da yazılım geliştirme kitleriyle hazırlanabilir. Geliştiricilerin kendilerine ve ekibe bıraktığı açıklama satırlarını da içerir.

Nesne kodu ise kaynak kodun bir derleyiciden geçmesiyle oluşan çalıştırılabilir dosyadır. Bir program satın aldığınızda indirdiğiniz .exe uzantılı dosya bunun tanıdık örneğidir. Kaynak kod bir programlama dilinde yazılırken nesne kodu çoğunlukla makinenin anladığı ikili sayılardan oluşur ve doğrudan okunamaz.

Bu fark test aşamasında görünür hale gelir. Kalite uzmanları kaynak kodla değil, derlenmiş nesne kodla etkileşime girer. Yerelleştirilmiş ürünün çalıştığını ve ekranda göründüğü gibi durduğunu ancak derlenmiş sürümde doğrulayabilirsiniz. Video oyunlarında da benzer bir düzen işler.

Yerelleştirici için önemli olan, iki katmanın hangi sırayla devreye girdiğidir. Çeviri, derleme öncesinde kaynak dosyaları üzerinde yapılır; sonuç ise derleme sonrasında ortaya çıkar. Arada geçen adımlarda oluşan her hata, ancak çalıştırılabilir sürüm elde edildikten sonra görünür hale gelir. Bu yüzden test için zaman ayırmak seçenek değil, zorunluluktur.

Kod ve kaynak ayrımı nasıl kurulur? Uydu derleme mimarisi

Düzgün uluslararasılaştırılmış yazılım, kodu son kullanıcının ekranda gördüğü varlıklardan ayırır. Metinler, görseller ve videolar “kaynak” adı verilen ayrı dosyalarda saklanır. Her yerel ayar için ayrı kaynak kod ve ayrı derlenmiş sürüm tutmak yerine, kod nötr biçimde geliştirilir ve dışarıdaki kaynak dosyalarına dinamik bağlarla bağlanır.

Bu mimariye “uydu derleme” (satellite assembly) denir. Kod, ihtiyaç duyduğu kaynağa benzersiz bir tanımlayıcıyla erişir. Farklı yerel ayar sürümleri varsa, kod hedef yerel ayarın kaynak dosyasından ilgili metni çalışma anında çeker. Böylece yeni bir dil eklemek, yeni bir program yazmak değil, yeni bir kaynak dosyası eklemek anlamına gelir.

Bu düzenin çevirmene sağladığı en büyük kolaylık, kaynak koda hiç dokunmadan çalışabilmektir. Dunne’ın deyişiyle yazılım yerelleştirmesinin asıl emek yükü menü dizelerinin, diyalog kutularının ve dize tablolarının çevirisidir. Yerelleştirme ya da test sırasında bir sorun çıkarsa kodu düzeltmek yazılım mühendisinin işidir.

Mimarinin bir başka faydası bakım tarafındadır. Bir metni düzeltmek için programın yeniden yazılması gerekmez; ilgili kaynak dosyasındaki satır güncellenir ve ürün yeniden derlenir. Aynı düzen, tek bir dilde yapılan üslup değişikliğinin diğer dilleri etkilememesini sağlar. Diller birbirinden bağımsız ilerleyebilir.

Dize kimliği ve varsayılan dile dönüş

Kaynak dosyasındaki her metin dizesinin benzersiz bir kimliği vardır. Bu kimlik bir sayı ya da metinsel bir etiket olabilir. Program çalışırken bir yordam önce kullanıcının yerel ayarını belirler, sonra o yerel ayarın dosyasında bu kimliğe karşılık gelen metni bulur ve ekrana basar.

Kimliğe karşılık gelen metin kullanıcının dilinde bulunamazsa sistem varsayılan dile döner; bu genellikle İngilizcedir. Karma dilli ekranların en sık nedeni budur. Yeni eklenen bir dize henüz çevrilmemişse ya da kimliği değişmişse, kullanıcı Türkçe bir menünün ortasında İngilizce bir satır görür.

Bir .po dosyasındaki tipik kayıt bu mantığı görünür kılar. Kaynak koda gönderme yapan bir yorum satırı, çevrilecek metni tutan msgid ve çeviriyi tutan msgstr yan yana durur. Metnin içindeki %s bir yer tutucudur, \n ise satır sonu oluşturan bir kaçış dizisidir; ikisi de olduğu gibi korunur.

Kimlikler bu nedenle sürümler arasında sabit tutulur. Geliştirici bir etiketi yeniden adlandırdığında, o dizenin geçmiş çevirisi teknik olarak kaybolmuş sayılır ve çeviri belleğinden yeniden eşleştirilmesi gerekir. Küçük görünen bir yeniden adlandırma, çok dilli bir üründe onlarca satırlık ek iş çıkarabilir.

Ayrım bozulduğunda: koda gömülü metin

Her yazılım bu mimariye baştan uygun geliştirilmez. Aceleyle yazılan ya da tek pazar düşünülerek üretilen ürünlerde metin doğrudan kodun içine yazılmış olabilir. Bu durumda dize çıkarma araçları o metni göremez, çeviri paketine girmez ve ekranda kaynak dilde kalır. Düzeltme çeviri değil, geliştirme işidir.

Aynı sorunun daha sinsi biçimi, cümlenin parçalar halinde kodda birleştirilmesidir. İngilizce için doğal görünen bir dizilim, sondan eklemeli ya da farklı söz dizimine sahip dillerde tutmaz. Bu tür sorunlar test aşamasında değil, tasarım aşamasında çözülür.

1. Çeviri paketinde hiç görünmeyen ama ekranda çıkan metinler.
2. Kaynak dilde kalan tek tük düğme ve uyarı yazıları.
3. Bağlamsız, yarım cümle gibi duran dizeler.
4. Tarih, saat ve sayı biçimlerinin dile göre değişmemesi.

Bu belirtileri erken bildirmek işin süresini kısaltır. Yerelleştirme sürecinizi planlarken hizmet kapsamımızı incelemeniz, hangi işin çeviri hangi işin geliştirme olduğunu ayırmanıza yardımcı olur.

Açık kaynak yazılımda kod görünür durumdadır

Ticari yazılımda kod telif korumalıdır ve derlendikten sonra doğrudan erişilemez. Özgür ve açık kaynak yazılımda (FOSS) durum farklıdır. Bu ürünlerde kaynak kod nesne koduyla birlikte yayımlanır; kullanıcılar ve geliştiriciler kodu görebilir, kopyalayabilir ve değiştirebilir. Bu, ticari yazılımla arasındaki en belirgin farktır.

Çevirmen açısından bunun pratik bir karşılığı vardır: bağlam. Belirsiz bir dizenin hangi işlevde çağrıldığını depoda görebilirsiniz. GNU projesi, telif durumuna göre bu yazılımları farklı başlıklar altında sınıflandırır.

Tür	Kullanım	Değiştirme
Açık kaynak yazılım	Serbest	Kaynak kod erişilebilir
Copyleft yazılım	Serbest	Türev ürün aynı koşullara bağlı
Copyleft olmayan	Serbest	Yeni kısıtlar eklenebilir
Shareware	Süreli	Süre sonunda ücret veya abonelik
Özgür yazılım	Serbest	Lisans değiştirmeye izin verir
Freeware	Ücretsiz	Telifli; değiştirilemez, satılamaz

Bu sınıflandırma, gönüllü çeviri topluluklarının hangi ürünlerde oluştuğunu da açıklar. Kaynak kodun açık olduğu projelerde çeviri katkısı genellikle aynı depoda toplanır ve herkes tarafından görülebilir. Ticari üründe ise çeviri kapalı bir tedarik zinciri içinde ilerler; bağlam ancak müşterinin paylaştığı kadar olur.

Türkiye bağlamı

Türkiye’de yazılım geliştiren birçok ekip ürününü önce Türkçe yazar, ihracat kararını sonra verir. Bu sıralama kod ve kaynak ayrımını çoğu zaman gecikmeli bir işe dönüştürür. Metin kodun içine gömülmüşse, ilk ihracat projesinin faturası çeviriden çok yeniden geliştirmeye çıkar.

Türkçenin dil özellikleri bu gecikmenin bedelini artırır. Sondan eklemeli yapı nedeniyle kodda parça parça birleştirilen cümleler Türkçede çoğunlukla bozulur; ekin biçimi kendisinden önceki sesli harfe göre değişir. İngilizce için sorunsuz görünen bir birleştirme mantığı, Türkçe çıktı verirken tutarsız sonuçlar üretir.

Kamuya iş yapan yazılımlarda ek bir katman daha vardır. Erişilebilirlik ve kurumsal kimlik gereklerinin arayüz metinlerine yansıması, dizelerin ayrı dosyada tutulmasını daha da gerekli kılar. Metin ayrı durduğunda, kurum talebiyle gelen terim değişikliği tek dosyada çözülür.

Bu sizin için ne anlama geliyor?

Yazılımınızı çevirtmeye karar verdiğinizde ilk sorulacak soru fiyat değil, mimaridir. Kod ve kaynak ayrımı düzgün kurulmuşsa proje öngörülebilir ilerler. Kurulmamışsa, çeviri bütçesinin yanına bir geliştirme kalemi eklemeniz gerekir. Bu farkı en baştan bilmek, teslim tarihini gerçekçi tutmanın en kolay yoludur.

1. Geliştirme ekibinizden dizelerin hangi dosya biçiminde tutulduğunu yazılı olarak isteyin.
2. Örnek bir kaynak dosyasını çeviri tarafına önceden gönderin; biçim uyumu erken görülsün.
3. Koda gömülü metin taramasını çeviri başlamadan yaptırın.
4. Dize kimliklerinin sürümler arasında sabit kalacağını taahhüt altına alın.
5. İlk teslimden sonra ekran görüntüsüyle görsel kontrol için zaman ayırın.

Bu adımlar ek maliyet gibi görünse de, sonradan yapılacak düzeltmelerin yanında küçük kalır. Elinizdeki dosya biçimini paylaşarak teklif isteyebilir, kapsamı birlikte netleştirebilirsiniz.

Sık sorulan sorular

Çevirmen yazılımın kaynak koduna dokunur mu?

Normalde hayır. Düzgün uluslararasılaştırılmış bir yazılımda çevirmen yalnızca kaynak dosyalarındaki dizelerle çalışır. Kodda değişiklik gerekiyorsa bunu geliştirici yapar.

Dize kimliği değişirse çeviri kaybolur mu?

Çeviri dosyada kalır ama kod artık onu çağıramaz. Kimliği değişen dize çoğu sistemde varsayılan dile, genellikle İngilizceye düşer. Bu yüzden kimlikler sabit tutulur.

Kod ve kaynak ayrımı hangi dosyalarla yapılır?

Ortama göre değişir: .po ve .pot dosyaları, .resx ve .resw kaynak dosyaları, Java için .properties, çerçevelere özgü XML biçimleri ve XLIFF en yaygın olanlardır.

Açık kaynak yazılımda kodu görebilmek çeviriye yarar mı?

Evet, bağlam açısından yarar. Dizenin hangi işlevde çağrıldığını kodda görebilir, belirsiz bir kelimenin menü başlığı mı hata mesajı mı olduğunu anlayabilirsiniz.

Kaynaklar

• Jiménez-Crespo, M. A. (2024). Localization in Translation. Routledge, s. 148–150.
• Sommerville, I. (2010). Software Engineering (9. baskı). Addison-Wesley, s. 5.
• GNU gettext el kitabı, “PO Files” bölümü, gnu.org (çevrimiçi belge).