Chat-निर्मित ऐप्स के लिए अंतरराष्ट्रीयकरण आर्किटेक्चर

जब आप और भाषाएँ जोड़ते हैं तो सबसे पहले क्या टूटता है

सबसे पहले टूटने वाली चीज़ कोड नहीं होती। वो शब्द होते हैं।

Chat-निर्मित ऐप अक्सर तेज प्रोटोटाइप के रूप में शुरू होते हैं: आप टाइप करते हैं "एक बटन जोड़ें जिस पर "Save" लिखा हो", UI दिखता है, और आप आगे बढ़ जाते हैं। कुछ हफ्ते बाद, आप स्पैनिश और जर्मन चाहते हैं और पाते हैं कि वे "अस्थायी" लेबल स्क्रीन, कंपोनेंट्स, ईमेल और एरर संदेशों में बिखरे हुए हैं।

कॉपी बदलना कोड की तुलना में अधिक बार होता है। प्रोडक्ट नाम बदले जाते हैं, कानूनी टेक्स्ट बदलता है, ऑनबोर्डिंग फिर से लिखा जाता है, और सपोर्ट क्लियर एरर संदेश मांगता है। अगर टेक्स्ट सीधे UI कोड में रहता है, तो हर छोटा शब्द बदलना खतरनाक रिलीज़ बन जाता है, और आप उन जगहों को मिस कर देंगे जहाँ वही विचार अलग तरीक़े से लिखा गया है।

यहाँ शुरुआती लक्षण हैं जो बताते हैं कि आप अनुवाद कर्ज (translation debt) बना रहे हैं:

• एक ही स्क्रीन पर मिली-जुली भाषाएँ (कुछ स्ट्रिंग्स अनुवादित, अन्य अभी भी अंग्रेज़ी में)।
• एक जैसा लेबल छोटे-छोटे फ़र्कों के साथ डुप्लिकेट होना ("Sign up", "Sign Up", "Create account").
• टेक्स्ट लंबा होने पर टूटे हुए लेआउट (बटन ओवरफ़्लो, हेडिंग्स खराब तरीके से ब्रेक हो जाना)।
• मोबाइल और वेब का अलगाव (एक ही क्रिया के लिए अलग शब्द)।
• सपोर्ट कंटेंट और सिस्टम संदेश UI के पीछे रह जाना।

एक यथार्थ उदाहरण: आप Koder.ai में एक साधारण CRM बनाते हैं। वेब ऐप पर लिखा है “Deal stage”, मोबाइल ऐप पर है “Pipeline step”, और एक एरर टोस्ट कहता है “Invalid status”。अगर तीनों का अनुवाद भी किया गया हो, उपयोगकर्ता ऐप को असंगत महसूस करेंगे क्योंकि अवधारणाएँ मेल नहीं खातीं।

"सुसंगत" का मतलब हर जगह समान अक्षर नहीं होता। इसका मतलब है:

• एक ही अवधारणा पूरे UI में एक ही की और एक ही अर्थ से जुड़ी हो।
• वेब और मोबाइल अनुवादों के लिए एक ही स्रोत सत्य हो।
• टोन और शब्दावली स्थिर हों (औपचारिक बनाम अनौपचारिक, “customer” बनाम “client”)।
• UI लेआउट लंबी और छोटी दोनों तरह की वाक्यों को संभालने के लिए डिजाइन किए गए हों।

एक बार आप टेक्स्ट को सजावट नहीं बल्कि प्रोडक्ट डेटा मानने लगे, भाषाएँ जोड़ना घमासान नहीं रह जाता बल्कि निर्माण का नियमित हिस्सा बन जाता है।

मूल अवधारणाएँ और एक सरल लक्ष्य

Internationalization (i18n) वह काम है जिससे एक ऐप बिना री-राइट के कई भाषाओं को सपोर्ट कर सके। Localization (l10n) किसी खास भाषा और क्षेत्र के लिए असल कंटेंट है — जैसे फ्रेंच (कनाडा) के लिए सही शब्द, तारीख़ फ़ॉर्मेट और टोन।

एक सरल लक्ष्य: हर यूज़र-नेज़र टेक्स्ट एक स्थिर की (key) से चयनित हो, न कि UI कोड में सीधे टाइप किया गया हो। अगर आप कोई वाक्य बिना किसी React component या Flutter widget खोले बदल सकते हैं, तो आप सही दिशा में हैं। यह chat-निर्मित ऐप्स के लिए i18n आर्किटेक्चर का मूल है, जहाँ चैट से जेनरेट की गई हार्ड-कोडेड कॉपी आसानी से शिप हो सकती है।

