Author:

Creation:2026-09-09Last update:2026-09-10

इस दस्तावेज़ को अपने पसंदीदा AI एसिस्टेंट के साथ संदर्भित करेंChatGPT Claude DeepSeek Google AI mode Gemini Perplexity Mistral Grok

अपने प्रश्न को पूछें और दस्तावेज़ का सारांश प्राप्त करें, इस पृष्ठ और आपके चुने हुए AI प्रदाता का उपयोग करके

इस पृष्ठ की सामग्री एक AI द्वारा अनुवादित की गई है।

अंग्रेजी में मूल सामग्री के अंतिम संस्करण देखें

इस दस्तावेज़ को संपादित करें

अगर आपके पास इस दस्तावेज़ को सुधारने के लिए कोई विचार है, तो कृपया GitHub पर एक पुल अनुरोध सबमिट करके योगदान देने में संकोच न करें।

दस्तावेज़ के लिए GitHub लिंक

Copy

दस्तावेज़ का Markdown को क्लिपबोर्ड पर कॉपी करें

जावास्क्रिप्ट अंतर्राष्ट्रीयकरण (i18n) का इतिहास

अंतर्राष्ट्रीयकरण कोई नई अवधारणा नहीं है। जावास्क्रिप्ट और आधुनिक वेब के आने से बहुत पहले ही सॉफ़्टवेयर को कई भाषाओं, मुद्राओं, दिनांक स्वरूपों और क्षेत्रीय मानकों को संभालना पड़ता था। 1980 के दशक में शुरुआती ग्राफिकल ऑपरेटिंग सिस्टम जैसे GEM और Mac OS पहले से ही इनमें से कई समस्याओं का समाधान कर रहे थे।

यही विचार अंततः बैकएंड फ्रेमवर्क में भी पहुंचे। Ruby on Rails, Django, Java फ्रेमवर्क और PHP अनुप्रयोगों ने अंतर्राष्ट्रीयकरण के लिए अपने-अपने दृष्टिकोण विकसित किए। बुनियादी प्रश्न काफी हद तक स्पष्ट थे:

अनुवाद कहां संग्रहीत होने चाहिए?
हम दिनांक, संख्याएं और मुद्राएं कैसे स्वरूपित करें?
हम बहुवचन और व्याकरणिक अंतरों को कैसे संभालें?
हम यह कैसे तय करें कि उपयोगकर्ता को कौन सी भाषा दिखनी चाहिए?

जब सर्वर पृष्ठ को रेंडर करता था, तो प्रक्रिया अपेक्षाकृत सीधी थी। एप्लिकेशन उपयुक्त अनुवाद लोड कर सकता था, HTML रेंडर कर सकता था और परिणाम ब्राउज़र को भेज सकता था।

ध्यान दें कि PHP और GNU gettext उस t() हेल्पर पैटर्न के अग्रदूत थे जो बाद में जावास्क्रिप्ट और JSX में सर्वव्यापी हो गया।

इसके बाद जावास्क्रिप्ट ने ब्राउज़र पर नियंत्रण करना शुरू किया।

जैसे-जैसे एप्लिकेशन सर्वर-रेंडर किए गए पेजों से जटिल क्लाइंट-साइड एप्लिकेशन में बदले, अंतर्राष्ट्रीयकरण फ्रंटएंड की समस्या भी बन गया। अचानक, ब्राउज़र को पेज को रीलोड किए बिना अनुवाद लोड करने, भाषा बदलने, मान स्वरूपित करने, बहुवचन संभालने और UI अपडेट करने की आवश्यकता पड़ी।

और इसने एक नया प्रश्न खड़ा किया:

आप हर उपयोगकर्ता को भारी मात्रा में अनुवाद डेटा और रनटाइम कोड भेजे बिना किसी एप्लिकेशन को बहुभाषी कैसे बनाते हैं?

इस प्रश्न ने एक दशक से अधिक समय तक जावास्क्रिप्ट i18n के विकास को आकार दिया है।

