Usuli¶

Maktaba hii inakaa mahali ambapo hadithi mbili ndefu hukutana — moja kuhusu jinsi programu zinavyotafsiriwa, nyingine kuhusu jinsi Python inavyoingiza thamani ndani ya mifuatano — ambazo hatimaye zilikutana mwaka 2025 kisha zikakwama hasa mahali ambapo makubaliano madogo na ya makini yalihitajika. Ukurasa huu husimulia hadithi zote mbili, pamoja na viungo vya vyanzo, kwa sababu maamuzi ya muundo yaliyo kwenye tovuti hii ni rahisi kuyapima unapoweza kuona maswali wanayoyajibu.

Mfumo ikolojia wa gettext¶

GNU gettext imekuwa ndiyo njia ambayo programu huria hutafsiriwa tangu katikati ya miaka ya 1990: weka alama kwenye mifuatano ndani ya msimbo, itoe ndani ya kiolezo, wape wafasiri faili moja la katalogi kwa kila lugha, kusanya, pakia wakati wa utekelezaji. Kuzunguka mzunguko huo ulikua mfumo ikolojia mzima — vihariri vya PO, mitiririko ya mapitio, na majukwaa ya tafsiri ambayo yote huzungumza umbizo lilelile la faili — na Python imesambaza moduli ya gettext katika maktaba yake sanifu kwa zaidi ya miongo miwili. Nusu ya wakati wa utekelezaji ya tafsiri haikuwa tatizo kamwe.

