लोकलाइज़ेशन टेस्टिंग

i18n, l10n और g11n: असल में क्या टेस्ट होता है

Internationalization (i18n) एक इंजीनियरिंग गुण है: प्रोडक्ट ऐसे बनाया जाता है कि कोड बदले बिना उसे किसी भी locale के लिए ढाला जा सके। टेक्स्ट टेम्पलेट में नहीं, resource फ़ाइलों में रहता है; तारीख़, संख्या और मुद्रा locale-aware फ़ॉर्मेटिंग API से गुज़रती हैं; टेक्स्ट की दिशा मानकर नहीं चली जाती; स्टोरेज और ट्रांसपोर्ट शुरू से अंत तक Unicode हैं। Localization (l10n) एक locale के लिए अनुकूलन है: अनुवादित strings, locale फ़ॉर्मेट, स्थानीय कंटेंट, क़ानूनी टेक्स्ट, पेमेंट तरीक़े, पते और फ़ोन के फ़ॉर्मेट। Globalization (g11n) उस बिज़नेस और इंजीनियरिंग प्रयास का व्यापक नाम है जो दोनों को जोड़कर एक प्रोडक्ट को कई बाज़ारों में उपलब्ध कराता है।

यह फ़र्क़ इसलिए मायने रखता है क्योंकि डिफ़ेक्ट अलग होते हैं। i18n डिफ़ेक्ट कोड में रहता है और हर locale में दिखता है — hard-coded मुद्रा चिह्न, जोड़-जोड़कर बना वाक्य, तय pattern से parse की गई तारीख़। l10n डिफ़ेक्ट एक locale के कंटेंट में रहता है — ग़लत शब्द, छूटा अनुवाद, ग़लत पता फ़ॉर्मेट। i18n डिफ़ेक्ट सबसे सस्ते तब मिलते हैं जब अभी कोई अनुवाद है ही नहीं, pseudo-localization से; l10n डिफ़ेक्ट के लिए असली अनुवाद चाहिए, और भाषा की गुणवत्ता के लिए मातृभाषी व्यक्ति।

• Locale — BCP 47 language tag (RFC 5646) से पहचाना जाता है: ar, ar-SA, hi-IN, en-IN। भाषा वाला हिस्सा अनुवाद चुनता है; क्षेत्र वाला हिस्सा फ़ॉर्मेट, मुद्रा और डिफ़ॉल्ट कैलेंडर चुनता है।
• Internationalization टेस्टिंग — क्या प्रोडक्ट locales को सपोर्ट कर भी सकता है? उसे pseudo-localized टेक्स्ट, Unicode डेटा, right-to-left दिशा और ग़ैर-डिफ़ॉल्ट फ़ॉर्मेट के साथ चलाएँ।
• Localization टेस्टिंग — क्या यह ख़ास locale सही है? संदर्भ में अनुवाद, फ़ॉर्मेट, सांस्कृतिक उपयुक्तता, असली strings के साथ लेआउट।

लोकलाइज़ेशन टेस्टिंग का नक्शा

लोकलाइज़ेशन टेस्टिंग ऐसे क्षेत्रों में फैली है जिनके लिए अलग कौशल और अलग डेटा चाहिए। हर locale की कवरेज प्लान करने के लिए यह नक्शा इस्तेमाल करें; आगे के सेक्शन हर क्षेत्र से गुज़रते हैं, और right-to-left लेआउट RTL टेस्टिंग गाइड में विस्तार से है।

• भाषा और अनुवाद गुणवत्ता — शब्दावली, संदर्भ, पूर्णता, plural और लिंग रूप, message parameters, truncation।
• Locale फ़ॉर्मेट — तारीख़ और कैलेंडर (ग्रेगोरियन और हिजरी), समय और time zone, संख्याएँ और अंक, मुद्रा, इकाइयाँ, पते, फ़ोन नंबर और व्यक्तिगत नाम।
• टेक्स्ट और लिपि हैंडलिंग — encoding, Unicode normalization, grapheme cluster, फ़ॉन्ट, sorting, search और input methods।
• लेआउट — टेक्स्ट का फैलना और सिकुड़ना, लाइन के ऊपर-नीचे चिह्नों वाली लिपियों के लिए line height, और अरबी के लिए पूरा right-to-left mirroring और bidirectional-text क्षेत्र।
• Locale चयन और fallback — प्रोडक्ट locale कैसे चुनता है (यूज़र सेटिंग, Accept-Language हेडर, डिवाइस, URL), असमर्थित locale पर क्या होता है, और क्या चुनाव ईमेल, PDF, SMS और push notification तक पहुँचता है।
• हर locale में एक्सेसिबिलिटी — lang एट्रिब्यूट जो screen reader को बताता है कि कौन-सी आवाज़ और उच्चारण नियम इस्तेमाल करने हैं, और आइकन व कंट्रोल के अनुवादित accessible names।

