अनुप्रयोग स्थानीयकरण और RTL समर्थन। रिपोर्ट Yandex.Taxi

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


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



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

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



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

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



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



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



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



अगली बार जब git स्टेटस निष्पादित किया जाता है, तो डेवलपर उसकी कार्यशील निर्देशिका में देखता है कि कौन सी फाइलें बदल गई हैं।



वह जनरेट की गई HTML रिपोर्ट में यह भी देख सकता है कि किस कुंजी के लिए किस भाषा में कौन सा मूल्य बदल गया है।



और वह यह भी देख सकता है कि वर्तमान में उसकी परियोजना के अनुवाद में क्या समस्याएं हैं।



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



एक विशिष्ट रीमैपिंग सुविधा भी है। जब मैं RTL के बारे में बात करूंगा तो मैं इसके बारे में थोड़ा और विस्तार से बात करूंगा।

अब यह प्लगइन किन समस्याओं का विश्लेषण करता है? 2014 में हमारे सामने जो समस्या थी, वह आम है, अनुवाद की कमी। अब, परियोजना में एक नई लाइन, एक नया अनुवाद जोड़ने के लिए, डेवलपर के लिए बस XML फ़ाइल में इसे परिभाषित करने के लिए पर्याप्त नहीं है।



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



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



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

लेकिन एक ही समय में, कुछ अनुवादों में वे लाइन पर संख्या को बदलना भूल गए।



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

यह सब स्थानीयकरण के बारे में है।

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



आप कहाँ से शुरू करना चाहते हैं? एंड्रॉइड के साथ, सिद्धांत रूप में, राइट-टू-लेफ्ट रेंडरिंग समर्थन बॉक्स से काफी अच्छी तरह से लागू किया गया है।

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

मुझे लगता है कि दर्शकों में बैठे अधिकांश लोगों को संभवतः Android 4.4 के लिए न्यूनतम समर्थन प्राप्त है। कोई अधिक भाग्यशाली है - यह 5.0 और उच्चतर है। कोई व्यक्ति कम भाग्यशाली हो सकता है, और वे 4.0, या, भगवान ना करे, 2.3 का समर्थन करते हैं। इस मामले में, आपको बड़ी समस्याएं होंगी, क्योंकि एंड्रॉइड में पूर्ण-आरटीएल समर्थन 4.2 संस्करण के बाद से दिखाई दिया है। इसलिए, 17 वें मिनट के साथ, आप परिमाण के क्रम से अपने जीवन को सरल बनाएंगे।

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

UI को कस्टमाइज़ करने और टेक्स्ट को रेंडर करने के लिए विकल्प क्या हैं RTL?



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

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

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



या तो यह एक ईस्टर अंडे है, या क्या यह editText के कार्यान्वयन में ऐसा दुष्प्रभाव है: editText पर आपका संकेत तितर-बितर होने लगता है। इसलिए, किसी भी मामले में, आपको उसके लिए कुछ मूल्य निर्धारित करना होगा।

^{_{स्लाइड से लिंक करें}}

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

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

लेकिन अगर ऐसा कुछ विशिष्ट है, तो w3.org के पास इन प्रतीकों का उपयोग करने का एक अच्छा लेख है ।

जब हम अपने आवेदन में आरटीएल समर्थन शुरू करते हैं तो हमें क्या समस्याएं आती हैं? सबसे पहले, यह स्थानीयकरण मानकों का संघर्ष है।

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

^{_{स्लाइड से लिंक करें}}

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

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



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

एक समस्या जो शायद केवल प्रतिबिंब द्वारा हल की जाती है, क्योंकि यह घटक में कठोरता से लागू होती है, यह TextInputLayout का संकेत संरेखण है। तथ्य यह है कि यदि हिब्रू में आरटीएल मजबूत पात्रों में संकेत निर्दिष्ट किया गया है, तो यह स्पष्ट रूप से दाईं ओर संरेखित किया जाएगा, भले ही आप संपादित पाठ में जो सामग्री दर्ज करते हैं वह लैटिन वर्णों से हो सकती है। और इसके विपरीत। यदि आपका संकेत लैटिन में है, तो यह स्पष्ट रूप से बाईं ओर संरेखित किया जाएगा। इसे केवल परावर्तन के साथ हल किया जा सकता है।



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

^{_{स्लाइड से लिंक करें}}

यदि आप आवेदन में RTL का समर्थन करते हैं, लेकिन आपके आवेदन का minSdkVersion 17 से नीचे है, तो आपको बाएं और दाएं प्रकार की विशेषताओं का उपयोग करना जारी रखना होगा, आप अपने मार्कअप में केवल प्रारंभ और अंतिम विशेषताओं का उपयोग नहीं कर सकते। यह RtlCompat पर्स है। RtlSymmetry शपथ लेता है जब वह असममित गद्दी देखता है। सामान्य तौर पर, मेरी राय यह है कि संसाधन को संसाधित करते समय, यदि यह सममित पैडिंग के दौरान आता है तो दुर्घटनाग्रस्त हो जाना चाहिए। यदि आपको किसी प्रकार के असममित एक्सेस की आवश्यकता है, तो पूर्ण-लेआउट लेआउट पैरामीटर के रूप में मार्जिन का उपयोग करें।

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

मेरी रिपोर्ट एक करीबी को आकर्षित कर रही है। मैं अपने आवेदन में सही स्थानीयकरण के निर्माण पर कुछ शोध करना चाहता हूं, जो कि हम समय के साथ आए हैं।



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

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

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

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

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

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