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

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

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

@ jlutz777 वे 2 वैध उपयोग के मामले हैं, इस विषय पर हाल ही में आंतरिक रूप से चर्चा की गई है और मैं इसके लिए भी वकालत कर रहा हूं। यह आसानी से संभव नहीं है, यह देखते हुए कि i18n और AoT कोणीय में कैसे काम करते हैं, लेकिन यह भविष्य में हो सकता है जब हम v5 में AoT के लिए नई संकलन प्रक्रिया प्राप्त करेंगे।
मैं इसे एक बार रोडमैप में जोड़ दूंगा/यदि हमारे पास इसके बारे में कुछ आधिकारिक और ठोस है।

मैं इलेक्ट्रॉन + कोणीय 2 ऐप पर काम कर रहा हूं और अब कोणीय के साथ i18n सुविधा का उपयोग करके एकाधिक लैंगेज के लिए स्थानीयकरण के लिए समर्थन जोड़ने की कोशिश कर रहा हूं। वास्तव में टेम्प्लेट-स्ट्रिंग का निष्कर्षण और उन्हें विभिन्न भाषा फ़ाइल स्वरूपों में परिवर्तित करना स्पष्ट रूप से प्रलेखित है, हालांकि मैं अभी भी इसके बारे में बहुत कुछ स्पष्ट नहीं कर पा रहा हूं और इसकी तलाश कर रहा हूं:

• क्या मैं भाषा को गतिशील रूप से बदल सकता हूँ? या क्या मुझे अलग-अलग भाषा के लिए अलग से एप्लिकेशन बनाने की आवश्यकता है।
• क्या मैं सभी स्ट्रिंग्स को एक ही स्थान पर (कुंजी/मूल्य जोड़ी के रूप में) प्रबंधित/समेकित कर सकता हूं, ताकि मैं बदल सकूं
  एक स्थान पर स्ट्रिंग को कई स्थानों पर प्रभावित किया जाना है?
• क्या मैं विशिष्ट भाषा स्ट्रिंग प्राप्त करने के लिए टेम्पलेट के अलावा कहीं से भी स्थानीयकृत फ़ाइल तक पहुंच सकता हूं
  कुंजी प्रदान की? (जैसा कि मैंने ऊपर पूछा था)।

अंक 2 और 3 को "टेम्पलेट के बाहर अनुवाद स्ट्रिंग का उपयोग करें - #11405" सुविधा के साथ हल किया जाएगा।
बिंदु 1 के लिए मैंने ऊपर दिए गए @ jlutz777 को उत्तर देखें। अभी के लिए आपको अभी भी कई भाषाओं में ऐप बनाना है, या JIT का उपयोग करना है जो बूटस्ट्रैप पर अनुवादों को गतिशील रूप से लोड कर सकता है (यह रनटाइम पर स्विच नहीं कर रहा है, लेकिन यह अभी भी x बार बंडल करने से बेहतर है)।

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

@figuerres यह कुछ ऐसा है जो भविष्य में बदल जाएगा, अभी तक कोई वादा नहीं किया गया है लेकिन हम इस मुद्दे से अवगत हैं और हम संभावित समाधान देख रहे हैं, बाहरी फ़ाइल का उपयोग करना उनमें से एक है

हाय @ocombe - ऐसा लगता है कि हम शायद अपने आवेदन के लिए कोणीय में i18n का उपयोग करने जा रहे हैं। क्या दस्तावेज़ों में ऐसी कोई विशेषताएं हैं जो आपको लगता है कि आने वाले महीनों में बहिष्कृत हो सकती हैं या उनमें महत्वपूर्ण परिवर्तन हो सकते हैं? किसी भी प्रकार की जानकारी का हार्दिक स्वागत है। और डीवीडी के लिए फिर से धन्यवाद!

अरे @rjsteinert! यह जानकर ख़ुशी हुई कि!
अभी के लिए केवल एक ब्रेकिंग बदलाव की योजना है, वह है आईडी का ऑटो जेनरेशन। विधि बदल जाएगी और आईडी अब मेल नहीं खाएंगे, लेकिन आपकी अनुवाद फ़ाइलों को अपडेट करने के लिए एक क्ली माइग्रेशन टूल होगा (और एक पैरामीटर जिसका उपयोग आप केवल तैयार होने पर माइग्रेट करने के लिए कर सकते हैं)।

मैंने आज इस विषय के बारे में बहुत कुछ किया है और मैं सोच रहा हूं कि क्या कोई "सरल" समाधान हो सकता है जैसे कि अनुवाद के बजाय किसी सेवा के लिए i18n-टैग को कॉल के साथ बदलना?

वर्तमान:
<span i18n>Hello world</span> => <span>Hello world</span> . में रेंडर किया गया

मेरा विचार:
<span i18n>Hello world</span> => <span>{{i18nservice.translate('pass-in-the-generated-message-id')}}</span> . में रेंडर किया गया

इस तरह वास्तविक अनुवाद एओटी में गतिशील रूप से किया जा सकता है क्योंकि सेवा एपीआई, फ़ाइल इत्यादि से भरी जा सकती है और यहां तक ​​​​कि स्थानीय स्विचिंग भी एक नया स्रोत लोड करने के साथ i18nservice.setLocale('de-DE') से अधिक नहीं होगी।
xi18n-tool के साथ पाठ निष्कर्षण अभी भी पहले की तरह काम करेगा और हम अनुवाद सेवा के लिए अनुक्रमणिका के रूप में उपयोग करने के लिए किसी भी तरह से उत्पन्न संदेश आईडी का लाभ उठा सकते हैं।
वर्तमान कार्यान्वयन अभी भी त्रुटिपूर्ण रूप से काम करेगा क्योंकि एनजीसी केवल "--use-i18nservice" ध्वज की तलाश कर सकता है और अन्यथा अब तक संकलित कर सकता है।

एक समस्या जिसे मैं वर्तमान में पहचान सकता हूं वह है प्रत्येक घटक में i18nservice का इंजेक्शन क्योंकि इसे कॉल करने योग्य होने के लिए घटकों के संदर्भ में मौजूद होना चाहिए, लेकिन यह एक या दूसरे तरीके से हल करने योग्य होना चाहिए।

इस पर कोई विचार?

यह उन चीजों में से एक है जिन पर हम विचार कर रहे हैं हां, अभी भी समस्या है कि उन अनुवादों के अंदर कोड ब्लॉक का इलाज कैसे किया जाए जब कंपाइलर रनटाइम (एओटी) पर उपलब्ध न हो। इसका मतलब यह होगा कि हम अनुवाद के अंदर कोणीय घटकों/निर्देशों/पाइपों का उपयोग नहीं कर सकते हैं...

हाँ, ऐसा नहीं सोचा था।
मैं वर्तमान में एक पीओसी/वर्कअराउंड विकसित कर रहा हूं जो एचटीएमएल में सभी अनुवादों को बिल्ड चरण (वेबपैक) पर रेखांकित करता है, उन्हें एनजी-कंटेनरों में एनजी-स्विच के साथ लपेटता है।
I18n-विशेषताओं के लिए यह उन्हें मूल तत्व पर सेट करने वाले निर्देश का उपयोग कर रहा है।
उन सभी <x id=".. "/> प्लेसहोल्डर्स को बदलने के लिए अनुवाद स्वयं भी "रेंडर" हो जाते हैं।

यह बदसूरत है लेकिन काम करता है ... एनजी को मूल रूप से इसका समर्थन करने के लिए इंतजार नहीं कर सकता।
इस सप्ताह के अंत में पीओसी प्रकाशित करेंगे, हो सकता है कि यह आपके आगे के गर्भाधान के लिए उपयोगी हो।

मैं एक "समाधान" के साथ आया जो कार्यान्वयन होने तक मेरी आवश्यकताओं के अनुरूप है।
प्री-लोडर अब कंपाइलर को सौंपने से पहले सभी स्थानों के लिए HTML प्रस्तुत करता है, अब तक एक आकर्षण की तरह काम करता है।

रेपो: https://github.com/actra-development-oss/ng-i18n-aot-loader
एनपीएम: https://www.npmjs.com/package/@actra-development-oss/ng -i18n-aot-loader

संभवतः एक घटक में एक विशेषता हो सकती है जो सिस्टम/कंपाइलर को बताती है कि उसे एक सेवा की आवश्यकता है।
वह सेवा तब आईडी और लोकेल लेती है और स्थानीयकृत टेक्स्ट/मार्कअप लौटाती है।
सभी स्थानीयकृत पाठ सर्वर पर उन संसाधनों के रूप में संग्रहीत किए जाते हैं जिनसे सेवा पढ़ सकती है।

यदि किसी घटक में कोई लोकेल रन-टाइम विशेषता नहीं है।
यदि घटक के पास है तो यह रन-टाइम पर स्थानीयकृत डेटा प्राप्त करता है।
कंपाइलर सिर्फ डेटा फाइल बनाता है और सर्विस को हुक करता है।

यह मुझे अधिकांश अनुप्रयोगों के लिए सबसे आम आवश्यकता को संभालने का एक अच्छा तरीका लगता है और एक ही ऐप की कई प्रतियां बनाने और बनाए रखने के लिए साइटों की आवश्यकता नहीं होती है।

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

आईएमएचओ एक वैध समाधान हो सकता है जिस तरह से मैंने पीओसी के रूप में कार्यान्वित किया (उपरोक्त टिप्पणी देखें) संकलन समय पर अनुवादों को इनलाइन करने के लिए, बस एक और अधिक सुरुचिपूर्ण, एकीकृत तरीके से।
ऊपर वर्णित दोनों समस्याओं को समाप्त कर दिया जाएगा, केवल नीचे की ओर मैं कल्पना कर सकता हूं कि संभवतः बंडल आकार है, यह "सादा बंडल" + (अनुवादित एचटीएमएल-आकार * लोकेशंस) तक बढ़ेगा।
इसे पूरे दस्तावेज़ के बजाय i18n -टैग किए गए html में केवल ng-switch से कम किया जा सकता है लेकिन फिर भी i18n-* -tags के लिए एक समस्या है।

खैर यहाँ बात है; कभी-कभी आपकी सीमाएँ होती हैं ....

एक व्यावहारिक दृष्टिकोण से ऐसा न होना बेहतर हो सकता है, आपके पास पाठ का एक हिस्सा हो सकता है जिसे कई भाषाओं में दिया जा सकता है। काहानि का अंत।

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

इसे सरल रखें, पहले इसे सभी उपयोगकर्ताओं के 95% के लिए काम करें, फिर किनारे के मामलों का पता लगाएं।

मुझे नहीं लगता कि एक किनारे के मामले के रूप में, यह हमेशा की तरह व्यवसाय है।
कोणीय एक व्यवसाय-श्रेणी का ढांचा है, यदि सभी नहीं, तो i18n-उपयोगकर्ताओं को बाइंडिंग की आवश्यकता होगी, या कम से कम बहुवचन और पाठ के अंदर का चयन करना होगा।

<span i18n>Hello, {user.gender, select, m {Mr.}, f {Ms.}} {{user.name}}</span>
आप इसे अलग तारों के साथ कैसे हल करेंगे?
सरल उत्तर: आप नहीं कर सकते, क्योंकि आप लक्ष्य भाषा के नियमों को नहीं जान सकते हैं, हर भाषा 'ग्रीटिंग', 'लिंग', 'नाम' प्रारूप का पालन नहीं करती है।

उन विखंडू को अलग करना होगा:

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

कोर i18n अपेक्षित रूप से कोणीय में काम करता है और व्यवसाय-ग्रेड ऐप्स के लिए प्रयोग योग्य है, केवल एक चीज जो स्पष्ट रूप से गायब है वह है एओटी-संगतता, इसलिए मुझे आपका दृष्टिकोण नहीं मिलता है कि एक शक्तिशाली, कार्य प्रणाली को किसी ऐसी चीज से क्यों बदला जाना चाहिए जो आधा सक्षम न हो इसे पूरा करने के लिए कई बार काम करना पड़ता है।

इस समस्या का समाधान निकालने के लिए कल हमारी बैठक है।

@ocombe यह सुनकर खुशी हुई, मुझे आशा है कि इससे भविष्य में एंगुलर के रिलीज के लिए कुछ अच्छी चीजें मिलती हैं, यहां काम पर हम वास्तव में प्यार कर रहे हैं कि यह हमारी विकास आवश्यकताओं के लिए कैसे काम करता है!

@ocombe , क्या पूरे दस्तावेज़ को पुनः लोड किए बिना भाषा बदलना संभव है? मैंने समझाया :
मैं "के बारे में" नामक पृष्ठ पर हूं, लेकिन जब मैं भाषा बदलता हूं, तो मुझे अपने आवेदन के मुख्य प्रवेश पृष्ठ पर पुनः निर्देशित किया जाता है।

अपने i18n-ऐप पर काम करते समय मुझे ज्ञात "बग" भी आया कि बाहरी स्टाइलशीट जैसे @ कोणीय/सामग्री (नोड_मॉड्यूल्स में रहने वाले) को हल नहीं किया जा सका और इस प्रकार ng-xi18n -टूल विफल हो गया।
मैंने निष्कर्षण उपकरण के लिए "लापता फाइलों को अनदेखा करें" -होस्टकॉन्टेक्स्ट लागू किया, पीओसी के रूप में भी, लेकिन इसे मुख्य रेपो से जोड़ने के लिए पीआर # 17845 के रूप में जोड़ा गया।

@ocombe जैसा कि आप इस विषय पर बहुत सक्रिय प्रतीत होते हैं, क्या आप पीआर पर एक नज़र डालने और प्रतिक्रिया देने पर ध्यान देंगे?

धन्यवाद, मैं इसे देख लूंगा।

डायनेमिक डेटा सहित पूरी परियोजना पर आंतरिककरण को लागू करने का तरीका खोजते हुए कुछ दिन हो गए हैं, लेकिन कुछ भी ठोस नहीं मिला। क्या आप कृपया मुझे कुछ और सुझा सकते हैं जो कम से कम कुछ समय के लिए मेरी मदद करें। धन्यवाद।

हैलो @ocombe! क्या हमारे पास @ jlutz777 द्वारा उठाए गए बिंदु के बारे में अनुवर्ती कार्रवाई हो सकती है (गतिशील बाइंडिंग के बारे में, इस प्रकार प्रति भाषा एक ऐप नहीं है)?

आपके काम के लिए बहुत बहुत धन्यवाद!

@vicb अभी इस पर काम कर रहा है, यह 5.x में होगा (5.0 नहीं लेकिन सबसे अधिक संभावना 5.1)

@ocombe क्या चेकलिस्ट को अपडेट किया जाना चाहिए? मैं देख सकता हूं कि उनमें से कुछ पहले से ही नए संस्करणों में विलय हो चुके हैं। और यह आपकी मेहनत को बेहतर ढंग से प्रदर्शित करेगा। मैं

हाँ, अच्छा विचार, मैं इसे अपडेट कर दूंगा
संपादित करें: अपडेट किया गया

रनटाइम i18n (एओटी के साथ सभी स्थानों के लिए एक बंडल) - [इस पर काम करना]

संबंधित मुद्दा/पीआर/चर्चा कहां है?

नामित दिनांक स्वरूपों (जैसे ultraLongDate ) को विस्तारित करने के लिए एक एपीआई होना अच्छा होगा, इसलिए मूल तिथि पाइप को इसके बारे में पता होगा और कस्टम दिनांक पाइप की आवश्यकता नहीं होगी।

बस "रनटाइम i18n (एओटी के साथ सभी स्थानों के लिए एक बंडल)" पर प्रगति के बारे में उत्सुक।

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

मैं जो उम्मीद कर रहा हूं वह है:

1. रनटाइम i18n . पर कुछ रफ ईटीए
2. पुष्टि है कि रनटाइम i18n सभी भाषाओं के लिए सिंगल बिल्ड करेगा
3. उत्पादित प्रत्येक भाषा आलसी लोड करने योग्य होगी या एक विशाल बंडल में होगी

@chcaru "मूल" समाधान प्रदान करने के लिए एनजी की प्रतीक्षा करते हुए https://github.com/actra-Develop-oss/ng-i18n-aot-loader/ पर एक नज़र डालें
यह वही प्रदान करता है जो आप मांग रहे हैं, एक एओटी एकाधिक लोकेशंस के साथ निर्मित होता है।

@चकारू :
1/रफ ईटीए कोणीय v6 है (पहला बीटा जनवरी के अंत तक होना चाहिए, मुझे विश्वास है? सुनिश्चित नहीं है), अच्छी खबर यह है कि कोड अनुवादों को रनटाइम अनुवादों के बाद जल्दी से पालन करना चाहिए क्योंकि लगभग सभी काम हो जाएंगे
2/हाँ
3/अनुवादों को बंडल से अलग किया जाना चाहिए, आप बूटस्ट्रैप से पहले अपनी ज़रूरत के अनुसार आलसी लोड करने में सक्षम होंगे, या बस सब कुछ एक में बंडल कर सकते हैं, हम मॉड्यूल के लिए आलसी लोडिंग अनुवादों का भी समर्थन करना चाहते हैं, लेकिन यह सुनिश्चित नहीं है कि यह कब होगा उपलब्ध रहना

@ocombe जब तक angularv6 जारी नहीं किया जाता है, अनुवाद को गतिशील रूप से लोड करने और/या एकल पैकेज के साथ बहु-भाषा एप्लिकेशन बनाने का सबसे गंभीर विकल्प ngx-translate है।

क्या आपके पास ngx-translate का उपयोग शुरू करने में लोगों की मदद करने के लिए कुछ सुझाव हैं ताकि angularv6 के बाहर होने पर आसानी से माइग्रेट किया जा सके?
दोनों अनुप्रयोगों के बीच कोई पुल?

वास्तव में नहीं, कोड काफी अलग है... अगर मैं माइग्रेशन टूल पर काम करने के लिए प्रेरित होता हूं तो हम देखेंगे कि v6 उन सुविधाओं के साथ कब आता है

नमस्ते, आगामी सुविधाओं की पारदर्शिता के लिए धन्यवाद।

निम्नलिखित प्रश्नों के उत्तर जानना बहुत उपयोगी होगा:

1. कोई विचार है कि नया i18n वर्कफ़्लो https://angular.io/guide/i18n में वर्णित वर्तमान वर्कफ़्लो से कितना अलग होगा?

2. क्या i18n और i18n-* उदाहरण के लिए i18n-शीर्षक विशेषता वैकल्पिक कस्टम आईडी के साथ अभी भी टेम्प्लेट में उपलब्ध होगी?

3. क्या निम्न आदेश अभी भी काम करेंगे?

ng serve --aot --locale fr

ng xi18n  --i18nFormat=xlf
ng xi18n  --i18nFormat=xlf2
ng xi18n  --i18nFormat=xmb

1. टेम्प्लेट से निकाले गए Messages.xlf ट्रांस-इकाइयों को कोड में उपयोग किए गए लोगों के साथ कैसे मिला दिया जाएगा?

1. हम अपडेट के अनुभव को यथासंभव सुगम बनाएंगे, सबसे अधिक संभावना है कि पहले जो काम किया था वह कम से कम v7 तक काम करेगा।
2. i18n विशेषताएँ वही रहेंगी
3. निष्कर्षण भी समान होना चाहिए
4. शायद यही एकमात्र हिस्सा है जो बदलेगा, मुझे यकीन नहीं है कि अभी तक मैं आपको ऐसी चीजें नहीं बताना पसंद करता हूं जो बदल सकती हैं, लेकिन जब विचार बनाए जाते हैं तो संदेशों को रनटाइम पर विलय कर दिया जाएगा (इसलिए बूटस्ट्रैप और दृश्य के बीच दिखाई दे रहा है स्क्रीन)

@Toub की टिप्पणी के बाद, इस संक्रमण अवधि के लिए, हम निम्नलिखित दृष्टिकोण (i18n विशेषता और ngx-translate को मिलाकर) के लिए फीडबैक प्राप्त करने में रुचि रखते हैं, जिसे हम लागू करना चाहते हैं। जब नया i18n समर्थन तैयार होगा, तो हमारा उद्देश्य कोड में करने के लिए अधिक अपडेट को कम करना है।

(ध्यान दें कि हम डायनामिक लोकेशंस चाहते हैं, यानी प्रति लोकेल एक जेनरेट किया गया ऐप नहीं)

