पृष्ठभूमि¶

यह लाइब्रेरी दो लंबी कहानियों के संगम पर खड़ी है — एक इस बारे में कि सॉफ़्टवेयर का अनुवाद कैसे होता है, दूसरी इस बारे में कि Python स्ट्रिंग्स को कैसे इंटरपोलेट करता है — जो अंततः 2025 में मिलीं और फिर ठीक उसी बिंदु पर अटक गईं जहाँ एक छोटी, सतर्क परिपाटी की ज़रूरत थी। यह पेज दोनों कहानियाँ स्रोतों के लिंक सहित सुनाता है, क्योंकि इस साइट के डिज़ाइन निर्णयों को परखना तब आसान होता है जब वे प्रश्न दिखते हों जिनका ये उत्तर देते हैं।

gettext का इकोसिस्टम¶

GNU gettext 1990 के दशक के मध्य से मुक्त सॉफ़्टवेयर के अनुवाद का तरीक़ा रहा है: कोड में स्ट्रिंग्स मार्क करो, उन्हें एक टेम्पलेट में एक्सट्रैक्ट करो, अनुवादकों को प्रति भाषा एक कैटलॉग फ़ाइल दो, कंपाइल करो, रनटाइम पर लोड करो। उस लूप के इर्द-गिर्द एक पूरा इकोसिस्टम पनपा — PO एडिटर, समीक्षा वर्कफ़्लो, और अनुवाद प्लेटफ़ॉर्म, जो सब एक ही फ़ाइल फ़ॉर्मैट बोलते हैं — और Python दो दशकों से भी अधिक समय से अपनी मानक लाइब्रेरी में एक gettext module देता आया है। अनुवाद का रनटाइम-पक्ष कभी समस्या नहीं था।

