इंटरनेशनलाइज़ेशन (i18n)

यह क्यों ज़रूरी है

ज़्यादातर i18n defects source भाषा में दिखते ही नहीं, इसलिए सिर्फ़ English में test करने वाली टीम उन्हें एक साथ हर दूसरे market में ship कर देती है। देर से मिलने पर इन्हें ठीक करना translation defects से महँगा भी पड़ता है: hard-coded string या fixed date pattern का मतलब है कोड बदलना, नया build और हर locale में retest, जबकि ग़लत translation resource फ़ाइल की एक line है।

Tester के लिए i18n की समझ तय करती है कि report कहाँ जाएगी। Arabic interface में सादा English label translator के लिए translation bug नहीं है; यह code defect है, और उसकी कोई string key है ही नहीं।

दो अलग काम: एक बार कोड में, फिर हर locale के लिए

Localization testing गाइड ने ये terms introduce किए; test design के लिए जो मायने रखता है वह है काम कहाँ होता है। Internationalization एक बार, कोड में, developers करते हैं: यह product का गुण है। Localization हर locale के लिए अलग से, content में, translators और local experts करते हैं: translated strings, local formats, क़ानूनी text, payment तरीक़े। कुछ टीमें दोनों को मिलाकर globalization (g11n) कहती हैं।

क्योंकि काम अलग जगहों पर होता है, defects भी अलग जगहों पर रहते हैं। i18n defect आम तौर पर source भाषा के अलावा हर locale में दिखता है, और सही data वाला कोई भी tester उसे reproduce कर सकता है। l10n defect एक locale में दिखता है और उसे परखने के लिए अक्सर native speaker चाहिए। एक ही screen पर दोनों हो सकते हैं: string template से बना price (i18n) और "cart" के लिए ग़लत Arabic शब्द (l10n)।

• i18n सवाल: क्या product कोई भी locale ले सकता है? Translation आने से पहले test करें, pseudo-locale, Unicode data, right-to-left दिशा और non-default formats के साथ।
• l10n सवाल: क्या यह locale सही है? Translation आने के बाद test करें, असली strings, असली formats और native speaker के साथ।
• Locale, सिर्फ़ language नहीं: ar Arabic text चुनता है; ar-SA वह region जोड़ता है जो formats, currency और calendar defaults तय करता है। Language tags RFC 5646 के अनुसार होते हैं।

Externalised strings और locale data

String को externalise करने का मतलब है उसे कोड से निकालकर resource फ़ाइल में एक key के नीचे रखना: कोड checkout.total माँगता है और runtime मौजूदा locale का text लौटाता है। हर वाक्य named parameters वाला एक message होता है, जोड़े गए टुकड़े कभी नहीं, क्योंकि शब्दों का क्रम और agreement भाषाओं में अलग होते हैं। Counts plural categories इस्तेमाल करते हैं: Unicode CLDR के नियम English को दो, Hindi को दो और Arabic को छह देते हैं, इसलिए message में हर category का एक रूप होता है और formatter उसे चुनता है; नीचे की ICU MessageFormat syntax में # की जगह number आता है।

Locale data वह सब है जो runtime किसी locale के बारे में जानता है और जो translation नहीं है: date और number patterns, digits, currency symbols और उनकी जगह, calendar, हफ़्ते का पहला दिन, plural नियम और sort order। ज़्यादातर platforms पर यह CLDR से आता है और ECMAScript के Intl objects (ECMA-402) जैसे locale-aware APIs से कोड तक पहुँचता है। Internationalized कोड कभी DD/MM/YYYY जैसा pattern hard-code नहीं करता; वह user का locale tag API को देता है और जो लौटे उसे दिखाता है। CLDR data नए releases के साथ बदलता है, इसलिए test को expected format platform के अपने formatter से लेना चाहिए, किसी website से एक बार copy की गई value से नहीं।

• Missing keys: हर locale फ़ाइल की source फ़ाइल से तुलना करें; जो key en.json में है और ar.json में नहीं, वह English पर fall back करती है या raw key दिखाती है।
• Parameters: {name} और {amount} translation के बाद जस के तस रहने चाहिए; translated placeholder raw braces दिखाता है या formatter तोड़ देता है, और हटाया गया placeholder value को चुपचाप गायब कर देता है।

en.json
  "checkout.total":    "Total: {amount}"
  "checkout.nights":   "{count, plural, one {# night} other {# nights}}"
  "checkout.greeting": "Welcome back, {name}"