• हम i18n विशेषता का उपयोग करेंगे ताकि हम कोणीय चिमटा उपकरण का लाभ उठा सकें।
• निकाले गए टूल के आधार पर, हम xliff फ़ाइलों (या अन्य प्रारूपों के साथ) को उन प्रारूपों वाली सामग्री में बदल सकते हैं जिनका उपयोग ngx-translate (json या po) द्वारा किया जा सकता है।
• हम अनुवाद लागू करने के लिए i18n एक का उपयोग करने वाले तत्वों पर translate विशेषता का लाभ उठाएंगे (पहले निकाले गए)

यहाँ एक नमूना है:

<!-- Without parameters -->
<div i18n="hello-id" translate>HELLO</div>

<!-- With parameters -->
<div i18n="hello-id" translate [translateParams]="{value: 'world'}">HELLO</div>

आपकी प्रतिक्रियाओं के लिए धन्यवाद!

क्या आप उसके लिए ngx-translate पर कोई समस्या खोल सकते हैं? मुझे लगता है कि "अनुवाद" के विकल्प के रूप में "i18n" विशेषताओं का समर्थन करने के लिए शायद सबसे अच्छी बात lib को अपडेट करना होगा

@ocombe सुझाव के लिए धन्यवाद! एनजीएक्स-ट्रांसलेट पर इसके लिए अभी एक मुद्दा जोड़ा गया है ...

