Kaynak Dosya Çıkarma: Yerelleştirmede Metin Koddan Nasıl Ayrılır?

Yerelleştirme projelerinin çoğu, ilk günkü heyecanını aynı yerde kaybeder: çevirmene gönderilecek dosya bir türlü çıkarılamaz. Metinler kodun içine dağılmıştır, bir kısmı veritabanındadır, bir kısmı görsellerin içine gömülüdür. Kaynak dosya çıkarma tam da bu sorunu ortadan kaldırmak için yapılır.

İçindekiler

Alan yazınında bu işlem “dışsallaştırma” olarak geçer ve kodun yerelleştirilebilir varlıklardan ayrılması anlamına gelir (Jiménez-Crespo 2024, s. 48). Metin, görsel ve video gibi tüm dile bağlı unsurlar ayrı dosyalarda tutulur; kod ise hiçbir dile ait olmayacak biçimde yazılır.

Bu yazıda işlemin ne olduğunu, yapılmadığında hangi maliyetlerin doğduğunu ve çeviri satın alan taraf olarak hangi soruları sormanız gerektiğini anlatıyoruz. Konu teknik görünür, ama sonucunu doğrudan bütçenizde görürsünüz.

Kaynak dosya çıkarma nedir?

Kaynak dosya çıkarma, kullanıcının ekranda gördüğü her ifadeyi programın mantığından ayırmak demektir. “Kaydet”, “Şifreniz en az sekiz karakter olmalı”, “Siparişiniz alındı” gibi ifadeler kodun içinde tırnak içinde durmaz; ayrı bir dosyada bir kimlik numarasıyla eşleşerek saklanır.

Program çalışırken kullanıcının diline göre ilgili dosyayı okur ve metni yerine yerleştirir. Böylece yeni bir dil eklemek, kodu değiştirmeyi değil yeni bir dosya eklemeyi gerektirir. Bu yaklaşım, geliştirme dili dahil bütün diller için aynı biçimde uygulanır.

Uygulamada çıkarma yalnızca metni kapsamaz. Tarih ve saat biçimleri, para birimi gösterimi, sıralama kuralları, ölçü birimleri ve dile bağlı görseller de aynı mantıkla ayrılır. Bunlar kodun içine sabitlendiğinde her yeni pazar ayrı bir geliştirme işi doğurur.

Çıkarma işleminin kalitesi, sonraki bütün aşamaların hızını belirler. Eksiksiz çıkarılmış bir üründe çeviri süreci dosya alışverişine indirgenir; eksik çıkarılmış bir üründe ise her tur yeni mühendislik saati ister.

Uydu derleme: kod nötr, kaynaklar ayrı

Bu mimarinin yerleşik adı uydu derlemedir. Merkezde dilden bağımsız çalışan kod bulunur; çevresinde her dil için ayrı kaynak dosyalar durur ve bunlar çalışma anında merkeze bağlanır (Jiménez-Crespo 2024, s. 48). Yapının görsel karşılığı bir gezegen ve etrafındaki uydulardır.

Bu yapının işletme açısından en önemli sonucu şudur: yeni bir dil eklemek ürünün çekirdeğini riske atmaz. Türkçe sürüme yapılan bir düzeltme İngilizce sürümü bozmaz, çünkü ikisi ayrı dosyalardadır.

İkinci sonuç hızdır. Bir metin hatasını düzeltmek için tüm ürünü yeniden yayına almanız gerekmeyebilir; çoğu durumda ilgili kaynak dosyayı güncellemek yeter. Bu, özellikle mevzuat metinlerinde ve kampanya duyurularında değerli bir esneklik sağlar.

Üçüncü sonuç ölçeklenebilirliktir. Beş dilden yirmi dile çıkmak, mimarisi doğru kurulmuş bir üründe orantılı bir maliyet artışıdır. Mimari yanlışsa aynı geçiş, orantısız biçimde büyüyen bir yeniden yazma projesine dönüşür.

Hangi varlıklar çıkarılır?

Yerelleştirilebilir varlık yalnızca arayüz metni değildir. Aşağıdaki tablo, tipik bir dijital üründe hangi içeriğin nerede tutulduğunu ve çeviri sürecine nasıl girdiğini özetliyor.

Varlık türü	Nerede tutulur	Çeviriye nasıl girer
Arayüz metinleri	Dile göre kaynak dosyalar	Doğrudan, kimlik numarasıyla
Yardım ve destek içeriği	İçerik yönetim sistemi	Bağlayıcı veya dışa aktarım
Yasal metinler	Ayrı belge deposu	Genellikle elle, hukuk onayıyla
Metin içeren görseller	Tasarım dosyaları	Katmanlı özgün dosya üzerinden
Ses ve video	Medya kütüphanesi	Altyazı veya seslendirme akışıyla