Nusu isiyotatuliwa daima ilikuwa mfuatano wa katalogi unaonekanaje. Ujumbe wa %(name)s huwakabidhi wafasiri sintaksia ya printf ambayo herufi moja iliyofutwa huigeuza kuwa kuanguka kwa programu katika uzalishaji; ujumbe wa .format() huikabidhi katalogi ufikiaji wa sifa za vitu hai. (Kwa nini t-strings hupitia zote mbili, na hitilafu zikionyeshwa waziwazi.) Na f-strings — sintaksia ambayo msimbo mwingi wa Python sasa huipendelea — haziwezi kushiriki hata kidogo: kufikia wakati maktaba yoyote inaiona, tayari ni mfuatano uliokamilika. Watu hujaribu hata hivyo, mara nyingi vya kutosha kiasi kwamba kifuatiliaji masuala cha Babel hukusanya majaribio hayo (#594, #715); kushindwa ni kwa kimuundo, si kipengele kilichokosekana.

PEP mbili, zenye tofauti ya miaka kumi¶

Mwaka 2015, Alyssa Coghlan na Nick Humrich waliandika PEP 501, wakipendekeza violezo vya uingizaji ambavyo kichocheo chake cha kwanza kilichotajwa kilikuwa i18n — "kutoa sintaksia safi zaidi kwa tafsiri ya i18n", kwa maneno ya PEP yenyewe. Pendekezo hilo liliahirishwa, kwa sehemu kwa sababu mjadala ulionyesha kuwa kesi ya i18n ilibeba mazingatio ya ziada makubwa ambayo matumizi rahisi zaidi hayakuwa nayo.

Muongo mmoja baadaye, PEP 750 — ya Jim Baker, Guido van Rossum, Paul Everitt, Koudai Aono, Lysandros Nikolaou, na Dave Peck — ilifufua wazo hilo kama t-strings, ilikubaliwa Aprili 2025, na ikatolewa katika Python 3.14 Oktoba 2025. Kisha PEP 501 ikaondolewa kwa manufaa yake. Kuna kipengele kimoja muhimu kwa ukurasa huu: i18n haipo miongoni mwa vichocheo vilivyotajwa vya PEP 750. PEP hiyo iliufanya mfumo kuwa wa jumla — aina ya kiolezo ambayo maktaba yoyote inaweza kuitumia — na ikaliacha swali la tafsiri hasa pale ambapo PEP 501 ilikuwa imeliegesha miaka kumi mapema: wazi.

Kwa hiyo, kufikia Python 3.14, lugha ilikuwa na muundo wa data ambao katalogi ya jumbe inauhitaji, bila makubaliano yoyote ya kuutumia hivyo.

Mjadala wa stdlib¶

Miezi miwili kabla 3.14 haijatolewa, Adrian Mönnich (ThiefMaster, mtunzaji wa mradi wa Indico) alipendekeza kuziba pengo hilo ndani ya maktaba sanifu yenyewe: uzi Support t-strings in gettext kwenye discuss.python.org, uliofunguliwa Agosti 2025, ulikuja na ombi la kuunganisha linalofanya kazi lililoongeza uungwaji mkono wa t-string kwa gettext na pygettext vyote viwili.

Uzi huo unastahili kusomwa mzima, kwa sababu huibua kila swali gumu ambalo maktaba hii ilibidi ilijibu baadaye:

• Uingizaji unaweza kuwa nini? Jina rahisi tu, au sifa na miito yenye jina la kishika nafasi linalotokana nayo? Kila jibu hubadilishana urahisi na uthabiti wa msgid pamoja na usalama wa katalogi.
• Maumbo ya wingi yanahitaji nini, wakati mfumo wa wingi wa lugha lengwa unatofautiana na ule wa chanzo?
• Je, gettext ndilo lengo sahihi hata kidogo? Barry Warsaw — ambaye alikuwa amehoji wakati wa uandaaji wa PEP 750 kwamba t-strings hazioani vyema na i18n — alielekeza kwenye flufl.i18n yake na mtindo wake wa $-string kama zana rafiki zaidi; wengine walihoji kuiacha gettext kabisa kwa manufaa ya mifumo mipya kama Fluent.
• Na swali kuu: chochote maktaba sanifu inachotoa, kimsingi hakiwezi kubadilika kamwe. Makubaliano yenye machaguo mengi wazi kiasi hiki ni kitu hatari kukigandisha katika jaribio la kwanza.

Hakuna maafikiano yaliyoundwa. Suala la CPython lilifungwa kama "not planned" na ombi la kuunganisha likafungwa bila kuunganishwa Oktoba 2025, siku chache baada ya kutolewa kwa 3.14. Uwezo ulikuwepo ndani ya lugha; makubaliano hayakuwa na makazi.

Kwa nini kifurushi, kwanza¶

Hilo ndilo pengo ambalo mradi huu ulichagua kuliziba kutoka nje ya maktaba sanifu, kwa dau la makusudi: makubaliano hukomaa haraka zaidi mahali ambapo yanaweza kubadilisha matoleo kwa uhuru na kupata wafuasi kesi baada ya kesi, na maktaba sanifu — ambayo lazima iwe sahihi mara ya kwanza — ndipo makubaliano yanapopaswa kuishia, si mahali yanapopaswa kuundwa.

Kwa uhalisia, kila swali lililobishaniwa katika uzi lina jibu lililoandikwa hapa, kila moja kwenye ukurasa wake:

• Uingizaji ni majina rahisi tu, ili msgid zibaki thabiti na zenye maana — mwongozo huonyesha kanuni, Jinsi inavyofanya kazi huonyesha sababu.
• Uumbizaji hubaki nje ya katalogi kabisa (Kwa nini t-strings).
• Wingi hufuata kanuni ya muungano/mwingiliano inayoruhusu mfumo wa wingi wa lugha lengwa kutofautiana na ule wa chanzo (ainisho §4).
• Katalogi mbovu hurejea badala ya kuanguka, ikitunza mkataba wa gettext wenyewe (mwongozo).
• Na makubaliano yote ni ainisho lenye matoleo pamoja na seti ya utiifu inayosomeka na mashine — yaliyoandikwa ili utekelezaji mwingine, ikiwemo ule wa maktaba sanifu wa siku zijazo, uweze kuyachukua bila kuyabadilisha na kushirikiana.

Mjadala haujaisha, na mradi huu ni mshiriki ndani yake, si hukumu juu yake. Ikiwa una uzoefu wa gettext wa uzalishaji unaohusu machaguo haya, uzi uleule na Discussions za hazina hii ndipo mjadala unapoendelea.

Ratiba ya matukio¶