Yazılım Yerelleştirmesi: Arayüz Metinlerinin Zorlukları

Yazılım yerelleştirme projeleri ilk bakışta kolay görünür. Metinler kısadır, cümleler basittir, toplam kelime sayısı bir sözleşmeden bile azdır. Buna rağmen bu projeler, aynı hacimdeki belge çevirisinden düzenli olarak daha uzun sürer ve daha çok revizyon turu gerektirir.

İçindekiler

Nedeni tek bir cümleyle özetlenebilir: çevirmen metni görür, ürünü görmez. Elindeki dosyada “Kapat”, “Tamam”, “Devam” gibi yüzlerce kısa dize vardır; bunların hangi ekranda, hangi düğmede, hangi cümlenin ortasında kullanıldığı bilgisi çoğu zaman yoktur.

Aşağıda arayüz metinlerinin altı tipik zorluğunu ve bunların nasıl yönetildiğini ele alıyoruz. Amaç, teklif alırken hangi kalemlerin gerçekten gerekli olduğunu görebilmeniz.

Yazılım yerelleştirme neden belge çevirisine benzemez?

Belge çevirisinde metin doğrusaldır. Bir paragrafı anlamadığınızda öncesine ve sonrasına bakarsınız; bağlam metnin kendi içindedir. Arayüz dizelerinde böyle bir süreklilik yoktur. Dosyadaki sıra, ekrandaki sırayı yansıtmaz; genellikle alfabetik ya da kod dosyası sırasına göre dizilmiştir.

İkinci fark, metnin bir alanın içine sığmak zorunda olmasıdır. Belgede cümle uzayabilir, sayfa büyür. Arayüzde düğmenin genişliği sabittir; metin uzarsa ya taşar ya kesilir.

Üçüncü fark tutarlılık baskısıdır. Aynı kavram tüm ürün boyunca aynı kelimeyle karşılanmalıdır. Bir ekranda “Hesap”, diğerinde “Üyelik” yazması kullanıcı için iki farklı şey anlamına gelir. Bu yüzden yazılım projelerinde terim listesi tercih değil zorunluluktur.

Dördüncü fark ise ürünün canlı olmasıdır. Belge bir kez çevrilir ve biter; yazılım her sürümde değişir. Bu nedenle yazılım yerelleştirme bir teslimat değil, tekrarlanan bir döngüdür ve çeviri belleği bu döngünün merkezinde durur.

Bağlamsız dize sorunu

Bağlamsızlık, arayüz çevirisinin en pahalı sorunudur çünkü hatası sessizdir: çeviri dilbilgisi açısından doğrudur, sadece yanlış yerdedir.

Klasik örnek tek kelimelik komutlardır. İngilizce “Order” hem “sipariş” hem “sıralama” demektir. “Book” hem “kitap” hem “rezervasyon yap” anlamına gelir. “Free” hem “ücretsiz” hem “boş” olabilir. Bu kelimeler bir dize listesinde yalnız başına durduğunda çevirmen, tahmin etmek zorunda kalır.

Çözüm karmaşık değildir ama disiplin ister. Her dizeye en az iki satırlık bir açıklama eklenir: bu metin nerede görünüyor ve ne işe yarıyor? Ek olarak ekran görüntüleri paylaşılır. Bu iki uygulama, sonradan yapılacak düzeltme turlarının önemli bölümünü ortadan kaldırır.

Bağlam eksikliğinin ikinci biçimi, aynı kaynak metnin farklı yerlerde farklı çeviri gerektirmesidir. Çeviri araçları aynı dizeyi otomatik olarak tek bir karşılıkla doldurabilir. Bu davranış tutarlılık için yararlıdır, ama iki farklı anlam söz konusuysa hatayı çoğaltır. Bu nedenle tekrarlı dizelerin körü körüne birleştirilmemesi gerekir.

Metin uzunluğu ve arayüz taşması

Çeviri sırasında metin uzunluğu neredeyse hiçbir zaman sabit kalmaz. Diller arasında ifade yoğunluğu farklıdır; aynı anlam bir dilde daha az, başka bir dilde daha çok karakterle kurulur.

Türkçe bu konuda iki yönlü davranır. Sondan eklemeli yapı sayesinde İngilizcede birkaç kelimeyle kurulan bir yapı tek kelimeye inebilir; buna karşılık ek zincirleri uzadığında tek kelimenin kendisi ekranda geniş yer kaplar. Sonuç, öngörülemeyen bir dalgalanmadır: bazı düğmeler boşalır, bazıları taşar.

Bu yüzden tasarım tarafında alınacak önlem sabit genişlikten kaçınmaktır. Düğme ve etiket alanları içeriğe göre esneyebilmeli, metin taştığında satır kaydırma ya da kontrollü kısaltma devreye girmelidir. Sabit genişlik zorunluysa, çevirmene karakter sınırı bilgisinin dize dosyasında verilmesi gerekir.

Karakter sınırı verildiğinde çevirmenin işi değişir: artık çeviri değil, sınır içinde anlam koruma işi yapar. Bu, ayrı bir beceridir ve ücretlendirmede de ayrı değerlendirilir.