यूज़र-फेसिंग टेक्स्ट अधिकांश टीमों की अपेक्षा से व्यापक होता है। इसमें बटन, लेबल, वैलिडेशन एरर, खाली अवस्थाएँ, ऑनबोर्डिंग टिप्स, पुश नोटिफिकेशन्स, ईमेल, PDF एक्सपोर्ट और कोई भी संदेश शामिल है जो उपयोगकर्ता देख या सुन सकता है। आमतौर पर इसमें इंटरनल लॉग्स, डेटाबेस कॉलम नाम, एनालिटिक्स इवेंट IDs, फीचर फ़्लैग्स या केवल एडमिन-डिबग आउटपुट शामिल नहीं होते।

अनुवाद कहाँ रहने चाहिए? व्यवहार में, यह अक्सर frontend और backend दोनों में रहता है, पर एक स्पष्ट सीमा के साथ।

• Frontend UI chrome (navigation, forms, menus और अधिकतर स्क्रीन टेक्स्ट) की जिम्मेदारी लेता है।
• Backend उन संदेशों का मालिक है जो वह जनरेट करता है: transactional emails, server-side validation errors, और जो कुछ error response के रूप में लौटता है।
• साझा डोमेन (जैसे order status लेबल) को एक स्रोत सत्य से आना चाहिए ताकि वेब और मोबाइल अलग न हों।

गलती यह है कि जिम्मेदारियों को मिलाया जाए। अगर backend पूर्ण अंग्रेज़ी वाक्य UI एरर के रूप में लौटाता है, तो frontend उन्हें साफ़-सुथरा लोकलाइज़ नहीं कर पाएगा। बेहतर पैटर्न: backend एक error code लौटाए (और शायद सुरक्षित पैरामीटर्स), और client उस कोड को स्थानीयकृत संदेश में मैप करे।

कॉपी का मालिकाना हक़ प्रोडक्ट निर्णय है, तकनीकी विवरण नहीं। जल्दी तय कर लें कि कौन शब्द बदल सकता है और टोन को कौन अप्रूव करेगा।

अगर प्रोडक्ट कॉपी का मालिक है, तो अनुवाद को कंटेंट जैसा ट्रीट करें: version करें, review करें, और प्रोडक्ट को बदलाव के लिए सुरक्षित तरीका दें। अगर इंजीनियरिंग कॉपी का मालिक है, तो नियम रखें कि कोई नई UI स्ट्रिंग तब तक शिप नहीं होगी जब तक उसके साथ एक की और डिफ़ॉल्ट अनुवाद न मिल जाए।

उदाहरण: अगर आपका signup flow तीन अलग स्क्रीन में "Create account" कहता है, तो इसे एक की बनाइए और हर जगह वही की उपयोग कीजिए। इससे अर्थ सुसंगत रहता है, अनुवादक तेज़ होते हैं, और छोटे शब्द बदलाव मल्टी-स्क्रीन क्लीनअप नहीं बनते।

स्ट्रिंग कीज़ को ऐसा ढाँचा दें जो स्थिर रहे

कीज़ आपकी UI और अनुवादों के बीच का कॉन्ट्रैक्ट होती हैं। अगर वह कॉन्ट्रैक्ट बदलता रहता है, तो आप missing text, जल्दी-जल्दी fixes और वेब/मॉबाइल पर असंगत शब्दावली पाएंगे। chat-निर्मित ऐप्स के लिए अच्छा i18n आर्किटेक्चर इस एक नियम से शुरू होता है: कीज़ वर्तमान अंग्रेज़ी वाक्य के बजाय अर्थ बताएं।

स्थिर IDs का उपयोग करें (जैसे billing.invoice.payNow) पूरे वाक्य के बजाय (जैसे "Pay now")। वाक्य-आधारित कीज़ तभी टूटती हैं जब कोई शब्द बदलता है, विराम चिह्न जोड़ता है, या केस बदलता है।

एक व्यावहारिक पैटर्न जो पठनीय भी रहे और टिके भी: screen (या domain) + component + intent। इसे नीरस और अनुमान्य रखें।

उदाहरण:

• auth.login.title
• auth.login.emailLabel
• billing.checkout.payButton
• nav.settings
• errors.network.offline

