कई भाषाओं में एप्लिकेशन को स्थानीय कैसे करें ताकि यह दर्दनाक रूप से शर्मनाक न हो

Habré पर स्थानीयकरण / आवेदनों के अंतर्राष्ट्रीयकरण के सवालों पर बार-बार चर्चा की गई। हम, एबीबीवाई भाषा सेवाएं , लंबे समय से भाषाई सेवाओं, सेवाओं और प्रौद्योगिकियों के क्षेत्र में काम कर रहे हैं, और हम लगातार सॉफ्टवेयर स्थानीयकरण में लगे हुए हैं। हमने इस मामले में काफी अनुभव अर्जित किया है, हमने इसे पूरी प्रक्रिया को व्यवस्थित करने पर अधिक जोर देने के साथ साझा करने का फैसला किया। अनुप्रयोगों का स्थानीयकरण आमतौर पर माना जाता है की तुलना में अधिक कठिन कार्य है, और आप इसे विभिन्न तरीकों से संपर्क कर सकते हैं: आप शुरू में सरल और समझने योग्य पाठ बना सकते हैं, आप शांत अनुवादकों में निवेश कर सकते हैं जो किसी भी पाठ से समझ में आता है, आप किसी भी तरह से पाठ तैयार और अनुवाद कर सकते हैं। ", लेकिन अंतिम परिणाम को समेटने के लिए समुदाय या परीक्षकों को रखें। केवल यह याद रखना आवश्यक है कि स्रोत पाठ को एक भाषा में सत्यापित किया गया है, और परिणाम सभी भाषाओं में सत्यापित किया गया है, अर्थात्, प्रयासों को एन गुना अधिक खर्च करना होगा।

सामान्य तौर पर, स्थानीयकरण वास्तव में एक और बाजार का उद्घाटन है, और यह स्पष्ट है कि, स्थानीयकरण पर निर्णय लेते समय, प्रबंधन अतिरिक्त लाभ प्राप्त करने की उम्मीद करता है। इसके अलावा, अक्सर कुल विकास बजट का केवल एक छोटा सा हिस्सा (कहते हैं, लगभग 1-2%) इस बहुत स्थानीयकरण में निवेश किया जाता है। यानी गणना यह है कि 1% जोड़कर आप + 50% आय प्राप्त कर सकते हैं। ऐसी उम्मीदें कितनी यथार्थवादी हो सकती हैं?

उद्देश्य और गुंजाइश

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

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

सॉफ्टवेयर अनुवाद की बात करें तो निम्नलिखित मुख्य प्रकार की सामग्री को अलग किया जा सकता है:

• आवेदन की लाइनें ही;
• उपयोगकर्ता मैनुअल;
• उत्पाद पर मदद।

प्रत्येक बाद के पैराग्राफ में जाने पर, अनुवाद की जाने वाली जानकारी की मात्रा बढ़ जाती है। आवेदन में स्वयं 10-100 हजार शब्द, विभिन्न मैनुअल और प्रशिक्षण पाठ्यक्रम शामिल हो सकते हैं - एक और 200-500 हजार, और पूर्ण उत्पाद सहायता - 1-3 मिलियन शब्दों तक (सब कुछ, निश्चित रूप से, परियोजना पर निर्भर करता है)।

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

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

प्रक्रिया संगठन

तो, चलो कहते हैं कि चुनाव किया जाता है, स्थानीयकरण की आवश्यकता है।

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

सॉफ्टवेयर के लिए संभावित विकल्प (बिल्कुल नहीं):

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

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

सामग्री

इस चरण की मुख्य विशेषता यह है कि सामग्री तैयार करते समय की गई कोई भी गलती स्वचालित रूप से अनुवाद भाषाओं (एन) की संख्या से गुणा होती है। एक मनमाने ढंग से खराब किए गए वाक्यांश को लें।

सबसे अच्छे रूप में, एन अनुवादक अनुवाद परियोजना प्रबंधक (TRM) से इस वाक्यांश को स्पष्ट करने के लिए कहेंगे। TRM आवश्यक रूप से उत्पाद विशेषज्ञ नहीं है: यह वह व्यक्ति है जो प्रक्रिया का आयोजन करता है। उसे सीधे तौर पर सामग्री बनाने वाले लोगों की तुलना में स्थिति को समझने के लिए स्पष्ट रूप से अधिक समय बिताना होगा।

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

शब्दावली

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

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

उत्पाद पंक्तियाँ

एप्लिकेशन सामग्री बनाने के कई तरीके हैं। विशिष्ट कार्यान्वयन विकास प्रक्रिया पर निर्भर करता है कि लाइनें कैसे रखी जाती हैं, और अन्य कारक।

एक लगातार स्थिति: डिजाइनर, क्लाइंट (या उत्पाद विपणन) के साथ संचार करता है, प्राथमिक उत्पाद विनिर्देश बनाता है।

फिर प्रोग्रामर कोड लिखता है, कभी-कभी इंटरफ़ेस तत्वों के नाम की नकल करता है, कभी-कभी त्रुटियों सहित, अपने स्वयं के कुछ का परिचय देता है।

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

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

दो और मुद्दे जोड़ें:

• प्रत्येक प्रोग्रामर (और वास्तव में, प्रत्येक व्यक्ति नहीं), यहां तक ​​कि अपनी मूल भाषा में भी, स्पष्ट रूप से और सही ढंग से अपने विचारों को तैयार कर सकता है (अफसोस, लेकिन यह है)।
• विकास टीम अपने विशेष क्षेत्र में काढ़ा करती है, जहां वे सब कुछ समझते हैं, जबकि अपनी स्वयं की कठबोली भाषा का उपयोग करते हैं।

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

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

मामले पर विचार करें जब लाइनें अभी भी किसी प्रकार के नियंत्रण से गुजरती हैं।

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

स्रोत सामग्री की जाँच के पहलू

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

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


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

नियंत्रित भाषा प्रणाली

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

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

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

सारांश

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

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

फ्रिज द्वारा पोस्ट किया गया।