IOS में अनुप्रयोगों का स्थानीयकरण

भाग 1. हमारे पास क्या है?

स्थानीयकृत स्ट्रिंग संसाधन गाइड

परिचय

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

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

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

बॉक्स से बाहर। IOS अनुप्रयोगों में स्ट्रिंग संसाधनों का भंडारण कैसे आयोजित किया जाता है

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

और इसलिए, Xcode हमें "बॉक्स से बाहर" क्या अवसर प्रदान करता है? सबसे पहले, आइए एक परियोजना में स्ट्रिंग संसाधनों के भंडारण के लिए मानक देखें।

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

इसके अलावा, Apple एक मानक फ़ाइल एक्सटेंशन प्रदान करता है। यह मानक एक सहयोगी सरणी ( "-" ) के रूप में स्ट्रिंग डेटा संग्रहीत करने के लिए प्रारूप को नियंत्रित करता है:

 "key" = "value"; 

कुंजी केस-संवेदी है, रिक्त स्थान, अंडरस्कोर, विराम चिह्न और विशेष वर्णों के उपयोग की अनुमति देता है।

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

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

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

नतीजतन, एक साधारण डिजाइन के लिए प्रोग्रामर को डेटा के साथ फाइल भरते समय बहुत गहन और चौकस होना पड़ता है।

जानकार डेवलपर्स तुरंत कह सकते हैं: "लेकिन JSON और PLIST के बारे में क्या? उन्होंने क्या नहीं किया?" खैर, सबसे पहले, JSON और PLIST (वास्तव में, साधारण XML ) सार्वभौमिक मानक हैं जो स्ट्रिंग्स और न्यूमेरिक, तार्किक ( BOOL ), बाइनरी डेटा, समय और दिनांक, साथ ही संग्रह - अनुक्रमित ( Array ) और साहचर्य दोनों को संग्रहीत करने की अनुमति देते हैं। Dictionary ) सरणियाँ। तदनुसार, इन मानकों का सिंटैक्स अधिक संतृप्त है, और इसलिए उन पर कुतरना आसान है। दूसरे, ऐसी फ़ाइलों की प्रसंस्करण गति स्ट्रिंग्स-फ़ाइलों की तुलना में थोड़ी कम है, फिर से अधिक जटिल वाक्यविन्यास के कारण। यह इस तथ्य का उल्लेख नहीं है कि उनके साथ काम करने के लिए आपको कोड में कई हेरफेर करने की आवश्यकता है।

स्थानीयकृत, स्थानीयकृत, लेकिन स्थानीयकृत नहीं। उपयोगकर्ता इंटरफ़ेस स्थानीयकरण

और इसलिए, मानकों के साथ, अब यह पता लगाने की कोशिश करें कि यह सब कैसे उपयोग किया जाए।

क्रम में चलते हैं। सबसे पहले, एक सरल सिंगल व्यू एप्लिकेशन बनाएं और ViewController पर Main.storyboard में कुछ पाठ घटक जोड़ें।

इस मामले की सामग्री सीधे इंटरफ़ेस में संग्रहीत की जाती है। इसे स्थानीय बनाने के लिए, आपको निम्नलिखित कार्य करने होंगे:

1) प्रोजेक्ट सेटिंग्स पर जाएं

2) फिर - टारगेट से प्रोजेक्ट तक

3) जानकारी टैब खोलें

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

अब एक और भाषा जोड़ते हैं। ऐसा करने के लिए, " + " पर क्लिक करें और वांछित भाषा चुनें (उदाहरण के लिए, मैंने रूसी चुना)। कैरिंग Xcode हमें तुरंत यह चुनने की पेशकश करता है कि कौन सी भाषा जोड़े गए भाषा के लिए स्थानीय हो।

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

उदाहरण के लिए, Main.storyboard (Base) बेस डेवलपमेंट लैंग्वेज में डिफॉल्ट इंटरफ़ेस मार्कअप फाइल है, और इसे स्थानीयकरण बनाते समय, संबंधित Main.strings (Russian) जोड़े में बनाया गया था - रूसी स्थानीयकरण के लिए एक स्ट्रिंग फ़ाइल। इसे खोलकर, आप निम्नलिखित देख सकते हैं:

 /* Class = "UILabel"; text = "Label"; ObjectID = "tQe-tG-eeo"; */ "tQe-tG-eeo.text" = "Label"; /* Class = "UITextField"; placeholder = "TextField"; ObjectID = "cpp-y2-Z0N"; */ "cpp-y2-Z0N.placeholder" = "TextField"; /* Class = "UIButton"; normalTitle = "Button"; ObjectID = "EKl-Rz-Dc2"; */ "EKl-Rz-Dc2.normalTitle" = "Button"; 

