Ecommerce localization plan करें

Translation से आगे market readiness देखें

Translation किसी fact को दूसरी भाषा में व्यक्त करने का काम है। Localization यह भी पूछती है कि reader product को समझ सकता है या नहीं, उसके measurements का अर्थ निकाल सकता है या नहीं और relevant service information ढूँढ सकता है या नहीं। Market readiness इससे आगे जाती है: किसी व्यक्ति को वास्तविक delivery, payment, return और product rules की पुष्टि करनी होगी। Fluent page इन operational facts को सिद्ध नहीं करती।

हर locale के लिए scope sheet बनाएँ। Language reviewer, category reviewer और store owner पहचानें। कौन-सी policies unresolved हैं, उन्हें record करें और next action assign करें। ऐसी buyer journey से शुरू करें जिसे team end to end support कर सके; review capacity बढ़ने पर language inventory का विस्तार करें।

Buyer journey की पूरी content inventory बनाएँ

Buyer जिस path का पालन करता है उससे शुरुआत करें: product discovery, variant selection, specification reading, cart review और service information। जब वे उस path को प्रभावित करते हों तो navigation labels, size guidance, image text और error messages भी शामिल करें। केवल descriptions का translation करने से critical decisions दूसरी भाषा में छूट सकते हैं।

हर content surface को उसके वास्तविक owner और storage location से जोड़ें। Theme label, product field और policy document को अलग tools की आवश्यकता हो सकती है। Inventory को source revisions से connected रखें, ताकि product update पर team को हर dependent sentence फिर से खोजनी न पड़े और केवल affected translations review के लिए सामने आएँ।

BCP 47 और market को अलग समझें

W3C guidance समझाती है कि BCP 47 tags language और जहाँ उपयोगी हो वहाँ script या region अलग कर सकते हैं। Intended content और destination platform के supported values से मेल खाने वाला language tag चुनें। केवल country abbreviation जैसा दिखने के कारण locale code invent न करें।

अपने records में content locale को target market और currency से अलग रखें। एक ही language कई markets में उपयोग हो सकती है, जिनकी commercial settings अलग हों। Fallback behavior स्पष्ट करें: missing translation review के दौरान दिखाई देनी चाहिए; source language silently दिखाकर locale को completed न गिनें।

Context वाला versioned glossary बनाएँ

हर important term की छोटी definition और वह product context लिखें जिसमें लागू होती है। Approved target forms, unchanged brand names और misleading alternatives जोड़ें। Reviewer के लिए exception माँगने का रास्ता रखें, ताकि technically wrong glossary term हर sentence में force न हो।

Glossary का version बनाकर उसे हर candidate से attach करें। Term बदलने पर affected content review trigger होना चाहिए। Terminology और translation-related metadata को mark करने के लिए W3C ITS reference दे सकता है; नीचे का lightweight record illustrative editorial format है, ITS implementation या store import schema नहीं।

{
  "conceptId": "material-linen",
  "definition": "Fiber described as linen in the approved specification",
  "sourceTerm": "linen",
  "targetLocale": "de",
  "approvedTerm": "Leinen",
  "rule": "Do not infer a material blend or certification",
  "reviewStatus": "pending"
}

Amounts, claims और uncertainty को सुरक्षित रखें

Localized decimal separator केवल display choice है; इससे stored amount बदलने की अनुमति नहीं मिलती। Source price, currency और unit values protected record में रखें। Conversion की जरूरत हो तो उसे recorded conversion rule के साथ separately approved deterministic operation बनाएँ।

Claims पर भी यही discipline लागू करें। suitable for travel जैसी phrase को unsupported durability guarantee न बनने दें। Materials, compatibility, certifications और health-related assertions के लिए evidence माँगें। Source की uncertainty बचाएँ और missing specifications को model को attractive story बनाने देने के बजाय product owner को flag करें।

Fact pass और language pass अलग रखें

पहले pass में quantities, units, product relationships और claims को source के विरुद्ध compare करें। दूसरे pass में terminology, natural expression, audience और brand tone जाँचें। दोनों results independently record करें, ताकि readable copy unresolved factual defect छिपा न सके।

Warnings और variant labels सहित पूरा product context review करें, केवल isolated strings नहीं। Unfamiliar या regulated categories में appropriate specialist शामिल करें। Model-generated back-translation differences खोजने में मदद कर सकती है, लेकिन generated texts का आपस में agree करना independent proof नहीं है कि किसी एक का product से सही मिलान है।

Destination import और storefront दोनों verify करें

Shopify की merchant documentation translation management को localized store content प्रस्तुत करने के बड़े काम से अलग दिखाती है। Platform का language workflow और supported resources जाँचें। दूसरे store stack में कोई locale column map करने से पहले multilingual layer और import contract confirm करें।

Delivery package में product identifiers, locale, source revision, approved text और reviewer identity रखें। इस review package को minimal import payload से अलग रखें। Staging store में language selection, fallback, text wrapping, links और product selection check करें। Export में content होना intended page पर उसका visible होना सिद्ध नहीं करता।

Coverage को current approved revisions से मापें

Source changes को field level पर track करें। Corrected material statement affected translations को invalidate करे, भले title वही रहे। Updated glossary targeted terminology review माँग सकती है; price change commercial data path से flow हो, हर description को rewrite करके नहीं।

Coverage को current, approved product-locale revisions के रूप में measure करें और held या stale records अलग report करें। API spend, reviewer effort और storefront behavior independently track करें। Catalog workflow से records define करें, फिर coverage बढ़ाने से पहले product importance और source freshness के अनुसार backlog review करें।

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