🏘️ 🌆 🌿 अनंत स्थानीयकरण, या हम वास्तविक समय में मानचित्र का अनुवाद कैसे करते हैं 🔱 🍰 🚧

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

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

अरबी के बारे में

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

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

फिजी

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

मामले

टीम में हम विशिष्ट शब्दावली का उपयोग करते हैं। नीचे चार उदाहरण हैं ↓
प्रणाली दो प्रकार की भाषाओं के साथ काम करने का समर्थन करती है:

मेटाडेटा भाषा - वह भाषा जिसमें सभी उपयोगकर्ता नियंत्रण प्रदर्शित होते हैं: UI, मेटाडेटा।

डेटा भाषा - एक भाषा जिसमें भू-वस्तुओं की विशेषताओं के मूल्य, कुछ निर्देशिकाएं और क्लासिफायर प्रदर्शित होते हैं।

भाषाएँ प्रदेशों से बंधी हैं। एक क्षेत्र में दो प्रकार की भाषाएं हो सकती हैं:

क्षेत्र की मुख्य भाषा उस क्षेत्र में आधिकारिक तौर पर अपनाई जाने वाली भाषा है।

क्षेत्र की अतिरिक्त भाषा वह भाषा है जिसमें हम उत्पाद जारी करना चाहते हैं। यह मुख्य के अलावा आता है।

भाषाएँ और बोलियाँ

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

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

प्रदेशों के लिए स्नैप

हमारी पूरी दुनिया कुछ क्षेत्रों में विभाजित है - ये देश, क्षेत्र, क्षेत्र हो सकते हैं। प्रत्येक क्षेत्र के लिए हम कई भाषाओं को निर्दिष्ट करते हैं, जिनमें से एक को मुख्य माना जाता है, और बाकी - अतिरिक्त। अनुवाद प्राथमिक भाषा से अतिरिक्त भाषाओं में होता है।

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

भाषा दर्ज करें और बदलें

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

इस तस्वीर में आप देख सकते हैं कि हमने भाषाओं को टैब में विभाजित कर दिया है, जहां बाईं ओर मुख्य भाषा है, और फिर अतिरिक्त हैं।

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

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

क्राउडिन, या स्ट्रीम ट्रांसफर

इसलिए, हमने अपने कार्टोग्राफर को विभिन्न भाषाओं में डेटा भरने में सक्षम बनाया है। लेकिन अनुवाद कार्य को पेशेवरों को सौंपना बहुत बेहतर है।

एप्लिकेशन ट्रांसलेट करते समय पहली बात जो ध्यान में आती है, वह है ट्रांसलेटर्स को रिसोर्स फाइल्स देना और उन्हें डाउनलोड करने के बाद ट्रांसफर करना।

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

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

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

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

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

सामग्री को जल्दी से अपडेट करने के लिए, हमने एक छोटी सेवा लिखी जो तीन धाराओं में काम करती है।

पहली स्ट्रीम (सेवर) उन सभी डेटा को निकालती है जिनके लिए अनुवाद की आवश्यकता होती है, और उनसे xml फाइलें उत्पन्न करता है।

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

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

बिना रेक के नहीं चल सकता था। हम अपने डेटा संस्करण प्रणाली पर ठोकर खाई।
जब हमने शब्द का अनुवाद डाउनलोड किया, तो डेटा का संस्करण अपडेट किया गया और शब्द फिर से अनुवाद में गिर गया।

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

ट्यूटोरियल

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

क्राउडइन में काफी विस्तृत ट्यूटोरियल है , लेकिन नीचे मैं लिखूंगा कि हमने यह कैसे किया।

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

यह कुंजी आपके प्रत्येक प्लेटफ़ॉर्म अनुरोध के अंत में जोड़ी जानी चाहिए। उदाहरण के लिए, इस तरह:
GET: https://api.crowdin.com/api/project/{myLitleProject}/download/all.zip?key={project-key} आईडीproproject- https://api.crowdin.com/api/project/{myLitleProject}/download/all.zip?key={project-key}

2. एक फ़ोल्डर बनाएं जहां हम परियोजना के अंदर फाइलें अपलोड करेंगे।

 var uri = $"project/{_projectName}/add-directory?key={apiKey}"; var content = new MultipartFormDataContent { { new StringContent(crowdInDirectoryPath), "name" } }; return PostAsync(uri, content);

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