@ocombe समस्या मैं देख सकता हूँ कि i18n / i18n-* विशेषताएँ रनटाइम पर हटा दी जाती हैं (https://github.com/angular/angular/issues/11042)। क्या उन्हें रखने का कोई तरीका है?

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

@ocombe मैं समझता हूं लेकिन मैं अनुवादों को लोड नहीं करता क्योंकि मैं कोणीय सीएलआई का उपयोग कर रहा हूं और ng serve के साथ आवेदन शुरू किया है ...

@ocombe , हमारी कंपनी जल्द ही i18n का समर्थन करने के प्रयास से पहले प्रति लोकेल रणनीति के अनुसार कई ऐप का उपयोग करेगी जो वर्तमान में निर्धारित है। हम यूआरएल में लोकेल को शामिल करने और ऐप में बेस href सेट करने की भी योजना बना रहे हैं। एक बार रनटाइम i18n सुविधा पूर्ण हो जाने के बाद, हमें अपनी url लोकेल रणनीति के साथ क्या परिवर्तन करने की आवश्यकता होगी? क्या रनटाइम i18n जारी होने के बाद बड़े रिफ्लेक्टर से बचने का कोई बेहतर तरीका है? इस सब पर आपके काम के लिए धन्यवाद।

️ कहना चाहिए "जल्द ही शुरू होगा"

एक ऐप/लोकेल अभी भी काम कर रहा है क्योंकि यह अभी है (यदि आप क्ली का उपयोग नहीं कर रहे हैं तो बूटस्ट्रैप पर लोकेल फ़ाइल लोड करने के लिए छोटा परिवर्तन घटाएं)

क्या कोई मुझे लक्षित कर सकता है जिसमें i18n विशेषताएँ टेम्पलेट डर्निंग बंडल से हटाई गई हैं?

सीसी @ocombe

इसे 4.2.6 (PR https://github.com/angular/angular/issues/17999) में बदल दिया गया था।

नमस्ते! मैं लंबे समय से इस सूत्र का अनुसरण कर रहा हूं। मैंने देखा कि v6 के लिए पहला बीटा आउट हो गया है। मैंने चैंज पढ़ा लेकिन इस लंबे समय से चले आ रहे मुद्दे से संबंधित कुछ भी नहीं देखा। इस मोर्चे पर कोई खबर? या कम से कम, क्या कोई गारंटी है कि इंटरफ़ेस आपके पॉलीफ़िल के समान होगा?

आपके काम के लिए धन्यवाद!

यह अंतिम बीटा में से एक में होने जा रहा है, या शायद आरसी (मुझे पता है कि मुझे पता है ...)
इंटरफ़ेस बंद होने से goog.getMsg के समान होगा क्योंकि कोड अनुवाद के लिए Google आंतरिक रूप से यही उपयोग करता है: https://developer.pubref.org/static/apidoc/global/closure/goog/getMsg.html
लेकिन हम एक रैपर का उपयोग कर रहे हैं, इसलिए हो सकता है कि यह एंगुलर के लिए इंटरफ़ेस को बदल दे, अभी तक निश्चित नहीं है।
अपने पॉलीफिल में मैं एक समान इंटरफ़ेस का उपयोग करता हूं, लेकिन यदि आवश्यक हो तो आईडी, विवरण और अर्थ को परिभाषित करने की संभावना के साथ, और मेरा मानना ​​​​है कि हमें एक या दूसरे तरीके की आवश्यकता होगी (या तो मापदंडों के माध्यम से, या एक डेकोरेटर के माध्यम से)

आपके कड़ी मेहनत के लिए धन्यवाद! हम अप्रैल से शुरू होने वाले अपने संपूर्ण 1.x ऐप को फिर से लिखने की तैयारी कर रहे हैं। क्या इन परिवर्तनों की तैयारी के लिए हमें कुछ करना चाहिए/करना चाहिए? अभी हम 6.x का उपयोग करने की योजना बना रहे हैं। एक बार फिर धन्यवाद!

@ocombe बस उत्सुक है जब "अग्रणी और पिछली जगहों को अनदेखा करें" उतरेगा?

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

@ocombe हाँ यह बहुत अच्छा होगा। हम भी रनटाइम i18n में बहुत रुचि रखते हैं, क्योंकि यह हमारे लिए एकमात्र अवरोध बिंदु है। क्या आप इसके पूरा होने का अनुमान % में दे सकते हैं?

आपकी कड़ी मेहनत के लिए बहुत-बहुत धन्यवाद!

@ocombe

विशेष रूप से यह सुविधा स्पष्ट रूप से प्राथमिकता नहीं है, यह उम्मीद न करें कि हम जल्द ही इस पर काम करेंगे

क्या आप स्पष्ट कर सकते हैं कि आप यहाँ किस विशेषता की बात कर रहे हैं? मैं कोई धारणा नहीं बनाना चाहता।

@ofuangka सुविधा "अग्रणी और पिछली जगहों को अनदेखा करें" प्राथमिकता नहीं है।
@Karamuto अभी अनुमान लगाना मुश्किल है, हम अभी इस पर काम कर रहे हैं

@ocombe
क्या आप कृपया रनटाइम i18n के बारे में अपना मील का पत्थर साझा कर सकते हैं (एओटी के साथ सभी स्थानों के लिए एक बंडल)

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

इसके अलावा, हम xlf फ़ाइलों (प्रति मॉड्यूल एक फ़ाइल) को विभाजित करने में सक्षम होना चाहते हैं, क्या यह संभव है?

ऊपर ऊपर
क्या एंगुलर 6 में रनटाइम i18n जारी किया जाएगा?

धन्यवाद और खुश कोडिंग!

यहाँ उम्मीद खो दी है, कि यह समय पर समाप्त हो जाएगा, क्योंकि अधिक समय नहीं बचा है और इस सुविधा के बारे में अभी तक कोई वास्तविकता नहीं थी।

संस्करण 7 का विमोचन हमारे लिए बहुत देर से होगा।

@करमुतो #22654
मुझे लगता है कि इसे v6 में रिलीज़ किया जाएगा, लेकिन उन्हें पहले आइवी को खत्म करना होगा।

हमारे पास इस सप्ताह काम करने वाली एक हैलो वर्ल्ड होनी चाहिए, लेकिन न्यूनतम सुविधाओं के साथ (उदाहरण के लिए कोई आईसीयू समर्थन नहीं)।
लेकिन चूंकि यह आईवी के साथ जारी किया गया है जो एक झंडे के पीछे है, हम इस पर काम करना जारी रखेंगे और जैसे ही हम एक नई सुविधा समाप्त करेंगे, v7 के लिए प्रतीक्षा करने की कोई आवश्यकता नहीं है

@ocombe
वह बहुत अच्छा लगता है! इसे शुरू से ही आईसीयू के साथ पूरा होने की जरूरत नहीं है। यदि यह v6 के बाद के संस्करणों में आगे बढ़ता है तो यह हमारे द्वारा पूरी तरह से ठीक है।

फिर से महान कार्य के लिए धन्यवाद!

@ करामुतो चुपके चोटी के लिए # 22654 देखें!

गूंगा प्रश्न: क्या कस्टम घटकों के लिए स्ट्रिंग आधारित इनपुट के लिए i18n निर्देश रखने का कोई तरीका है। एरिया-लेबल अग्रेषित करते समय एक उदाहरण:

मैं एक कस्टम बटन लपेटता हूं जो अच्छी चीजें करता है:

कस्टम बटन का टेम्प्लेट बस करता है:

क्या पहले से ही ऐसा करने का कोई तरीका है?

@kekraft मुझे लगता है कि स्थिर इनपुट के साथ आप i18n विशेषता सिंटैक्स का उपयोग कर सकते हैं:

<custom-button ariaLabel="your label" i18n-ariaLabel></custom-button>

घटक में:

<button [attr.aria-label]="ariaLabel">Some button</button>

@ocombe क्या आपको किसी रनटाइम i18n कार्य को पूरा करने के लिए योगदानकर्ताओं की आवश्यकता है?

हां ! v6 प्रकाशित ~~~
यहां कोई अपडेट?

उदाहरण i18n कोणीय 6 यहाँ है
https://github.com/angular/angular/pull/23660

@sandangel क्या आपका मतलब बस "सब कुछ" या "सब कुछ जो चेक किया गया है", इस धागे की शुरुआत में योजनाओं से?
वास्तव में एक ही आवेदन के लिए उत्सुक था, मुझे लगता है कि यह सबसे महत्वपूर्ण चीजों में से एक है। आपके द्वारा लिंक किए गए #23660 पर गए और फिर https://pr23660-e12f469.ngbuilds.io/guide/i18n पर पहुंचे
लेकिन वहाँ यह अभी भी कहता है:

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

क्या कई भाषाओं के लिए एक ही आवेदन करना संभव है या नहीं?

@MrCroft ऐसा लगता है कि रनटाइम i18n अभी भी प्रगति पर है। मैंने इसे आपके जैसे कुछ और विकल्प पढ़ा लेकिन सभी स्थानीयकरणों के लिए एक बंडल नहीं :(

हमारे पास एक कामकाजी हैलो वर्ल्ड है लेकिन यह केवल नए रेंडरर (आईवी) के लिए है और चूंकि आईवी प्राइम टाइम के लिए तैयार नहीं है, आपको दुर्भाग्य से इसके लिए इंतजार करना होगा :(

@ocombe इसलिए, जब तक हमारे पास उत्पादन में आइवी नहीं है (शायद v7 के आसपास) हमारे पास रनटाइम अनुवाद नहीं होंगे। क्या ये सही है?

@ocombe क्या हैलो वर्ल्ड और आइवी स्टफ सार्वजनिक रूप से उपलब्ध हैं? इस नए i18next कार्यान्वयन को समझने की कोशिश करना अच्छा होगा😃

@fetis https://github.com/actra-development-oss/ng-i18n-aot-loader/

@fetis हाँ :(
@feloy हाँ, सरल हैलो वर्ल्ड यहाँ है: https://github.com/angular/angular/tree/master/packages/core/test/bundling/hello_world_i18n लेकिन बहुत कम
आप यहां परीक्षण पा सकते हैं: https://github.com/angular/angular/blob/master/packages/compiler/test/render3/r3_view_compiler_i18n_spec.ts
और कुछ रिफैक्टरिंग + निष्कर्षण यहाँ: https://github.com/angular/angular/pull/22931

@ocombe हम अपने आवेदन में i18n को लागू करने की कोशिश कर रहे हैं, लेकिन जहां भी मैं इसके बारे में पढ़ता हूं, मैं देखता हूं कि हमें प्रति भाषा एक संदेश। xlf फ़ाइल की आवश्यकता है। क्या यह विभिन्न ग्राहक सामना करने वाली स्क्रीन आदि के साथ एक जटिल अनुप्रयोगों पर विचार करने के लिए ओवरहेड नहीं बन जाएगा .. मैं यह देखना चाहता हूं कि क्या हम प्रति घटक या प्रति मॉड्यूल संदेश फ़ाइल को तोड़ सकते हैं? क्या यह पहले से ही समर्थित है?

@ स्टिकलर-वी यह फ़ाइल यह आपके स्ट्रिंग्स के लिए आपके अनुवाद सॉफ़्टवेयर के लिए सिर्फ परिवहन है। इसे मैन्युअल रूप से अनुवाद करने पर विचार न करें।

मैं देखता हूं, हालांकि हमारे पास विभिन्न भाषाओं में वास्तविक पाठ कहां है? अनुवादकों द्वारा इसे करने के विपरीत हमें इस पाठ को मैन्युअल रूप से प्रबंधित करने की आवश्यकता है।

क्षमा करें, लेकिन मैं थोड़ा खो गया हूँ। यहां मूल दस्तावेज के आधार पर https://angular.io/guide/i18n। src/app/app.component.html में केवल अंग्रेज़ी टेक्स्ट होगा। Messages.fr.xlf वह फाइल है जिसमें फ्रेंच टेक्स्ट है लेकिन यह स्वतः उत्पन्न होता है और इसे छूने की सलाह नहीं दी जाती है।

अगर मैं अंग्रेजी के बजाय फ्रेंच टेक्स्ट का उपयोग करके app.component.html प्रस्तुत करना चाहता हूं, तो मैं फ्रेंच संदेश "बोनजोर" आदि कहां निर्दिष्ट करूंगा?

@ स्टिकलर-वी यह वास्तव में ऑफटॉपिक है, कृपया स्टैक ओवरफ्लो पर एक प्रश्न बनाएं। मुझे वहां जवाब देने में खुशी होगी।

क्या आप कृपया यहाँ इस पर चर्चा नहीं कर सकते, यह यहाँ का विषय नहीं है, धन्यवाद
आपके प्रश्न @ स्टिकलर-वी के लिए, प्रति मॉड्यूल/घटक एक फ़ाइल अभी संभव नहीं है, यह भविष्य में हो सकता है लेकिन यह उन चीजों की सूची में नहीं है जिन पर हम अभी काम कर रहे हैं

मार्ग अनुवाद का समर्थन करने की कोई योजना है?

क्षमा करें यदि इसका उत्तर पहले ही दिया जा चुका है, लेकिन क्या इस संस्करण के साथ JS में अनुवाद संभव है या यह अभी भी केवल-टेम्पलेट है?

@ santhony7 यह अभी भी संभव नहीं है क्योंकि आइवी तैयार नहीं है।

मेरे पास रनटाइम i18n की मंशा/कार्यक्षमता के बारे में एक प्रश्न है, यदि इसका मतलब है कि हम अनिवार्य रूप से रनटाइम पर भाषा का चयन करने में सक्षम होंगे और ऐप को फिर से लोड किए बिना इसे "फ्लिप" करेंगे जैसा कि पुराने ng-translate में कार्यक्षमता थी। AngularJS के लिए और ngx-translate में? या इसका मतलब पूरी तरह से कुछ और है?

नहीं, भाषा बदलने के लिए आपको ऐप को फिर से लोड करना होगा।

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

रनटाइम i18n के लाभ:

• भाषा क्लाइंट पक्ष का पता लगाएं, और अपनी इच्छित अनुवाद फ़ाइल को आलसी लोड करें
• क्योंकि कोड भाषा-स्वतंत्र है, आपको सभी भाषाओं के लिए एक बंडल मिलता है
• पुस्तकालय "i18n" संगत भी हो सकते हैं
• चूंकि हम रनटाइम पर अनुवाद लोड करते हैं, हमारे पास एक ऐसी सेवा प्रदान करने के लिए आवश्यक सब कुछ है जो आपके कोड में भी अनुवाद कर सकता है (न कि केवल टेम्प्लेट)
• हम प्रति मॉड्यूल अनुवादों को विभाजित कर सकते हैं (शायद पहले उपलब्ध नहीं)

नुकसान:

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

सैद्धांतिक रूप से आप पूरे ऐप को पुनः लोड किए बिना भाषा बदल सकते हैं, लेकिन आपको मौजूदा घटकों को फिर से बनाना होगा क्योंकि जब घटक बनाया जाता है तो टेम्पलेट उत्पन्न होते हैं, या आप सेवा को अपने टेम्पलेट में बाँध सकते हैं ( i18n का उपयोग करने के बजाय)

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

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

@ocombe स्पष्ट करने के लिए बहुत बहुत धन्यवाद! मैंने अपने आवेदन के भीतर वर्तमान कोणीय i18n लागू किया है और परिवर्तन/अज्ञात आवश्यकताओं के कारण एक रोड़ा मारा है। मैं वर्तमान अंतर को पाटने में मदद करने के लिए संयोजन के रूप में https://github.com/ngx-translate/i18n-polyfill लाइब्रेरी का भी उपयोग कर रहा हूं।

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

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

हमारे पास एक ही समय में कई भाषाओं में अनुवादित ऐप्स का समर्थन करने की कोई योजना नहीं है, भविष्य में यह संभव हो सकता है यदि हम अनुवाद/मॉड्यूल लोड कर सकते हैं, लेकिन यह आर्किटेक्चर का दुष्प्रभाव होगा, न कि कुछ ऐसा जो हम विशेष रूप से करते हैं हासिल करने की कोशिश की।

क्या आइवी + रनटाइम i18n के लिए कोई ईटीए है?
अगर ऐसा नहीं है तो मैं पूरी तरह से समझता हूं, लेकिन मुझे यह जानने की जरूरत है कि क्या (मेरे वर्तमान प्रोजेक्ट की समय सीमा को देखते हुए) मैं इसके लिए इंतजार कर सकता हूं या मौजूदा समाधान में से किसी एक का उपयोग शुरू करने की आवश्यकता है और भविष्य के संस्करण के लिए रनटाइम i18n में माइग्रेशन को स्थगित करना होगा। .

मैं एक सटीक समय सीमा देने की कोशिश नहीं करूंगा, हर बार जब मैंने कोशिश की तो यह गलत था: डी
यह अभी v7 ​​से पहले नहीं होगा (पहले बीटा के रूप में उपलब्ध होगा)

कोई बात नहीं, हम सभी जानते हैं कि कैसे अनुमान हमेशा गलत होते हैं। :डी
क्या आपको लगता है कि मौजूदा i18n (+ i18n-polyfill) से रनटाइम 18n या ngx-translate से माइग्रेट करना आसान होगा?

शायद वर्तमान i18n से, लेकिन मैं ngx-translate का एक संस्करण लिखूंगा जो कोणीय i18n के आंतरिक का उपयोग करता है, यदि यह संभव है (अभी तक निश्चित नहीं है)

नमस्ते, मैंने वर्तमान स्थिति को समझने के लिए इस सूत्र को पार करने का प्रयास किया है। क्या एनजीएक्स ट्रांसलेशन कोड वर्तमान में डायनेमिक लोकलाइज़ेशन वाले एकल ऐप के लिए सबसे व्यवहार्य "वर्कअराउंड" है?

नमस्ते, क्या ngx-translate/i18n-polyfill का उपयोग करके रन टाइम पर स्थानीयकरण बदलना संभव है?

@ सुचग रनटाइम पर नहीं। आप रनटाइम पर अनुवाद करने में सक्षम हैं लेकिन आप उपयोग किए गए लोकेल को नहीं बदल सकते हैं।

@mjschranz त्वरित उत्तर के लिए धन्यवाद
यहां तक ​​कि रन टाइम अनुवाद भी अभी के लिए ठीक है। क्या आप इसके लिए कोई उदाहरण साझा कर सकते हैं।
मैंने https://github.com/ngx-translate/i18n-polyfill पर साझा किए गए उदाहरण की कोशिश की, और क्रोम ब्राउज़र की भाषा में बदलाव किया लेकिन कोई भाग्य नहीं।
क्या अनुवाद के लिए कोई विशिष्ट तरीका है ??

कृपया, बाहरी पुस्तकालयों के बजाय कोणीय के बारे में चर्चा यहां रखें। यदि आपको इसके लिए किसी सहायता की आवश्यकता है, तो संदेशों को उनके जीथब रिपॉजिटरी पर पोस्ट करें

अरे, क्या भविष्य में यह सुविधा कैसी दिखेगी, इस पर कोई अन्य ट्रैकिंग समस्याएँ या डिज़ाइन दस्तावेज़ हैं? शायद हम कार्यान्वयन में मदद कर सकते हैं या यह सुनिश्चित करने के लिए खुद को तैयार कर सकते हैं कि v7 में संक्रमण जितना संभव हो उतना आसान होगा।

नमस्ते, मैं वर्तमान में कोणीय 5 चला रहा हूं और हमें अपनी परियोजना में बहु भाषा जोड़ने की जरूरत है।
मैंने एक समाधान जोड़ा है जो अब मेरे लिए काम करता है, जो लगभग सुरुचिपूर्ण है। https://github.com/angular/angular/issues/24549।

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

@mattiLeBlanc आप डायनामिक संदेशों को कैसे हल करते हैं, उदाहरण के लिए घटक या सेवाओं के संदेश?

@zverbeta कृपया मुझे एंगुलर कोर या इस चर्चा के संदर्भ को पूरी तरह से न समझने के लिए क्षमा करें। मैं इसे केवल शुरुआत के लिए अपने संदर्भ से प्राप्त कर सकता हूं।

आपके प्रश्न के उत्तर में, मैं यह मानूंगा कि हम केवल अनुवाद फ़ाइलों (xlf) को एक अच्छे तरीके से लोड करने में रुचि रखते हैं, एक लोकेल के आधार पर जिसे URL या भाषा क्वेरीपरम से निकाला जा सकता है। (स्थान क्या है यह तय करने के लिए मैं वर्तमान में एक यूआरएल मानचित्र का उपयोग करता हूं)।

जैसे हम मार्कअप को i18n से टैग करते हैं, वैसे ही किसी कंपोनेंट या सेवा के संदेश को टैग नहीं किया जाता है। मुझे Wordpress और PHP के लिए i18n के साथ कुछ अनुभव है। वहां हम सही अनुवाद प्राप्त करने के लिए __( 'text' to translate, 'text domain' ) दृष्टिकोण का उपयोग करते हैं। इस __() को सीएलआई कमांड द्वारा मैसेज फाइल बनाकर स्कैन भी किया जा सकता है।

क्या यह उन मुद्दों में से एक है जिसका आप जिक्र कर रहे हैं?

उदाहरण के लिए मार्कअप के इस ब्लॉक के साथ एक बात मैंने देखी (क्योंकि मैं आलसी था और प्रत्येक उपखंड पर i18n नहीं जोड़ना चाहता था):

<div class="eligibility-banner" i18n="@@eligbilityBanner" fxLayout="column" fxLayout.gt-xs="row" fxLayoutAlign.gt-xs="center center" fxLayoutAlign="center start">
        <div class="requirement-text" fxFlex="20">To be eligible, you:</div>

        <div fxLayout="column" fxFlex="80" fxLayout.gt-xs="row" fxLayoutAlign="center start">
          <div fxLayout="row" fxLayoutAlign="center center" class="requirement" fxFlex="33">
              <pro-svg icon="icon-check-circle" className="icon-check" width="44" height="44"></pro-svg>
              <div class="text">own an Australian business (with a valid ABN/ACN)</div>
          </div>
          <div fxLayout="row" fxLayoutAlign="center center" class="requirement" fxFlex="33">
              <pro-svg icon="icon-check-circle" className="icon-check" width="44" height="44"></pro-svg>
              <div class="text">are over 18 years old</div>
          </div>
          <div fxLayout="row" fxLayoutAlign="center center" class="requirement" fxFlex="33">
              <pro-svg icon="icon-check-circle" className="icon-check" width="44" height="44"></pro-svg>
              <div class="text">are an Australian Citizen or Permanent Resident</div>
          </div>
        </div>
      </div>

वह पूरे डिव ब्लॉक को मेरे संदेश में कॉपी करता है। xlf।
यह बहुत अधिक मार्कअप प्रदूषण है। (बेशक मैं टेक्स्ट रखने वाले प्रत्येक टैग पर i18n का उपयोग कर सकता हूं।)

इस उदाहरण के लिए, _e() कमांड का उपयोग करना बहुत अच्छा काम करेगा, मुझे लगता है। आप अपने टेक्स्ट को इको कमांड से रैप करेंगे और उन सभी रैप्ड टेक्स्ट को इकट्ठा कर लिया जाएगा। आप एक्सएमएल में उस मार्कअप कॉपी से छुटकारा पा सकते हैं।
यदि आपको उस स्ट्रिंग में कुछ गतिशील जोड़ने की आवश्यकता है, तो आप इसे स्ट्रिंग में प्लेस होल्डर के साथ पाइप कर सकते हैं (जैसे आप sprintf के साथ करेंगे। कुछ ऐसा

<p>{{ __( 'I would like a nice %s, please', fruit ) }}</p> 

जहां fruit एक वैरिएबल है जिसका मान __( 'apple') या __( 'pear) है।
पाठ के 3 टुकड़े एक्सएमएल में समाप्त हो जाएंगे और उनका अलग से अनुवाद किया जा सकता है।

क्या यह किसी काम का होगा? यह i18n विशेषता जोड़ने के समान ही है, मुझे फिर से पढ़ने के बाद एहसास हुआ :)

अंत में, कुछ प्रारूपों को देखते हुए। XLIFF 2 1.2 की तुलना में बहुत अच्छा, थोड़ा साफ दिखता है। एक्सएमबी भ्रमित करने वाला, भयानक दस्तावेज दिखता है जो ऐसा लगता है कि इसे 1995 में स्टाइल किया गया था।
XLIFF 2 का उपयोग करते समय मैंने नोटिस किया था कि TARGET टेक्स्ट को वैसे ही प्रस्तुत नहीं किया गया था जैसे यह संस्करण 1.2 में करता है।

क्या आप लोगों ने .pot और .mo फाइलों को देखा है? बहुत ही सरल प्रारूप और POEdit टूल के साथ अनुवादित द्वारा भी उपयोग किया जाता है।

मुझे टॉगल बटन का उपयोग करके अपने आवेदन को अंग्रेजी और स्पेनिश में बदलने की जरूरत है। क्या सभी परिवर्तन, कार्यशील फ़ाइल अलग से। मैंने .dist/en और dist/es के तहत दो बिल्ड बनाए हैं। क्या कोई मुझे बता सकता है कि तैनाती के लिए मुझे क्या करना है और दोनों बिल्ड के बीच कैसे स्विच करना है?

टॉगल बटन पर क्लिक करने पर मुझे क्या करना होगा

@shobhit12345 कृपया अपना सहायता अनुरोध https://stackoverflow.com पर पोस्ट करें

जब मैं --prod के साथ निर्माण करता हूं तो @zverbeta जिस समाधान को मैंने #24549 पर पोस्ट किया था वह काम नहीं करता। स्पष्ट है क्योंकि मैं require का उपयोग कर रहा हूं जो शायद उपलब्ध नहीं है?
--prod ध्वज के बिना समाधान काम करता है क्योंकि इसमें वेबपैक संबंधित कोड शामिल है?

@mattiLeBlanc मुझे यह lib https://github.com/ngx-translate/i18n-polyfill मिला और यह गतिशील पाठ के साथ मेरी समस्या का समाधान करता है

नमस्ते, हम i 18 n का उपयोग करके गतिशील मूल्यों (प्रक्षेपण) का अनुवाद कैसे कर सकते हैं।

    <source>This amount is for <x id="INTERPOLATION" equiv-text="{{policyName}}"/> policy #<x id="INTERPOLATION_1" equiv-text="{{policyGroupId}}"/></source>
    <target>Esta cantidad es para <x id="INTERPOLATION" equiv-text="{{**policyName**}}"/> política #<x id="INTERPOLATION_1" equiv-text="{{policyGroupId}}"/></target>

अरे! क्या कोई ऐसी जगह है जहां हम काम कर रहे कार्यों को ट्रैक कर सकते हैं और/या मदद कर सकते हैं? (इस पर काम करने वाले टैग)

रनटाइम i18n के बीटा संस्करण को जारी करने की समय सीमा पर कोई अपडेट?

@marcelnem मुझे टिप्पणी नहीं मिल रही है लेकिन iirc ocombe ने उल्लेख किया है कि रनटाइम i18n को आईवी के लिए विलय कर दिया गया है ताकि आप इसे वी 7 बीटा पर आईवी ध्वज के साथ परीक्षण कर सकें

रनटाइम भाग किया जाता है, लेकिन संकलक भाग नहीं, जिसका अर्थ है कि आप अभी तक आइवी के साथ इसका परीक्षण नहीं कर सकते हैं

नमस्ते, मैं कोणीय 6 i18n के साथ काम कर रहा हूँ। मैं बहु-भाषा के साथ काम कर रहा हूं, जिसका अर्थ है कि मैंने रसोई की किताब का पालन किया है:
https://v2.angular.io/docs/ts/latest/cookbook/i18n.html#!

मेरा वर्तमान कार्यान्वयन AOT का उपयोग कर रहा है, इसलिए मैंने एक message.xlf फ़ाइल और एक message.pt.xlf उत्पन्न किया। सब कुछ ठीक चल रहा है, जब मैं दौड़ता हूँ

एनजी सर्व --कॉन्फ़िगरेशन=पीटी

मुझे अपेक्षित के रूप में अनुवादित ग्रंथ मिलते हैं। लेकिन मुझे लगता है कि इसके काम करने के तरीके में कुछ गड़बड़ है। मुझे शायद कुछ याद आ रहा है। जहां तक ​​मुझे समझ में आया, हर बार जब मैं अनुवाद करने के लिए एक नई स्ट्रिंग जोड़ता हूं और इसे i18n विशेषता के साथ चिह्नित करता हूं, तो मुझे "ng xi18n" चलाने वाले संदेशों को फिर से उत्पन्न करने की आवश्यकता होती है और फिर मैन्युअल रूप से संदेशों को अपडेट करते हैं। pt.xlf। एक्सएलएफ फ़ाइल में लाइन नंबर भी होता है जहां स्रोत होता है, इसलिए ऐसा लगता है कि अगर मैं पंक्ति बदलता हूं, तो मुझे फ़ाइल को फिर से जेनरेट करने और मैन्युअल रूप से मेरी पीटी फ़ाइल को अपडेट करने की भी आवश्यकता होगी।

<context context-type="linenumber">16</context>

यह स्मार्ट नहीं लगता है, यह मुझे इसे काम करने के लिए बहुत अधिक अतिरिक्त काम देगा। क्या आप मेरी चिंता को समझते हैं? क्या मुझे कुछ याद नहीं आ रहा है?
मुझे पता है कि एंगुलर 7 i18n में आइवी के शामिल होने के साथ एक बड़ा अपडेट होगा, क्या मुझे इसके लिए इंतजार करना चाहिए?

सादर,
फैबियो

पीएस मैं वास्तव में आशा करता हूं कि यह विषय से हटकर नहीं है, लेकिन अगर आपको लगता है कि यह है, तो कृपया मुझे कम से कम एक दिशा दें। उदाहरण के लिए मुझे यह कहां पूछना चाहिए? या अगर कोई लिंक है जो मेरे संदेह का उत्तर दे सकता है।

@fabiopcarvalho एक बात मैंने महसूस की है कि प्रत्येक अनुवाद के लिए कस्टम आईडी का उपयोग करना बुद्धिमानी है ताकि HTML लेआउट में परिवर्तनों का ट्रैक रखना आसान हो सके।

लेकिन हाँ, आपको अनुवाद फ़ाइल को नियमित रूप से अपडेट करना होगा।

@fabiopcarvalho मैं अनुवादों को मर्ज करने में मेरी मदद करने के लिए xliffmerge का उपयोग करता हूं

बिल्कुल सही, मैंने उस टूल का इस्तेमाल किया और इसने बहुत अच्छा काम किया। मैं भी आईडी का उपयोग कर रहा हूँ और
वे मदद करते हैं।
उत्तर के लिए धन्यवाद !!

गुरुवार, 30 अगस्त, 2018 को, पेड्रो रोमेरो नोटिफिकेशन @github.com ने लिखा:

@fabiopcarvalho https://github.com/fabiopcarvalho मैं xliffmerge का उपयोग करता हूं
https://github.com/martinroob/ngx-i18n मर्ज करने में मेरी सहायता करने के लिए
अनुवादों का

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/angular/angular/issues/16477#issuecomment-417407822 ,
या थ्रेड को म्यूट करें
https://github.com/notifications/unsubscribe-auth/AWOWQ6vpjOb0Ntgpv7TUngRrBBsUIkVjks5uWCV7gaJpZM4NOSBk
.

अभिगम्यता के लिए विशेषताओं में ICU संदेशों की अनुमति देना महत्वपूर्ण है क्योंकि विशेषता aria-label का उपयोग अभिगम्यता में बहुत अधिक किया जाता है। क्या फॉलोअप के लिए कोई समस्या है?

मुझे नहीं लगता कि इसमें कोई समस्या है, क्या आप इसे खोल सकते हैं? मैं अभी आइवी के लिए आईसीयू एक्सप्रेशन पर काम कर रहा हूं, इसलिए मैंने एक TODO जोड़ा, लेकिन एक फीचर अनुरोध बेहतर होगा

@ocombe , https://github.com/angular/angular/issues/21615

बिल्कुल सही धन्यवाद (गीथब खोज वास्तव में खराब है!)!

क्या हम i18n के नए संस्करण के साथ HTTP के माध्यम से उदाहरण के लिए बाहरी स्रोत से अनुवाद फ़ाइलों को आलसी लोड करने में सक्षम होंगे?

@ocombe जैसा कि आपने कहा था कि आप रनटाइम i18n (एओटी के साथ सभी स्थानों के लिए एक बंडल) पर काम कर रहे हैं। एक साल से अधिक समय हो गया है जिसका हम इंतजार कर रहे हैं। जब हम उम्मीद कर सकते हैं कि यह सुविधा कोणीय 7 रिलीज में आ रही है?

@ Sef1995 यह उन चीजों में से एक है जिसे हम सक्षम करना चाहते हैं
@ अहमदशहीद को आईवी की आवश्यकता होगी जिसे वी 7 से स्वतंत्र रूप से रिलीज़ किया जाएगा और आईवी वी 7 की रिलीज के लिए तैयार नहीं होगा। आइवी के कुछ हिस्से पहले से ही एक झंडे के पीछे v6 में हैं, लेकिन यह फीचर पूर्ण नहीं है और आपको इसे वास्तविक दुनिया के एप्लिकेशन में उपयोग नहीं करना चाहिए। हमारे पास अभी तक आइवी के लिए रिलीज की तारीख नहीं है।

@ocombe एक त्वरित प्रश्न है, अगर हम आज (कोणीय 6) के रूप में i18n को लागू करते हैं, जिसके लिए अलग-अलग बिल्ड (प्रत्येक भाषा के लिए एक) की आवश्यकता होगी, क्या आइवी के बाहर होने और i18n रनटाइम के दौरान प्रयास खो गया है? मेरा मतलब है कि जिस तरह से i18n को अभी लागू किया जाएगा, वह आने वाले समय से अलग होगा? पहले से कुछ स्प्रिंट की योजना बनाने और काम को प्राथमिकता देने की कोशिश करना। धन्यवाद

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

@ocombe एक त्वरित प्रश्न है, अगर हम आज (कोणीय 6) के रूप में i18n को लागू करते हैं, जिसके लिए अलग-अलग बिल्ड (प्रत्येक भाषा के लिए एक) की आवश्यकता होगी, क्या आइवी के बाहर होने और i18n रनटाइम के दौरान प्रयास खो गया है? मेरा मतलब है कि जिस तरह से i18n को अभी लागू किया जाएगा, वह आने वाले समय से अलग होगा? पहले से कुछ स्प्रिंट की योजना बनाने और काम को प्राथमिकता देने की कोशिश करना। धन्यवाद

नमस्ते, आप एक बिल्ड के साथ वेबपैक को गतिशील रूप से (एक अस्थायी समाधान के रूप में) फाइलों में लोड करने की आवश्यकता का उपयोग कर सकते हैं:
उदाहरण यहां पाया जा सकता है: https://github.com/angular/angular/issues/24549#issuecomment -402013622

आपको --prod --aot=false के साथ निर्माण करना होगा, क्योंकि AOT=true वेबपैक सामग्री को हटा देगा।

@ocombe हाय,

A7 रिलीज़ उम्मीदवार बाहर है, जैसा कि वादा किया गया था कि क्या हम रनटाइम अनुवाद का परीक्षण करेंगे? Runtime i18n (one bundle for all locales with AOT) । मैं इसका परीक्षण कैसे कर सकता हूं। कृपया सहायता कीजिए

धन्यवाद

मैं @sheikalthaf से दूसरा सवाल करता हूं, हालांकि v7 पहले ही जारी किया जा चुका है।

@sheikalthaf @Shuyinsama जैसा कि ऊपर और पहले संदेश में कुछ टिप्पणियों के बारे में बताया गया है:
रनटाइम i18n के लिए ivy की आवश्यकता होती है जिसे v7 से स्वतंत्र रूप से रिलीज़ किया जाएगा। आइवी के कुछ हिस्से पहले से ही ध्वज के पीछे v7 में हैं, लेकिन यह पूर्ण नहीं है और आपको इसे वास्तविक दुनिया के अनुप्रयोग में उपयोग नहीं करना चाहिए। हमारे पास अभी तक आइवी के लिए रिलीज की तारीख नहीं है।

@ocombe : माता-पिता से बाल घटक तक गतिशील i18n कुंजी पास करने के बारे में क्या।

बाल घटक:
<div i18n="{{labelTextKey}}">{{labelText}}</div>

मूल घटक:
<app-input [labelText]="'Second name'" [labelTextKey]="'@<strong i="13">@LabelSecondName</strong>'" ..></app-input>

मैं इसे पास कर सकता हूं, लेकिन जैसा कि i18n अनुवाद निर्माण के समय होता है, चर उस स्थिति में अभी भी खाली है। तो, इसलिए कोई अनुवाद नहीं होता है।

ऐसे मामले के लिए कोई अपडेट?

@bobKasbi

आपको बाल घटक में i18n टैग की आवश्यकता नहीं है, आप इसे इस तरह माता-पिता में उपयोग कर सकते हैं:

<app-input i18n-labelText="@@LabelSecondName" labelText="Second name"></app-input>

@cjsase : बढ़िया काम कर रहा है। बहुत धन्यवाद! लगभग 2 दिनों से संघर्ष कर रहा था।

इसके आधार पर: https://github.com/angular/angular/issues/21706#issuecomment -430435254

• हमें v7 में आइवी की उम्मीद नहीं करनी चाहिए। v8 मार्च/अप्रैल 2019 के लिए योजनाबद्ध है। अगर हमें v7 में आइवी की उम्मीद नहीं करनी चाहिए, तो क्या अप्रैल 2019 में आइवी के जारी होने तक अंतर्राष्ट्रीयकरण (i18n) के लिए क्या उपयोग करना है, इस बारे में कोई सिफारिश/सहमति है?

यह गलत जानकारी है। कोर टीम ने कभी नहीं कहा कि आईवीवाई 2019 में रिलीज होगी। इसके बजाय कोर टीम ने कहा (जोर मेरा):

इसे किसी भी छोटे संस्करण में जारी किया जाना चाहिए, जब भी इसका परीक्षण और सत्यापन किया गया हो

मान लें कि मेरे पास आईवी सक्षम के साथ एक कोणीय 7.1.0-बीटा.0 ऐप है, क्या मेरे लिए बिना पेज रीफ्रेश के सामने से जारी गतिशील भाषा परिवर्तन के साथ एक सेटअप करना संभव है?

यदि हाँ तो कैसे? यह दस्तावेज़: https://github.com/angular/angular/blob/master/aio/content/guide/i18n.md
और यह दस्तावेज़: https://angular.io/guide/i18n

यह विशेषता नहीं है?

मैं आधुनिक/भविष्य का i18n-कोणीय ऐप बनाना कहां से सीख सकता हूं?

@tatsujb नहीं यह संभव नहीं है, और यह आईवी और रनटाइम i18n के साथ भी संभव नहीं होगा। यदि आप भाषा बदलना चाहते हैं, तो अभी के लिए आपको अपना एंगुलर ऐप पुनः लोड करना होगा

ठीक है, लेकिन डॉक्स थोड़े कोणीय के एक काइमेरिक संस्करण पर लागू होते हैं जैसे 4 माइनस।

मुझे नहीं लगता कि वे मेरे सेटअप पर लागू होते हैं और न ही वे यह कवर करते हैं कि आप परिवर्तन को कैसे प्रभावी बनाते हैं।

मैं इसे ले रहा हूं परिवर्तन को बैकएंड द्वारा लागू करना होगा।

मेरे मामले में मेरे कोणीय को जावा-वसंत बैकएंड द्वारा उत्पादन मोड में परोसा जाता है। जब मैं भाषा बदलने के लिए ध्वज चिह्न दबाता हूं तो क्या होने वाला है, इसकी बड़ी लाइनें क्या हैं?

आप उपयोगकर्ता को www.yourdomain.com/cn/ पर ले जाते हैं, जहां आपका संपूर्ण कोणीय ऐप चीनी में संकलित है। आप जिस भाषा का समर्थन करना चाहते हैं, उसके लिए आप एक संपूर्ण संकलित कोणीय ऐप के साथ समाप्त होते हैं।

@ocombe @ santhony7 इसके बारे में क्या: https://github.com/actra-development-oss/ng-i18n-aot-loader ?

क्या मैं यह कोशिश कर सकता हूँ?

क्या यह 7.1.0-बीटा.0 के साथ बुरी तरह से संगत है या शालीनता से संगत है?

@ocombe @ santhony7 इसके बारे में क्या: https://github.com/actra-development-oss/ng-i18n-aot-loader ?

क्या मैं यह कोशिश कर सकता हूँ?

क्या यह 7.1.0-बीटा.0 के साथ बुरी तरह से संगत है या शालीनता से संगत है?

मैं इसके बजाय ngx-translate का उपयोग करने की सलाह देता हूं। मैंने दोनों का उपयोग किया है और ngx-translate को बनाए रखना बहुत आसान है।

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

दो डेमो में से एनजीएक्स-अनुवाद बहुत धीमा लगता है, आपका क्या मतलब है जब आप कहते हैं कि इसे बनाए रखना आसान था?

@tatsujb वें एनजी-आई18एन-एओटी-लोडर के डेवलपर के रूप में मुझे पता है कि इसे लागू करना मुश्किल है, कम से कम लोडर को एकीकृत करना।
बाकी सब कुछ केक का एक टुकड़ा है क्योंकि यह मूल कोणीय i18n प्रतिमानों का पालन करता है।

इसे तब तक v7 के साथ काम करना चाहिए जब तक कि टैग संरचनाओं या इसी तरह में कोई ब्रेकिंग परिवर्तन नहीं हुआ है।

एनजीएक्स-अनुवाद को लागू करने की कोशिश कर रहा हूं मुझे अनुवाद योग्य जगह से अनुवाद योग्य जगह पर जाना है। सैकड़ों हैं यह मेरे लिए थोड़ा हास्यास्पद है कि मैं अपने i18n टैग का उपयोग नहीं कर सकता, जिसकी मैंने पहले से योजना बनाई थी।

मुझे लगता है कि आप पर भरोसा करना गलत विकल्प था, @ डिगिस्मैक

@tatsujb इस मुद्दे का अनुसरण करने वाले 58 लोग हैं। व्यक्तिगत रूप से, मैं i18n के संबंध में कोणीय टीम के अपडेट के लिए इसका अनुसरण कर रहा हूं। मैं सराहना करता हूं यदि आपने बकवास बंद कर दिया है जब तक कि यह ओपी राज्यों से संबंधित नहीं है:

यदि आप एंगुलर में नई i18n सुविधाओं को जोड़ना चाहते हैं, तो नीचे पूछने में संकोच न करें और मैं आपको बता दूंगा कि क्या यह संभव है और यदि आपको इसके लिए कोई समस्या खोलनी चाहिए।
यदि आपके पास कोई बग है, तो एक समस्या खोलें (यहां इसके बारे में चर्चा करने की आवश्यकता नहीं है)।

यदि आपके पास अन्य पुस्तकालयों के साथ समस्या है, तो मैं सुझाव देता हूं कि स्टैक ओवरफ्लो पर एक प्रश्न पूछें।

मुद्दा लिखना/टिप्पणी करना मेरी आदत में नहीं है... लेकिन मैं करूँगा!
मानते हुए :
@gtbuchanan और CO टाइप ए व्यक्ति हैं।
@tatsujb और अन्य व्यक्ति जो शिकायत/टिप्पणी/चीजों की अपेक्षा करते हैं वे व्यक्ति के प्रकार बी हैं

टाइप ए आप हमेशा वही चीजें दोहराते नहीं थक रहे हैं?!?! मेरे लिए आप टाइप बी से ज्यादा परेशान हैं।

कोणीय प्रकार बी में i18n लापता सुविधा के कारण लोग आपसे अधिक निराश हैं जो किसी मुद्दे पर "सब्सक्राइब" करते हैं (यदि यह आपको दोस्त बनाना है, तो फेसबुक पर कुछ लाइक कमाएं, मुझे नहीं पता, यहां उसके लिए जगह नहीं है , आप शब्द नहीं बदलेंगे या यह कहते हुए कुछ आविष्कार नहीं करेंगे!...)

मुझे लगता है कि टाइप ए सदस्यता समाप्त कर सकता है, अपडेट की प्रतीक्षा कर सकता है, जल्दी से चैंज की जांच कर सकता है या ब्लॉग/समाचार पढ़ सकता है, सुनिश्चित करें कि कोणीय टीम इसे बड़े फ़ॉन्ट ARIAL 72pixel में रखेगी कि वे ts+runtime i18n से i18n गतिशील अनुवाद पेश करते हैं: कोणीय में बड़ी सुविधा गायब है! उन्होंने इसे बहुत अधिक नहीं माना इसलिए हमारे पास आज सही i18n नहीं है, यह Google की रणनीति है और यह बदल नहीं सकता है!

लोग बी 2 साल पहले इस सुविधा की प्रतीक्षा करते हैं, https://github.com/angular/angular/issues/9104#issue -159302131 हाँ कोणीय 2.X के बाद से!

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

टाइप बी कृपया शिकायत/टिप्पणी जारी रखें जब तक आप कर सकते हैं! लोगों की ज़रूरतों को समझने का यही सबसे अच्छा तरीका है!

स्ट्राइक स्ट्राइक लोल

@tatsujb यह सब व्यक्तिगत वरीयता के लिए आता है। जब मैंने पिछली बार ng-i18n-aot-loader लागू किया था तो मुझे इसे काम करने के लिए एक बेदखल निर्माण और वेबपैक कॉन्फ़िगरेशन को अनुकूलित करना पड़ा था। शायद अब वो बात नहीं रही। हालांकि, एक इजेक्टेड बिल्ड को चलाने का मतलब था कि एंगुलर सीएलआई उपकरण अब प्रयोग करने योग्य नहीं थे। इसलिए, मुझे लंबे समय में ngx-translate को लागू करना और इस तथ्य से निपटना आसान लगा कि यह थोड़ा अलग तरीके से काम करता है।

@gtbuchanan मुझे आपका दर्द महसूस होता है, लेकिन यह "बकबक" सीधे ओपी की पोस्ट में उल्लिखित सुविधाओं के दायरे से संबंधित है। चूंकि Runtime i18n (one bundle for all locales with AOT) की समय-सीमा लगातार खिसकती जा रही है, लोग अभी भी मौजूदा समाधान खोजने के लिए इस थ्रेड पर आ रहे हैं।

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

चूंकि एंगुलर I18N समर्थन ने इसे नवीनतम रिलीज़ में नियोजित नहीं किया - क्या आपके पास हमारे और अन्य लोगों के लिए कोई सिफारिश है जो अभी नई परियोजनाएं बनाने के बारे में हैं?

उदाहरण के लिए, जब तक I18N तैयार नहीं हो जाता, हम ngx-translate का उपयोग कर सकते हैं, लेकिन फिर मैंने उस प्रोजेक्ट के जीथब मुद्दों में कहीं पढ़ा, कि यह आलसी लोडिंग का समर्थन नहीं करेगा, जो हमारे लिए एक शो स्टॉपर होगा।

फिर दूसरी ओर, एंगुलर का I18N सपोर्ट अभी प्राइम टाइम के लिए तैयार नहीं है।

मैं वास्तव में कुछ संकेतों की सराहना करता हूं जो हमें सही दिशा में इंगित करते हैं कि आगामी परियोजना के लिए क्या उपयोग करना है - एनजीएक्स-अनुवाद बनाम?

होना चाहिए:

• धीरे लोड हो रहा है

अच्छा लगा:

• आईसीयू अभिव्यक्ति

धन्यवाद

इस मुद्दे के अनुयायियों के लिए, @ocombe कुछ घंटों में angularconnect पर रनटाइम i18n के बारे में बात करेगा। मुझे लगता है कि कम से कम कुछ खुले प्रश्नों का उत्तर वहां दिया जाएगा। एक लाइवस्ट्रीम उपलब्ध है

@ctaepper - जानकारी के लिए बहुत बहुत धन्यवाद!

@guygit यह ngx-translate या angular-l10n हो सकता है। यहाँ मेरे द्वारा बनाई गई तुलना तालिका है https://medium.com/@sergeyfetiskin/tools -to-translate-your-angular-app-c021e25ff26a

हमारे ऐप्स के लिए, हमने कोणीय तरीके से जाने का फैसला किया, यहां तक ​​​​कि इसकी कुछ सीमाएं भी हैं।

@fetis बहुत बहुत धन्यवाद - मैं एक नज़र डालेगा :-)

अनुवाद फ़ाइलों के लिए XLIFF फ़ाइलों की पसंद के बारे में सोचकर - Google अनुवाद टूलकिट के साथ-साथ Flutter/Dart i18n दोनों ARB फ़ाइलों का समर्थन करते हैं और XLIFF का समर्थन नहीं करते हैं। मैंने सुना है कि एआरबी फ़ाइल समर्थन की योजना नहीं है, लेकिन सोच रहा था कि क्या यह ऐसा कुछ है जिस पर फिर से विचार किया जा सकता है। या अगर कोई ( @ocombe ?) इंगित कर सकता है कि कोणीय XLIFF फ़ाइलों के साथ कहाँ इंटरैक्ट करता है, तो मैं देख सकता हूँ कि यह ARB समर्थन को एकीकृत करना कितना कठिन होगा।

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

@localpcguy यदि आप एक कनवर्टर प्रकार की चीज़ लिखना समाप्त कर देते हैं, तो आप इसे https://github.com/translate/translate में योगदान करने में रुचि ले सकते हैं जो पहले से ही कई प्रारूपों से रूपांतरण की पेशकश कर रहा है।

एक तरफ ध्यान दें, ओकोम्बे ने कुछ महीने पहले कहा था कि वह पीओ फाइलों (और जेएसओएन?) का समर्थन करने के लिए कड़ी मेहनत करेगा। उम्मीद है कि यह किसी बिंदु पर होगा, क्योंकि हमारे पास XLIFF के साथ काम करने के लिए ओके-ईश टूल खोजने में कठिन समय था।

क्योंकि हमारे पास XLIFF के साथ काम करने के लिए ओके-ईश टूल खोजने का कठिन समय था।

@PowerKiKi यह सच नहीं है। लगभग कोई भी ऑनलाइन अनुवाद प्रबंधन उपकरण XLIFF प्रारूप का समर्थन करता है। और यदि आप .xliff को मैन्युअल रूप से संपादित नहीं करना चाहते हैं तो यहां तक ​​कि निःशुल्क डेस्कटॉप अनुवाद प्रोग्राम भी उपलब्ध हैं

@fetis मुझे विषय से हटकर जाने से नफरत है, लेकिन उपकरणों के साथ XLIFF का उपयोग करने के संबंध में काफी दर्द हुआ है। मेरी टिप्पणी यहाँ देखें: https://github.com/angular/angular/issues/20193#issuecomment -345755889

कृपया ऐसे टूल का संदर्भ दें, क्योंकि हमें अभी भी कुछ भी अच्छा नहीं मिला है और अभी तक कुछ ऐसा नहीं मिला है जो XLIFF 2 का समर्थन करता हो। स्मार्ट कैट सुंदर दिखती है, लेकिन इसमें स्ट्रिंग्स को अपडेट करने से मुझे अपनी आंखों का पता लगाने की इच्छा होती है।

ऐसा लगता है कि आप कुछ ऐसा जानते हैं जो हम नहीं जानते :)

पूटल https://github.com/translate/translate का उपयोग करता है और गेटटेक्स्ट (पीओ फाइलों) के साथ वास्तव में बहुत अच्छा था लेकिन यह प्लेसहोल्डर्स/टैग का समर्थन नहीं करता है और वे इसे जोड़ने के लिए किसी से योगदान की प्रतीक्षा कर रहे हैं

मैं इस मुद्दे के लिए एक या दो साल से अधिक समय से सदस्यता ले रहा हूं। ऐसा लगता है कि इस संबंध में प्रगति कोणीय टीम के लिए प्राथमिकता नहीं है, और प्रत्येक भाषा के लिए ऐप को एक बार संकलित करना और गतिशील अनुवाद करने के लिए हुप्स के माध्यम से जाना स्वीकार्य नहीं है। मैं अनुशंसा करता हूं, यदि आप ऐसा करने में सक्षम हैं, तो एक कस्टम पाइप बनाने के लिए जो आपको पसंद की अन्य i18n लाइब्रेरी का उपयोग करता है। शुद्ध होने के कारण, यह पाइप ऐप को कई बार संकलित करने के लिए समान रूप से कुशल होगा। इसके अलावा, एक i18n का उपयोग करके जो कोणीय पर निर्भर नहीं करता है, आप कोड से गतिशील अनुवाद तुच्छ रूप से करने में सक्षम होंगे। एक और फायदा यह है कि आपके अनुवाद अब कोणीय पर निर्भर नहीं होंगे, इसलिए यदि आप चाहें तो कुछ घटकों को अन्य ढांचे में माइग्रेट करना शुरू कर सकते हैं, या आप पूरी स्वतंत्रता के साथ अनुवाद प्रारूप और उपकरण भी चुन सकते हैं। मैं https://airbnb.io/polyglot.js/ का उपयोग कर रहा हूं और इससे बहुत खुश हूं, और यहां तक ​​​​कि जब मेरे ऐप का एंगुलर i18n से पॉलीग्लॉट में माइग्रेशन अभी भी चल रहा है, तो मैं परिणाम और हटाने से अधिक खुश नहीं हो सकता कोणीय i18n के साथ निर्भरता की।

उन लोगों के लिए खेद है जो इसे आपके मेल पर अधिसूचना के रूप में प्राप्त करेंगे और मेरी राय की परवाह नहीं करेंगे, लेकिन चूंकि आपकी अधिसूचनाओं को इतना लंबा पढ़ रहा है, मुझे लगता है कि सदस्यता समाप्त करने से पहले मुझे अलविदा कहना होगा :)

चीयर्स!

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

एंगुलर टीम के लिए रनटाइम i18n एक बड़ी प्राथमिकता है। हालाँकि, अवरोधन इसे नया आइवी रेंडरर जारी करता है। परियोजना की प्रगति अब तक अच्छी है और हम शायद एंगुलर 8 के लिए आइवी की उम्मीद कर सकते हैं। मैं समझता हूं कि इसमें शामिल सभी लोगों के लिए यह एक कठिन स्थिति है। योजनाएं हैं लेकिन जब तक आइवी समाप्त नहीं हो जाती तब तक उन्हें लागू नहीं किया जा सकता है।

कृपया लंदन में हाल ही में एंगुलरकनेक्ट सम्मेलन (2018) से बातचीत देखें, विशेष रूप से ओलिवियर कॉम्बे द्वारा "रनटाइम i18n" और एलेक्स रिकबॉघ द्वारा दिन 2 की मुख्य वक्ता के रूप में।

दरअसल मेरा अनुभव @intellix जैसा ही है।

XLIFF 1.2 10 साल पुराना है , फिर भी ओपन सोर्स प्रोजेक्ट्स में इसके लिए समर्थन काफी खराब लगता है। https://github.com/translate/pootle/issues/4762 और https://github.com/translate/pootle/issues/1811 के अनुसार पूटल पल्सहोल्डर्स का समर्थन नहीं करता है। वेबलेट भी उनका समर्थन नहीं करता है , हालांकि एक पीआर जल्द ही समर्थन जोड़ सकता है।

डेस्कटॉप पर, Virtaal _does_ XLIFF प्लेसहोल्डर्स का समर्थन करता है, लेकिन नवीनतम रिलीज़ 0.7.1 6 साल पुराना है और जो मैंने सुना है, वह अब नवीनतम macOS पर काम नहीं करता है। यह दुर्भाग्य से एक सुव्यवस्थित परियोजना का आभास नहीं देता है, कुछ बहुत पुराने पीआर के साथ जो अभी भी अपनी स्पष्ट सादगी के बावजूद विलय की प्रतीक्षा कर रहे हैं। और पिछले कुछ वर्षों में बहुत कम प्रतिबद्ध गतिविधि ।

मुझे अभी पता चला है कि Poedit 2.2 कुछ दिन पहले जारी किया गया था जो XLIFF 1.2 और 2.0 का समर्थन करता है। दुर्भाग्य से मैं इसका परीक्षण नहीं कर सकता क्योंकि मुझे इस समय स्थापित करते समय Snapcraft.io सीडीएन से एक त्रुटि मिलती है। लेकिन यह डेस्कटॉप उपयोगकर्ताओं के लिए सबसे अच्छा समाधान हो सकता है।

@fetis अगर आपको XLIFF 1.2 को संपादित करने के लिए कुछ ओपन सोर्स (या कम से कम उपयोग करने के लिए मुफ़्त) प्रोजेक्ट मिले, या बेहतर अभी तक XLIFF 2.0, प्लेसहोल्डर्स के समर्थन के साथ, कृपया उन्हें यहां सूचीबद्ध करें। मैंने जो कुछ भी परीक्षण किया वह या तो बिल्कुल काम नहीं कर रहा था, या उपयोग करने के लिए बेहद जटिल था।

@intellix @PowerKiKi यहाँ वह सूची है जो मुझे पता है। हमारा लक्ष्य एक ऑनलाइन अनुवाद मंच है, जहां हम विभिन्न देशों के अनुवादकों/सहयोगियों के साथ सहयोग कर सकते हैं। प्रत्येक सहयोगी के लिए डेस्कटॉप सॉफ़्टवेयर स्थापित करने की प्रक्रिया से गुजरना और XLIFF फ़ाइलों के सिंक्रनाइज़ेशन को प्रबंधित करना हमारे लिए कोई विकल्प नहीं है। इसलिए, मैंने डेस्कटॉप टूल, मेरे द्वारा किए गए प्लेटफ़ॉर्म का परीक्षण नहीं किया।

अनुप्रयोग
ओमेगा टी
https://omegat.org/

स्व की मेजबानी की
https://weblate.org/hi/ +पेड होस्टिंग
https://pootle.translatehouse.org/
https://pontoon.mozilla.org/

प्लेटफार्मों
क्राउडिन
https://crowdin.com/
सीएलआई समर्थन

वेबअनुवादआईटी
https://webtranslateit.com/
सीएलआई समर्थन

ट्रांसिफेक्स
https://www.transifex.com/

वाक्यांश ऐप
https://phraseapp.com/

स्थानीयकरण
https://localise.co/
सीएलआई समर्थन

_मुझे लगता है कि हम अपनी परियोजनाओं के लिए स्थानीयकरण के साथ समाप्त कर देंगे क्योंकि यह सस्ती कीमत के साथ पर्याप्त कार्यक्षमता प्रदान करता है।_

~पीओएडिटर~
https://poeditor.com/pricing/
घोषित XLIFF समर्थन कोणीय प्रारूप के साथ काम नहीं करता है

यदि आप एक ओपन-सोर्स समाधान की तलाश में हैं, तो यह सूची मेरे लिए उपयोगी हो सकती है https://opensource.com/article/17/6/open-source-localization-tools

साइड नोड्स
मैंने XLIFF 2.0 को सपोर्ट करने वाला कोई ऑनलाइन प्लेटफॉर्म नहीं देखा और यह मेरे लिए एक बड़ा सरप्राइज था। XLIFF 1.2 को आधिकारिक तौर पर पदावनत के रूप में चिह्नित किया गया है और उद्योग में किसी ने भी v2.

यह सुनकर खुशी हुई कि पीओएडिट ने एक्सएलआईएफएफ समर्थन की घोषणा की, मैंने इसे .पीओ फाइलों के लिए इस्तेमाल किया और यह अच्छा था।

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

@localpcguy कई प्रारूप हैं, लेकिन यह सब नीचे आता है कि हम कितने का समर्थन कर सकते हैं। एक धारावाहिक लिखने और बनाए रखने में समय लगता है। Xliff 2 को किसी और के द्वारा PR के रूप में जोड़ा गया था, इसलिए हमने समर्थन जोड़ा (अन्यथा हमें इसका समर्थन करने में समय नहीं लगता)।
हमें दो चीजों के लिए एक धारावाहिक की आवश्यकता है: निष्कर्षण, और विलय।
मैंने इस बारे में एंगुलर कनेक्ट पर बात नहीं की है, लेकिन मेरी आशा है कि हम बाहरी सीरिएलाइज़र का उपयोग करने में सक्षम होना चाहिए। आईवी के साथ रनटाइम (मर्ज) के लिए ऐसा करना बहुत आसान होना चाहिए, लेकिन निष्कर्षण अभी भी जटिल है क्योंकि जब हम कंपाइलर में बदलाव करते हैं तो सीरिएलाइज़र को अपडेट करने की आवश्यकता होती है।
मेरे पास इसे करने के बारे में कुछ विचार हैं, लेकिन आइवी लैंड होने के बाद मुझे इसके बारे में टीम से बात करनी होगी। मैं वास्तव में जो करना पसंद करूंगा वह कम से कम JSON समर्थन जोड़ना होगा ताकि मैं कोणीय i18n का उपयोग करके एनजीएक्स-अनुवाद को फिर से लिख सकूं (और क्योंकि बहुत से लोग इसे चाहते हैं)।

धन्यवाद @ocombe (और अन्य सभी इनपुट, मुझे विभिन्न विचार देखना पसंद है)। ऐसा लगता है कि #14185 वह पीआर था जिसका आपने उल्लेख किया था, अगर मैं एआरबी समर्थन जोड़ना चाहता हूं तो क्या यह अभी भी एक अच्छी शुरुआत है? क्या ऐसा कुछ है जिसे सबमिट किए जाने पर संभावित रूप से विलय किया जा सकता है?

@localpcguy कल हमारी एक बैठक है जहाँ हम उस (और अन्य बातों) पर चर्चा करेंगे, मैं आपको बताऊँगा कि यह कैसा चल रहा है

ठीक है तो हम जो सोचते हैं वह काम करेगा: निष्कर्षण के लिए हम किसी प्रकार के जेसन प्रारूप में तार निकालेंगे (यहां तक ​​​​कि एआरबी भी हो सकता है क्योंकि यह अनुवाद के लिए एक आधिकारिक जेसन प्रारूप है) जिसे कोई भी प्रारूप में ले सकता है और पोस्टप्रोसेस कर सकता है जिसे आप उपयोग करना चाहते हैं (json वास्तव में उपयोग में आसान है), और रनटाइम के लिए हम एक प्रकार का इंटरफ़ेस प्रदान करेंगे जिसका उपयोग आप अपने स्वयं के लोडर को लिखने के लिए कर सकते हैं जो आपके प्रारूप को समझता है।

तो इसका बहुत मतलब है, कि हम अनुवाद के लिए किसी भी प्रकार के प्रारूप का उपयोग करने के लिए स्वतंत्र हैं, जब तक हम ऐप के लिए लोडर प्रदान कर सकते हैं?

अच्छा यह कमाल होगा: +1:

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

क्या हम आइवी पर फ़्लाई पर भाषा बदलने के बीटा डेमो (केवल एक वीडियो या लाइवस्ट्रीम फाइल नहीं) की उम्मीद कर सकते हैं? पीओसी प्री-फाइनल आइवी को एक साथ रखने की कोशिश करना लाइन बैराज का पता लगाने का एक शानदार तरीका हो सकता है।

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

बाहरी उपयोगकर्ताओं के लिए रनटाइम सेवा अभी तक पूरी नहीं हुई है, हमारे पास केवल वह कोड है जो क्लोजर ( goog.getMsg ) का उपयोग करता है क्योंकि Google ऐप्स के साथ आइवी का परीक्षण करने के लिए हमें यही चाहिए था।
मैं अब आने वाले महीनों के लिए इस पर काम करूंगा। इसका मतलब है कि आप शायद अभी तक i18n का उपयोग ivy के साथ नहीं कर सकते हैं।
रनटाइम i18n के लिए कोड कल ही मर्ज किया गया था, और i18n के लिए कंपाइलर कोड को अगले कुछ दिनों में मर्ज किया जाना चाहिए (हम वहां पहुंच रहे हैं!) फिर हम बाहरी लोगों के लिए नई सेवा पर काम करेंगे, जिसमें नए लोडर शामिल हैं जिनके बारे में मैंने अभी ऊपर बात की थी, और सेवा आपके कोड में अनुवाद का उपयोग करने के लिए।

मक्खी पर भाषा को बदलने के लिए, इसे अभी भी ऐप के पूर्ण पुनः लोड की आवश्यकता होगी, या शायद एक मार्ग परिवर्तन (जो सभी मौजूदा घटकों को साफ कर देगा)। मैं अभी तक पीओसी पर काम करने की कोशिश नहीं करूंगा।

मक्खी पर भाषा को बदलने के लिए, इसे अभी भी ऐप के पूर्ण पुनः लोड की आवश्यकता होगी, या शायद एक मार्ग परिवर्तन (जो सभी मौजूदा घटकों को साफ कर देगा)। मैं अभी तक पीओसी पर काम करने की कोशिश नहीं करूंगा।

यह उचित है, ... हालांकि ऐप के पूर्ण पुनः लोड की आवश्यकता नहीं है (या कुछ भी जो अंतिम उपयोगकर्ता की आंखों में सहजता को पूरा करता है, एकेए स्टोर नहीं खो रहा है, न ही प्रमाणीकरण, न ही यूआरएल (ठीक है ... /en/... के लिए लेखांकन नहीं

@tatsujb ऐप को रीलोड करना पेज को रीलोड नहीं कर रहा है, स्टैकब्लिट्ज प्रत्येक संपादन पर ऐप को फिर से लोड करता है, क्या आपको लगता है कि यह आपकी आंखों के लिए देखने योग्य है?

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

तो इस सही सेटअप के साथ; स्टोर वैरिएबल वैल्यू और ऑथेंटिकेशन (साथ ही स्क्रॉल करने योग्य डिव पर स्क्रॉल राशि) रहेगा?

@tatsujb जब तक वे कोणीय-निर्मित उदाहरण के बाहर संग्रहीत होते हैं, उदाहरण के लिए लेक्सिकल वैरिएबल या विंडो प्रॉपर्टी में।

@trotyl आप पेज के बिना ऐप को फिर से कैसे लोड करते हैं?

@saithis आप हमेशा एप्लिकेशन को platformBootstrap().bootstrapModuleFactory() (या अन्य समकक्ष) द्वारा अनिवार्य रूप से बूटस्ट्रैप करते हैं, आप इसे कभी भी कहीं भी कॉल कर सकते हैं, कॉल पर कोई जादू नहीं है (एंगुलर सीएलआई को छोड़कर वर्तमान में कोड प्रतिस्थापन के लिए कुछ सीमा है, अब एक नहीं होना चाहिए आइवी में समस्या)।

स्क्रिप्ट आमंत्रण समय पर बूटस्ट्रैप उत्सुकता से और इसे हमेशा के लिए रखें (अनमाउंट न करें) केवल एसपीए के लिए एक सामान्य अभ्यास है, लेकिन कोई भी आपको ऐसा करने के लिए मजबूर नहीं कर रहा है।

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

@trotyl धन्यवाद, मुझे नहीं पता था कि बूटस्ट्रैपिंग फिर से काम करती है।

@ocombe क्या आप कृपया यहां स्पैम हटा सकते हैं? और मेरी टिप्पणी भी।

1. to @fetis : आप जैसे लोगों को मुद्दे को अनफॉलो करना चाहिए और रिलीज के लिए सबस्क्राइब करना चाहिए
   

2. @Andrulko को: हमें परवाह नहीं है

3. @ कोणीय के लिए: जैसा कि कहा गया है कि मैं यहां शिकायत पूरी तरह से समझता हूं! जैसे हम v7 के लिए ivy चाहते थे vX के लिए नहीं या v7 के लिए बड़ा सुधार नहीं बेचते, जबकि आप इसके लिए प्रतिक्रिया नहीं दे सकते या आप इसे अपनी समय सीमा का सम्मान करने के लिए 7.x में डाल देंगे ... यह उचित नहीं है! हाँ विकल्प होना चाहिए कि कुछ भी घोषणा न करें और कोई भी शिकायत नहीं करेगा यह भी बुरा विचार है, आपको ढांचे में अपनी जगह बनाने की जरूरत है। हाँ हम v2 के बाद से सही i18n की प्रतीक्षा करते हैं, बड़े ऐप के लिए इस अनिवार्य पहलू में आप अंतरराष्ट्रीय वेबएप जैसे बड़े ऐप के लिए कोणीय तैयार नहीं बेच सकते हैं जिसमें 50000स्ट्रिंग शामिल हैं, निश्चित रूप से आप इसे पढ़ना पसंद नहीं करते हैं, लेकिन यह करुणा के बिना और अच्छे के साथ है विश्वास, इम्हो अगर हम i18n पर विचार नहीं करते हैं और अन्य सभी पहलुओं के लिए धीमी गति से निर्माण समय/देव समय पर विचार करते हैं तो मैं कह सकता हूं कि कोणीय बहुत बढ़िया है। शीर्ष पर निश्चित दिशा बदलनी चाहिए, निश्चित रूप से निर्णायकों से बात कर रहा हूं। हमसे (जो आलोचना करते हैं) हाईट अपवाद क्योंकि बिग-गूगल से हम इस तरह की बड़ी गलती नहीं कर सकते। मैं Google डेवलपर्स को अपवादों की तरह देखता हूं- बिना गलती के स्मार्ट लोग अनुभवी डेवलपर्स के लिए और Google जैसे devteam के लिए यह चीजें नहीं होनी चाहिए! मेरी वैश्विक राय बड़े ऐप के लिए कोणीय 100% नहीं बेचती है जब कंपनी इसे चुनती है तो निजी-कंपनी को बेचें/समझाएं खुला स्रोत क्या है!

4. @ सभी विशेष रूप से उन लोगों के लिए जो व्यावसायिक कंपनी में काम नहीं कर रहे हैं: मेरी टिप्पणी को नापसंद करें क्योंकि मैं निश्चित रूप से ओपन सोर्स का सम्मान नहीं करता?!?! यह बड़े ऐप के लिए तैयार है (100% नहीं 80%)... हम निर्भर हैं!

यह मेरी आखिरी टिप्पणी है क्योंकि हम जहाज छोड़ते हैं! सदस्यता समाप्त करें + मेरी अगली परियोजना में कोणीय न चुनें (आप कह सकते हैं कि आप विजेता हैं, ओपन सोर्स प्रोजेक्ट को हमारे जैसे लोगों की आवश्यकता नहीं है)

ऐसा जुनून! बस संतुलन के लिए ... हमने अपने ऐप को एंगुलर 6 में फिर से लिखा, 6 भाषा में अंतर्राष्ट्रीयकृत किया, और केवल मामूली असुविधाओं को महसूस किया है। निश्चित रूप से, तेजी से निर्माण समय और फ्लाई पर अनुवाद निश्चित रूप से अच्छा होगा लेकिन हमारे लिए दुनिया का अंत नहीं होगा। फ्रेमवर्क का 98% जो i18n नहीं है, कमाल का है। बढ़िया काम दोस्तों! नई सुविधाओं के लिए तत्पर हैं।

हमारे पास अपने नए उद्यम पोर्टल के लिए एंगुलर के साथ एक शानदार अनुभव भी है। i18n आखिरी गायब विशेषता है जिसकी हमें आवश्यकता है, क्योंकि स्विट्जरलैंड में, हमें चार भाषाओं का समर्थन करना है। मुझे लगता है कि यहां मुद्दा संचार के साथ है। प्रोजेक्ट प्लानिंग के लिए, अगर हमारे पास एक साल पहले i18 रिलीज़ का बेहतर अनुमान होता, तो हम इसके लिए योजना बना सकते थे और अन्य संभावनाओं पर विचार कर सकते थे। उस ने कहा, हम किसी भी अपडेट को सुनने के लिए उत्सुक हैं। :-)

कोणीय की रक्षा में, आप इसे इस तरह से उत्पादन में उपयोग करने में काफी आसान कर सकते हैं (सबसे अच्छा समाधान मुझे मिला)

1. अनुवाद तर्क को कहीं स्थानांतरित करने के लिए अनुवादित चर पाठ को अपने घटक में लपेटें

parent-component.component.html

<app-route-translation
  [routeData]="routeData"
></app-route-translation>

route-translation.component.html

<span
  i18n="route text|Navigation text for route@@routeText"
>{
  routeData.langKey, select,

  home-1 {Home 1}
  home-1-1 {Home 1-1}
  home-1-2 {Home 1-2}
  home-2 {Home 2}
  home-2-1 {Home 2-1}
  home-2-2 {Home 2-2}
  home-root {Home root}
  lazyPage {Lazy page}
  notFound {404}

  other {Other}
}</span>

1. angular.json में बिल्ड कॉन्फ़िगरेशन फ़ोल्डर्स को कॉन्फ़िगर करें जैसे

"prod-en": {
  ...
   "outputPath": "dist/en/",
  ...
},
"prod-ru": {
  ...
   "outputPath": "dist/ru/",
  ...
}

1. विभिन्न भाषाओं के लिए ऐप संकलित करने के लिए डॉकर बिल्ड फ़ाइल को इस तरह कॉन्फ़िगर करें

FROM node:8 as build-stage
WORKDIR /app
COPY angular-util .
RUN npm install
RUN npm run ng build -- --configuration=prod-en
RUN npm run ng build -- --configuration=prod-ru

FROM nginx
WORKDIR /usr/share/nginx/html
COPY --from=build-stage /app/dist .
COPY nginx.conf /etc/nginx/conf.d/default.conf

1. उप डोमेन (जैसे en.site-name.com, ru.site-name.com) पर ऐप पेश करने के लिए इस nginx.conf का उपयोग करें, जहां ru में set $subdomain ru; को आपके डिफ़ॉल्ट लोकेल से बदला जाना चाहिए

server {
  listen 80;
  set $subdomain ru;
  if ($host ~ ^(\w+)\.) {
    set $subdomain $1;
  }
  location / {
    root /usr/share/nginx/html/$subdomain;
    try_files $uri $uri/ /index.html =404;
  }
}

अधिक जानकारी के लिए यहां देखें
https://github.com/ivanivanyuk1993/angular-util/tree/master/src/app/util/shared/route-list
https://github.com/ivanivanyuk1993/titans-कंधे-प्रोजेक्ट/ट्री/मास्टर/कंटेनर-विवरण/ui-container-description

मैं इस टिप्पणी के लिए एक अंगूठा चाहूंगा। यह सही नहीं हो सकता है, लेकिन यह अभी भी इस विषय पर सबसे उपयोगी पोस्ट है जो मुझे वेब पर मिली है

सभी को नमस्कार,

मैं अपने प्रोजेक्ट के लिए i18n अनुवादों का उपयोग कर रहा हूं। मुझे निम्नलिखित क्षेत्र में संदेह है:

1. क्या विभिन्न पुस्तकालयों के लिए अलग-अलग एक्सएलएफ स्रोत फाइलें उत्पन्न करना संभव है (एनजी जेनरेट लाइब्रेरी लाइब्रेरीनाम कमांड का उपयोग करके बनाया गया)?
2. चयन या बहुलीकरण के लिए अंतर्राष्ट्रीयकरण का उपयोग करते समय, उत्पन्न xlf स्रोत फ़ाइल विभिन्न विकल्पों के लिए ट्रांस-यूनिट आईडी बनाती है। क्या विभिन्न विकल्पों के लिए भी टेम्पलेट के माध्यम से एक आईडी प्रदान करना संभव है? (जैसा कि नीचे की छवि में दिखाया गया है)
   

कृपया आप कुछ उत्तरों के साथ मेरी मदद कर सकते हैं।

@learnersLicense :

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

1. मुझे नहीं लगता कि यह संभव है। आप प्लेसहोल्डर्स को विशेष टिप्पणियों के साथ नाम दे सकते हैं: <div i18n>Some value: {{ valueA // i18n(ph="PH_A") }}</div> लेकिन मुझे नहीं लगता कि यह आईसीयू अभिव्यक्तियों के साथ काम करता है, @AndrewKushnir ?
   आप उसके लिए एक फीचर अनुरोध कर सकते हैं, या शायद https://github.com/angular/angular/issues/24080 पर एक टिप्पणी जोड़ें जो समान प्रतीत होता है (आईसीयू अभिव्यक्तियों में desc/अर्थ जोड़ें)

आपकी लाइब्रेरी का उपभोग करने वाला कोई व्यक्ति उस लाइब्रेरी के लिए आपके अनुवाद लोड नहीं कर पाएगा

इसके आसपास काम करने का एक तरीका यह है:
1) लाइब्रेरी एक्सट्रेक्ट i18n को xliff में अनुवाद करें और अनुवाद करें
2) लाइब्रेरी पैकेज के साथ xliff फ़ाइलें शिप करें

3) उपभोक्ता अपनी स्वयं की xliff फ़ाइलें भी निकालता है
4) उपभोक्ता xliff को xml पार्सर में लोड करता है। नोड_मॉड्यूल से उत्पन्न होने वाली किसी भी ट्रांस-इकाइयों को छोड़ देता है
5) उपभोक्ता अपने xliff को लाइब्रेरी xliff के साथ जोड़ता है

जिसका अर्थ है कि जो कोई आपकी लाइब्रेरी का उपभोग करता है, वह उस लाइब्रेरी के लिए आपके अनुवादों को लोड नहीं कर पाएगा

हो सकता है कि मैं इस कथन को गलत समझ रहा हूं, लेकिन जब मैं अपनी xlf फाइलें बनाता हूं तो मुझे अपनी कंपनियों के अनुप्रयोगों के लिए अनुवाद सेटअप के बारे में पता होता है, उनमें अन्य परियोजनाओं के टेम्प्लेट में निर्दिष्ट कुंजियाँ शामिल होती हैं। जो दिमाग में आता है वह है https://github.com/ng-bootstrap/ng-bootstrap

यह फिलहाल संभव नहीं लगता:

<my-button i18n-title="@@SHARED_GO_LABEL" [title]="'Go'" [button-style]="'primary'" (click)="navigateToForm()"></my-button>

इन परिवर्तनों के दायरे में इस पर ध्यान दिया जाएगा (या मैं कुछ गलत कर रहा हूँ)?

@mikejr83

यह सम्भव है। आपको बस title title="Go" रूप में निर्दिष्ट करना होगा न कि [title]="'Go'" के रूप में

आपके उत्तरों और सुझावों के लिए @ocombe और @ ewok-janitor धन्यवाद। मैं

@ocombe क्या पुस्तकालय के लिए अनुवाद उपलब्ध होने तक कोई संभावित तिथि है?

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

क्या xliff फ़ाइलों के लिए पहले से कोई समाधान है? https://github.com/angular/angular/issues/17506
जब तक संदर्भ निश्चित नहीं हैं, तब तक प्रारूप का उपयोग करना असंभव है।

@ocombe मार्ग अनुवादों का समर्थन करने की कोई योजना है?

यह कई बार अनुरोध किया गया है हाँ, यह तत्काल योजना नहीं है लेकिन यह करने के लिए चीजों की सूची में है

नमस्ते, क्या आईवीआई को बीटा में जारी किए जाने पर रनटाइम i18n का उपयोग करने के बारे में कोई दस्तावेज है?

@marcelnem , यदि आप इस URL की जांच करते हैं, तो सभी दस्तावेज़ीकरण बिंदु लंबित हैं।

https://is-angular-ivy-ready.firebaseapp.com/#/status

@ocombe महान कार्य आप अभी Google पर कर रहे हैं। कोणीय i18n शुरू से ही ngx-translate जैसा 'कुछ' होना चाहिए था। मैं सोच रहा था कि क्या एंगुलर 8/9 जारी होने के बाद एनजीएक्स-ट्रांसलेट से एंगुलर i18n स्टाइल में माइग्रेट करने के लिए माइग्रेशन गाइड, ऑटोमेटेड-टूल, फीचर तुलना, ...

हाय ocombe
इस सुविधा के बारे में आपसे जांच करने की आवश्यकता है, जिसे आपने ऊपर बताया है
रनटाइम i18n (एओटी के साथ सभी स्थानों के लिए एक बंडल) - [इस पर काम कर रहा है] >> क्या यह अभी भी प्रगति पर है, या यह बाहर है

क्या आप मुझे बता सकते हैं, कोई कामकाज, अगर यह अभी भी प्रगति पर है
शुक्रिया

@ocombe आपने ऊपर लिखा है कि भाषा संकुल को लैसी लोडिंग द्वारा लोड किया जाना चाहिए। क्या भाषा पैक को सीधे index.html में लोड करना भी संभव होगा? क्योंकि हमारे पास मामला है कि हमारा एप्लिकेशन एडब्ल्यूएस लैम्ब्डा पर चलता है और संकलित कोणीय फाइलें एस 3 बाल्टी में संग्रहीत होती हैं। यह वास्तव में पहले से ही एक समाधान है कि यह बिल्कुल काम करता है, लेकिन हम लैसी लोडिंग का उपयोग नहीं कर सकते क्योंकि कोणीय किसी अन्य होस्ट से फ़ाइलों को लोड नहीं कर सकता है। इसलिए, एंगुलर की सभी फाइलों को पहले से ही index.html में शामिल किया जाना चाहिए (जहां हम एक स्क्रिप्ट के माध्यम से S3 होस्ट जोड़ते हैं)।

@ nidhi8953 यह अभी भी डब्ल्यूआईपी है, यह आईवी के साथ उपलब्ध होगा, अभी के लिए यह केवल Google के अंदर काम करता है (क्योंकि हम अनुवाद के लिए आंतरिक रूप से क्लोजर कंपाइलर का उपयोग करते हैं)। रनटाइम सेवा जो अनुवादों को संभालेगी, बाहरी दुनिया के लिए बहुत प्रयोगात्मक है। यदि आप कुछ चीजों का परीक्षण करना चाहते हैं, तो आप इस उदाहरण को देख सकते हैं: https://github.com/angular/angular/blob/master/packages/core/test/bundling/hello_world_i18n/index.ts लेकिन आपको पता होना चाहिए कि फ़ंक्शंस अभी भी एक कारण से निजी हैं, उनका नाम बदल दिया जाएगा और निकट भविष्य में बदल दिया जाएगा। वर्तमान लक्ष्य एपीआई के एक ठोस सेट पर काम करना शुरू करना है एक बार v8 बाहर हो गया है (महीने के अंत में) और पूरे v8 के लिए v9 के बाहर होने तक इसके चारों ओर पुनरावृति करना है, जिस बिंदु पर एपीआई को स्थिर माना जाना चाहिए

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

@ocombe क्या हम आइवी (वर्तमान में 8.0.0-rc.3) का उपयोग कर सकते हैं और कई बिल्ड की कोणीय 7 विधि का उपयोग करके i18n को लागू कर सकते हैं? या क्या मुझे आइवी के लिए i18n एपीआई जारी होने तक एंगुलर 7 के साथ रहना होगा? यदि संभव हो, तो मैं वास्तव में आइवी का लाभ उठाना पसंद करूंगा, जबकि साथ ही i18n के पुराने तरीके का उपयोग करते हुए नई, रनटाइम विधि उपलब्ध होने तक।

अपडेट: इसे आज़माने के बाद, न तो ng xi18n निष्कर्षण (#https://github.com/angular/angular-cli/issues/14225 देखें) और न ही w/i18n के निर्माण का कोई प्रभाव नहीं पड़ता है। कोई .xlf फ़ाइल निर्यात नहीं की जाती है और किसी भी शब्द का अनुवाद नहीं किया जाता है। लेकिन tsconfig.app.json में enableIvy विकल्प को गलत पर सेट करने के साथ, दोनों संस्करण 8.0.0-rc.3 के साथ बढ़िया काम करते हैं। इसका मतलब है कि मैं एंगुलर के अपग्रेड पथ का अनुसरण कर सकता हूं, i18n को नहीं खो सकता, डिफरेंशियल लोडिंग जैसे कुछ नए लाभ प्राप्त कर सकता हूं, और i18n के काम करने के बाद आइवी को चालू करने के लिए तैयार रह सकता हूं।

@jacobbowdoin जैसा कि आपने पाया कि यह आइवी के साथ काम नहीं करता है, लेकिन अगर यह सक्रिय नहीं है तो यह काम करता है।
मैं पुराने निष्कर्षण/लोडिंग सिस्टम को आईवी के साथ काम करना चाहता था, लेकिन चूंकि यह सिर्फ अस्थायी होता, इसलिए इसे टीम द्वारा प्राथमिकता के रूप में निर्धारित नहीं किया गया था (जो समझ में आता है, अनिवार्य चीजें पहले काम करना प्राथमिकता है)।

हाय @ocombe , हम अभी i18n विकसित करना चाहते हैं, इसलिए हम रनटाइम-i18n की प्रतीक्षा नहीं कर सकते। क्या आप अब भी ngx-translate का उपयोग करने की अनुशंसा करेंगे? क्या इसका i18n-polyfill के साथ उपयोग करने का कोई मतलब है? क्या i18n-polyfill का उपयोग करने से रनटाइम-i18n में माइग्रेशन आसान हो जाएगा?

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

हाय @ocombe , क्या इस पर कोई स्टेटस अपडेट है:

-रनटाइम i18n
-एक टेम्पलेट के बाहर अनुवाद स्ट्रिंग का उपयोग करें - #11405

हम वर्तमान में बहस कर रहे हैं कि क्या हमें स्रोत कोड अनुवाद की प्रतीक्षा करनी चाहिए या i18n-polyfill का उपयोग करना चाहिए (हमने पहले ही i18n के साथ शुरुआत की है)। हम आसानी से कुछ सप्ताह प्रतीक्षा कर सकते हैं, इसलिए लगभग समयरेखा की सराहना की जाएगी। आपका बहुत बहुत धन्यवाद!

@halilovicedvin जैसे ही Google ऐप्स में ivy डिफ़ॉल्ट है, हम बाहरी उपयोगकर्ताओं के लिए रनटाइम i18n सेवा पर काम करना शुरू कर देंगे, इसलिए कहीं जल्द और v9 के बीच
मैं गर्मियों के बाद तक इस पर भरोसा नहीं करूंगा क्योंकि लोग कुछ दिन की छुट्टी लेने जा रहे हैं

@halilovicedvin हमने कुछ हफ्ते पहले i18n के साथ i18n-polyfill के साथ शुरुआत की है और यह बहुत अच्छा काम करता है। मुझे उम्मीद है कि रनटाइम-i18n का उपयोग उसी तरह किया जाएगा जैसे i18n-polyfill

@vekunz मैं यह भी उम्मीद कर रहा था कि अगर हम i18n-polyfill के साथ ngx-translate का उपयोग करते हैं, तो हम आसानी से रनटाइम-i18n में माइग्रेट करने में सक्षम होंगे, लेकिन @ocombe (https://github.com/angular/angular/issues) से टिप्पणी के बाद /16477#issuecomment-498239301) मुझे यकीन नहीं है कि पॉलीफ़िल को सेटअप करने का अतिरिक्त प्रयास उचित है या नहीं। हो सकता है कि हम केवल ngx-translate का ही उपयोग करें।

@vekunz इसे स्थापित करने का आपका अनुभव क्या है?

@marcelnem आप i18n-polyfill के साथ ngx-translate का उपयोग नहीं कर सकते। i18n-polyfill केवल angular-i18n के साथ प्रयोग के लिए है।

i18n-polyfill का सेटअप वास्तव में बहुत आसान था। यहां तक ​​​​कि प्रलेखन भी बिल्कुल सही नहीं है, मैंने इसे बहुत तेजी से समझ लिया है कि क्या बदलना है।

@vekunz मैं अब समझता हूं, धन्यवाद। मुझे यकीन नहीं है कि i18n-polyfill का उद्देश्य क्या है। क्या आपको अभी भी कई बार ऐप बनाना है और इसे http://myapp/en , http://myapp/de , http://myapp/fr ,... के तहत आधिकारिक कोणीय i18n के साथ कई बार तैनात करना है?

@marcelnem हाँ, आपको i18n-polyfill के साथ भी कई बिल्ड की आवश्यकता है। उद्देश्य यह है कि कोणीय-i18n के साथ आप वर्तमान में केवल HTML टेम्प्लेट के अंदर अनुवाद का उपयोग कर सकते हैं, न कि आपके टाइपस्क्रिप्ट कोड के अंदर। i18n-polyfill आपके अंदर टाइपस्क्रिप्ट कोड के अनुवाद का उपयोग करने के लिए angular-i18n का विस्तार करता है।
कोणीय 9 (गिरावट में आ रहा है) के साथ कोणीय-i18n टाइपस्क्रिप्ट के अंदर भी अनुवाद का समर्थन करेगा, लेकिन इस बीच हमें इसके लिए i18n-polyfill की आवश्यकता है।

@vekunz क्या आप इसके बारे में कुछ और विस्तार से जा सकते हैं: "यहां तक ​​​​कि दस्तावेज़ीकरण भी बिल्कुल सही नहीं है, मैंने इसे बहुत तेज़ी से समझ लिया है कि क्या बदलना है।" मैं शायद अगले सप्ताह i18n-polyfill देख रहा हूं, इसलिए किसी भी जानकारी की सराहना की जाएगी। धन्यवाद

@halilovicedvin @marcelnem मैंने एक पेस्टबिन डॉक बनाया जहां मैं इसका वर्णन करता हूं, क्योंकि यह इस GitHub मुद्दे का मुख्य विषय नहीं है https://pastebin.com/Xib6X6E9

@ocombe xi18n टूल का उपयोग करके, क्या मैं इनपुट पथ को संपूर्ण प्रोजेक्ट/रिपॉजिटरी के बजाय केवल src फ़ोल्डर (अनुवाद उत्पन्न करने के लिए) तक सीमित कर सकता हूं?

@ocombe क्या आइवी एंगुलर 8 के साथ कई स्थानों का समर्थन करता है (सिर्फ लोकेल परिभाषा, भाषा फ़ाइल नहीं; उदाहरण के लिए दिनांक पाइप के लिए)? क्योंकि एक अन्य टीम वर्तमान में एनजीएक्स-अनुवाद के साथ एंगुलर का उपयोग करती है, लेकिन एक तीसरे पक्ष के घटक को सही लोकेल की आवश्यकता होती है। एक विकल्प जेआईटी-कंपाइलर को प्रोड मोड में उपयोग करना होगा, लेकिन यह बहुत अच्छा नहीं है। लेकिन साथ ही वे हर भाषा के लिए एक नया बंडल संकलित नहीं कर सकते, क्योंकि यह बहुत अधिक होगा।

@vekunz नहीं, आप एकाधिक लोकेशंस सेट नहीं कर सकते हैं, आपको प्रत्येक संकलित बंडल के लिए लोकेल सेट करने की आवश्यकता है (इसे क्ली कॉन्फ़िगरेशन फ़ाइल में सेट किया जा सकता है)
मुझे पता है कि यह वह नहीं है जो आप सुनना चाहते थे, लेकिन अभी के लिए ऐसा ही है

@ocombe क्या आप कृपया कुछ बता सकते हैं, मुझे पता है कि एंगुलर की टीम इसे किसी समस्या के रूप में नहीं पहचानती है, लेकिन क्या आपको लगता है कि एंगुलर हमें निकट भविष्य में ऐप को फिर से लोड किए बिना रनटाइम में भाषा बदलने की अनुमति देगा, इसलिए अनुवाद में एक एकल बंडल और सही अनुवादों को लोड करने और इसे टेक्स्ट लिटरल्स के साथ बाँधने की संभावना है?

एक बंडल हाँ होने पर, लेकिन अनुवादों को बूस्टरैप (जब ऐप लोड होता है) पर लोड किया जाएगा। मौजूदा आर्किटेक्चर के साथ पहले से ही अनुवादों का उपयोग करने वाले घटकों को पुनः लोड किए बिना अनुवादों को "हॉट" रीलोड करना बहुत जटिल होगा।
मैं यह नहीं कह रहा हूं कि यह असंभव है, लेकिन मैं इसे निकट भविष्य में दुर्भाग्य से होते हुए नहीं देखता।

त्वरित प्रतिक्रिया के लिए धन्यवाद @ocombe :) अच्छा काम जारी रखें: +1:

कुछ कोणीय सम्मेलन (मुझे लगता है कि एंगुलरकनेक्ट) से @ocombe की एक प्रस्तुति थी जहां उन्होंने i18n और आइवी के बारे में बात की थी, और वहां उन्होंने इसे बहुत अच्छा बताया, यह इतना जटिल क्यों है। मैं वीडियो खोजने की कोशिश कर सकता हूं।

मुझे लगता है कि मुझे यह https://www.youtube.com/watch?v=miG-ghJhFPc . मिल गया है

आइवी के साथ रनटाइम i18n की प्रतीक्षा कर रहे लोगों के लिए v9 के लिए वर्तमान योजना है कि अनुवाद आइवी के साथ काम करें, लेकिन केवल एक बिल्ड स्टेप के रूप में (जैसे कि यह अभी व्यू इंजन के साथ है)। इसका मतलब है कि यह अभी भी 1 बिल्ड / लोकेल होने जा रहा है, और कोई कोड अनुवाद नहीं होगा (केवल टेम्पलेट अनुवाद)।

बमर। खैर, इसके लायक क्या है, आपकी कड़ी मेहनत के लिए धन्यवाद!

@ocombe क्या आप अभी भी रनटाइम कोड अनुवादों के लिए पॉलीफ़िल बनाए रखेंगे?

अगर यह टूट जाता है हाँ, मैं इसमें नई चीजें नहीं जोड़ूंगा, हालांकि

यह एक तरह से बेकार है कि i18n इतने लंबे समय तक द्वितीय श्रेणी का नागरिक रहा है... हर कोई मूल अंग्रेजी स्थानीय वातावरण में काम नहीं करता है। ):

वैसे मैं सहमत हूं, मैं कुछ कंपनियों को मुझे प्रायोजित करने की कोशिश कर रहा हूं ताकि मैं कोणीय के लिए नए शक्तिशाली i18n समाधान विकसित कर सकूं (मेरे पास विचारों का एक टन है)।
यदि आप रुचि रखने वाले लोगों के बारे में सोचते हैं, तो मुझे ट्विटर (@ocombe) या ईमेल ([email protected]) पर बताएं

@ocombe मैं आपके काम के लिए भी आपको धन्यवाद देना चाहता हूं। यह थोड़ी हैरान करने वाली खबर है कि आपको टीम छोड़नी पड़ रही है। जैसा कि आपने कहा I had to ... , यह मुझे सीधे आपसे पूछने के लिए मार्गदर्शन करता है कि मुख्य कारण क्या था। मुझे उन अप्रत्यक्ष संकेतों और अनुमानों से नफरत है, इसलिए आपसे इतना सीधा सवाल है।

मैं एंगुलर टीम के साथ काम करने वाला एक बाहरी ठेकेदार था और Google का पूर्णकालिक कर्मचारी नहीं था और इस तरह मेरा अनुबंध किसी भी बिंदु पर समाप्त हो सकता है जो इस बात पर निर्भर करता है कि टीम को क्या चाहिए।
वे परियोजना में मदद करने के लिए आंतरिक रूप से नए लोगों की भर्ती कर रहे हैं और मुझे विश्वास है कि उन्हें i18n और अन्य विषयों में मदद करने के लिए सही लोग मिलेंगे, इसलिए आपको कोणीय के भविष्य के बारे में चिंता करने की ज़रूरत नहीं है: visage_légèrement_souriant: यह सिर्फ एक है अस्थायी झटका

@ocombe आपके स्पष्टीकरण के लिए धन्यवाद।

क्या कोई मुझे बता सकता है कि मैं कक्षा के बाहर i18n (i18n-polyfill) का उपयोग कैसे कर सकता हूं जैसे कि एनम या कॉन्स एरे या .model.ts फाइलें?

स्थिरांक के लिए, मैं अभी भी उन्हें एक कक्षा में रखता हूँ। मुझे कोई विकल्प नहीं पता: /

@ocombe एनजीएक्स-अनुवाद, i18npolyfill और कोणीय टीम के साथ कोणीय के लिए i18n के साथ आपकी कड़ी मेहनत के लिए बहुत बहुत धन्यवाद।
हम अपने उपयोगकर्ताओं को अनुवाद प्रदान करने के लिए दैनिक रूप से आपके काम का उपयोग करते हैं, जैसा कि किसी भी गैर-तुच्छ एप्लिकेशन के लिए आवश्यक है।
आप जो कर रहे हैं उसमें आगे बढ़ने के लिए शुभकामनाएँ।

स्थिरांक के लिए, मैं अभी भी उन्हें एक कक्षा में रखता हूँ। मुझे कोई विकल्प नहीं पता: /

हम्म .. अगर मैं उन्हें कक्षा में ले जाता हूं तो मुझे वैरिएबल को उपयोग करने के लिए स्थिर बनाने की आवश्यकता होती है। लेकिन मैं i18n का उपयोग स्थिर चर के लिए नहीं कर सकता।

निर्यात वर्ग उदाहरण {
कंस्ट्रक्टर (निजी i18n: I18n) {}
स्थिर चर = i18n ('पाठ'); // मैं यहाँ i18n का उपयोग नहीं कर सकता क्योंकि यह वर्ग उदाहरण के लिए स्थिर नहीं है
}

दुखद समाचार ... यह "कमजोर" कोणीय ... अन्य लोगों की तरह कहते हैं, यह महान काम के लिए @ocombe के लिए केवल बड़ा धन्यवाद है, शुभकामनाएँ!

मैं उत्सुक हूँ, ngx-translate का उपयोग करने के क्या नुकसान हैं? ऐसा लगता है कि यह ठीक उसी तरह की कार्यक्षमता के लिए सक्षम है जिसकी लोग तलाश कर रहे हैं

मैं कहूंगा कि नुकसान निम्नलिखित हैं:

• बंडल आकार बढ़ाता है (बाहरी lib + निर्माण समय पर कोड को बदलने के बजाय बाहरी फाइलों के रूप में अनुवाद)
• आधिकारिक नहीं (यदि मैं मर जाता हूं तो काम बंद हो जाता है, और समान स्तर का समर्थन नहीं)
• xliff/xmb का समर्थन नहीं करता है (लेकिन प्लगइन के माध्यम से जेसन और अन्य प्रारूपों का समर्थन करता है, और कोई इसका समर्थन करने के लिए xliff/xmb प्लगइन बना सकता है)
• आलसी लोडिंग/अनुवादों को विभाजित करते समय कुछ छोटी गाड़ी व्यवहार हो सकता है (मुझे इसे ठीक करने के लिए कभी नहीं मिला)
• आधिकारिक कार्यान्वयन की तुलना में सिंटैक्स अधिक जटिल है
• प्रदर्शन (अनुवादों की प्रारंभिक लोडिंग पाठ को 1s के लिए गायब कर सकती है, और अधिक स्मृति दबाव क्योंकि मुझे यह देखने के लिए रनटाइम पर सामग्री की निगरानी करनी होती है कि क्या कुछ बदल गया है)

ऐसा कहा जा रहा है कि यह बहुत से लोगों के लिए काफी अच्छा लगता है

यह उत्सुक है कि कोणीय कैसे बढ़ावा देता है और अभिगम्यता में निवेश करता है लेकिन उस पैकेज में भाषाओं को शामिल नहीं करता है। यह वास्तव में महसूस करता है कि यह एक एकभाषी वातावरण से लिया गया निर्णय है।

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

@ocombe कोई संभावना नहीं है कि Google आपको ठेकेदार के रूप में नहीं रखता है?😉

@DmitryEfimenko हम वर्तमान में ngx-translate का उपयोग कर रहे हैं और इससे काफी खुश हैं।

@ocombe क्या संभावना है कि Google बाहरी डेवलपर/समुदाय से इस सुविधा को स्वीकार करे? मुझे लगता है कि हम बहुत लंबा इंतजार कर रहे हैं।

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

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

@ocombe @IgorMinar मैं आइवी i18n के लिए कुछ स्वयंसेवी कार्य प्रदान करना चाहता हूं, अगर कुछ संभावनाएं हैं तो कृपया मुझे बताएं।

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

मैं योगदान करने को तैयार हूं लेकिन मुझे कार्यों के दायरे और जटिलता का बिल्कुल पता नहीं है। क्या हम सूची को मूल संदेश में अपने विनिर्देश/आवश्यकताओं के रूप में ले सकते हैं?

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

@ocombe मुझे लगता है कि यह हम में से 2 से अधिक है।

हमें कोणीय टीमों से क्या चाहिए

• एक आवश्यकता सूची/कुछ विशिष्टता
• किसी न किसी जटिलता का अनुमान
• संचार के लिए 1-2 सलाहकार

उस समुदाय के साथ विकास को व्यवस्थित कर सकता है और कार्यों को विभाजित कर सकता है

https://hackmd.io/UfFN_wyVT-Ob1p70nA3N_Q?view पर मुझे इसकी जानकारी है

@fetis काम को बहुत अधिक विभाजित करना एक अच्छा विचार नहीं हो सकता है, संचार और संदर्भ साझा करने में भी भारी लागत आती है, खासकर कुछ मुख्य कार्यों के लिए संघर्ष की उच्च संभावना होती है।

अभी भी आश्चर्य है कि XLIFF को एक समर्थक के रूप में सूचीबद्ध किया गया है (या बल्कि, ngx-translate के लिए इसकी कमी एक चोर है)। ऐसा लगता है कि Google अनुवाद और अन्य Google सेवाएं ARB फ़ाइलों का उपयोग कर रही हैं, जो अनुवाद स्ट्रिंग्स का JSON प्रतिनिधित्व है। उदाहरण के लिए, हमने फ़्लटर/डार्ट के साथ अपने मोबाइल ऐप बनाए, जहां आईएनटीएल को एआरबी फाइलों के साथ कार्यान्वित किया जाता है। यह अच्छा होगा यदि एंगुलर टीम, इसे देखते हुए, Google पारिस्थितिकी तंत्र में अन्य वस्तुओं के साथ बेहतर इंटर-ऑप के लिए इसे ध्यान में रखे।

कार्य को बहुत अधिक विभाजित करना एक अच्छा विचार नहीं हो सकता है, संचार और संदर्भ साझाकरण में भी भारी लागत आती है, विशेष रूप से कुछ मुख्य कार्यों के लिए जिनमें संघर्ष की उच्च संभावना होती है।

मैं सहमत हूं लेकिन मुझे नहीं लगता कि यह पूरा एक व्यक्ति उचित समय में दे सकता है। दायरा बहुत बड़ा है

कार्य को बहुत अधिक विभाजित करना एक अच्छा विचार नहीं हो सकता है, संचार और संदर्भ साझाकरण में भी भारी लागत आती है, विशेष रूप से कुछ मुख्य कार्यों के लिए जिनमें संघर्ष की उच्च संभावना होती है।

मैं सहमत हूं लेकिन मुझे नहीं लगता कि यह पूरा एक व्यक्ति उचित समय में दे सकता है। दायरा बहुत बड़ा है

@fetis मैं आपके साथ काम कर सकता हूं। हम वास्तव में अपनी परियोजनाओं में कोणीय i18n का उपयोग करना चाहते हैं, लेकिन यह बहुत सीमित है।

मैं टीम को बता दूंगा कि आप दोनों की रुचि है ताकि हम देख सकें कि इसे कैसे व्यवस्थित किया जाए।

@ocombe कोणीय टीम से कोई प्रतिक्रिया?

मैंने उन्हें बता दिया है और वे रुचि रखते हैं, लेकिन बाहरी मदद स्वीकार करने से पहले उन्हें इन सभी के लिए एक ठोस योजना के साथ आने की जरूरत है (अन्यथा आप शायद उस पर काम नहीं करने जा रहे हैं जिसकी आवश्यकता है)।
@petebacondarwin अब से कार्यभार संभालेंगे

हाय @ocombe , मैं टिप्पणियों के माध्यम से जा रहा था और मैं मोटे तौर पर समझ गया था कि अभी भी i18n टैग के लिए डायनामिक आईडी बनाने का कोई प्रावधान नहीं है, जबकि हम उनका उपयोग *ngFor में करते हैं। क्या कोई अन्य विकल्प या समाधान है? या मुझे केवल एनजीएक्स-अनुवाद के साथ जाना है।

@swapnilvaidankar मुझे नहीं लगता कि कोई समाधान है, नहीं

@swapnilvaidankar - क्या आप इसका मतलब बता सकते हैं?

i18n टैग के लिए डायनामिक आईडी बनाएं जबकि हम उनका उपयोग *ngFor . में करते हैं

जैसा कि हम जानते हैं, किसी भी अन्य भाषा में स्थिर पाठ का अनुवाद करने के लिए हमें नीचे दिए गए HTML तत्व टैग में i18n विशेषता का उपयोग करना होगा,

<h1 i18n = "Card Header | Title for the under construction card@@constructionheader">Under Construction</h1>

जो नीचे के रूप में xlf फ़ाइल स्निपेट उत्पन्न करता है और हम किसी भी भाषा के लिए लक्ष्य निर्धारित कर सकते हैं। यहाँ मैंने नीचे के रूप में फ्रेंच के लिए अनुवाद किया है,

  <trans-unit id="constructionheader" datatype="html">
    <source>Under Construction</source>
    <target>En construction</target>
    <context-group purpose="location">
      <context context-type="sourcefile">src/app/app.component.html</context>
      <context context-type="linenumber">3</context>
    </context-group>
    <note priority="1" from="description"> Title for the under construction card</note>
    <note priority="1" from="meaning">Card Header </note>
  </trans-unit>

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

मैंने इस तरह से कोशिश की है,

• 
  {{ उत्पाद }}
  

जो नीचे के रूप में xlf फ़ाइल स्निपेट उत्पन्न करता है और यह सुनिश्चित नहीं करता है कि उत्पाद नाम का अन्य भाषाओं में अनुवाद करने के लिए इसका उपयोग कैसे किया जाएउपनाम

  <trans-unit id="product" datatype="html">
    <source><x id="INTERPOLATION" equiv-text="{{ product }}"/></source>
    <context-group purpose="location">
      <context context-type="sourcefile">src/app/product/product.component.html</context>
      <context context-type="linenumber">6</context>
    </context-group>
    <note priority="1" from="description"> product name from List</note>
    <note priority="1" from="meaning">product name </note>
  </trans-unit>

यहाँ समस्या, अगर आप आईडी देख सकते हैंटैग केवल 'उत्पाद' है। हालांकि मैं उम्मीद कर रहा था कि ड्रॉपडाउन सूची में उपलब्ध होने वाले उत्पादों की सूची के अनुसार आईडी को गतिशील रूप से उत्पन्न किया जाना चाहिए।

सुनिश्चित नहीं है कि गतिशील सामग्री या सामग्री की सूची के साथ काम करते समय इसे कैसे प्राप्त किया जाए।

विस्तृत स्पष्टीकरण के लिए खेद है।
मुझे आशा है कि आप यहाँ इस मुद्दे को समझ गए होंगे।

धन्यवाद,
स्वप्निल

क्या आप कृपया इसके लिए कोई मुद्दा खोल सकते हैं? यह वास्तव में यहाँ का विषय नहीं है और यदि कोई अन्य व्यक्ति उसी चीज़ की तलाश में है तो उसे खोजना आसान हो जाएगा

@swapnilvaidankar i18n विशेषताएँ स्थिर पाठ अनुवाद के लिए हैं न कि गतिशील सामग्री के लिए। आपके उदाहरण में "उत्पाद" या तो आपके स्रोत कोड से आ रहे हैं (आपकी टीएस फ़ाइल में परिभाषित हैं) और आपको एनजीएक्स-अनुवाद का उपयोग करने की आवश्यकता है (या सीधे टीएस फ़ाइल में उत्पाद नामों का अनुवाद किया है), या एक एचटीपी अनुरोध से आ रहे हैं तब अनुवादित उत्पाद नाम आपके बैकएंड द्वारा प्रदान किए जाने चाहिए।

मुझे नहीं लगता कि इसके लिए हमें किसी नए मुद्दे की जरूरत है। यह केवल TS फ़ाइलों में रन-टाइम अनुवाद के लिए अनुरोध है जिसे पहले ही कई बार अनुरोध किया जा चुका है।

@swapnilvaidankar यदि विकल्पों की संख्या सीमित है और आप इसे पहले से ही जानते हैं, तो आप सरल ngSwitch के साथ एक घटक बना सकते हैं जो पाठ को प्रस्तुत करता है। हम इस वर्कअराउंड का उपयोग करते हैं, एक आकर्षण की तरह काम करता है।

@fetis - परेशानी यह है कि इन सामान्य मुद्दों को विशिष्ट चीजों के बारे में चर्चा में साइड-ट्रैक करना बहुत आसान है। एक नया मुद्दा बनाना इस चर्चा को विचलित किए बिना उस चर्चा को जारी रखने के लिए एक नया सूत्र प्रदान करता है।

@fetis हाँ, इस मुद्दे को मैंने कई बार कई जगहों पर देखा है लेकिन मुझे कोई उचित समाधान नहीं मिला। मैं ngSwitch में भी आया लेकिन मेरे मामले में उपयुक्त समाधान नहीं था। हालांकि कामकाज के लिए धन्यवाद।

@ocombe मेरा मानना ​​​​है कि मुझे इसे किसी ऐसे मुद्दे के रूप में पोस्ट करने की ज़रूरत है जहां कहीं और चर्चा की जाए। मैं

आप सभी की प्रतिक्रियाओं के लिए धन्यवाद।

@petebacondarwin @swapnilvaidankar यहाँ मुद्दा है https://github.com/angular/angular/issues/11405 जिसे आप ढूंढ रहे हैं
चूंकि 2.0.0-rc.6 (!) btw

हैलो @ocombe , क्या यह समस्या अभी भी अप टू डेट है? ऐसा लगता है कि आइवी एंगुलर 9 पर डिफ़ॉल्ट होने जा रहा है, इसलिए मुझे आश्चर्य है कि i18n की स्थिति क्या है? क्या आप कृपया अनुमान लगा सकते हैं कि यह कब उत्पादन के लिए तैयार हो सकता है? कोणीय 9, 10, 11 के साथ? यदि एंगुलर 9 के साथ नहीं, तो क्या एंगुलर 9 (और आइवी) बिना i18n के शिप करेगा या यह पुराने i18n का उपयोग करेगा?

वर्तमान स्थिति के बारे में कुछ और जानकारी इस (https://github.com/angular/angular/issues/11405) अंक में मिल सकती है। वर्तमान स्थिति के बारे में इस अंक में पढ़ने लायक टिप्पणियाँ:

• https://github.com/angular/angular/issues/16477#issuecomment -512290696
• https://github.com/angular/angular/issues/16477#issuecomment -506378004
• https://github.com/angular/angular/issues/16477#issuecomment -512548506

इसके अलावा यह जाँच के लायक है।

हालाँकि हम v9 में स्विच को फ़्लिप कर रहे हैं ताकि डिफ़ॉल्ट आइवी का उपयोग करने के लिए है, हम उम्मीद करते हैं कि ऐसे कई परिदृश्य हो सकते हैं जो पूरी तरह से काम नहीं कर रहे हैं, और यह कि वे प्रोजेक्ट अभी के लिए व्यू-इंजन के साथ रहेंगे।
हम i18n को ऊपर लाने और v9.0.0 रिलीज के लिए चलने के लिए काम कर रहे हैं लेकिन यह कड़ा होगा।

"रनटाइम i18n (सभी स्थानों के लिए एक बंडल)" पर वर्तमान स्थिति क्या है?

@Ivajkin - खेद है कि इस मुद्दे को अद्यतित नहीं रखा जा रहा है।

"रनटाइम i18n" आमतौर पर मांगा जाने वाला फीचर है, लेकिन इसका मतलब अलग-अलग लोगों के लिए अलग-अलग चीजें हो सकता है।
नए i18n $localize दृष्टिकोण में, रनटाइम पर वास्तविक अनुवाद करना संभव होगा।

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

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

यह सब v9.0.0 के लिए काम करता है।

हम कहां हैं यह देखने के लिए https://github.com/angular/angular/tree/master/packages/localize देखें।

@petebacondarwin क्या आप नए संकलन समय अनुवाद पर थोड़ा विस्तार से विचार करेंगे? क्या यह हमें एक एकल बंडल (एओटी के साथ) बनाने की अनुमति देगा जो सभी स्थानों के लिए काम करता है?

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

अब हमारे पास कुछ विकल्प हैं:

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

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

रनटाइम विकल्प बी) कृपया। हम अनुवादों को JSON फ़ाइलों के रूप में लोड कर सकते हैं और रनटाइम पर भाषाओं को स्विच कर सकते हैं जैसा कि हम वर्तमान में ngx-translate के साथ करते हैं।

स्पष्टीकरण के लिए धन्यवाद। मैं समझता हूं कि ए) दृष्टिकोण अधिक "कोणीय" है, लेकिन बी) दृष्टिकोण (और सामान्य रूप से आलसी लोडिंग) का महान लाभ उपयोगकर्ताओं द्वारा अनुवादों को गतिशील रूप से परिभाषित/बदलने की क्षमता भी है (ऐप्स के लिए संशोधित अनुवाद तुरंत उपयोग किए जा सकते हैं) . अगर मैं इसे सही ढंग से समझता हूं, तो दृष्टिकोण में अनुवाद में कोई छोटा बदलाव a) का मतलब एक नया पुनर्निर्माण होगा।