अनसुलझा पक्ष हमेशा यही था कि कैटलॉग की स्ट्रिंग कैसी दिखती है। एक %(name)s संदेश अनुवादकों को printf सिंटैक्स थमा देता है, जिसे एक मिटाया हुआ अक्षर प्रोडक्शन क्रैश में बदल देता है; एक .format() संदेश कैटलॉग को जीवित ऑब्जेक्ट्स पर attribute पहुँच दे देता है। (t-strings क्यों दोनों से गुज़रता है, विफलताएँ प्रदर्शित करते हुए।) और f-strings — वह सिंटैक्स जिसे अधिकांश Python कोड अब पसंद करता है — भाग ही नहीं ले सकते: किसी भी लाइब्रेरी तक पहुँचते-पहुँचते वे एक पूर्ण स्ट्रिंग बन चुके होते हैं। लोग फिर भी कोशिश करते हैं, इतनी बार कि Babel का issue tracker वे प्रयास जमा करता रहता है (#594, #715); विफलता संरचनात्मक है, कोई छूटी हुई सुविधा नहीं।

दो PEP, दस साल का अंतराल¶

2015 में Alyssa Coghlan और Nick Humrich ने PEP 501 लिखा, जिसमें इंटरपोलेशन टेम्पलेट प्रस्तावित थे और जिसकी घोषित पहली प्रेरणा i18n थी — PEP के अपने शब्दों में, "providing a cleaner syntax for i18n translation"। प्रस्ताव स्थगित हुआ, आंशिक रूप से इसलिए कि चर्चा ने दिखाया कि i18n के मामले में ऐसे उल्लेखनीय अतिरिक्त विचार जुड़े थे जो सरल उपयोगों में नहीं थे।

एक दशक बाद, PEP 750 — Jim Baker, Guido van Rossum, Paul Everitt, Koudai Aono, Lysandros Nikolaou और Dave Peck द्वारा — ने उस विचार को t-strings के रूप में पुनर्जीवित किया, अप्रैल 2025 में स्वीकृत हुआ, और अक्टूबर 2025 में Python 3.14 में शिप हुआ। PEP 501 तब उसके पक्ष में वापस लिया गया। इस पेज के लिए एक ब्योरा महत्त्वपूर्ण है: i18n PEP 750 की घोषित प्रेरणाओं में नहीं है। PEP ने तंत्र को सामान्यीकृत किया — एक टेम्पलेट type जिसे कोई भी लाइब्रेरी उपभोग कर सकती है — और अनुवाद का प्रश्न ठीक वहीं छोड़ दिया जहाँ PEP 501 ने उसे दस साल पहले खड़ा किया था: खुला।

तो Python 3.14 आते-आते भाषा के पास ठीक वही डेटा संरचना थी जो एक संदेश कैटलॉग को चाहिए, और उसे कैटलॉग की तरह उपयोग करने की कोई परिपाटी नहीं।

stdlib की चर्चा¶

3.14 के शिप होने से दो महीने पहले, Adrian Mönnich (ThiefMaster, Indico प्रोजेक्ट के एक अनुरक्षक) ने वह अंतर स्वयं मानक लाइब्रेरी में पाटने का प्रस्ताव रखा: discuss.python.org पर Support t-strings in gettext थ्रेड, अगस्त 2025 में खुला, जिसके साथ gettext और pygettext दोनों में t-string समर्थन जोड़ने वाला एक कार्यशील pull request था।

यह थ्रेड पूरा पढ़ने लायक़ है, क्योंकि इसमें हर वह कठिन प्रश्न उभरता है जिसका उत्तर इस लाइब्रेरी को बाद में देना पड़ा:

• इंटरपोलेशन क्या हो सकता है? केवल एक सरल नाम, या व्युत्पन्न placeholder नाम के साथ attributes और कॉल भी? हर उत्तर सुविधा को msgid की स्थिरता और कैटलॉग की सुरक्षा से तौलता है।
• बहुवचन रूपों को क्या चाहिए, जब लक्ष्य भाषा की बहुवचन प्रणाली स्रोत से भिन्न हो?
• क्या gettext सही लक्ष्य भी है? Barry Warsaw — जिन्होंने PEP 750 के विकास के दौरान तर्क दिया था कि t-strings i18n के लिए उपयुक्त नहीं — ने अपने flufl.i18n और उसकी $-string शैली को मित्रवत टूल बताया; दूसरों ने gettext को पूरी तरह पीछे छोड़कर Fluent जैसी नई प्रणालियों की ओर जाने की वकालत की।
• और मेटा-प्रश्न: मानक लाइब्रेरी जो भी शिप करे, वह लगभग कभी बदला नहीं जा सकता। इतने खुले चुनावों वाली परिपाटी को पहले ही प्रयास में स्थिर कर देना जोखिम भरा है।

कोई सहमति नहीं बनी। CPython issue not planned कहकर बंद हुआ और pull request बिना merge के अक्टूबर 2025 में बंद हुआ, 3.14 की रिलीज़ के कुछ ही दिन बाद। क्षमता भाषा में मौजूद थी; परिपाटी का कोई घर नहीं था।

पहले एक पैकेज क्यों¶

यही वह अंतर है जिसे इस प्रोजेक्ट ने मानक लाइब्रेरी के बाहर से भरना चुना, एक सोचे-समझे दाँव पर: परिपाटी वहाँ तेज़ी से परिपक्व होती है जहाँ वह स्वतंत्र रूप से संस्करण बदल सके और मामला-दर-मामला अपनाई जाए, और मानक लाइब्रेरी — जिसे पहली ही बार में सही होना पड़ता है — वह जगह है जहाँ परिपाटी को पहुँचना चाहिए, न कि जहाँ उसे गढ़ा जाए।

ठोस रूप में, थ्रेड के हर विवादित प्रश्न का यहाँ लिखा हुआ उत्तर है, हर एक अपने पेज पर:

• इंटरपोलेशन केवल सरल नाम हैं, ताकि msgid स्थिर और अर्थपूर्ण रहें — गाइड नियम दिखाती है, यह कैसे काम करता है कारण।
• फ़ॉर्मैटिंग पूरी तरह कैटलॉग से बाहर रहती है (t-strings क्यों)।
• बहुवचन एक union/intersection नियम का पालन करते हैं, जो लक्ष्य भाषा की बहुवचन प्रणाली को स्रोत से भिन्न होने देता है (spec §4)।
• टूटा हुआ कैटलॉग क्रैश की बजाय फ़ॉलबैक करता है, gettext का अपना अनुबंध निभाते हुए (गाइड)।
• और पूरी परिपाटी एक संस्करणित विनिर्देश है जिसके साथ मशीन-पठनीय कन्फ़ॉर्मन्स सुइट है — इस तरह लिखा गया कि कोई दूसरा क्रियान्वयन, भविष्य का कोई मानक-लाइब्रेरी वाला भी, उसे अपरिवर्तित अपनाकर अंतरसंचालित हो सके।

चर्चा समाप्त नहीं हुई है, और यह प्रोजेक्ट उसमें एक भागीदार है, उस पर कोई फ़ैसला नहीं। यदि आपके पास प्रोडक्शन का gettext अनुभव है जो इन चुनावों से जुड़ता है, तो वही थ्रेड और इस रिपॉज़िटरी के Discussions वे जगहें हैं जहाँ चर्चा जारी है।

समय-रेखा¶