Çoğu işletme sahibi çok dilli panel kurmayı bir çeviri işi sanır. Dil dosyasını çoğaltırsın, cümleleri çevirirsin, üst menüye bayrak koyarsın ve iş bitti diye düşünürsün. Sonra ilk yabancı müşteri gelir: arayüz İngilizce açılır ama ürün adı Türkçe kalır, fiyat TL görünür, teslimat e-postası Türkçe gider ve arama motoru iki dilli sayfayı aynı içerik sayıp ikisini birlikte geri plana atar.
Çok dillilik bir metin meselesi değil, bir yönlendirme ve eşleşme meselesidir. Kullanıcının hangi dili gördüğü kadar, o dilin hangi para birimine, hangi ödeme yöntemine, hangi e-posta şablonuna ve hangi URL'ye bağlandığı önemlidir. Bu yazıda bir epin satış scripti üzerinde çok dilli kurulumu altı katmanda ele alıyorum ve her katmanda hangi kararın sonraki katmanı kilitlediğini gösteriyorum. Amaç, ikinci dili açtıktan sonra geri dönmek zorunda kalmayacağın bir yapı kurmak.
Dil ile ülkeyi aynı şey saymak neden her şeyi bozuyor?
En yaygın mimari hata, dil seçimini ülke seçimiyle birleştirmektir. Panelde tek bir açılır menü vardır ve kullanıcı "İngilizce" seçtiğinde para birimi otomatik dolara döner. Oysa Almanya'da yaşayan bir müşteri İngilizce arayüz isteyip euro ile ödemek isteyebilir; Türkiye'deki bir bayi İngilizce panel kullanıp TL ile çalışabilir.
Doğru model, iki ayrı değişken tutmaktır: arayüz dili ve fatura ülkesi/para birimi. Arayüz dili metinleri belirler, ülke ise para birimini, vergi davranışını ve görünecek ödeme yöntemlerini belirler. Bu iki eksen ayrıldığında, yeni bir dil eklemek yeni bir pazar açmak zorunluluğu getirmez ve tersi de geçerlidir.
Bu ayrım aynı zamanda raporlamayı temizler. Hangi dilde daha çok satış yaptığın ile hangi para biriminde daha çok tahsilat yaptığın iki farklı bilgidir ve reklam bütçesini yönlendirirken ikisini de ayrı görmek istersin.
Dil algılama nasıl çalışmalı, otomatik mi manuel mi?
Otomatik algılama iyi bir başlangıç noktası, kötü bir son karardır. Tarayıcının dil başlığına bakarak ilk ziyarette makul bir varsayım yapabilirsin, ama kullanıcı bir kez dil değiştirdiğinde o tercih kalıcı olmalı ve bir daha ezilmemelidir. En sinir bozucu deneyim, kullanıcının Türkçe seçtikten sonra bir sonraki sayfada yine İngilizce açılan paneldir.
Uygulanabilir sıralama şu: URL'de dil belirteci varsa o kazanır. Yoksa oturum veya kullanıcı hesabındaki kayıtlı tercihe bakılır. O da yoksa tarayıcı dili değerlendirilir. Hiçbiri yoksa varsayılan dil devreye girer. Bu öncelik zincirini tek bir yerde kurmak, sonradan çıkan onlarca tutarsızlığı baştan engeller. İyi bir dijital ürün satış yazılımı bu zinciri yapılandırılabilir biçimde sunar; sen de mantığı şablonlara dağıtmak zorunda kalmazsın.
| URL yapısı | Örnek | Avantaj | Dezavantaj |
|---|---|---|---|
| Dizin ön eki | site.com/en/urun | Tek alan adı, otorite birikir, kurulumu basit | Ülke hedeflemesi daha zayıf |
| Alt alan adı | en.site.com/urun | Ayrı yapılandırma esnekliği | Sertifika ve yönlendirme yükü artar |
| Sorgu parametresi | site.com/urun?lang=en | Hızlı devreye alınır | Arama motoru için en zayıf seçenek |
| Ayrı alan adı | site.co.uk/urun | Güçlü ülke sinyali | Maliyet ve yönetim yükü yüksek |
| Çerez tabanlı | URL değişmez | Kullanıcıya görünmez | Dizinleme imkansızlaşır, kullanılmamalı |
Ürün içerikleri neden arayüzden ayrı ele alınmalı?
Arayüz metinleri sınırlı ve sabittir; bir kez çevirirsin, yıllarca kullanırsın. Ürün içerikleri ise sürekli değişir, yüzlerce kalem olur ve her birinin adı, açıklaması, teslimat notu ve stok uyarısı ayrı ayrı çeviri isteyebilir. Bu iki kümeyi aynı mekanizmayla yönetmeye çalışmak, ürün ekleme işini yavaşlatır ve eksik çeviriye yol açar.
Pratik çözüm, ürün tarafında devralma mantığı kurmaktır: bir ürünün çevirisi yoksa varsayılan dildeki içerik gösterilir ama sistem bunu bir eksik olarak raporlar. Böylece yüz ürünün hepsini çevirmeden ikinci dili açabilir, eksikleri satış hacmine göre sırayla tamamlayabilirsin. Yanlış olan, çevirisi olmayan ürünü bomboş göstermek veya iki dili aynı kutuda birleştirmektir.
Kategori adları, kampanya başlıkları ve yardım sayfaları da aynı mantıkla yönetilmeli. Özellikle yardım ve kurallar sayfası ihmal edilir; oysa yabancı müşterinin iade ve teslimat sorusunu ilk sorduğu yer tam olarak orasıdır.
Çok dilli epin panellerinde en sık görülen eksik katmanlar
- Çevrilmeyen e-posta ve bildirim şablonları 40%
- Eksik ürün ve kategori çevirisi 30%
- Hatalı URL yapısı ve hreflang 20%
- Tarih, sayı ve para biçimlendirmesi 10%
E-posta ve bildirim şablonları neden en çok atlanan katman?
Çünkü görünmezler. Panelde her şey İngilizce çalışır, test siparişi verilir, ekran güzel görünür. Ama teslimat e-postası, şifre sıfırlama mesajı, bakiye yükleme onayı ve fatura bildirimi hâlâ varsayılan dilde gider. Yabancı müşteri için bu, ürünü aldığı ama ne yapacağını anlamadığı bir andır ve doğrudan destek talebine dönüşür.
Şablonları dil bazında tutman gerekir ve gönderim anında hangi dilin seçileceği net olmalı: kullanıcının hesap dili esas alınır, misafir siparişlerinde ise siparişin oluşturulduğu oturumun dili kaydedilir. Sipariş kaydına dil bilgisini yazmazsan, iki gün sonra gönderilecek bir hatırlatma mailinin hangi dilde gideceğini bilemezsin.
Aynı kural SMS, panel içi bildirim ve otomatik teslimat mesajları için de geçerli. Bir e-pin yazılımı değerlendirirken şablonların dil bazında çoğaltılabilir olup olmadığını mutlaka sor; çoğu hazır çözüm arayüzü çevirir, şablonları tek dilde bırakır.
Arama motoru tarafında ne yapmazsan iki dil birbirini yer?
Aynı içeriğin iki dildeki sürümü, doğru işaretlenmediğinde birbirinin rakibi olur. Bunu engelleyen yapı hreflang etiketleridir: her sayfanın her dil sürümü, diğer tüm sürümleri karşılıklı olarak işaret etmelidir. Tek yönlü işaretleme yeterli değildir ve en sık yapılan hata tam olarak budur.
İkinci kritik nokta kanonik adreslerdir. Her dil sürümünün kendi kanonik adresi olmalı; İngilizce sayfanın kanoniği Türkçe sayfayı işaret ediyorsa İngilizce sürüm dizinden düşer. Üçüncü nokta ise site haritasıdır: dil sürümlerini ayrı bölümler halinde veya dil bağlantılarıyla birlikte bildirmek, taranma hızını belirgin biçimde artırır.
| Kontrol | Nasıl doğrulanır | Kabul ölçütü | Öncelik |
|---|---|---|---|
| Dil tercihi kalıcılığı | Dil değiştir, üç sayfa gez | Tercih hiç sıfırlanmaz | Yüksek |
| Karışık dil kontrolü | Her şablonu tek tek aç | Ekranda tek dil görünür | Yüksek |
| E-posta dili | Her dilde test siparişi | Mail sipariş diliyle gider | Yüksek |
| Para birimi eşleşmesi | Dil ve ülke ayrı değiştirilir | İkisi bağımsız çalışır | Yüksek |
| Karşılıklı hreflang | Kaynak kodu incelenir | Tüm sürümler çift yönlü bağlı | Orta |
| Sayı ve tarih biçimi | Fiyat ve sipariş tarihi okunur | Yerel biçim doğru | Orta |
| Eksik çeviri raporu | Yönetim panelinden bakılır | Eksikler listelenebilir | Orta |
Yeni dili yayına almadan önce bir uçtan uca sipariş dene: ürünü o dilde bul, sepete at, öde, teslimat mailini oku, iade talebi aç. Zincirin herhangi bir halkasında dil değişiyorsa kurulum bitmiş değildir.
Kaç dil açmalısın ve nereden başlamak mantıklı?
Dil sayısı bir prestij göstergesi değil, bir operasyon yüküdür. Her yeni dil; ürün açıklaması, destek yanıtı, kural sayfası ve kampanya metni demektir. Üç dil açıp ikisini güncelleyememek, tek dilde mükemmel çalışmaktan daha kötü bir izlenim bırakır.
Sağlıklı yol, trafik verisine bakmaktır. Ziyaretçilerinin dil ve ülke dağılımını incele, en yüksek hacimli ikinci dili seç ve onu tam olarak tamamla. Destek yanıtlarını o dilde verebilecek bir kapasiten olduğundan emin ol. Ancak bu ikinci dil kendi maliyetini çıkardıktan sonra üçüncüye geç. Özellikler sayfasında dil yönetiminin nasıl yapılandırıldığını görebilir, kendi hacmine göre planlama yapabilirsin.
Çok dilli yapı baştan kurulu gelsin
Arayüz dili, ürün çevirileri, e-posta şablonları ve para birimi eşleşmesi tek panelden yönetilsin. Lisans paketlerini ve dil yönetimi detaylarını incele.
Dil seçimi para birimini otomatik değiştirmeli mi?
Hayır. Dil ve para birimi iki ayrı değişken olmalı. Bir kullanıcı İngilizce arayüz isteyip TL ile ödeme yapmak isteyebilir. Otomatik bağlama, beklenmeyen fiyat değişimleri ve terk edilen sepetler üretir.
Hangi URL yapısı çok dilli epin paneli için en uygun?
Çoğu durumda dizin ön eki en dengeli seçenektir: tek alan adı altında otorite birikir, kurulum ve yönlendirme yönetimi sade kalır. Sorgu parametresi ve çerez tabanlı yaklaşımlar dizinleme açısından zayıftır.
Tüm ürünleri çevirmeden ikinci dili açabilir miyim?
Evet, devralma mantığı kurarsan. Çevirisi olmayan ürün varsayılan dildeki içerikle gösterilir ve eksik olarak raporlanır. Böylece hacimli ürünlerden başlayarak kademeli ilerleyebilirsin.
Teslimat e-postası hangi dilde gitmeli?
Kayıtlı kullanıcılarda hesap dili, misafir siparişlerinde ise siparişin oluşturulduğu oturumun dili esas alınmalı. Bunun için dil bilgisinin sipariş kaydına yazılması gerekir.
Çok dilli bir panel, iyi çevrilmiş metinlerden değil, birbirini tutan katmanlardan doğar. Dil, para birimi, şablon ve URL ekseni aynı mantığı paylaşıyorsa yeni pazar açmak birkaç saatlik iştir; paylaşmıyorsa her yeni dil yeni bir teknik borç olur. Bu katmanların gerçek bir panelde nasıl bir arada durduğunu görmek için canlı demo üzerinden dil değiştirip uçtan uca bir sipariş akışını kendin dene.