ट्रांसलेशन और लिंग्विस्टिक टेस्टिंग

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

Translators आम तौर पर spreadsheet या translation-management system से काम करते हैं, screen देखे बिना, इसलिए गलत अर्थ का सही अनुवाद आम है: English "Open" status भी है और command भी, और "Save" का मतलब एक screen पर data सहेजना और दूसरी पर कम पैसे देना होता है। Developers target language कम ही पढ़ते हैं, इसलिए translated placeholder, छूटी plural category या उलटे order number वाला Arabic वाक्य code review से निकल जाता है। Defect सबसे पहले अक्सर user ही देखता है।

Product के लिए ये defects crash नहीं, भरोसा खर्च करते हैं: जो shop Arabic में अपने products गिन नहीं सकती, या जिस bank का Hindi confirmation शब्द के बीच में कट जाता है, वह उसी market में लापरवाह दिखता है जिसे जीतना चाहता है। Tester के लिए translation testing structure से value जोड़ने का मौका है: locales की list, counts की table, mixed-direction strings का set और हर string key का screenshot, भाषा बोले बिना इनमें से ज़्यादातर defects पकड़ लेते हैं।

Linguistic review और functional localization testing अलग काम हैं

Linguistic review (कुछ teams इसे linguistic QA या in-context review कहती हैं) एक qualified native speaker करता है, बेहतर हो कि वह नहीं जिसने text translate किया, glossary और style guide के सामने रखकर। यह accuracy (क्या Arabic वही कहती है जो English कहती थी?), fluency, terminology, grammar और spelling, register (product user को कैसे संबोधित करता है) और cultural fit पर राय देता है। इसका output हर string key के लिए corrections की list है, bug report नहीं।

Functional localization testing tester translated build, test data और checklist के साथ करता है, और इसके लिए fluency ज़रूरी नहीं। यह verify करती है कि translation load हुई और पूरी है, कि layout, placeholders, plurals, sorting, search और input उस locale में काम करते हैं, और features source language जैसा ही व्यवहार करते हैं। इसका output defects हैं। दोनों activities एक artefact पर मिलती हैं: हर string का context में screenshot, जो reviewer को वह context देता है जो translator के पास कभी नहीं था और developer को वह key जिसे fix करना है।

• Linguistic review को चाहिए: glossary, style guide, source text और screenshots; यह string key, current text, proposed text और reason दर्ज करती है।
• Functional testing को चाहिए: हर locale में build, realistic localized test data, plural count table और mixed-direction string set; यह string key, locale, screen, expected और actual दर्ज करती है।
• क्रम: pseudo-localization और functional testing पहले चलाएँ ताकि missing strings reviewer को न रोकें; strings stable होने पर linguistic review कराएँ; corrections आने के बाद retest (confirmation testing) करें।

Translated strings में क्या टूटता है: अर्थ, placeholders, plurals, length

Context defects उन strings से आते हैं जो यह देखे बिना translate हुईं कि वे कहाँ दिखेंगी। छोटी strings सबसे risky हैं: "Open", "Close", "Post", "Clear", "None" और "Home" में हर एक के कई अर्थ हैं, और दो अलग अर्थों के साथ दो screens पर reuse हुई एक key दोनों में सही नहीं हो सकती। हर context के लिए एक key माँगें और हर छोटी string उसकी screen पर जाँचें।

Placeholders message के वे हिस्से हैं जिन्हें code भरता है: {name}, {{count}}, %s, %1$s, {0}। Translator किसी एक को translate या delete कर सकता है। साधारण %s placeholders हमेशा क्रम से भरे जाते हैं, इसलिए अगर target वाक्य city को date से पहले रखता है तो date वहाँ पहुँच जाती है जहाँ city होनी चाहिए; %1$s और %2$s जैसे numbered placeholders इसीलिए हैं कि translation उनका क्रम बदल सके। हर placeholder वाले message को हर locale में असली value के साथ टेस्ट करें, और resource files को आमने-सामने पढ़ें: translation में placeholders का set source के set के बराबर होना चाहिए।

