Chat-निर्मित ऐप्स के लिए अंतरराष्ट्रीयकरण आर्किटेक्चर: स्थिर स्ट्रिंग कीज़, बहुवचन नियम और एक समान अनुवाद वर्कफ़्लो परिभाषित करें ताकि वेब और मोबाइल पर अनुवाद一致 रहें।

सबसे पहले टूटने वाली चीज़ कोड नहीं होती। वो शब्द होते हैं।
Chat-निर्मित ऐप अक्सर तेज प्रोटोटाइप के रूप में शुरू होते हैं: आप टाइप करते हैं "एक बटन जोड़ें जिस पर "Save" लिखा हो", UI दिखता है, और आप आगे बढ़ जाते हैं। कुछ हफ्ते बाद, आप स्पैनिश और जर्मन चाहते हैं और पाते हैं कि वे "अस्थायी" लेबल स्क्रीन, कंपोनेंट्स, ईमेल और एरर संदेशों में बिखरे हुए हैं।
कॉपी बदलना कोड की तुलना में अधिक बार होता है। प्रोडक्ट नाम बदले जाते हैं, कानूनी टेक्स्ट बदलता है, ऑनबोर्डिंग फिर से लिखा जाता है, और सपोर्ट क्लियर एरर संदेश मांगता है। अगर टेक्स्ट सीधे UI कोड में रहता है, तो हर छोटा शब्द बदलना खतरनाक रिलीज़ बन जाता है, और आप उन जगहों को मिस कर देंगे जहाँ वही विचार अलग तरीक़े से लिखा गया है।
यहाँ शुरुआती लक्षण हैं जो बताते हैं कि आप अनुवाद कर्ज (translation debt) बना रहे हैं:
एक यथार्थ उदाहरण: आप Koder.ai में एक साधारण CRM बनाते हैं। वेब ऐप पर लिखा है “Deal stage”, मोबाइल ऐप पर है “Pipeline step”, और एक एरर टोस्ट कहता है “Invalid status”。अगर तीनों का अनुवाद भी किया गया हो, उपयोगकर्ता ऐप को असंगत महसूस करेंगे क्योंकि अवधारणाएँ मेल नहीं खातीं।
"सुसंगत" का मतलब हर जगह समान अक्षर नहीं होता। इसका मतलब है:
एक बार आप टेक्स्ट को सजावट नहीं बल्कि प्रोडक्ट डेटा मानने लगे, भाषाएँ जोड़ना घमासान नहीं रह जाता बल्कि निर्माण का नियमित हिस्सा बन जाता है।
Internationalization (i18n) वह काम है जिससे एक ऐप बिना री-राइट के कई भाषाओं को सपोर्ट कर सके। Localization (l10n) किसी खास भाषा और क्षेत्र के लिए असल कंटेंट है — जैसे फ्रेंच (कनाडा) के लिए सही शब्द, तारीख़ फ़ॉर्मेट और टोन।
एक सरल लक्ष्य: हर यूज़र-नेज़र टेक्स्ट एक स्थिर की (key) से चयनित हो, न कि UI कोड में सीधे टाइप किया गया हो। अगर आप कोई वाक्य बिना किसी React component या Flutter widget खोले बदल सकते हैं, तो आप सही दिशा में हैं। यह chat-निर्मित ऐप्स के लिए i18n आर्किटेक्चर का मूल है, जहाँ चैट से जेनरेट की गई हार्ड-कोडेड कॉपी आसानी से शिप हो सकती है।
यूज़र-फेसिंग टेक्स्ट अधिकांश टीमों की अपेक्षा से व्यापक होता है। इसमें बटन, लेबल, वैलिडेशन एरर, खाली अवस्थाएँ, ऑनबोर्डिंग टिप्स, पुश नोटिफिकेशन्स, ईमेल, PDF एक्सपोर्ट और कोई भी संदेश शामिल है जो उपयोगकर्ता देख या सुन सकता है। आमतौर पर इसमें इंटरनल लॉग्स, डेटाबेस कॉलम नाम, एनालिटिक्स इवेंट IDs, फीचर फ़्लैग्स या केवल एडमिन-डिबग आउटपुट शामिल नहीं होते।
अनुवाद कहाँ रहने चाहिए? व्यवहार में, यह अक्सर frontend और backend दोनों में रहता है, पर एक स्पष्ट सीमा के साथ।
गलती यह है कि जिम्मेदारियों को मिलाया जाए। अगर 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.titleauth.login.emailLabelbilling.checkout.payButtonnav.settingserrors.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 आर्किटेक्चर को स्थिर रखता है भले ही फीचर्स इधर-उधर हों।
यदि आप वेब और मोबाइल दोनों भेजते हैं, तो आप एक साझा कीट-कैटलॉग चाहते हैं, साथ ही फीचर टीमों के लिए अलग काम करने की जगह। एक व्यावहारिक लेआउट:
प्लैटफ़ॉर्म के बावजूद कीज़ एक समान रखें (React वेब पर हो या Flutter मोबाइल पर)। अगर आप Koder.ai जैसी प्लेटफ़ॉर्म से दोनों ऐप जेनरेट करते हैं, तो स्रोत कोड का एक्सपोर्ट आसान होता है जब दोनों प्रोजेक्ट एक ही की नाम और एक ही संदेश फ़ॉर्मेट की ओर पॉइंट करें।
अनुवाद समय के साथ बदलते हैं। बदलावों को प्रोडक्ट बदलाव की तरह ट्रीट करें: छोटे, समीक्षा किए हुए और ट्रैकेबल। एक अच्छी समीक्षा अर्थ और रीयूज़ पर केंद्रित होती है, सिर्फ़ वर्तनी पर नहीं।
टीमों के बीच कीज़ के बहाव को रोकने के लिए कीज़ फीचर्स के मालिक हों (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 पैकेज" या फ़ोल्डर है जिसमें:
React और Flutter फिर consumer बनते हैं। उन्हें स्थानीय रूप से नई कीज़ नहीं बनानी चाहिए। Koder.ai-स्टाइल वर्कफ़्लो में, आप दोनों क्लाइंट्स को उसी की सेट से जेनरेट कर सकते हैं और बदलावों को किसी अन्य कोड परिवर्तन की तरह review में रख सकते हैं।
बैकेंड संरेखन भी इसी कहानी का हिस्सा है। Errors, notifications और emails Go में हँथ से लिखे अंग्रेज़ी वाक्यों के रूप में नहीं होने चाहिए। इसके बजाय, स्थिर error codes लौटाएँ (जैसे auth.invalid_password) साथ में सुरक्षित पैरामीटर्स। फिर क्लाइंट्स कोड्स को ट्रांसलेटेड टेक्स्ट में मैप करें। सर्वर-साइड मेल्स के लिए, सर्वर वही कीज़ और locale फ़ाइलों का उपयोग करके टेम्पलेट रेंडर कर सकता है।
एक छोटा नियम-पुस्तक बनाइए और कोड रिव्यू में लागू रखिए:
डुप्लिकेट कीज़ से बचने के लिए अनुवादकों और भविष्य के लिए एक "description" फ़ील्ड (या टिप्पणी फ़ाइल) जोड़ें। उदाहरण: billing.trial_days_left बताएं कि यह बैनर के रूप में दिखेगा या ईमेल में। वह एक वाक्य अक्सर “close enough” री-यूज़ रोक देता है जो अनुवाद कर्ज बनाता है।
यह सुसंगति chat-निर्मित ऐप्स के i18n आर्किटेक्चर की रीढ़ है: एक साझा शब्दावली, कई सरफेस और अगली भाषा शिप करते समय कोई आश्चर्य नहीं।
एक अच्छा i18n आर्किटेक्चर सरल से शुरू होता है: एक सेट मैसेज कीज़, एक सोर्स-ऑफ-ट्रुथ कॉपी के लिए, और वेब व मोबाइल दोनों पर एक ही नियम। अगर आप तेज़ बनाते हैं (उदाहरण के लिए Koder.ai के साथ), यह संरचना तेज़ी बनाए रखती है बिना अनुवाद कर्ज उत्पन्न किए।
अपनी लोकैल्स जल्दी चुनें और तय करें कि जब अनुवाद गायब हो तो क्या होगा। एक सामान्य विकल्प: उपयोगकर्ता की पसंदीदा भाषा दिखाएँ अगर उपलब्ध हो, नहीं तो fallback अंग्रेज़ी दिखाएँ, और missing keys को लॉग करें ताकि आप अगली रिलीज़ से पहले उन्हें ठीक कर सकें।
फिर इसे लागू करें:
billing.plan_name.pro या auth.error.invalid_password। एक ही की हर जगह रखें।t("key") उपयोग करें। Flutter में भी लोकलाइज़ेशन wrapper और वही की-आधारित लुकअप widgets में कॉल करें। लक्ष्य वही कीज़ हैं, न कि वही लाइब्रेरी।if (count === 1) जैसे हैक्स स्क्रीन-स्क्रीन पर नहीं फैलते।अंत में, एक ऐसी भाषा टेस्ट करें जिसका शब्द लंबा होता है (जर्मन क्लासिक है) और एक जिसे विराम चिह्न अलग हैं। यह जल्दी बटन ओवरफ़्लो, खराब हेडिंग ब्रेकिंग और अंग्रेज़ी शब्द लंबाई पर निर्भर लेआउट की दिक्कतें दिखा देगा।
अगर आप अनुवादों को एक साझा फ़ोल्डर (या जेनरेटेड पैकेज) में रखते हैं और कॉपी बदलावों को कोड बदलाव की तरह ट्रीट करते हैं, तो वेब और मोबाइल ऐप्स तेज़ी से बने हुए भी सुसंगत रहेंगे।
अनुवादित 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 सिर्फ़ टेक्स्ट दिशा नहीं है। लेआउट फ्लो पलटता है, कुछ आइकॉन को मिरर करना पड़ता है (जैसे बैक एरो), और मिक्स्ड कंटेंट (अरेबिक के साथ अंग्रेज़ी प्रोडक्ट कोड) आश्चर्यजनक ऑर्डर में दिख सकता है। असली स्क्रीन पर टेस्ट करें, सिर्फ़ एक लेबल नहीं, और सुनिश्चित करें कि UI कंपोनेंट्स दिशा परिवर्तन को सपोर्ट करते हों।
कभी भी उपयोगकर्ता द्वारा लिखा हुआ अनुवाद न करें (नाम, पते, सपोर्ट टिकट, चैट संदेश)। आप इसके आस-पास के लेबल अनुवाद कर सकते हैं, और आस-पास के मेटाडेटा (तारीख, संख्या) को फ़ॉर्मैट कर सकते हैं, पर कंटेंट जैसा है वैसा ही रहना चाहिए। अगर आप बाद में ऑटो-ट्रांसलेशन जोड़ते हैं, तो वह एक स्पष्ट फीचर होना चाहिए जिसमें "original/translated" टॉगल हो।
एक व्यावहारिक उदाहरण: एक Koder.ai-निर्मित ऐप दिखा सकता है “{name} renewed on {date} for {amount}”。 इसे एक ही संदेश रखें, {date} और {amount} को लोकैल के अनुसार फ़ॉर्मैट करें, और उपयोगकर्ता के टाइम ज़ोन में दिखाएँ। यह एक पैटर्न बहुत सा अनुवाद कर्ज रोकता है।
त्वरित नियम जो आमतौर पर बग रोकते हैं:
अनुवाद कर्ज अक्सर "सिर्फ़ एक त्वरित स्ट्रिंग" से शुरू होता है और बाद में हफ्तों के क्लीनअप में बदल जाता है। Chat-निर्मित प्रोजेक्ट्स में यह और तेज़ी से हो सकता है क्योंकि UI टेक्स्ट कंपोनेंट्स, फॉर्म्स और बैकएण्ड संदेशों में जेनरेट हो जाता है।
सबसे महँगी समस्याएँ वे होती हैं जो ऐप भर में फैलें और ढूंढना मुश्किल हो जाएँ।
कल्पना कीजिए एक 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)।एक सरल उदाहरण: आप अंग्रेज़ी, स्पैनिश और जापानी में बिलिंग स्क्रीन लॉन्च कर रहे हैं। UI में है: “Invoice”, “Paid”, “Due in 3 days”, “1 payment method” / “2 payment methods”, और एक कुल जैसे “$1,234.50”。 अगर आपने यह i18n आर्किटेक्चर अपनाया है, तो आप कीज़ एक बार परिभाषित करते हैं (वेब व मोबाइल दोनों साझा), और हर भाषा केवल वैल्यू भरती है। “Due in {days} days” ICU मैसेज बन जाता है, और पैसे का फ़ॉर्मैट लोकैल-सेंसिटिव फ़ॉर्मैटर से आता है, न कि हार्ड-कोडेड कॉमा से।
भाषा समर्थन को फीचर-बाय-फीचर रोलआउट करें, न कि बड़े रीराइट के रूप में:
दो चीज़ों को दस्तावेज़ करें ताकि नई फीचर्स सुसंगत रहें: आपके की नामकरण के नियम (उदाहरणों सहित) और स्ट्रिंग्स के लिए "definition of done" (कोई हार्ड-कोडेड कॉपी नहीं, बहुवचन के लिए ICU, तारीख/नंबर के लिए फ़ॉर्मैटिंग, साझा कैटलॉग में जोड़ा गया)।
अगले कदम: अगर आप Koder.ai में बना रहे हैं, तो Planning Mode का उपयोग करें ताकि आप स्क्रीन और कीज़ को UI जेनरेट करने से पहले परिभाषित कर सकें। फिर snapshots और rollback का उपयोग करें ताकि आप वेब और मोबाइल पर कॉपी और अनुवादों में सुरक्षित रूप से iterate कर सकें बिना जोखिम वाले रिलीज़ के।