आवेदन अंतर्राष्ट्रीयकरण के बारे में कुछ शब्द

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

यूनिकोड का उपयोग करें

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

फोंट का ख्याल रखना

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

पैंतरेबाज़ी के लिए कमरा छोड़ दो

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

आरयू: के रूप में सहेजें
en: के रूप में सहेजें
फाई: तलेनना निमेल
zh:为 为

यदि चीनी भाषा के लिए हमें केवल 3 वर्णों की आवश्यकता है, तो फ़िनिश के लिए 16 के रूप में कई हैं! इसके अलावा, वर्णों की संख्या के अलावा, एक विशेष फ़ॉन्ट की विशेषताएं भी महत्वपूर्ण हैं।

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

Psevdolokalizatsiya

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

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

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


और यहाँ इन सेटिंग्स के साथ परिणाम है:

बाहरी संसाधन

स्थानीयकृत सामग्रियों का संपूर्ण अवलोकन करने के लिए, कोड से सभी संसाधनों को अलग करना आवश्यक है। टेक्स्ट वाली मल्टीमीडिया जानकारी (अक्सर ये छवियां होती हैं, साथ ही वीडियो और ऑडियो भी, उदाहरण के लिए, खेलों में) भी अलग से संग्रहित की जानी चाहिए, जो कि लोकेल द्वारा क्रमबद्ध हैं। सबसे पहले, यह सामग्री रचनाकारों के काम को बहुत सरल करेगा, उन्हें किसी भी सिस्टम संदेश को ठीक करने के लिए कोड में तल्लीन करने की आवश्यकता नहीं होगी। दूसरे, यह स्थानीयकरण प्रबंधक को प्रत्येक भाषा के समय और बजट की सही गणना करने की अनुमति देगा। तीसरा, यह आपको बहुभाषी सामग्री के साथ काम करने में अतुलनीय रूप से लचीला होने की अनुमति देगा।
स्थानीयकृत डेटा के आदान-प्रदान के लिए सबसे लोकप्रिय प्रारूप XLIFF और .po फाइलें हैं । एक तरह से या किसी अन्य, आधुनिक स्वचालित अनुवाद सिस्टम किसी भी फाइल को अनुवादकों द्वारा समझने योग्य प्रारूप में बदलने में सक्षम हैं।
Google और Apple भी, डेवलपर्स को स्थानीयकरण के लिए सभी संसाधनों को बाहर निकालने के लिए दृढ़ता से सलाह देते हैं : एंड्रॉइड डेवलपर्स के लिए सिफारिशें, अंतर्राष्ट्रीयकरण के लिए ऐप्पल की सिफारिशें ।

अंतर्राष्ट्रीयकरण में हार्डकोडिंग

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

विराम चिह्न

कई डेवलपर्स कोड में विराम चिह्न "सिलाई" करना पसंद करते हैं, यह सोचकर कि डॉट्स और प्रश्न चिह्न निश्चित रूप से सभी भाषाओं में समान हैं। लेकिन तुलना करें:

आरयू:

  क्या आपको यकीन है? 

एन:

  क्या आपको यकीन है? 

fr:

  Êtes-vous sûr? 

es:

  ¿एस्टा सेग्रो? 

ar:

  هل هنت متأكد أ 

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

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

संख्या

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

आरयू: 18 765.22
en: 18,765.22
डी: 18.765,22
वह: 18,765.22
एल: 18.765,22
fa: 18 : 765.22

हजारवें और भिन्नात्मक सीमांकक के रूप में किस वर्ण का उपयोग किया जाता है, इस पर ध्यान दें। अंग्रेजी और हिब्रू में, डॉट और कॉमा जर्मन और ग्रीक की तुलना में पूरी तरह से अलग हैं। और रूसी में, संख्या> 9999 के लिए हजारवां विभाजक के रूप में एक स्थान (अक्रिय) का उपयोग किया जाता है। और फ़ारसी में, हजारों को एक विशेष प्रतीक "मोम्मे" (यू + 066 बी) द्वारा अलग किया जाता है, हालांकि, इस भाषा के लिए कोई विशेष मानक नहीं है, विभाजक भी अल्पविराम या एक स्थान हो सकते हैं।
बेशक, हम यह मान सकते हैं कि ये ट्राइफल्स हैं और "जिन्हें इसकी आवश्यकता है, और इस रूप में वे समझेंगे।" हालांकि, ऐसी trifles कभी-कभी गंभीर गलतफहमी पैदा कर सकती हैं, खासकर जब यह कीमतों या महत्वपूर्ण इंजीनियरिंग गणना की बात आती है।
मूल्य निर्धारण की बात करें, तो तुलना करें:

आरयू: 2,25 €
en: € 2.25
डी-एट: € 2.25
डी-डे: 2,25 €
lv: € 2.25
लेफ्टिनेंट: 2.25 €

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

माप की इकाइयों

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

सभी भाषाओं में समान व्याकरण नहीं है।

फोर्स लाइन टूट गई

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