यह वही लाभ है जो पूर्वनिर्धारित कोणीय घटकों के साथ स्थिर रूप से जेनरेट किए गए पृष्ठों से उपयोगकर्ता द्वारा जेनरेट किए गए टेम्पलेट्स में स्विच के रूप में उपयोगकर्ता द्वारा वांछित प्रोग्रामर द्वारा परिभाषित कोणीय घटक होते हैं (इस तरह से परिभाषित टेम्पलेट डेटाबेस से भी लोड किया जाएगा ... )

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

आपके द्वारा सूचीबद्ध विकल्पों के लिए, मैं कुछ मामलों में ऐसी गतिशील कार्यक्षमता प्राप्त करने के लिए लगभग 25% एप्लिकेशन प्रदर्शन का त्याग करने को तैयार हूं (बेशक मैं हर जगह इस गतिशील दृष्टिकोण का उपयोग नहीं करूंगा)। इसलिए यदि एओटी स्थानीयकृत टेम्पलेट 0.4 ​​सेकंड में प्रस्तुत किया गया था, तो गतिशील टेम्पलेट के मामले में यदि इसे 0.5 सेकंड में उत्पन्न किया गया था, तो भी मैं इसे उन ऐप्स में स्वीकार्य मानूंगा जहां मुझे अनुवाद परिवर्तन के लिए तत्काल प्रतिक्रियाओं की आवश्यकता है।

