Uluslararasılaştırma i18n Nedir, Neden Önce Yapılır?

Yerelleştirme bütçesini beklenmedik biçimde şişiren kalem çoğu zaman çeviri değildir. Ürünün çeviriye hazır olmamasıdır. Uluslararasılaştırma i18n kısaltmasıyla anılan çalışma, tam olarak bu hazırlığın adıdır.

İçindekiler

Tanım basittir: uluslararasılaştırma, bir ürünü kaynak kodunu değiştirmeden herhangi bir dile ve yerel ayara uyarlanabilir hâle getirmektir. Dilden bağımsız bir mühendislik işidir. Yerelleştirme ise bu hazır altyapının belirli bir pazar için doldurulmasıdır.

Sıra önemlidir ve tersine çevrilemez. i18n yapılmamış bir üründe çeviri, kodun içinden metin ayıklamaya dönüşür; her sürümde yeniden yapılır ve her seferinde yeni hata üretir.

Uluslararasılaştırma i18n neyi kapsar?

Kapsamı dört başlıkta toplamak mümkündür: metnin koddan ayrılması, karakter kodlamasının doğru seçilmesi, biçimlendirmenin yerel ayara devredilmesi ve arayüzün değişken metin uzunluğuna dayanacak şekilde tasarlanması.

Bunların hiçbiri dil bilgisi gerektirmez. Hepsi ürün henüz tek dilliyken yapılabilir; hatta en ucuz yapıldıkları an odur. Ürün büyüdükçe aynı işin maliyeti doğrusal değil, dosya sayısıyla birlikte artar.

Kısaltma da buradan gelir: “internationalization” kelimesinin ilk ve son harfi arasında 18 harf vardır. Aynı mantıkla yerelleştirme l10n, erişilebilirlik a11y biçiminde yazılır. Bu kısaltmalar teklif ve teknik yazışmalarda standart hâle gelmiştir.

Neden çeviriden önce yapılır?

Çünkü çeviri, üründen çıkarılabilen bir metin listesi üzerinde çalışır. Böyle bir liste yoksa çevirmenin önünde metin değil kaynak kod vardır.

Bunun üç somut sonucu olur. Birincisi, çevirmen hangi metnin kullanıcıya göründüğünü kestiremez; kod içi anahtarları, günlük mesajlarını ve kullanıcıya görünen metni ayırt edemez. İkincisi, yanlışlıkla kod bozulabilir; bir tırnak işareti ya da değişken adı çevrilirse ürün çalışmaz. Üçüncüsü, sonraki sürümde aynı işin tamamı tekrarlanır çünkü ortada yeniden kullanılabilir bir dize dosyası yoktur.

Doğru sırada ilerlendiğinde ise çeviri belleği devreye girer ve yalnızca değişen dizeler ücretlendirilir. Sektör ölçümlerinde çeviri işlerinin yaklaşık %40’ının yeniden kullanılabilir olduğu görülmüştür (DePalma 2012); sürümlü ürünlerde bu oranın karşılığı doğrudan bütçedir.

Sıra kuralının bir istisnası yok gibi görünse de pratikte bir ara yol vardır: ürünün tamamı yerine yalnızca kullanıcıya en çok görünen ekranlar uluslararasılaştırılır, geri kalanı sonraki sürüme bırakılır. Bu, bütçeyi bölmek isteyen ekipler için makul bir yaklaşımdır; ancak hangi ekranların kapsamda olduğunun yazılı olması gerekir, aksi hâlde eksik çeviri hata olarak raporlanır.

Sabit kodlanmış metin: en pahalı hata

Sabit kodlanmış (hard-coded) metin, kullanıcıya görünen bir yazının doğrudan kodun içine yazılmasıdır. Tek başına zararsız görünür; ürün tek dilliyken hiçbir sorun çıkarmaz.

Sorun ikinci dilde başlar. Bu metinler dışa aktarma araçlarına görünmez; çeviri paketinde yer almaz; ürün Türkçeye çevrildiğinde ekranın ortasında İngilizce bir uyarı olarak kalır. Genellikle en geç fark edilenler de bunlardır: hata mesajları, doğrulama uyarıları, boş liste metinleri ve e-posta şablonları.

Çözüm, tüm kullanıcıya görünen metinlerin kaynak dosyalarına taşınmasıdır. Her metnin bir anahtarı olur, kod anahtarı çağırır, dil dosyası karşılığını verir. Bu yapı kurulduktan sonra yeni dil eklemek yeni dosya eklemekten ibarettir.

Dize dosyaları ve bağlam: çevirmen neyi görür?

Uluslararasılaştırılmış bir üründe çeviriye giden şey ekran değil, bir dize listesidir. Çevirmen listeyi görür, ekranı görmez. Bu, yazılım çevirisinin en temel kısıtıdır ve bağlam notlarının neden zorunlu olduğunu açıklar.

