براہِ راست مواد پر جائیں

پس منظر

یہ لائبریری دو طویل کہانیوں کے سنگم پر کھڑی ہے — ایک اس بارے میں کہ سافٹ ویئر کا ترجمہ کیسے ہوتا ہے، دوسری اس بارے میں کہ Python سٹرنگز میں انٹرپولیشن کیسے کرتی ہے — جو بالآخر 2025 میں آ کر ملیں اور پھر ٹھیک اسی مقام پر رک گئیں جہاں ایک چھوٹے، محتاط اصول کی ضرورت تھی۔ یہ صفحہ دونوں کہانیاں حوالوں کے ساتھ سناتا ہے، کیونکہ اس سائٹ کے ڈیزائن کے فیصلوں کو پرکھنا اُس وقت آسان ہوتا ہے جب آپ کو وہ سوال بھی نظر آئیں جن کا وہ جواب ہیں۔

gettext کا ماحولی نظام

نوے کی دہائی کے وسط سے GNU gettext ہی وہ طریقہ ہے جس سے آزاد سافٹ ویئر کا ترجمہ ہوتا آیا ہے: کوڈ میں سٹرنگز نشان زد کیجیے، انہیں ایک ٹیمپلیٹ میں نکالیے، مترجموں کو ہر زبان کے لیے ایک کیٹلاگ فائل دیجیے، کمپائل کیجیے، اور رن ٹائم پر لوڈ کر لیجیے۔ اسی چکر کے گرد ایک پورا ماحولی نظام اُگ آیا — PO ایڈیٹر، جائزے کے ورک فلو، اور ترجمے کے پلیٹ فارم جو سب ایک ہی فائل صیغہ بولتے ہیں — اور Python دو دہائیوں سے زیادہ عرصے سے اپنی معیاری لائبریری میں gettext ماڈیول بھیجتی رہی ہے۔ ترجمے کا رن ٹائم والا نصف کبھی مسئلہ نہیں تھا۔