@demisx दोनों दृष्टिकोण v9 के साथ उपलब्ध होंगे, लेकिन केवल विकल्प a) पहले पूरी तरह से समर्थित होगा (retrocompatibility के लिए), विकल्प b के लिए नई चीजें विकसित की जा सकती हैं) इससे पहले कि यह कोणीय टीम द्वारा पूरी तरह से समर्थन किया जाए।
मेरी लाइब्रेरी Locl विकल्प b के लिए कुछ सहायक प्रदान करेगी) जब v9 जारी किया जाता है ताकि कोई भी इसका उपयोग कर सके, जब तक कि कोणीय टीम उस अंतर को पाट न दे

ध्यान रखें कि इस तरह के रनटाइम अनुवाद इस अर्थ में "प्रतिक्रियाशील" नहीं होंगे कि एक बार एक घटक को प्रस्तुत करने के बाद उसके पाठ को गतिशील रूप से बदलना संभव नहीं होगा, भले ही एक नया अनुवाद लोड किया गया हो।

$localize टैग की गई स्ट्रिंग के संबंध में अनुवादित संदेश स्थिर होते हैं। तो घटक को फिर से प्रस्तुत करने की आवश्यकता होगी। और आईवीवाई में टेम्पलेट्स के कैशिंग के आधार पर यह हो सकता है कि एक पुन: प्रतिपादन भी पर्याप्त नहीं है।

