পটভূমি¶

এই লাইব্রেরির অবস্থান দুটি দীর্ঘ কাহিনির সন্ধিস্থলে — একটি সফটওয়্যার কীভাবে অনুবাদ হয় তা নিয়ে, অন্যটি Python কীভাবে স্ট্রিং ইন্টারপোলেট করে তা নিয়ে — যে দুটি অবশেষে ২০২৫ সালে মিলল, আর তারপর ঠিক সেইখানে থেমে গেল যেখানে একটি ছোট, সতর্ক রীতির দরকার ছিল। এই পৃষ্ঠা দুটি কাহিনিই বলে, উৎসের লিঙ্কসহ, কারণ এই সাইটের নকশা-সিদ্ধান্তগুলি বিচার করা সহজ হয় যখন সেগুলি কোন প্রশ্নের উত্তর দিচ্ছে তা আপনি দেখতে পান।

gettext ইকোসিস্টেম¶

নব্বইয়ের দশকের মাঝামাঝি থেকে মুক্ত সফটওয়্যার এভাবেই অনুবাদ হয়ে আসছে GNU gettext-এর মাধ্যমে: কোডে স্ট্রিংগুলি চিহ্নিত করুন, একটি টেমপ্লেটে এক্সট্র্যাক্ট করুন, অনুবাদকদের প্রতি ভাষায় একটি করে ক্যাটালগ ফাইল দিন, কম্পাইল করুন, রানটাইমে লোড করুন। সেই লুপকে ঘিরে গড়ে উঠেছে একটি গোটা ইকোসিস্টেম — PO এডিটর, রিভিউ ওয়ার্কফ্লো, আর অনুবাদ প্ল্যাটফর্ম, যারা সবাই একই ফাইল ফরম্যাটে কথা বলে — আর Python দুই দশকেরও বেশি সময় ধরে নিজের স্ট্যান্ডার্ড লাইব্রেরিতে একটি gettext মডিউল দিয়ে এসেছে। অনুবাদের রানটাইম অর্ধেকটা কখনও সমস্যা ছিল না।