यह तय करने के लिए कि एक की को रीयूज़ करना है या नया बनाना है, पूछें: “क्या अर्थ हर जगह बिल्कुल समान है?” सामान्य क्रियाओं के लिए कीज़ रीयूज़ करें, पर जब संदर्भ बदलता है तो अलग की बनाएं। उदाहरण के लिए, प्रोफ़ाइल स्क्रीन में “Save” एक साधारण क्रिया हो सकती है, जबकि किसी जटिल एडिटर में वही “Save” कुछ भाषाओं में अलग टोन चाह सकता है।

साझा UI टेक्स्ट समर्पित नामस्पेस में रखें ताकि यह विभिन्न स्क्रीन में डुप्लिकेट न हो। कुछ सामान्य बकेट जो अच्छे काम करते हैं:

• common.actions.* (save, cancel, delete)
• common.status.* (loading, success)
• common.fields.* (search, password)
• errors.* (validation, network)
• nav.* (tabs, menu items)

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

Koder.ai-शैली के एक छोटे उदाहरण में: आपकी चैट React वेब ऐप और Flutter मोबाइल ऐप दोनों जेनरेट करती है। अगर दोनों common.actions.save उपयोग करते हैं, तो हर जगह सुसंगत अनुवाद मिलते हैं। पर अगर वेब profile.save और मोबाइल account.saveButton उपयोग करें, तो समय के साथ वे अलग हो जाएंगे, भले ही आज अंग्रेज़ी समान दिखे।

स्ट्रिंग्स कहाँ रखें और अनुवाद फ़ाइलें कैसे व्यवस्थित करें

अपने स्रोत भाषा (अक्सर अंग्रेज़ी) को सिंगल सोर्स ऑफ़ ट्रुथ मानें। उसे एक जगह रखें, कोड की तरह review करें, और न रखें कि स्ट्रिंग्स घटकों में "बस अभी के लिए" दिखाई दें। यह हार्ड-कोडेड UI कॉपी और बाद की री-वर्क से बचने का सबसे तेज़ तरीका है।

एक सरल नियम मदद करता है: ऐप को केवल i18n सिस्टम से टेक्स्ट दिखाना चाहिए। अगर किसी को नई कॉपी चाहिए, तो वे पहले एक की और डिफ़ॉल्ट संदेश जोड़ें, फिर UI में वही की इस्तेमाल करें। यह आपके i18n आर्किटेक्चर को स्थिर रखता है भले ही फीचर्स इधर-उधर हों।

एक फ़ोल्डर लेआउट जो समझदारी से रहे

यदि आप वेब और मोबाइल दोनों भेजते हैं, तो आप एक साझा कीट-कैटलॉग चाहते हैं, साथ ही फीचर टीमों के लिए अलग काम करने की जगह। एक व्यावहारिक लेआउट:

• /i18n
• /i18n/locales/en.json (source)
• /i18n/locales/es.json, /i18n/locales/fr.json, ...
• /i18n/features/billing.json, /i18n/features/auth.json, ...
• /i18n/shared.json (buttons, common labels, errors)

प्लैटफ़ॉर्म के बावजूद कीज़ एक समान रखें (React वेब पर हो या Flutter मोबाइल पर)। अगर आप Koder.ai जैसी प्लेटफ़ॉर्म से दोनों ऐप जेनरेट करते हैं, तो स्रोत कोड का एक्सपोर्ट आसान होता है जब दोनों प्रोजेक्ट एक ही की नाम और एक ही संदेश फ़ॉर्मेट की ओर पॉइंट करें।

वर्शनिंग और समीक्षा जो अनुवाद कर्ज रोकती हैं

अनुवाद समय के साथ बदलते हैं। बदलावों को प्रोडक्ट बदलाव की तरह ट्रीट करें: छोटे, समीक्षा किए हुए और ट्रैकेबल। एक अच्छी समीक्षा अर्थ और रीयूज़ पर केंद्रित होती है, सिर्फ़ वर्तनी पर नहीं।

• किसी भी स्रोत लोकैल में बदलाव के लिए PR समीक्षा अनिवार्य करें
• कीज़ को बिना खोज और प्लान के डिलीट करने पर ब्लॉक रखें
• जब टेक्स्ट अस्पष्ट हो तो अनुवादकों के लिए नोट्स जोड़ें
• CI में एक सरल "missing translations" चेक जोड़ें

टीमों के बीच कीज़ के बहाव को रोकने के लिए कीज़ फीचर्स के मालिक हों (billing., auth.), और सिर्फ़ वर्डिंग बदलने के लिए कीज़ का नाम न बदलें। कीज़ पहचानकर्ता हैं, कॉपी नहीं।

बिना हैक्स के बहुवचन और व्याकरण

