Üç dilde yayın yapan bir ekip, her hafta aynı toplantıda aynı soruyu tekrar ediyor: bu haftanın yazısı hangi dilde önce çıkacak? Cevap genellikle "kim boşsa o yazar" oluyor, ki bu da altı ay sonra dil versiyonları arasında tuhaf bir dengesizlik yaratıyor; bir dilde kırk yazı varken diğerinde yirmi beş, ve hiçbiri bunun neden olduğunu tam hatırlamıyor. İçerik takvimi burada bir organizasyon aracı değil, teknik SEO kararlarının zamanlamasını taşıyan bir kayıt sistemi haline geliyor.
Tek dilli bir sitede takvim sadece yayın sıklığını ve konu sırasını taşır; çok dilli brief bu takvime pazar bazlı niyet satırı ekler. Çok dilli yapıda aynı takvim üç ayrı bilgiyi aynı anda taşımak zorunda: hangi konu, hangi dilde önce, ve diğer dil versiyonu ne zaman ona yetişecek. Bu üçüncü katman genellikle unutuluyor, çünkü kağıt üzerinde bir "yayın tarihi" sütunu yeterli görünüyor; ama kaynak dil değişiminin etkilerinde görüldüğü gibi, bir dil versiyonunun sürekli geriden gelmesi zamanla hreflang kümesinin dengesini de bozan bir alışkanlığa dönüşüyor; bu, kaynak dil değişiminin görünmez kalmasıyla aynı kökten gelir.
Tek takvim mi, dil başına ayrı takvim mi: takvim modeli kararı
İki dil versiyonu birbirine yakın hacimde yayın yapıyorsa tek bir ana takvim, her satırda dil sütunlarını yan yana taşıyarak yeterli olur. Bu model, aynı konunun her iki dilde de aynı satırda görünmesini sağlar; bir yazının Türkçe hali yayında, İngilizce hali taslakta olsa bile ikisi aynı satırda durur ve gecikme doğrudan görünür.
Üç veya daha fazla dil varsa, veya diller arasında konu örtüşmesi kısmi ise (bazı konular sadece belirli pazarlara özgüyse) tek takvim karmaşıklaşır; satırlar boş hücrelerle dolar ve hangi boşluğun kasıtlı, hangisinin unutulmuş olduğu ayırt edilemez hale gelir. Bu durumda dil başına ayrı takvim, ortak bir "konu havuzu" sayfasıyla birleştirilir: her konu bir kere havuza girer, sonra her dil kendi takviminde o konuyu ne zaman işleyeceğini işaretler. Havuz, konunun tekrar keşfedilmesini önler; ayrı takvimler ise her dilin kendi yayın ritmini korumasına izin verir.
Model seçimi aynı zamanda bir bakım maliyeti kararı. Tek takvim daha az dosya, daha az senkronizasyon riski anlamına gelir; diller arasındaki dengesizlik hemen görünür ama aynı satırda çok fazla bilgi sığdırma zorunluluğu gelir. Ayrı takvimler daha esnek ama koordinasyon için ekstra bir "konu havuzu" toplantısı gerektirir. İkinci modele geçmek için iyi bir kural: haftada toplam on iki'den fazla yayın yapılıyorsa veya dil sayısı üçü aşıyorsa ayrı takvim anlamlı hale gelir; bunun altında tek tablo fazlasıyla yeterli.
Hangi yazı hangi dilde önce yayınlanır: sıra kararı nasıl verilir
Sıra kararını rastgele bırakmak yerine üç soruya bağlamak daha güvenilir sonuç veriyor; bu, hangi sayfanın önce çevrileceği kararıyla aynı çerçevedir. Birincisi, hangi pazarda arama hacmi daha yüksek; bir konu belirli bir dilde çok daha sık aranıyorsa, o dil önce yazılır ve diğer dil onu takip eder. İkincisi, hangi dil versiyonunun mevcut otoritesi daha güçlü; güçlü bir dil versiyonuna eklenen yeni içerik, zayıf bir versiyona eklenenden daha hızlı indekslenip sıralanma eğiliminde olduğu için, stratejik önem taşıyan konular önce güçlü dile verilir. Üçüncüsü, hangi dilde yazarın veya kaynağın o konuya dair daha derin bilgisi var; yüzeysel bir çeviriyle yazılan versiyon, içerik kalitesi farkının anlattığı zayıf sürüm sorununu doğrudan üretir.
Bu üç kriter çoğu zaman aynı dili işaret etmez; arama hacmi bir dilde yüksekken uzmanlık başka dilde daha güçlü olabilir. Böyle bir çatışmada pratik çözüm, konuyu ikiye bölmek değil, önce yazan dile ekstra bir araştırma adımı eklemek: yazar kendi dilinde değilse, kaynak materyali toplarken ilgili pazarın gerçek arama davranışını da incelemesi istenir.
Bir dilin sürekli "ikinci" kalmasının kümülatif etkisi var. Altı ay boyunca aynı dil sürekli ikinci sıraya düşürülürse, o versiyonun yayın hacmi düşer, iç link ağı zayıflar ve Google o versiyonun otoritesini diğerine kıyasla daha düşük değerlendirmeye başlar. Sıra kararı bireysel yazı bazında değil, üç aylık dönemler halinde gözden geçirilmeli; hangi dilin kaç kez önce yazdığı takvimdeki bir özet satırında görünür tutulursa dengesizlik erken fark edilir.
Çeviri gecikmesi takvime nasıl işlenir: teslim tarihi ile yayın tarihi farkı
Takvimde en sık yapılan hata, "yayın tarihi" ile "çeviri teslim tarihi" için aynı hücreyi kullanmak. Kaynak dilde yazı Pazartesi yayınlanıyorsa, çeviri süreci o gün başlar ve genellikle üç ile yedi gün arasında sürer; bu süre takvimde ayrı bir sütun olarak görünmezse, ekip çevirinin ne zaman biteceğini tahmin etmek zorunda kalır ve tahmin çoğunlukla optimist çıkar.
Pratik çözüm iki ayrı tarih sütunu tutmak: "kaynak yayın tarihi" ve "hedef dil yayın tarihi". Aradaki fark sabit bir kural değil, konunun uzunluğuna ve çevirmenin iş yüküne göre değişebilir, ama takvimde görünür bir sayı olarak durması gerekiyor. İçerik briefi hazırlama sürecinde anlatılan yaklaşım burada devreye giriyor: brief kaynak dilde tamamlandığı gün çeviri süreci de aynı brief üzerinden başlatılabilir, bu da iki dil arasındaki gecikmeyi bir hafta değil iki üç güne indirir.
Çeviri teslim tarihi ile yayın tarihi arasına bir tampon süre koymak da sıklıkla atlanıyor. Çeviri teslim edilince doğrudan yayına giriyor, ama çeviri kalitesi kontrolü, iç link güncellemesi ve SEO meta verisi revizyonu için en az bir gün gerekiyor. Bu tampon takvimde ayrı bir adım olarak görünmezse, çeviri kalite sorunları ya gözden kaçıyor ya da yayın tarihi gecikiyor ve bu sefer kaynak-hedef dil farkı yeniden açılıyor.
Çeviri gecikmesinin başka bir boyutu da kaynak metnin yayından sonra güncellenmesi. Kaynak dilde küçük bir düzeltme yapılınca çevirinin de güncellenmesi gerekip gerekmediği çoğu ekipte netleştirilmiyor; hedef dil versiyonları kaynak metinden sessizce uzaklaşıyor. Takvime son güncelleme tarihi sütunu eklemek bu kayışmayı görünür kılıyor: kaynak dilde son güncelleme ile hedef dilin son güncelleme tarihi arasındaki fark büyüdükçe, o versiyonun güncel kalıp kalmadığı hızlıca anlaşılıyor.
Yayın senkronizasyonu: aynı gün mü, planlı gecikme mi
İki dil versiyonunu aynı gün yayınlamak kulağa en temiz çözüm gibi geliyor, ama pratikte çeviri kalitesini yayın hızına feda etme riskini taşıyor. Çevirmen kaynak metni henüz bitmemişken çalışmaya başlıyor, son dakika değişiklikleri hedef dile yansımıyor, ve sonuç iki sürüm arasında küçük ama fark edilebilir bir içerik uyumsuzluğu oluyor.
Planlı bir gecikme, örneğin üç ile beş gün arası, çoğu ekip için daha sürdürülebilir bir ritim kuruyor. Bu gecikme boyunca hreflang kümesi teknik olarak sorunsuz kalır; yeni dil henüz yoksa return tag de erken yazılmamalıdır.; karşılıklı referans zaten HTML head'de veya sitemap'te tanımlıdır ve sayfa henüz yayınlanmamış olsa bile, ikinci sayfa yayına girdiği anda referans aktif hale gelir. Asıl risk gecikmenin planlı olmaktan çıkıp kronik hale gelmesi; üç gün olması gereken fark aylar boyunca iki hafta olarak sürüklenirse, bu artık senkronizasyon değil ihmal olur.
Yayın senkronizasyon kararı içerik türüne göre de değişiyor. Zamana duyarlı konular (bir ürünün lansmanı, bir yasa değişikliği, sektördeki önemli bir gelişme) için eş zamanlı yayın mantıklı; kalite biraz düşse bile erken çıkmak o pencerede değer taşıyor. Evergreen içerik için gecikmeyi tolere etmek daha kolay; üç gün sonra yayınlanan eksiksiz bir çeviri, aynı gün yayınlanan acele bir çeviriden zamanla daha fazla trafik toplar.
Takvimde izlenmesi gereken alanlar: hangi sütunlar gerçekten işe yarar
Takvim şablonları genellikle konu, yazar ve tarih gibi temel alanlarla başlar, ama çok dilli yapıda bu üçü yetersiz kalıyor. Pratikte anlamlı fark yaratan sütunlar şunlar:
- Kaynak dil ve hedef dil(ler): hangi versiyon önce, hangileri onu takip ediyor
- Çeviri durumu: beklemede, çeviride, düzenlemede, yayına hazır
- Hedef yayın tarihi (her dil için ayrı): tek bir tarih değil, dil başına tarih
- İç link hedefleri: bu yazının hangi mevcut yazılara bağlanacağı; dil bazında ayrı olabilir, çünkü her dilin kendi yayında olan arşivi farklıdır
- Kaynak/uzmanlık notu: konuyu kimin, hangi dilde daha iyi bildiği
Bu alanlardan iç link hedefleri sütunu özellikle gözden kaçıyor. Bir dilde yayında olan otuz yazı varken diğerinde on beş yazı varsa, iki dilin iç link havuzu da farklıdır; aynı konunun her iki dil versiyonu birbirine kopyala yapıştır iç link listesiyle bağlanamaz, çünkü hedef sayfalardan biri henüz yayında olmayabilir.
Çeviri durumu sütunu basit görünüyor ama en sık tartışma yaratan alan da bu. "Yayına hazır" ne anlama geliyor: çeviri tamamlandı mı, yoksa kalite kontrolden de geçti mi? Ekip içinde bu tanımı önceden netleştirmek, gecikmelerin kaynağını hızlı bulmayı kolaylaştırıyor. Durum etiketleri ne kadar granüler olursa, takvim o kadar güvenilir bir zaman tahmini üretiyor.
Takvim kayması nasıl fark edilir ve düzeltilir
Kayma genellikle ansızın oluşmaz, haftalık birikimle büyür. Bir dilin bir hafta gecikmesi önemsiz görünür, ama on iki hafta sonra o dil versiyonu üç ay geride kalmış olabilir. Bunu erken yakalamanın en basit yolu, takvimde her dilin toplam yayınlanmış yazı sayısını ayrı bir özet satırında tutmak; sayılar arasındaki fark belirli bir eşiği (örneğin toplam yazının yüzde yirmisi) geçtiğinde bu bir uyarı sinyali sayılır.
Düzeltme, geride kalan dile bir "yakalama sprinti" ayırmak biçiminde işliyor: birkaç hafta boyunca yeni konu eklemeyi durdurup, birikmiş çeviri kuyruğunu eritmek. Bu sprint sırasında içerik önceliklendirme mantığı tekrar devreye girer, ama artık yeni konular arasında değil, birikmiş kuyruk içinde hangi yazının önce tamamlanacağına karar vermek için kullanılır. En değerli ve en trafikli konular kuyruğun başına alınır, niş veya düşük öncelikli konular arkada bırakılabilir.
Sprint dışında kayma riskini azaltan yapısal bir önlem var: her yeni yayın döneminde, bir sonraki konuyu seçmeden önce diller arasındaki yazı farkına bakmak. Fark ikiden büyükse yeni konu açmak yerine geciken çeviriyi tamamlamak önce geliyor. Bu kural uygulandığında yazı sayısı büyüdükçe denge bozulmak yerine korunuyor; ekibin hafızasına değil, takvim kuralına yaslanmış oluyor.
Editoryal takvim aracı seçimi: basit tablo ne zaman yeterli, ne zaman değil
İki ile üç dil ve haftada bir veya iki yazı hacminde, paylaşımlı bir tablo (Google Sheets veya benzeri) genellikle yeterli. Sütun sayısı arttıkça ve ekip büyüdükçe, bir proje yönetim aracına geçiş anlamlı hale gelir; asıl fark tablonun kendisinde değil, durum değişikliklerinin otomatik bildirim üretip üretmediğinde. Bir çevirmen "yayına hazır" durumuna geçtiğinde ekip bunu manuel kontrol etmek zorunda kalmıyorsa, gecikme fark edilme süresi kısalır.
Araç geçişi için iyi bir tetikleyici: aynı haftada üçten fazla dil versiyonu aynı anda aktifse veya beşten fazla kişi aynı takvimi güncelliyorsa, tablo yetersizleşiyor. Bildirim eksikliği, sürüm çakışması ve kimin hangi satırı değiştirdiğinin bilinmemesi bu eşiğin üstünde tekrar eden sorunlar haline geliyor. Aracın adı önemli değil; bir yazı birden fazla dil versiyonu için ayrı satırlar oluşturabilmeli ve her satıra dil bazlı durum atanabilmeli.
Hangi araç seçilirse seçilsin, kritik olan tek şey değişmiyor: her dilin yayın tarihi ayrı bir veri noktası olarak durmalı ve bu veri düzenli aralıklarla (haftalık veya iki haftalık) gözden geçirilmeli. Format kararında anlatıldığı gibi, blog formatı zaten sürekli üretim gerektiren bir taahhüt; bu taahhüdün dil versiyonları arasında dengeli kalması, takvimin görünmez ama en kritik işlevi.
Bir içerik takvimi ne kadar detaylı tasarlanırsa tasarlansın, gerçek testi haftalık gözden geçirme alışkanlığından geçiyor. Takvim doldurulup bir kenara bırakılan bir tablo değil, her hafta açılıp güncellenen, gecikmelerin erken görüldüğü bir çalışma aracı olarak kullanılırsa amacına hizmet ediyor.
Çok dilli bir yayın hattında en pahalı hata, tek bir yanlış yayın tarihi değil, fark edilmeden büyüyen kümülatif bir dengesizlik oluyor. Takvim bu dengesizliği erken yakalayan tek mekanizma; ne kadar sade tutulursa tutulsun, dil başına ayrı tarih ve durum takibi olmadan bu erken uyarı sistemi çalışmıyor.