Bir şirket global pazara açılıyor. Web sitesi sadece Türkçe. İngilizce, Almanca, Arapça versiyonlar gerekiyor. Geliştirici her dil için ayrı site kuruyor: site.com, site-en.com, site-de.com. SEO karmaşık, içerik senkronizasyonu yok, bakım maliyeti 3 kat. Sorun yaklaşım: çok dilli mimari yok, her dil ayrı proje gibi yönetiliyor.
Aynı içeriği farklı dillerde sunan, tek mimari altında yönetilen yapı. İyi mimari dil değişimini 1 tıklamada yapar, SEO korunur, içerik merkezi yönetilir. Kötü mimari: her dil için ayrı bakım, tutarsız içerik, kayıp trafik.
URL yapısı, dil algılama stratejileri, içerik yönetimi, SEO optimizasyonu ve performans dengeleri. Ayrıca RTL (sağdan sola) dil desteği, çeviri yönetimi ve farklı pazar stratejileri.
URL Yapısı: Üç Yaklaşım
URL yapısı kritik. Üç ana yaklaşım var: subdomain, subdirectory, ccTLD. Her birinin avantajı ve bedeli farklı.
Subdomain yaklaşımı: her dil ayrı subdomain alır. en.site.com (İngilizce), de.site.com (Almanca), ar.site.com (Arapça). Her dil bağımsız çalışır, ayrı sunucuda host edebilirsiniz, farklı CDN kullanabilirsiniz. SEO gücü dağılır—her subdomain ayrı domain gibi görülür, backlink paylaşılmaz.
Subdirectory yaklaşımı: her dil ayrı klasör. site.com/en/, site.com/de/, site.com/ar/. SEO gücü birleşir, backlink tüm dillere fayda sağlar, yönetim kolay. Tüm diller aynı sunucuda—farklı pazar için ayrı hosting yapamıyorsunuz. Google bu yaklaşımı öneriyor.
ccTLD yaklaşımı: her dil ayrı domain. site.com (global/İngilizce), site.de (Almanca), site.com.tr (Türkçe). Yerel SEO güçlü, kullanıcı güveni yüksek, her pazar bağımsız. Her domain ayrı maliyet, SEO gücü dağılır, yönetim karmaşık.
Hangi yaklaşım? Subdirectory çoğu durumda en iyi. SEO dostu, yönetimi kolay, maliyet düşük. ccTLD büyük pazarlar için (Almanya, Fransa)—subdomain teknik gereksinim varsa (farklı sunucu, farklı CMS).
Varsayılan dil: site.com ne gösterir? İki yaklaşım: 1) Varsayılan dil (Türkçe) site.com'da, diğer diller /en/, /de/. 2) Tüm diller subdirectory'de: /tr/, /en/, /de/, site.com redirect eder. İkinci yaklaşım daha temiz—tüm diller eşit.
Dil Algılama ve Yönlendirme
Kullanıcı site.com'a geldi. Hangi dili gösterelim? Dil algılama stratejisi: tarayıcı dili, IP lokasyonu, kullanıcı tercihi, cookie.
Tarayıcı dili: Accept-Language header'ı okur. Kullanıcı tarayıcısı Almanca, site /de/ gösterir. Basit, hızlı. Her zaman doğru değil: kullanıcı Almanya'da ama İngilizce konuşuyor.
IP lokasyonu: kullanıcı IP'sinden ülke tespit eder. Almanya IP'si, /de/ gösterir. Daha doğru—VPN kullanıcıları yanlış yönlendirilir. GeoIP veritabanı (MaxMind) kullanılır.
Kullanıcı tercihi: kullanıcı dil seçti, cookie'ye kaydedildi. Bir sonraki ziyarette aynı dil gösterir. En doğru yöntem, ilk ziyarette çalışmaz.
Hibrit yaklaşım: ilk ziyaret tarayıcı dili + IP lokasyonu, kullanıcı değiştirirse cookie'ye kaydet. Sonraki ziyaretlerde cookie öncelikli.
Otomatik yönlendirme: kullanıcı site.com'a geldi, otomatik /de/'ye yönlendirildi. SEO için 302 (temporary) redirect kullanın, 301 (permanent) değil. Google her dili ayrı indexlemeli.
Dil seçici: header'da bayrak veya dropdown. Kullanıcı manuel değiştirebilir. Bayrak tartışmalı: dil ≠ ülke. İngilizce ABD, İngiltere, Avustralya'da konuşulur, hangi bayrak? Dil adı daha net: "English", "Deutsch", "العربية".
İçerik Yönetimi ve Çeviri
İçerik nasıl yönetilir? İki yaklaşım: merkezi içerik + çeviri, veya dil başına ayrı içerik.
Merkezi içerik: bir içerik ID'si, birden fazla dil versiyonu. Veritabanında: content_id, language, title, body. İçerik senkronize, bir yerden yönetim. Tüm diller aynı yapıda—yerel uyarlama zor.
Dil başına ayrı içerik: her dil bağımsız. Almanca site Alman pazarına özel içerik, Türkçe site Türk pazarına özel. Tam esneklik, yerel uyarlama. İçerik senkronizasyonu manuel, tutarsızlık riski.
Çeviri yönetimi: kim çeviriyor? Üç seçenek: profesyonel çevirmen, makine çevirisi, hibrit.
Profesyonel çevirmen: kaliteli, doğal, kültürel uyarlama. Pahalı, yavaş. Sayfa başı 50-200 TL, 1000 sayfa = 50.000-200.000 TL. Büyük siteler için sürdürülebilir değil.
Makine çevirisi: Google Translate, DeepL. Hızlı, ucuz, ölçeklenebilir. Kalite düşük, teknik terimler yanlış, kültürel bağlam yok. Kullanıcı deneyimi bozulur.
Hibrit: makine çevirisi + insan düzeltmesi. Makine ilk taslak oluşturur, çevirmen düzeltir. Maliyet %50 azalır, hız 2x artar. Optimal yaklaşım.
Çeviri araçları: i18n kütüphaneleri (i18next, react-intl), TMS (Translation Management System) platformları (Lokalise, Crowdin). Çevirmen web arayüzünden çeviri yapar, kod otomatik güncellenir.
SEO ve Hreflang
SEO kritik. Google her dili ayrı indexlemeli, doğru dil doğru kullanıcıya gösterilmeli. Hreflang tag bu işi yapar.
Hreflang nedir? HTML tag, Google'a "bu sayfa şu dilde, alternatif diller şunlar" der. Örnek: <link rel="alternate" hreflang="en" href="https://site.com/en/about" />. Her sayfada tüm dil alternatifleri listelenir.
Hreflang formatı: dil kodu (ISO 639-1) + opsiyonel ülke kodu (ISO 3166-1). "en" (İngilizce genel), "en-US" (Amerikan İngilizcesi), "en-GB" (İngiliz İngilizcesi). Ülke kodu ne zaman gerekli? Dil aynı ama içerik farklıysa evet.
X-default: varsayılan dil. Kullanıcı dili sitede yoksa, x-default gösterir. <link rel="alternate" hreflang="x-default" href="https://site.com/en/" />. Genellikle İngilizce x-default.
Hreflang yerleşimi: HTML head'de veya XML sitemap'te. HTML head daha yaygın, her sayfada tag. XML sitemap büyük siteler için (10.000+ sayfa), merkezi yönetim.
Yaygın hatalar: 1) Hreflang eksik veya yanlış. 2) Self-referencing yok: sayfa kendi dilini de listelemeli. 3) Bidirectional yok: /en/ sayfası /de/'yi listeliyor ama /de/ sayfası /en/'i listelemiyor. 4) URL yanlış: hreflang'deki URL 404 veriyor.
Google Search Console: hreflang hatalarını gösterir. "International Targeting" bölümü, hreflang raporu. Hataları düzeltin, Google doğru indexler.
Canonical tag: her dil kendi canonical'ına işaret eder. /en/about canonical'ı https://site.com/en/about. /de/about canonical'ı https://site.com/de/about. Çapraz canonical yapmayın.
RTL Dil Desteği
Arapça, İbranice gibi diller sağdan sola (RTL) yazılır. RTL desteği sadece metin yönü değil, tüm layout'u etkiler. Menü sağda, logo solda değil sağda, scroll bar solda.
HTML dir attribute: <html dir="rtl" lang="ar">. Tarayıcı otomatik RTL davranışı uygular: metin sağdan başlar, scroll bar solda. Yeterli değil, CSS de ayarlanmalı.
CSS logical properties: left/right yerine start/end kullanın. margin-left: 20px yerine margin-inline-start: 20px. RTL'de otomatik sağa döner. Flexbox ve grid RTL'de otomatik ters çalışır.
Görseller ve ikonlar: ok ikonları ters çevrilmeli. Sağ ok (→) RTL'de sol ok (←) olmalı. Tüm görseller ters çevrilmez. Logo, ürün fotoğrafı aynı kalır.
Sayılar ve tarihler: Arapça'da sayılar LTR (soldan sağa). "2026" RTL'de de "2026", "6202" değil. Tarih formatı değişir: İngilizce "March 12, 2026", Arapça "12 مارس 2026".
Form alanları RTL'de sağ hizalı. Placeholder metni sağdan başlar. E-posta, URL gibi alanlar LTR kalır—dir="ltr" ile override edin.
Gerçek Arapça konuşan kullanıcı ile test edin. Otomatik RTL yeterli değil, kültürel bağlam önemli. Renk, görsel, mesaj yerel pazara uygun mu?
Performans ve Yükleme
Performans zorlaşır. Her dil ayrı çeviri dosyası, font, içerik. Yükleme süresi artar, optimizasyon şart.
Çeviri dosyası boyutu: JSON veya YAML formatında çeviriler. Küçük site 10-50 KB, büyük site 500 KB - 1 MB. Tüm diller tek dosyada olmasın, dil başına ayrı dosya. Kullanıcı Almanca seçti, sadece Almanca dosyası yüklensin.
Lazy loading: çeviri dosyası lazy loading ile yüklenebilir. İlk yükleme varsayılan dil, kullanıcı dil değiştirince yeni dosya yüklenir. Dil değişimi gecikmeli olur, kullanıcı fark eder.
Font yükleme: her dil farklı font gerektirebilir. Arapça için Noto Sans Arabic, Çince için Noto Sans SC. Font dosyası 200-500 KB. Subset kullanın: sadece kullanılan karakterler. Google Fonts subset parametresi: &text=مرحبا.
CDN ve edge caching: çeviri dosyaları CDN'de cache'lenir. Kullanıcı Almanya'dan geldi, Almanca dosya Almanya edge'inden yüklenir. Latency azalır.
Server-side rendering (SSR): çeviri server'da yapılır, HTML hazır gelir. Client-side rendering (CSR) yerine SSR daha hızlı ilk yükleme sağlar. Bedeli? Server yükü artar, cache stratejisi gerekir.
Static site generation (SSG): her dil için statik HTML oluşturur. Build sırasında çeviri yapılır, runtime yok. En hızlı yöntem—içerik değiştiğinde rebuild gerekir.
Kullanıcı Deneyimi ve Yerelleştirme
Sadece çeviri değil, yerelleştirme (localization). Kültürel bağlam, yerel tercihler, pazar özellikleri.
Tarih ve saat formatı: Türkiye'de "12.03.2026", ABD'de "03/12/2026", ISO formatı "2026-03-12". JavaScript: new Date().toLocaleDateString('tr-TR').
Para birimi: Türkiye'de "₺199", Almanya'da "€19", ABD'de "$19". Sadece sembol değil, format da değişir: "1.234,56" (Avrupa), "1,234.56" (ABD). Döviz kuru dinamik mı, statik mi? E-ticaret sitesinde dinamik şart.
Ölçü birimleri: Türkiye'de kilogram, ABD'de pound. Sıcaklık: Celsius vs Fahrenheit. Mesafe: kilometre vs mil. Dönüşüm otomatik olmalı.
Görseller ve renkler: kültürel bağlam. Beyaz Batı'da saflık, Çin'de yas. Kırmızı Çin'de şans, Güney Afrika'da yas. Görsellerde insan varsa, yerel etnik görünüm tercih edilmeli.
Yasal gereksinimler: GDPR (Avrupa), CCPA (Kaliforniya), KVKK (Türkiye). Her pazarda farklı gizlilik politikası, çerez onayı. Avrupa'da çerez banner zorunlu, ABD'de değil.
Ödeme yöntemleri: Türkiye'de kredi kartı + havale, Almanya'da SEPA, Hollanda'da iDEAL, Çin'de Alipay. Yerel ödeme yöntemi dönüşümü artırır.
Teknik Mimari ve Veritabanı
Veritabanı yapısı nasıl olmalı? İki yaklaşım: tek tablo + dil sütunu, veya dil başına ayrı tablo.
Tek tablo yaklaşımı: pages tablosu, language sütunu. Her satır bir dil versiyonu. Basit, sorgu kolay. Dil sayısı arttıkça tablo şişer, performans düşer.
Ayrı tablo yaklaşımı: pages (dil bağımsız), pages_translations (çeviriler). pages tablosu: id, slug, created_at. pages_translations tablosu: page_id, language, title, body. Ölçeklenebilir, performans iyi. Join gerekir, sorgu karmaşık.
NoSQL yaklaşımı: MongoDB gibi document database. Her document bir sayfa, içinde tüm diller. { id: 1, slug: "about", translations: { en: {...}, de: {...}, ar: {...} } }. Esnek, hızlı—ilişkisel veri zor.
Cache stratejisi: dil başına ayrı cache. /en/about ve /de/about ayrı cache key. Cache invalidation: İngilizce içerik değişti, sadece /en/* cache'i temizlenir, /de/* etkilenmez.
API tasarımı: dil parametresi nasıl geçilir? Üç yöntem: 1) URL'de: /api/en/posts. 2) Query string'de: /api/posts?lang=en. 3) Header'da: Accept-Language: en. URL yöntemi en net, cache dostu.
Yaygın Hatalar
Otomatik çeviri kullanımı: Google Translate ile tüm site çevrilmiş, kalite kötü. Profesyonel çevirmen veya hibrit yaklaşım gerekir.
Hreflang eksik: Google her dili ayrı site sanıyor, duplicate content cezası. Hreflang tag ekle, Google Search Console kontrol et.
RTL desteği yok: Arapça site LTR gibi görünüyor, kullanılamaz. dir="rtl", CSS logical properties, test.
Dil algılama yok: kullanıcı Almanya'dan geldi, Türkçe site gösteriliyor. IP lokasyonu + tarayıcı dili, otomatik yönlendirme.
İçerik senkronizasyonu yok: İngilizce site güncel, Almanca site 6 ay eski. Merkezi içerik yönetimi, çeviri workflow.
Performans ihmal edilmiş: tüm dil dosyaları yükleniyor, sayfa 10 saniyede açılıyor. Dil başına ayrı dosya, lazy loading, CDN.
Yerelleştirme yok: tarih formatı yanlış, para birimi dolar, ödeme yöntemi yerel değil. Tam yerelleştirme, kültürel uyarlama.
Test ve Doğrulama
Canlıya alınmadan önce test edilmeli. Her dil ayrı test: içerik, SEO, performans, kullanılabilirlik.
İçerik testi: çeviri doğru mu? Teknik terimler yanlış mı? Kültürel bağlam uygun mu? Native speaker ile test edin—makine çevirisi yeterli değil.
SEO testi: hreflang doğru mu? Google Search Console hata gösteriyor mu? Her dil ayrı indexleniyor mu? Canonical tag doğru mu?
Performans testi: her dil için Lighthouse skoru. Çeviri dosyası boyutu ne kadar? Font yükleme süresi? LCP, FID, CLS metrikleri?
Dil değişim testi: kullanıcı dil değiştirdi, doğru sayfaya yönlendiriliyor mu? Cookie kaydediliyor mu? Sonraki ziyarette aynı dil gösteriliyor mu?
RTL testi: Arapça site düzgün görünüyor mu? Layout ters mi? Görseller doğru mu? Gerçek Arapça kullanıcı ile test edin.
Bakım ve Güncelleme
Sürekli bakım gerektirir. Yeni içerik eklendiğinde, tüm dillere çevrilmeli. Çeviri süreci nasıl yönetilir?
Çeviri workflow: 1) İçerik oluşturulur (Türkçe). 2) Çeviri talebi açılır. 3) Çevirmen çevirir. 4) Editör kontrol eder. 5) İçerik yayınlanır. TMS (Translation Management System) bu süreci otomatikleştirir.
Çeviri durumu: hangi içerik hangi dilde mevcut? Dashboard: İngilizce %100, Almanca %80, Arapça %60. Eksik çeviriler vurgulanır, öncelik belirlenir.
Versiyon kontrolü: İngilizce içerik güncellendi, Almanca çeviri eski kaldı. Sistem uyarı verir: "Almanca çeviri güncel değil, yeniden çeviri gerekiyor."
Çeviri belleği: daha önce çevrilmiş cümleler kaydedilir. Aynı cümle tekrar çıktığında, otomatik önerilir. Tutarlılık artar, maliyet azalır.
Glossary: teknik terimler, marka isimleri, özel kelimeler. Her dilde standart çeviri. "Dashboard" Almanca'da "Dashboard" mı, "Kontrollpanel" mi? Glossary belirler, tutarlılık sağlar.
Gerçek sürtünme: editör her dil için ayrı görsel yükler, çevirmen teknik terimleri farklı yorumlar, geliştirici cache kuralını her dile ayrı ayarlar. Merkezi yönetim yoksa her ekip üyesi farklı davranır—tutarsızlık kaçınılmaz.