बहुवचन नियम भाषा के अनुसार बदलते हैं, इसलिए अंग्रेज़ी का सरल पैटर्न (1 बनाम बाकी) जल्दी टूट जाता है। कुछ भाषाओं में 0, 1, 2-4 के लिए अलग रूप होते हैं, और कुछ में पूरा वाक्य बदल जाता है। अगर आप UI में ही बहुवचन लॉजिक bake कर देते हैं तो आप कॉपी डुप्लिकेट करेंगे और किनारे केस मिस होंगे।

सुरक्षित तरीका यह है कि एक फ़्लेक्सिबल संदेश रखें और i18n पर पर छोड़ दें कि सही रूप चुने। ICU-स्टाइल मैसेज इसके लिए बनाए गए हैं। वे व्याकरण के फैसलों को अनुवाद में रखते हैं, न कि आपके कंपोनेंट्स में।

यहाँ एक छोटा उदाहरण है जो अक्सर भूल जाता है:

itemsCount = "{count, plural, =0 {No items} one {# item} other {# items}}"

यह एक ही की 0, 1 और बाकी सभी कवर करती है। अनुवादक इसे अपनी भाषा के बहुवचन रूपों के साथ बदल सकते हैं बिना आपके कोड को छुए।

जब आपको लिंग (gender) या भूमिका-आधारित शब्दावली चाहिए, तो अलग कीज़ जैसे welcome_male और welcome_female बनाने से बचें जब तक कि प्रोडक्ट वाकई इसकी माँग न करे। select का उपयोग करें ताकि वाक्य एक ही इकाई बना रहे:

welcomeUser = "{gender, select, female {Welcome, Ms. {name}} male {Welcome, Mr. {name}} other {Welcome, {name}}}"

व्याकरणिक मामलों में फँसने से बचने के लिए वाक्यों को यथासंभव पूरा रखें। फ्रैगमेंट्स जोड़ने जैसे "{count} " + t('items') न करें क्योंकि कई भाषाओं में शब्दों का क्रम बदलता है। एक ही संदेश में संख्या, संज्ञा और आसपास के शब्द रखें।

Chat-निर्मित ऐप्स के लिए एक सरल नियम जो अच्छी तरह काम करता है: अगर वाक्य में संख्या, व्यक्ति या स्थिति है, तो शुरू से ही ICU बनाएं। थोड़ा अधिक upfront खर्च आता है पर बाद में यह अनुवाद कर्ज बचाता है।

वेब और मोबाइल अनुवादों को सुसंगत रखना

अगर आपका React वेब और Flutter मोबाइल अपनी-अपनी ट्रांसलेशन फ़ाइलें रखते हैं, तो वे अलग हो जाएँगी। वही बटन अलग शब्दों के साथ दिखेगा, एक की वेब पर एक अर्थ और मोबाइल पर दूसरा अर्थ देगी, और सपोर्ट टिकट्स में दिखाई देगा “ऐप X कह रहा है पर वेबसाइट Y कहती है”।

सबसे सरल और महत्वपूर्ण फिक्स: एक सोर्स-ऑफ-ट्रुथ फ़ॉर्मेट चुनें और उसे कोड की तरह ट्रीट करें। अधिकांश टीमों के लिए इसका मतलब है एक साझा सेट ऑफ़ locale फ़ाइलें (जैसे JSON उपयोग करते हुए ICU-स्टाइल मैसेज) जिनको वेब और मोबाइल दोनों consume करें। जब आप चैट और जेनरेटर से ऐप बनाते हैं यह और भी ज़रूरी होता है क्योंकि गलती से दो जगह नई टेक्स्ट बनेगी।

एक साझा सोर्स-ऑफ-ट्रुथ

एक व्यावहारिक सेटअप एक छोटा "i18n पैकेज" या फ़ोल्डर है जिसमें:

• हर भाषा के लिए locale फ़ाइलें (सब जगह एक ही कीज़)
• मैसेज फ़ॉर्मैट नियम (plural और placeholders के लिए ICU)
• एक छोटा README जो बताता है कैसे कीज़ जोड़ें

React और Flutter फिर consumer बनते हैं। उन्हें स्थानीय रूप से नई कीज़ नहीं बनानी चाहिए। Koder.ai-स्टाइल वर्कफ़्लो में, आप दोनों क्लाइंट्स को उसी की सेट से जेनरेट कर सकते हैं और बदलावों को किसी अन्य कोड परिवर्तन की तरह review में रख सकते हैं।