Değişkenler, çoğul ve cümle birleştirme

Arayüz metinlerinin bir kısmı sabit değildir; içine çalışma anında veri yerleştirilir. “3 yeni mesajınız var” cümlesindeki sayı bir değişkendir. Bu yapı, çeviride üç ayrı sorun üretir.

Birincisi sıra sorunudur. Değişkenler numarasız yer tutucularla yazıldığında çevirmen sırayı değiştiremez; oysa hedef dilde kelime dizilişi farklı olabilir. Çözüm, isimlendirilmiş yer tutucular kullanmaktır.

İkincisi çoğul sorunudur. Diller çoğul kurallarında ayrışır; bazı dillerde ikiden fazla çoğul biçim vardır. Sayıya bakıp iki metinden birini seçen basit bir kurgu, bu diller için yetersiz kalır. Doğru yaklaşım, çoğul biçimlerini dilden bağımsız bir mekanizmaya devretmektir.

Üçüncüsü ve Türkçe için en kritik olanı cümle birleştirmedir. Kod içinde parçaların yan yana eklenerek cümle kurulması, ekleri kaynak dile göre sabitler. Türkçede ek, kendinden önceki kelimenin ünlüsüne göre değişir; sabit ek kullanan bir kalıp kaçınılmaz olarak bozuk cümle üretir. Bu nedenle tam cümlenin tek dize olarak tutulması, i18n kontrol listesinin ilk maddelerindendir.

Kısayollar, kısaltmalar ve özel karakterler

Masaüstü yazılımlarında menü öğeleri klavye kısayollarıyla birlikte tanımlanır. Kısayol harfi genellikle metnin içinde işaretlenir. Çeviride bu harf hedef dilde bulunmayabilir ya da aynı ekranda iki öğeye aynı harf düşebilir.

Kısayol çakışması, dilsel testte yakalanan tipik bir hatadır ve kaynak dosyada işaretlenmemişse çevirmenin görmesi mümkün değildir. Aynı durum kısaltmalar için de geçerlidir: kaynak dilde yerleşik olan bir kısaltmanın Türkçe karşılığı yoksa, açık yazmak gerekir ve bu da alan sorununa geri döner.

Özel karakterler ise ayrı bir başlıktır. Dize dosyalarında kaçış karakterleri, biçimlendirme etiketleri ve satır sonu işaretleri bulunur. Bunların çeviri sırasında korunması zorunludur; bozulduğunda ürün ya yanlış görünür ya da hata verir. Çeviri araçlarının kalite kontrol modülleri bu tür kayıpları otomatik olarak işaretler.

Terim listesi ve marka dili

Arayüz çevirisinde tutarlılık, doğruluktan daha görünür bir kalite ölçütüdür. Kullanıcı bir kelimenin en isabetli karşılığını bilmez; ama aynı şeyin iki ekranda iki farklı adla anılmasını hemen fark eder.

Bu yüzden proje başlamadan önce bir terim listesi onaylanır. Listede en az üç bilgi bulunur: kaynak terim, onaylanan Türkçe karşılık ve kullanılmayacak alternatifler. Ürün adları, modül adları ve marka terimleri için ayrıca “çevrilmeyecek” işareti konur; aksi hâlde ürün adı cümle içinde çevrilir ve destek ekibi ile kullanıcı aynı şeyden söz ettiğini anlayamaz.

Terim listesinin ikinci işlevi üslup kararlarıdır. Kullanıcıya “siz” mi denecek, komutlar emir kipiyle mi yazılacak, hata mesajları suçlayıcı bir dil mi kullanacak? Bu kararlar tek tek dizelerde değil, kısa bir üslup rehberinde toplanır ve çevirmene projeyle birlikte verilir.

Liste tek seferlik bir belge değildir. Yeni sürümlerde ortaya çıkan terimler eklenir, tartışmalı kararlar güncellenir. Çeviri araçlarının terim veritabanı işlevi tam olarak bunun içindir: onaylanan karşılık, çevirmen o terimi yazarken otomatik olarak önerilir ve kalite kontrol modülü sapmaları işaretler.

Dosya biçimleri ve dilsel test

Dize dosyasının biçimi, projenin ne kadar sorunsuz ilerleyeceğini büyük ölçüde belirler. Aşağıdaki tablo yaygın biçimleri ve pratik sonuçlarını özetler.

Biçim	Tipik kullanım	Bağlam notu taşır mı?
XLIFF	Çeviri araçları arası değişim	Evet, yapının parçası
PO / POT	Açık kaynak, PHP, WordPress	Evet, yorum alanları
JSON / YAML	Web ve mobil uygulamalar	Kısmen, ek alan gerekir
RESX / strings	Masaüstü ve mobil platformlar	Kısmen
Excel / CSV	Ara çözüm	Hayır, elle sütun eklenir

