Globalization: क्या है, i18n और ऐप्स में बहुभाषी समर्थन

Globalization (i18n) क्या है और इसकी आवश्यकता क्यों है?

Globalization (संक्षिप्त रूप i18n — "i" और "n" के बीच 18 अक्षर) — किसी भी भाषा और क्षेत्र के साथ काम करने के लिए ऐप का वास्तुशिल्पीय तैयारी है। i18n का मुख्य नियम: कोई भी टेक्स्ट स्ट्रिंग स्रोत कोड में हार्डकोडेड (hardcoded) नहीं होनी चाहिए। इसके बजाय, स्ट्रिंग्स को संसाधन फ़ाइलों में निकाला जाता है, और कोड उन्हें कुंजियों (keys) के माध्यम से एक्सेस करता है। नई भाषा जोड़ते समय, केवल अनुवाद फ़ाइल जोड़ना पर्याप्त है — कोड अपरिवर्तित रहता है। यह i18n को स्थानीयकरण (l10n) से अलग करता है, जहाँ स्ट्रिंग्स का स्वयं अनुवाद किया जाता है।

व्यावसायिक तर्क — वैश्वीकरण बाज़ार का विस्तार करता है। Common Sense Advisory (2023) के अनुसार, 70% से अधिक उपयोगकर्ता अपनी मातृभाषा में ऐप्स में खरीदारी पसंद करते हैं। 10 भाषाओं में स्थानीयकरण संभावित दर्शकों को 80% तक बढ़ाता है। i18n के बिना, प्रत्येक नई भाषा में विस्तार के लिए कोड में बदलाव की आवश्यकता होती है, जो बाज़ार में प्रवेश को धीमा करता है और लागत को 5–10 गुना बढ़ाता है। सही i18n आर्किटेक्चर न्यूनतम लागत पर 40+ भाषाओं का समर्थन करने की अनुमति देता है।

i18n के घटक शामिल हैं: स्ट्रिंग बाहरीकरण (String externalization), बहुवचन (pluralization 1/2/5+ के लिए), तिथियों और संख्याओं का स्वरूपण (DateFormatter/SimpleDateFormat), RTL भाषाओं का समर्थन (Right-to-Left), लोकेल-आधारित छँटाई (Collator), क्षेत्रीय प्रतीक (हज़ार विभाजक, दशमलव चिह्न)। IT Sectr में, हम i18n को आर्किटेक्चर चरण में शामिल करते हैं, बाद में नहीं — इससे बाद के स्थानीयकरण में 60% तक समय बचता है।

iOS में अंतर्राष्ट्रीयकरण: NSLocalizedString और XLIFF

NSLocalizedString — अनुवाद के साथ काम करने का प्रमुख Swift मैक्रो। प्रारूप: NSLocalizedString("key", comment: "अनुवादक के लिए विवरण")। मैक्रो स्वचालित रूप से डिवाइस की वर्तमान लोकेल (NSLocale.preferredLanguages) के लिए Localizable.strings से स्ट्रिंग प्रतिस्थापित करता है। यदि कुंजी के लिए अनुवाद नहीं मिलता है, तो कुंजी स्वयं या विकास भाषा (आमतौर पर en) में मान लौटाया जाता है। Apple सार्थक कुंजियाँ उपयोग करने की सलाह देता है, न कि अंग्रेज़ी स्ट्रिंग्स को कुंजियों के रूप में।

// Localizable.strings (en)
// "welcome_title" = "Welcome!";
// Localizable.strings (ru)
// "welcome_title" = "स्वागत है!";

// Swift कोड — सभी भाषाओं के लिए एकीकृत
titleLabel.text = NSLocalizedString(
    "welcome_title",
    comment: "स्वागत स्क्रीन शीर्षक"
)

// Localizable.stringsdict के माध्यम से बहुवचन
// 
// <dict>
//     <key>items_count</key>
//     <dict>
//         <key>NSStringLocalizedFormatKey</key>
//         <string>%#@items@</string>
//         <key>items</key>
//         <dict>
//             <key>one</key>
//             <string>%d उत्पाद</string>
//             <key>few</key>
//             <string>%d उत्पाद</string>
//             <key>many</key>
//             <string>%d उत्पाद</string>
//         </dict>
//     </dict>
// </dict>

// बहुवचन का उपयोग
let items = 5
let label = String.localizedStringWithFormat(
    NSLocalizedString("items_count", comment: ""), items
)

