27 जून 2025·8 मिनट
लोकलाइज़ेशन और अनुवाद प्रबंधित करने के लिए वेब ऐप कैसे बनाएं?
एक वेब ऐप की योजना बनाएं जो अनुवाद वर्कफ़्लोज़, लोकेल डेटा, समीक्षा, QA चेक्स और रिलीज़्स को मैनेज करे — डेटा मॉडल, UX और इंटीग्रेशन्स सहित।
एक वेब ऐप की योजना बनाएं जो अनुवाद वर्कफ़्लोज़, लोकेल डेटा, समीक्षा, QA चेक्स और रिलीज़्स को मैनेज करे — डेटा मॉडल, UX और इंटीग्रेशन्स सहित।
लोकलाइज़ेशन प्रबंधन उस रोज़मर्रा के काम का नाम है जिसमें आपके प्रोडक्ट के टेक्स्ट (और कभी-कभी इमेज, तारीखें, मुद्राएँ और फॉर्मैटिंग नियम) को अनुवादित, समीक्षा, अनुमोदित और शिप किया जाता है—बिना बिल्ड तोड़े या यूज़र्स को भ्रमित किए।
प्रोडक्ट टीम के लिए लक्ष्य “सब कुछ अनुवादित कर देना” नहीं है। लक्ष्य हर भाषा संस्करण को सटीक, सुसंगत और प्रोडक्ट में हुए बदलावों के साथ अपडेट रखना है।
ज़्यादातर टीमें अच्छी नीयत से शुरू करती हैं और गड़बड़ में खत्म कर देती हैं:
एक उपयोगी लोकलाइज़ेशन मैनेजमेंट वेब ऐप कई रोल्स का समर्थन करता है:
आप एक MVP बनाएंगे जो स्ट्रिंग्स को केंद्रीकृत करता है, प्रत्येक लोकेल के लिए स्थिति ट्रैक करता है, और बुनियादी समीक्षा व एक्सपोर्ट का समर्थन करता है। एक पूरा सिस्टम ऑटोमेशन (सिंक, QA चेक्स), समृद्ध संदर्भ, और गोरसरी तथा अनुवाद मेमोरी जैसे टूल जोड़ता है।
टेबल्स या स्क्रीन डिजाइन करने से पहले तय करें कि आपका लोकलाइज़ेशन मैनेजमेंट वेब ऐप वास्तव में किसके लिए जिम्मेदार है। एक तंग स्कोप पहले संस्करण को उपयोगी बनाता है—और बाद में सब कुछ फिर से बनाने से रोकता है।
अनुवाद शायद एक ही जगह पर नहीं रहते। लिखें कि आपको शुरू से किसका समर्थन चाहिए:
यह सूची आपको “एक ही वर्कफ़्लो सभी के लिए” दृष्टिकोण से बचाती है। उदाहरण के लिए, मार्केटिंग कॉपी को अनुमोदन की आवश्यकता हो सकती है, जबकि UI स्ट्रिंग्स को तेज़ इटरेशन चाहिए।
MVP के लिए 1–2 फॉर्मैट चुनें, फिर बाद में बढ़ाएँ। सामान्य ऑप्शन हैं JSON, YAML, PO, और CSV। व्यावहारिक MVP विकल्प है JSON या YAML (एप स्ट्रिंग्स के लिए), और CSV केवल तब अगर आप पहले से स्प्रेडशीट इम्पोर्ट पर निर्भर हैं।
प्लुरल फ़ॉर्म्स, नेस्टेड कीज़ और कमेंट्स जैसी ज़रूरतों के बारे में स्पष्ट रहें। ये विवरण आपके लोकेल फ़ाइल प्रबंधन और भविष्य के इम्पोर्ट/एक्सपोर्ट विश्वसनीयता को प्रभावित करते हैं।
एक स्रोत भाषा पर परिभाषित करें (अक्सर en) और फॉलबैक व्यवहार सेट करें:
pt-BR → pt → en)यह भी तय करें कि प्रति लोकेल “हो गया” का क्या मतलब है: 100% अनुवादित, समीक्षा किया हुआ, या शिप किया हुआ।
MVP के लिए अनुवाद समीक्षा प्रक्रिया और बुनियादी i18n वर्कफ़्लो पर ध्यान दें: क्रिएट/एडिट स्ट्रिंग्स, वर्क असाइन करना, समीक्षा, और एक्सपोर्ट।
बाद के ऐड-ऑन की योजना बनाएं—स्क्रीनशॉट्स/संदर्भ, ग्लॉसरी, अनुवाद मेमोरी की बुनियादी बातें, और मशीन अनुवाद का इंटीग्रेशन—लेकिन तब तक न बनाएं जब तक आप अपने कोर वर्कफ़्लो को असली कंटेंट के साथ वैलिडेट न कर लें।
एक अनुवाद ऐप उसकी डेटा मॉडल पर सफल या असफल होता है। यदि अंतर्निहित एंटिटीज़ और फ़ील्ड्स स्पष्ट हैं, तो बाकी सब—UI, वर्कफ़्लो, इंटीग्रेशन—सरल हो जाता है।
अधिकांश टीमें छोटे सेट ऑफ़ टेबल्स/कलेक्शंस के साथ 80% ज़रूरतें कवर कर सकती हैं:
en, en-GB, pt-BR).checkout.pay_button).रिलेशनशिप्स को स्पष्ट रूप से मॉडल करें: एक Project के कई Locales होते हैं; एक Key एक Project से संबंधित होता है; एक Translation एक Key और एक Locale से संबंधित होता है।
प्रत्येक अनुवाद में स्टेटस जोड़ें ताकि सिस्टम मनुष्यों का मार्गदर्शन कर सके:
draft → in_review → approved\n- blocked उन स्ट्रिंग्स के लिए जो अभी शिप न हों (लीगल समीक्षा, संदर्भ गायब, आदि)स्टेटस चेंजेज़ को इवेंट्स (या हिस्ट्री टेबल) के रूप में रखें ताकि बाद में पूछा जा सके “किसने और कब इसे अप्रूव किया?”।
अनुवाद सामान्य टेक्स्ट से ज़्यादा होते हैं। कैप्चर करें:
{name}, %d) और क्या उन्हें स्रोत से मिलाना ज़रूरी है\n- मैक्स लंबाई (बटन और UI सीमाओं के लिए)\n- कॉनटेक्स्ट नोट्स (कहाँ दिखाई देता है, अर्थ, टोन)\n- टैग्स (फ़ीचर एरिया, प्लेटफ़ॉर्म, urgency)कम से कम ये ज़रूर रखें: created_by, updated_by, timestamps, और छोटा change_reason। इससे समीक्षा तेज़ होती है और टीमें भरोसा कर पाती हैं कि क्या ऐप में है वही शिप हुआ था।
स्टोरेज के फैसले सब कुछ आकार देंगे: एडिटिंग UX, इम्पोर्ट/एक्सपोर्ट स्पीड, डिफिंग, और यह कि आप कितनी पक्की निश्चिन्ति से शिप कर सकते हैं।
Row-per-key (हर स्ट्रिंग की एक DB रो प्रति की प्रति लोकेल) डैशबोर्ड्स और वर्कफ़्लो के लिए शानदार है। आप आसानी से "missing French" या "needs review" फ़िल्टर कर सकते हैं, असाइं कर सकते हैं, और प्रोग्रेस कैलक्युलेट कर सकते हैं। डाउनसाइड: एक्सपोर्ट के लिए लोकेल फ़ाइल को फिर से बनाना ग्रुपिंग और ऑर्डरिंग मांगता है, और फ़ाइल पाथ/नेमस्पेस के लिए अतिरिक्त फ़ील्ड्स चाहिए।
Document-per-file (प्रत्येक लोकेल फ़ाइल को JSON/YAML डॉक्युमेंट के रूप में स्टोर करना) रिपोज़िटरी के तरीके से साफ़ मैच करता है। एक्सपोर्ट तेज़ होता है और फ़ॉर्मैटिंग आइडेंटिकल रखना आसान होता है। लेकिन सर्च और फ़िल्टरिंग मुश्किल हो जाती है जब तक कि आप कीज़, स्टेटस और मेटाडेटा का इंडेक्स न रखें।
कई टीमें हाइब्रिड अपनाती हैं: स्रोत-सचाई के रूप में row-per-key स्टोर करें, साथ में एक्सपोर्ट के लिए जनरेटेड फाइल स्नैपशॉट रखें।
अनुवाद यूनिट स्तर (key + locale) पर रिविशन हिस्ट्री रखें। हर बदलाव रिकॉर्ड करे: पिछला वैल्यू, नया वैल्यू, लेखक, टाइमस्टैम्प, और कमेंट। इससे समीक्षा और रोलबैक सरल हो जाते हैं।
अलग से, रिलीज़ स्नैपशॉट्स ट्रैक करें: “वास्तव में क्या v1.8 में शिप हुआ।” एक स्नैपशॉट अप्रूव्ड रिविशन्स के एक संगत सेट की ओर इशारा कर सकता है ताकि बाद के एडिट्स चुपचाप शिप नहीं हो सकें।
“Plural” को एक साधारण बूलियन न समझें। ICU MessageFormat या CLDR श्रेणियाँ (उदा., one, few, many, other) उपयोग करें ताकि पॉलिश या अरबी जैसी भाषाओं को अंग्रेज़ी नियमों में न फ़िट करना पड़े।
जेंडर और अन्य वैरिएंट्स के लिए, उन्हें एक ही की (या मैसेज) के वेरिएंट्स के रूप में मॉडल करें बजाय अलग-थलग कीज़ के, ताकि अनुवादक पूरे संदर्भ को देखें।
की, स्रोत टेक्स्ट, अनुवाद, और डेवलपर नोट्स पर फुल-टेक्स्ट सर्च लागू करें। इसे ऐसे फ़िल्टर्स के साथ पेयर करें जो असल काम से मैच करें: status (new/translated/reviewed), tags, file/namespace, और missing/empty।
इन फ़ील्ड्स को जल्दी से इंडेक्स करें—सर्च वह फ़ीचर है जिसे लोग दिन में सैकड़ों बार प्रयोग करते हैं।
लोकलाइज़ेशन मैनेजमेंट वेब ऐप आम तौर पर सरल शुरू होता है—फाइल अपलोड करें, स्ट्रिंग्स एडिट करें, फिर फाइल डाउनलोड करें। यह जटिल तब हो जाता है जब आप कई प्रोडक्ट्स, कई लोकेल्स, बार-बार रिलीज़ और ऑटोमेशन (सिंक, QA, MT, रिव्यूज़) जोड़ते हैं।
लचीलापन बनाए रखने का आसान तरीका है शुरू में ही कन्सर्न्स को अलग करना।
एक सामान्य, स्केलेबल सेटअप है API + वेब UI + बैकग्राउंड जॉब्स + डेटाबेस:\n\n- Web UI: आपकी अनुवाद एडिटर, रिव्यू स्क्रीन, और प्रोजेक्ट सेटिंग्स।\n- API: UI, CLI टूल, और इंटीग्रेशन्स द्वारा उपयोग किया जाने वाला एकल सत्य स्रोत।\n- Background jobs: लंबे चलने वाला काम (इम्पोर्ट/एक्सपोर्ट, QA स्कैन, सिंक) जो UI को ब्लॉक न करें।\n- Database: प्रोजेक्ट्स, कीज़, ट्रांसलेशन्स, हिस्ट्री और परमिशन्स स्टोर करता है।
यह विभाजन आपको भारी टास्क के लिए और अधिक वर्कर्स जोड़ने में मदद करता है बिना पूरे ऐप को फिर से लिखे।
यदि आप पहले वर्किंग वर्ज़न पर तेज़ी से जाना चाहते हैं, तो एक वाइब-कोडिंग प्लेटफ़ॉर्म जैसे Koder.ai आपको वेब UI (React), API (Go), और PostgreSQL स्कीमा को एक स्ट्रक्चर्ड स्पेक से स्कैफ़ोल्ड करने में मदद कर सकता है—फिर जब आप तैयार हों तो सोर्स कोड एक्सपोर्ट कर लें और अपनी तैनाती संभाल लें।
अपने API को कुछ कोर रिसोर्सेज़ के इर्द-गिर्द रखें:\n\n- Projects: ऐप/प्रोडक्ट का कंटेनर।\n- Locales: प्रोजेक्ट पर सक्षम भाषाएँ/रीजन।\n- Keys: स्थिर पहचानकर्ता (उदा., checkout.button.pay).\n- Translations: key+locale के लिए वास्तविक टेक्स्ट, साथ में स्टेटस (draft/approved), लेखक, timestamps।
एंडपॉइंट्स को इस तरह डिजाइन करें कि वे मानवीय एडिटिंग और ऑटोमेशन दोनों का समर्थन करें। उदाहरण के लिए, कीज़ की लिस्टिंग ऐसे फ़िल्टर्स स्वीकार करे जैसे "missing in locale", "changed since", या "needs review"।
ऑटोमेशन को असिंक्रोनस वर्क के रूप में ट्रीट करें। एक क्व्यू आमतौर पर संभालती है:\n\n- इम्पोर्ट्स (लोकेल फ़ाइलें पार्स करें, वैलिडेट करें, कीज़ बनाएं/अपडेट करें)\n- एक्सपोर्ट्स (रिलीज़ के लिए लोकेल बंडल बनाएं)\n- QA चेक्स (प्लेसहोल्डर्स, लंबाई, HTML, प्रतिबंधित शब्द)\n- सिंक जॉब्स (Git, CI, या अन्य सिस्टम से पुल/पुश)
जॉब्स को idempotent बनाएं (रिट्राई पर सुरक्षित) और प्रोजेक्ट-स्तरीय जॉब लॉग रिकॉर्ड करें ताकि टीमें विफलताओं का स्व-निदान कर सकें।
छोटी टीमें भी बड़े डेटासेट बना सकती हैं। सूची (कीज़, हिस्ट्री, जॉब्स) के लिए पेजिनेशन जोड़ें, सामान्य रीड्स (प्रोजेक्ट लोकेल स्टैट्स) को कैश करें, और इम्पोर्ट/एक्सपोर्ट एंडपॉइंट्स और पब्लिक टोकन्स की रक्षा के लिए रेट लिमिट्स लागू करें।
ये बोरिंग डिटेल्स वही हैं जो आपके सिस्टम को तब धीमा पड़ने से रोकते हैं जब उपयोग बढ़ता है।
यदि आपका ऐप स्रोत स्ट्रिंग्स और अनुवाद हिस्ट्री स्टोर करता है, तो एक्सेस कंट्रोल वैकल्पिक नहीं है—यह विनाशकारी आकस्मिक एडिट्स को रोकने और निर्णयों को ट्रैसेबल रखने का तरीका है।
एक सरल सेट रोल्स अधिकांश टीमों को कवर कर देता है:\n\n- Admin: ऑर्ग सेटिंग्स, लोकेल, इंटीग्रेशन और यूज़र एक्सेस मैनेज करता है।\n- Developer: स्रोत स्ट्रिंग्स संपादित करता है, कीज़ बनाता है, इम्पोर्ट/एक्सपोर्ट ट्रिगर करता है।\n- Translator: असाइन किए गए लोकेल्स में अनुवाद संपादित करता है।\n- Reviewer: अनुवादों को अप्रूव या रिजेक्ट करता है और अंतिम शब्द लॉक करता है।\n- Viewer: स्टेकहोल्डर्स के लिए रीड-ओनली एक्सेस।
हर एक्शन को एक परमिशन मानें ताकि आप बाद में विकसित कर सकें। सामान्य नियम:\n\n- Edit source: केवल Admin, Developer (अनुवादकों को अर्थ बदलने से रोकने के लिए)\n- Approve: Reviewer (और वैकल्पिक रूप से Admin) ताकि स्पष्ट समीक्षा प्रक्रिया बनी रहे\n- Export: Developer/Admin, या Reviewer को अनुमति दें यदि वे रिलीज़ के मालिक हों\n- Manage locales: Admin केवल (नया लोकेल जोड़ना वर्कफ़्लोज़ और बजट प्रभावित करता है)\n- Edit translations: Translator/Reviewer असाइन किए गए लोकेल्स और प्रोजेक्ट्स के भीतर
यह एक अनुवाद प्रबंधन प्रणाली के साथ साफ़ मैप बनाता है और ठेका पर काम करने वालों के लिए भी लचीला रहता है।
यदि आपकी कम्पनी पहले से Google Workspace, Azure AD, या Okta का उपयोग करती है, तो SSO पासवर्ड रिस्क कम करता है और ऑफबोर्डिंग को तुरंत बनाता है। छोटू टीमों के लिए ईमेल/पासवर्ड काम कर सकता है—सिर्फ़ मजबूत पासवर्ड और रीसेट फ्लोज़ लागू करें।
सुरक्षित, कम-जीवित सेशन (HTTP-only कुकीज़), CSRF प्रोटेक्शन, रेट लिमिटिंग, और जहाँ संभव हो 2FA का उपयोग करें।
किसने क्या और कब बदला—एडिट्स, अप्रूवल्स, लोकेल चेंजेज़, एक्सपोर्ट्स, और परमिशन अपडेट—इन सबको रिकॉर्ड करें। लॉग के साथ “undo” वर्ज़न हिस्ट्री जोड़ें ताकि रोलबैक सुरक्षित और तेज़ हो (देखें /blog/plan-storage-and-versioning)।
आपका UI वह जगह है जहाँ लोकलाइज़ेशन का असल काम होता है, इसलिए उन स्क्रीन पर प्राथमिकता दें जो बैक-एंड और बेक-फोर्थ को कम करते हैं और स्थिति को एक नज़र में स्पष्ट बनाते हैं।
डैशबोर्ड से तीन सवाल जल्दी-जल्दी जवाब दें: क्या पूरा हुआ, क्या गायब है, और क्या ब्लॉक है।
प्रति लोकेल प्रगति दिखाएँ (प्रतिशत अनुवादित, प्रतिशत समीक्षा किया हुआ), साथ में स्पष्ट "मिसिंग स्ट्रिंग्स" काउंट। एक रिव्यू क्यू विजेट जोड़ें जो अप्रूवल का इंतज़ार कर रही आइटम्स को हाईलाइट करे, और "हाल ही में बदला" फीड ताकि रिव्यूवर जोखिम भरे एडिट्स देख सकें।
फ़िल्टर्स चार्ट्स से ज़्यादा मायने रखते हैं: लोकेल, प्रोडक्ट एरिया, स्टेटस, असाइनी, और "पिछली रिलीज़ से बदला"।
एक अच्छा एडिटर साइड-बाइ-साइड होता है: बाएं स्रोत, दाहिने लक्ष्य, संदर्भ हमेशा दिखे।
संदर्भ में की, स्क्रीनशॉट टेक्स्ट (यदि मौजूद हो), कैरेक्टर लिमिट्स, और प्लेसहोल्डर्स (उदा., {name}, %d) शामिल हों। इतिहास और टिप्पणियाँ उसी व्यू में हों ताकि अनुवादकों को अलग “डिस्कशन” स्क्रीन न खोलनी पड़े।
स्टेटस वर्कफ़्लो को एक क्लिक में रखें: Draft → In review → Approved।
लोकलाइज़ेशन का काम अक्सर "कई छोटे बदलाव" होता है। बल्क सेलेक्ट जोड़ें जिनमें असाइन टू यूज़र/टीम, स्टेटस बदलना, और किसी लोकेल या मॉड्यूल के लिए एक्सपोर्ट/इम्पोर्ट जैसी क्रियाएँ हों।
बल्क एक्शन्स को रोल्स द्वारा गेटेड रखें (देखें /blog/roles-permissions-for-translators)।
भारी अनुवादक घंटों एडिटर में रहते हैं। फुल कीबोर्ड नेविगेशन, दृश्यमान फोकस स्टेट्स, और शॉर्टकट्स का समर्थन करें जैसे:\n\n- नेक्स्ट/प्रीवियस स्ट्रिंग\n- सेव और मार्क "In review"\n- स्रोत को लक्ष्य में कॉपी करना\n स्क्रीन रीडर्स और हाई-कॉन्ट्रास्ट मोड का भी समर्थन करें—एक्सेसिबिलिटी सभी के लिए गति बढ़ाती है।
एक लोकलाइज़ेशन मैनेजमेंट वेब ऐप वर्कफ़्लो पर सफल या असफल होता है। यदि लोग यह नहीं बता पा रहे कि अगला क्या अनुवाद करना है, किसने निर्णय लिया है, या कोई स्ट्रिंग ब्लॉक क्यों है, तो आपको देरी और असंगत गुणवत्ता मिलेगी।
एक स्पष्ट वर्क यूनिट के साथ शुरुआत करें: एक लोकेल के लिए कीज़ का सेट किसी विशेष वर्ज़न में। प्रोजेक्ट मैनेजर (या लीड्स) को अनुमति दें कि वे लोकेल, फाइल/मॉड्यूल, और प्राथमिकता के आधार पर असाइन करें, साथ में वैकल्पिक ड्यू डेट।
असाइनमेंट को "मेरा काम" इनबॉक्स में दिखाएँ जो तीन सवालों के जवाब दे: क्या असाइन है, क्या ओवरड्यू है, और क्या दूसरों पर इंतज़ार कर रहा है। बड़ी टीमों के लिए वर्कलोड संकेत जोड़ें (आइटम की गिनती, शब्द गणना अनुमान, आखिरी गतिविधि) ताकि असाइनमेंट्स निष्पक्ष हों।
समीक्षा एक सरल स्टेटस पाइपलाइन होनी चाहिए, उदाहरण: Untranslated → In progress → Ready for review → Approved।
समीक्षा केवल द्विआधारी जांच से ज़्यादा होनी चाहिए। इनलाइन कमेंट्स, सुझावित संपादन, और अनुमोदन/अस्वीकृति कारण सहित का समर्थन करें। जब रिव्यूवर रिजेक्ट करे, तो हिस्ट्री रखें—ओवरराइट न करें।
यह आपकी अनुवाद समीक्षा प्रक्रिया को ऑडिटेबल बनाता है और बार-बार होने वाली गलतियों को कम करता है।
स्रोत टेक्स्ट बदलेगा। जब ऐसा होता है, मौजूदा अनुवादों को Needs update के रूप में मार्क करें और एक डिफ़ या "क्या बदला" सारांश दिखाएँ। पुराने अनुवाद को संदर्भ के रूप में रखें, लेकिन उसे बिना स्पष्ट निर्णय के फिर से अप्रूव न होने दें।
इवेंट्स पर नोटिफ़ाई करें जो प्रगति को ब्लॉक करते हैं: नया असाइनमेंट, समीक्षा का अनुरोध, रिजेक्शन, ड्यू डेट पास होना, और स्रोत परिवर्तन जो अप्रूव्ड स्ट्रिंग्स को प्रभावित करता है।
नोटिफिकेशन्स को actionable रखें और डीप लिंक दें जैसे /projects/{id}/locales/{locale}/tasks ताकि लोग एक क्लिक में मुद्दा सुलझा सकें।
मैन्युअल फ़ाइल जुगलिंग वही जगह है जहां लोकलाइज़ेशन प्रोजेक्ट्स शुरू में भटकना शुरू करते हैं: अनुवादक स्टेल स्ट्रिंग्स पर काम करते हैं, डेवलपर अपडेट खींचना भूल जाते हैं, और रिलीज़ आंशिक-तैयार लोकेल्स के साथ शिप हो जाती है।
एक अच्छा लोकलाइज़ेशन मैनेजमेंट वेब ऐप इम्पोर्ट/एक्सपोर्ट को एक रिपीटेबल पाइपलाइन के रूप में ट्रीट करे, न कि एक वन-ऑफ टास्क।
टीम्स वास्तव में जिन पाथ्स का उपयोग करती हैं उनका समर्थन करें:\n\n- रिपो से पुल करें (GitHub/GitLab/Bitbucket): शेड्यूल पर या ऑन-डिमांड लोकेल फाइलें फेच करें।\n- रिपो में पुश करें: अपडेटेड अनुवादों के साथ PR खोलें बजाय सीधे main में लिखने के।\n- मैन्युअल अपलोड/डाउनलोड: वेन्डर्स या लेगेसी प्रोजेक्ट्स के लिए अभी भी ज़रूरी।
एक्सपोर्ट करते समय फ़िल्टरिंग अनुमति दें: प्रोजेक्ट, ब्रांच, लोकेल, और स्टेटस (उदा., "approved only") ताकि आंशिक समीक्षा वाले स्ट्रिंग्स प्रोडक्शन में न लीक हों।
सिंक तभी काम करता है जब कीज़ स्थिर रहें। शुरुआती ही तय कर लें कि स्ट्रिंग्स कैसे जेनरेट होंगी:\n\n- यदि आप ह्यूमन-रीडेबल कीज़ इस्तेमाल करते हैं (उदा., checkout.button.pay_now), तो आकस्मिक रेनाम से उन्हें प्रोटेक्ट करें।\n- यदि आप हैश-आधारित कीज़ उपयोग करते हैं, तो स्रोत स्ट्रिंग और संदर्भ स्टोर करें ताकि अपडेट्स चुपचाप डुप्लिकेट न बना दें।
आपका ऐप यह पता लगा सके कि स्रोत स्ट्रिंग बदल गया है पर की वही है, और अनुवादों को ओवरराइट करने की बजाय needs review के रूप में मार्क करे।
वेबहुक जोड़ें ताकि सिंक ऑटोमैटिक हो:\n\n- main पर नया कमिट → अपडेटेड स्रोत स्ट्रिंग्स इम्पोर्ट करें।\n- रिलीज़ टैग क्रिएट → "approved" अनुवाद एक्सपोर्ट करें और PR खोलें।
वेबहुक idempotent होने चाहिए (दोबारा चलाने पर सुरक्षित) और स्पष्ट लॉग बनाना चाहिए: क्या बदला, क्या स्किप हुआ, और क्यों।
यदि आप इसे इम्प्लिमेंट कर रहे हैं, तो सबसे सरल एंड-टू-एंड सेटअप (रिपो एक्सेस + वेबहुक + PR एक्सपोर्ट) का दस्तावेज़ UI से लिंक कर दें, उदाहरण: /docs/integrations।
लोकलाइज़ेशन QA वह जगह है जहाँ एक अनुवाद मैनेजमेंट ऐप सिर्फ़ एक एडिटर नहीं रह जाता और प्रोडक्शन बग्स को रोकना शुरू कर देता है।
लक्ष्य है रिलीज़ से पहले ही समस्याओं को पकड़ना—खासकर वे जो केवल किसी विशेष लोकेल फ़ाइल में दिखाई देते हैं।
उन चेक्स से शुरू करें जो UI तोड़ सकते हैं या फ़ॉर्मैटिंग क्रैश करवा सकते हैं:\n\n- गायब या मिसमैच्ड प्लेसहोल्डर्स (उदा., {count} अंग्रेज़ी में है पर फ्रेंच में गायब, या प्लुरल फॉर्म्स असंगत)\n- इनवैलिड HTML उन स्ट्रिंग्स में जहाँ मार्कअप की अनुमति है (टूटा टैग, अनक्लोज्ड एंटिटी)\n- अनएस्केप्ड कैरैक्टर फ़ाइल फॉर्मैट के अनुसार (JSON में क्वोट्स, printf-स्टाइल स्ट्रिंग्स में बेमेल %)\n
इन्हें डिफ़ॉल्ट रूप से "रिलीज़ ब्लॉक करने वाला" मानें, और स्पष्ट एरर मेसेज व की/लोकेल के सटीक पॉइंटर दें।
ये हमेशा ऐप को तोड़ते नहीं, पर क्वालिटी और ब्रांड सुसंगतता को नुकसान पहुंचाते हैं:\n\n- ग्लॉसरी शब्द: जब किसी आवश्यक टर्म का उपयोग नहीं हुआ या असंगत अनुवाद हुआ तो फ्लैग करें।\n- पंक्चुएशन, व्हाइटस्पेस, और केसिंग: डबल स्पेसेस, ट्रेलिंग स्पेस, मिसिंग फाइनल पंक्चुएशन, या असंगत कोट्स।
टेक्स्ट सही होने के बाद भी गलत दिख सकता है। प्रति की स्क्रीनशॉट संदर्भ अनुरोध करने का एक तरीका जोड़ें (या किसी की के साथ स्क्रीनशॉट अटैच करें), ताकि रिव्यूवर ट्रनकेशन, लाइन ब्रेक और टोन को वास्तविक UI में वैलिडेट कर सकें।
हर रिलीज़ से पहले प्रति लोकेल QA सारांश जेनरेट करें: एरर्स, वार्निंग्स, अनुवादित नहीं हुए स्ट्रिंग्स, और टॉप ऑफेंडर्स।
इसे एक्सपोर्ट या इंटरनल लिंक करना आसान रखें (उदा., /releases/123/qa) ताकि टीम के पास एकल "go/no-go" दृश्य हो।
ग्लॉसरी, TM, और मशीन ट्रांसलेशन जोड़ना लोकलाइज़ेशन को काफी तेज कर सकता है—बशर्ते आपका ऐप इन्हें मार्गदर्शन और ऑटोमेशन के रूप में ट्रीट करे, न कि "तुरंत प्रकाशित करने योग्य" सामग्री के रूप में।
ग्लॉसरी वह क्यूरेट सूची है जिसमें टर्म्स और प्रति लोकेल स्वीकृत अनुवाद होते हैं (प्रोडक्ट नाम, UI अवधारणाएँ, लीगल फ़्रेज़)।
एंट्रीज़ को टर्म + लोकेल + स्वीकृत अनुवाद + नोट्स + स्टेटस के रूप में स्टोर करें।
इसे लागू करने के लिए, अनुवाद संपादन में चेक जोड़ें:\n\n- स्रोत स्ट्रिंग के अंदर ग्लॉसरी मैच हाइलाइट करें और स्वीकृत लक्ष्य टर्म सुझाएँ।\n- जब अनुवाद अनिवार्य ग्लॉसरी टर्म से अलग हो तो चेतावनी दें (या प्रोजेक्ट सेटिंग्स के मुताबिक ब्लॉक करें)।\n- सिंपल नियमों के माध्यम से इन्फ्लेक्शंस/वेरिएंट्स का समर्थन करें ताकि एन्फोर्समेंट बहुत कड़ा न हो।
TM पहले से स्वीकृत अनुवादों को पुन: उपयोग करता है। इसे सरल रखें:\n\n- (नॉर्मलाइज़्ड स्रोत टेक्स्ट, कॉन्टेक्स्ट की, लोकेल) द्वारा इंडेक्स करें।\n- पहले "approved" सैगमेंट दिखाएँ; बैकअप के रूप में "reviewed" या "imported"।\n- मैच क्वालिटी दिखाएँ (एक्ज़ैक्ट वर्सेस फज़ी) और ओरिजिनल कॉन्टेक्स्ट दिखाएँ ताकि उपयोगकर्ता सुझावों पर भरोसा करें।
TM को एक सुझाव प्रणाली के रूप में ट्रीट करें: उपयोगकर्ता मैच को स्वीकार, संपादित, या रिजेक्ट कर सकते हैं, और केवल स्वीकार किए गए अनुवाद TM में वापस फ़ीड हों।
MT ड्राफ्ट्स और बैकलॉग्स के लिए उपयोगी है, पर यह डिफॉल्ट फाइनल आउटपुट नहीं होना चाहिए।
MT को प्रोजेक्ट और जॉब के हिसाब से ऑप्ट-इन बनाएं, और MT-भराई गई स्ट्रिंग्स को सामान्य समीक्षा प्रक्रिया से होकर ही गुजरने दें।
विभिन्न टीमों की अलग ज़रूरतें होती हैं। एडमिन्स को प्रदाताओं का चयन करने, उपयोग सीमाएँ सेट करने, और कौन सा डेटा भेजा जाए (उदा., संवेदनशील कीज़ को छोड़ना) चुनने दें।
लागत दृश्यता और ऑडिटिंग के लिए अनुरोध लॉग रखें, और विकल्पों को /settings/integrations में दस्तावेज़ करें।
एक लोकलाइज़ेशन ऐप को सिर्फ़ "अनुवाद स्टोर" से ज़्यादा होना चाहिए—उसे उन्हें सुरक्षित रूप से शिप करने में मदद करनी चाहिए।
मुख्य विचार है रिलीज़: अनुमोदित स्ट्रिंग्स का एक फ्रीज़्ड स्नैपशॉट ताकि जो डिप्लॉय हो रहा है वह पूर्वानुमेय और पुनरुत्पाद्य हो।
रिलीज़ को एक अपरिवर्तनीय बंडल मानें:\n\n- लोकेल + नेम्स्पेस/फाइल + की + अंतिम स्वीकृत टेक्स्ट\n- मेटाडेटा: अप्रूवल स्टेटस, रिव्यूवर, टाइमस्टैम्प, स्रोत स्ट्रिंग हैश\n- वैकल्पिक: बिल्ड नंबर, git कमिट, और ऐप वर्ज़न\n यह आपको यह बताने देता है: “हमने v2.8.1 में fr-FR के लिए क्या शिप किया?” बिना अनुमान लगाए।
ज़्यादातर टीमें रेअल यूज़र्स से पहले अनुवादों का वैलिडेशन चाहती हैं। एक्सपोर्ट को एनवायरनमेंट के अनुसार मॉडल करें:\n\n- Staging export: नई अप्रूव्ड स्ट्रिंग्स और सम्भवतः "कैंडिडेट" अनुवाद प्रीव्यू के लिए\n- Production export: केवल पूरी तरह अप्रूव्ड कंटेंट, एक रिलीज़ ID से जुड़ा हुआ\n
एक्सपोर्ट एंडपॉइंट को स्पष्ट रखें (उदा., /api/exports/production?release=123) ताकि बिना समीक्षा वाले टेक्स्ट का रिसाव न हो।
रोलबैक सबसे आसान तब होता है जब रिलीज़ इम्यूटेबल हों। यदि किसी रिलीज़ ने समस्याएँ पेश कीं (टूटे प्लेसहोल्डर्स, गलत शब्दावली), तो आपको सक्षम होना चाहिए:\n\n- ऐप को पिछले रिलीज़ एक्सपोर्ट पर रिवर्ट करें\n- समस्याग्रस्त स्ट्रिंग्स फिर से खोलें, ठीक करें, और नई रिलीज़ काटें\n “प्रोडक्शन में सीधे संपादन” से बचें—यह ऑडिट ट्रेल को तोड़ देता है और घटनाओं का विश्लेषण मुश्किल बनाता है।
नोट करें कि यह "स्नैपशॉट + रोलबैक" मानसिकता आधुनिक बिल्ड प्लेटफ़ॉर्म्स के साथ अच्छी तरह मेल खाती है। उदाहरण के लिए, Koder.ai स्नैपशॉट्स और रोलबैक को पहले-श्रेणी वर्कफ़्लो के रूप में शामिल करता है, जो लोकलाइज़ेशन रिलीज़ के इम्यूटेबल विचार के डिजाइन में उपयोगी है।
डिप्लॉयमेंट के बाद, एक छोटा ऑपरेशनल चेकलिस्ट चलाएँ:\n\n- सभी लोकेल्स के लिए एक्सपोर्ट सफल रहा; कोई फ़ाइल मिसिंग नहीं\n- प्रमुख यूज़र पाथ्स के लिए बेसिक रनटाइम स्मोक टेस्ट\n- अनुवाद एरर सिग्नल्स की मॉनिटरिंग (मिसिंग कीज़, प्लेसहोल्डर मिसमैच, अचानक फ़ॉलबैक स्पाइक्स)
यदि आप रिलीज़ हिस्ट्री UI में दिखाते हैं, तो “डिफ़ बनाम पिछली रिलीज़” व्यू जोड़ें ताकि टीमें जल्दी जोखिम भरे बदलाव देख सकें।
सुरक्षा और दृश्यता एक उपयोगी लोकलाइज़ेशन टूल और उसे टीमें भरोसे के साथ उपयोग कर सकें—के बीच का फर्क है। जब आपका वर्कफ़्लो चलने लगे, तो इसे लॉक करें और मापना शुरू करें।
डिफ़ॉल्ट रूप से सबसे कम विशेषाधिकार लागू करें: अनुवादकों को प्रोजेक्ट सेटिंग्स बदलने की अनुमति न दें, और रिव्यूवर्स को बिलिंग या एडमिन-ओनली एक्सपोर्ट्स तक पहुंच न दें। रोल्स स्पष्ट और ऑडिटेबल बनाएं।
सीक्रेट्स को सुरक्षित रखें। डेटाबेस प्रमाणपत्र, वेबहुक साइनिंग कीज़, और थर्ड-पार्टी टोकन्स को सीक्रेट्स मैनेजर या एन्क्रिप्टेड एनवायरनमेंट वेरिएबल में रखें—कभी भी रिपो में न रखें। जब कोई टीम छोड़ता है तो कीज़ को रोटेट करें।
बैकअप वैकल्पिक नहीं हैं। अपने डेटाबेस और ऑब्जेक्ट स्टोरेज (लोकेल फाइल्स, अटैचमेंट) के ऑटोमैटिक बैकअप लें, रिस्टोर टेस्ट करें, और रिटेंशन परिभाषित करें—एक “बैकअप जो रिस्टोर नहीं हो पाता” सिर्फ़ एक्स्ट्रा स्टोरेज है।
यदि स्ट्रिंग्स में यूज़र कंटेंट (सपोर्ट टिकट, नाम, पते) शामिल हो सकता है, तो उन्हें अनुवाद सिस्टम में स्टोर करने से избег करें। प्लेसहोल्डर्स या रेफरेंसेज़ का उपयोग करें, और लॉग्स से संवेदनशील वैल्यूज़ हटाएँ।
यदि आपको ऐसा टेक्स्ट प्रोसेस करना ही है, तो रिटेंशन नियम और एक्सेस प्रतिबंध परिभाषित करें।
कुछ ऐसे मैट्रिक्स ट्रैक करें जो वर्कफ़्लो की सेहत को दर्शाते हों:\n\n- थ्रूपुट: प्रतिदिन/सप्ताह में अनुवादित स्ट्रिंग्स\n- रिव्यू समय: "अनुवादित" से "अप्रूव्ड" तक का औसत समय\n- टॉप चेंज्ड कीज़: अस्थिर UI एरिया पहचानें जो बार-बार बदलते हैं और पुनर्गठित किए जाने चाहिए
एक सरल डैशबोर्ड और CSV एक्सपोर्ट शुरुआत के लिए काफी है।
बुनियादी आधार मजबूत होने पर विचार करें:\n\n- push/pull और स्टेटस चेक्स के लिए एक डेवलपर CLI\n- UI में स्ट्रिंग्स का प्रीव्यू देने वाला इन-कॉन्टेक्स्ट एडिटर\n- इंटीग्रेशन्स के लिए API कीज़ (CI, GitHub/GitLab, Slack)
यदि आप इसे एक प्रोडक्ट के रूप में ऑफ़र करने की योजना बना रहे हैं, तो एक स्पष्ट अपग्रेड पाथ और कॉल-टू-एक्शन जोड़ें (देखें /pricing)।
यदि आपका तत्काल लक्ष्य असली उपयोगकर्ताओं के साथ वर्कफ़्लो को जल्दी वैलिडेट करना है, तो आप MVP को Koder.ai पर भी प्रोटोटाइप कर सकते हैं: प्लानिंग मोड में रोल्स, स्टेटस फ्लो, और इम्पोर्ट/एक्सपोर्ट फॉर्मैट्स बताएं, चैट के जरिए React UI और Go API पर इटरेट करें, और जब तैयार हों तो कोडबेस एक्सपोर्ट कर लें और प्रोडक्शन के लिए हार्डन करें।
एक लोकलाइज़ेशन मैनेजमेंट वेब ऐप आपके स्ट्रिंग्स को केंद्रीकृत करता है और उनके चारों ओर की वर्कफ़्लो—अनुवाद, समीक्षा, अनुमोदन और एक्सपोर्ट—को मैनेज करता है, ताकि टीमें बिना टूटे हुए कीज़, गायब प्लेसहोल्डर्स, या अस्पष्ट स्थिति के अपडेट शिप कर सकें।
प्रारम्भ में यह तय करें:
pt-BR → pt → en)एक तंग स्कोप “एक वर्कफ़्लो सबके लिए” की गलतियों को रोकता है और MVP को उपयोगी बनाए रखता है।
अधिकांश टीमें निम्नलिखित कोर इकाइयों से 80% मामलों को कवर कर सकती हैं:
वे मेटाडेटा कैप्चर करें जो प्रोडक्शन त्रुटियों और समीक्षा झंझटों से बचाए:
यह निर्भर करता है कि आप किसे प्राथमिकता दे रहे हैं:
कई टीमें हाइब्रिड अपनाती हैं: स्रोत-सत्य के लिए row-per-key और एक्सपोर्ट के लिए जनरेटेड फाइल स्नैपशॉट्स।
दो परतों का उपयोग करें:
यह “साइलेंट एडिट्स” को रोकता है जो पहले से शिप किए गए कंटेंट को बदल देते हैं और घटनाओं का डिबग आसान बनाता है।
शुरू में वही रोल्स रखें जो असल काम से मिलते हों:
API को कुछ मूल संसाधनों के इर्द-गिर्द रखें:
Projects, Locales, Keys, Translationsफिर लिस्ट एंडपॉइंट्स को वास्तविक कार्यों के लिए फ़िल्टर करने के योग्य बनाएं, जैसे:
लंबे चलने वाले कामों को असिंक्रोनस मानें:
जॉब्स को idempotent बनाएं (दोबारा चलाने पर सुरक्षित) और प्रोजेक्ट-स्तर पर लॉग रखें ताकि टीमें अपने आप फेल्यर का निदान कर सकें।
ऐसे चेक्स प्राथमिकता दें जो टूटी UI को रोकें:
{count}, %d) और प्लुरल-फॉर्म कवरेजडिफ़ॉल्ट रूप से इन्हें रिलीज़-ब्लॉकिंग मानें, और गाइडलाइन/व्हाइटस्पेस जैसी चीज़ों के लिए नरम वार्निंग्स जोड़ें।
draft → in_review → approved)यदि ये एंटिटीज़ साफ़ हों तो UI स्क्रीन, अनुमतियाँ और इंटीग्रेशन आसानी से बनाते/निर्वाहित किए जा सकते हैं।
created_by, updated_by, timestamps, change reason)यह “सिर्फ़ एक टेक्स्ट एडिटर” और एक भरोसेमंद सिस्टम के बीच का फर्क बनता है।
हर एक्शन के लिए परमिशन परिभाषित करें (सोर्स एडिट, अप्रूव, एक्सपोर्ट, लोकेल प्रबंधित करना) ताकि सिस्टम बिना वर्कफ़्लो तोड़े विकसित हो सके।
यह UI में मानवीय एडिटिंग और CLI/CI द्वारा ऑटोमेशन दोनों का समर्थन करता है।