यह एक कारण है कि रनटाइम अनुवाद को लागू करना मुश्किल है क्योंकि इसका व्यवहार आवश्यक रूप से सहज नहीं होगा।

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

कोणीय 9 RC1 रिटर्न पर ng xi18n चल रहा है "हमें खेद है लेकिन i18n अभी तक आइवी में लागू नहीं किया गया है", लेकिन चैंज इंगित करता है कि अब _some_ i18n समर्थन लागू किया गया है। मुझे लगता है कि अनुवाद फ़ाइलों को अभी के लिए मैन्युअल रूप से अपडेट करने की आवश्यकता है?

@neil-119 वर्तमान में निष्कर्षण आइवी-मोड में समर्थित नहीं है। निष्कर्षण चलाने के लिए आपको अभी भी आइवी को अक्षम करना होगा। लेकिन फिर आप निकाले गए अनुवाद फ़ाइलों का उपभोग करने के लिए इसे फिर से सक्षम कर सकते हैं।

मुझे उम्मीद है कि अंतिम v9 रिलीज में निष्कर्षण को शामिल करने की योजना है।

@ neil-119 कोणीय सीएलआई को स्वचालित रूप से निष्कर्षण के लिए वीई का उपयोग करना चाहिए। काम करने के लिए आपको कुछ भी करने की ज़रूरत नहीं है। हम इसका परीक्षण भी करते हैं इसलिए मुझे आश्चर्य है कि यह टूटा हुआ है। क्या आप कृपया रेपो के साथ कोई समस्या खोल सकते हैं?