Tablodaki son iki satır çoğu projede unutulur. Görsel içindeki yazı, düz bir resim dosyasına dönüştürülmüşse artık çıkarılamaz; her dil için tasarımcının araya girmesi gerekir. Bu yüzden katmanlı özgün dosyaların saklanması ucuz bir sigortadır.

Yasal metinler de ayrı bir dikkat ister. Bunlar çeviriden çok yerel mevzuata göre yeniden yazma işidir ve çıkarma aşamasında ayrı bir küme olarak işaretlenmelidir.

Listeye eklenmesi kolayca unutulan bir grup daha var: kullanıcıya sistem tarafından gönderilen metinler. Sipariş onayı e-postaları, kısa mesajlar, uygulama bildirimleri ve hata kodlarının açıklamaları çoğu zaman ayrı bir yerde tutulduğu için çıkarma listesine hiç girmez. Kullanıcı bunları ürünün parçası olarak gördüğünden, yarım kalan yerelleştirme en çok burada fark edilir.

Çıkarma yapılmazsa ne olur?

Eksik çıkarmanın belirtileri projelerde şaşırtıcı derecede benzer görünür:

1. Yayına alınan sürümde bazı ekranlar hâlâ kaynak dilde kalır.
2. Her küçük metin düzeltmesi yazılım güncellemesi gerektirir.
3. Aynı ifade farklı yerlerde farklı çevrilir, çünkü tek bir listede toplanmamıştır.
4. Kelime sayımı tutmaz; teklif ile fatura arasında fark oluşur.
5. Bir sonraki sürümde işin önemli bölümü baştan yapılır.

Bu belirtilerin ortak sonucu öngörülemezliktir. Maliyet tahmini yapılamaz, teslim tarihi tutmaz ve kalite dalgalanır. Sorun çeviride görünse de kaynağı hazırlık aşamasındadır.

Düzeltmenin de bir maliyeti vardır, ama tek seferliktir. Metinleri kaynak dosyalara taşımak için harcanan mühendislik günü, ikinci veya üçüncü dilde kendini geri öder.

Dosya biçimleri ve değişim standartları

Çıkarılan içerik platforma göre farklı biçimlerde tutulur. Web tarafında JSON ve XML tabanlı yapılar yaygındır; mobil uygulamalarda ise platformun kendi kaynak dosya biçimi kullanılır. Ortak nokta, metnin bir kimlikle eşleşmesi ve kodun dışında durmasıdır.

Bu dosyalar çeviri sürecine girerken çoğu zaman ortak bir değişim biçimine dönüştürülür. Sektörde bu amaçla geliştirilmiş standartlar vardır ve çeviri araçlarının hemen hepsi bunları okur (Jiménez-Crespo 2024, s. 66-67). Standart kullanmak, tedarikçi değiştirdiğinizde içeriğinizin taşınabilir kalmasını sağlar.

Sizin açınızdan kritik soru biçimin adı değildir. “Bu dosyaları başka bir tedarikçiye verirsem açabilir mi?” sorusunun cevabı evet ise mimari sağlıklıdır. Cevap hayır ise bağımlılık oluşmuş demektir.

Aynı mantık çeviri belleği ve terim listesi için de geçerlidir. Bunların da standart biçimlerde dışa aktarılabilmesi, ileride yaşayacağınız geçişleri kolaylaştırır.

Bu işi kim yapar, ne kadar sürer?

Çıkarma işi geliştirme tarafındadır. Küçük projelerde ürünü yazan geliştirici, büyük projelerde ise yerelleştirme mühendisi olarak anılan uzman bu görevi üstlenir. Bu kişi kodu değiştirme yetkisine sahip tek taraftır ve çeviri ekibinin bildirdiği teknik hataları da o düzeltir (Jiménez-Crespo 2024, s. 62-63).

Çeviri bürosunun rolü tespit ve raporlamadır. İyi bir tedarikçi, dosyaları aldığında eksik kalan metinleri, birleştirilmiş cümle kalıplarını ve çevrilmemesi gereken teknik değerleri işaretleyip size geri bildirir. Bu geri bildirim, geliştirici ekip için hazır bir yapılacaklar listesi anlamına gelir.

Süre, ürünün büyüklüğünden çok düzenine bağlıdır. Baştan doğru kurulmuş bir üründe çıkarma birkaç saatlik bir dışa aktarma işidir. Geriye dönük yapılıyorsa iş, ekranların taranmasını ve her metnin tek tek taşınmasını gerektirdiği için günlere yayılabilir.

Bu yüzden çıkarma maliyetini çeviri bütçesinin içinde değil, ürün geliştirme bütçesinin içinde düşünmek daha doğrudur. Bir kez ödenir, her dilde kullanılır.

Çıkarılan metnin bağlam sorunu

Metni koddan ayırmanın bir yan etkisi vardır: çevirmen artık cümleleri bulundukları ekrandan kopuk görür. Tek başına duran “Aç” kelimesi bir düğme mi, bir menü başlığı mı, yoksa bir durum bilgisi mi belli olmaz.