Tek kelimelik dizeler bu kısıtın en keskin örneğidir. İngilizce “Open” kelimesi bir düğmenin üzerinde “Aç”, bir durum etiketinde “Açık” demektir. Not yoksa çevirmen ikisinden birini seçmek zorunda kalır ve yarı yarıya hata olasılığı doğar. Aynı sorun “Save”, “Order”, “Book” gibi hem ad hem eylem olabilen kelimelerin tamamında tekrarlanır.

İyi hazırlanmış bir dize dosyası her anahtar için üç bilgi taşır: metnin geçtiği ekran, dizenin türü (düğme, başlık, hata mesajı, yardım metni) ve varsa karakter sınırı. Bu üç bilgi revizyon turlarının sayısını doğrudan düşürür. Sektörün yaygın değişim biçimi olan XLIFF, not ve bağlam alanlarını dosyanın kendi yapısında taşır; böylece bilgi araçtan araca geçerken kaybolmaz.

Ekran görüntüsü paylaşmak da düşük maliyetli bir çözümdür. Çeviri paketine ekranların anlık görüntülerini eklemek, uzun bağlam notlarının yerini büyük ölçüde tutar ve hazırlaması dakikalar sürer.

Kodlama, sıralama ve Türkçe harfler

Karakter kodlaması, i18n çalışmasının en teknik ama en kolay çözülen kısmıdır. Kural tektir: uçtan uca UTF-8. Veritabanı, uygulama, dosya okuma, HTTP başlıkları ve e-posta gönderimi aynı kodlamayı kullanmalıdır.

Zincirin bir halkası eski bir kodlamada kalırsa Türkçe harfler bozuk karakterlere dönüşür. Bu tür bozulmaların büyük bölümü verinin kendisini kalıcı olarak bozar; sonradan düzeltmek genellikle veri onarımı gerektirir. Türkiye’de uzun yıllar kullanılan ISO-8859-9 gibi eski kodlamalardan devralınan veritabanları bu sorunun en sık kaynağıdır.

Kodlamanın yalnızca ekranı değil dosya alışverişini de etkilediğini unutmamak gerekir. Dize dosyaları çeviri aracına aktarılırken yanlış kodlamayla açılırsa hata çeviri sırasında değil, dosya geri yüklenirken ortaya çıkar. Bu yüzden ilk aktarımda küçük bir örnek dosyayla deneme yapmak, tüm paketi göndermekten daha güvenlidir.

İkinci konu sıralama ve karşılaştırmadır. Türkçe alfabede harf sırası İngilizceden farklıdır ve büyük-küçük harf dönüşümü özeldir: “i” harfinin büyüğü noktalı “İ”, “I” harfinin küçüğü noktasız “ı”dır. Yerel ayar belirtilmeden yapılan dönüşümler arama sonuçlarını, kullanıcı adı eşleştirmesini ve sıralamayı sessizce bozar.

i18n teknik kontrol listesi

Aşağıdaki liste, geliştirme ekibine verilebilecek asgari kontrol setidir. Maddeler tamamlanmadan çeviri başlatmak, ilerleyen adımlarda geri dönüş üretir.

Kullanıcıya görünen tüm metinleri kaynak dosyalarına taşıyın; kodda metin bırakmayın.
Tüm katmanlarda UTF-8 kullanın ve veritabanı harmanlama ayarını doğrulayın.
Cümleleri kod içinde parça parça birleştirmeyin; tam cümleyi tek dize olarak tutun.
Değişkenleri isimlendirilmiş yer tutucularla kullanın, sıra bağımlılığından kaçının.
Tarih, saat, sayı ve para birimi biçimlerini yerel ayar kütüphanesine devredin.
Çoğul kurallarını dilden bağımsız bir mekanizmayla yönetin.
Arayüzde sabit genişlik kullanmayın; metin uzadığında taşmayan yerleşim kurun.
Her dizeye çevirmen için bağlam notu ve ekran bilgisi ekleyin.

i18n eksikse maliyet nereden çıkar?

Eksik uluslararasılaştırmanın faturası çeviri satırında görünmez; başka kalemlere dağılır. Aşağıdaki tablo, en sık karşılaşılan eksiklikleri ve bunların hangi kaleme yazıldığını özetler.

Eksiklik	Görünen belirti	Maliyetin çıktığı kalem
Sabit kodlanmış metin	Ekranda çevrilmemiş yazı	Geliştirme + ek düzeltme turu
Cümle birleştirme	Bozuk ek ve devrik cümle	Yeniden çeviri + test
Eksik bağlam notu	Yanlış anlamda çeviri	Revizyon + gecikme
Sabit genişlikli arayüz	Taşan veya kesilen metin	Tasarım düzeltmesi
Karışık kodlama	Bozuk Türkçe karakter	Veri onarımı

