Uluslararası Arayüzde Lokalizasyon Nerede Kırılır
Çok dilli arayüz, metinleri başka bir dile çevirmekle ortaya çıkmaz. Çeviri işin kolay kısmı; kırılmalar düzende, tarih ve sayı biçimlerinde, sıralama ve arama davranışında, bir de kullanıcının neyi tanıdığında oluyor. Lokalizasyonu metin işi sayan ekip hatayı yayına aldıktan sonra görür, üstelik genellikle kendi konuşmadığı bir dilde.
Çeviri bitince düzen bozulur
Aynı cümle her dilde aynı yeri kaplamaz. İngilizce kısa etiketler Almancada ve Türkçede uzar, buton genişliği sabitse metin ya taşar ya kesilir. Bir projede Almanca dil dosyası yüklendiğinde üst menüdeki üç etiket iki satıra inmişti ve başlık çubuğunun yüksekliği sabit olduğu için alt satır görünmüyordu.
Bunun çözümü çeviriyi kısaltmak değil, düzeni metne göre esnetmektir. Kutulara sabit piksel yerine içeriğe göre büyüyen bir yapı verin, satır kaydırmayı engelleyen kısıtları kaldırın, en uzun çeviriyi referans alarak bakın. Tasarım aşamasında elinizde gerçek çeviri yoksa sahte uzatılmış bir dil dosyasıyla test etmek işi görür: her dizgeyi yapay olarak uzatıp arayüzü açarsınız, taşan yerler ilk ekranda belli olur.
"Evrensel ol" ile "yerel örnek ver" aynı anda olmaz
Uluslararası içerik tavsiyeleri çoğu zaman kendi içinde çelişir: aynı listede hem kültürel referanslardan kaçınmak hem de yerel örnek ve vaka kullanmak önerilir. Bu ikisi birbirini götürür. Kültürel referansı ayıklarsan geriye kimseye ait olmayan, kimseyi ikna etmeyen bir metin kalır.
Tercih açık olmalı. Yerel örnek kazanır, ama tek şartla: o pazar için ayrı içerik üretmeyi göze alıyorsanız. Bütçe buna yetmiyorsa örneği tamamen çıkarın, yerine ürünün kendi ekran görüntüsünü ve sayısını koyun. Tanınmayan bir marka adını bir ülkeden diğerine taşımak, örneği hiç vermemekten daha kötü sonuç verir.
Biçim ve harf işleri koda bakar
Tarihte 03.04.2025 bir ülkede nisan, diğerinde marttır ve kullanıcı hangisi olduğunu anlamak için durur. Ay adını yazın, sorun biter. Ondalık ayırıcı, binlik ayırıcı, para birimi konumu ve telefon alanı da aynı şekilde tarayıcı diline değil, kullanıcının seçtiği bölgeye bağlanmalı.
Form alanlarında en sık yapılan hata ad ve soyadı ayırmaktır. Her ülkede iki parçalı isim yoktur, sıralama da her yerde aynı değildir. Tek bir "tam ad" alanı hem daha az hata üretir hem de daha az doğrulama kodu ister.
Arama ve sıralamada ise Türkçe klasik bir tuzak barındırır. Varsayılan dil ayarıyla yapılan büyük/küçük harf dönüşümü i harfini I yapar, İ yapmaz; bu yüzden "İstanbul" araması "istanbul" kaydını bulamaz. Normalizasyonu açıkça Türkçe kurallarına göre yapmazsanız kullanıcı arayüzde bir arama hatası görür, oysa sorun tasarımda değil iki satırlık bir dönüşüm çağrısındadır.
Pazar olgunluğu yıl cinsinden ölçülmez
Bir ülkenin internet kullanımının başka bir ülkeden üç yıl geride olduğu türü iddialar eski ve ölçülemez. İşinize yarayacak veri kendi kayıtlarınızda duruyor: hangi ülkeden hangi cihazla, hangi bağlantı hızıyla, hangi tarayıcı sürümüyle geliniyor.
Oradan çıkan karar nettir. Belirli bir pazarda trafiğin çoğu düşük bellekli telefonlardan geliyorsa açılış sayfasındaki animasyonu ve büyük görseli o pazar için kapatın, önce içerik gelsin. Yeni bir ülkeye girerken ürünün sade bir sürümüyle başlamak da doğru yaklaşımdır, yeter ki sadeleştirme rastgele değil, o pazarın ölçülen kısıtına göre yapılsın.
Dil bazında ölçmüyorsanız lokalizasyon bir varsayımdır
Lokalizasyon projelerinin çoğu, işe yarayıp yaramadığı hiç bilinmeden tamamlanmış sayılır. Sebep basit: raporlar toplamda bakar, dile göre ayırmaz. Toplam dönüşüm oranı sabit kalırken bir dilde yükselip diğerinde düşmüş olabilir ve bunu göremezsiniz.
En az üç şeyi dil kırılımında izleyin: kayıt formunun tamamlanma oranı, ödeme adımındaki terk noktası, arama kutusunda sonuç dönmeyen sorgular. Sonuncusu en ucuz geri bildirim kaynağıdır, çünkü kullanıcıların o dilde hangi kelimeyi beklediğini doğrudan söyler. Çevirmenin seçtiği terim ile kullanıcının aradığı terim tutmuyorsa boş sonuç listesi bunu ilk haftada gösterir.