Ülke ve dil aynı değildir, ama form tasarımında neredeyse her zaman birlikte düşünülür ve bu yüzden sık sık birbirine karıştırılır. Bir ülkede birden fazla dil konuşulabilir; bir dil birden fazla ülkede kullanılabilir. Bu iç içe geçmişlik, “dili biliyorsam ülkeyi de biliyorum” varsayımını doğurur ve o varsayım test matrisini baştan bozar. Bu yazıda iki eksenin nerede ayrıldığını, yerelleştirmenin hangi katmanlardan oluştuğunu ve matrisin nasıl kurulacağını ele alıyoruz.
Ülke ve dil neden birbirinden türetilemez?
İki kavram arasındaki ilişki bire bir değil, çaprazdır. Bir ülkenin içinde birden fazla resmî dil bulunabilir; aynı dil, birden fazla ülkede resmî dil olarak kullanılabilir. Bu iki olgu aynı anda doğru olduğunda, tek bir eşleme tablosu kurmak imkânsız hale gelir.
Buna rağmen sistemlerde en sık görülen kısa yol, dili ülkenin vekili saymaktır. Kullanıcı arayüzde bir dil seçtiğinde, arka planda bütün veri kurallarının da o dile göre belirlendiği varsayılır. Varsayım, dil ile ülkenin örtüştüğü durumlarda hiç sorun çıkarmaz; örtüşmediği anda ise sessizce yanlış sonuç üretir.
Yanlış sonucun sessiz olması, hatayı pahalı kılar. Kullanıcı bir hata mesajı görmez, veri kaydedilir, rapor üretilir; sorun ancak bir denetim ya da bir müşteri şikâyetiyle ortaya çıkar. Bu yüzden iki ekseni baştan ayırmak, sonradan düzeltmekten çok daha ucuzdur.
Yerelleştirmenin üç katmanı
Yerelleştirme tek bir iş değil, birbirinden bağımsız üç katmandır. Katmanları ayırmadan konuşmak, tartışmayı sürekli belirsiz bırakır.
| Katman | Neyi belirler | Neye bağlıdır |
|---|---|---|
| Arayüz dili | Ekranda görünen metinlerin dili | Kullanıcının dil tercihi |
| İçerik bölgesi | Hangi pazarın içeriği ve kuralları gösterilir | Kullanıcının bulunduğu ya da seçtiği bölge |
| Veri biçimi | Tarih, sayı, ad sırası ve adres alanlarının biçimi | Verinin ait olduğu bölge |
Bu üç katman aynı değeri almak zorunda değildir. Bir kullanıcı arayüzü kendi dilinde görmek isterken, veriyi başka bir ülkenin kurallarına göre girmek zorunda olabilir. Üç katmanı tek bir değere bağlamak, bu durumu ifade edilemez kılar.
Katmanları ayırmanın bir diğer faydası, hata ayıklamayı kolaylaştırmasıdır. Bir ekranda tarih yanlış göründüğünde, sorun arayüz dilinde mi, içerik bölgesinde mi, veri biçiminde mi aranacağı bellidir. Tek bir “yerelleştirme ayarı” varsa, üç ihtimal aynı anda şüpheli kalır.
Dil etiketi ile bölge kodunun görevleri
Dil etiketi ve bölge kodu, sık sık aynı kutuda saklanan ama farklı işler yapan iki değerdir. Dil etiketi, metnin hangi dilde olduğunu söyler: başlıklar, düğme yazıları, hata mesajları. Bölge kodu ise verinin hangi kurallara göre yorumlanacağını söyler: alanların hangi sırayla beklendiği, hangi alanların zorunlu olduğu, doğrulamanın hangi kurala bağlı olduğu.
Bunları tek bir değerde birleştirmenin cazibesi, daha az alan tutmaktır. Bedeli ise şudur: aynı dili konuşan iki farklı bölgeyi artık ayırt edemezsiniz. Kullanıcı arayüzü tek bir dilde görürken, veri iki farklı bölgenin kuralına göre işlenmek zorunda kaldığında, tek değerli model bu ayrımı taşıyamaz.
Ayrım, kod tarafında da kendini gösterir. Arayüz metinlerini seçen mekanizma ile veri kurallarını seçen mekanizma aynı olmamalıdır. İkisini aynı değere bağlamak, bir gün “arayüz Türkçe kalsın ama veri başka bir bölgenin kuralına göre işlensin” gibi bir isteği karşılanamaz kılar.
Aynı dilin farklı bölgelerdeki metin uzunlukları da belirgin biçimde değişir. Aynı düğme yazısı bir bölgede kısa, başka bir bölgede uzun olabilir; bu fark düzenleri, tablo sütunlarını ve kesme mantığını doğrudan etkiler. Dil etiketine bakarak uzunluk varsaymak, tam olarak bu yüzden yanıltıcıdır.
Dili ülke yerine koymak hangi hataları doğurur?
En bilinen hata, aynı dili konuşan iki bölgeyi tek kurala bağlamaktır. Kullanıcının dil tercihine bakıp veri kuralını seçen bir sistem, aynı dili paylaşan bölgelerden birinin kurallarını diğerine uygular. Sonuç, geçerli bir kaydın reddedilmesi ya da geçersiz bir kaydın kabul edilmesidir.
İkinci hata, varsayılan bölgeyi dilden türetmektir. Kullanıcı bir dil seçtiğinde, sistemin o bölgeyi de seçtiğini varsaymak, kullanıcının gerçekte başka bir bölgede olduğu durumlarda yanlış veri üretir. Bölge, açıkça seçilmediği sürece tahmin edilmemelidir.
Üçüncü hata, doğrulama hatasını yanlış sebebe bağlamaktır. Dil yüzünden seçilmiş bir kural, geçerli bir veriyi reddettiğinde kullanıcı “biçimim yanlış” mesajı görür; oysa sorun biçimde değil, kuralın hangi bölgeden alındığındadır. Kullanıcı bu durumda veriyi düzeltmeye çalışır ve asla başaramaz.
Dördüncü hata, dilin bölgeyi temsil ettiği varsayımıyla test yazmaktır. Her dil için tek bir ülke seçen bir matris, aynı dilin farklı bölgelerde farklı davrandığı durumları hiç görmez. Testler yeşil kalır, üretimde ise kapsanmayan bölge kırılır.
Bu tür hataların kaynağı genellikle metin biçimidir ve ayrıntıları dilin kendi yapısına bağlıdır; ad ve metin verisinin bölgeye göre nasıl değiştiğini bölgeye göre ad verisi yazısında bulabilirsiniz.
Test matrisi nasıl örneklenir?
Doğru matris, iki eksenin bağımsız örneklenmesiyle kurulur. Dil ekseni, metnin nasıl göründüğünü; bölge ekseni, verinin nasıl işlendiğini sınar. İki ekseni aynı anda değiştirmek, hangi eksenin hataya yol açtığını belirsizleştirir.
Bunu yapmanın pratik yolu, iki ayrı listeyi çaprazlamaktır:
- Dil listesi: farklı yazı sistemleri ve farklı metin uzunlukları üreten diller.
- Bölge listesi: farklı alan uygulanabilirliği ve farklı alan sıralaması olan bölgeler.
- Kesişim: her dilin her bölgeyle en az bir kez birleştiği küçük bir tablo.
- Özel durumlar: aynı dili paylaşan iki bölgenin yan yana konulduğu satırlar.
Dördüncü madde, matrisin en değerli satırlarıdır; çünkü “dil ülkeyi belirler” varsayımını doğrudan sınar. Bu satırlar olmadan, matris çalışıyor gibi görünür ama asıl riski görmez.
Matrisi büyütmenin tek yolu ürünü çoğaltmak değildir. Dil ve bölge listelerini ayrı ayrı çeşitlendirmek, aynı sayıda testle daha fazla yol kapsar. Bölgesel ayrıntıların kendisini burada tekrarlamaya gerek yok; belirli bir bölgenin veri düzeni Brezilya gibi ülke sayfalarında ayrıca görülebilir.
Geliştiriciler için: biçimi dile değil bölgeye bağlamak
Biçim kararlarını dil etiketine bağlayan her kod yolu, er ya da geç yanlış bölgeyi seçer. Yapılacak iş, biçim ve doğrulama kurallarını bölge koduna bağlamak, dil etiketini yalnızca metin seçiminde kullanmaktır.
İki değeri ayrı alanlarda tutun ve hiçbir zaman birini diğerinden türetmeyin. Kullanıcıdan dil tercihini alın, bölgeyi ise açıkça sorun. Bölge bilinmiyorsa, sessizce bir varsayılan seçmek yerine bunu bir eksiklik olarak işleyin.
Doğrulama katmanını bölge koduna göre yapılandırın ve kural seçimini tek bir yerde toplayın. Kurallar dağıldığında, bir bölge eklendiğinde hangi dosyaların güncelleneceği belirsizleşir ve bazı yollar eski kuralla kalır.
Testlerde iki ekseni ayrı ayrı raporlayın. Bir hata çıktığında, hatanın metin katmanından mı veri katmanından mı geldiğini görmek, hatanın nereye atanacağını belirler. Bu ayrım olmadan, her yerelleştirme hatası aynı kişiye düşer ve hiçbiri kalıcı olarak kapanmaz.
Sonraki adımlar
İki ekseni ayırdıktan sonra, formlardaki ülke seçiminin kendisi ayrı bir test konusu haline gelir; bunu ülke seçim alanı testi yazısında bulabilirsiniz. Hangi ülkelerin hangi bölge başlıkları altında toplandığını ise bölge grupları ve pazar seviyeleri yazısı ele alır. Dil ve bölge ayrımını gerçek verilerle karşılaştırmak için sitemizdeki ülke ve bölge dizini sayfasına bakabilirsiniz.
Bu yazıdaki örnek eşleşmeler, dil ve bölge bileşimleri ile örnek değerler yalnızca anlatımı netleştirmek için kurulmuş kurgusal örneklerdir; gerçek kullanıcı dağılımını, gerçek bir pazar listesini ya da gerçek bir dil politikasını yansıtmaz ve herhangi bir kuruma atfedilemez.