Háttér¶

Ez a könyvtár két hosszú történet találkozási pontján ül — az egyik arról szól, hogyan fordítják le a szoftvereket, a másik arról, hogyan interpolál a Python szövegeket —, amelyek 2025-ben végre metszették egymást, majd pontosan ott akadtak el, ahol egy kicsi, gondos konvencióra lett volna szükség. Ez az oldal mindkét történetet elmeséli, forráshivatkozásokkal, mert a webhelyen szereplő tervezési döntéseket könnyebb megítélni, ha látod a kérdéseket, amelyekre válaszolnak.

A gettext ökoszisztémája¶

A GNU gettext az 1990-es évek közepe óta a szabad szoftverek fordításának módja: jelöld meg a szövegeket a kódban, nyerd ki őket egy sablonba, adj a fordítóknak nyelvenként egy katalógusfájlt, fordítsd binárisra, töltsd be futásidőben. E ciklus köré egész ökoszisztéma nőtt — PO-szerkesztők, felülvizsgálati munkafolyamatok és fordítási platformok, amelyek mind ugyanazt a fájlformátumot beszélik —, a Python pedig több mint két évtizede szállít gettext modult a standard könyvtárában. A fordítás futásidejű fele soha nem volt gond.

A megoldatlan fele mindig az volt, hogy hogyan néz ki a katalógus szövege. Egy %(name)s üzenet olyan printf-szintaxist ad a fordítók kezébe, amelyet egyetlen törölt betű éles összeomlássá változtat; egy .format() üzenet attribútum-hozzáférést ad a katalógusnak élő objektumokhoz. (A Miért t-string? mindkettőt végigjárja, a hibákat kirakatba téve.) Az f-stringek pedig — az a szintaxis, amelyet ma a legtöbb Python-kód előnyben részesít — egyáltalán nem tudnak részt venni: mire bármelyik könyvtár meglátja őket, már kész szövegek. Az emberek mégis próbálkoznak, elég gyakran ahhoz, hogy a Babel hibajegyzéke gyűjtse a kísérleteket (#594, #715); a kudarc szerkezeti, nem hiányzó funkció kérdése.

Két PEP, tíz év különbséggel¶

2015-ben Alyssa Coghlan és Nick Humrich megírta a PEP 501-et, amely interpolációs sablonokat javasolt, és amelynek kimondott első motivációja az i18n volt — „tisztább szintaxis biztosítása az i18n-fordításhoz”, a PEP saját szavaival. A javaslatot elnapolták, részben azért, mert a vita megmutatta: az i18n-eset olyan jelentős többletszempontokat hordoz, amilyeneket az egyszerűbb felhasználási módok nem.

Egy évtizeddel később a PEP 750 — Jim Baker, Guido van Rossum, Paul Everitt, Koudai Aono, Lysandros Nikolaou és Dave Peck tollából — t-stringek néven élesztette újra az ötletet, 2025 áprilisában elfogadták, és 2025 októberében megjelent a Python 3.14-ben. A PEP 501-et ezután annak javára visszavonták. Egy részlet fontos ezen az oldalon: az i18n nem szerepel a PEP 750 kimondott motivációi között. A PEP általánosította a mechanizmust — egy sablontípust, amelyet bármely könyvtár feldolgozhat —, és pontosan ott hagyta a fordítás kérdését, ahol a PEP 501 tíz évvel korábban letette: nyitva.

Így hát a Python 3.14 idejére a nyelvnek pontosan megvolt az az adatszerkezete, amelyre egy üzenetkatalógusnak szüksége van, és nem volt konvenciója arra, hogyan használja ilyenként.

A stdlib-vita¶

Két hónappal a 3.14 megjelenése előtt Adrian Mönnich (ThiefMaster, az Indico projekt egyik karbantartója) azt javasolta, hogy magában a standard könyvtárban zárják be ezt a rést: a discuss.python.orgon 2025 augusztusában nyitott Support t-strings in gettext szál egy működő pull requesttel érkezett, amely mind a gettext, mind a pygettext számára t-string-támogatást adott hozzá.

A szálat érdemes teljes egészében elolvasni, mert felszínre hozza mindazokat a nehéz kérdéseket, amelyekre ennek a könyvtárnak később válaszolnia kellett:

• Mi lehet egy interpoláció? Csak egyszerű név, vagy attribútumok és hívások is, származtatott helyőrzőnévvel? Minden válasz a kényelmet cseréli el a msgid stabilitására és a katalógus biztonságára.
• Mit követelnek meg a többesszám-alakok, amikor a célnyelv többesszám-rendszere eltér a forrásnyelvétől?
• Egyáltalán a gettext a jó célpont? Barry Warsaw — aki a PEP 750 kidolgozása során amellett érvelt, hogy a t-string nem jó választás az i18n-hez — a saját flufl.i18n csomagjára és annak $-string stílusára mutatott mint barátságosabb eszközre; mások azt javasolták, hogy hagyják el egészen a gettextet olyan újabb rendszerek javára, mint a Fluent.
• És a metakérdés: bármit szállítson is a standard könyvtár, azon gyakorlatilag soha többé nem lehet változtatni. Egy ennyi nyitott döntést hordozó konvenciót kockázatos elsőre befagyasztani.

Nem alakult ki konszenzus. A CPython hibajegyét „not planned” jelzéssel lezárták, a pull requestet pedig egyesítés nélkül zárták le 2025 októberében, néhány nappal a 3.14 megjelenése után. A képesség megvolt a nyelvben; a konvenciónak nem lett otthona.

Miért előbb egy csomag¶

Ezt a rést választotta ez a projekt betöltendőnek, a standard könyvtáron kívülről, egy tudatos fogadás alapján: egy konvenció ott érik meg gyorsabban, ahol szabadon verziózhat és esetről esetre nyerheti el az elfogadottságot, a standard könyvtár pedig — amelynek elsőre kell eltalálnia — az a hely, ahová egy konvenciónak meg kell érkeznie, nem az, ahol ki kell dolgozni.

Konkrétan a szál minden vitatott kérdésére van leírt válasz itt, mindegyikre a maga oldalán:

• Az interpolációk csak egyszerű nevek lehetnek, hogy a msgidek stabilak és értelmesek maradjanak — a kézikönyv mutatja a szabályt, a Hogyan működik az okokat.
• A formázás teljesen kimarad a katalógusból (Miért t-string?).
• A többes számok unió/metszet szabályt követnek, amely megengedi, hogy a célnyelv többesszám-rendszere eltérjen a forrásnyelvétől (spec 4. §).
• A hibás katalógus összeomlás helyett visszaesik, megtartva a gettext saját szerződését (a kézikönyv).
• Az egész konvenció pedig verziózott specifikáció géppel olvasható konformitási készlettel — úgy megírva, hogy egy másik megvalósítás, akár egy jövőbeli standard könyvtárbeli is, változtatás nélkül átvehesse, és együttműködhessen vele.

A vita nem ért véget, és ez a projekt résztvevője annak, nem ítélete fölötte. Ha van olyan éles üzemi gettext-tapasztalatod, amely érinti ezeket a döntéseket, ugyanaz a szál és ennek a tárolónak a Discussions felülete az a hely, ahol a beszélgetés folytatódik.

Idővonal¶