Bu hatanın otuz yılda farklı kılıklara büründüğünü gördüm. Doksanların ortasında çok dilli CD-ROM’lar üretiyorduk, bir proofreader İstanbul’da imza atıyordu, sonra İtalyan distribütör arayıp ana menüdeki İtalyanca satırın şaka gibi okunduğunu söylüyordu. Metin doğruydu. Etrafındaki bağlam değildi. Sistemin bunu bilmesinin bir yolu yoktu, bilen insanlar da çoktan bir sonraki işe geçmişti.
Bu sorunun bugünkü hâli bir içerik hattı. Editoryal işi otomatikleştirmeye para ödüyorsun, ilk elli yazıyı sorunsuz atlatıyorsun, sonra hattın okuma ekibinin aslında okumadığı bir dilde utanç verici bir şey yayımladığını fark ediyorsun. Ajans sana söylemiyor, çünkü ajans da fark etmedi.
Bizim iki dilli WordPress hattımız yüz altmış günde üç editoryal kuralı yıktı. Her birinden sonra eklediğimiz çok dilli yayın kapıları bir kahve molasında okuyabileceğin kısa Python betikleri. Çok dilli bir WordPress sistemini birisine emanet ediyorsan, bu yazıda anlatacaklarım, o kişiye sorman gereken soruların hamuru.
Bir hat ne kadar ciddi yayımlamayı reddettiğiyle ölçülür
Söz konusu hat bizim. The WP Clan sitelerinde 4 Haziran 2026’dan beri her gün bir yazıyı İngilizce ve Türkçe yayımlıyor. Yazıyı yazdığım an itibarıyla moratorium dosyası yüz elli beş yazıyı kapsıyor. Yüz altmış günde üç yüz on yayımlanmış içerik, artı sayfalar, artı taksonomi işlemleri. Kurumsal ölçekte küçük, ilginç şekillerde bozulmaya yetecek kadar büyük.
Hattın tek işi var: iki dilde bir editoryal parça üretmek ve iki WordPress sitesinde canlıya almak. İyi bir günde bunu yeterince iyi yapıyor. Asıl zor yarısı, kötü bir günde yayımlamayı reddetmek. İşte o ret, yayın kapısı dediğim şey. Yüz altmış günde üç farklı kuralı yıktık ve her seferinde çözüm, kural çiğnendiğinde sıfırdan farklı bir çıkış kodu veren bir tarayıcı oldu. Üç betik, aralarında yaklaşık yüz yetmiş satır Python, bir de yayın betiğinde küçük bir değişiklik. Tüm sorunun yüzey alanı bu.
İlk kapı var çünkü bir Türkçe argo canlı yayına kadar geldi
Yıktığımız ilk kural, ton. Türkçede bir deyim ailesi var: konuşmada sıcacık, folklorik duran, basılı sayfada kaba okunan türden. Düğünde kuzenine söylersin. Kurumsal okuyucunun kollarını kavuşturup okuyacağı bir sayfaya yazmazsın. Hatırlamak istemediğim bir gün, bunlardan biri Türkçe sitede bizim imzamızla yayımlandı.
Tepkim net oldu. Tarayıcı bir gün sonra, 14 Eylül 2026’da devreye girdi ve dosyanın başlığı hâlâ sebebini kayda geçiriyor: “added 2026-09-14 after a crude Turkish idiom reached a live post.” Türkçe ve İngilizce için otuz küsur bütün-sözcük deseninden ibaret, büyük-küçük harfe duyarsız, yayımlanmak üzere olan her HTML dosyasının düz metnine karşı taranıyor. Herhangi bir eşleşmede 1 ile çıkıyor, bu da yayın adımını kilitliyor.
Asıl ilginç kısım yazarkendi. Maliyet hangi sözcükleri işaretleyeceğimizi seçmek değildi. O kısa bir konuşmaydı. Maliyet şunu fark etmekti: Python’un büyük-küçük harf duyarsız eşlemesinden geçen Türkçede, sıradan bir zarf olan sık (yani “sık”, yoğun anlamında) yalnızca noktalı ve noktasız i ile ayrılan kaba bir sözcükle çakışıyor. O kaba sözcüğü listeye koyarsan Türkçenin yarısı bir anda kural ihlali gibi okunur. Tarayıcı bu yüzden bilerek çıplak biçimi atlıyor, çakışmayan daha uzun desenlere dayanıyor. İngilizce tarafında da benzer bir durum küçük ölçekte vardı: “dumb pipe” standart teknik bir terim, o yüzden çıplak sözcük listede değil; “garbage” erişilebilirlik metinlerinde meşru, o da listede değil.
Satın alan tarafın gerçek dersi şu, kimse sana söylemeyecek: konuşmadığın bir dilde ton tarayıcısı bir sözcük listesi değil, o dilin dilbilgisine özenle oyulmuş bir sözcük listesidir. Birisi sana bunu kırk sekiz saatte pazarlıyorsa, hangi çakışmaları ele aldığını sor. Boş bakış alırsan, ya kaçıran ya da sıradan yazıyı ihlal gibi işaretleyen bir tarayıcı satın alıyorsun. İkisi de pahalı.
İkinci kapı var çünkü on üç yazı yanlış büyük-küçük harfle çıktı
Yıktığımız ikinci kural ev stili. 13 Eylül 2026’da geniş bir editoryal sıfırlama kapsamında voice dosyasını yeniden yazdık. O yeniden yazımda kaybolan paragraflardan biri başlık büyük-küçük harf kuralıydı. On üç gün üst üste her yazı, iki dilde de cümle büyük-küçük harfiyle canlıya çıktı ve kimse fark etmedi. Önceki yüz yazı kuralı sorunsuz taşımıştı, hattın arkasındaki yazar da sessizce şunu varsaymıştı: 4 Haziran’da yazılı olan kural 28 Eylül’de de yazılı olacak.
Değildi. Şimdi bunu yakalayan tarayıcı, kural aynı gün geri konulmuşken 28 Eylül 2026’da eklendi. Yaptığı iş bir gidiş-dönüş testi: sıfırlama tarihinden itibaren her yazının başlığı deterministik bir başlık-büyük-küçük harf fonksiyonundan geçiriliyor. Saklanan başlık fonksiyonun çıktısıyla eşleşmezse yazı kilitleniyor. Fonksiyon İngilizce AP kurallarını (üç harf ve altı bağlaç ve edatlar küçük kalır, ilk ve son sözcük ile iki noktadan sonrası büyük yazılır) ve Türkçe büyük-küçük kurallarını (her sözcük büyük, noktalı ve noktasız i korunur, yani i büyüktekrarında İ olur, ı ise I) uyguluyor. Kendi kuralıyla küçük yazılan isimler, mesela wp-cli ve theme.json, olduğu gibi bırakılıyor.
Stil rehberi olan alıcı için ders basit ve rahatsız edici. Kuralın yalnızca bir belgede yaşıyorsa, o belgenin bir sonraki yeniden yapılandırmasında kaybolur ve ardından gelen on üç iş yanlış çıkar; kimse kafasını kaldırıp sormaz. Çözüm kuralın arkasına ikinci bir yüzey koymak. Bizde şimdi iki tane var: config dosyasındaki paragraf ve onu zorlayan betik. Biri diğerini sessizce silemez, hat yayımlamayı reddeder.
Üçüncü kapı var çünkü em çizgi oyunu ele veriyor
Üçüncü kuralı iki kez, zıt yönlerde yıktık. 27 Eylül 2026’da em çizgiyi (tire değil, uzun olanı) her dilde, her yüzeyde tümden yasakladık. Gerekçe estetik değildi. Em çizgi, makine yazımının en tanınır izi hâline geldi; onu gören okuyucu argümanı takip etmeyi bırakıp metni bir insanın yazıp yazmadığını ölçmeye başlıyor. Bu, o noktalama işaretinin değerinden daha pahalı.
Sonra olanlar voice dosyasının kendisine yazılı: “Bu bölüm 09-27’de yazıldı, aynı gün temizlik sırasında bir git checkout’ta kayboldu. 2026-09-28’de geri getirildi. Tarayıcı arada bir kuralı, arkasında yazıyla desteklenmeden zorluyordu.” Yirmi dört saat boyunca, tarayıcı em çizgileri reddediyordu ama bunun sebebi bir insanın okuyabileceği hiçbir metinde yoktu. Sıradaki yazar makul biçimde tarayıcının hatalı olduğunu düşünüp devre dışı bırakırdı. Kural tarayıcı hayatta kaldığı için hayatta kaldı; paragraf geri gelince daha iyi hayatta kaldı.
Tarayıcının kendisi iki şeyi işaretliyor: em çizgi karakterini ve düz metindeki boşluklu kısa çizgiyi, ki bu em çizginin kuralın etrafından dolaşarak geri sızma yolu. Bir <pre> ya da <code> bloğunun içindeki hiçbir şeyi bilerek işaretlemiyor, çünkü kodun içinde calc(100vw – 160px) gerçek koddur, çizgi veridir, düz metin değil. En çizgi rahat bırakılıyor çünkü sayısal ve tarih aralıklarında (“1.400 ile 2.200 kelime arası” gibi) doğru tipografi odur. Bu tür kurallar bir sözcük listesinde yaşamaz, doğru düzenli ifadelerle yaklaşık altmış satır Python’da yaşar.
Bir tarayıcının yakalayamadığı şey ve ne yapılacağı
Üç kural için üç tarayıcı. Tarayıcıların yakalayamadığı dördüncü bir olay var ve masaya koymaya değer, çünkü bir sonraki sınıf başarısızlığın şeklini veriyor.
14 Ekim 2026’da hem İngilizce hem Türkçe sitelerde wp-cli üzerinden wp post term set <id> category 1 129 130 komutu --by=id bayrağı olmadan çalıştırıldı. Bu bayrak isteğe bağlı değil. Onsuz wp-cli, 1, 129 ve 130’u kategori adı olarak algılıyor, bu adla kategori bulamıyor ve sessizce bunları oluşturuyor. O sabah her iki sitede de tam adları “1”, “129” ve “130” olan üç yeni üst düzey kategoriyle ve kimsenin eğlenmediği bir temizlik turuyla bitirdik. Kalıcı çözüm kategori geçişini doğrudan yayın betiğinin içine aldı ve --by=id’yi sabitledi, CLAUDE dosyası da gelecekteki el ile geçişler için aynı uyarıyı artık kırmızıyla taşıyor.
Bunun yakalanmama sebebi, yazdığımız tarayıcıların hepsinin düz metne bakıyor olması. HTML’ye bakan bir tarayıcı başıboş bir kategoriyi göremez. İlk sınıf hata yayımladığın şeyin içinde yaşıyor, kapısı da tarayıcı. İkinci sınıf hata yayımladığın altyapının içinde yaşıyor, kapısı da kullandığı aletlerin varsayılan davranışına asla geri düşmeyen bir dağıtım betiği. Her iki sınıf da ölçekli her WordPress sisteminde var. Tek tip kapı kurarsan diğer tür dağınıklığı temizlemekle hep uğraşırsın.
Bu yapı bize ait olmayan bir WordPress multisite üzerinde nasıl görünüyor
Çok dilli bir WordPress sistemi işletiyor ve bu örüntüyü oturtmak istiyorsan, işin şekli şöyle. Hiçbiri yeni değil. Hepsi ucuz. Pahalı olan kısım hangi kuralların kapının arkasına girmesini istediğin konusunda anlaşmak, yoksa kapıyı yazmak değil.
- Dil başına bir ton tarayıcısı: bütün-sözcük desenleri ve o dilin dilbilgisinin yarattığı çakışmalar için geriye bakışlı eşleşmeler. Bizde Türkçe ve İngilizce birlikte bir sayfalık Python, atlanan her sözcüğün neden atlandığını anlatan bir kod-içi not. Yeni diller aynı dosyaya kendi sözcük listesini ekler.
- Varlığının kendisi editoryal bir iz olan her şey için bir noktalama tarayıcısı. Em çizgi aşikâr olanı. Ev tonuna göre, olmaması gereken yerdeki kırılmaz boşlukları, kod bloğundaki akıllı tırnakları ve düz metinde üç nokta yerine kullanılan üç nokta karakterini de işaretlemek isteyebilirsin.
- Deterministik bir fonksiyondan gidiş-dönüş yapan ve yalnızca kural anlaşıldıktan sonraki yazılarda zorlayan bir başlık-büyük-küçük harf tarayıcısı. Mevcut arşive geriye dönük uygulamak, tarayıcıyı kapatmanın en hızlı yolu; sıfırlama öncesi on bin başlığı kim temizleyecek diye düşünenlerin gözünde.
- wp-cli veya REST API’ye hangi alanın atandığını ve bunun slug, id veya ad olup olmadığını açıkça belirtmeden hiçbir şey geçirmeyen bir yayın betiği. Varsayılan yok, geri düşme yok. Bizim yayın betiğimize eklediğimiz üç satırlık düzeltme tam olarak kategori geçişindeki
--by=idanahtarı, wp-cli’nin id veya ad kabul ettiği diğer her yerde de aynı karar yazılı.
Kapıların dokunduğu veri, açıkça: ton ve çizgi tarayıcıları diskteki HTML’ye bakıyor, başlık tarayıcısı dil başına slug, başlık ve özeti içeren bir JSON dosyasına. Hiçbiri müşteri verisine, ödeme kayıtlarına ya da WooCommerce sipariş tablolarına dokunmuyor. Bir yayın kapısı işini yapmak için müşteri kişisel verisine ihtiyaç duymaya başladığı an, kapsam ve güvenlik hakkında başka bir konuşma yapılması gerekir. Editoryal kapıları editoryal yüzeylerde tut, ticari kapıları ait oldukları sipariş hattında bırak.
Emek, dürüstçe: her tarayıcı, ilgili dildeki çakışma analizi dahil kabaca bir günlük yazı, artı üçünü yayın kancasına bağlamak için üç gün üzerinden bir gün. İki ya da üç dilli, tek editoryal ekipli bir WordPress multisite: bir haftalık iş, kuralları konuştuğunuz toplantı dahil. Bölgesel ekiplerle on beş dilli bir sistem: dört ila altı hafta, çünkü “kimin ton tanımı kazanacak” zor konuşması iki yerine on beş kez yaşanır.
Bu kapıları olmayan çok dilli bir sistemi bize teslim etsen ne yapardık
Bir envanterle başlardım. Eklentilerin, temaların ya da sunucuların değil. Şu an sadece üç dört eski çalışanın kafasında yaşayan ve hattın sırf tesadüfen uyduğu editoryal kuralların envanteri. Ev tonu, pazar başına yasak sözcükler, başlık büyük-küçük harf, noktalama, taksonomi kuralları, slug biçimi, hreflang eşlemeleri. Ne gelirse, her satırı yayımlamayı reddedebilecek bir tarayıcıya çevir ve tarayıcıları dağıtıma bağla. Kurum geriye yalnızca bir kişinin nasıl bozulmayacağını bildiği daha kısa bir yığınla ve bir başkasının bir öğleden sonra okuyabileceği bir betikle kalır. Hamle bu. Konferans açılış konuşmasına yetmez, ama arkasından çıkan hat uykuyu kaçırmadan devredebileceğin türden.
Last modified: Kasım 11, 2026