समाधानों में काफी बदलाव आया है। हम वैश्विक जावास्क्रिप्ट ऑब्जेक्ट्स और t('some.key') कॉल्स से फ्रेमवर्क-विशिष्ट लाइब्रेरीज़, कंपाइल-टाइम एक्सट्रैक्शन, टाइपस्क्रिप्ट-जेनरेटेड टाइप्स, सर्वर कंपोनेंट्स, ट्री-शेकिंग और अंततः कंपाइलर-आधारित दृष्टिकोणों तक पहुंचे हैं जहां अनुवाद बिल्ड के दौरान जावास्क्रिप्ट कोड में बदल जाते हैं।

यह लेख 2011 से 2026 तक के इस विकास पर नज़र डालता है: प्रत्येक पीढ़ी के उपकरणों ने क्या हल करने का प्रयास किया, क्या सफल रहा, क्या नहीं, और फ्रंटएंड आर्किटेक्चर ने आज i18n के हमारे तरीके को कैसे प्रभावित किया।

जावास्क्रिप्ट अंतर्राष्ट्रीयकरण लाइब्रेरी इकोसिस्टम

विषय सूची

शुरुआती वेब: 2016 से पहले जावास्क्रिप्ट अंतर्राष्ट्रीयकरण

आधुनिक i18n टूल्स की स्थिति को समझने के लिए, हमें यह देखना होगा कि 2011 और 2015 के बीच वेब विकास कैसा था।

क्लाइंट का बढ़ता दायरा

2010 के दशक की शुरुआत में, अंतर्राष्ट्रीयकरण मुख्य रूप से सर्वर-साइड ज़िम्मेदारी थी। जावास्क्रिप्ट काफी हद तक jQuery के माध्यम से एनिमेशन, फॉर्म सत्यापन और छोटे विजेट्स के लिए एक अतिरिक्त परत मात्र थी।

जैसे-जैसे सिंगल-पेज एप्लिकेशन (SPAs) Backbone.js, Knockout.js और शुरुआती AngularJS के साथ लोकप्रिय हुए, रेंडरिंग लॉजिक सीधे ब्राउज़र में स्थानांतरित हो गया। क्लाइंट-साइड कोड को अचानक पूर्ण पेज रीफ्रेश के बिना स्थानीय दिनांक प्रदर्शित करने, मुद्राओं को स्वरूपित करने, बहुवचन संभालने और गतिशील रूप से टेक्स्ट बदलने की आवश्यकता पड़ी।

फिर भी 2011 का ब्राउज़र वातावरण इस चुनौती के लिए तैयार नहीं था:

ECMAScript अंतर्राष्ट्रीयकरण API विनिर्देश (ECMA-402) को केवल दिसंबर 2012 में अंतिम रूप दिया गया था, जिसने वैश्विक Intl ऑब्जेक्ट पेश किया। ब्राउज़र विक्रेताओं द्वारा Intl अपनाने से पहले, बुनियादी दिनांक और संख्या स्वरूपण के लिए भी कस्टम फ़ंक्शन या भारी पॉलीफिल की आवश्यकता होती थी।

Webpack जैसे उपकरण अपनी प्रारंभिक अवस्था में थे, और ब्राउज़र में ESM मौजूद नहीं था। डेवलपर्स <script> टैग के माध्यम से स्क्रिप्ट लोड करते थे, अक्सर window.translations = { ... } जैसे वैश्विक ऑब्जेक्ट्स में अनुवाद इंजेक्ट करते थे।

अनुवाद विशाल, केंद्रीकृत JSON फ़ाइलों में लिखे जाते थे। टोक्यो में लैंडिंग पेज लोड करने वाला उपयोगकर्ता भी अकाउंट सेटिंग्स, बिलिंग पैनल और एडमिन डैशबोर्ड के लिए स्ट्रिंग्स डाउनलोड करता था।

क्लाइंट-साइड लाइब्रेरीज़ की पहली लहर

2012 और 2015 के बीच, आधुनिक जावास्क्रिप्ट i18n की प्रारंभिक नींव रखी गई:

Jan Mühlemann द्वारा निर्मित, i18next ने जावास्क्रिप्ट में रनटाइम की-वैल्यू डिक्शनरी का खाका तैयार किया। इसने की-ट्रेवर्सल, वेरिएबल इंटरपोलेशन, प्लूरलाइज़ेशन रूल्स और लैंग्वेज डिटेक्टरों व बैकएंड्स के लिए प्लगेबल आर्किटेक्चर पेश किया। यह वैनिला जेएस और शुरुआती Node.js बैकएंड में मानक बन गया।

Kazupon (Kazuya Kawaguchi) द्वारा निर्मित, vue-i18n ने Vue.js रिएक्टिव डेटा-बाइंडिंग मॉडल में अंतर्राष्ट्रीयकरण को अनुकूलित किया, जिसमें टेम्पलेट निर्देश (v-t) और $t() हेल्पर पेश किए गए।

FormatJS प्रोजेक्ट के हिस्से के रूप में Yahoo! द्वारा निर्मित, react-intl ने <FormattedMessage> और <FormattedDate> जैसे घटकों के माध्यम से रिएक्ट में मानकीकृत ICU MessageFormat और ब्राउज़र Intl API पेश किए।

Jan Mühlemann ने तेजी से बढ़ते रिएक्ट समुदाय में i18next की शुरुआत की, जिसमें भाषा परिवर्तन पर घटकों को फिर से रेंडर करने के लिए हायर-ऑर्डर कंपोनेंट्स (withTranslation) और रिएक्ट कॉन्टेक्स्ट का उपयोग किया गया।

2016 से पहले के युग की सीमाएं

यद्यपि इन उपकरणों ने बहुभाषी क्लाइंट अनुप्रयोगों को सक्षम किया, उस युग की वास्तुशिल्प सीमाओं ने कई समस्याएं पैदा कीं:

t('marketing.landing.hero.cta') जैसे लुकअप्स ने कोई स्थैतिक सत्यापन प्रदान नहीं किया। कुंजियों में टाइपिंग त्रुटियां प्रोडक्शन में बिना किसी त्रुटि संदेश के विफल हो गईं, जिससे अंतिम उपयोगकर्ताओं को खाली लेबल या कच्चे की-नाम दिखाई दिए।

ICU संदेश सिंटैक्स को पार्स करना और रनटाइम पर रेगेक्स-आधारित इंटरपोलेशन का मूल्यांकन करना मोबाइल उपकरणों पर CPU संसाधनों की खपत करता था।

रूट-आधारित या घटक-स्तरीय कोड विभाजन के बिना, सभी स्थानीयकृत स्ट्रिंग्स एक साथ लोड होती थीं, जिससे प्रारंभिक पेज लोड समय पर बुरा प्रभाव पड़ता था।

केंद्रीकृत JSON फ़ाइलों में अनुवाद घटकों से बहुत दूर संग्रहीत होते थे, जिससे अनुपयोगी कुंजियाँ और गायब अनुवाद आम समस्याएं बन गईं।

फ्रेमवर्क युग: विभिन्न इकोसिस्टम्स में विकास

2016 और 2026 के बीच, फ्रंटएंड आर्किटेक्चर पूरी तरह बदल गया। टाइपस्क्रिप्ट मानक बन गया, घटक-आधारित आर्किटेक्चर परिपक्व हुआ, Webpack, Vite और Turbopack जैसे बंडलर्स ने कोड स्प्लिटिंग की शुरुआत की, रिएक्ट सर्वर कंपोनेंट्स ने रेंडरिंग को वापस सर्वर पर स्थानांतरित किया, और कंपाइलर्स ने एप्लिकेशन कोड का विश्लेषण करना शुरू किया।

निम्नलिखित टैब दिखाते हैं कि प्रत्येक फ्रेमवर्क और इकोसिस्टम ने रिलीज़ की तारीखों, मूल उद्देश्यों और नवाचारों के साथ इन चुनौतियों का समाधान कैसे किया। इन इकोसिस्टम्स में, react-intlayer और इसके समकक्ष फ्रेमवर्क कार्यान्वयन (next-intlayer, vue-intlayer, angular-intlayer, svelte-intlayer, और solid-intlayer) अपने-अपने रनटाइम वातावरण के लिए विशेष रूप से तैयार किए गए उच्च प्रदर्शन समाधान हैं।

सभी तालिका सामग्री दिखाएं