Girişimler için i18n: Ne Zaman Uluslararasılaştırmalısınız (Ve Yeniden Yazmaktan Nasıl Kaçınırsınız)

Neredeyse her girişimde A Serisi civarında bir konuşma yaşanır. Biri analizlere bakar ve kayıtların %30'unun İngilizce konuşulmayan ülkelerden geldiğini fark eder. Ürün yalnızca İngilizcedir. Bu kullanıcı gruplarından gelen churn oranı korkunçtur. Mühendislik lideri, "uluslararasılaştırmamız gerekiyor" der.

Sonra tahmin gelir: en az altı ay.

Bu tahmin neredeyse her zaman doğrudur ve neredeyse her zaman önlenebilir.

i18n'i Sonradan Eklemenin Gerçek Maliyeti

CSA Research'e göre, tüketicilerin %87'si kendi dillerinde alternatifler varken yalnızca İngilizce olan bir üründen satın almaz. Lokalizasyon pazarı 2023'te 6,27 milyar dolara ulaştı ve büyümeye devam ediyor. Bunlar niş rakamlar değil — kod tabanınıza sessizce yerleştirdiğiniz, ulaşılabilir pazarınızın tavanını temsil ediyorlar.

i18n'i sonradan eklemenin pahalı olmasının nedeni, uluslararasılaştırmanın teknik olarak zor olması değil. Nedeni, uygulamaların i18n gözetilmeden nasıl inşa edildiği:

• 200 bileşene dağılmış string sabitleri
• ABD kurallarına göre sabit kodlanmış tarih ve sayı biçimlendirmesi
• İngilizce metin için boyutlandırılmış veritabanı sütunları
• Hiç düşünülmemiş sağdan sola düzen
• İngilizce dilbilgisi varsayımları etrafında yapılandırılmış içerik
• Tek bir bölgeye bağlı saat dilimi yönetimi

Bunların her biri başlangıçta doğru yapmak ucuzdur. Her biri, kod tabanının 40.000 satıra ve her biri orijinal varsayımların üzerine inşa etmiş dört mühendise sahip olduğu 18. ayda çözmesi acı vericidir.

Altı aylık tahmin çevirileri eklemek için değil. Uygulamanızın i18n gözetilmeden inşa edilmiş kısımlarını denetlemek ve yeniden yazmak için. Çeviri işin %20'si. Geri kalan %80 arkeoloji.

Aslında Ne Zaman Uluslararasılaştırmalısınız?

Bu sorunun iki kısmı var: mimarinizi ne zaman i18n-hazır yapmalısınız ve ne zaman gerçekten birden fazla dil yayınlamalısınız.

Mimari: Her zaman, ilk günden.

Baştan i18n-hazır inşa etmenin maliyeti yaklaşık iki saatlik kurulum süresidir. Hiçbir şey çevirmiyorsunuz. Çevirmen tutmuyorsunuz. Sadece kapıları kapamayan kararlar alıyorsunuz.

• String'leri sabit kodlamak yerine kaynak dosyalarına taşıyın
• Yerel ayar destekli bir tarih/saat kütüphanesi kullanın (Luxon, yerel ayar desteğiyle date-fns, Temporal)
• Intl.NumberFormat'ı sarmalayan bir sayı biçimlendirme yaklaşımı seçin
• Kullanıcı arayüzünüzde metin genişlemesi için alan bırakın (Almanca İngilizceden %30 daha uzun olabilir)
• Başlangıçtan itibaren yerel ayarı bir kullanıcı tercihi olarak saklayın

Bu erken optimizasyon değil. Fazla mühendislik de değil. Değiştirebileceğiniz yapılandırma değerleri için ortam değişkenleri kullanmanızla aynı sebep — belirli bir ihtiyacı öngörmüyorsunuz, belirli bir tuzaktan kaçınıyorsunuz.

Çevirileri yayınlamak: Sinyal aldıktan sonra.

İlk günden Fransızca yayınlamanız gerekmiyor. Hazır olmanız gerekiyor. İkinci bir dile gerçekten yatırım yapma kararı verilere dayanmalıdır:

• Hedef pazardan organik kayıtlar görüyorsunuz
• Bir satış görüşmesi anlaşmayı kapatmak için bunu gerektiriyor
• İngilizce penetrasyonunun düşük olduğu bir pazara giriyorsunuz
• Belirli bir dile sahip müşteri grubu daha yüksek oranda kaybediliyor

Bu sinyal göründüğünde, "i18n-hazır" olmak, altı ay değil bir haftada ikinci bir dil yayınlayabileceğiniz anlamına gelir.

3 Aylık Zaman Çizelgesi Tuzağı

Ekipler böyle yakalanır: i18n'e ihtiyaçları olduğunu bilirler, yanlış yapmak istemezler, bu yüzden "düzgün bir i18n projesi" planlarlar. Üç aylık kapsamı belirlerler. Bu tahmin şunları içerir:

• Mevcut string'leri denetleme
• Çeviri hattı oluşturma
• Çeviri yönetim sistemi entegrasyonu
• Çeviri satıcısıyla koordinasyon
• Her yerel ayarda kalite güvencesi

Proje planlanırken yol haritası ilerlemeye devam eder. Üç aylık proje, özellik göndermediği için sürekli ertelenir. Sonunda öncelik sıralamasına girdiğinde, kod tabanı büyüdüğü için beş aylık bir proje haline gelmiştir.

Tuzak, i18n'i büyük bir geçiş olarak ele almaktır. Alternatif, mimariden başlayarak kademeli olarak attığınız bir temel olarak ele almaktır.

Minimal Uygulanabilir i18n Kurulumu

Çekirdek aşamasında bir React veya Next.js uygulaması için "i18n-hazır" pratikte nasıl görünür. Kurulumu iki saat sürer ve çevirmeye hazır olana kadar sıfır süregelen yük getirir.

Adım 1: String dışsallaştırma yaklaşımı seçin.

Görüntü string'lerini sabit kodlamayın. En azından JSON dosyalarına koyun. Daha iyisi: başlangıçtan itibaren tipli bir çözüm kullanın.

// Kötü — sabit kodlanmış string
<button>Get started for free</button>

// Daha iyi — dışsallaştırılmış, şimdilik sadece İngilizce olsa bile
// messages/en.json
{
  "cta.getStarted": "Get started for free"
}

// Bileşen
const t = useTranslations();
<button>{t('cta.getStarted')}</button>

Henüz bir çeviri platformuna ihtiyacınız yok. Yalnızca İngilizce bile olsa, her yerel ayar için bir JSON dosyası yeterlidir. Önemli olan satır içi string'ler yerine t() kullanma alışkanlığıdır.

Adım 2: İlk günden yerel ayar-duyarlı biçimlendirme.

// Kötü — sabit kodlanmış ABD biçimlendirmesi
const formatted = `$${price.toFixed(2)}`;
const date = new Date(ts).toLocaleDateString('en-US');

// İyi — yerel ayar-duyarlı
const formatted = new Intl.NumberFormat(locale, {
  style: 'currency',
  currency: 'USD'
}).format(price);

const date = new Intl.DateTimeFormat(locale, {
  dateStyle: 'medium'
}).format(new Date(ts));

Daha sonra ikinci bir yerel ayar eklediğinizde, biçimlendirme sadece çalışır. 80 dosyada grep-and-replace yok.

Adım 3: Metin genişlemesini göz önünde bulundurarak tasarlayın.

Arayüzünüzde nefes alma alanı bırakın. Metin uzadığında zarif şekilde bozulan CSS kullanın. Metin kapsayıcılarında piksel sabit genişliklerden kaçının. Bu tasarımda hiçbir maliyeti yoktur ama Almanca yayınladığınızda kalite güvencesinde gerçek para tasarrufu sağlar.

Adım 4: Yerel ayarı birinci sınıf kullanıcı özelliği olarak saklayın.

Tek bir dil yayınlıyor olsanız bile, kullanıcı modelinizde preferred_locale'i saklayın. İkinci bir dil eklediğinizde, mevcut kullanıcılarınızın zaten kayıtlı bir yerel ayar tercihi vardır. Canlı veriler altında şema geçişi yapmanız gerekmez.

Yaygın Girişim Hataları

"İhtiyaç duyduğumuzda i18n ekleriz." İhtiyaç duyduğunuz an, düzgün yapacak zamanınızın olmadığı andır. Kararı tetikleyen sinyal — Fransızca gerektiren önemli bir müşteri, bölgesel bir go-to-market hamlesi — her zaman aciliyetle birlikte gelir.