3. निर्यात फ़ाइलें। ऐड-फ़ाइल फ़ंक्शन में बहुत सारे विकल्प और पैरामीटर हैं, कैसे और कहां पढ़ें। नीचे एक उदाहरण है कि हम xml फ़ाइलों के साथ डेटा कैसे लोड करते हैं।

उदाहरण

हम सभी डेटा डालते हैं जिसे हम निम्नलिखित संरचना के साथ xml फ़ाइलों में अनुवाद करने जा रहे हैं।

 <LocalizableDocument> <LocalizableValues> <LocalizableValue> … <Attributes> <LocalizableAttributeValue> <AttributeName/> <Value/> </LocalizableAttributeValue> </Attributes> </LocalizableValue> </LocalizableValues> </LocalizableDocument>

क्राउडइन को पार्स करने के लिए फ़ाइल से कौन से डेटा का अनुवाद करना है, इसे निर्दिष्ट करने की आवश्यकता है। ऐसा करने के लिए, आपको सामग्री में दस्तावेज़ के आवश्यक तत्वों के लिए पथों के साथ Translatable_elements पैरामीटर की एक सरणी लिखने की आवश्यकता है। हमारे मामले में, यह इस तरह दिखता था:

 var uri = $"project/{_projectName}/add-file?key={apiKey}"; var content = new MultipartFormDataContent { { new StringContent("/LocalizableDocument/LocalizableValues/LocalizableValue/Attributes/LocalizableAttributeValue/Value"), "translatable_elements[0]" } }; foreach (var filePath in filePaths) { var fileName = Path.GetFileName(filePath); var fileStream = File.OpenRead(filePath); var fileContent = new StreamContent(fileStream); content.Add(fileContent, $"files[{_crowdInDirectoryPath}/{fileName}]", fileName); } return PostAsync(uri, content);

कृपया ध्यान दें: प्रलेखन में कहा गया है कि क्राउडइन एक समय में अधिकतम 20 फाइलें चबा सकता है, जबकि एक फाइल का आकार 100 एमबी नहीं होना चाहिए।

4. हमें पता चलता है कि हमने किन फाइलों का पूरी तरह से अनुवाद किया है। हम एक विशिष्ट भाषा के लिए एक कमांड का उपयोग करके ऐसा करते हैं।

 var uri = $"project/{_projectName}/language-status?key={apiKey}"; var content = new MultipartFormDataContent {{ new StringContent(langCode), "language" } }; return PostAsync(uri, content);

मंच हमें कुछ इस तरह लौटाएगा:

  <item> <node_type>directory</node_type> <id>29812</id> <name>Version 1.0</name> <files> <item> <node_type>file</node_type> <id>29827</id> <name>strings.xml</name> <node_type>file</node_type> <phrases>7</phrases> <translated>0</translated> <approved>0</approved> <words>32</words> <words_translated>0</words_translated> <words_approved>0</words_approved> </item> </files> </item>

यहाँ हम मूल्यों में रुचि रखते हैं <अनुवादित /> और <स्वीकृत />। पहला इस फ़ाइल में अनुवादित लाइनों का प्रतिशत दिखाता है, दूसरा स्वीकृत मानों का प्रतिशत दिखाता है यदि, अनुवादक के अलावा, एक समीक्षक भी वर्कफ़्लो में भाग लेता है। हमारे वर्कफ़्लो के आधार पर, उदाहरण के लिए, 100 पर हम अनुवादित और स्वीकृत दस्तावेज़ पर विचार करते हैं। अब यह फाइल हमारे पास वापस आयात की जा सकती है।

5. हमारे सिस्टम में फ़ाइल को वापस आयात करें।
यह एक सरल GET अनुरोध के साथ किया जाता है।

 https://api.crowdin.com/api/project/{_projectName}/export-file?file={_crowdInDirectoryPath}/{fileName}&language={langCode}&key={project-key}

परिणामस्वरूप फ़ाइल deserialized है और डेटा हमारे सिस्टम में आयात किया गया है।

एक निष्कर्ष के बजाय

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

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

अनंत स्थानीयकरण, या हम वास्तविक समय में मानचित्र का अनुवाद कैसे करते हैं