अनुप्रयोग स्थानीयकरण: हमने मित्रों का अनुवाद और विकास कैसे किया

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

इस लेख में मैं आपको बताऊंगा कि हमने स्थानीयकरण प्रक्रिया का निर्माण कैसे किया, हम गुणवत्ता नियंत्रण कैसे प्राप्त करते हैं, हम मंच के आधार पर अनुवाद कैसे जारी करेंगे, और सबसे महत्वपूर्ण बात यह है कि हमने यह कैसे सुनिश्चित किया कि डेवलपर्स हमारे अनुवाद प्रणाली के बारे में अच्छी तरह से बोलें। यह एक बहुत ही महत्वपूर्ण बिंदु है: 300 से अधिक डेवलपर्स परियोजनाओं पर काम करते हैं, जिनमें से काम आरामदायक होना चाहिए। डेवलपर्स अनुवादक नहीं हैं और अनुवाद के बारे में नहीं सोचना चाहिए।

यह लेख नवंबर में हाईलोड ++ सम्मेलन में मेरी रिपोर्ट के आधार पर लिखा गया था।

सामग्री:

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

शुरुआत करने के लिए, आइए देखें कि हमारी कंपनी में स्थानीयकरण प्रक्रिया आम तौर पर कैसी दिखती है।

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

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

इन सब से निपटते हैं। लेकिन पहले, मैं एक शब्द का परिचय और व्याख्या करना चाहता हूं।

एक टोकन कोई भी अविभाज्य पाठ है जिसका अनुवाद करने की आवश्यकता है। यह एक बटन कैप्शन, एक शीर्षक या एक संपूर्ण पैराग्राफ हो सकता है।

अब हम मुख्य सामग्री पर जाने के लिए तैयार हैं!

संदर्भ की शर्तें

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

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

पाठ का पुन: उपयोग करना बहुत ही कपटपूर्ण क्षण होता है। एक तरफ, स्थानीयकरण प्रक्रिया को तेज किया जाता है, और दूसरी तरफ, आप एक अजीब स्थिति में आ सकते हैं।

मैं एक उदाहरण के साथ समझाऊंगा। एक बार हमारे सामने एक प्रश्न था "क्या आप धूम्रपान करते हैं?" उत्तर विकल्प "हाँ" और "नहीं" के साथ। यहाँ हम तीन टोकन देखते हैं: दो उत्तर के लिए और एक प्रश्न के लिए। इस प्रश्न का रूसी में अनुवाद किया गया था, "क्या आप धूम्रपान करते हैं?", उत्तर "मैं धूम्रपान करता हूँ" और "मैं धूम्रपान नहीं करता"। फिर हमने एक और सर्वेक्षण करने और उत्तर विकल्पों का पुन: उपयोग करने का निर्णय लिया। अंग्रेजी में, सब कुछ सही लगा: "फैंसी पार्टी में जाना?" - "हाँ" / "नहीं"। रूसी में, टोकन के पुन: उपयोग के कारण, निम्नलिखित "संवाद" निकला: "क्या आप पार्टी में जाएंगे?" - "मैं धूम्रपान करता हूं" / "मैं धूम्रपान नहीं करता"।

अब, जब हम TOR संकलित करते हैं और पाठ के पुन: उपयोग पर निर्णय लेते हैं, तो हम इस बात पर ध्यान देते हैं कि यह पहले किन संदर्भों में उपयोग किया गया था। हम यह भी संकेत देते हैं कि टोकन सर्वर द्वारा दिया गया है या क्लाइंट में एकीकृत है और ऐप स्टोर या Google Play के माध्यम से ग्राहकों तक पहुंचाया गया है।

ये तकनीकें समय बचाने में मदद करती हैं क्योंकि वे बाद के चरणों में चर्चा को बाहर कर देती हैं।

अनुवाद

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

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

अनुवाद का आदेश

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

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

एक उदाहरण है। मान लीजिए कि हमें ग्रीटिंग को अधिक औपचारिक बनाने की आवश्यकता है। प्रारंभ में, अंग्रेजी में "हे", स्पेनिश में "होला", फ्रेंच में "सालुट", रूसी में "हैलो", ऑस्ट्रेलियाई में "G'day mate" और मैक्सिकन में "Que onda" (एक लहर की तरह) था। मैक्सिकन शांत हैं!)। यदि हम पाठ को बदलना चाहते हैं, तो इसे और अधिक आधिकारिक बना दिया जाएगा, तो हमें मूल पाठ को अंग्रेजी में बदलना होगा। इस बिंदु पर, अन्य भाषाओं में अनुवाद गलत हो जाते हैं: उन्हें जांचने और स्पष्ट करने की आवश्यकता होती है। हम अनुवादकों का ध्यान इस ओर आकर्षित करते हैं।