Tablonun sağ sütunu, i18n’in neden bir çeviri kalemi değil bir mühendislik yatırımı olduğunu gösterir. Bu yatırım bir kez yapılır; her yeni dilde tekrar amortismana girmez.

Maliyetin görünmeyen ikinci bileşeni zamandır. Yukarıdaki eksikliklerin çoğu, ürün yayına çok yaklaştığında fark edilir; düzeltme ise geliştirme ekibinin sırasına girer. Yerelleştirme takvimini bozan şey genellikle çeviri süresi değil, bu düzeltmelerin beklenmesidir.

Türkiye bağlamı

Türkçe, uluslararasılaştırma eksikliklerini ortalama bir dile göre daha hızlı görünür kılar. Sondan eklemeli yapı nedeniyle bir ismin aldığı ek, kendinden önceki ünlüye göre değişir. Kodda “%s için” biçiminde kurulan bir kalıp, yer tutucuya gelen kelimeye göre “için” değil bazen başka bir ek gerektirir; İngilizcede sorunsuz çalışan birleştirme mantığı Türkçede bozuk cümle üretir.

Bu nedenle Türkçe hedef dillerden biriyse, cümle birleştirme yasağı kontrol listesinin en kritik maddesidir. Çözüm genellikle kalıbı parçalamak yerine tam cümlelerin ayrı dizeler olarak tutulmasıdır; gerektiğinde aynı anlam için birden fazla varyant tanımlanır.

Yerel ayar tarafında ise Türkiye için tarih gg.aa.yyyy, ondalık ayırıcı virgül, binlik ayırıcı nokta ve para birimi simgesi tutardan sonra gelir. Kamu ile entegre çalışan ürünlerde ayrıca T.C. kimlik numarası, vergi kimlik numarası ve IBAN alanlarının biçim doğrulaması yerel kurala göre tanımlanmalıdır.

Bu sizin için ne anlama geliyor?

Çeviri satın alan taraf için buradaki pratik sonuç nettir: teklif almadan önce ürününüzün i18n durumunu bilmelisiniz. Bilmiyorsanız aldığınız teklif gerçekçi olmayacaktır.

Geliştiricinize tek soru sorun: “Kullanıcıya görünen metinlerin tamamını tek dosyada dışa aktarabiliyor musunuz?”
Cevap evetse dosya biçimini öğrenin ve teklif isterken belirtin.
Cevap hayırsa önce i18n çalışması planlayın; çeviriyi bekletmek daha ucuzdur.
Dize dosyalarına bağlam notu eklenmesini iş tanımına yazın.
İlk dili pilot olarak seçin, kontrol listesini o dilde doğrulayın, sonra diğerlerini açın.

Bu sıralamayı izleyen ekiplerde ikinci ve üçüncü dilin maliyeti belirgin biçimde düşer, çünkü tekrarlanan iş ortadan kalkar. Ürününüzün mevcut durumunu birlikte değerlendirmemizi isterseniz bize yazın; dosya biçimi ve kapsam konusunda ne gerektiğini hizmet sayfamızda da bulabilirsiniz.

Sık sorulan sorular

Uluslararasılaştırma ile yerelleştirme aynı şey mi?

Hayır. Uluslararasılaştırma, ürünü herhangi bir dile uyarlanabilir hâle getiren teknik hazırlıktır ve dilden bağımsızdır. Yerelleştirme, hazır ürünün belirli bir pazara uyarlanmasıdır. Biri altyapı, diğeri uygulamadır.

i18n yapılmamış bir ürünü yine de çevirtebilir miyim?

Çevirtebilirsiniz ama metinler koda gömülü olduğu için her dize elle bulunup değiştirilir. Bu, sonraki her güncellemede tekrarlanan bir maliyettir ve hata oranı yüksektir.

Türkçe için özel olarak nelere dikkat edilmeli?

UTF-8 kodlama, Türkçe harflerin sıralama ve arama davranışı, noktalı-noktasız i ayrımını gözeten büyük-küçük harf dönüşümü, esneyebilen arayüz genişlikleri ve gg.aa.yyyy tarih biçimi.

i18n çalışmasını kim yapar?

Geliştirme ekibi yapar. Çeviri sağlayıcısı genellikle denetim listesi verir, dosya biçimlerini belirler ve sonuçta çıkan dize dosyalarını doğrular; kodu kendisi değiştirmez.

Kaynaklar

Pietrzak, P. & Kornacki, M. (2021). Using CAT Tools in Freelance Translation. Routledge, s. 14–19.
Esselink, B. (2000). A Practical Guide to Localization. John Benjamins, s. 25–40.
W3C Internationalization Working Group, Internationalization Best Practices.
Unicode Consortium, Common Locale Data Repository (CLDR) — dil ve yerel ayar verileri.
DePalma, D. (2012). Translation Productivity Benchmarks. Common Sense Advisory (2012 verisi).