ar.json  (वही keys; Arabic में सभी छह plural categories)
  "checkout.total":    "الإجمالي: {amount}"
  "checkout.nights":   "{count, plural, zero {لا ليالي} one {ليلة واحدة} two {ليلتان}
                         few {# ليالٍ} many {# ليلة} other {# ليلة}}"
  "checkout.greeting": "أهلاً بعودتك يا {name}"

Tester क्या जाँचता है
  हर दिखने वाली string की key है       -> template में कुछ भी typed नहीं
  {amount} पहले से formatted आता है    -> locale API से, message से नहीं
  {count} हर plural category छूता है   -> Arabic के लिए 0, 1, 2, 3, 11 और 100

आज़माएँ: JSON डिफ़

Worked example: pseudo-locale में checkout screen

Pseudo-localization source strings से एक नक़ली locale बनाती है: अक्षरों पर accents लगते हैं, हर message लंबा होकर brackets में लिपट जाता है, और चाहें तो base direction right-to-left पलट जाती है। टीम screen अब भी पढ़ सकती है, और interface का जो text बदला हुआ नहीं दिखता वह कभी externalise हुआ ही नहीं। Translator की ज़रूरत नहीं, इसलिए यह CI में हर build पर चल सकती है। उदाहरण के लिए Android en-XA (accents वाला, लंबा text) और ar-XB (right-to-left) pseudo-locales देता है।

नीचे एक hotel checkout screen English और pseudo-locale में है, साथ में हर line tester को क्या बताती है। सादी English खोजें, एक वाक्य की जगह कई bracket जोड़े खोजें, गायब closing bracket खोजें, और accented अक्षरों की जगह question marks खोजें।

• Expansion: हर string टीम के चुने factor से लंबी होती है, क्योंकि कई translations English से लंबी होती हैं और छोटे labels सबसे ज़्यादा बढ़ते हैं। जो layout इसे झेल ले वह आम तौर पर असली Arabic और Hindi strings भी झेल लेता है।
• Right-to-left pseudo-locale: यह Arabic translation के बिना base direction पलटती है, इसलिए बिना-mirror icons, ग़लत जगह के back arrows और ग़लत तरफ़ aligned text Arabic फ़ाइल बनने से हफ़्तों पहले दिख जाते हैं।

English                   Pseudo-locale                  Tester क्या देखता है
------------------------  -----------------------------  --------------------------------
Checkout                  [Çĥéçķöüţ ····]                ठीक: externalised
Book now                  Book now                       template में hard-coded
You have 2 guests         [Ýöü ĥàṽé] 2 [ĝüéšţš]          तीन टुकड़े: concatenated
Total: SAR 1,250.00       Total: SAR 1,250.00            hard-coded: कभी key थी ही नहीं
Room type                 [?ööm ?ý?é ····]               question marks: non-UTF-8 रास्ता
Cancel booking            [Çàñçéļ ḃööķí                  truncated: fixed-width button
Welcome back, Ahmed       [Ŵéļçömé ḃàçķ, Ahmed ····]     ठीक: {name} बचा रहा

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

आम i18n defects और वे कहाँ रहते हैं

ज़्यादातर i18n defects कुछ ही classes में आते हैं। हर class का एक symptom है, कोड में एक जगह और उसे पकड़ने का एक सस्ता तरीक़ा; class पहचान लें तो आप सिर्फ़ symptom नहीं, कारण report कर पाते हैं।

• Validation messages, API errors, emails, labels और image text में hard-coded strings। पकड़ने का तरीक़ा: pseudo-locale, फिर Arabic, हर message पढ़ते हुए, उन्हें भी जो error होने पर ही दिखते हैं।
• Concatenation और if वाले plurals: "You have " + n + " items", count === 1 ? "night" : "nights"। Symptom: bracket वाले टुकड़े, "ليلتان" की जगह "2 ليلة"। पकड़ने का तरीक़ा: counts 0, 1, 2, 3, 11 और 100।
• Fixed formats: DD/MM/YYYY templates, हाथ से रखे currency codes, कोड में लिखा decimal point। Symptom: हर locale में एक ही format। पकड़ने का तरीक़ा: ar-SA और hi-IN, platform के अपने formatter से तुलना करके।
• Layout में physical direction: text की दिशा के साथ चलने वाली logical properties (margin-inline-start, text-align: start) और dir attribute की जगह margin-left और text-align: left। Symptom: Arabic page जिसका layout English ही रहता है। पकड़ने का तरीक़ा: right-to-left pseudo-locale।
• Non-Unicode रास्ते: कोई column, API या export जो Unicode की जगह कोई पुराना (legacy) encoding इस्तेमाल करे, या bytes में गिनी गई length limit। Symptom: question marks, mojibake, 100-character field जो 60 Arabic अक्षर (UTF-8 में 120 bytes) reject कर दे। पकड़ने का तरीक़ा: हर field में Unicode datasets, फिर stored value जाँचें।
• रास्ते में खोया locale: interface Arabic है पर email, PDF receipt या SMS English। पकड़ने का तरीक़ा: Arabic में एक flow पूरा करें और हर वह output खोलें जो screen नहीं है।

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

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

संदर्भ

• Internationalization (i18n) ActivityW3Cबहुभाषी वेब कंटेंट बनाने और टेस्ट करने के लिए W3C के internationalization लेख, ट्यूटोरियल और जाँचें।
• RFC 5646: Tags for Identifying LanguagesIETF · 2009BCP 47 भाषा टैग (ar, ar-SA, hi-IN, en-GB) — lang एट्रिब्यूट, Accept-Language और locale सेटिंग में इस्तेमाल होने वाले पहचानकर्ता।
• Unicode CLDR ProjectUnicode ConsortiumCommon Locale Data Repository: तारीख़, समय, संख्या व मुद्रा फ़ॉर्मेट और plural नियमों का locale डेटा जिसे ज़्यादातर प्लेटफ़ॉर्म इस्तेमाल करते हैं।
• ECMAScript Internationalization API Specification (ECMA-402)Ecma International (TC39)JavaScript Intl API का स्पेसिफ़िकेशन — ब्राउज़र में तारीख़, संख्या, मुद्रा, सूची और plural नियमों की locale-aware फ़ॉर्मेटिंग।