प्रसंग प्रभाव

एक महत्वपूर्ण बिंदु वह संदर्भ है जिसमें अनुवाद मौजूद है।

मैं उदाहरणों के साथ समझाऊंगा।

तुरंत, मैं ध्यान देता हूं कि कुछ उदाहरण ज्ञात संसाधनों के स्क्रीनशॉट हैं, लेकिन उनके नाम हमारे लिए कोई मायने नहीं रखते हैं, हम सिर्फ स्थानीयकरण में सबसे आम प्रकार की त्रुटियों को देखते हैं।

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

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

अगला उदाहरण इस बारे में है कि अनुवाद के परिणामस्वरूप पाठ का मूल विचार कैसे खो गया। रूसी संस्करण को दाईं ओर देखें: हमें स्वयं के साथ संचार शुरू करने की पेशकश की जाती है। हालांकि यह समझा गया कि वे हमें अपने इंस्टाग्राम अकाउंट को लिंक करने का अवसर देते हैं।

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

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

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

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

इसलिए, हमने यह सुनिश्चित किया कि अनुवाद विकल्प संदर्भ पर अत्यधिक निर्भर है, अर्थात् निम्नलिखित कारकों पर:

• उपयोगकर्ता लिंग
• पाठ में दिखाई देने वाला संख्यात्मक चर: "आपका केवल एक मित्र है" और "आपके पहले से ही दस मित्र हैं";
• प्लेटफ़ॉर्म: वेब, एंड्रॉइड, आईओएस;
• जिस परियोजना के लिए अनुवाद किया जा रहा है।

हमें अंतिम बिंदु पर ध्यान दें - परियोजना पर अनुवाद की निर्भरता। यह महत्वपूर्ण है क्योंकि प्रत्येक परियोजना की अपनी शैली है।

ये उन पत्रों के शीर्षलेख हैं जो उपयोगकर्ता को भेजे जाते हैं यदि उसका खाता अवरुद्ध हो गया है।

सगाई के लिए: "आपका खाता बंद है।"
लुमेन के लिए: "आपका खाता बंद है।"
बम्बल के लिए: "आप अवरुद्ध थे।"
और चैपी के लिए - "अजी!"

प्रत्येक परियोजना के भीतर एक एकीकृत शैली बनाए रखने के लिए, आपको अनुवादकों को अनुवाद इतिहास तक पहुंच प्रदान करने की आवश्यकता है। हमारे पास अनुवाद स्मृति (TM) नामक एक उपकरण है। अनुवादक को हमेशा मैचों और समानता के प्रतिशत के बारे में जानकारी तक पहुंच होती है: वह या तो पुराने अनुवाद का उपयोग कर सकता है या एक नया दर्ज कर सकता है। हम अनुवादकों को न केवल 100% मैच दिखाते हैं, बल्कि कम समान विकल्प भी दिखाते हैं, और हम निश्चित रूप से मतभेदों को उजागर करेंगे।

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

मामले और संख्या

हमारे पास केस मैट्रिक्स नामक एक उपकरण है। यह केवल मामलों और अंकों के लिए गुणा तालिका की तरह है।

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

परिणामस्वरूप, मैट्रिक्स इन त्रुटियों से बचने में मदद करता है:

उपकरण का लाभ यह है कि वांछित आकार उपयोगकर्ता को दिखाने से पहले, रेंडर करने से ठीक पहले चुना जाता है। यहां बताया गया है:

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

"आप 10 क्रेडिट की जरूरत है": वाक्यांश "10 क्रेडिट" स्वचालित रूप से प्रतिस्थापित किया जाएगा।

अनुवाद की जाँच करें

यदि हम 150,000 वाक्यांशों और ग्रंथों को 52 भाषाओं में गुणा करते हैं, तो हमें 7.5 मिलियन के क्षेत्र में एक संख्या मिलती है। बेशक, मैन्युअल रूप से यह सब जाँचना अवास्तविक है। इसलिए, हमने बचत के समय अनुवादों की एक स्वचालित जाँच की।

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

हम लापता HTML की भी जांच करते हैं, अन्यथा लेआउट जाएगा।

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

हम मुख्य बिंदुओं पर प्रकाश डालते हैं:

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

उपयोगकर्ता सहायता

पेशेवर अनुवादकों के काम के अलावा, हम उपयोगकर्ताओं की मदद का उपयोग करते हैं। यहां दो तरीके हैं: ए / बी परीक्षण और संयुक्त अनुवाद।

