Çok Dilli CMS Tasarımı: TR–EN–DE–RU İçerikleri Tek Panelden Yönetmek

Multilingual CMS mimarisinde hedef; içerikleri farklı dillere bölmekten çok, tek bir içerik gerçeği (single source of truth) etrafında çoklu dil varyasyonlarını yönetmektir. Bunun için iki ana model kullanılır: 1. Content type bazlı locale alanları (locale fields) 2. Her dil için ayrı entry yaklaşımı (separate entries per locale) Hangisini seçeceğiniz; içerik tipi sayısı, ilişki (relation) yoğunluğu, editoryal ekip kapasitesi ve SEO/URL stratejinizle doğrudan ilgilidir.

Çok dilli CMS tasarımı nasıl olmalı? (AEO – Soru formatı)

Kısa cevap: Önce URL/locale stratejisini netleştir, sonra “locale fields mi ayrı entry mi?” karar ver; lokalize alanları standartlaştır; çeviri workflow’u, preview ve hreflang QA ile süreci panel içine taşı. • Eğer içerikler birbirine sık bağlıysa (otel: oda→paket→destinasyon) locale fields avantajlı olabilir. • Eğer her dilde içerik çok farklıysa (pazar bazlı kampanya, farklı teklif/CTA) ayrı entry yaklaşımı daha kontrollü olabilir.

Bu karar, panelinizin “yaşanabilirliği”ni belirler. Yanlış seçim; içerik ekibini yorar, geliştirici ekibe koşul yazdırır ve SEO hatalarını artırır.

Locale fields yaklaşımı (tek entry, çok dil alanı)

Artıları • Relation’lar daha kolay yönetilir (tek entity, çok dil alanı). • “TR güncellendi mi?” kontrolü tek ekranda yapılır. • Medya/struktur ortaksa hızlıdır. Eksileri • Panel karmaşıklaşabilir (çok alan, çok tab). • Dil bazlı “çok farklı içerik” durumunda zorlaşır. • Slug/URL gibi alanların dil bazında yönetimi net kural ister.

Ayrı entry yaklaşımı (her dil ayrı kayıt)

Artıları • Her dil bağımsız gelişir (pazar bazlı içerik). • Workflow, yayın ve kalite kontrol dil bazında daha net ayrılır. • “DE içerik farklı CTA kullanacak” gibi durumlar kolaydır. Eksileri • Relation’lar çoğalır (eşleme ihtiyacı). • “Asıl içerik hangisi?” karmaşası doğabilir. • Senkronizasyon (TR değişti, EN/RU ne oldu?) iyi yönetilmezse dağılır.

Karar tablosu (TR–EN–DE–RU için pratik rehber)

Çok dilli CMS’de en kritik kullanım anı şudur: içerik ekibi “EN sayfayı nasıl görünecek?” diye bakmak ister. Eğer preview yoksa; hatalar canlıda görülür.

Preview tasarımı için minimum gereksinimler

• •Locale seçimi (TR/EN/DE/RU)
• •Draft preview (yayın öncesi)
• •“Eksik çeviri” uyarısı (publish gate)
• •Slug ve meta kontrol paneli (hızlı QA)

Çok dilli projelerde en büyük operasyonel yük, çeviriyi panel dışında yönetmektir. Excel ve e-posta ile süreç yürüdüğünde; hangi içerik “çeviri bekliyor”, hangisi “QA bekliyor” bilinmez. Panel içi workflow; içerik üretimini queue mantığıyla yönetir.

Çeviri süreci (iç ekip, ajans, makine çeviri)

• •İç ekip: marka tonu yüksek, hız orta
• •Ajans: kapasite yüksek, brief gerektirir
• •Makine + edit: hız yüksek, QA şart

İdeal pratik: makine çeviriyi “taslak” olarak üretip, editoryal ekip veya ajansla lokalizasyon katmanı eklemek (özellikle CTA ve kültürel referanslarda).

CMS içinde “çeviri bekleyenler” view’ları

Panelde şu görünümler operasyonu dramatik şekilde rahatlatır: • “EN missing fields” (title/body/meta/CTA eksikleri) • “DE ready for QA” • “RU published but outdated” (TR güncellendi, RU geride) • “Needs legal/compliance review” (KVKK hassas içerik)

Hangi alanlar için ayrı dil alanı açmalıyım? (AEO – Soru formatı)

Kısa cevap: Kullanıcıya görünen her metin ve SEO sinyali üreten her alan lokalize edilmelidir: title, slug, body, meta, CTA; ayrıca navigasyon etiketleri ve schema metinleri.

Lokalize edilmesi önerilen alanlar: • Title/H1, body, summary • Slug (dil stratejinize göre) • Meta title/description, OG metinleri • CTA metinleri (özellikle pazara göre) • FAQ soruları/cevapları • Otel: oda özellikleri, paket dahil olanlar, destinasyon açıklamaları

Otel projelerinde relation yoğunluğu (oda/paket/destinasyon) ve sezon baskısı; B2B projelerde ise hizmet/case/lead funnel içeriği ön plandadır. Her ikisinde de ortak risk: SEO uyumsuzluğu (hreflang, canonical, slug) ve operasyonel dağınıklık.

Otel için pratik öneriler

• •Oda/paket/destinasyon için locale fields çoğu zaman daha stabil (relation azalarak yönetilir).
• •Kampanya içerikleri pazara göre farklıysa ayrı entry daha iyi olabilir.
• •Destinasyon isimleri ve medya; dil bazında kural setiyle yönetilmeli (örn. alt text/OG).

B2B için pratik öneriler

• •Service sayfalarında CTA’lar pazara göre değişebilir: ayrı entry veya locale field + CTA override.
• •Case içeriklerinde KPI ve kanıt metinleri “çeviri + uyarlama” gerektirir (lokalizasyon).
• •Blog içeriklerinde “outdated” flag’i en çok değer üreten kontrol mekanizmasıdır.

Çok dilli CMS kurgusu olmayan projelerde çeviri ve güncelleme süreçleri genellikle Excel + e-posta ile yürür; bu da ciddi operasyonel yük ve hata üretir. Fark yaratan şey; çeviriyi “bir dosya işi” değil, panel içinde yönetilen bir süreç (queue + status + QA) olarak ele almaktır. Böyle kurgulanan projelerde yeni dil eklemek ve mevcut içeriği güncellemek çok daha öngörülebilir hale gelir.

TR–EN–DE–RU içerikleri tek panelden yönetmek; hem operasyonel hızı artırır hem de SEO/lokalizasyon hatalarını azaltır. Doğru model seçimi (locale fields vs ayrı entry), sağlam workflow ve preview/QA katmanı ile; çok dilli büyüme sürdürülebilir bir sisteme dönüşür.