एंगुलर i18n बिल्ड-टाइम बनाम रनटाइम की व्याख्या

एंगुलर में अंतर्राष्ट्रीयकरण दो अलग-अलग मॉडलों का अनुसरण कर सकता है - बिल्ड-टाइम या रनटाइम। आधिकारिक दृष्टिकोण का उपयोग करता है @angular/localizeयह सेटअप प्रत्येक भाषा के लिए एक अलग बिल्ड तैयार करता है। यह सेटअप रनटाइम पर स्थिर और तेज़ है, लेकिन इसके लिए कई डिप्लॉयमेंट की योजना बनाना और ऐप के अंदर भाषा स्विचिंग की सुविधा न होना आवश्यक है।

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

यदि आपको रीलोड किए बिना डायनामिक स्विचिंग की आवश्यकता है, तो रनटाइम लाइब्रेरी इसके लिए उपयुक्त विकल्प हैं। लोकप्रिय विकल्पों में ngx-translate और angular-i18next शामिल हैं। ये लाइब्रेरी आवश्यकतानुसार अनुवाद लोड करती हैं और UI को तुरंत अपडेट करती हैं, हालांकि सेटअप, प्रदर्शन और SSR सपोर्ट के मामले में इनमें कुछ कमियां और खूबियां हैं।

इस लेख में, हम बताते हैं कि अंतर्निहित एंगुलर अंतर्राष्ट्रीयकरण (i18n) वर्कफ़्लो कैसे काम करता है, इसे कैसे तैनात किया जाए, और कब रनटाइम लाइब्रेरी बेहतर विकल्प होती है।

कैसे @angular/localize काम करता है

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

इसमें रनटाइम भाषा बदलने की सुविधा नहीं है, इसलिए सेटअप निष्कर्षण और निर्माण कॉन्फ़िगरेशन पर केंद्रित है।

आइए पूरी कार्यप्रणाली को समझते हैं:

1. टेम्प्लेट और टाइपस्क्रिप्ट में अनुवाद के लिए टेक्स्ट को चिह्नित करें। HTML सामग्री और विशेषताओं के लिए i18n विशेषता का उपयोग करें। $स्थानीयकरण टाइपस्क्रिप्ट में, स्ट्रिंग्स को भी उसी निष्कर्षण प्रक्रिया में शामिल किया जाता है।
2. Angular CLI का उपयोग करके संदेशों को अनुवाद फ़ाइल में निकालें। यह डिफ़ॉल्ट रूप से एक XLIFF फ़ाइल उत्पन्न करता है, जिसमें आपके सेटअप के आधार पर अन्य प्रारूपों के विकल्प भी उपलब्ध हैं, जिनमें संदेश ID और मूल पाठ शामिल होते हैं।
3. निकाली गई फ़ाइल का अनुवाद करें और पहचानकर्ताओं को स्थिर रखें। आवश्यकतानुसार कस्टम आईडी जोड़ें ताकि मूल पाठ में किए गए अपडेट मौजूदा अनुवादों को खराब न करें या अप्रत्यक्ष विसंगतियां उत्पन्न न करें।
4. प्रत्येक लोकेल के लिए ऐप का एक ही संस्करण बनाएं और डिप्लॉय करें। angular.json में लोकेल कॉन्फ़िगर करें, फिर भाषा-विशिष्ट बंडल जेनरेट करें जिन्हें अलग-अलग रूट या डोमेन से सर्व किया जाता है।

बहुवचन बनाने के लिए ICU अभिव्यक्तियों का उपयोग किया जाता है। आप ऐसे मामलों को परिभाषित करते हैं जैसे =0, =1, या अन्यऔर एंगुलर सक्रिय लोकेल के आधार पर सही फॉर्म का चयन करता है। भाषाएँ इस बात में भिन्न होती हैं कि उन्हें कितने फॉर्म की आवश्यकता होती है, इसलिए संदेश संरचना की योजना पहले से ही बना लें।

नेस्टेड आईसीयू एक्सप्रेशंस एक ही पैटर्न का पालन करते हैं लेकिन जटिलता बढ़ाते हैं, इसलिए उन्हें पठनीय रखें और विभिन्न लोकेशंस में उनका परीक्षण करें।

मल्टी-लोकेल एंगुलर ऐप्स का निर्माण और परिनियोजन

एंगुलर के बिल्ड-टाइम i18n के साथ, परिनियोजन सीधे तौर पर इस बात से जुड़ा होता है कि आप angular.json को कैसे कॉन्फ़िगर करते हैं। आप एक स्रोत लोकेल और लक्ष्य लोकेल का एक सेट परिभाषित करते हैं, जिनमें से प्रत्येक को एक अनुवाद फ़ाइल से मैप किया जाता है।

बिल्ड प्रक्रिया के दौरान, एंगुलर ऐप को एक बार कंपाइल करता है, फिर पोस्ट-प्रोसेसिंग चरण के रूप में स्थानीयकृत प्रतिस्थापन लागू करता है। इसका मतलब है कि आप प्रत्येक भाषा के लिए पूर्ण बिल्ड नहीं चला रहे हैं, लेकिन फिर भी आपको प्रत्येक लोकेल के लिए अलग-अलग आउटपुट बंडल प्राप्त होते हैं।