ए / बी परीक्षण

तो, आपको एक अनुवाद की आवश्यकता है, उदाहरण के लिए, रूसी में। अनुवादक ने एक वाक्यांश का दो अलग-अलग तरीकों से अनुवाद किया, और आपको नहीं पता कि कौन सा विकल्प चुनना है। इस मामले में, आप A / B परीक्षण कर सकते हैं: उपयोगकर्ताओं को विभिन्न विकल्प दिखाते हैं और उनकी प्रतिक्रिया के आधार पर किसी एक को चुनते हैं।

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

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

संयुक्त अनुवाद

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

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

हमारे पास एक सहयोगी अनुवाद मंच है । आप अपने लॉगिन खाते का उपयोग करके लॉग इन कर सकते हैं। और सर्वश्रेष्ठ अनुवाद के लिए मतदान करें।

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

मदद के लिए उपयोगकर्ताओं से पूछने से डरो मत। वे शीघ्र मदद करेंगे।

डिज़ाइन

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

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

समानांतर विकास

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

पुरानी योजना जिसमें बदलाव किए गए थे

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

टोकन का उपयोग करते समय त्रुटियां

अनुवादों में कई चर होते हैं।

यदि आप जल्दी में हैं, तो आप आसानी से "credit_amount" और "credit" को भ्रमित कर सकते हैं। इससे बचने के लिए, हमने नियंत्रण पेश किया - एक पाठ कंटेनर, अनुवाद पर एक प्रकार का अमूर्त, जो जानता है कि इस अनुवाद में किस प्रकार के चर का उपयोग किया जाता है। यह प्रतिस्थापन करता है और पुष्टि करता है कि प्रतिस्थापन के लिए पारित मूल्य प्रकार अपेक्षित हैं। यदि सभी प्रतिस्थापन किए जाते हैं, तो यह एक पंक्ति देता है जो पहले से ही उपयोगकर्ता को दिखाया जा सकता है। यदि नहीं, तो उसी कंटेनर को लौटा दिया जाता है। यदि हम सभी प्रतिस्थापन पूरा करने से पहले उपयोगकर्ता को अनुवाद दिखाने की कोशिश करते हैं, तो हम लॉग में एक चेतावनी देखेंगे और हमें पता चल जाएगा कि कहां जाना है और कैसे स्थिति को ठीक करना है।

विकास में मुख्य विशेषताएं:

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

गुणवत्ता नियंत्रण

इसलिए, हमारे पास पहले से ही एक विकसित उत्पाद है जिसका हमने अनुवाद किया है। यह जांचना बाकी है कि हमने कितना अच्छा प्रदर्शन किया।

आइए उदाहरणों से शुरू करते हैं। इस स्क्रीनशॉट में कितने जाम हैं?

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

दूसरा उदाहरण उन अनुवादों की भी चिंता करता है जो बहुत लंबे हैं जो स्क्रीन की चौड़ाई के अनुरूप नहीं हैं - सब कुछ बस यहां फसली है, शिलालेख बटन पर फिट नहीं होता है।

निम्नलिखित उदाहरण में, हमें विभिन्न भाषाओं में पाठ दिखाने के अलावा, हमें दर्द जानने के लिए भी पेश किया जाता है।

ठेस पर होने वाली ऐसी त्रुटियों को रोकने के लिए, गुणवत्ता नियंत्रण बस आवश्यक है।

नियंत्रण विकल्प

आइए देखें कि नियंत्रण विकल्प क्या मौजूद हैं।

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

अनुप्रयोग स्क्रीनशॉट

गुणवत्ता नियंत्रण की अगली विधि एप्लिकेशन के स्क्रीनशॉट के अनुसार है।

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

यदि आपके पास एक वेब संस्करण है और आपको कहीं से चित्र प्राप्त करने की आवश्यकता है, तो आप टोकन मार्कर को स्रोत पाठ में एकीकृत कर सकते हैं, Google Chrome के लिए प्लग-इन लिख सकते हैं - और परीक्षकों की मशीनों से, उनके ब्राउज़र से, यह प्लग-इन आपके स्थानीयकरण प्रणाली के लिए पृष्ठों के स्क्रीनशॉट भेजेगा जिस पर उन्होंने टोकन खोजे।

<ul> <li>...</li> <li> <!--lexeme_12345-->  <!--lexeme_12345_end--> </li> <li>...</li> </ul> 

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

अनुवाद के दौरान नियंत्रण