भाषा और अनुवाद की गुणवत्ता

अनुवादक आमतौर पर स्क्रीन देखे बिना स्प्रेडशीट या translation-management सिस्टम से काम करते हैं, और कई अनुवाद डिफ़ेक्ट यहीं से आते हैं। अंग्रेज़ी का "Save" क्रिया (फ़ाइल सेव करें) भी हो सकता है और संज्ञा (डिस्काउंट में बचत) भी; "Open" स्टेटस भी हो सकता है और कमांड भी; बिना संदर्भ के अनुवादक एक चुन लेता है। टेस्टर का काम है हर string को असली स्क्रीन पर देखना और स्क्रीनशॉट के साथ string key रिपोर्ट करना, ताकि सुधार सही resource में पहुँचे।

Plural सबसे आम संरचनात्मक डिफ़ेक्ट है। अंग्रेज़ी में दो cardinal plural रूप हैं। Unicode CLDR के plural नियम अरबी को छह श्रेणियाँ देते हैं — zero (0), one (1), two (2), few (जिन संख्याओं के आख़िरी दो अंक 3–10 हों, जैसे 3 या 103), many (आख़िरी दो अंक 11–99) और other (जैसे 100–102) — और हिंदी को दो, जिसमें "one" रूप 0 और 1 दोनों के लिए है। जो कोड count === 1 से रूप चुनता है वह अरबी के लिए बनावट से ही ग़लत है। सुधार है plural श्रेणियों वाला message format; टेस्ट है संख्याओं की ऐसी तालिका जो हर श्रेणी को छुए।

• शब्दावली की एकरूपता — स्क्रीन, हेल्प पेज और ईमेल में हर अवधारणा के लिए एक ही शब्द, glossary से मिलान करके। एक स्क्रीन पर कार्ट को "सला" (سلة) और दूसरी पर "अरबा" (عربة) कहना डिफ़ेक्ट है।
• अनअनुवादित strings — अरबी या हिंदी इंटरफ़ेस के भीतर छूटी अंग्रेज़ी; validation मैसेज, API एरर, ईमेल और स्प्रिंट के आख़िर में जोड़ी गई strings में आम।
• Concatenated strings — टुकड़ों से बने वाक्य ("You have" + n + "items") सही अनुवादित नहीं हो सकते क्योंकि शब्द-क्रम और अन्वय अलग होते हैं; हर वाक्य parameters वाला एक message होना चाहिए।
• Message parameters — अनुवाद के भीतर {name} या %s बिना बदले बचे रहने चाहिए; अनुवादित या हटाया गया parameter कच्चे braces दिखाता है या formatter को क्रैश कर देता है।
• लिंग और संबोधन — अरबी क्रियाएँ और विशेषण लिंग से मेल खाते हैं; तय करें कि मैसेज यूज़र को कैसे संबोधित करें और जाँचें कि फ़ैसला एकरूप लागू है। हिंदी में आप/तुम का चुनाव भी इसी तरह तय करें।