प्रत्येक लोकेल ऐप का अपना संस्करण तैयार करता है, जिसे आमतौर पर सबपाथ या डोमेन से सर्व किया जाता है। एक सामान्य सेटअप में निम्नलिखित पाथ का उपयोग किया जाता है। /en/ और /fr/प्रत्येक फ़ाइल अपने संबंधित बिल्ड आउटपुट की ओर इंगित करती है। यह संरचना आवश्यक है क्योंकि अनुवादित सामग्री फ़ाइलों में अंतर्निहित होती है, इसलिए भाषा बदलने का अर्थ है एक अलग बिल्ड लोड करना।

सर्वर कॉन्फ़िगरेशन i18n सेटअप का हिस्सा बन जाता है। आपको ऐसे रूटिंग नियमों की आवश्यकता होती है जो आने वाले अनुरोधों को सही लोकेल संस्करण से मैप करें।

इसका कार्यान्वयन वातावरण के अनुसार काफी भिन्न होता है – Nginx में सीधे रीराइट नियम, जबकि Firebase Hosting में कुछ ही घोषणात्मक पंक्तियाँ – लेकिन लक्ष्य एक ही है। अनुरोधों को URL संरचना या रीडायरेक्ट लॉजिक के आधार पर सही स्थानीयकृत बंडल तक पहुँचाया जाना चाहिए।

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

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

इस मॉडल के बुनियादी ढांचे पर स्पष्ट प्रभाव पड़ते हैं। आपको कई बिल्ड आर्टिफैक्ट्स को मैनेज करना होगा, प्रत्येक लोकेल के लिए रूटिंग कॉन्फ़िगर करनी होगी और सर्वर स्तर पर रीडायरेक्ट को संभालना होगा। CI पाइपलाइनों को अनुवाद अपडेट का ध्यान रखना होगा और सामग्री में बदलाव होने पर स्थानीयकृत आउटपुट को फिर से बनाना होगा।

एक वैकल्पिक दृष्टिकोण इस जटिलता से बचता है। Weglot जैसे रिवर्स प्रॉक्सी मॉडल सर्वर और ब्राउज़र के बीच में स्थित होते हैं। यह सामग्री का तुरंत अनुवाद करता है और एक ही डिप्लॉयमेंट से सभी भाषाओं को सेवा प्रदान करता है। इससे कई बिल्ड और रूटिंग नियमों की आवश्यकता समाप्त हो जाती है। अधिक जानकारी के लिए Weglot बाद में!

रनटाइम लाइब्रेरी की तुलना: ngx-translate, Transloco और angular-i18next

रनटाइम लाइब्रेरी, एंगुलर के बिल्ट-इन i18n से अलग समस्या का समाधान करती हैं। ऐप में अनुवादों को कंपाइल करने के बजाय, वे उन्हें रनटाइम पर लोड करती हैं और पूरे ऐप को रीलोड किए बिना UI को अपडेट करती हैं।

इससे वे तब बेहतर विकल्प बन जाते हैं जब उपयोगकर्ताओं को ऐप के भीतर भाषा बदलने की आवश्यकता होती है या जब सामग्री बार-बार बदलती रहती है।

एनजीएक्स-अनुवाद यह सबसे व्यापक रूप से उपयोग किया जाने वाला विकल्प है। यह भाषा बदलने के लिए त्वरित स्विचिंग की सुविधा प्रदान करता है। अनुवाद.उपयोग()JSON फ़ाइलों या API से लोड किए गए अनुवादों के साथ। यह छोटे ऐप्स में अच्छी तरह से काम करता है और यहाँ एकमात्र ऐसा विकल्प है जिसकी पुष्टि हो चुकी है। ईओण का संगतता। एसएसआर संभव है स्थानांतरण राज्य और कस्टम लोडर, हालांकि इसके लिए सेटअप की आवश्यकता होती है। हाल के संस्करणों में एक प्रदाता-आधारित एपीआई जोड़ा गया है, जो स्टैंडअलोन घटकों के साथ बेहतर तालमेल बिठाता है।

ट्रांसलोको यह संरचना और स्केलेबिलिटी पर केंद्रित है। यह बिल्ट-इन SSR सपोर्ट और ng add के साथ एक सुव्यवस्थित सेटअप प्रदान करता है। यह स्कोप्ड ट्रांसलेशन को भी सपोर्ट करता है, जिससे आप प्रति फीचर भाषा फ़ाइलों को लेज़ी-लोड कर सकते हैं। इससे बंडल का आकार कम होता है और बड़े ऐप्स को रखरखाव योग्य बनाए रखने में मदद मिलती है। भाषा स्विचिंग का उपयोग करता है सेटएक्टिवलैंग() और यह यूआई को तुरंत अपडेट करता है।

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

यहां एक अधिक प्रत्यक्ष तुलना दी गई है:

यह चुनाव इस बात पर निर्भर करता है कि आपका ऐप भाषा परिवर्तन और विस्तार को कैसे संभालता है:

• यदि आपको सरल सेटअप या आयोनिक सपोर्ट की आवश्यकता है तो ngx-translate का उपयोग करें।
• मॉड्यूलर अनुवाद की आवश्यकता वाले SSR या बड़े एप्लिकेशन के लिए Transloco का उपयोग करें।
• यदि आप कई प्लेटफार्मों पर i18next के साथ संरेखण चाहते हैं तो angular-i18next का उपयोग करें।

💡 यदि रनटाइम स्विचिंग की आवश्यकता नहीं है और आप न्यूनतम क्लाइंट लॉजिक पसंद करते हैं, तो एंगुलर का अंतर्निहित i18n बेहतर विकल्प बना रहता है।

कोड में बदलाव किए बिना एंगुलर ऐप्स का अनुवाद करना

Angular की अंतर्निहित i18n और रनटाइम लाइब्रेरी के अलावा एक तीसरा विकल्प भी है: बाहरी वेबसाइट अनुवाद उपकरण। ये उपकरण Angular ऐप के बाहर स्थित होते हैं और कोडबेस के अंदर मौजूद स्ट्रिंग्स के बजाय रेंडर किए गए आउटपुट का अनुवाद करते हैं।

के रूप में उल्लेख, Weglot यह रिवर्स प्रॉक्सी मॉडल का उपयोग करता है। यह सर्वर और ब्राउज़र के बीच स्थित होता है, HTML प्रतिक्रिया का पता लगाता है, और फिर आगंतुकों को अनुवादित संस्करण प्रदान करता है। इसका मतलब है कि आपको स्ट्रिंग्स को i18n से चिह्नित करने, JSON अनुवाद फ़ाइलों को प्रबंधित करने या प्रत्येक स्थान के लिए ऐप को पुनः निर्मित करने की आवश्यकता नहीं है। सेटअप तेज़ है क्योंकि अनुवाद परत को एंगुलर के बाहर संभाला जाता है।

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

भाषा बदलने का अनुभव भी अधिक सहज हो सकता है। Weglot यह जावास्क्रिप्ट-आधारित स्विचर का समर्थन करता है जो एंगुलर को पूरी तरह से रीबिल्ड किए बिना ही दिखाई देने वाली भाषा को अपडेट कर देता है। इससे बहुभाषी सामग्री को तेजी से लॉन्च करना आसान हो जाता है।

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

SEO सेटअप पर भी निर्भर करता है। रिवर्स प्रॉक्सी अनुवाद इंडेक्स करने योग्य अनुवादित पृष्ठों का समर्थन कर सकता है, लेकिन एक साधारण जावास्क्रिप्ट snippet केवल स्थानीयकृत यूआरएल बनाने से एसईओ-अनुकूल यूआरएल नहीं बनते। यह तब महत्वपूर्ण है जब लक्ष्य का एक हिस्सा ऑर्गेनिक सर्च ट्रैफिक हो।

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

सही एंगुलर i18n दृष्टिकोण का चयन करना

एंगुलर के अंतर्राष्ट्रीयकरण के लिए सही दृष्टिकोण इस बात पर निर्भर करता है कि आपका ऐप व्यवहार में भाषाओं को कैसे संभालता है।

बिल्ड-टाइम i18n प्रदर्शन और स्थिरता को प्राथमिकता देता है, जबकि रनटाइम लाइब्रेरी यूआई के भीतर लचीलेपन पर ध्यान केंद्रित करती हैं। बाहरी उपकरण अधिकांश कार्यान्वयन कार्य को हटा देते हैं लेकिन नियंत्रण को कोडबेस से बाहर स्थानांतरित कर देते हैं।

चुनना @angular/localize जब रनटाइम परफॉर्मेंस बेहद महत्वपूर्ण हो और आपकी टीम CI में अलग-अलग स्थानीयकृत बिल्ड को मैनेज करने में सहज हो। यह तब सबसे उपयुक्त होता है जब भाषा बदलना ऐप के अंदर नहीं बल्कि नेविगेशन के माध्यम से हो सके।

जब उपयोगकर्ताओं को बिना रीलोड किए भाषा बदलने की आवश्यकता हो और आप एक व्यापक रूप से उपयोग किया जाने वाला रनटाइम विकल्प चाहते हों, तो ngx-translate चुनें। यह Ionic प्रोजेक्ट्स और छोटे Angular ऐप्स के लिए सबसे उपयुक्त है।

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

चुनना Weglot जब लक्ष्य Angular कोडबेस में अनुवाद लॉजिक जोड़े बिना एक बहुभाषी वेबसाइट बनाना हो, तो यह उपयुक्त है। यह कंटेंट डिलीवरी और तेजी से रोलआउट के लिए सबसे अच्छा है, उन ऐप्स के लिए नहीं जहां TypeScript के व्यवहार को भाषा के अनुसार बदलने की आवश्यकता होती है।

{{demo-banner}}