यहां, सामान्य तौर पर, सब कुछ सरल है, लेकिन स्पष्टता के लिए, हम अधिक विस्तार से विचार करेंगे, देखभाल करने वाले Xcode द्वारा उत्पन्न टिप्पणियों पर ध्यान दें:

 /* Class = "UILabel"; text = "Label"; ObjectID = "tQe-tG-eeo"; */ "tQe-tG-eeo.text" = "Label"; 

यहां text पैरामीटर के लिए "Label" मान के साथ UILabel वर्ग का एक उदाहरण है। ObjectID - मार्कअप फ़ाइल में ऑब्जेक्ट की पहचानकर्ता - यह Storyboard/Xib पर रखे जाने के समय किसी भी घटक को सौंपी गई एक अनूठी रेखा है। यह ऑब्जेक्ट और ऑब्जेक्ट के पैरामीटर नाम (इस मामले में, text ) से है कि कुंजी का निर्माण होता है, और रिकॉर्ड को औपचारिक रूप से निम्नानुसार व्याख्या की जा सकती है:

लेबल के लिए tQe-tG-eeo ऑब्जेक्ट का टेक्स्ट पैरामीटर सेट करें।

इस रिकॉर्ड में, केवल " मूल्य " परिवर्तन के अधीन है। " लेबल " को " लेबल " से बदलें। हम अन्य वस्तुओं के साथ भी ऐसा ही करेंगे।

 /* Class = "UILabel"; text = "Label"; ObjectID = "tQe-tG-eeo"; */ "tQe-tG-eeo.text" = ""; /* Class = "UITextField"; placeholder = "TextField"; ObjectID = "cpp-y2-Z0N"; */ "cpp-y2-Z0N.placeholder" = " "; /* Class = "UIButton"; normalTitle = "Button"; ObjectID = "EKl-Rz-Dc2"; */ "EKl-Rz-Dc2.normalTitle" = ""; 

हमने अपना एप्लिकेशन लॉन्च किया।

लेकिन हम क्या देखते हैं? एप्लिकेशन मूल स्थानीयकरण का उपयोग करता है। कैसे जांचें कि क्या हमने स्थानांतरण को सही तरीके से किया है?

यहां यह एक छोटे से विषयांतर बनाने और आईओएस प्लेटफॉर्म और एप्लिकेशन संरचना की विशेषताओं की दिशा में थोड़ी खुदाई करने के लायक है।

शुरू करने के लिए, स्थानीयकरण को जोड़ने की प्रक्रिया में परियोजना की संरचना को बदलने पर विचार करें। रूसी स्थानीयकरण जोड़ने से पहले परियोजना निर्देशिका कैसी दिखती है:

और इसके बाद:

जैसा कि हम देख सकते हैं, Xcode ने एक नई निर्देशिका ru.lproj बनाई, जिसमें इसने बनाए गए स्थानीय स्ट्रिंग्स को रखा।

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

इस पदानुक्रम के साथ काम करने के लिए, Apple Bundle(NSBundle) क्लास Bundle(NSBundle) ( मुफ्त अनुवाद ) प्रदान करता है।

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

FileManager वर्ग का उपयोग कर Bundle.main संरचना पर विचार करें:

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

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

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

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

अपने आप करो। कोड में स्थानीयकृत स्ट्रिंग संसाधनों के साथ कार्य करना

उम्मीद है कि स्थिर सामग्री के साथ, सब कुछ कम या ज्यादा स्पष्ट है। लेकिन उस पाठ के बारे में जो कोड में सीधे सेट है?

IOS ऑपरेटिंग सिस्टम के डेवलपर्स ने इस बात का ध्यान रखा।

स्थानीय पाठ संसाधनों के साथ काम करने के लिए, फाउंडेशन फ्रेमवर्क स्विफ्ट में NSLocalizedStrings परिवार प्रदान करता है

 NSLocalizedString(_ key: String, comment: String) NSLocalizedString(_ key: String, tableName: String?, bundle: Bundle, value: String, comment: String) 

और उद्देश्य-सी में मैक्रोज़

 NSLocalizedString(key, comment) NSLocalizedStringFromTable(key, tbl, comment) NSLocalizedStringFromTableInBundle(key, tbl, bundle, comment) NSLocalizedStringWithDefaultValue(key, tbl, bundle, val, comment) 

चलो स्पष्ट के साथ शुरू करते हैं। स्ट्रिंग्स फ़ाइल में key पैरामीटर स्ट्रिंग कुंजी है; val (डिफ़ॉल्ट मान) - डिफ़ॉल्ट मान जिसका उपयोग किया जाता है यदि निर्दिष्ट कुंजी फ़ाइल में नहीं है; comment - (कम स्पष्ट) स्थानीयकृत स्ट्रिंग का एक संक्षिप्त विवरण (वास्तव में, यह उपयोगी कार्यक्षमता नहीं ले जाता है और एक विशिष्ट स्ट्रिंग का उपयोग करने के उद्देश्य की व्याख्या करने के लिए अभिप्रेत है)।

