Arka Plan¶

Bu kütüphane, iki uzun hikâyenin — biri yazılımın nasıl çevrildiği, öteki Python'un dizgileri nasıl interpolasyona uğrattığı hakkında — kesişme noktasında durur; iki hikâye nihayet 2025'te kesişti ve tam da küçük, özenli bir uzlaşımın gerektiği noktada durakladı. Bu sayfa iki hikâyeyi de kaynaklara bağlantılarla anlatır, çünkü bu sitedeki tasarım kararları, yanıtladıkları soruları görebildiğinizde daha kolay değerlendirilir.

gettext ekosistemi¶

GNU gettext, 1990'ların ortasından beri özgür yazılımın çevrilme biçimidir: dizgileri kodda işaretle, bir şablona çıkar, çevirmenlere dil başına bir katalog dosyası ver, derle, çalışma zamanında yükle. Bu döngünün çevresinde koca bir ekosistem büyüdü — hepsi aynı dosya formatını konuşan PO editörleri, inceleme iş akışları ve çeviri platformları — ve Python, yirmi yılı aşkın süredir standart kütüphanesinde bir gettext modülü barındırıyor. Çevirinin çalışma zamanı yarısı hiçbir zaman sorun olmadı.

Çözülmemiş yarı, her zaman katalog dizgisinin neye benzediğiydi. Bir %(name)s mesajı çevirmenlere printf sözdizimi teslim eder; silinen tek bir harf onu üretim çökmesine çevirir. Bir .format() mesajı ise kataloğa canlı nesneler üzerinde öznitelik erişimi teslim eder. (Neden t-string? ikisini de, hataları göstererek anlatır.) Ve f-string'ler — bugün çoğu Python kodunun tercih ettiği sözdizimi — hiç katılamaz: herhangi bir kütüphane birini gördüğünde, o çoktan bitmiş bir dizgidir. İnsanlar yine de deniyor; öyle sık ki Babel'in issue takipçisi bu girişimleri biriktiriyor (#594, #715); başarısızlık yapısaldır, eksik bir özellik değildir.

On yıl arayla iki PEP¶

2015'te Alyssa Coghlan ve Nick Humrich, belirtilen ilk motivasyonu i18n olan — PEP'in kendi sözleriyle "i18n çevirisi için daha temiz bir sözdizimi sağlamak" — interpolasyon şablonlarını öneren PEP 501'i yazdı. Öneri ertelendi; kısmen, tartışmanın i18n durumunun daha basit kullanım senaryolarının taşımadığı önemli ek kaygılar taşıdığını göstermesi yüzünden.

On yıl sonra, PEP 750 — Jim Baker, Guido van Rossum, Paul Everitt, Koudai Aono, Lysandros Nikolaou ve Dave Peck imzasıyla — fikri t-string'ler olarak canlandırdı, Nisan 2025'te kabul edildi ve Ekim 2025'te Python 3.14 ile yayımlandı. PEP 501 bunun üzerine onun lehine geri çekildi. Bu sayfa için bir ayrıntı önemli: i18n, PEP 750'nin belirtilen motivasyonları arasında değildir. PEP mekanizmayı genelleştirdi — her kütüphanenin tüketebileceği bir template türü — ve çeviri sorusunu tam olarak PEP 501'in on yıl önce bıraktığı yerde bıraktı: açıkta.

Yani Python 3.14 itibarıyla dil, bir mesaj kataloğunun ihtiyaç duyduğu veri yapısının tam kendisine sahipti — ve onu öyle kullanmak için hiçbir uzlaşıma.

Stdlib tartışması¶

3.14 çıkmadan iki ay önce, Adrian Mönnich (ThiefMaster, Indico projesinin bir bakımcısı) bu boşluğu standart kütüphanenin kendisinde kapatmayı önerdi: discuss.python.org'daki Support t-strings in gettext başlığı, Ağustos 2025'te, hem gettexte hem pygettexte t-string desteği ekleyen çalışır bir pull request ile birlikte açıldı.

Başlık baştan sona okunmaya değer, çünkü bu kütüphanenin daha sonra yanıtlamak zorunda kaldığı her zor soruyu su yüzüne çıkarır:

• Bir interpolasyon ne olabilir? Yalnızca yalın bir ad mı, yoksa türetilen bir yer tutucu adıyla öznitelikler ve çağrılar mı? Her yanıt, kullanışlılığı msgid kararlılığı ve katalog güvenliğiyle takas eder.
• Çoğul biçimler ne gerektirir, hedef dilin çoğul sistemi kaynağınkinden farklı olduğunda?
• gettext doğru hedef mi ki? PEP 750'nin geliştirilmesi sırasında t-string'lerin i18n için iyi bir uyum olmadığını savunmuş olan Barry Warsaw, daha dostane araç olarak kendi flufl.i18n paketini ve $-dizgi tarzını gösterdi; başkaları gettext'i tamamen geride bırakıp Fluent gibi daha yeni sistemlere geçmeyi savundu.
• Ve üst-soru: standart kütüphane ne yayımlarsa yayımlasın, o esasen bir daha asla değişemez. Bu kadar açık seçeneği olan bir uzlaşımı ilk denemede dondurmak riskli bir iştir.

Uzlaşı oluşmadı. CPython issue'su "planlanmadı" olarak kapatıldı ve pull request, 3.14'ün yayımlanmasından günler sonra, Ekim 2025'te birleştirilmeden kapatıldı. Yetenek dilde vardı; uzlaşımın ise bir yuvası yoktu.

Neden önce bir paket¶

Bu projenin standart kütüphanenin dışından doldurmayı seçtiği boşluk işte bu; bilinçli bir bahisle: bir uzlaşım, serbestçe sürümlenebildiği ve benimsenmeyi vaka vaka kazanabildiği yerde daha hızlı olgunlaşır ve ilk seferde doğru olmak zorunda olan standart kütüphane, bir uzlaşımın varması gereken yerdir — üzerinde çalışılacağı yer değil.

Somut olarak, başlıktaki her tartışmalı sorunun burada yazıya dökülmüş bir yanıtı var, her biri kendi sayfasında:

• İnterpolasyonlar yalnızca yalın adlardır; böylece msgid'ler kararlı ve anlamlı kalır — kılavuz kuralı gösterir, Nasıl Çalışır nedenlerini.
• Biçimlendirme katalogdan tamamen uzak durur (Neden t-string?).
• Çoğullar, hedef dilin çoğul sisteminin kaynağınkinden farklı olmasına izin veren bir birleşim/kesişim kuralını izler (spec §4).
• Bozuk bir katalog, gettext'in kendi sözleşmesini koruyarak çökmek yerine geri düşer (kılavuz).
• Ve uzlaşımın tamamı, makine tarafından okunabilir bir uyumluluk paketiyle birlikte sürümlenmiş bir belirtimdir — öyle yazılmıştır ki başka bir gerçekleştirim, gelecekteki bir standart kütüphane gerçekleştirimi dahil, onu değiştirmeden benimseyip birlikte çalışabilsin.

Tartışma bitmedi ve bu proje onun bir katılımcısıdır, hakkında verilmiş bir hüküm değil. Bu seçimleri ilgilendiren üretim gettext deneyiminiz varsa, aynı başlık ve bu deponun Discussions bölümü, tartışmanın sürdüğü yerlerdir.

Zaman çizelgesi¶