बैकेंड संरेखन भी इसी कहानी का हिस्सा है। Errors, notifications और emails Go में हँथ से लिखे अंग्रेज़ी वाक्यों के रूप में नहीं होने चाहिए। इसके बजाय, स्थिर error codes लौटाएँ (जैसे auth.invalid_password) साथ में सुरक्षित पैरामीटर्स। फिर क्लाइंट्स कोड्स को ट्रांसलेटेड टेक्स्ट में मैप करें। सर्वर-साइड मेल्स के लिए, सर्वर वही कीज़ और locale फ़ाइलों का उपयोग करके टेम्पलेट रेंडर कर सकता है।

नियम जो आपको सिंक में रखें

एक छोटा नियम-पुस्तक बनाइए और कोड रिव्यू में लागू रखिए:

• नई UI टेक्स्ट के लिए पहले साझा locale फ़ाइलों में एक नई की चाहिए
• कीज़ में स्पष्ट namespace और intent होना चाहिए (स्क्रीन स्थितियों के बजाय)
• हर की के लिए प्लेसहोल्डर्स एक बार परिभाषित हों और हर जगह एक ही तरह उपयोग हों
• अगर दो वाक्य अर्थ में भिन्न हैं, तो वे कभी एक ही की साझा नहीं कर सकते
• अगर दो कीज़ का अर्थ एक जैसा है, तो एक को हटाएँ और एक ही चुनें

डुप्लिकेट कीज़ से बचने के लिए अनुवादकों और भविष्य के लिए एक "description" फ़ील्ड (या टिप्पणी फ़ाइल) जोड़ें। उदाहरण: billing.trial_days_left बताएं कि यह बैनर के रूप में दिखेगा या ईमेल में। वह एक वाक्य अक्सर “close enough” री-यूज़ रोक देता है जो अनुवाद कर्ज बनाता है।

यह सुसंगति chat-निर्मित ऐप्स के i18n आर्किटेक्चर की रीढ़ है: एक साझा शब्दावली, कई सरफेस और अगली भाषा शिप करते समय कोई आश्चर्य नहीं।

किसी वास्तविक प्रोजेक्ट पर स्टेप-बाय-स्टेप सेटअप

एक अच्छा i18n आर्किटेक्चर सरल से शुरू होता है: एक सेट मैसेज कीज़, एक सोर्स-ऑफ-ट्रुथ कॉपी के लिए, और वेब व मोबाइल दोनों पर एक ही नियम। अगर आप तेज़ बनाते हैं (उदाहरण के लिए Koder.ai के साथ), यह संरचना तेज़ी बनाए रखती है बिना अनुवाद कर्ज उत्पन्न किए।

एक व्यावहारिक सेटअप (वेब + मोबाइल)

अपनी लोकैल्स जल्दी चुनें और तय करें कि जब अनुवाद गायब हो तो क्या होगा। एक सामान्य विकल्प: उपयोगकर्ता की पसंदीदा भाषा दिखाएँ अगर उपलब्ध हो, नहीं तो fallback अंग्रेज़ी दिखाएँ, और missing keys को लॉग करें ताकि आप अगली रिलीज़ से पहले उन्हें ठीक कर सकें।

फिर इसे लागू करें:

• लोकैल्स और fallback परिभाषित करें: समर्थित भाषाओं, डिफ़ॉल्ट लोकैल और स्पष्ट fallback आदेश का निर्णय लें। तय करें कि लोकैल कैसे डिटेक्ट किया जाएगा (ब्राउज़र/ऐप सेटिंग, उपयोगकर्ता प्रोफ़ाइल)।
• एक अनुवाद फ़ंक्शन और की कन्वेंशन बनाएं: स्थिर, अर्थ-आधारित कीज़ उपयोग करें (पूरे वाक्य नहीं)। उदाहरण: billing.plan_name.pro या auth.error.invalid_password। एक ही की हर जगह रखें।
• React और Flutter में वायर करें: React में अपने ऐप को i18n provider से wrap करें और कंपोनेंट्स में t("key") उपयोग करें। Flutter में भी लोकलाइज़ेशन wrapper और वही की-आधारित लुकअप widgets में कॉल करें। लक्ष्य वही कीज़ हैं, न कि वही लाइब्रेरी।
• शुरू से ही वेरिएबल्स और प्लुरल नियम सपोर्ट करें: ICU-स्टाइल मैसेज उपयोग करें जैसे "{count, plural, one {# file} other {# files}}" और "Hello, {name}"। इससे if (count === 1) जैसे हैक्स स्क्रीन-स्क्रीन पर नहीं फैलते।
• एक हल्का कॉपी समीक्षा स्टेप जोड़ें: शिपिंग से पहले नई/बदली हुई स्ट्रिंग्स की समीक्षा करें: की नामकरण जांचें, हार्ड-कोडेड UI कॉपी हटाएँ, प्लेसहोल्डर्स का मिलान करें, और सुनिश्चित करें कि वेब व मोबाइल दोनों ने बदलाव उठाया है।

