Ištakos¶

Ši biblioteka stovi dviejų ilgų istorijų susitikimo taške — vienos apie tai, kaip verčiama programinė įranga, kitos apie tai, kaip Python interpoliuoja eilutes — kurios pagaliau susikirto 2025 m. ir tada sustojo lygiai toje vietoje, kur reikėjo mažo, kruopštaus susitarimo. Šis puslapis pasakoja abi istorijas su nuorodomis į šaltinius, nes šioje svetainėje priimtus sprendimus lengviau vertinti, kai matai klausimus, į kuriuos jie atsako.

Gettext ekosistema¶

GNU gettext nuo dešimtojo dešimtmečio vidurio yra būdas, kuriuo verčiama laisvoji programinė įranga: pažymėk eilutes kode, ištrauk jas į šabloną, duok vertėjams po vieną katalogo failą kiekvienai kalbai, sukompiliuok, įkelk veikimo metu. Aplink tą ciklą išaugo visa ekosistema — PO redaktoriai, peržiūros darbo eigos ir vertimo platformos, visos kalbančios tuo pačiu failų formatu — o Python savo standartinėje bibliotekoje gettext modulį tiekia jau daugiau nei du dešimtmečius. Vertimo vykdymo pusė niekada nebuvo problema.

Neišspręsta visada liko pusė, kaip atrodo katalogo eilutė. %(name)s pranešimas paduoda vertėjams printf sintaksę, kurią viena ištrinta raidė paverčia lūžiu produkcijoje; .format() pranešimas paduoda katalogui prieigą prie gyvų objektų atributų. (Kodėl t-eilutės abu pereina, su gedimais ant stalo.) O f-eilutės — sintaksė, kurią dabar labiausiai mėgsta Python kodas — negali dalyvauti apskritai: kol jas pamato bet kuri biblioteka, jos jau yra baigtos eilutės. Vis tiek bandoma — pakankamai dažnai, kad Babel klaidų sekiklis kauptų tuos bandymus (#594, #715); gedimas yra struktūrinis, o ne trūkstama savybė.

Du PEP'ai su dešimties metų tarpu¶

2015 m. Alyssa Coghlan ir Nick Humrich parašė PEP 501, siūlantį interpoliacijos šablonus, kurių pirmoji nurodyta motyvacija buvo i18n — „providing a cleaner syntax for i18n translation“, paties PEP'o žodžiais. Pasiūlymas buvo atidėtas, iš dalies todėl, kad diskusija parodė, jog i18n atvejis neša reikšmingų papildomų svarstymų, kurių paprastesni panaudojimo atvejai neturi.

Po dešimtmečio PEP 750 — Jim Baker, Guido van Rossum, Paul Everitt, Koudai Aono, Lysandros Nikolaou ir Dave Peck — atgaivino idėją kaip t-eilutes, buvo priimtas 2025 m. balandį ir 2025 m. spalį pateko į Python 3.14. PEP 501 tada buvo atsiimtas jo naudai. Vienas dalykas šiam puslapiui svarbus: i18n nėra tarp PEP 750 nurodytų motyvacijų. PEP'as apibendrino mechanizmą — šablono tipą, kurį gali vartoti bet kuri biblioteka — ir paliko vertimo klausimą lygiai ten, kur PEP 501 jį buvo pastatęs dešimt metų anksčiau: atvirą.

Taigi nuo Python 3.14 kalba turėjo būtent tokią duomenų struktūrą, kokios reikia pranešimų katalogui, ir jokio susitarimo, kaip ja naudotis.

Standartinės bibliotekos diskusija¶

Likus dviem mėnesiams iki 3.14 išleidimo, Adrian Mönnich (ThiefMaster, Indico projekto prižiūrėtojas) pasiūlė tą spragą užpildyti pačioje standartinėje bibliotekoje: gija Support t-strings in gettext svetainėje discuss.python.org, atverta 2025 m. rugpjūtį, atėjo su veikiančiu pull request'u, pridedančiu t-eilučių palaikymą tiek gettext, tiek pygettext.

Giją verta perskaityti visą, nes joje iškyla visi sunkūs klausimai, į kuriuos šiai bibliotekai vėliau teko atsakyti:

• Kas gali būti interpoliacija? Vien paprastas vardas, ar atributai ir iškvietimai su išvestiniu vietaženklio vardu? Kiekvienas atsakymas keičia patogumą į msgid stabilumą ir katalogo saugumą.
• Ko reikalauja daugiskaitos formos, kai tikslinės kalbos daugiskaitos sistema skiriasi nuo pirminės?
• Ar gettext apskritai yra tinkamas taikinys? Barry Warsaw — kuris PEP 750 kūrimo metu buvo teigęs, kad t-eilutės i18n netinka — nurodė savo flufl.i18n ir jo $ eilučių stilių kaip draugiškesnį įrankį; kiti siūlė gettext apskritai palikti ir pereiti prie naujesnių sistemų, tokių kaip Fluent.
• Ir metaklausimas: ką bepatiektų standartinė biblioteka, to iš esmės niekada nebegalima pakeisti. Susitarimas su tiek atvirų pasirinkimų yra rizikingas dalykas užšaldyti iš pirmo karto.

Bendro sutarimo nesusidarė. CPython klausimas buvo uždarytas kaip „not planned“, o pull request'as uždarytas nesulietas 2025 m. spalį, kelios dienos po 3.14 išleidimo. Galimybė kalboje egzistavo; susitarimas namų neturėjo.

Kodėl pirmiau paketas¶

Būtent tą spragą šis projektas pasirinko užpildyti iš už standartinės bibliotekos ribų, sąmoningai lažindamasis: susitarimas bręsta greičiau ten, kur gali laisvai versijuotis ir pelnyti pritaikymą po vieną atvejį, o standartinė biblioteka — kuri privalo būti teisi iš pirmo karto — yra ten, kur susitarimas turėtų atsidurti, o ne ten, kur jis turėtų būti išrūšiuotas.

Konkrečiai: kiekvienas gijoje ginčytas klausimas čia turi surašytą atsakymą, kiekvienas savo puslapyje:

• Interpoliacijos yra tik paprasti vardai, todėl msgid'ai išlieka stabilūs ir prasmingi — vadovas parodo taisyklę, Kaip tai veikia — priežastis.
• Formatavimas visiškai lieka už katalogo ribų (Kodėl t-eilutės).
• Daugiskaita paklūsta sąjungos/sankirtos taisyklei, leidžiančiai tikslinės kalbos daugiskaitos sistemai skirtis nuo pirminės (spec §4).
• Sugadintas katalogas grįžta atgal, o ne lūžta, išlaikydamas paties gettext kontraktą (vadovas).
• O visas susitarimas yra versijuota specifikacija su mašininiu būdu skaitomu atitikties rinkiniu — parašyta taip, kad kita realizacija, įskaitant būsimą standartinės bibliotekos, galėtų ją perimti nepakeistą ir sąveikauti.

Diskusija nesibaigė, o šis projektas yra jos dalyvis, o ne nuosprendis joje. Jei turite produkcinės gettext patirties, susijusios su šiais pasirinkimais, ta pati gija ir šios saugyklos Discussions yra ten, kur diskusija tęsiasi.

Laiko juosta¶