XLIFF — डेवलपर्स और अनुवादकों के बीच अनुवाद आदान-प्रदान का प्रारूप। Xcode एक XLIFF फ़ाइल निर्यात करता है (Editor → Export for Localization) जिसमें अनुवाद के लिए सभी स्ट्रिंग्स होती हैं। अनुवादक CAT टूल्स (Trados, memoQ, Smartcat) में XLIFF के साथ काम करता है। अनुवाद के बाद, XLIFF वापस Xcode में आयात किया जाता है (Editor → Import Localizations)। XLIFF स्वचालित रूप से सभी .lproj निर्देशिकाओं को अपडेट करता है। यह प्रोडक्शन में iOS ऐप्स के स्थानीयकरण का मानक कार्यप्रवाह है।

SwiftUI और i18n

SwiftUI Text इनिशियलाइज़र के माध्यम से NSLocalizedString के साथ काम करता है। SwiftUI में टेक्स्ट स्वचालित रूप से अंतर्राष्ट्रीयकृत होता है: Text("welcome_title") NSLocalizedString की तरह ही Localizable.strings में अनुवाद खोजता है। बहुवचन के लिए, Text("%d items", count: items) का उपयोग करें। SwiftUI Text(date, style: .date) के माध्यम से तिथि स्वरूपण का समर्थन करता है — यह स्वचालित रूप से Locale.current का उपयोग करता है। Apple नई परियोजनाओं के लिए SwiftUI की सिफारिश करता है क्योंकि इसमें अंतर्राष्ट्रीयकरण अधिक पारदर्शी है।

Android में अंतर्राष्ट्रीयकरण: strings.xml और RTL

Android i18n संसाधन प्रणाली पर आधारित है। स्ट्रिंग्स डिफ़ॉल्ट भाषा (आमतौर पर अंग्रेज़ी) के लिए res/values/strings.xml में रखी जाती हैं। प्रत्येक भाषा के लिए एक अलग निर्देशिका बनाई जाती है: res/values-ru/strings.xml (रूसी), res/values-de/strings.xml (जर्मन), res/values-fr/strings.xml (फ़्रेंच)। Android डिवाइस की सिस्टम भाषा (Locale.getDefault()) के आधार पर स्वचालित रूप से स्ट्रिंग्स चुनता है। यदि सटीक लोकेल नहीं मिलता है, तो आधार (values/strings.xml) का उपयोग किया जाता है।

// res/values/strings.xml (अंग्रेज़ी, डिफ़ॉल्ट)
<resources>
    <string name="welcome_title">Welcome!</string>
    <string name="items_count">%d item(s)</string>
</resources>

// res/values-ru/strings.xml (रूसी)
<resources>
    <string name="welcome_title">स्वागत है!</string>
    <plurals name="items_count">
        <item quantity="one">%d वस्तु</item>
        <item quantity="few">%d वस्तुएँ</item>
        <item quantity="many">%d वस्तुएँ</item>
    </plurals>
</resources>

// Kotlin कोड
textView.text = getString(R.string.welcome_title)

// बहुवचन
val items = 5
textView.text = resources.getQuantityString(
    R.plurals.items_count, items, items
)

// कोड में RTL समर्थन
textView.textDirection = View.TEXT_DIRECTION_LOCALE
// Manifest: supportsRtl="true"

RTL (Right-to-Left) — उन भाषाओं का समर्थन जहाँ टेक्स्ट दाएँ से बाएँ पढ़ा जाता है (अरबी, हिब्रू, उर्दू, फ़ारसी)। Android android:layoutDirection और android:textDirection विशेषताओं के माध्यम से RTL का समर्थन करता है। मैनिफ़ेस्ट में android:supportsRtl="true" निर्दिष्ट करें — और Android स्वचालित रूप से लेआउट को मिरर करेगा। NavDrawer, बैक/फ़ॉरवर्ड आइकन, टेक्स्ट संरेखण दोनों दिशाओं में काम करना चाहिए। कोड में LEFT/RIGHT के बजाय View.LAYOUT_DIRECTION_LOCALE और Gravity.START/END का उपयोग करें।

स्थानीयकृत संसाधन

Android Resource Qualifiers न केवल स्ट्रिंग्स बल्कि छवियों (res/drawable-ru/), लेआउट (res/layout-ru/), एनिमेशन, रंगों को भी स्थानीयकृत करने की अनुमति देते हैं। अरबी और हिब्रू के लिए, दर्पणित तत्वों वाले अलग लेआउट की आवश्यकता होती है — res/layout-ar/ (अरबी) का उपयोग करें। Android क्षेत्रीय वेरिएंट का भी समर्थन करता है: values-rUS, values-rGB, values-de-DE। क्वालिफ़ायर को संयोजित किया जा सकता है: values-ldrtl-ru — RTL डिस्प्ले के लिए रूसी।

क्षेत्रीय प्रारूप: iOS और Android में तिथियाँ, संख्याएँ, मुद्रा