अंत में, एक ऐसी भाषा टेस्ट करें जिसका शब्द लंबा होता है (जर्मन क्लासिक है) और एक जिसे विराम चिह्न अलग हैं। यह जल्दी बटन ओवरफ़्लो, खराब हेडिंग ब्रेकिंग और अंग्रेज़ी शब्द लंबाई पर निर्भर लेआउट की दिक्कतें दिखा देगा।

अगर आप अनुवादों को एक साझा फ़ोल्डर (या जेनरेटेड पैकेज) में रखते हैं और कॉपी बदलावों को कोड बदलाव की तरह ट्रीट करते हैं, तो वेब और मोबाइल ऐप्स तेज़ी से बने हुए भी सुसंगत रहेंगे।

डायनामिक कंटेंट: तारीखें, संख्याएँ और उपयोगकर्ता टेक्स्ट

अनुवादित UI स्ट्रिंग्स समस्या का आधा हिस्सा हैं। अधिकांश ऐप बदलने वाले मान भी दिखाते हैं जैसे तारीखें, कीमतें, काउंट और नाम। अगर आप उन मानों को साधारण टेक्स्ट मानकर फॉर्मेट करेंगे, तो आपको अजीब फ़ॉर्मैट, गलत टाइमज़ोन और कई भाषाओं में "अजीब" लगने वाले वाक्य मिलेंगे।

शुरू में ही संख्याओं, मुद्रा और तारीखों को लोकैल नियमों से फ़ॉर्मैट करें, न कि कस्टम कोड से। फ्रांस के उपयोगकर्ता को "1 234,50 €" अपेक्षित होगा जबकि US उपयोगकर्ता को "$1,234.50"। यही तारीखों पर भी लागू होता है: "03/04/2026" ambiguous है, पर लोकैल फ़ॉर्मैटिंग स्पष्ट बनाती है।

टाइमज़ोन्स अगला जाल हैं। सर्वर सामान्यतः timestamps को न्यूट्रल रूप में (आम तौर पर UTC) स्टोर करें, पर उपयोगकर्ता अपनी ज़ोन में देखना चाहते हैं। उदाहरण: 23:30 UTC पर बना ऑर्डर टोकियो में किसी के लिए "कल" हो सकता है। हर स्क्रीन के लिए एक नियम तय करें: व्यक्तिगत इवेंट्स के लिए उपयोगकर्ता-लोकल समय दिखाएँ, और स्टोर पिकअप जैसी चीज़ों के लिए फिक्स बिज़नेस टाइमज़ोन दिखाएँ (और उसे स्पष्ट रूप से लेबल करें)।

अनुवादित फ्रैगमेंट्स को जोड़कर वाक्य न बनाइए। यह व्याकरण तोड़ देता है क्योंकि शब्दों का क्रम भाषाओं में बदलता है। इसके बजाय:

“{count} ” + t("items") + " " + t("in_cart")

की जगह एक संदेश का उपयोग करें जैसे: “{count} items in your cart”。 अनुवादक फिर सुरक्षित रूप से शब्दों का क्रम बदल सकते हैं।

राइट-तो-लेफ्ट (RTL) भाषाएँ

RTL सिर्फ़ टेक्स्ट दिशा नहीं है। लेआउट फ्लो पलटता है, कुछ आइकॉन को मिरर करना पड़ता है (जैसे बैक एरो), और मिक्स्ड कंटेंट (अरेबिक के साथ अंग्रेज़ी प्रोडक्ट कोड) आश्चर्यजनक ऑर्डर में दिख सकता है। असली स्क्रीन पर टेस्ट करें, सिर्फ़ एक लेबल नहीं, और सुनिश्चित करें कि UI कंपोनेंट्स दिशा परिवर्तन को सपोर्ट करते हों।

उपयोगकर्ता-जनित कंटेंट

