Yeni yayınlanan bir Cache-Control analiz aracının İngilizce sürümünde Japonca metinler göründü; durumu "Fresh" yerine “新鮮” olarak okunuyordu. Hata, sayfanın yalnızca İngilizce etiketler sağlamasına rağmen, sabit kodlanmış Japonca dizeler döndüren ortak mantığa (shared logic) dayanıyordu.

Geliştirici, her biri aynı ayrıştırma (parsing) fonksiyonlarını ve temel mantığı yeniden kullanan bir İngilizce sayfa ve bir Japonca sayfadan oluşan bir dizi hafif tarayıcı aracı inşa ediyor. Sadece görünen kelimeler farklı olmalıdır. Cache-Control analiz aracı piyasaya sürüldüğünde, İngilizce arayüz doğru etiketleri görüntüledi ancak işlenen değerler, hâlâ Japonca karakterler içeren mantık katmanından geliyordu. Konsolda hiçbir hata görünmedi; sayfa normal görünüyordu ancak İngilizce konuşan kullanıcılara sunulan bilgiler yanlıştı.

Ortak mantık neden çeviriye ihanet edebilir?

Hata bir tasarım seçiminden kaynaklanıyordu: Ne gösterileceğine karar veren temel fonksiyon, Japonca sabit dizeler döndürüyordu. Çevredeki İngilizce metinden sorumlu olan sayfa katmanı, bu değerleri değiştirme fırsatı bulamadı. Mantık ve kullanıcı arayüzü (UI) birbirinden net bir şekilde ayrıldığı için sorun test sırasında görünmez kaldı; kullanıcıya sunulan dil yanlış olsa bile teknik olarak her şey "çalışıyordu".

Bunun dezavantajı, paylaşılan modül içinde kullanılan dilin, onu kullanan her ön uç (front-end) için varsayılan hale gelmesidir. Farklı bir dil gerektiğinde, bu varsayılan değer gizli bir hataya dönüşür.

Çözüm: anahtarlar, paketler ve bir güvenlik ağı

Yazar, sorumlulukları ayırmak için mimariyi yeniden yazdı:

  • Mesaj paketleri (Message packs) artık her dil için tüm insan tarafından okunabilir dizeleri tutuyor.
  • Ortak mantık (Shared logic) asla ham metin değil, yalnızca sembolik anahtarlar döndürüyor.
  • Sayfalar, anahtara dayanarak ilgili paketten uygun kelimeyi buluyor.

Bir mesajın bir sayı içermesi gerektiğinde, yeni kod bir şablon dizesi (template string) yerine küçük bir fonksiyon kullanıyor. Bu, her dilin sayının nereye geleceğine karar vermesine olanak tanıyarak kelime sırasındaki farklılıklara uyum sağlıyor.

Ayrıca basit bir statik analiz adımı da eklendi: derleme süreci (build process), paylaşılan dosyaları Japonca karakterler açısından tarıyor. Herhangi bir karakter görünürse geliştiriciye anında uyarı gönderiliyor ve sabit kodlanmış yabancı metinlerin tekrar araya sızması önleniyor.

Bu deneyim yazara ne öğretti?

  1. Çeviri, bir inceleme aşaması görevi görür. İngilizce mesajları yazarken yazar, bazı Japonca karşılıkların belirsiz olduğunu fark etti. Çeviri yapmak, her iki dilde de daha net ifadeler kullanılmasını sağladı.
  2. Dize döndüren ortak fonksiyonlar, herkes için bir dili kilitler. Eğer bir fonksiyon dile karar veriyorsa, farklı bir dil bekleyen tüm kullanıcılar bu hatayı devralır. Hata bir UI aksaklığı değil, bir mantık kusurudur.

Çok dilli araçları yöneten herkes için öneriler

  • Temel fonksiyonlardan dize değil, anahtar döndürün. Yerelleştirme işini kullanıcı arayüzü (UI) katmanına bırakın.
  • Veya istenen dizeleri fonksiyona parametre olarak geçin. Bu, mantığın dilden bağımsız (agnostic) kalmasını sağlar.
  • Paylaşılan modülleri sabit kodlanmış ana dil metinleri açısından denetleyin. ASCII olmayan karakterler için yapılacak hızlı bir arama, gizli sorunları ortaya çıkarabilir.
  • Paylaşılan kodda yabancı karakterler için derleme zamanı (build-time) kontrolü ekleyin. Erken tespit, sürüm sonrası kafa karışıklığını önler.

Bir sonraki adımda nelere dikkat edilmeli?

Özet: Eğer projeniz farklı dil sürümleri arasında kod paylaşıyorsa, paylaşılan kısmın kelimelere asla karar vermediğinden emin olun. Her sayfanın kendi kelimelerini sağlamasına izin verin; böylece yanlışlıkla Japonca konuşan bir İngilizce sayfanın utancından kurtulursunuz.