Çok Dilli Web Sitesi Nasıl Kurulur?

Çok dilli bir site, aynı sayfaların başka dillerde kopyası değildir. Her dil sürümü kendi okuruna, kendi pazarının alışkanlıklarıyla konuşmalı; arama motorları da hangi sayfanın hangi dilde ve hangi kitle için olduğunu net olarak anlayabilmelidir. Bu yazı, kurulum kararlarını sırasıyla ele alıyor.

Önce karar: dil mi hedefliyorsunuz, ülke mi?

"İngilizce site" ile "Birleşik Krallık sitesi" aynı şey değildir. İlki dil hedefler; ikincisi ülkeye özgü fiyat, kargo, yasal metin ve iletişim bilgisi gerektirir. Google, kitleyi belirlerken ülke kodlu alan adlarının yanında yerel adres ve telefon, yerel dil ve para birimi gibi sinyallere de bakıyor 1.

Pratik bir ayrım:

• Yalnız dil farkı varsa (aynı ürün, aynı fiyat, aynı teslimat): dil sürümleri yeterli.
• Ülkeye göre ticari fark varsa (para birimi, vergi, kargo, iade koşulu): dil ve ülke birlikte planlanmalı; örneğin Almanya ve İsviçre için iki ayrı Almanca sürüm gerekebilir.

Hedef listeyi baştan yazmak, sonraki tüm kararları (URL, içerik bütçesi, yasal sayfalar) belirler. AB'deki tüketicilere satış yapacaksanız erişilebilirlik yükümlülüklerini de bu aşamada değerlendirin; ayrıntılar Avrupa Erişilebilirlik Yasası yazısında.

URL yapısı seçenekleri

Google, her dil sürümü için çerez ya da tarayıcı ayarıyla içeriği değiştirmek yerine ayrı URL kullanılmasını öneriyor ve seçenekleri şöyle karşılaştırıyor 1:

Çoğu kurumsal ve e-ticaret sitesi için alt klasör yapısı, tek alan adı, tek yönetim paneli ve tek SSL sertifikasıyla en az bakım yükünü getirir. Ülke kodlu alan adları ise yerel bir şirket kimliği ve ayrı bir operasyon gerektiğinde anlamlıdır. Google, URL'lerde yerel dildeki kelimeleri kullanmanın da sorun olmadığını belirtiyor; bu durumda URL'lerde UTF-8 kodlaması kullanılmalı 1.

hreflang ve lang: temel bilgiler

hreflang, bir sayfanın diğer dil ve bölge sürümlerini arama motoruna bildiren işarettir. Google'ın dokümanındaki temel kurallar 2:

• Üç yöntemden biri kullanılır: sayfa başlığındaki bağlantı etiketleri, HTTP üst bilgisi (PDF gibi HTML olmayan dosyalar için) veya site haritası.
• Her dil sürümü kendisini ve diğer tüm sürümleri listelemeli. İki sayfa birbirini göstermezse işaretler yok sayılır.
• Dil kodu ISO 639-1 biçiminde yazılır, isteğe bağlı olarak ISO 3166-1 Alpha 2 bölge koduyla birleştirilir (örneğin en, en-GB, de-CH).
• x-default değeri, kullanıcının diline uyan bir sürüm olmadığında gösterilecek sayfayı (çoğunlukla dil seçim sayfasını) belirtir.

Önemli bir ayrıntı: Google, sayfanın dilini hreflang ya da HTML lang özniteliğinden değil, kendi algoritmalarıyla belirliyor 2. Yine de lang özniteliğini atlamayın. W3C, her sayfanın varsayılan dilinin html öğesindeki lang özniteliğiyle bildirilmesini ve sayfa içinde dil değiştiğinde ilgili öğeye ayrıca lang eklenmesini öneriyor 5. Ekran okuyucular doğru telaffuz için bu bilgiye dayanır. Arapça gibi sağdan sola yazılan diller ekleyecekseniz yazı yönünün dilden ayrı olarak işaretlenmesi gerektiğini de unutmayın 5.

Çeviri, yerelleştirme ve makine çevirisi

Çeviri metni bir dilden diğerine aktarır. Yerelleştirme ise sayfayı hedef pazara uyarlar: örnekler, görseller, birimler, yasal metinler, iletişim bilgisi, hatta ürün seçkisi. "Ücret" yerine "fiyat" mı denmeli, kampanya dili o kültürde nasıl karşılanır, hangi ödeme yöntemleri yaygındır gibi sorular yerelleştirmenin konusudur.

Google iki noktada açık:

• Yalnız iskeleti çevirmeyin. Menü ve alt bilgi gibi kalıp metni çevirip asıl içeriği tek dilde bırakmak, aynı içeriğin arama sonuçlarında farklı dillerde kalıp metinle birden çok kez görünmesine ve kötü bir kullanıcı deneyimine yol açabilir. Google, her sayfada içerik ve gezinme için tek dil kullanılmasını ve yan yana çevirilerden kaçınılmasını öneriyor 1.
• Ölçekli otomatik çeviriye dikkat. Spam politikaları, çeviri gibi otomatik dönüşümlerle kullanıcıya az değer katan çok sayıda sayfa üretmeyi ölçekli içerik kötüye kullanımı örnekleri arasında sayıyor. Politika, içeriğin nasıl üretildiğinden bağımsız olarak kullanıcıya değer katıp katmadığına bakıyor 3.