के रूप में मापदंडों के लिए bunble ( tbl ) और bunble , फिर उन्हें और अधिक विस्तार से माना जाना चाहिए।

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

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

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

 /// Returns a localized string, using the main bundle if one is not specified. public func NSLocalizedString(_ key: String, tableName: String? = default, bundle: Bundle = default, value: String = default, comment: String) -> String 

"मुख्य बंडल एक स्थानीय स्ट्रिंग देता है" - हमारे पास सभी है। ऑब्जेक्टिव-सी थोड़ा अलग है।

 #define NSLocalizedString(key, comment) \ [NSBundle.mainBundle localizedStringForKey:(key) value:@"" table:nil] #define NSLocalizedStringFromTable(key, tbl, comment) \ [NSBundle.mainBundle localizedStringForKey:(key) value:@"" table:(tbl)] #define NSLocalizedStringFromTableInBundle(key, tbl, bundle, comment) \ [bundle localizedStringForKey:(key) value:@"" table:(tbl)] #define NSLocalizedStringWithDefaultValue(key, tbl, bundle, val, comment) \ [bundle localizedStringForKey:(key) value:(val) table:(tbl)] 

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

नीचे दिए गए उदाहरणों का वर्णन होगा कि वैश्विक कार्यों और मैक्रोज़ के साथ कैसे काम किया जाए।

आइए देखें कि यह सब कैसे काम करता है।
सबसे पहले, एक स्ट्रिंग फ़ाइल बनाएं जिसमें हमारे स्ट्रिंग संसाधन होंगे। इसे Localizable.strings * कहें और इसे इसमें जोड़ें।

 "testKey" = "testValue"; 