Özel bir çeviri hattı oluşturma. Çeviri yönetimi çözülmüş bir sorundur. Özel bir çözüm oluşturmak haftalarca, bakımı aylarca sürer. Zaten var olan araçları kullanın.

Lokalizasyonu sadece çeviri olarak ele alma. Dil, lokalizasyonun %20'sidir. Para birimi, tarih biçimleri, adres biçimleri, yasal gereksinimler, RTL desteği, yerel ayara özgü UX kuralları — bunlar diğer %80'dir. Bozuk bir düzende çevrilmiş bir string hala bozuk bir deneyimdir.

Çevirmenlere doğrudan JSON dosyalarına erişim verme. İnsan çevirmenler JSON'u hiçbir zaman manuel olarak düzenlememeli. Hata oranı yüksektir ve geri bildirim döngüsü yavaştır. Bağlam, karakter sınırları ve terim tutarlılığı zorlamasıyla çeviri çalışması için oluşturulmuş bir arayüze ihtiyaçları vardır.

İngilizce kelime sırasının genelleştiğini varsayma. JavaScript string interpolasyonuyla çevrilmiş string'leri birleştirmek, farklı dilbilgisi yapılarına sahip dillerde bozulur. Değişkenli her şey için ICU mesaj formatı kullanın.

// Kötü — İngilizce kelime sırasını varsayar
t('welcome') + ' ' + userName + '!'

// İyi — ICU formatı, yerel ayar token'ları yeniden sıralayabilir
t('welcome', { name: userName })
// en: "Welcome, {name}!"
// ja: "{name}さん、ようこそ！"

Bir Karar Çerçevesi

Nerede olduğunuzu ve ne yapacağınızı belirlemek için bunu kullanın:

Temel içgörü: mimari karar ve çeviri kararı bağımsızdır. Mimari kararı şimdi verin. Çeviri kararını veriler size söylediğinde verin.

Pratik Kontrol Listesi

Başka bir bileşen yazmadan önce şunları kontrol edin:

• String'ler dışsallaştırılmış (JSX/şablonlarda sabit kodlanmamış)
• Tarih biçimlendirmesi yerel ayar-duyarlı API'ler kullanıyor
• Sayı ve para birimi biçimlendirmesi Intl.NumberFormat kullanıyor
• Kullanıcı modelinin bir locale alanı var
• Arayüz düzenleri %30 daha uzun metinle test edilmiş
• Çevrilebilir parçalarla string birleştirme yok
• Değişkenli string'ler için ICU mesaj formatı kullanılıyor
• Çoğullama doğru şekilde ele alınmış (sadece "s" eklemek değil)

Bunların hepsini tamamlamak iki saat sürer. Herhangi birini ölçekte kaçırmak haftalara mal olur.

Bu Pratikte Nasıl Görünür

Birden fazla dil yayınlamaya gerçekten hazır olduğunuzda, iş akışı "arkeolojik kazı"dan "çeviri projesine" dönüşür. İhtiyacınız olan:

1. Kaynak string'leri çevirmenlere aktarmanın bir yolu
2. Çeviriler için inceleme süreci
3. String'leri kod dağıtımı olmadan güncelleyen bir dağıtım hattı
4. Her kullanıcıya doğru yerel ayarın çalışma zamanında iletilmesi

Better i18n olarak bu spesifik sorun etrafında bir platform inşa ettik — React, Next.js, Vue ve Svelte için tip-güvenli SDK'lar, çevirilerin kod gibi incelemeden geçmesi için Git tabanlı çeviri iş akışları ve çevirileri yeniden dağıtmadan güncelleyebilmeniz için CDN iletimi. Fiyatlandırma sayfamızdaki ücretsiz katman, bütçe taahhüdü olmadan temel oluşturmak isteyen erken aşama ekipler için boyutlandırılmıştır. Teknik parçaların nasıl bir araya geldiğini görmek istiyorsanız, geliştiriciler için sayfası tam resmi sunuyor.

Altı aylık yeniden yazım kaçınılmaz değil. İki saatlik bir kararın çok uzun süre ertelenmesinin sonucudur.