Konu Başlıkları
Yükleniyor...

Uluslararası Kullanılabilirlik: Dil, Yön ve Yerelleştirme Kararları

Çok Dilli Sitelerde Kullanılabilirlik: Pratik Kararlar

Aynı arayüz Almanya'da sorunsuz çalışırken Arapça sürümünde dağılabilir ve sebep çoğu zaman çeviri kalitesi değildir. Yön, metin uzunluğu, arama alışkanlığı ve güven sinyalleri ülkeye göre değişir; kullanılabilirlik ilkeleri değişmez. İş, bu ikisini birbirinden ayırmakta.

Evrensel ilke, yerel ayrıntı

Net gezinme, hızlı yüklenen sayfa, ne yapacağı anlaşılan buton: bunlar her pazarda aynı işi görür. Değişen şey ilkenin uygulanma biçimi.

Uluslararası kullanılabilirlik metinleri tam burada kendisiyle çelişir. Aynı sayfada bir yanda “metni kısa ve sade tut”, öbür yanda “Arapça daha uzun ve süslü anlatımı destekler” yazar. İkisi birden tavsiye olamaz. Ayrım şurada: kısalık bir yapı kararıdır, yani paragraf başına tek fikir, taranabilir başlık, ısınma cümlesi yok. Kelime sayısı ise yerel bir karardır ve o dilde yazan editöre bırakılır. Türkçe bir cümleyi İngilizce özgününün karakter sayısına sıkıştırmaya çalışan metinler, okurun anlamadığı metinlerdir.

Sağdan sola geçmek direction: rtl demek değil

Arapça ve İbranice sürümlerde düzen aynalanır: menü sağa, akış sağdan sola, ileri oku ters yöne. Arapça okuyan da sayfayı F benzeri bir desende tarar, sadece ters yönde; yani hiyerarşiyi bozmadan yansıtmak yeterli.

Kırılan yer düzen değil, karışık yönlü içerik. Bir projede RTL'yi tek satır direction: rtl ile bitirdiğimi sanmıştım; IBAN ve sipariş numarası alanları ekranda karışık sırada görünene kadar.

RTL'de yön değiştirmeyenler:

  • Sayılar, telefon numaraları, IBAN, kart numarası
  • Latin alfabesiyle yazılmış marka adları, e-posta adresleri, URL'ler
  • Kod blokları ve terminal çıktısı
  • Yönü olmayan ikonlar; ok ve geri/ileri ikonları ise aynalanır

CSS tarafında left/right yerine mantıksal özellikleri kullan: margin-inline-start, padding-inline-end, text-align: start. Tek stil sayfası iki yönde de çalışır, ayrıca bakımı yapılacak bir rtl.css çıkmaz (MDN, CSS logical properties).

Metin uzar, arama kutusu şaşırır

Çeviri neredeyse her zaman uzar. Almanca birleşik kelimeler, Türkçe ekler, Fransızca dolaylı anlatım; ilk kırılan yerler sabit genişlikli butonlar, sekme çubukları ve tablo başlıkları oluyor. Yaygın tavsiye tasarıma belli bir yüzde pay bırakmaktır ama oran uydurmaya gerek yok: desteklenen dillerdeki en uzun gerçek çeviriyi al, arayüzü onunla aç.

Arama kutusu ikinci kör nokta. Kullanıcı hem kendi dilinde hem İngilizce arar, B2B tarafında çoğunlukla doğrudan İngilizce teknik terimle arar. Ürün adını Türkçeleştirip dizine yalnızca Türkçe karşılığını yazan site bu aramayı kaybeder. Yabancı dilde yazılan sorguda yazım hatası oranı yüksek olduğu için öneri ve otomatik düzeltme burada süs değil, aramanın kendisi. en-US ile en-GB farkları da eşanlamlı olarak beslenmeli: color/colour, catalog/catalogue.

Tek site mi, ülke başına site mi

Ayrı yerelleştirilmiş siteler kağıt üstünde iyi görünür, maliyeti bakımda çıkar. n dilli bir yapıda her fiyat değişikliği, her yasal metin güncellemesi, her yeni ürün sayfası n kere yapılır ve unutulma olasılığı en yüksek olan n'inci kopyadır. Üç dil yönetilebilir. Sekiz dilde, süreç otomatik değilse, siteler birkaç ay içinde sessizce birbirinden ayrılır ve hangisinin doğru olduğunu kimse bilmez.

Pratik sıra şu: tek kod tabanı, dil anahtarı, tarih ve para birimi Intl ile biçimlendirilir. Elle kurulan “1.234,56 TL” dizgisi bir yerde patlar. Ülkeye özel siteyi ancak ölçülebilir bir sebep varsa aç: yerel ödeme yöntemi, yasal zorunluluk ya da o pazarda ccTLD'nin gerçekten güven göstergesi olması. Avustralya iyi örnek, İngilizce konuşan bir pazar olmasına rağmen .au adres, yerel ölçü birimi ve yerel stok bilgisi dönüşümü gözle görülür biçimde değiştiriyor.

Bir de şu: çeviriyi teslim alıp test etmemek en pahalı seçenek. Her dil için o dili konuşan biriyle yapılan yarım saatlik bir oturum, bütün çeviri belleği araçlarından daha fazla hata bulur.