# ICU MessageFormat, Arabic: one message, six CLDR plural categories
cart.items = {count, plural,
  zero  {السلة فارغة}
  one   {منتج واحد في السلة}
  two   {منتجان في السلة}
  few   {# منتجات في السلة}
  many  {# منتجًا في السلة}
  other {# منتج في السلة}
}

# Counts that hit every Arabic category
0 (zero) · 1 (one) · 2 (two) · 3, 10, 103 (few) · 11, 99 (many) · 100, 101, 102 (other)

# Hindi has two categories: one (0 and 1) and other
0, 1 (one) · 2, 5, 1.5 (other)

Pseudo-localization: अनुवाद से पहले i18n डिफ़ेक्ट खोजें

Pseudo-localization हर UI string को अपने-आप बदले गए ऐसे रूप से बदल देता है जिसे टीम अब भी पढ़ सके: accent वाले अक्षर, अतिरिक्त लंबाई, और हर message की शुरुआत और अंत बताने वाले ब्रैकेट। प्रोडक्ट को pseudo-locale में चलाएँ और हर वह डिफ़ेक्ट श्रेणी तुरंत दिख जाती है जिसके लिए असली अनुवाद ज़रूरी नहीं — hard-coded टेक्स्ट सादी अंग्रेज़ी रहता है, जोड़कर बना वाक्य कई ब्रैकेट वाले टुकड़ों में दिखता है, truncation आख़िरी ब्रैकेट काट देता है, और ASCII के बाहर के अक्षर encoding समस्याएँ उजागर करते हैं।

Android दो pseudo-locale देता है जिन्हें debug बिल्ड में चालू किया जा सकता है: English (XA), जो accent जोड़ता है, टेक्स्ट लंबा करता है और हर message को ब्रैकेट में रखता है; और AR (XB), जो दिशा right-to-left कर देता है और अक्षरों का क्रम उलट देता है, ताकि टीम कोई RTL भाषा जाने बिना mirroring और bidirectional समस्याएँ पकड़ सके। वेब पर pseudo-locale आमतौर पर एक और resource फ़ाइल होती है जो बिल्ड के दौरान source strings से जनरेट होती है।

Source (en):           Save changes
Pseudo (expanded):     [Ŝàṽé çĥàñĝéš ·····]
RTL pseudo:            same text, base direction switched to right-to-left

What each symptom on screen means:
  Save changes            -> hard-coded string, never externalised
  [Ŝàṽé] [çĥàñĝéš]         -> sentence assembled by concatenation
  [Ŝàṽé çĥàñĝ             -> truncated: no room for longer translations
  [Ŝ?ṽ? ?ĥ?ñĝ?š]          -> characters lost in an encoding conversion

तारीख़, कैलेंडर और time zone

तारीख़ का फ़ॉर्मेट सिर्फ़ दिन और महीने का क्रम नहीं है। Locale तय करता है कैलेंडर, महीनों के नाम, अंक, separator, हफ़्ते का पहला दिन और 12 या 24 घंटे की घड़ी। सऊदी अरब में दो कैलेंडर रोज़ इस्तेमाल होते हैं: ग्रेगोरियन कैलेंडर और हिजरी कैलेंडर, जिसे सऊदी अरब Umm al-Qura (उम्म अल-क़ुरा) कैलेंडर के रूप में मानकीकृत करता है। कई प्रोडक्ट दोनों दिखाते हैं या यूज़र को चुनने देते हैं; जो भी जगह तारीख़ दिखाती, लेती, स्टोर करती या तुलना करती है, उसे साफ़ होना चाहिए कि वह कौन-सा कैलेंडर इस्तेमाल करती है।

यह मानकर न चलें कि "ar-SA" क्या देगा। Locale के डिफ़ॉल्ट runtime के भीतर के CLDR डेटा से आते हैं और वर्ज़न के साथ बदलते हैं: पुराने runtime ar-SA तारीख़ें डिफ़ॉल्ट रूप से हिजरी कैलेंडर में दिखाते थे, जबकि नए runtime अरबी-इंडिक अंकों के साथ ग्रेगोरियन कैलेंडर इस्तेमाल करते हैं। कैलेंडर और numbering system स्पष्ट रूप से माँगें — जैसे Unicode locale extensions ar-SA-u-ca-islamic-umalqura या ar-SA-u-nu-latn से — और नतीजा हर उस runtime पर टेस्ट करें जिसे आप शिप करते हैं: सर्वर, ब्राउज़र और मोबाइल। अलग-अलग हिजरी गणनाएँ (Umm al-Qura, tabular civil) एक ही दिन को अलग तारीख़ पर रख सकती हैं, इसलिए conversion टेस्ट में कैलेंडर का नाम होना चाहिए, सिर्फ़ "हिजरी" नहीं।

Time zone IANA tz डेटाबेस से आते हैं। Asia/Riyadh UTC+03:00 है और सऊदी अरब daylight saving time नहीं मानता; Asia/Kolkata UTC+05:30 है, वह भी बिना daylight saving के। इससे DST डिफ़ेक्ट लोकल टेस्टिंग में अदृश्य रहते हैं पर यूरोप या उत्तरी अमेरिका के यूज़र्स के लिए असली होते हैं। Instants को UTC में या स्पष्ट offset (ISO 8601) के साथ स्टोर करें, यूज़र के zone में सिर्फ़ डिस्प्ले के लिए बदलें, और आधे घंटे का offset, DST मानने वाला zone, और आधी रात के पास के समय टेस्ट करें, जहाँ कैलेंडर का दिन बदल जाता है।

• हर तारीख़ फ़ील्ड अपना कैलेंडर बताए; हिजरी date picker में तारीख़ चुनने पर वही वैल्यू स्टोर हो जो समकक्ष ग्रेगोरियन तारीख़ चुनने पर होती।
• महीने और साल का अंत: Umm al-Qura के महीने 29 या 30 दिन के होते हैं; दोनों कैलेंडर में महीने और साल का आख़िरी दिन टेस्ट करें।
• आधी रात का खिसकाव: रियाद समय 01:30 पर दिया गया ऑर्डर UTC में पिछले दिन पड़ता है; UTC दिन के हिसाब से समूह बनाने वाली रिपोर्ट उसे ग़लत तारीख़ पर दिखाती है।
• हफ़्ता और वीकेंड: हफ़्ते का पहला दिन locale के अनुसार बदलता है, और सऊदी अरब में वीकेंड शुक्रवार और शनिवार है; कैलेंडर, शेड्यूल और business-day गणना प्रोडक्ट के नियम पर चलें, hard-coded नियम पर नहीं।

One instant: 2026-09-28T09:05:00Z
(example output from Node.js 22 with ICU 78 / CLDR 48; other runtimes may differ)

ar-SA                          ٢٨ سبتمبر ٢٠٢٦
ar-SA-u-nu-latn                28 سبتمبر 2026
ar-SA-u-ca-islamic-umalqura    ١٧ ربيع الآخر ١٤٤٨ هـ
hi-IN                          28 सितंबर 2026
en-US                          September 28, 2026

Time in Asia/Riyadh  (UTC+03:00)   12:05
Time in Asia/Kolkata (UTC+05:30)   14:35

आज़माएँ: तारीख़ टेस्ट डेटा जनरेटर आज़माएँ: Timezone कन्वर्टर आज़माएँ: टाइमस्टैम्प कन्वर्टर आज़माएँ: ISO 8601 कन्वर्टर

संख्याएँ, अंक और मुद्रा

अरबी टेक्स्ट पश्चिमी अंक (0–9) या अरबी-इंडिक अंक (٠١٢٣٤٥٦٧٨٩) इस्तेमाल कर सकता है, और अरबी-इंडिक अंकों के साथ separator भी बदलते हैं: अरबी दशमलव separator ٫ (U+066B) और अरबी हज़ार separator ٬ (U+066C)। हिंदी टेक्स्ट आमतौर पर पश्चिमी अंक इस्तेमाल करता है, हालाँकि देवनागरी अंक (०–९) मौजूद हैं और माँगे जा सकते हैं। भारत बड़ी संख्याओं को अलग तरह समूहित करता है — 12,34,567, यानी लाख (1,00,000) और करोड़ (1,00,00,000) प्रणाली — en-IN और hi-IN दोनों में। हर locale के लिए तय करें कि प्रोडक्ट कौन-से अंक और कौन-सा grouping इस्तेमाल करेगा, फिर डिस्प्ले और इनपुट दोनों टेस्ट करें: यूज़र रकम या फ़ोन फ़ील्ड में अरबी-इंडिक अंक टाइप कर सकता है, और प्रोडक्ट को या तो उन्हें स्वीकार करके normalise करना चाहिए या साफ़ मैसेज के साथ अस्वीकार।

मुद्राएँ ISO 4217 कोड से पहचानी जाती हैं — सऊदी रियाल के लिए SAR और भारतीय रुपये के लिए INR, दोनों की दो minor units। रकम को locale से फ़ॉर्मेट करें, string टेम्पलेट से नहीं: चिह्न, उसकी जगह और spacing locale के अनुसार बदलते हैं। सऊदी सेंट्रल बैंक ने 2025 में रियाल का अलग चिह्न पेश किया, और Unicode 17.0 उसे U+20C1 SAUDI RIYAL SIGN के रूप में encode करता है; अगर आपका डिज़ाइन इसे इस्तेमाल करता है तो जाँचें कि आपके लक्षित डिवाइस के कौन-से फ़ॉन्ट इसे दिखा सकते हैं, क्योंकि जिस फ़ॉन्ट में glyph नहीं है वह ख़ाली बॉक्स दिखाता है।

Locale से फ़ॉर्मेट की गई strings में अदृश्य अक्षर होते हैं। ar-SA के लिए SAR रकम फ़ॉर्मेट करने पर दोनों सिरों पर right-to-left mark (U+200F) और मुद्रा से पहले no-break space आता है, इसलिए हाथ से टाइप की गई string से तुलना करने वाला टेस्ट फ़ेल होता है जबकि स्क्रीन सही दिखती है। उसी फ़ॉर्मेटिंग API के आउटपुट से तुलना करें, या assertion में अदृश्य अक्षरों को जान-बूझकर हटाएँ।

• Parsing: "1.234" कुछ locales में एक हज़ार दो सौ चौंतीस है और कुछ में एक दशमलव दो तीन चार; डिस्प्ले के लिए फ़ॉर्मेट की गई वैल्यू को उसी locale से parse करना चाहिए।
• फ़ोन नंबर, IBAN और ID नंबर पहचानकर्ता हैं, मात्राएँ नहीं: डिस्प्ले में उन्हें न group करें, न उनके अंक बदलें।

1234567.5 as currency, per locale
(example output from Node.js 22 with ICU 78 / CLDR 48)

ar-SA            SAR   ١٬٢٣٤٬٥٦٧٫٥٠ ر.س.
                       (U+200F at start and end, U+00A0 before ر.س.)
ar-SA-u-nu-latn  SAR   1,234,567.50 ر.س.
hi-IN            INR   ₹12,34,567.50
en-IN            INR   ₹12,34,567.50
en-US            SAR   SAR 1,234,567.50

1234567 with Devanagari digits (hi-IN-u-nu-deva):  १२,३४,५६७

आज़माएँ: अरबी टेस्ट डेटा जनरेटर आज़माएँ: हिंदी टेस्ट डेटा जनरेटर आज़माएँ: डेसिमल डेटासेट जनरेटर

टेक्स्ट, Unicode और लिपियाँ

हर लेयर को UTF-8 पर सहमत होना चाहिए: HTML meta charset और HTTP Content-Type, फ़ॉर्म सबमिशन, API, message queue, डेटाबेस कॉलम और कनेक्शन, लॉग, और CSV या PDF export। जब कोई लेयर UTF-8 bytes को किसी पुराने single-byte encoding में पढ़ती है तो नतीजा mojibake होता है — "مرحبا" कुछ ऐसा बन जाता है "مرحبا" — और एक round trip नुक़सान को स्थायी बना सकता है। अक्षरों की जगह प्रश्नचिह्न का मतलब आमतौर पर है कि किसी conversion में अक्षर खो गए; ख़ाली बॉक्स का मतलब आमतौर पर है कि फ़ॉन्ट में glyph नहीं है। MySQL में पुराना utf8 (utf8mb3) character set अरबी और देवनागरी तो स्टोर करता है पर supplementary (चार-byte) अक्षर नहीं, जिनमें ज़्यादातर emoji आते हैं; utf8mb4 पूरा Unicode स्टोर करता है।

एक ही दिखने वाला टेक्स्ट अलग-अलग code point क्रमों में स्टोर हो सकता है — "é" एक precomposed code point के रूप में या "e" और एक combining accent के रूप में। Unicode normalization (NFC, NFD, NFKC, NFKD) इन्हें तुलनीय बनाता है, इसलिए search, uniqueness जाँच और यूज़रनेम को एकरूप तरीके से normalise करना चाहिए। लंबाई भी अस्पष्ट है: हिंदी शब्द "नमस्ते" 6 code points, 6 UTF-16 units, 18 UTF-8 bytes और 3 यूज़र को दिखने वाले अक्षर (grapheme clusters: न, म, स्ते) है। Bytes में गिनी सीमा, अक्षरों में गिनी सीमा और code point से चलने वाला cursor — तीनों अलग नतीजे देंगे।

देवनागरी virama (हलंत) के ज़रिए व्यंजनों को संयुक्ताक्षर (क्ष, स्त) में जोड़ती है, और कुछ मात्राएँ उस व्यंजन से पहले बनाई जाती हैं जिसके बाद वे मेमोरी में आती हैं — "कि" में इ की मात्रा क के बाद स्टोर होती है पर उसके बाईं ओर दिखती है। Cluster के भीतर truncation, highlighting या cursor चलाने से बिना आधार की मात्रा बचती है, जिसे rendering engine आमतौर पर बिंदीदार वृत्त (◌ि) के साथ दिखाते हैं। पूरी देवनागरी shaping सपोर्ट न करने वाला फ़ॉन्ट संयुक्ताक्षरों को दिखते हलंत के साथ अलग-अलग अक्षरों में दिखाता है।

Sorting और search locale-specific हैं: प्लेटफ़ॉर्म का collation इस्तेमाल करें (JavaScript में Intl.Collator, डेटाबेस में collations) और ऐसे नामों से टेस्ट करें जो अलिफ़ के अलग-अलग रूपों (ا أ إ آ) से शुरू हों, मात्राओं/तश्कील के साथ और बिना, और मिश्रित लिपियों में। इनपुट की अपनी जाँचें हैं: अरबी कीबोर्ड, InScript लेआउट या phonetic transliteration कीबोर्ड से टाइप की गई हिंदी, और input method editors (IME) जो कई keystrokes में टेक्स्ट compose करते हैं — हर keystroke पर चलने वाला validation composition को बीच में तोड़ सकता है।

• टेक्स्ट का फैलना और सिकुड़ना: अनुवाद अंग्रेज़ी से काफ़ी लंबा या छोटा हो सकता है, ख़ासकर छोटे labels में; बटन, टैब, टेबल हेडर, toast और badge को हर locale की असली strings से टेस्ट करें।
• ऊर्ध्वाधर जगह: देवनागरी में शिरोरेखा के ऊपर और नीचे मात्राएँ हैं और अरबी में अक्षरों के ऊपर-नीचे तश्कील; hidden overflow के साथ fixed line height इन्हें काट देती है।
• SMS: अरबी या देवनागरी वाला मैसेज आमतौर पर UCS-2 में, 16 bit प्रति अक्षर, भेजा जाता है; एक SMS में 140 octets user data होता है (3GPP TS 23.040), इसलिए एक मैसेज में GSM 7-bit alphabet के 160 की जगह 70 अक्षर आते हैं, और OTP व notification टेम्पलेट कई मैसेज में बँट सकते हैं।

आज़माएँ: Unicode डेटासेट जनरेटर आज़माएँ: स्ट्रिंग लेंथ काउंटर आज़माएँ: कैरेक्टर काउंटर आज़माएँ: स्पेशल कैरेक्टर डेटासेट जनरेटर

लोकलाइज़ेशन टेस्टिंग कैसे चलाएँ

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

• Requirements और डिज़ाइन में locale फ़ैसले देखें: कौन-से locales, हर locale के लिए कौन-सा कैलेंडर और अंक, यूज़र कौन-से फ़ॉर्मेट बदल सकता है, fallback भाषा, और क्या जान-बूझकर अनुवादित नहीं होगा (ब्रांड नाम, क़ानूनी टेक्स्ट)।
• Internationalization के लिए कोड की समीक्षा करें: externalised strings, locale-aware फ़ॉर्मेटिंग API, लेआउट कोड में कोई भौतिक left/right नहीं, शुरू से अंत तक Unicode स्टोरेज।
• CI में pseudo-localization चलाएँ: हर बिल्ड pseudo-locale में चलता है, और कोई भी सादी अंग्रेज़ी string डिफ़ेक्ट है।
• हर locale में localized टेस्ट डेटा से फ़ंक्शनल टेस्टिंग करें — लक्षित लिपियों और फ़ॉर्मेट में नाम, पते, फ़ोन नंबर, रकम और तारीख़ें — हर लेयर से डेटाबेस तक और वापस export, ईमेल और SMS तक।
• मातृभाषियों के साथ संदर्भ में linguistic review करें, स्क्रीनशॉट और string keys के साथ, glossary और style guide के विरुद्ध।
• हर रिलीज़ पर रिग्रेशन: localized smoke टेस्ट, missing-key जाँच और हर बिल्ड पर हर locale की screenshot तुलना, और जब कोई फ़ीचर टेक्स्ट-भारी स्क्रीन बदले तो पूरा localization दौर।

Localization test checklist, per locale (ar-SA, hi-IN, en-US ...)

[ ] Locale is picked correctly (setting, Accept-Language, URL) and persists
[ ] Unsupported locale falls back to the agreed default, never to raw keys
[ ] No untranslated or hard-coded strings (pseudo-locale run is clean)
[ ] Plurals: counts 0, 1, 2, 3, 11, 100 give the correct Arabic forms
[ ] Dates: calendar, digits, month names, time zone, midnight shift
[ ] Numbers: digits, decimal and grouping separators, lakh/crore in hi-IN
[ ] Currency: ISO 4217 code, symbol, position, minor units, input parsing
[ ] Text: Arabic and Devanagari intact through DB, API, CSV, PDF, email, SMS
[ ] Length limits enforced in the unit the backend uses (chars vs bytes)
[ ] Sorting and search work for the locale (alif forms, diacritics)
[ ] Layout: no truncation, clipping or overlap with real strings
[ ] RTL: direction, mirroring, bidirectional text (see the RTL guide)
[ ] lang attribute on the page and on inline foreign-language text

आज़माएँ: बहुभाषी टेस्ट डेटा जनरेटर आज़माएँ: अरबी टेस्ट डेटा जनरेटर आज़माएँ: हिंदी टेस्ट डेटा जनरेटर आज़माएँ: सऊदी एड्रेस टेस्ट डेटा

लोकलाइज़ेशन जाँचों का ऑटोमेशन

ऑटोमेटेड टेस्ट एक से ज़्यादा locale में चलने चाहिए। Suite को locale और time zone से parameterise करें, और assertions में फ़ॉर्मेट की गई strings टाइप करने की बजाय अपेक्षित वैल्यू प्लेटफ़ॉर्म के Intl API से निकालें — टाइप की गई strings अदृश्य marks चूक जाती हैं और CLDR डेटा अपडेट होते ही टूटती हैं। अपेक्षित वैल्यू उसी runtime में निकालें जिसने असली वैल्यू बनाई: Node.js test runner और ब्राउज़र के ICU वर्ज़न अलग हो सकते हैं और नतीजे भी।

तीन सस्ती जाँचें ज़्यादातर रिग्रेशन पकड़ लेती हैं: missing-key जाँच जो CI में हर locale फ़ाइल की source locale से तुलना करे, untranslated जाँच जो source जैसी ही वैल्यू पकड़े (ब्रांड नाम और कोड के लिए allow-list के साथ), और मुख्य स्क्रीन की हर locale में screenshot तुलना।

// Locale-parameterised UI check (Playwright Test)
for (const locale of ["en-US", "ar-SA", "hi-IN"]) {
  test(`order total is formatted for ${locale}`, async ({ browser }) => {
    const context = await browser.newContext({
      locale,
      timezoneId: locale === "hi-IN" ? "Asia/Kolkata" : "Asia/Riyadh",
    });
    const page = await context.newPage();
    await page.goto("/orders/ORD-2026-0042");
    // expected value computed with Intl in the same browser, not typed by hand
    const expected = await page.evaluate(
      (l) => new Intl.NumberFormat(l, { style: "currency", currency: "SAR" }).format(1500),
      locale,
    );
    await expect(page.getByTestId("order-total")).toHaveText(expected);
    await expect(page).toHaveScreenshot(`order-${locale}.png`);
  });
}

// Missing and untranslated keys (Node.js, runs in CI)
const flat = (o, p = "") => Object.entries(o).flatMap(([k, v]) =>
  v && typeof v === "object" ? flat(v, p + k + ".") : [[p + k, v]]);
const en = new Map(flat(require("./locales/en.json")));
const ar = new Map(flat(require("./locales/ar.json")));
const missing = [...en.keys()].filter((k) => !ar.has(k));
const same = [...en].filter(([k, v]) => ar.get(k) === v);
if (missing.length) { console.error("Missing in ar:", missing); process.exit(1); }
if (same.length) console.warn("Identical to en, check:", same.map(([k]) => k));

आज़माएँ: JSON डिफ़ आज़माएँ: बहुभाषी टेस्ट डेटा जनरेटर

आम लोकलाइज़ेशन डिफ़ेक्ट, बग टाइटल के रूप में

नीचे के उदाहरण समझाने के लिए हैं, असली घटनाएँ नहीं। हर एक बग रिपोर्ट के pattern — लक्षण, जगह और शर्त — पर चलता है; बाक़ी रिपोर्ट बग रिपोर्ट कैसे लिखें गाइड में है।

• Cart badge "منتجان" की जगह "2 منتج" दिखाता है — plural रूप count === 1 जाँच से चुना गया
• ऐप में अरबी चुनने वाले यूज़र्स को ऑर्डर कन्फ़र्मेशन ईमेल अंग्रेज़ी में मिलता है
• रियाद समय 00:00 से 03:00 के बीच तारीख़ चुनने पर हिजरी date picker पिछला दिन स्टोर करता है
• अरबी कीबोर्ड से टाइप किए "١٥٠٠" को रकम फ़ील्ड "Invalid number" कहकर अस्वीकार करता है
• hi-IN सेल्स रिपोर्ट 12,34,567 की जगह 1,234,567 दिखाती है
• हिंदी प्रोडक्ट नाम संयुक्ताक्षर के भीतर कटा, search नतीजों में बिंदीदार वृत्त वाली मात्रा बची
• अरबी रजिस्ट्रेशन फ़ॉर्म पर validation मैसेज "Field is required" अनुवादित नहीं

अक्सर पूछे जाने वाले सवाल

संदर्भ

• Internationalization (i18n) ActivityW3Cबहुभाषी वेब कंटेंट बनाने और टेस्ट करने के लिए W3C के internationalization लेख, ट्यूटोरियल और जाँचें।
• Unicode CLDR ProjectUnicode ConsortiumCommon Locale Data Repository: तारीख़, समय, संख्या व मुद्रा फ़ॉर्मेट और plural नियमों का locale डेटा जिसे ज़्यादातर प्लेटफ़ॉर्म इस्तेमाल करते हैं।
• The Unicode StandardUnicode Consortiumसार्वभौमिक कैरेक्टर सेट और उसके एन्कोडिंग रूप (UTF-8, UTF-16, UTF-32), नॉर्मलाइज़ेशन और हर कोड पॉइंट के गुण।
• ECMAScript Internationalization API Specification (ECMA-402)Ecma International (TC39)JavaScript Intl API का स्पेसिफ़िकेशन — ब्राउज़र में तारीख़, संख्या, मुद्रा, सूची और plural नियमों की locale-aware फ़ॉर्मेटिंग।
• Intl — MDNMDN Web Docs (Mozilla)व्यवहार में Intl namespace: DateTimeFormat, NumberFormat, Collator, PluralRules और locale negotiation कैसे काम करता है।
• Time Zone DatabaseIANAदुनिया के time zone और उनके ऐतिहासिक offset व daylight-saving नियमों का tz डेटाबेस, जो साल में कई बार अपडेट होता है।
• ISO 4217 — Currency codesISOतीन-अक्षरी मुद्रा कोड (SAR, INR, USD…) और उनकी minor units — मुद्रा फ़ील्ड और फ़ॉर्मेटिंग टेस्ट का संदर्भ।
• RFC 5646: Tags for Identifying LanguagesIETF · 2009BCP 47 भाषा टैग (ar, ar-SA, hi-IN, en-GB) — lang एट्रिब्यूट, Accept-Language और locale सेटिंग में इस्तेमाल होने वाले पहचानकर्ता।
• Indic Layout RequirementsW3C · 2020देवनागरी जैसी भारतीय लिपियों की लेआउट आवश्यकताएँ — संयुक्ताक्षर, मात्राएँ, लाइन ब्रेकिंग — हिंदी इंटरफ़ेस के लिए प्रासंगिक (W3C Working Draft)।