অমীমাংসিত অর্ধেকটা বরাবরই ছিল ক্যাটালগ স্ট্রিংটি দেখতে কেমন। একটি %(name)s বার্তা অনুবাদকদের হাতে printf সিনট্যাক্স তুলে দেয়, যেখানে একটি অক্ষর মুছে গেলেই প্রোডাকশন ক্র্যাশ; একটি .format() বার্তা ক্যাটালগের হাতে জীবন্ত অবজেক্টের অ্যাট্রিবিউট অ্যাক্সেস তুলে দেয়। (t-strings কেন দুটিরই মধ্য দিয়ে হাঁটে, ব্যর্থতাগুলি চোখের সামনে রেখে।) আর f-strings — আজকের বেশিরভাগ Python কোড যে সিনট্যাক্স পছন্দ করে — অংশই নিতে পারে না: কোনও লাইব্রেরি যখন একটি দেখে, ততক্ষণে সেটি সমাপ্ত একটি স্ট্রিং। তবু লোকে চেষ্টা করে, এত বার যে Babel-এর issue tracker সেই চেষ্টাগুলি জমিয়ে রাখে (#594, #715); ব্যর্থতাটি কাঠামোগত, কোনও অনুপস্থিত ফিচার নয়।

দুটি PEP, দশ বছরের ব্যবধানে¶

২০১৫ সালে 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 হিসেবে পুনরুজ্জীবিত করে, ২০২৫ সালের এপ্রিলে গৃহীত হয়, আর ২০২৫ সালের অক্টোবরে Python 3.14-এ আসে। PEP 501 তখন তার অনুকূলে প্রত্যাহার করা হয়। একটি বিবরণ এই পৃষ্ঠার জন্য গুরুত্বপূর্ণ: i18n PEP 750-এর ঘোষিত প্রেরণাগুলির মধ্যে নেই। PEP-টি ব্যবস্থাটিকে সাধারণীকৃত করেছে — একটি টেমপ্লেট টাইপ, যা যেকোনও লাইব্রেরি গ্রহণ করতে পারে — আর অনুবাদের প্রশ্নটিকে ঠিক সেখানেই রেখে দিয়েছে যেখানে PEP 501 দশ বছর আগে তাকে রেখে গিয়েছিল: খোলা।

তাই Python 3.14 আসার সঙ্গে সঙ্গে ভাষাটির হাতে ছিল একটি বার্তা ক্যাটালগের ঠিক যে ডেটা স্ট্রাকচারটি দরকার, আর তাকে সেভাবে ব্যবহার করার কোনও রীতি ছিল না।

stdlib-এর আলোচনা¶

3.14 আসার দু'মাস আগে Adrian Mönnich (ThiefMaster, Indico প্রকল্পের একজন রক্ষণাবেক্ষক) সেই ফাঁকটি স্ট্যান্ডার্ড লাইব্রেরির ভিতরেই বন্ধ করার প্রস্তাব দেন: discuss.python.org-এ ২০২৫ সালের অগস্টে খোলা Support t-strings in gettext থ্রেডটির সঙ্গে ছিল একটি কার্যকর pull request, যা gettext ও pygettext — দুটিতেই t-string সমর্থন যোগ করছিল।

থ্রেডটি পুরোটা পড়ার মতো, কারণ এই লাইব্রেরিকে পরে যে কঠিন প্রশ্নগুলির উত্তর দিতে হয়েছে, তার প্রতিটিই সেখানে উঠে আসে:

• একটি ইন্টারপোলেশন কী হতে পারে? কেবল একটি সরল নাম, নাকি ব্যুৎপন্ন placeholder নামসহ অ্যাট্রিবিউট ও কল? প্রতিটি উত্তরই সুবিধার বিনিময়ে msgid স্থিতিশীলতা ও ক্যাটালগ নিরাপত্তা বেচে দেয়।
• বহুবচন রূপে কী প্রয়োজন, যখন লক্ষ্য ভাষার বহুবচন ব্যবস্থা উৎস ভাষার থেকে আলাদা?
• gettext-ই কি আদৌ সঠিক লক্ষ্য? Barry Warsaw — যিনি PEP 750 তৈরির সময়ই যুক্তি দিয়েছিলেন যে t-strings i18n-এর জন্য উপযুক্ত নয় — তাঁর flufl.i18n ও তার $-string ধরনটিকে বেশি বন্ধুত্বপূর্ণ টুল হিসেবে দেখিয়েছিলেন; অন্যরা যুক্তি দেন gettext-কে পুরোপুরি ছেড়ে Fluent-এর মতো নতুনতর ব্যবস্থার দিকে যাওয়ার।
• আর মেটা-প্রশ্নটি: স্ট্যান্ডার্ড লাইব্রেরি যা-ই দিক, তা মূলত আর কখনও বদলানো যায় না। এত খোলা সিদ্ধান্তওয়ালা একটি রীতিকে প্রথম চেষ্টাতেই জমিয়ে ফেলা ঝুঁকিপূর্ণ।

কোনও ঐকমত্য তৈরি হয়নি। CPython issue-টি "not planned" হিসেবে বন্ধ হয়, আর pull request-টি ২০২৫ সালের অক্টোবরে, 3.14 রিলিজের কয়েক দিন পরেই, মার্জ না হয়েই বন্ধ হয়। ক্ষমতাটি ভাষার ভিতরে ছিল; রীতিটির কোনও ঘর ছিল না।

কেন প্রথমে একটি প্যাকেজ¶

এই প্রকল্প সেই ফাঁকটিই স্ট্যান্ডার্ড লাইব্রেরির বাইরে থেকে পূরণ করতে বেছে নিয়েছে, একটি সচেতন বাজি ধরে: একটি রীতি সেখানেই দ্রুত পরিণত হয় যেখানে সে স্বাধীনভাবে সংস্করণ বদলাতে পারে এবং ক্ষেত্র ধরে ধরে গ্রহণযোগ্যতা অর্জন করতে পারে, আর স্ট্যান্ডার্ড লাইব্রেরি — যাকে প্রথম বারেই ঠিক হতে হয় — সেই জায়গা যেখানে একটি রীতির শেষ হওয়া উচিত, যেখানে তার মীমাংসা হওয়া উচিত নয়।

বাস্তবে, থ্রেডের প্রতিটি বিতর্কিত প্রশ্নের একটি করে লিখিত উত্তর এখানে আছে, প্রতিটি নিজের পৃষ্ঠায়:

• ইন্টারপোলেশন কেবল সরল নাম, যাতে msgid স্থিতিশীল ও অর্থবহ থাকে — গাইড নিয়মটি দেখায়, এটি কীভাবে কাজ করে কারণগুলি।
• ফরম্যাটিং ক্যাটালগের পুরোপুরি বাইরে থাকে (t-strings কেন)।
• বহুবচন একটি union/intersection নিয়ম মেনে চলে, যা লক্ষ্য ভাষার বহুবচন ব্যবস্থাকে উৎস ভাষার থেকে আলাদা হতে দেয় (spec §4)।
• ভাঙা ক্যাটালগ ক্র্যাশ না করে ফলব্যাক করে, gettext-এর নিজের চুক্তি রক্ষা করে (গাইড)।
• আর গোটা রীতিটি একটি সংস্করণযুক্ত স্পেসিফিকেশন, সঙ্গে মেশিন-পাঠযোগ্য কনফরম্যান্স সুইট — এমনভাবে লেখা যাতে আরেকটি বাস্তবায়ন, এমনকি ভবিষ্যতের কোনও স্ট্যান্ডার্ড-লাইব্রেরি বাস্তবায়নও, তা অপরিবর্তিত গ্রহণ করে আন্তঃক্রিয়া করতে পারে।

আলোচনাটি শেষ হয়নি, আর এই প্রকল্প তাতে একজন অংশগ্রহণকারী, তার উপর কোনও রায় নয়। এই সিদ্ধান্তগুলিকে স্পর্শ করে এমন প্রোডাকশন gettext অভিজ্ঞতা আপনার থাকলে, সেই থ্রেড আর এই রিপোজিটরির Discussions সেখানেই আলোচনাটি চলতে থাকে।

সময়রেখা¶