मुझे पता है कि कई डेवलपर इसे इस तरह करते हैं: वे अंग्रेजी में अपना ऐप विकसित करना शुरू करते हैं, और @"Tap this to do that!" के बजाय NSLoclaizedString(@"Tap this to do that!", @"Telling what to do...") डालते हैं।क्या NSLocalizedString() में "असली" कुंजी का उपयोग करना सुरक्षित है? क्या गारंटीकृत फ़ॉलबैक भाषा है?
फिर वे genstrings चलाते हैं जो इन सभी तारों को निकालने के द्वारा किसी भी तरह स्थानीयकरण योग्य .स्ट्रिंग फ़ाइल बनाता है। गन्दा हिस्सा: कोड में उपयोग किया जाने वाला लंबा टेक्स्ट कुंजी बन जाता है। यह काम करता हैं। एक दिन तक जहां आप जल्दी से अपने कोड में जाते हैं और अंग्रेजी स्ट्रिंग को बदलते हैं और स्थानीयकरण के बारे में भूल जाते हैं और यह उन सभी Localizable.strings फ़ाइलों के लिए कुंजी के रूप में कार्य करता है।
तो मैं "असली" कुंजी का उपयोग करता हूं जो स्ट्रिंग के साथ मिश्रित नहीं होता है। एक त्वरित परीक्षण के लिए मैंने अंग्रेजी और फ्रेंच में स्थानांतरित एक परियोजना बनाई। फिर मैंने सिम्युलेटर भाषा को जर्मन में सेट किया। क्योंकि, आप जानते हैं, अगर उपयोगकर्ता कभी TTTDT की तरह कुंजी देखता है तो यह बहुत चूसना होगा।
तो बस अंग्रेजी और जर्मन के साथ, मैंने डेमो ऐप लॉन्च किया। और मुझे जो मिला वह अंग्रेजी स्थानीयकरण योग्य.स्ट्रिंग्स फ़ाइल से अंग्रेजी पाठ था।
निष्कर्ष: ऐसा लगता है कि यदि ओएस भाषा ऐप द्वारा कवर नहीं की जाती है तो NSLocalizedString अंग्रेजी फ़ाइल पर वापस आ जाता है।
Quesion: मान लीजिए कि हमेशा Localizable.strings (English) फ़ाइल है, और कुंजी ठीक से स्वरूपित मानों के साथ फ़ाइल में हैं। क्या ऐसी परिस्थितियां हैं जिनके अंतर्गत NSLocalizedString विफल हो जाएगा और फिर सीधे कुंजी प्रदर्शित करेगा?
अच्छे अंक। मैं बेहतर प्रदर्शन भी जोड़ूंगा। – dontWatchMyProfile