جو نصف ہمیشہ بے فیصلہ رہا وہ یہ تھا کہ کیٹلاگ کی سٹرنگ دکھتی کیسی ہے۔ %(name)s والا پیغام مترجموں کو printf کی نحو تھما دیتا ہے، جس میں ایک حرف مٹنے سے پروڈکشن کا کریش بن جاتا ہے؛ .format() والا پیغام کیٹلاگ کو زندہ آبجیکٹس پر خصوصیات تک رسائی دے دیتا ہے۔ (t-string کیوں دونوں سے گزرتا ہے، ناکامیوں کو سامنے رکھ کر۔) اور f-string — یعنی وہ نحو جو اب زیادہ تر Python کوڈ کو پسند ہے — شریک ہی نہیں ہو سکتی: جب تک کوئی لائبریری اسے دیکھتی ہے، وہ پہلے ہی مکمل شدہ سٹرنگ بن چکی ہوتی ہے۔ لوگ پھر بھی کوشش کرتے ہیں، اتنی بار کہ Babel کا ایشو ٹریکر ان کوششوں کا مجموعہ بن گیا ہے (#594، #715)؛ یہ ناکامی ساختی ہے، کوئی نامکمل خصوصیت نہیں۔

دو PEP، دس برس کے فاصلے پر

سنہ 2015 میں Alyssa Coghlan اور Nick Humrich نے PEP 501 لکھا، جس میں ایسے انٹرپولیشن ٹیمپلیٹ تجویز کیے گئے جن کا بیان کردہ پہلا محرک i18n تھا — خود PEP کے الفاظ میں، "i18n ترجمے کے لیے صاف تر نحو فراہم کرنا"۔ تجویز مؤخر کر دی گئی، جزوی طور پر اس لیے کہ بحث نے دکھایا کہ i18n کا معاملہ کئی ایسے اضافی پہلو اٹھائے ہوئے ہے جو سادہ تر استعمالات میں نہیں تھے۔

ایک دہائی بعد PEP 750 — از Jim Baker، Guido van Rossum، Paul Everitt، Koudai Aono، Lysandros Nikolaou اور Dave Peck — نے اسی خیال کو t-string کے نام سے زندہ کیا، جو اپریل 2025 میں منظور ہوا اور اکتوبر 2025 میں Python 3.14 کے ساتھ آ گیا۔ پھر PEP 501 اسی کے حق میں واپس لے لیا گیا۔ ایک تفصیل اس صفحے کے لیے اہم ہے: i18n PEP 750 کے بیان کردہ محرکات میں شامل نہیں ہے۔ PEP نے سازوسامان کو عام بنا دیا — ایک ٹیمپلیٹ قسم جسے کوئی بھی لائبریری استعمال کر سکے — اور ترجمے کا سوال ٹھیک وہیں چھوڑ دیا جہاں PEP 501 اسے دس برس پہلے کھڑا کر گیا تھا: کھلا۔

چنانچہ Python 3.14 کے آتے آتے زبان کے پاس بالکل وہی ڈھانچہ موجود تھا جو ایک پیغام کیٹلاگ کو درکار ہے، اور اسے اس طور برتنے کا کوئی اصول نہیں تھا۔

معیاری لائبریری کی بحث

‏3.14 کے آنے سے دو ماہ پہلے، Adrian Mönnich (ThiefMaster، Indico پروجیکٹ کے ایک نگہبان) نے یہ خلا خود معیاری لائبریری میں پُر کرنے کی تجویز دی: discuss.python.org پر اگست 2025 میں کھلنے والا دھاگا Support t-strings in gettext ایک چلتی ہوئی پل ریکویسٹ کے ساتھ آیا، جو gettext اور pygettext دونوں میں t-string کی حمایت جوڑتی تھی۔

یہ دھاگا پورا پڑھنے کے لائق ہے، کیونکہ اس میں ہر وہ مشکل سوال سامنے آ جاتا ہے جس کا جواب اس لائبریری کو بعد میں دینا پڑا:

  • انٹرپولیشن کیا ہو سکتی ہے؟ صرف ایک سادہ نام، یا خصوصیات اور کالیں بھی، جن سے پلیس ہولڈر کا نام اخذ ہو؟ ہر جواب سہولت کو msgid کے استحکام اور کیٹلاگ کی حفاظت کے بدلے دیتا ہے۔
  • جمع کی صورتوں کے لیے کیا درکار ہے، جب ہدف زبان کا جمع کا نظام ماخذ سے مختلف ہو؟
  • کیا gettext ہی درست ہدف ہے؟ Barry Warsaw — جو PEP 750 کی تیاری کے دوران یہ دلیل دے چکے تھے کہ t-string i18n کے لیے موزوں نہیں — نے اپنے flufl.i18n اور اس کے $-سٹرنگ اسلوب کی طرف زیادہ خوشگوار اوزار کے طور پر اشارہ کیا؛ کچھ اور لوگوں نے gettext کو یکسر چھوڑ کر Fluent جیسے نئے نظاموں کی طرف جانے کی وکالت کی۔
  • اور بنیادی سوال: معیاری لائبریری جو کچھ بھی بھیجے، وہ عملاً کبھی بدل نہیں سکتی۔ اتنے کھلے انتخابات والے اصول کو پہلی ہی کوشش میں منجمد کر دینا خطرناک بات ہے۔

کوئی اتفاقِ رائے نہ بن سکا۔ CPython کا ایشو not planned کہہ کر بند کر دیا گیا اور پل ریکویسٹ اکتوبر 2025 میں، ‏3.14 کی ریلیز کے چند دن بعد، بغیر ضم ہوئے بند ہو گئی۔ صلاحیت زبان میں موجود تھی؛ اصول کا کوئی گھر نہیں تھا۔

پہلے ایک پیکیج کیوں

یہی وہ خلا ہے جسے اس پروجیکٹ نے معیاری لائبریری سے باہر رہ کر پُر کرنے کا انتخاب کیا، ایک سوچے سمجھے داؤ پر: کوئی اصول وہاں تیزی سے پختہ ہوتا ہے جہاں وہ آزادی سے ورژن بدل سکے اور معاملہ در معاملہ اپنائیت کما سکے، اور معیاری لائبریری — جسے پہلی ہی بار درست ہونا ہے — وہ جگہ ہے جہاں کسی اصول کو پہنچنا چاہیے، نہ کہ جہاں اسے طے کیا جائے۔

ٹھوس الفاظ میں، اس دھاگے کے ہر متنازع سوال کا لکھا ہوا جواب یہاں موجود ہے، ہر ایک اپنے صفحے پر:

  • انٹرپولیشن صرف سادہ نام ہیں، تاکہ msgid مستحکم اور بامعنی رہیں — رہنما اصول دکھاتا ہے، یہ کیسے کام کرتی ہے وجوہات۔
  • فارمیٹنگ کیٹلاگ سے مکمل طور پر باہر رہتی ہے (t-string کیوں
  • جمع ایک اتحاد/اشتراک کے اصول پر چلتی ہے جو ہدف زبان کے جمع کے نظام کو ماخذ سے مختلف ہونے دیتا ہے (تصریح §4
  • ٹوٹا ہوا کیٹلاگ کریش کرنے کے بجائے واپس ماخذ پر آ جاتا ہے، اور یوں خود gettext کا معاہدہ نبھاتا ہے (رہنما
  • اور پورا اصول ایک ورژن والی تصریح ہے، مع مشین سے پڑھی جانے والی مطابقت سویٹ کے — یوں لکھی گئی کہ کوئی دوسرا نفاذ، بشمول مستقبل کے کسی معیاری لائبریری والے نفاذ کے، اسے جوں کا توں اپنا کر ساتھ چل سکے۔

بحث ختم نہیں ہوئی، اور یہ پروجیکٹ اس میں ایک فریق ہے، اس پر کوئی فیصلہ نہیں۔ اگر آپ کے پاس پروڈکشن کا gettext تجربہ ہے جو ان انتخابات سے تعلق رکھتا ہو، تو وہی دھاگا اور اس ریپازٹری کے Discussions وہ جگہیں ہیں جہاں یہ گفتگو جاری ہے۔

زمانی خاکہ

کب کیا ہوا
نوے کی دہائی کا وسط GNU gettext وہ PO/POT/MO ورک فلو قائم کرتا ہے جو مترجم اور پلیٹ فارم آج بھی بولتے ہیں۔
2015 PEP 501 انٹرپولیشن ٹیمپلیٹ تجویز کرتا ہے، جس کا پہلا محرک i18n ہے؛ مؤخر۔
2016 f-string Python 3.6 میں آتی ہیں — انٹرپولیشن کو اس کی نحو مل جاتی ہے، اور ترجمہ اسے استعمال نہیں کر سکتا۔
جولائی 2024 PEP 750 t-string تجویز کرتا ہے۔
اپریل 2025 PEP 750 منظور؛ PEP 501 اسی کے حق میں واپس۔
اگست 2025 Support t-strings in gettext دھاگا کھلتا ہے، مع معیاری لائبریری کی ایک پل ریکویسٹ کے۔
اکتوبر 2025 Python 3.14 t-string کے ساتھ آتی ہے؛ معیاری لائبریری کا ایشو not planned کہہ کر بند۔
2026 gettext-tstrings ایک الفا کے طور پر آتی ہے، مع تصریح v1 اور اس کی مطابقت سویٹ کے۔