वर्तमान में निष्कर्षण आइवी-मोड में समर्थित नहीं है।

या नहीं, यह एक शो स्टॉपर है। वर्तमान में, हमारे पास स्ट्रिंग निष्कर्षण के साथ एक स्वचालित प्रक्रिया है। अगर हम स्वचालित रूप से अनुवाद नहीं निकाल सकते हैं, तो हम आइवी में कैसे माइग्रेट कर सकते हैं?
sconfig.json every time हेरफेर करें? यह मुझे अच्छा नहीं लगता।

@fetis - मैं गलत था। यदि आप सीएलआई का उपयोग कर रहे हैं तो ng xi18n पर कॉल करना अपेक्षित रूप से काम करना चाहिए, भले ही आइवी सक्षम हो।

@petebacondarwin धन्यवाद। मैं अपनी वर्तमान परियोजनाओं में आइवी को आज़माने जा रहा हूँ, इसलिए आशा है कि मैं जल्द ही इसकी पुष्टि करूँगा

हैलो, मैंने अपने घटक (कोणीय 9.0.0-आरसी.1) में उपयोग करने की कोशिश की

$localize `some string to localize`;

@ कोणीय/स्थानीयकरण/इनिट के स्रोत कोड में डॉक्टर के रूप में पाया गया।

जब मैं अपनी भाषा के लिए हमेशा की तरह निर्माण करने की कोशिश करता हूं तो मुझे यह त्रुटि मिलती है
No translation found for "4145296873012977836" ("some string to localize").

मैं उस स्ट्रिंग के लिए अनुवाद कैसे प्रदान कर सकता हूं?
मैं जो उम्मीद करता हूं वह यह है कि ng xi18n घटक कोड से इस पाठ के साथ .xlf फ़ाइल भी उत्पन्न करेगा। क्या यह सही है या मुझे कुछ याद आ रहा है?

हाय @ Ks89 - एप्लिकेशन कोड (टेम्पलेट्स के बजाय) से संदेश निकालना v9 के लिए समर्थित नहीं है।
लेकिन अगर आप डरपोक हैं तो आप इससे निजात पा सकते हैं। 4145296873012977836 संदेश की आईडी है, इसलिए यदि आप इस आईडी के साथ अपनी अनुवाद फ़ाइल में अनुवाद प्रदान करते हैं तो इसका उपयोग अनुवाद करते समय किया जाएगा।