Plural forms locale के हिसाब से चलती हैं, English के नहीं। CLDR plural categories (English और Hindi की दो, Arabic की छह) और यह कि count === 1 से form चुनने वाला code Arabic में क्यों गलत है, localization testing guide और internationalization वाले lesson में समझाया जा चुका है। Translation testing का हिस्सा count table है: locale की हर category की एक value, Arabic के लिए 0, 1, 2, 3, 11 और 100, जिसे screen पर हर counted message पर चलाया जाता है ताकि पक्का हो कि हर delivered translation में उसकी locale की सारी ज़रूरी categories हैं।

Length और truncation: translated text अक्सर English source से लंबा होता है, और Devanagari को line के ऊपर-नीचे की मात्राओं के लिए ज़्यादा height चाहिए। Fixed-width buttons, tabs, table headers, badges, push notification titles और SMS में यह दिखता है। Arabic शब्द के बीच का cut आख़िरी बचे letter को उसका final form दे देता है, जिससे टुकड़ा किसी दूसरे शब्द जैसा पढ़ा जा सकता है; Hindi अक्षर के बीच का cut दिखते हलंत (virama) वाला आधा व्यंजन छोड़ सकता है, और बँटे हुए message का अगला हिस्सा किसी मात्रा से शुरू हो सकता है जिसे कई fonts dotted circle पर बनाते हैं। जहाँ hard limit है, जैसे notification title या SMS segment, translated string को उसी unit में limit के सामने मापें जिसमें system गिनता है।

• Untranslated strings (Arabic या Hindi interface में छूटी English, localization testing guide देखें): app खोलने से पहले source और target resource files के key sets की तुलना करके इन्हें खोजें।
• Concatenation (internationalization वाला lesson देखें): code में टुकड़ों से जोड़ा वाक्य सही word order के साथ translate नहीं हो सकता; fix parameters वाला एक message है, जो developer बनाता है।
• Gender और register (localization testing guide देखें): linguistic review जाँचती है कि product user को संबोधित करने का अपना फ़ैसला, masculine, neutral या profile के हिसाब से, हर string में लागू करता है।

आज़माएँ: JSON डिफ़ आज़माएँ: स्ट्रिंग लेंथ काउंटर

Translated string के अंदर mixed LTR और RTL text

