App Store क्रॉस-लोकलाइज़ेशन: फ्री कीवर्ड स्पेस जो ज़्यादातर ऐप्स बर्बाद कर देते हैं
App Store Connect में एक कीवर्ड-फ़ील्ड ट्रिक बिल्कुल सामने पड़ी होती है, इसकी कोई कीमत नहीं है, और फिर भी ज़्यादातर ऐप्स इसे छूते तक नहीं। यह न कोई लूपहोल है, न ही नियमों के खिलाफ। बस इतना है कि Apple हर स्टोरफ्रंट पर एक से ज़्यादा भाषा इंडेक्स करता है, और लगभग कोई भी दूसरी वाली नहीं भरता।
इसका तरीका यह है। हर App Store टेरिटरी का एक प्राइमरी लोकेल होता है — उस मार्केट की डिफ़ॉल्ट भाषा — और एक या ज़्यादा सेकेंडरी लोकेल भी होते हैं जिन्हें Apple का सर्च एल्गोरिदम भी क्रॉल करता है। किसी भी लोकेल के मेटाडेटा में मौजूद कीवर्ड आपको उस देश में रैंक करा सकते हैं। यानी US स्टोर सिर्फ आपकी English (U.S.) फ़ील्ड नहीं पढ़ता; वह आपकी Spanish (Mexico) फ़ील्ड भी पढ़ता है। दोनों को अलग-अलग शब्दों से भर दें और आपने Apple को एक की जगह दो कीवर्ड सेट रैंक करने के लिए दे दिए।
यह फ्री स्पेस क्यों है
एक अकेला लोकेल आपको तीन इंडेक्स्ड फ़ील्ड देता है: 30-कैरेक्टर का ऐप नाम, 30-कैरेक्टर का सबटाइटल, और 100-कैरेक्टर की कीवर्ड फ़ील्ड। यानी हर लोकेल के 160 इंडेक्स्ड कैरेक्टर। डिस्क्रिप्शन App Store पर सर्च के लिए इंडेक्स नहीं होता, इसलिए यही 160 कैरेक्टर पूरा खेल हैं।
एक सेकेंडरी लोकेल इन्हीं तीन फ़ील्ड का दूसरा सेट होता है, जो उसी स्टोरफ्रंट की रैंकिंग को फीड करता है। एक US ऐप के लिए es-MX कीवर्ड फ़ील्ड भर दें तो आप 100 कैरेक्टर के छिपे कीवर्ड से बढ़कर लगभग 200 पर पहुंच जाते हैं — साथ ही एक और 30-कैरेक्टर का सबटाइटल जिसे Apple भी इंडेक्स करेगा। वही ऑडियंस, वही स्टोर, लगभग दोगुनी जगह। इसके लिए आपको कोई पैसा नहीं देना, फ़ायदे के लिए Spanish बोलने वाले यूज़र्स की भी ज़रूरत नहीं, और अलग लिस्टिंग की भी ज़रूरत नहीं — बस फ़ील्ड को खाली छोड़ना बंद करना है।
इसे "बर्बाद" स्पेस इसलिए कहा जाता है क्योंकि यह फ़ील्ड लगभग हमेशा खाली रहती है, या इससे भी बुरा, प्राइमरी लोकेल की कॉपी से भर दी जाती है। दोनों ही सूरतों में मौका गंवा दिया जाता है।
रेफरेंस टेबल: हर स्टोरफ्रंट कौन-से लोकेल इंडेक्स करता है
यह वह मैप है जिसे बुकमार्क करना समझदारी है। हर स्टोरफ्रंट के लिए यह Apple द्वारा इंडेक्स किया गया प्राइमरी लोकेल और वे सेकेंडरी लोकेल बताता है जिन्हें वह भी क्रॉल करता है। ये मैपिंग 2026 में ASO टूलिंग द्वारा दस्तावेज़ीकृत हैं — Apple समय-समय पर इन्हें बदलता रहता है, इसलिए लिखने से पहले App Store Connect या अपने ASO टूल में अपने मुख्य मार्केट कन्फर्म कर लें:
| Japan | Japanese — ja | English (U.S.) — en-US |
*US स्टोरफ्रंट अपवाद है: es-MX के साथ-साथ यह French, Simplified Chinese, Traditional Chinese, Korean, Portuguese (Brazil), Russian, Arabic, और Vietnamese भी इंडेक्स करता है — कुल मिलाकर नौ सेकेंडरी लोकेल।
टेबल से दो पैटर्न निकलते हैं। पहला, English (U.K.) सबसे भरोसेमंद सेकेंडरी है — यह ज़्यादातर non-English स्टोरफ्रंट में बैकअप लोकेल के तौर पर इंडेक्स होता है, जिससे en-GB फ़ील्ड भरना, अगर आप ग्लोबल स्तर पर बेचते हैं, तो सबसे मूल्यवान काम बन जाता है। दूसरा, US नौ सेकेंडरी लोकेल के साथ असामान्य रूप से उदार है, इसी वजह से es-MX वाली चाल के बारे में सबसे ज़्यादा लिखा जाता है।
पेच: सिर्फ अलग शब्द चलेंगे
दोगुना होने का फ़ायदा तभी मिलता है जब दूसरे लोकेल में ऐसे शब्द हों जो पहले में न हों। Apple के दो नियम इसे बिल्कुल स्पष्ट करते हैं, और दोनों आलसी तरीके के खिलाफ जाते हैं:
- हर शब्द सिर्फ एक बार इंडेक्स होता है। अगर कोई शब्द प्राइमरी और सेकेंडरी दोनों कीवर्ड फ़ील्ड में मौजूद है, तो डुप्लीकेट का कोई फ़ायदा नहीं होता। अपनी en-US कीवर्ड लिस्ट को es-MX में कॉपी कर दें और आपने दूसरी फ़ील्ड को बिना किसी अतिरिक्त रीच के जला दिया।
- लोकेल के बीच शब्द नहीं जुड़ते। Apple मल्टी-वर्ड फ्रेज़ सिर्फ एक ही लोकलाइज़ेशन के भीतर बनाता है, दो के बीच कभी नहीं। en-US में "budget" और es-MX में "presupuesto" डालें तो आप हर शब्द के लिए अलग-अलग रैंक कर सकते हैं — पर एक ऐसे फ्रेज़ के लिए नहीं जो दोनों को जोड़ता हो।
इसलिए सही तरीका यह नहीं है कि अपने प्राइमरी कीवर्ड को सेकेंडरी फ़ील्ड में अनुवाद कर दिया जाए। सही तरीका यह है कि वहां बिल्कुल अलग सिंगल शब्दों का सेट डाला जाए — वे शब्द जो पहले 100 कैरेक्टर में फिट नहीं हो पाए, पर्यायवाची, नज़दीकी यूज़-केस, लॉन्ग-टेल वेरिएंट। दूसरी फ़ील्ड ओवरफ्लो स्पेस है, कोई मिरर नहीं।
यही वजह है कि सिर्फ "सब कुछ अनुवाद कर दो" वाला भोला तरीका समस्या को कम नहीं, ज़्यादा कर देता है। अपनी English कीवर्ड फ़ील्ड को मशीन-अनुवाद करके Spanish में डालने से वही कॉन्सेप्ट दूसरी भाषा में बनते हैं, जो एक साझा स्टोरफ्रंट के लिए मतलब में डुप्लीकेशन ही रहता है, और अक्सर Apple की मैचिंग में भी। असली फ़ायदा दूसरी फ़ील्ड को विविध बनाने में है, न कि पहली का शब्द-दर-शब्द अनुवाद करने में।
दूसरी फ़ील्ड को असल में कैसे इस्तेमाल करें
एक US बजटिंग ऐप के लिए एक उदाहरण। प्राइमरी en-US फ़ील्ड में पहले से ही स्पष्ट शब्द मौजूद हैं — मान लीजिए नाम है Ledger: Budget & Money और सबटाइटल है Track spending and savings, और en-US कीवर्ड फ़ील्ड में expense,bills,debt,invoice,net worth,cash flow,receipt,tax,loan,credit रखा है।
es-MX कीवर्ड फ़ील्ड अब पूरी तरह से एक अलग सिंगल-शब्द बैग रखने के लिए फ्री है — जिसमें नाम, सबटाइटल, या en-US फ़ील्ड का कोई शब्द दोहराया न गया हो — जैसे subscription,paycheck,allowance,envelope,forecast,split,reimburse,wallet,goal,statement। यह वही US रैंकिंग को फीड करने वाली दूसरी 100-कैरेक्टर फ़ील्ड है, जो उन शब्दों से भरी है जो Apple पहले नहीं देख पाता था। एक अलग es-MX सबटाइटल जोड़ें और आपने नाम-प्लस-सबटाइटल सिग्नल को भी बढ़ा दिया।
यही तर्क बाकी टेबल पर भी लागू होता है। एक German ऐप en-GB को English ओवरफ्लो शब्दों से भरता है। एक Canadian ऐप fr-CA भरता है। एक Brazilian ऐप en-GB भरता है। हर मामले में दूसरी फ़ील्ड अलग शब्द है, अनुवाद नहीं, और हर शब्द अब भी ईमानदारी से ऐप का वर्णन करता है — जिससे आप Apple की गाइडलाइन 2.3.7 (अप्रासंगिक या ट्रेडमार्क वाले कीवर्ड) से बचे रहते हैं।
यह अनुवाद का नहीं, रिसर्च का काम क्यों है
ज़्यादातर ऐप्स इस स्पेस को बर्बाद इसलिए करते हैं क्योंकि इसे सही ढंग से भरना असल मेहनत का काम है। आपको प्राइमरी लोकेल के लिए एक कीवर्ड सेट चाहिए, फिर सेकेंडरी लोकेल के लिए एक दूसरा, बिल्कुल अलग सेट, और यह हर उस स्टोरफ्रंट के लिए चाहिए जिसकी आपको परवाह है। App Store की 50 मेटाडेटा भाषाओं से गुणा करें तो अलग रखने वाली सेकेंडरी फ़ील्ड की संख्या तेज़ी से बढ़ जाती है। यह समझना आसान है कि क्यों टीमें या तो सेकेंडरी फ़ील्ड छोड़ देती हैं या प्राइमरी वाली ही पेस्ट करके आगे बढ़ जाती हैं।
Mokbi में यही ड्राफ्टिंग और बहीखाता का काम रहता है। यह सिर्फ एक स्क्रीनशॉट एडिटर नहीं, पूरा स्टोर-लिस्टिंग पब्लिशर है: फ़्लो Screenshots → Feature graphic → Store text → Translate → Publish चलता है, और यह लिस्टिंग टेक्स्ट — नाम, सबटाइटल, कीवर्ड फ़ील्ड, डिस्क्रिप्शन — का ड्राफ्ट तैयार करता है और 50 भाषाओं में हर-लोकेल कीवर्ड सेट मैनेज करता है ताकि आप साथ-साथ देख सकें कि हर फ़ील्ड में क्या है और आप कहां गलती से खुद को दोहरा रहे हैं।
यह साफ़ समझ लें कि यह क्या करता है और क्या नहीं: यह टूल खुद-ब-खुद अलग सेकेंडरी कीवर्ड नहीं बना देगा, और एक-राउंड अनुवाद आपके शब्दों को विविध बनाने के बजाय दोहरा देगा। क्रॉस-लोकलाइज़ेशन एक स्ट्रैटेजी है जिसे आप चलाते हैं — यह तय करना कि किन सेकेंडरी लोकेल को टारगेट करना है, हर एक के लिए अलग शब्द सेट लिखना, और उन्हें ओवरलैप होने से रोकना। Mokbi आपको यह सब एक स्प्रेडशीट की बजाय एक ही जगह ड्राफ्ट और व्यवस्थित करने के लिए हर-लोकेल फ़ील्ड देता है, फिर लिस्टिंग को एक्सपोर्ट करता है ताकि आप उसे खुद App Store Connect में रिव्यू करके पब्लिश कर सकें।
एक-पैराग्राफ़ वर्ज़न
पता करें कि आपके टॉप स्टोरफ्रंट कौन-सा सेकेंडरी लोकेल इंडेक्स करते हैं — ऊपर की टेबल बड़े मार्केट कवर करती है, बाकी आपका ASO टूल कवर करेगा। उस सेकेंडरी लोकेल के नाम, सबटाइटल और कीवर्ड फ़ील्ड को उन अलग शब्दों से भरें जो प्राइमरी में फिट नहीं हुए। दोनों में कभी एक शब्द न दोहराएं, और कभी यह उम्मीद न करें कि Apple उनके बीच एक फ्रेज़ बना देगा। सही ढंग से करें तो यह App Store का सबसे सस्ता कीवर्ड विस्तार है, और यह उस फ़ील्ड में बैठा है जो आपके पास पहले से है।
आगे क्या पढ़ें
- App Store कीवर्ड फ़ील्ड: सभी 100 कैरेक्टर कैसे इस्तेमाल करें
- अपनी App Store लिस्टिंग किन भाषाओं में लोकलाइज़ करें
- 2026 में App Store Connect की 50 मेटाडेटा भाषाएं
स्रोत: Apple के App Store localizations और Review Guidelines (2.3.7) डॉक्स; aso.dev पर क्रॉस-लोकलाइज़ेशन; और MobileAction का टेरिटरी-स्तरीय कीवर्ड इंडेक्सेशन पर लेख।