एक काफी सामान्य उदाहरण है। रूसी-भाषी उपयोगकर्ता संदेश देखता है: “ परीक्षण अवधि समाप्त होने से पहले 5 दिन शेष हैं। कृपया एक वैध कुंजी दर्ज करें । " संसाधनों में, यह संदेश इस प्रकार है:

 'trialexpires_1': "परीक्षण अवधि के अंत तक"
 'trialexpires_2sg': "रुकी"
 'trialexpires_2pl': "लेफ्ट"
 'trialexpires_4sg': "दिन।"
 "trialexpires_4pl2 ':" दिन का। "
 'trialexpires_4pl3': "दिन।"
 'enterkey': "कृपया एक वैध कुंजी दर्ज करें।"

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

en: आपकी परीक्षण अवधि 5 दिनों में समाप्त हो रही है। कृपया मान्य कुंजी दर्ज करें।
डी: 5 टैगन एब में इहारे टेस्टवेरेशन लुफ्ट। बिट्टे गेबेन सी ईनें ग्यूटलगेन प्रोडुकट्सच्लसेल ईन ।

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

 'trialexpires': "परीक्षण अवधि के अंत तक [गणना: वाम | वाम] {% n} / गणना: दिन | दिन | दिन]।"
 'enterkey': "कृपया एक वैध कुंजी दर्ज करें।"

गिनती ऑपरेटर (या जिसे आप इसे कहते हैं) संख्यात्मक चर% n के आधार पर वांछित पाठ मान को प्रतिस्थापित करता है। इस प्रतिनिधित्व के साथ, अरबी अनुवादक, दाईं से बाईं ओर लिखते हुए, समस्या नहीं होगी - वह बस चर को स्वैप करता है।

मजबूर लाइन ब्रेक का उपयोग कर लेआउट

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

यह पाठ इतना बड़ा है
और खिड़की इतनी छोटी है
मुझे क्या तोड़ना पड़ेगा
उसे लाइन से लाइन।

संसाधनों में, यह इस तरह दिख सकता है:

 'menubox_string1': "यह पाठ इतना बड़ा है,"
 'menubox_string2': "और विंडो बहुत छोटी है,"
 'menubox_string3': "मुझे क्या तोड़ना पड़ेगा"
 'menubox_string4': "यह लाइन से लाइन है।"

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

 'menubox': "यह टेक्स्ट इतना बड़ा है, \ n विंडो इतनी छोटी है, \ n मुझे इस लाइन से \ n विभाजन करना है।"

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

अनुकूलन पर

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

उपयोगकर्ता निम्नलिखित पाठ देखता है:
आप टर्मिनल से एप्लिकेशन लॉन्च कर सकते हैं। टर्मिनल तक पहुंचने के लिए F2 दबाएं।

संसाधनों में, इसे निम्नलिखित टुकड़ों से इकट्ठा किया जाता है:

 'cmd': "टर्मिनल"
 'ऐप': "एप्लीकेशन"
 'act_42': "F2 दबाएँ"
 'run_from_terminal': "आप {cmd} से {app} लॉन्च कर सकते हैं {{cmd} का उपयोग करने के लिए।"

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

आइए देखें कि इस रूप में संसाधनों का रूसी में अनुवाद कैसे किया जाएगा।

 'cmd': "टर्मिनल"
 'ऐप': "एप्लीकेशन"
 'act_42': "F2 दबाएँ"
 'run_from_terminal': "आप {cmd} {{act_42} से {cmd} खोलने के लिए {app} चला सकते हैं।"

उपयोगकर्ता निम्नलिखित देखेंगे:

“ आप टर्मिनल से एप्लिकेशन चला सकते हैं। टर्मिनल खोलने के लिए F2 दबाएं । "

यदि हम "एप्लिकेशन" शब्द को "प्रोग्राम" शब्द से बदलते हैं, तो यह और भी बदतर हो जाएगा, लेकिन अधिक स्पष्ट रूप से:

“ आप टर्मिनल से प्रोग्राम चला सकते हैं। टर्मिनल खोलने के लिए F2 दबाएं । "

जाहिर है, इस दृष्टिकोण में मामले की श्रेणी को ध्यान में नहीं रखा गया है।
ऐसे उदाहरणों के लिए दूर जाने की जरूरत नहीं है। ज़रा चौंककर देखें स्थानीयकृत फोरस्क्वेयर:

या, फ़िल्टर के नामों पर एक नज़र डालें। उनमें से सभी वाक्यांश "स्थानों को दिखाएं ..." की निरंतरता नहीं हैं। ये संभवतः अन्यत्र उपयोग किए जाने वाले स्थिरांक हैं। ठीक है, या सिर्फ नासमझ अनुवाद और स्थानीयकरण परीक्षण की कमी।


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

रूसी संस्करण में, "अध्ययन का स्थान:% विश्वविद्यालय%" लिखना बेहतर होगा।
एक अन्य अनुभाग से एक समान उदाहरण:


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

निष्कर्ष

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

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

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