कभी भी उपयोगकर्ता द्वारा लिखा हुआ अनुवाद न करें (नाम, पते, सपोर्ट टिकट, चैट संदेश)। आप इसके आस-पास के लेबल अनुवाद कर सकते हैं, और आस-पास के मेटाडेटा (तारीख, संख्या) को फ़ॉर्मैट कर सकते हैं, पर कंटेंट जैसा है वैसा ही रहना चाहिए। अगर आप बाद में ऑटो-ट्रांसलेशन जोड़ते हैं, तो वह एक स्पष्ट फीचर होना चाहिए जिसमें "original/translated" टॉगल हो।

एक व्यावहारिक उदाहरण: एक Koder.ai-निर्मित ऐप दिखा सकता है “{name} renewed on {date} for {amount}”。 इसे एक ही संदेश रखें, {date} और {amount} को लोकैल के अनुसार फ़ॉर्मैट करें, और उपयोगकर्ता के टाइम ज़ोन में दिखाएँ। यह एक पैटर्न बहुत सा अनुवाद कर्ज रोकता है।

त्वरित नियम जो आमतौर पर बग रोकते हैं:

• timestamps UTC में स्टोर करें, दर्शक की लोकैल और टाइमज़ोन के अनुसार फ़ॉर्मैट करें।
• पूरा वाक्य बनाते समय प्लेसहोल्डर्स का उपयोग करें, फ्रैगमेंट्स जोड़ कर नहीं।
• मुद्रा लोकैल नियमों और सही करंसी कोड के साथ फ़ॉर्मैट करें।
• कम से कम एक RTL लोकैल असली स्क्रीन पर टेस्ट करें।
• उपयोगकर्ता-जनित टेक्स्ट डिफ़ॉल्ट रूप से अनुवादित न करें।

आम गलतियाँ जो अनुवाद कर्ज बनाती हैं

अनुवाद कर्ज अक्सर "सिर्फ़ एक त्वरित स्ट्रिंग" से शुरू होता है और बाद में हफ्तों के क्लीनअप में बदल जाता है। Chat-निर्मित प्रोजेक्ट्स में यह और तेज़ी से हो सकता है क्योंकि UI टेक्स्ट कंपोनेंट्स, फॉर्म्स और बैकएण्ड संदेशों में जेनरेट हो जाता है।

जो समस्याएँ बाद में चोट करती हैं

सबसे महँगी समस्याएँ वे होती हैं जो ऐप भर में फैलें और ढूंढना मुश्किल हो जाएँ।

• UI कंपोनेंट्स के अंदर कॉपी को हार्ड-कोड करना, जिसमें प्लेसहोल्डर्स, खाली अवस्थाएँ और बटन लेबल शामिल हैं। आप इसकी ऑडिट नहीं कर सकते और री-यूज़ नहीं कर सकते, और छोटे शब्द बदलने के लिए कोड एडिट्स चाहिए होंगे।
• बैकएंड वैलिडेशन और API एरर को अंग्रेज़ी वाक्य के रूप में लौटने देना। UI मिश्रित भाषाएँ दिखाएगा और आप एरर को विश्वसनीय रूप से ट्रांसलेटेड मैसेज से मैप नहीं कर पाएंगे।
• अनुवाद की के रूप में पूरा अंग्रेज़ी वाक्य उपयोग करना। यह सुविधाजनक लगता है जब तक कि कॉपी न बदले; तब कीज़ churn होती हैं, पुराने कीज़ रह जाते हैं, और आप ट्रांसलेशन मेमोरी खो देते हैं।
• वेब और मोबाइल के बीच कीज़ कॉपी करना और उन्हें अलग से एडिट करना। समय के साथ "एक जैसे" स्क्रीन अलग हो जाते हैं और उपयोगकर्ता असंगत शब्दावली नोटिस करते हैं।
• पहली गैर-अंग्रेज़ी भाषा जोड़ने तक बहुवचन नियम टाल देना। तब आप ढेरों "1 items" बग और अजीब व्याकरण पाते हैं जिन्हें सरल if-statements से ठीक नहीं किया जा सकता।

एक त्वरित वास्तविक उदाहरण

कल्पना कीजिए एक React वेब ऐप और Flutter मोबाइल ऐप दोनों एक बिलिंग बैनर दिखाते हैं: “You have 1 free credit left”。 किसी ने वेब टेक्स्ट को बदलकर “You have one credit remaining” कर दिया और की भी वही रख दी। मोबाइल अभी भी पुरानी की उपयोग कर रहा है। अब आपके पास एक अवधारणा के लिए दो कीज़ हैं और अनुवादक दोनों देखते हैं।