RTL testing guide Unicode Bidirectional Algorithm (UAX #9) और bidi test set समझाती है; translation testing उनमें एक सवाल जोड़ती है। हर placeholder target वाक्य में कहाँ बैठेगा, यह translator तय करता है, और placeholders भरने वाली values अक्सर left-to-right होती हैं: brand names, order ids, emails, URLs, file names और user का English में टाइप किया कुछ भी। जो translated string Arabic value के साथ सही पढ़ी जाती है, वह Latin value के साथ टूट सकती है, इसलिए हर placeholder को दोनों तरह की values चाहिए।

तीन cases बार-बार आते हैं। पहला: जिस value में digits के बाद hyphen और Latin letters आते हैं, उसका क्रम Arabic वाक्य के अंदर बदल जाता है: order id 1042-A A-1042 के रूप में दिखता है, जबकि letter से शुरू होने वाला A-1042 अपना क्रम रखता है क्योंकि उसके digits अपने से पहले वाले letter की direction लेते हैं। दूसरा: Latin value के बाद आने वाले Western digits, जिनके बीच सिर्फ़ spaces या punctuation हों, उसके left-to-right run में जुड़ जाते हैं: تقييم {user}: {score} में user "Sara" होने पर score "تقييم" के बगल में, नाम से पहले दिखता है। तीसरा: placeholder से शुरू होने वाला translation: बिना तय direction के दिखाया गया plain text अपनी paragraph direction पहले strong letter से लेता है (UAX #9 के rules P2 और P3), और dir="auto" भी यही करता है, इसलिए {app} يذكّرك بموعدك غداً. Latin app name से भरने पर left-to-right paragraph बन जाता है: left-aligned, और full stop गलत तरफ़।

• Placeholder वाले हर message के लिए लिखें कि हर translation में placeholder कहाँ है (शुरुआत, बीच या अंत), और उसे दो बार टेस्ट करें: एक Arabic value से और एक Latin value से, जैसे brand, email या hyphen वाला id।
• पूछें कि value isolate कैसे होती है: HTML में उसे रखने वाले element पर <bdi> या dir="auto", या plain text में उसके चारों ओर FSI (U+2068) और PDI (U+2069)। Isolation तीनों cases ठीक करता है: value अपने आप में layout होती है, और UAX #9 पहला strong letter खोजते समय isolated text को छोड़ देता है। Translation file में टाइप या paste किए गए direction marks (U+200E, U+200F) review में दिखते नहीं और सिर्फ़ उसी value को ठीक करते हैं जिससे उन्हें टेस्ट किया गया; संदिग्ध string को code points में बदलकर उन्हें देखें।
• वही string Hindi locale में भी जाँचें: Hindi left-to-right है, इसलिए सिर्फ़ Arabic में दिखने वाला defect direction handling की ओर इशारा करता है, और दोनों में दिखने वाला placeholder की ओर।

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

Worked example: Arabic और Hindi में checkout strings

एक shop अपनी checkout strings हर locale की एक JSON file में externalise करती है। Arabic और Hindi files translation vendor से आती हैं; tester app खोलने से पहले उन्हें English source के साथ आमने-सामने पढ़ता है, फिर screen पर counts 0, 1, 2, 3, 11 और 100 और order id 1042-A के साथ verify करता है।

• cart.items: Arabic ने plural structure गिरा दी; 2 पर "منتجان" की जगह "2 منتج" दिखता है, 3 पर "3 منتجات" और 11 पर "11 منتجاً" पढ़ा जाना चाहिए। Functional defect, count table से मिला; fix छह CLDR categories वाला message है।
• order.shipped: placeholder {orderId} को {رقم الطلب} में translate कर दिया गया, इसलिए formatter raw braces print करता है। Functional defect, दोनों files के placeholder sets की तुलना से मिला।
• order.shipped screen पर 1042-A के साथ, placeholder fix होने के बाद: Arabic वाक्य के अंदर id A-1042 दिखता है जब तक value को <bdi> से isolate न किया जाए। Functional defect, placeholder को Latin value से भरने पर मिला।
• status.open: "افتح" command है, "इसे खोलो"; key एक order status है और "مفتوح" पढ़ी जानी चाहिए। Linguistic defect, सिर्फ़ context में दिखता है, orders table के screenshot के साथ report हुआ।
• Hindi file: cart.items का "{count} आइटम" स्वीकार्य है क्योंकि Hindi में दो categories हैं और loanword बदलता नहीं, लेकिन reviewer इस screen पर "सेव करें" और settings screen पर "सहेजें" को glossary के विरुद्ध terminology inconsistency के रूप में flag करता है।

en.json
  "cart.items":    "{count, plural, one {# item} other {# items}}"
  "order.shipped": "Order {orderId} shipped to {city}"
  "status.open":   "Open"
  "button.save":   "Save"

ar.json (as delivered)
  "cart.items":    "{count} منتج"
  "order.shipped": "تم شحن الطلب {رقم الطلب} إلى {city}"
  "status.open":   "افتح"
  "button.save":   "حفظ"

hi.json (as delivered)
  "cart.items":    "{count} आइटम"
  "order.shipped": "ऑर्डर {orderId} {city} को भेज दिया गया"
  "status.open":   "खुला"
  "button.save":   "सेव करें"

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

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

संदर्भ

• Unicode CLDR ProjectUnicode ConsortiumCommon Locale Data Repository: तारीख़, समय, संख्या व मुद्रा फ़ॉर्मेट और plural नियमों का locale डेटा जिसे ज़्यादातर प्लेटफ़ॉर्म इस्तेमाल करते हैं।
• Unicode Standard Annex #9: Unicode Bidirectional AlgorithmUnicode Consortiumवह एल्गोरिदम जो मिश्रित right-to-left और left-to-right टेक्स्ट का डिस्प्ले क्रम तय करता है — ज़्यादातर bidirectional-text बग का स्रोत।
• Inline markup and bidirectional text in HTMLW3Cbidirectional एल्गोरिदम inline हिस्सों — अरबी टेक्स्ट के भीतर संख्याएँ, नाम, URL — को कैसे संभालता है, और उन्हें अलग करने वाला markup (bdi, dir)।
• The Unicode StandardUnicode Consortiumसार्वभौमिक कैरेक्टर सेट और उसके एन्कोडिंग रूप (UTF-8, UTF-16, UTF-32), नॉर्मलाइज़ेशन और हर कोड पॉइंट के गुण।