@petebacondarwin कब यह फीचर एंगुलर में जोड़ा जाएगा?
मुझे लगता है कि घटक में रनटाइम अनुवादों को वास्तव में उपयोगी बनाना वास्तव में महत्वपूर्ण है।

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

जवाब के लिए धन्यवाद

मैं 9.1 . में इसकी उम्मीद करूंगा

यदि हमारे पास पूरे ऐप को फिर से प्रस्तुत करने के लिए बाध्य करने का कोई तरीका है, चाहे प्रत्येक घटक के लिए ChangeDetectionStrategy कुछ भी हो, तो उन गतिशील मुद्दों को हल करना इतना आसान है।

@petebacondarwin Angular 9 अब नए $localize टैग फ़ंक्शन के साथ जारी किया गया है, लेकिन संदेशों को निकाले बिना। आपने इससे पहले कहा था कि हम एंगुलर 9.1 में इसकी उम्मीद कर सकते हैं। क्या यह पूर्वानुमान अभी भी मान्य है, और क्या हम $localize API के स्थिर रहने की उम्मीद कर सकते हैं?

आप टेम्प्लेट से अनुवाद निकाल सकते हैं।
यदि आप अपने कोड में भी $localize का उपयोग करना चाहते हैं, तो आपको Locl पर एक नज़र डालनी चाहिए: https://github.com/loclapp/locl/
@locl/cli आपको कोड और टेम्प्लेट से निकालने देगा

@vekunz - पूर्वानुमान अभी भी मान्य है। इसके अलावा, जैसा कि @ocombe बताते हैं, वर्तमान सीएलआई अनुवाद निष्कर्षण तंत्र किसी भी अनुवाद के लिए ठीक काम करता है जो एक कोणीय टेम्पलेट के भीतर है (यानी सामान जो i18n टैग द्वारा चिह्नित है)। केवल एक चीज जिसे आप अभी कोर टूल्स का उपयोग करके निकालने में सक्षम नहीं हैं, वह है आपके अपने कोड के भीतर $localize पर कॉल करना (उदाहरण के लिए किसी सेवा या घटक में)।

$localize कॉल अपने आप में एक स्थिर API है।

टूलींग जो अनुवाद और निष्कर्षण (विशेष रूप से संकलन समय पर) करता है वह अभी भी गैर-सार्वजनिक है। लेकिन यह तब तक चिंता का विषय नहीं है जब तक कि आप इसके चारों ओर अपना टूलिंग बनाने की योजना नहीं बना रहे हों (जैसे @ocombe Locl पर कर रहा है!)

धन्यवाद @petebacondarwin , इसके साथ, हम कोड से पाठ को निष्कर्षण के लिए "छिपे हुए" घटक टेम्पलेट में डुप्लिकेट कर सकते हैं। फिर निष्कर्षण और अनुवाद दोनों काम करना चाहिए, है ना?

@ocombe इस पूर्वानुमान के साथ कि निष्कर्षण कोणीय 9.1 के साथ काम करता है, हमारा प्रबंधक आपके समाधान के लिए भुगतान नहीं करेगा। विशेष रूप से इसलिए क्योंकि हमें भाषाओं और अनुवादित मार्गों के लाइव स्विचिंग की आवश्यकता नहीं है।

हम कोड से ग्रंथों को निष्कर्षण के लिए "छिपे हुए" घटक टेम्पलेट में डुप्लिकेट कर सकते हैं

हाँ वास्तव में, यह समाधान अभी के लिए काम करेगा।

मैं उलझन में हूं: क्या 9.1 में रनटाइम अनुवाद भी संभव होगा? या सिर्फ टेम्पलेट्स के बाहर निकालने? या इनमें से कोई नहीं?

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

@JustDoItSascha
मैंने एक साधारण डेमो बनाया है, जो रनटाइम अनुवाद प्रदर्शित करता है।
https://stackblitz.com/edit/ivy-vjqzd9?file=src%2Fapp%2Fapp.component.ts

नमस्ते! मैं main.ts में loadTranslations को कॉल करने का प्रयास कर रहा हूं क्योंकि जावास्क्रिप्ट पार्स आयात करते समय स्ट्रिंग्स का अनुवाद किया जाता है, लेकिन यह पर्याप्त नहीं है।

main.ts AppModule आयात करता है जो AppComponent आयात करता है (जहां मैं $localize का उपयोग कर रहा हूं)।

इसे काम करने के लिए मैं कर रहा हूँ:

loadTranslations(......);
import('./app/app.module').then(m => platformBrowserDynamic(). bootstrapModule(m.AppModule);

अब यह काम करता है लेकिन कोणीय के "complier.js" बंडल को विक्रेता बंडल में शामिल करने का कारण बनता है।

इससे बचने का कोई उपाय? धन्यवाद

वर्तमान में, आवेदन शुरू होने से पहले loadTranslations को कॉल करने की आवश्यकता है, इसलिए इसे polyfills.ts में किया जा सकता है। और यदि आप अनुवादों के अन्य सेट को लोड करना चाहते हैं, तो आपको पृष्ठ को फिर से लोड करना होगा। यदि आप थोड़ा और समझना चाहते हैं, तो मैंने इसे समझाने के लिए https://blog.ninja-squad.com/2019/12/10/angular-localize/ लिखा।

वर्तमान में, आवेदन शुरू होने से पहले loadTranslations को कॉल करने की आवश्यकता है, इसलिए इसे polyfills.ts में किया जा सकता है।

यह उससे भी बदतर है, किसी भी मॉड्यूल फ़ाइल को आयात करने से पहले इसे कॉल करने की आवश्यकता होती है, यही कारण है कि यदि आप इसे polyfills.ts (जिसे मुख्य ऐप फ़ाइल से पहले निष्पादित किया जाता है) में डालते हैं तो यह काम करता है, लेकिन यदि आप इसे अपने में उपयोग करना चाहते हैं "मुख्य" फ़ाइल तो आपको मॉड्यूल के लिए एक गतिशील import(...) का उपयोग करने की आवश्यकता है

@vekunz यह अभी के लिए मेरे काम का उपयोग नहीं करने का एक अच्छा कारण है कहा जा रहा है कि Locl केवल निष्कर्षण के बारे में नहीं है, मैं i18n को सरल बनाने के लिए कई अन्य टूल जोड़ने का इरादा रखता हूं

क्या एंगुलर में रनटाइम i18n को लागू करने का कोई इरादा है? हम लगभग तीन वर्षों से इस सुविधा की उम्मीद कर रहे हैं और अब आइवी यहाँ है और यह अभी भी केवल आधा-बेक्ड है।

क्या एंगुलर में रनटाइम i18n को लागू करने का कोई इरादा है? हम लगभग तीन वर्षों से इस सुविधा की उम्मीद कर रहे हैं और अब आइवी यहाँ है और यह अभी भी केवल आधा-बेक्ड है।

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

@ करसुनी - मुझे लगता है कि हमें यह स्पष्ट करने की आवश्यकता है कि कोर कोणीय ढांचे के लिए वास्तव में रनटाइम अनुवाद का क्या अर्थ है क्योंकि इसके बारे में काफी भ्रम है।

हमने v9 के लिए जो बदलाव किए हैं उनमें $localize आधारित अनुवाद शामिल है। इसका प्राथमिक उद्देश्य एंगुलर कंपाइलर से अनुवाद को अलग करना था, ताकि यह कई अच्छे सुधारों को सक्षम करे:

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

दूसरे, चूंकि $localize टैग वितरित कोड में छोड़े जा सकते हैं, अब ब्राउज़र में अनुवाद करना भी संभव है (संकलन समय के बजाय रनटाइम पर)। रनटाइम ट्रांसलेशन के रूप में कोर एंगुलर फ्रेमवर्क में हमारा यही मतलब है। लेकिन कृपया ऐसा न करें कि इसका अंतिम परिणाम प्रभावी रूप से संकलन समय पर अनुवाद के समान है। अनुवाद केवल एक बार होता है; यदि आप रनटाइम पर भाषा बदलना चाहते हैं तो आपको पूरे एप्लिकेशन को पुनरारंभ करना होगा (उदाहरण के लिए पुनः लोड के माध्यम से)। यह परियोजना को कई अनुवाद फ़ाइलों के साथ एक वितरण योग्य को तैनात करने की अनुमति देने का लाभ है, जो कम संख्या में उपयोग के मामलों में सहायक होता है जहां आप सभी अलग-अलग अनुवादों को सामने नहीं बनाना चाहते हैं। जैसा कि @ocombe और अन्य यहाँ इंगित किया गया है, अनुवादों को जल्दी लोड करने में कुछ मुश्किल मुद्दे हैं। ऐसा करने में अधिक सहायता के लिए आप https://www.locl.app/ पर विचार कर सकते हैं।

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

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

अंत में, ध्यान दें कि रनटाइम पर अनुवादित स्ट्रिंग्स का गतिशील परिवर्तन विशेष रूप से कोर एंगुलर फ्रेमवर्क द्वारा समर्थित नहीं है (डिजाइन द्वारा)। एंगुलर के चेंज डिटेक्शन सिस्टम में अनुवादित स्ट्रिंग्स को जोड़ने से अधिकांश अनुप्रयोगों पर बहुत अधिक दबाव पड़ेगा और प्रदर्शन खराब हो जाएगा। समुदाय के साथ अपनी बातचीत से मैंने शायद ही कोई वास्तविक दुनिया का परिदृश्य देखा हो जहां भाषा परिवर्तन पर एप्लिकेशन को फिर से शुरू करने के लिए वास्तव में इसकी आवश्यकता हो। यदि यह आपके आवेदन के लिए एक आवश्यकता है तो आप अनुवाद में खींचने वाले टेम्पलेट्स में अपने तारों पर एक कस्टम निर्मित पाइप का उपयोग करके इसे प्राप्त कर सकते हैं, और यहां तक ​​​​कि अनुवाद करने के लिए फ्लाई पर $localize भी कॉल कर सकते हैं लेकिन ऐसा नहीं दिखता है यह बहुत प्रदर्शनकारी होगा। अन्यथा आप https://netbasal.gitbook.io/transloco/ जैसे अधिक गतिशील दृष्टिकोण पर विचार कर सकते हैं।

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

रनटाइम अनुवाद को बेहतर बनाने के लिए किए गए बदलाव, जैसा कि ऊपर बताया गया है, 9.1 के बाद जल्द से जल्द दिखाई नहीं देंगे।

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

मुझसे गलती हो सकती है, लेकिन अकेले इस धागे में कई लोगों ने एप्लिकेशन को पुनर्निर्माण या पुनः लोड किए बिना, रनटाइम पर, भाषा को लाइव बदलने की क्षमता में स्पष्ट रूप से रुचि दिखाई। या क्या यहां सभी की अलग-अलग परिभाषा है runtime translation ?

मैं केवल एक भाषा बदलने के लिए किसी एप्लिकेशन को फिर से लोड नहीं करना चाहता। उदाहरण के लिए जब कोई उपयोगकर्ता किसी प्रपत्र वाले पृष्ठ पर होता है तो अनुवाद में स्विच के लिए एक पूर्ण पृष्ठ पुनः लोड उपयोगकर्ता को परेशान करेगा।

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

प्रश्न: आपके ऐप पर किसी विशेष फॉर्म पर जाने पर उपयोगकर्ता को भाषाओं को स्विच करने की आवश्यकता क्यों होगी?

मुझे नहीं लगता कि लाइव स्विचिंग भी जरूरी है। आप कितनी बार किसी वेबसाइट की भाषा बदलते हैं? आमतौर पर एक बार, अधिकतम। और इस एक बार के लिए, एक पृष्ठ पुनः लोड करना उतना महत्वपूर्ण नहीं है। जैसा कि @petebacondarwin ने कहा, लाइव स्विचिंग के लिए लगभग सभी परिदृश्य प्रासंगिक वास्तविक दुनिया के परिदृश्य नहीं हैं, बल्कि केवल "अच्छा है।"

या क्या यहां हर किसी के पास रनटाइम अनुवाद की एक अलग परिभाषा है?

मुझे बिल्कुल रनटाइम अनुवाद चाहिए। हमारे ग्राहकों को केवल बिल्ड सर्वर पर ही नहीं, बल्कि क्षेत्र में अनुवादों को संपादित और अपडेट करने में सक्षम होना चाहिए। तो, रनटाइम, संकलन समय के विपरीत।

पेज लोड होने के बाद भाषाओं का वास्तविक स्विचिंग एक अच्छा काम है।

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

प्रश्न: आपके ऐप पर किसी विशेष फॉर्म पर जाने पर उपयोगकर्ता को भाषाओं को स्विच करने की आवश्यकता क्यों होगी?

आप सही हो सकते हैं कि यह एक ठोस आवश्यकता नहीं है। मैं लोड पर अनुवादों को तैनात करने का प्रयास कर सकता हूं लेकिन यह उन अनुप्रयोगों के उपयोगकर्ता अनुभव को पूरी तरह से बदल देगा जो वर्तमान में भाषा को गतिशील रूप से स्विच करने में सक्षम हैं - पृष्ठ में पुनः लोड या स्थिति बदलने के बिना - बाहरी पुस्तकालय के साथ। अनुवाद बहुत लंबे समय से एक गर्म विषय रहा है।

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

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

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

आप सही हो सकते हैं कि यह एक ठोस आवश्यकता नहीं है। मैं लोड पर अनुवादों को तैनात करने का प्रयास कर सकता हूं लेकिन यह उन अनुप्रयोगों के उपयोगकर्ता अनुभव को पूरी तरह से बदल देगा जो वर्तमान में भाषा को गतिशील रूप से स्विच करने में सक्षम हैं - पृष्ठ में पुनः लोड या स्थिति बदलने के बिना - बाहरी पुस्तकालय के साथ। अनुवाद बहुत लंबे समय से एक गर्म विषय रहा है।

तकनीकी रूप से आप पूरे ऐप को फिर से लोड कर सकते हैं और फिर भी उपयोगकर्ता को वहीं रख सकते हैं जहां वह था।
आपको "बस" के लिए एक राज्य-संचालित ऐप (एनजीएक्स, एनजीआरएक्स, या किसी अन्य राज्य प्रबंधन पुस्तकालय के साथ) की आवश्यकता होती है, जिसे कहीं संग्रहीत किया जाता है और स्टार्टअप पर पुनर्प्राप्त किया जाता है।

स्क्रॉल स्थिति को बनाए रखने के लिए एकमात्र चाल होगी लेकिन यह भी व्यवहार्य है।

@petebacondarwin मुझे कहना है कि मैं आपसे सहमत हूं। मैं वास्तविक अंतिम-उपयोगकर्ताओं (देव चरण में परीक्षकों को छोड़कर) को नहीं जानता, जो किसी ऐप का उपयोग करते समय भाषाओं के बीच स्थायी रूप से स्विच कर रहे हैं। ज़रूर, वे शायद शुरुआत में ऐसा करते हैं यदि वे इसे किसी अन्य तरीके से खोलते हैं, लेकिन बाद में, यह एक दुर्लभ मामला है।

या क्या यहां हर किसी के पास रनटाइम अनुवाद की एक अलग परिभाषा है?

मुझे बिल्कुल रनटाइम अनुवाद चाहिए। हमारे ग्राहकों को केवल बिल्ड सर्वर पर ही नहीं, बल्कि क्षेत्र में अनुवादों को संपादित और अपडेट करने में सक्षम होना चाहिए। तो, रनटाइम, संकलन समय के विपरीत।

पेज लोड होने के बाद भाषाओं का वास्तविक स्विचिंग एक अच्छा काम है।

मुझे यकीन नहीं है कि आपके ग्राहक क्या कर रहे हैं, लेकिन "अनुवादों का संपादन प्रोडक्शन वेबसाइट में लाइव है" एक सामान्य परिदृश्य की तरह नहीं लगता है।

मुझे इस तरह के डील ब्रेकर होने के लिए भाषा को लाइव (_बिना पेज रीलोड_ के) बदलते हुए नहीं दिख रहा है।
किसी उपयोगकर्ता के लिए भाषा बदलना केवल एक बार होता है;

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

पृष्ठ पुनः लोड किए बिना लाइव परिवर्तन करने के लिए भाषा परिवर्तन देखने के लिए उपयोगकर्ता के जीवनकाल के लिए मुश्किल से उपयोग की जाने वाली किसी चीज़ के लिए बहुत अधिक प्रदर्शन जुर्माना लगता है।

अंत में, मेरे लिए 3 चीजें नीचे आती हैं;

1. टेम्प्लेट और TS फ़ाइलों से अनुवाद निकालें।
   
   
   
   • स्रोत लैंग एसेट अपडेट करें.
   
   
   • अनुवाद को भी अपडेट करें (_अगर मेरे पास कई भाषाएं हैं, fr, en, de... मैं चाहता हूं कि उन सभी को नई अनुवाद कुंजियों के साथ अपडेट किया जाए और हटा दी गई हों।_)
   
   
2. सभी अनुवादों के लिए एक बिल्ड (_प्रत्येक अनुवाद के लिए 1 बिल्ड होना भी ठीक है, जब तक कि यह बिल्ड समय को कई गुना न कर दे।_)
3. उपलब्ध भाषाएँ प्राप्त करना और भाषा को पुनः लोड करके बदलना।

@करसुनी
आप अनुवाद एसिंक्स प्राप्त कर सकते हैं और उसके बाद ही कोणीय ऐप लोड कर सकते हैं।
import(...) का उपयोग करके ऐप.मॉड्यूल एसिंक्रोनस को लोड करने के तरीके पर ऊपर मेरी टिप्पणी देखें।

व्यक्तिगत रूप से मैं विकिपीडिया का उपयोग यह पता लगाने के लिए करता हूं कि मुझे पता है कि एक फिल्म का शीर्षक किसी अन्य भाषा में "अनुवादित" किया गया था।

इस दिन और उम्र द्विभाषी या त्रिभाषी होना सामान्य से अधिक है (अमेरिका के भीतर से अलग, कोई नुकसान नहीं है)।

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

यहां तक ​​​​कि ocombe का ngx-translate जो आप लोगों के लिए "खराब प्रदर्शन अनुवाद" के समान उदाहरण होना चाहिए, रोजमर्रा के उपयोगकर्ता के लिए पूरी तरह से तेजी से चला।

मैं व्यक्तिगत रूप से त्रिभाषी हूं और मैं एक भाषा का उपयोग करने पर समझौता नहीं कर सकता: सभी भाषाएं मेरे लिए सुंदर हैं

उस सब के साथ जो मैंने कहा कि मैं इससे सहमत नहीं हो सकता:

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

विकिपीडिया इसका सबसे खराब उदाहरण है क्योंकि किसी लेख की विभिन्न भाषाएँ वास्तव में स्वतंत्र लेख हैं। आम तौर पर आपको एक ही साइट की विभिन्न भाषाओं की आवश्यकता नहीं होती है। भले ही आप चतुर्भुज काम करते हों।
और अगर आपको वास्तव में लाइव स्विचिंग की आवश्यकता है, तो आप कस्टम ट्रांसलेशन पाइप के साथ वर्कअराउंड का उपयोग कर सकते हैं, जिसका @petebacondarwin ने उल्लेख किया है या @ocombe का नया टूल।

ठीक है, इसलिए मुझे नहीं लगता कि यह चर्चा करने के लिए वास्तव में सबसे अच्छी जगह है। मुझे चिंता है कि (जबकि अब तक सभी बहुत ही उचित रहे हैं) हम नकारात्मक चर्चा में फिसल सकते हैं। मुझे डर है कि निकट भविष्य के लिए कोणीय ढांचा बॉक्स से बाहर एक लाइव भाषा स्विचिंग समाधान प्रदान नहीं करेगा।

मुझे लगता है कि इस मुद्दे के मूल्य ने अपना पाठ्यक्रम चलाया है। मैंने इस मुद्दे के विवरण में जुड़े खुले मुद्दों और पीआर को https://github.com/angular/angular/milestone/101 पर स्थानांतरित कर दिया है और मैं इस पीआर को बंद और लॉक करने जा रहा हूं।

यदि आपके पास फीचर अनुरोधों के नए मुद्दे हैं तो कृपया एक नया मुद्दा खोलें और मुझे इसमें टैग करें।