एक बेहतर पैटर्न है स्थिर कीज़ (जैसे billing.creditsRemaining) और ICU के साथ बहुवचन ताकि व्याकरण हर भाषा में सही रहे। अगर आप Koder.ai जैसे टूल का इस्तेमाल कर रहे हैं, तो एक नियम जल्दी जोड़ें: चैट में उत्पन्न होने वाला कोई भी यूज़र-फेसिंग टेक्स्ट translation फ़ाइलों में ही जाए, न कि कंपोनेंट्स या सर्वर एरर के अंदर। यह छोटी आदत आपके chat-निर्मित ऐप्स के i18n आर्किटेक्चर को बड़े प्रोजेक्ट में सुरक्षित रखती है।

त्वरित चेकलिस्ट, एक यथार्थ उदाहरण और अगले कदम

जब अंतरराष्ट्रीयकरण गड़बड़ लगे, आमतौर पर मूल बातें लिखी ही नहीं गई होतीं। एक छोटी चेकलिस्ट और एक ठोस उदाहरण आपकी टीम (और भविष्य के आप) को अनुवाद कर्ज से बाहर रख सकते हैं।

यहाँ हर नई स्क्रीन पर चलाने के लिए एक त्वरित चेकलिस्ट है:

• स्थिर कीज़: एक अर्थ के लिए एक की, वर्डिंग के लिए नहीं (उदाहरण: billing.invoice.paidStatus, न कि billing.greenLabel)।
• Fallbacks: एक स्पष्ट डिफ़ॉल्ट भाषा परिभाषित करें, और तय करें कि जब कोई की गायब हो तो क्या होगा (fallback टेक्स्ट दिखाएँ, लॉग करें, या रिलीज़ ब्लॉक करें)।
• बहुवचन नियम: गिनती के लिए ICU-स्टाइल मैसेज का उपयोग करें (0, 1, many) स्ट्रिंग हैक्स के बजाय।
• फ़ॉर्मैटिंग: तारीखें, पैसे और संख्याएँ लोकैल के अनुसार फ़ॉर्मैट करें (और मुद्रा को भाषा से अलग रखें)।
• RTL चेक: कम से कम एक राइट-टू-लेफ्ट भाषा जल्दी टेस्ट करें ताकि लेआउट की समस्याएँ बड़े स्क्रीन-सेट होने से पहले दिख जाएँ।

एक सरल उदाहरण: आप अंग्रेज़ी, स्पैनिश और जापानी में बिलिंग स्क्रीन लॉन्च कर रहे हैं। UI में है: “Invoice”, “Paid”, “Due in 3 days”, “1 payment method” / “2 payment methods”, और एक कुल जैसे “$1,234.50”。 अगर आपने यह i18n आर्किटेक्चर अपनाया है, तो आप कीज़ एक बार परिभाषित करते हैं (वेब व मोबाइल दोनों साझा), और हर भाषा केवल वैल्यू भरती है। “Due in {days} days” ICU मैसेज बन जाता है, और पैसे का फ़ॉर्मैट लोकैल-सेंसिटिव फ़ॉर्मैटर से आता है, न कि हार्ड-कोडेड कॉमा से।

भाषा समर्थन को फीचर-बाय-फीचर रोलआउट करें, न कि बड़े रीराइट के रूप में:

1. एक हाई-ट्रैफ़िक फ्लो से शुरू करें (billing, onboarding, या checkout)।
2. हार्ड-कोडेड UI कॉपी को translation फ़ाइलों में मूव करें और कीज़ से रिप्लेस करें।
3. उसी फ्लो के लिए प्लुरल मैसेज और फ़ॉर्मैटिंग जोड़ें।
4. अगले फीचर पर तभी बढ़ें जब missing keys लगभग शून्य हों।

दो चीज़ों को दस्तावेज़ करें ताकि नई फीचर्स सुसंगत रहें: आपके की नामकरण के नियम (उदाहरणों सहित) और स्ट्रिंग्स के लिए "definition of done" (कोई हार्ड-कोडेड कॉपी नहीं, बहुवचन के लिए ICU, तारीख/नंबर के लिए फ़ॉर्मैटिंग, साझा कैटलॉग में जोड़ा गया)।

अगले कदम: अगर आप Koder.ai में बना रहे हैं, तो Planning Mode का उपयोग करें ताकि आप स्क्रीन और कीज़ को UI जेनरेट करने से पहले परिभाषित कर सकें। फिर snapshots और rollback का उपयोग करें ताकि आप वेब और मोबाइल पर कॉपी और अनुवादों में सुरक्षित रूप से iterate कर सकें बिना जोखिम वाले रिलीज़ के।