Achtergrond¶

Deze bibliotheek staat op het snijpunt van twee lange verhalen — één over hoe software vertaald wordt, één over hoe Python strings interpoleert — die elkaar in 2025 eindelijk kruisten en toen vastliepen op precies het punt waar een kleine, zorgvuldige conventie nodig was. Deze pagina vertelt beide verhalen, met links naar de bronnen, omdat de ontwerpbeslissingen op deze site makkelijker te beoordelen zijn wanneer je de vragen kunt zien die ze beantwoorden.

Het gettext-ecosysteem¶

GNU gettext is sinds het midden van de jaren negentig de manier waarop vrije software vertaald wordt: markeer de strings in code, extraheer ze naar een sjabloon, geef vertalers één catalogusbestand per taal, compileer, laad tijdens runtime. Rond die lus groeide een heel ecosysteem — PO-editors, reviewworkflows en vertaalplatforms die allemaal hetzelfde bestandsformaat spreken — en Python levert al meer dan twee decennia een gettext-module in zijn standaardbibliotheek. De runtime-helft van vertalen was nooit het probleem.

De onopgeloste helft was altijd hoe de catalogusstring eruitziet. Een %(name)s-bericht geeft vertalers printf-syntaxis die één verwijderde letter in een productiecrash verandert; een .format()-bericht geeft de catalogus attribuuttoegang tot levende objecten. (Waarom t-strings doorloopt beide, met de fouten in beeld.) En f-strings — de syntaxis die de meeste Python-code nu verkiest — kunnen helemaal niet meedoen: tegen de tijd dat een bibliotheek er een ziet, is het al een afgeronde string. Mensen proberen het toch, vaak genoeg dat Babels issue-tracker de pogingen verzamelt (#594, #715); het falen is structureel, geen ontbrekende feature.

Twee PEP's, tien jaar uit elkaar¶

In 2015 schreven Alyssa Coghlan en Nick Humrich PEP 501, een voorstel voor interpolatiesjablonen waarvan de eerstgenoemde motivatie i18n was — "providing a cleaner syntax for i18n translation", in de woorden van de PEP zelf. Het voorstel werd uitgesteld, deels omdat de discussie liet zien dat het i18n-geval aanzienlijke extra overwegingen met zich meebracht die eenvoudigere toepassingen niet hadden.

Een decennium later blies PEP 750 — van Jim Baker, Guido van Rossum, Paul Everitt, Koudai Aono, Lysandros Nikolaou en Dave Peck — het idee nieuw leven in als t-strings, werd het geaccepteerd in april 2025, en verscheen het in Python 3.14 in oktober 2025. PEP 501 werd daarop in zijn voordeel ingetrokken. Eén detail is voor deze pagina van belang: i18n staat niet onder de genoemde motivaties van PEP 750. De PEP generaliseerde het mechanisme — een template-type dat elke bibliotheek kan consumeren — en liet de vertaalvraag exact waar PEP 501 haar tien jaar eerder had geparkeerd: open.

Dus vanaf Python 3.14 had de taal precies de datastructuur die een berichtencatalogus nodig heeft, en geen conventie om haar als zodanig te gebruiken.

De stdlib-discussie¶

Twee maanden voordat 3.14 uitkwam, stelde Adrian Mönnich (ThiefMaster, een maintainer van het Indico-project) voor dat gat in de standaardbibliotheek zelf te dichten: de thread Support t-strings in gettext op discuss.python.org, geopend in augustus 2025, kwam met een werkende pull request die t-string-ondersteuning toevoegde aan zowel gettext als pygettext.

De thread is het waard om volledig te lezen, omdat hij elke moeilijke vraag naar boven haalt die deze bibliotheek later moest beantwoorden:

• Wat mag een interpolatie zijn? Alleen een eenvoudige naam, of ook attributen en aanroepen met een afgeleide placeholdernaam? Elk antwoord ruilt gemak tegen msgid-stabiliteit en catalogusveiligheid.
• Wat vereisen meervoudsvormen, wanneer het meervoudssysteem van de doeltaal afwijkt van dat van de bron?
• Is gettext überhaupt het juiste doel? Barry Warsaw — die tijdens de ontwikkeling van PEP 750 had betoogd dat t-strings geen goede match voor i18n waren — wees naar zijn flufl.i18n en zijn $-string-stijl als het vriendelijkere gereedschap; anderen pleitten ervoor gettext helemaal achter te laten ten gunste van nieuwere systemen zoals Fluent.
• En de meta-vraag: wat de standaardbibliotheek ook uitbrengt, het kan in wezen nooit meer veranderen. Een conventie met zoveel open keuzes is riskant om bij de eerste poging te bevriezen.

Er vormde zich geen consensus. Het CPython-issue werd gesloten als "not planned" en de pull request werd ongemerged gesloten in oktober 2025, dagen na de release van 3.14. De capaciteit bestond in de taal; de conventie had geen thuis.

Waarom eerst een pakket¶

Dat is het gat dat dit project koos te vullen van buiten de standaardbibliotheek, op een bewuste weddenschap: een conventie rijpt sneller waar ze vrij kan versioneren en adoptie geval voor geval kan verdienen, en de standaardbibliotheek — die het de eerste keer goed moet hebben — is waar een conventie moet eindigen, niet waar ze moet worden uitgewerkt.

Concreet heeft elke omstreden vraag uit de thread hier een opgeschreven antwoord, elk op zijn eigen pagina:

• Interpolaties zijn alleen eenvoudige namen, zodat msgids stabiel en betekenisvol blijven — de handleiding toont de regel, Hoe het werkt de redenen.
• Opmaak blijft geheel buiten de catalogus (Waarom t-strings).
• Meervouden volgen een unie/doorsnede-regel die het meervoudssysteem van een doeltaal laat afwijken van dat van de bron (spec §4).
• Een kapotte catalogus valt terug in plaats van te crashen, in lijn met gettexts eigen contract (de handleiding).
• En de hele conventie is een versiebeheerde specificatie met een machineleesbare conformiteitssuite — zo geschreven dat een andere implementatie, inclusief een toekomstige in de standaardbibliotheek, haar ongewijzigd zou kunnen overnemen en interopereren.

De discussie is niet afgelopen, en dit project is er een deelnemer aan, geen oordeel erover. Heb je productie-ervaring met gettext die deze keuzes raakt, dan zijn dezelfde thread en de Discussions van deze repository de plek waar de discussie verdergaat.

Tijdlijn¶