Bu sorun iki yolla çözülür. Birincisi, kaynak dosyalara açıklama notu eklemektir; iyi hazırlanmış dosyalarda her dizenin yanında ne işe yaradığını anlatan kısa bir not bulunur. İkincisi, metni gerçek ekran üzerinde gösteren görsel yerelleştirme araçlarıdır (Jiménez-Crespo 2024, s. 60-61).

Bağlamsız çalışmanın bedeli tahminlerdir. Alan yazınında bu durum, bağlam görmeden yapılan yerelleştirmenin hataya açık bir tahmin işine dönüşmesi olarak tarif edilir. Türkçe gibi ek yapısı bağlama duyarlı bir dilde bu risk daha da büyür.

Pratik çözüm basittir: çıkarma yapılırken açıklama alanlarını boş bırakmayın ve mümkünse ekran görüntülerini kitin içine koyun. Bu, sonradan yapılacak düzeltme turlarının çoğunu ortadan kaldırır.

Türkiye bağlamı

Türkiye’de geliştirilen yazılımların önemli bölümü önce yalnızca Türkçe için tasarlanır. Metinler doğrudan kodun içine yazılır, çünkü başlangıçta ikinci bir dil düşünülmez. İhracat kararı alındığında ise ilk iş çeviri değil, geriye dönük kaynak dosya çıkarma olur.

Türkçenin yapısı bu işi ayrıca zorlaştırır. Sondan eklemeli dilde cümleyi parçalara bölüp çalışma anında birleştirmek çoğu zaman bozuk sonuç verir; “3 ürün eklendi” kalıbı sayıya ve duruma göre farklı ek ister. Bu tür kalıpların baştan tam cümle olarak çıkarılması gerekir.

Kişisel veri içeren ekranlarda çıkarma işlemi bir de uyum boyutu kazanır. Aydınlatma metni ve açık rıza ifadeleri KVKK çerçevesine göre yazılır; bunları arayüz metinleriyle aynı kümede tutmak yerine ayrı bir grup olarak yönetmek daha güvenlidir.

Bu sizin için ne anlama geliyor?

Kaynak dosya çıkarma, çeviri satın almadan önce cevabını bilmeniz gereken bir hazırlık sorusudur. Şu adımlar süreci hızlandırır:

1. Geliştirici ekibinizden ekranda görünen tüm metinlerin listesini tek dosyada isteyin.
2. Listede olmayan ama ekranda görünen ifadeleri işaretleyip düzeltme listesine ekleyin.
3. Metin içeren görsellerin katmanlı özgün dosyalarını arşivleyin.
4. Dosyaların standart biçimde dışa aktarılabildiğini teyit edin.

Hangi dosya biçimleriyle çalıştığımızı ve süreci nasıl kurduğumuzu çeviri hizmetleri sayfamızda anlatıyoruz. Elinizdeki dosyaların çeviriye hazır olup olmadığını kontrol etmemizi isterseniz teklif sayfamızdan örnek bir dosya gönderebilirsiniz.

Sık sorulan sorular

Kaynak dosya çıkarma çeviri bürosunun işi mi?

Hayır, bu iş geliştirme tarafındadır. Çeviri bürosu eksikleri tespit edip rapor edebilir, hatta bazı dosyaları elle ayıklayabilir; ancak metnin kalıcı olarak koddan ayrılması ürün ekibinin sorumluluğudur.

Metin koddan ayrılmamışsa çeviri yapılamaz mı?

Yapılır ama pahalı ve kırılgan olur. Her metin için kod dosyası açılır, her düzeltme yeni bir derleme gerektirir ve bir sonraki sürümde aynı iş baştan tekrarlanır. Tek seferlik küçük işler dışında sürdürülebilir değildir.

Hangi dosya biçimi tercih edilmeli?

Ürünün platformu belirler. Önemli olan biçimin adı değil, çeviri araçlarının o biçimi okuyabilmesi ve kodu koruyabilmesidir. Değişim için XLIFF gibi standartlar yaygın olarak kullanılır.

Görsellerin içindeki yazılar da çıkarılabilir mi?

Doğrudan çıkarılamaz. Bu yüzden metin içeren görsellerin katmanlı özgün dosyaları saklanmalı ya da yazı görselden ayrılıp üzerine metin katmanı olarak konmalıdır. Aksi hâlde her dil için görsel yeniden üretilir.

Kaynaklar

Jiménez-Crespo, M. A. (2024). Localization in Translation. Routledge, s. 47-48, 60-61, 66-67. · Dunne, K. J. (2014). “Localization”. Routledge Handbook of Translation Studies. · OASIS, XLIFF 1.2 belgeleri.

Bu yazı genel bilgilendirme amaçlıdır, hukuki görüş değildir.