तिथियाँ और समय — i18n के प्रमुख पहलुओं में से एक। विभिन्न क्षेत्र विभिन्न प्रारूपों का उपयोग करते हैं: रूस — DD.MM.YYYY, USA — MM/DD/YYYY, जापान — YYYY.MM.DD। उपयोगकर्ता को प्रदर्शित करने के लिए निश्चित प्रारूप (yyyy-MM-dd) का उपयोग करना एक गलती है। iOS में, Locale(identifier: locale) के साथ DateFormatter का उपयोग करें, Android में — DateFormat.getDateInstance(DateFormat.SHORT, locale)। वॉइस असिस्टेंट और AI खोज के लिए, तिथियाँ आंतरिक रूप से ISO 8601 में होनी चाहिए।

संख्याएँ और मुद्रा — विभिन्न क्षेत्रों में अलग-अलग विभाजक होते हैं: 1,234.56 (USA) बनाम 1.234,56 (रूस), 1 234,56 (फ़्रांस)। iOS: .locale = locale के साथ NumberFormatter। Android: DecimalFormatSymbols(locale) के साथ DecimalFormat। मुद्राओं के लिए: प्रारूप ¥1,234 (जापान) बनाम $1,234.56 (USA) बनाम 1 234,56 ₽ (रूस)। मुद्रा और संख्या को कभी भी मैन्युअल रूप से संयोजित न करें — NumberFormatter.currencyCode और .currencySymbol का उपयोग करें।

छँटाई (Collation) — वर्णमाला क्रम विभिन्न भाषाओं में भिन्न होता है। स्पेनिश में, "ch" "c" के बाद आता है। स्वीडिश में, "ä" वर्णमाला के अंत में है। जर्मन में, "ß" को "ss" के रूप में क्रमबद्ध किया जाता है। iOS: LocalizedComparison (String.localizedCompare)। Android: Collator.getInstance(locale)। उपयोगकर्ता को प्रदर्शित स्ट्रिंग्स के लिए compareTo() का कभी उपयोग न करें — यह Unicode Code Point क्रम का उपयोग करता है, जो क्षेत्रीय नियमों पर विचार नहीं करता।

मोबाइल ऐप अंतर्राष्ट्रीयकरण की सर्वोत्तम प्रथाएँ

वास्तुशिल्पीय सिद्धांत — i18n को पहले commit से शुरू करें। कोड में प्रत्येक स्ट्रिंग को एक रैपर फ़ंक्शन (tr("key")) से गुज़रना चाहिए जो i18n सेट होने तक मौजूद नहीं होता — यह डेवलपर को तुरंत स्ट्रिंग बाहरीकरण करने के लिए मजबूर करता है। अंग्रेज़ी स्ट्रिंग्स को कुंजियों के रूप में उपयोग न करें — जब अंग्रेज़ी शब्दावली बदलती है, तो सभी अनुवादों को अद्यतन करना होगा। सार्थक कुंजियाँ उपयोग करें: "profile.title", "settings.language.label"।

स्यूडोलोकलाइज़ेशन (Pseudolocalization) — वास्तविक अनुवाद से पहले i18n परीक्षण की एक तकनीक। एन्कोडिंग जाँचने के लिए प्रत्येक लैटिन अक्षर को विशेषक चिह्नों (á, é, ñ, ü) वाले अक्षरों से बदलें, स्ट्रिंग कटाव की जाँच के लिए [XXX] उपसर्ग जोड़ें। Xcode: रन स्कीम — "Double-Length Pseudolanguage" छद्म भाषा। Android: डेवलपर विकल्प — फ़ोर्स RTL लेआउट दिशा, सिस्टम फ़ॉन्ट स्केल 200% तक। स्यूडोलोकलाइज़ेशन अनुवादक की भागीदारी के बिना 80% i18n समस्याओं का पता लगाता है।

IT Sectr i18n जाँच सूची — रिलीज़ से पहले हम जाँचते हैं: (1) कोड में कोई हार्डकोडेड स्ट्रिंग नहीं (अपवाद: लॉग), (2) बहुवचन सभी भाषाओं के लिए सही ढंग से काम करते हैं, (3) तिथियाँ/संख्याएँ Locale API के माध्यम से स्वरूपित होती हैं, (4) लेआउट RTL भाषाओं पर सही ढंग से प्रदर्शित होता है, (5) अधिकतम स्केलिंग पर स्ट्रिंग नहीं कटतीं, (6) स्यूडोलोकलाइज़ेशन में कोई त्रुटि नहीं, (7) स्टोर में घोषित सभी भाषाओं के पास अनुवादों का पूरा सेट है।