Biçim seçildikten sonra sıra dilsel teste gelir. Bu adım, çevrilmiş dizelerin ürüne yüklenip ekran ekran gözden geçirilmesidir. Belge çevirisinde karşılığı yoktur ve atlandığında hatalar kullanıcıya kalır.

Dilsel testte aranan şeyler bellidir: taşan ya da kesilen metin, yanlış bağlamda kullanılmış kelime, çevrilmemiş dize, bozuk karakter, tutarsız terim ve yanlış biçimlendirilmiş tarih veya tutar. Bulgular kaynak dosyaya geri işlenir; böylece bir sonraki sürümde aynı hata tekrarlanmaz.

Türkiye bağlamı

Türkçe arayüzlerde en sık görülen üç sorun, dilin yapısından doğar. Birincisi ek uyumudur: kullanıcı adı, ürün adı ya da dosya adı gibi değişken içerikler cümleye eklendiğinde, sonrasına gelen ek değişkenin son ünlüsüne göre değişmelidir. Kodda sabitlenmiş ek, kullanıcıya bozuk bir cümle olarak görünür. Pratik çözüm, değişkeni cümle sonuna almak ya da eki gerektirmeyen bir kalıp seçmektir.

İkincisi büyük-küçük harf dönüşümüdür. Türkçede “i” harfinin büyüğü “İ”, “I” harfinin küçüğü “ı”dır. Yerel ayar belirtilmeden yapılan dönüşümlerde “İstanbul” kelimesi bozulur, arama sonuçları eksilir, kullanıcı adı eşleştirmesi başarısız olur. Arayüzde metni tümüyle büyük harfe çeviren stil kurallarının Türkçe için ayrıca sınanması gerekir.

Üçüncüsü klavye ve girdi tarafıdır. Türkçe Q ve F klavye düzenleri, kısayol harflerinin erişilebilirliğini etkiler. Ayrıca kullanıcıların Türkçe harf içermeyen yazımı tercih ettiği alanlar (parola, kullanıcı adı) ile Türkçe harf beklenen alanların doğrulama kurallarının ayrı tanımlanması gerekir.

Bu sizin için ne anlama geliyor?

Yazılımınızı Türkçeleştirecekseniz, projenin başarısı çeviri kalitesinden önce hazırlık kalitesine bağlıdır. Aşağıdaki sıra, gecikmelerin büyük bölümünü baştan önler.

1. Dizeleri yapılı bir biçimde (XLIFF, PO, JSON) dışa aktarın; Excel’i son çare olarak düşünün.
2. Her dizeye ekran adı ve tür bilgisi ekleyin; mümkünse ekran görüntüsü paylaşın.
3. Karakter sınırı olan alanları dosyada işaretleyin.
4. Terim listesini projeden önce onaylayın; ürün adları ve marka terimleri çevrilmeyecekse belirtin.
5. Dilsel test için ayrı bir sürüm ve süre planlayın; teslim tarihini buna göre kurun.
6. Çeviri belleğinin size teslim edilmesini sözleşmeye yazdırın; sonraki sürümlerde maliyeti bu belirler.

Bu altı madde tamamlandığında ilk sürüm sancılı geçse bile ikinci sürüm rutine döner. Ürününüzün dosya biçimini ve ekran sayısını paylaşırsanız kapsamı birlikte çıkarabiliriz; teklif formundan başlayabilir ya da hizmet kapsamlarımıza göz atabilirsiniz.

Sık sorulan sorular

Arayüz metinleri kısa, neden kelime başı fiyat yüksek çıkıyor?

Kısa dizeler birim başına daha fazla karar gerektirir: bağlam araştırması, karakter sınırı kontrolü, terim tutarlılığı ve ekran testi. Ücretlendirme kelime hacmine değil, bu karar yüküne göre şekillenir.

Geliştiricim dizeleri Excel olarak verebilir, sorun olur mu?

Olur ama ideal değildir. Excel bağlam alanı, karakter sınırı ve durum bilgisi taşımaz; geri yüklerken de biçim hatası riski yüksektir. Mümkünse XLIFF, PO veya JSON gibi yapılı bir biçim tercih edin.

Türkçe metin İngilizceden uzun mu olur, kısa mı?

İkisi de olabilir. Sondan eklemeli yapı bazı ifadeleri tek kelimeye indirirken, ek zincirleri başka ifadeleri belirgin biçimde uzatır. Bu yüzden arayüz sabit genişlikli değil, esneyebilir tasarlanmalıdır.

Ekran üzerinde test şart mı?

Kullanıcıya görünen bir üründe evet. Bağlamsız çevrilen dizelerin bir bölümü ancak ekranda görüldüğünde yanlış anlaşıldığı fark edilir; taşma ve kesilme sorunları da yalnızca burada görünür.

Kaynaklar

• Pietrzak, P. & Kornacki, M. (2021). Using CAT Tools in Freelance Translation. Routledge, s. 20–27.
• Esselink, B. (2000). A Practical Guide to Localization. John Benjamins, s. 59–92.
• OASIS, XLIFF Version 2.1 Specification (2018).
• Unicode Consortium, CLDR Plural Rules — dile göre çoğul biçimleri.