जैसा कि मैंने ऊपर कहा था, यह तब लग रहा था जब हमें पहले से ही तैयार अनुप्रयोग के लिए तस्वीरें लेने के लिए पर्याप्त नहीं था। हमने स्क्रीनशॉट लेने का फैसला किया जब एप्लिकेशन अभी तक तैयार नहीं है, जब अभी भी कुछ भी नहीं है और यह किसी भी तरह से गुणवत्ता को नियंत्रित करने के लिए आवश्यक है, यह समझने के लिए कि क्या सब कुछ वैसा ही होना चाहिए जैसा कि होना चाहिए।

इसलिए हमें अनुवाद के दौरान एक नियंत्रण उपकरण मिला।

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

बाद में हमने इस समाधान को ओपन-सोर्स ( लेख , कोड ) के रूप में डिज़ाइन किया।

अनुवाद ऑडिट

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

गुणवत्ता नियंत्रण में मुख्य विशेषताएं:

अनुवाद की गुणवत्ता का एक दृश्य मूल्यांकन आवश्यक है;
परीक्षण प्रक्रिया के दौरान, यह समझना महत्वपूर्ण है कि आपके दर्शक कौन से उपकरणों का उपयोग कर रहे हैं और इन सभी उपकरणों पर एप्लिकेशन का परीक्षण करें।

रिलीज की तारीख

तो, हमने शांत लिखित कार्यक्षमता का परीक्षण किया है। इसे यूजर्स तक पहुंचाना बाकी है।

वर्जनिंग टोकन

हमारे ब्रेट एप्लिकेशन में, एक सुपर पावर सेवा थी। कुछ बिंदु पर, हमें इसका नाम बदलकर "सगाई प्रीमियम" करने की आवश्यकता है, और एक बार सभी संस्करणों में यह परमाणु था ताकि उपयोगकर्ता एक स्क्रीन पर "सुपर स्ट्रेंथ" और दूसरी तरफ "सगाई प्रीमियम" नहीं देख सके।

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

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

अनुवाद संस्करण

हालाँकि, आप अनुवाद के दौरान गलतियाँ कर सकते हैं। नीचे दिए गए उदाहरण में उनमें से दो हैं।

मिथ्या: "यह एक रीमथ है।"
सच: "यह एक रीमैच है।"

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

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

सर्वर! = स्मार्टफोन

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

आप उपयोगकर्ता को जो कुछ भी दिखाते हैं वह या तो आंशिक रूप से सर्वर से आता है, या उसके स्मार्टफोन पर स्थित है (उदाहरण के लिए, एकीकृत अनुवाद)।

पथ जो उपयोगकर्ता से सर्वर पर स्थानांतरण को पारित करता है, हमारे उत्पादन सर्वर के माध्यम से निहित है, जहां आप आसानी से अनुवाद के साथ फ़ाइलों के अद्यतन संस्करण वितरित कर सकते हैं।

लेकिन एकीकृत अनुवाद का मार्ग लंबा है: यह ऐप स्टोर या Google Play के माध्यम से निहित है। उपयोगकर्ता अपडेट डाउनलोड करता है और उसके बाद ही फिक्स देखता है। यह प्रक्रिया हमारे लिए बहुत धीमी लग रही थी, और हम अपने "हॉट अपडेट" अपडेट तंत्र के साथ आए। यह आपको एक बटन के क्लिक पर अनुवाद का एक नया संस्करण उत्पन्न करने और दुनिया के सभी ग्राहकों को यह स्पष्ट करने की अनुमति देता है कि कुछ नया है जिसे डाउनलोड करने और उपयोग करने की आवश्यकता है।

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

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

रिलीज़: हाइलाइट्स

रिलीज प्रक्रिया में, आपको यह ध्यान रखना होगा कि आवेदन आपके ग्राहकों से किस रास्ते पर जाता है। संभवतः, आपके एप्लिकेशन के विभिन्न भागों को अलग-अलग अपडेट किया गया है।

अंतिम निष्कर्ष

आइए उस लेख पर लौटें जिसे मैंने लेख की शुरुआत में उद्धृत किया था।

यदि आप अनुवाद प्रणाली विकसित कर रहे हैं तो आपको क्या ध्यान देना चाहिए:

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

सामग्री मैं आपके साथ साझा करना चाहूंगा

मोबाइल अनुप्रयोगों में मक्खी पर अद्यतन तार: भाग 1

मोबाइल अनुप्रयोगों में मक्खी पर अद्यतन तार: भाग 2

100 भाषाओं को बोलने के लिए वेब एप्लिकेशन कैसे सिखाएं: स्थानीयकरण की विशेषताएं

हम पचास भाषाओं में इंटरफेस का अनुवाद करते हैं। स्केच

जीथब स्केच-संशोधक