Pratik yaklaşım: makine çevirisini ilk taslak için kullanabilirsiniz, ama hedef dili anadili olarak konuşan bir editör metni gözden geçirmeli. Özellikle ürün açıklamaları, yasal metinler, form hata mesajları ve satın alma adımları insan kontrolünden geçmeden yayına alınmamalı. Gözden geçirilmemiş bir dil sürümünü yayına almak yerine o dili bir süre ertelemek çoğu zaman daha iyi sonuç verir.

Dil değiştirici nasıl tasarlanmalı?

Google, kullanıcıyı tahmin edilen diline göre başka bir dil sürümüne otomatik yönlendirmekten kaçınmayı öneriyor; bu yönlendirmeler hem kullanıcıların hem arama motorlarının tüm sürümleri görmesini engelleyebilir. IP konum analizinin güvenilir olmadığını ve Google taramalarının çoğunun ABD'den yapıldığını da belirtiyor 1. W3C ise tarayıcı tercihine göre bir dil önermenin yanında her sayfada dili kolayca değiştirmeyi sağlayan bağlantılar verilmesini öneriyor 4.

Bu iki kaynaktan çıkan tasarım kuralları:

• Görünür olsun. W3C'ye göre dil bağlantıları gizlenmemeli; kullanıcı anlamadığı bir dilde sayfaya düşmüş olabilir 4. Başlıkta ve mobil menüde aynı yerde durmalı.
• Dil adını kendi dilinde yazın. "Almanca" değil "Deutsch", "Fransızca" değil "Français" 4.
• Bayrak kullanmayın. Bazı ülkelerde birden çok dil konuşulur, bazı diller birçok ülkede konuşulur; bayrak yalnız içerik gerçekten ülkeye göre değişiyorsa anlamlıdır 4.
• Aynı sayfanın karşılığına götürün. Kullanıcıyı ana sayfaya değil, okuduğu sayfanın diğer dildeki sürümüne gönderin. Karşılık yoksa bunu açıkça belirtin.
• Seçimi hatırlayın, zorlamayın. Kullanıcının seçtiği dili sonraki sayfalarda hatırlamak W3C'nin önerileri arasında 4; öneri bandı gösterecekseniz kapatılabilir olsun ve kendiliğinden yönlendirmesin.

Para birimi, tarih ve ölçü biçimleri

Aynı bilgi farklı pazarlarda farklı yazılır. Türkçede 1.250,50 olarak yazılan bir sayı İngilizcede 1,250.50 olarak okunur; 03.10.2026 tarihi ABD okuru için başka bir güne işaret edebilir. Unicode'un CLDR projesi tarih, saat, sayı, para birimi, ölçü birimi, sıralama ve çoğul biçimleri için dile ve bölgeye özgü verileri sağlıyor ve büyük işletim sistemleri ile tarayıcılarda kullanılıyor 6.

Bu yüzden biçimleri elle yazmak yerine, kullandığınız platformun ya da yazılım kütüphanesinin yerel ayar (locale) desteğini kullanın. Kontrol edilmesi gerekenler:

• Para birimi simgesi ve konumu, ondalık ve binlik ayırıcı
• Tarih ve saat biçimi, haftanın ilk günü
• Ölçü birimleri (metrik veya İngiliz ölçü sistemi), beden tabloları
• Adres ve telefon formu alanları (posta kodu biçimi, il alanı zorunluluğu)
• Çoğul ekleri ve sayıya bağlı cümleler ("1 ürün", "3 ürün")

İçerik yönetimi iş akışı

Çok dilli sitelerde en sık sorun, ilk yayından sonra dillerin birbirinden kopmasıdır: Türkçe sayfa güncellenir, İngilizcesi eski kalır. Bunu önlemek için iş akışını baştan kurun.

1. Kaynak dili belirleyin. Hangi dilin "ana" metin olduğunu ve diğerlerinin ondan türetileceğini yazın.
2. Terim sözlüğü hazırlayın. Marka adları, ürün terimleri ve çevrilmeyecek kelimeler için ortak bir liste tutun.
3. İçerik modelini dile göre kurun. CMS'te her sayfa ve ürünün dil sürümlerinin birbirine bağlı olduğundan emin olun; headless CMS ya da eklenti tabanlı çözümlerde bu ilişki farklı kurulur.
4. Çeviri durumunu izleyin. Her dil sürümü için "çevrildi, gözden geçirildi, yayında, kaynak değişti" gibi durumlar tanımlayın.
5. Eksik çeviri politikası belirleyin. Çevrilmemiş sayfa o dilde yayına alınmasın; karışık dilli sayfa üretmeyin 1.
6. hreflang'ı otomatik üretin. Sürümler eklendikçe ve kaldırıldıkça karşılıklı bağlantıların elle değil sistem tarafından güncellenmesini sağlayın 2.
7. Yayın öncesi her dili test edin. Formlar, e-postalar, hata mesajları ve ödeme adımları dahil her dilin baştan sona çalıştığını kontrol edin.

Çok dilli bir site kurmayı ya da mevcut sitenize dil eklemeyi planlıyorsanız çok dilli web sitesi hizmet sayfasında kurulum kapsamını, ihracat yapan işletmelere özgü ihtiyaçları da sanayi ve ihracat sayfasında bulabilirsiniz.