Priekšvēsture¶

Šī bibliotēka atrodas divu garu stāstu satikšanās vietā — viens ir par to, kā programmatūra tiek tulkota, otrs par to, kā Python interpolē virknes —, kuri beidzot krustojās 2025. gadā un tad apstājās tieši tajā punktā, kur bija vajadzīga maza, rūpīga konvencija. Šī lapa izstāsta abus stāstus ar saitēm uz avotiem, jo šīs vietnes dizaina lēmumus ir vieglāk novērtēt, kad redzami jautājumi, uz kuriem tie atbild.

gettext ekosistēma¶

Kopš 1990. gadu vidus GNU gettext ir tas, kā tiek tulkota brīvā programmatūra: atzīmē virknes kodā, ekstrahē tās veidnē, iedod tulkotājiem vienu kataloga failu katrai valodai, kompilē, ielādē izpildlaikā. Ap šo ciklu izauga vesela ekosistēma — PO redaktori, pārskatīšanas darbplūsmas un tulkošanas platformas, kas visas runā vienā un tajā pašā faila formātā —, un Python savā standarta bibliotēkā vairāk nekā divas desmitgades piegādā gettext moduli. Tulkošanas izpildlaika puse nekad nebija problēma.

Neatrisinātā puse vienmēr bija tas, kā izskatās kataloga virkne. Ziņojums ar %(name)s iedod tulkotājiem printf sintaksi, ko viens nodzēsts burts pārvērš par avāriju produkcijā; ziņojums ar .format() iedod katalogam piekļuvi dzīvu objektu atribūtiem. (Kāpēc t-virknes izstaigā abus, ar kļūmēm redzamā vietā.) Bet f-virknes — sintakse, ko lielākā daļa Python koda tagad izvēlas — nevar piedalīties nemaz: brīdī, kad kāda bibliotēka to ierauga, tā jau ir pabeigta virkne. Cilvēki tomēr mēģina, un tik bieži, ka Babel problēmu izsekotājs šos mēģinājumus savāc kopā (#594, #715); kļūme ir strukturāla, nevis trūkstoša iespēja.

Divi PEP ar desmit gadu starpību¶

1. gadā Alyssa Coghlan un Nick Humrich uzrakstīja PEP 501, piedāvājot interpolācijas veidnes, kuru pirmā deklarētā motivācija bija i18n — “providing a cleaner syntax for i18n translation”, kā teikts pašā PEP. Priekšlikums tika atlikts, daļēji tāpēc, ka diskusija parādīja: i18n gadījums nes līdzi ievērojamus papildu apsvērumus, kādu vienkāršākiem lietojumiem nav.

Desmit gadus vēlāk PEP 750 — no Jim Baker, Guido van Rossum, Paul Everitt, Koudai Aono, Lysandros Nikolaou un Dave Peck — atdzīvināja ideju kā t-virknes, tika pieņemts 2025. gada aprīlī un nonāca Python 3.14 versijā 2025. gada oktobrī. PEP 501 tad tika atsaukts par labu tam. Šai lapai svarīga ir viena detaļa: i18n nav starp PEP 750 deklarētajām motivācijām. PEP vispārināja mehānismu — veidnes tipu, ko var patērēt jebkura bibliotēka — un atstāja tulkošanas jautājumu tieši tur, kur PEP 501 to bija nolicis desmit gadus agrāk: atvērtu.

Tātad no Python 3.14 valodā bija tieši tā datu struktūra, kāda ziņojumu katalogam vajadzīga, un nekādas konvencijas, kā to par tādu izmantot.

Standarta bibliotēkas diskusija¶

Divus mēnešus pirms 3.14 iznākšanas Adrian Mönnich (ThiefMaster, viens no Indico projekta uzturētājiem) piedāvāja aizvērt šo plaisu pašā standarta bibliotēkā: pavediens Support t-strings in gettext vietnē discuss.python.org, atvērts 2025. gada augustā, nāca kopā ar strādājošu pull request, kas pievieno t-virkņu atbalstu gan gettext, gan pygettext.

Pavedienu ir vērts izlasīt pilnībā, jo tas izceļ katru grūto jautājumu, uz ko šai bibliotēkai vēlāk nācās atbildēt:

• Kas drīkst būt interpolācija? Tikai vienkāršs nosaukums vai arī atribūti un izsaukumi ar atvasinātu viettura nosaukumu? Katra atbilde maina ērtumu pret msgid stabilitāti un kataloga drošību.
• Ko prasa daudzskaitļa formas, kad mērķa valodas daudzskaitļa sistēma atšķiras no avota valodas sistēmas?
• Vai gettext vispār ir pareizais mērķis? Barry Warsaw — kurš PEP 750 izstrādes laikā bija apgalvojis, ka t-virknes i18n nav labi piemērotas — norādīja uz savu flufl.i18n un tā $-virkņu stilu kā draudzīgāku rīku; citi iestājās par gettext pilnīgu pamešanu par labu jaunākām sistēmām, tādām kā Fluent.
• Un meta-jautājums: lai ko standarta bibliotēka piegādātu, to pēc tam praktiski nekad nevar mainīt. Konvenciju ar tik daudz atvērtām izvēlēm ir riskanti iesaldēt jau pirmajā mēģinājumā.

Vienprātība neizveidojās. CPython problēmziņojums tika aizvērts kā “not planned”, un pull request 2025. gada oktobrī, dažas dienas pēc 3.14 laidiena, tika aizvērts nesapludināts. Iespēja valodā bija; konvencijai nebija mājvietas.

Kāpēc vispirms pakotne¶

Šī ir tā plaisa, ko šis projekts izvēlējās aizpildīt no ārpuses standarta bibliotēkai, ar apzinātu likmi: konvencija nobriest ātrāk tur, kur tā var brīvi versionēties un iekarot lietotājus gadījumu pēc gadījuma, bet standarta bibliotēka — kurai jābūt pareizai jau pirmajā reizē — ir vieta, kur konvencijai būtu jānonāk, nevis kur tā būtu jāizstrādā.

Konkrēti: katram pavedienā apstrīdētajam jautājumam šeit ir pierakstīta atbilde, katra savā lapā:

• Interpolācijas ir tikai vienkārši nosaukumi, lai msgid paliktu stabili un jēgpilni — ceļvedis parāda likumu, Kā tas darbojas — iemeslus.
• Formatējums paliek pilnībā ārpus kataloga (Kāpēc t-virknes).
• Daudzskaitļi seko apvienojuma/šķēluma likumam, kas ļauj mērķa valodas daudzskaitļa sistēmai atšķirties no avota valodas sistēmas (spec. §4).
• Sabojāts katalogs atkāpjas, nevis avarē, ievērojot paša gettext kontraktu (ceļvedis).
• Un visa konvencija ir versionēta specifikācija ar mašīnlasāmu atbilstības komplektu — uzrakstīta tā, lai cita implementācija, arī nākotnes standarta bibliotēkas implementācija, varētu to pārņemt nemainītu un savietoties.

Diskusija nav beigusies, un šis projekts tajā ir dalībnieks, nevis spriedums par to. Ja jums ir produkcijas gettext pieredze, kas skar šīs izvēles, tas pats pavediens un šī repozitorija Diskusijas ir vieta, kur diskusija turpinās.

Laika līnija¶