( स्ट्रिंग फ़ाइलें बिल्कुल स्टोरीबोर्ड / Xib की तरह स्थानीयकृत हैं , इसलिए मैंने इस प्रक्रिया का वर्णन नहीं किया है। हम रूसी परीक्षण फ़ाइल में " testValue " को " परीक्षण मान " के साथ बदल देंगे । ")

महत्वपूर्ण! IOS में, इस नाम की एक फ़ाइल डिफ़ॉल्ट स्ट्रिंग संसाधन फ़ाइल है, अर्थात यदि आप तालिका नाम ( tbl ) तालिका का नाम निर्दिष्ट नहीं करते हैं, तो अनुप्रयोग स्वतः ही Localizable.strings पर दस्तक देगा।

हमारी परियोजना के लिए निम्नलिखित कोड जोड़ें

 //Swift print("String for 'testKey': " + NSLocalizedString("testKey", comment: "")) 

 //Objective-C NSLog(@"String for 'testKey': %@", NSLocalizedString(@"testKey", @"")); 

और परियोजना को चलाएं। कोड निष्पादित करने के बाद, कंसोल में एक लाइन दिखाई देगी

 String for 'testKey': testValue 

सब कुछ सही काम करता है!

इसी तरह इंटरफ़ेस के स्थानीयकरण के उदाहरण के साथ, स्थानीयकरण को बदलें और एप्लिकेशन को चलाएं। कोड निष्पादन का परिणाम होगा

 String for 'testKey':   

अब मान को कुंजी द्वारा प्राप्त करने का प्रयास करते हैं, जो कि Localizable.strings फ़ाइल में नहीं है:

 //Swift print("String for 'unknownKey': " + NSLocalizedString("unknownKey", comment: "")) 

 //Objective-C NSLog(@"String for 'unknownKey': %@", NSLocalizedString(@"unknownKey", @"")); 

ऐसे कोड के निष्पादन का परिणाम होगा

 String for 'unknownKey': unknownKey 

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

 //Swift print("String for 'testKey': " + NSLocalizedString("unknownKey", tableName: nil, bundle: Bundle.main, value: "noValue", comment: "")) 

 //Objective-C NSLog(@"String for 'testKey': %@", NSLocalizedStringWithDefaultValue(@"unknownKey", nil, NSBundle.mainBundle, @"noValue", @"")); 

जहां value पैरामीटर ( डिफ़ॉल्ट मान ) है। लेकिन इस मामले में, आपको संसाधनों के स्रोत को निर्दिष्ट करना होगा - bundle ।

स्थानीयकृत स्ट्रिंग मानक iOS स्ट्रिंग्स के समान इंटरपोलेशन तंत्र का समर्थन करते हैं। ऐसा करने के लिए, स्ट्रिंग शाब्दिक ( %@ , %li , %f , आदि) का उपयोग करके स्ट्रिंग फ़ाइल में एक रिकॉर्ड जोड़ें, उदाहरण के लिए:

 "stringWithArgs" = "String with %@: %li, %f"; 

ऐसी लाइन को आउटपुट करने के लिए, आपको फॉर्म का एक कोड जोड़ना होगा

 //Swift print(String(format: NSLocalizedString("stringWithArgs", comment: ""), "some", 123, 123.098 )) 

 //Objective-C NSLog(@"%@", [NSString stringWithFormat: NSLocalizedString(@"stringWithArgs", @""), @"some", 123, 123.098]); 

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

 //Swift print(String(format: NSLocalizedString("stringWithArgs", comment: ""), "some", "123", 123.098 )) 

 //Objective-C NSLog(@"%@", [NSString stringWithFormat: NSLocalizedString(@"stringWithArgs", @""), @"some", @"123", 123.098]); 

तब एप्लिकेशन बेमेल के स्थान पर स्ट्रिंग "123" के पूर्णांक कोड को प्रतिस्थापित करेगा

 "String with some: 4307341664, 123.089000" 

यदि आप इसे छोड़ देते हैं, तो हम प्राप्त करते हैं

 "String with some: 0, 123.089000" 

लेकिन अगर आप तर्क सूची में %@ अनुरूप वस्तु को छोड़ देते हैं

 //Swift print(String(format: NSLocalizedString("stringWithArgs", comment: ""), "123", 123.098 )) 

 //Objective-C NSLog(@"%@", [NSString stringWithFormat: NSLocalizedString(@"stringWithArgs", @""), @"123", 123.098]); 

तब एप्लिकेशन कोड निष्पादन के समय दुर्घटनाग्रस्त हो जाएगा।

मुझे धक्का दो, बच्चा! सूचनाओं का स्थानीयकरण

स्थानीयकृत स्ट्रिंग संसाधनों के साथ काम करने में एक और महत्वपूर्ण कार्य, जिसके बारे में मैं संक्षेप में बात करना चाहूंगा, सूचनाओं को स्थानीयकरण करने का कार्य है। लब्बोलुआब यह है कि अधिकांश ट्यूटोरियल (दोनों Push Notifications और Localizable Strings ) अक्सर इस समस्या की उपेक्षा करते हैं, और ऐसे कार्य इतने दुर्लभ नहीं हैं। इसलिए, जब पहली बार इसके साथ सामना किया जाता है, तो डेवलपर के पास एक उचित प्रश्न हो सकता है: क्या यह सिद्धांत रूप में संभव है? मैं यहां Apple Push Notification Service ऑपरेशन मैकेनिज्म पर विचार नहीं करूंगा, खासकर iOS 10.0 से शुरू करने के बाद से, पुश और लोकल नोटिफिकेशन को एक ही फ्रेमवर्क के जरिए लागू किया जाता है - UserNotifications ।

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

सही निर्णय बहुत ही सरल था, हालांकि पूरी तरह से स्पष्ट नहीं था। APNS पर सर्वर द्वारा भेजे गए मानक JSON के बजाय

  "aps" : { "alert" : { "body" : "some message"; }; }; 

फॉर्म के JSON भेजने की जरूरत है

  "aps" : { "alert" : { "loc-key" : "message localized key"; }; }; 

जहां स्थानीय loc-key का उपयोग Localizable.strings फ़ाइल से स्थानीयकृत स्ट्रिंग कुंजी को पास करने के लिए किया जाता है। तदनुसार, धक्का संदेश डिवाइस के वर्तमान स्थानीयकरण के अनुसार प्रदर्शित किया जाता है।

पुश सूचनाओं में स्थानीयकृत तारों को प्रक्षेपित करने का तंत्र समान तरीके से काम करता है:

  "aps" : { "alert" : { "loc-key" : "message localized key"; "loc-args" : [ "First argument", "Second argument" ]; }; }; 

loc-args कुंजी तर्कों का एक सरणी पास करती है जिसे स्थानीयकृत अधिसूचना पाठ में एम्बेड किया जाना चाहिए।

संक्षेप में ...

और इसलिए, अंत में हमारे पास क्या है:

• सरल और सुलभ सिंटैक्स के साथ विशेष .string फ़ाइलों में स्ट्रिंग डेटा संग्रहीत करने के लिए मानक;
• कोड में अतिरिक्त जोड़तोड़ के बिना इंटरफ़ेस को स्थानीय बनाने की क्षमता;
• कोड से स्थानीय संसाधनों तक त्वरित पहुंच;
• स्थानीयकरण फ़ाइलों की स्वचालित पीढ़ी और Xcode टूल का उपयोग करके प्रोजेक्ट डायरेक्टरी (एप्लिकेशन) के संसाधनों को संरचित करना;
• अधिसूचना पाठ को स्थानीय बनाने की क्षमता।

, Xcode , .

.