Lokalizasyon ve Uluslararasılaştırma: Çeviriden Sonra Başlayan İş
Çok dilli bir ürün kurarken zor kısım çeviri değil. Zor kısım, çevirinin sığacağı yeri baştan açık bırakmak: değişen sözcük sırası, farklı çoğul kuralları, iki katına çıkan etiket uzunlukları, tersine dönen düzen. Metni bunlar hazır değilken çevirtirseniz elinizde her dilde ayrı ayrı yamalanan bir arayüz kalır.
Uluslararasılaştırma çeviriden önce gelir
İki iş var ve sırası sabittir. Uluslararasılaştırma, kodu tek bir dilin varsayımlarından arındırmaktır: metin kaynak dosyalarına çıkar, biçimlendirme sabit kodlanmaz, düzen yön değiştirebilir hale gelir. Lokalizasyon ise belirli bir pazar için yapılan uyarlamadır. İlkini atlarsanız ikincisini her yeni dilde sıfırdan yaparsınız, üstelik her seferinde başka bir yerde kırılır.
Cümleyi parçalayıp birleştirmeyin
Arayüzdeki en yaygın hata metni koddan birleştirmek: "Sepetinizde " . $n . " ürün var". Bu cümle İngilizceden Türkçeye kadar dayanabilir ama çoğul kurallarında dağılır. CLDR altı çoğul kategorisi tanımlar (zero, one, two, few, many, other); Arapça altısını da kullanır, Rusça ve Lehçe üçünü, Türkçe ve İngilizce ikisini. Türkçede ayrıca sayıdan sonra çoğul eki gelmez: "3 books" karşılığı "3 kitaplar" değil "3 kitap"tır. Bir parçayı sayıya göre değiştirmek yetmez, cümlenin tamamı sayının fonksiyonu olmalıdır.
Çözüm ICU MessageFormat: çeviri dosyasında tam cümle şablonu durur, çoğul dallanması metnin içindedir, çevirmen kendi dilinin kaç dalı varsa onu yazar. PHP tarafında MessageFormatter, NumberFormatter ve IntlDateFormatter bunu intl uzantısıyla zaten getirir. Kendi tarih ve sayı biçimleyicinizi yazmayın, o iş çözülmüş durumda.
Metin uzar, düzen ters döner
Kısa İngilizce etiketler çeviride en çok büyüyen metinlerdir; iki harflik bir düğme yazısı Almancada bileşik bir kelimeye dönüşebilir. Sabit genişlikli düğme ve tek satıra kilitli menü, tasarımın çeviriye direnen kısmıdır. Arayüzü en uzun dilde test edin, en kısa dilde değil.
Sağdan sola diller yalnızca metni değil düzeni de çevirir. Bunu dir="rtl" ve CSS mantıksal özellikleriyle (margin-inline-start, padding-inline-end, text-align: start) tek noktadan halledebilirsiniz; left ve right yazdığınız her yer sonradan elle düzeltilecek bir istisnadır. İkonlarda ayrım yönlüdür: geri oku aynalanır, saat ikonu aynalanmaz.
Dil bir şey, bölge başka bir şey
Kullanıcının dili ile bulunduğu pazar aynı değişken değil. Portekizce Brezilya ile Portekiz'de farklı yazılır, İngilizce konuşan iki kullanıcıdan biri 09/07 tarihini eylülün 7'si diye okurken diğeri 9 temmuz olarak okur. Ondalık ayırıcı, para birimi simgesinin yeri, hafta başlangıcı günü de bölgeye bağlıdır. Bu yüzden dili ve bölgeyi ayrı taşıyın, ikisini tek bir bayrak ikonuna indirmeyin. Dili IP adresinden tahmin edip kullanıcıyı zorla yönlendirmek de her seyahat edende ve her VPN kullanıcısında hata verir: tahmini varsayılan olarak kullanın, seçimi kullanıcıya bırakın, seçtiğini hatırlayın.
Her dil ayrı URL, tek kaynak
Dil tercihini genelde URL yolunda taşırım, çerezde değil. Aynı adresin çerezle dil değiştirmesi kullanıcı için sorun çıkarmaz ama arama motoru o sayfayı tek dilde indeksler, paylaşılan bağlantı da karşı tarafta yanlış dilde açılır. /tr/ ve /en/ gibi ayrı yollar, aralarına hreflang bağlantıları koyunca hem indekslenir hem doğru açılır.
Ayrı URL, ayrı içerik demek değil. Her dil için siteyi klonlamak ilk gün hızlıdır, altıncı ayda kopyalar birbirinden ayrışır ve hangi sürümün güncel olduğunu kimse bilmez. İçerik ve çeviri tek kaynaktan yönetilsin, çoğalan şey yalnızca sunum olsun.
Kültürel duyarlılık renk ve simge seçiminde bitmiyor. Asıl kültürel hata, ürünü tek bir dilin dilbilgisine göre kurup diğerlerini o kalıba sığdırmaya çalışmak. Kalıbı baştan esnek kurarsanız yeni bir dil eklemek çeviri dosyası eklemekten ibaret kalır.