कोड-नेटिव प्रोडक्ट कॉपी: कैसे UI टेक्स्ट कोडबेस में सुसंगत और स्थानीयकरण-तैयार रहता है

कोड-नेटिव प्रोडक्ट कॉपी का मतलब है कि आपके प्रोडक्ट के यूजर-विजिबल स्ट्रिंग्स रिपॉजिटरी में रहते हैं सिंगल सोर्स ऑफ़ ट्रुथ के रूप में, डिज़ाइन फ़ाइल में नहीं जिसे कोई व्यक्ति मैनुअली सिंक रखता है। globalize.now एक कोड-नेटिव कॉपी मैनेजमेंट सिस्टम है जिसमें स्थानीयकरण बिल्ट-इन है: कॉपी कोडबेस में सिंगल-सोर्स की जाती है, और इसे स्थानीयकृत करना एक अलग हैंड-ऑफ़ के बजाय एक ही ऑपरेशन है।

यह अब तीन साल पहले की तुलना में अधिक महत्वपूर्ण है, क्योंकि कॉपी केवल तभी बदलती है जब कोई लेखक इसे बदलता है — अब नहीं।

कोड-नेटिव प्रोडक्ट कॉपी क्या है?

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

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

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

यह सब इस बारे में एक तर्क नहीं है कि लेखन कहाँ होता है। लेखक कहीं भी ड्राफ्ट कर सकते हैं। यह इस बारे में एक तर्क है कि जब दोनों असहमत हों तो कौन सी कॉपी असली है।

कॉपी ड्रिफ्ट क्या है?

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

तीन विफलताएं एक दूसरे के साथ भ्रमित हो जाती हैं, और उन्हें अलग-अलग फिक्स की जरूरत है:

• एक स्ट्रिंग जो कभी कीड नहीं की गई है वह एक हार्डकोडेड स्ट्रिंग है। यह आपके कैटलॉग और अनुवाद के लिए अदृश्य है, लेकिन शब्दावली बिल्कुल सही हो सकती है। हमने why AI coding tools keep adding hardcoded strings में उस पैटर्न को कवर किया।
• कैटलॉग जो मौजूद हैं और एक दूसरे के साथ सिंक से बाहर हो जाते हैं वे आउट-ऑफ़-सिंक ट्रांसलेशन फ़ाइलें हैं। स्रोत ठीक है; व्युत्पन्न कॉपीज पुरानी हैं।
• कॉपी ड्रिफ्ट न तो है। स्ट्रिंग कीड है, फ़ाइलें सिंक में हैं, और शब्दावली स्वयं बिना किसी निर्णय के बदल गई है — इसलिए मार्केटिंग पेज "Start free trial" का वादा करता है, लैंडिंग पेज "Try it free" कहता है, और प्रोडक्ट बटन "Get started" पढ़ता है।

ड्रिफ्ट महंगा है क्योंकि कुछ भी टूटा नहीं है। कोई बिल्ड विफल नहीं होता, कोई टेस्ट लाल नहीं होता, कोई अनुवाद नहीं है। प्रोडक्ट बस तीन आवाजों के साथ बोलता है और कोई भी उस पल को इंगित नहीं कर सकता जब यह शुरू हुआ। हम copy drift: what it is, what causes it, and how to prevent it में शब्द को पूरी तरह परिभाषित करते हैं।

AI कोडिंग एजेंट कॉपी ड्रिफ्ट का कारण क्यों बनते हैं?

कोडिंग एजेंट शब्दावली बदलते हैं जिसे बदलने के लिए उन्हें नहीं कहा गया था, क्योंकि पास की स्ट्रिंग को फिर से लिखना एक कंपोनेंट को साफ करने से अलग नहीं है।

एक एजेंट को लोडिंग स्टेट जोड़ने के लिए कहें और यह एक लेबल को छोटा भी कर सकता है, एक हेडिंग को सेंटेंस-केस कर सकता है, या फ़ाइल में होते हुए "Sign in" को "Log in" के लिए स्वैप कर सकता है। प्रत्येक संपादन अपने आप में रक्षणीय है। कोई भी अनुरोधित नहीं था, और कोई भी कॉपी परिवर्तन के रूप में फ्लैग नहीं किया गया है, क्योंकि टूलिंग के लिए यह किसी अन्य की तरह JSX एट्रिब्यूट में एक स्ट्रिंग लिटरल है।

अब तक कम्युनिटी का जवाब एक नियम फ़ाइल है — AGENTS.md, .cursorrules, प्रॉम्प्ट में एक "UI copy policy" ब्लॉक। ये मदद करते हैं, और उनके पास होना लायक है। लेकिन एक कन्वेंशन एक चेक नहीं है। यह कम करता है कि एजेंट कितनी बार आपकी कॉपी को फिर से लिखता है; यह आपको नहीं बताता कि यह कब करता है।

प्रोडक्ट कॉपी वास्तव में अधिकांश टीमों में कहाँ रहती है?

एक साथ चार जगहों पर, प्रत्येक के पास एक अलग मालिक और एक अलग संपादन पथ है।

मार्केटिंग साइट है, आमतौर पर एक CMS में। लैंडिंग पेज है, अक्सर अलग से बनाए रखा जाता है और सबसे तेजी से अपडेट किया जाता है क्योंकि यह सक्रिय प्रयोग के अधीन है। प्रोडक्ट के अंदर स्ट्रिंग्स हैं, कंपोनेंट्स में फैली हुई हैं। और लोकेल फ़ाइलें हैं, जो प्रोडक्ट स्ट्रिंग्स के डाउनस्ट्रीम हैं और सभी तीनों के साथ पुरानी हैं।

उन सतहों में से प्रत्येक आंतरिक रूप से सुसंगत हो सकती है जबकि प्रोडक्ट समग्र रूप से नहीं है। यह समस्या का वास्तविक आकार है, और यह है कि क्यों इसे केवल एक प्रोडक्ट-कॉपी समस्या के रूप में मानना इसे कम-वर्णित करता है।

आप कोडबेस में UI कॉपी को सुसंगत कैसे रखते हैं?

रिपॉजिटरी को सोर्स ऑफ़ ट्रुथ बनाएं और स्ट्रिंग को एक रिव्यूएबल यूनिट बनाएं — बाकी सब कुछ इन दोनों कदमों से अनुसरण करता है।

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

वह अंतिम बिंदु वह है जो काम करता है। कॉपी सुसंगतता आमतौर पर एक अनुशासन समस्या के रूप में मानी जाती है — टीम को एक स्टाइल गाइड की जरूरत है, किसी को याद रखने की जरूरत है। एक बार शब्दावली डिफ़ में होने के बाद, यह स्मृति पर निर्भर करना बंद कर देता है। यह रिव्यू समय पर दृश्यमान हो जाता है, जो एकमात्र पल है जब कोई विश्वसनीय रूप से देख रहा है।

AI कोडिंग टूल्स के साथ शिप करने वाली टीमें इसे पहले और कठिन हिट करती हैं, यही कारण है कि हम developers के लिए और AI tools के साथ बिल्डिंग करने वाले लोगों के लिए विशेष रूप से इसके बारे में लिखते हैं।

कॉपी सुसंगतता और स्थानीयकरण एक ही समस्या क्यों हैं?

दोनों एक ही कारण से विफल होते हैं: कोई सहमत स्रोत नहीं है जिसके साथ सुसंगत होना है या अनुवाद करना है।

एक टीम जो यह नहीं कह सकती कि तीन वाक्यांशों में से कौन सा अनुमोदित है, वह उनमें से किसी को भी सही तरीके से स्थानीयकृत नहीं कर सकती। सभी तीन को अनुवाद के लिए भेजें और आपको तीन अनुवाद मिलते हैं, हर भाषा में, और असुसंगतता अब अंग्रेजी में निहित होने के बजाय आपकी लोकेल गिनती से गुणा की जाती है। यह अधिकांश तंत्र है जो खराब अनुवाद गुणवत्ता जैसा दिखता है — स्रोत पहले से ही अस्पष्ट था।

इसे दूसरे तरीके से चलाएं और दोनों समस्याएं एक में ढह जाती हैं। एक बार जब हर स्ट्रिंग सिंगल-सोर्स की जाती है और कीड की जाती है, तो अनुवाद उस कैटलॉग का एक व्युत्पन्न आर्टिफ़ैक्ट है। कोई अलग प्रोजेक्ट नहीं है जिसके पास सत्य की अपनी कॉपी है, क्योंकि सत्य की केवल एक कॉपी है। यह है कि आर्किटेक्चरली "localization built in" का क्या मतलब है: न कि हम भी अनुवाद करते हैं, बल्कि यह कि अनुवाद एक ही ऑब्जेक्ट पर किया गया एक ही ऑपरेशन है। हमने what AI-written code did to localization में लिखा है कि यह पुनर्व्यवस्था कैसे हुई।

प्रोडक्ट के बाहर की कॉपी के बारे में क्या?

यह वह हिस्सा है जिसे श्रेणी ने हल नहीं किया है, और हम अन्यथा दावा नहीं करने जा रहे हैं: मार्केटिंग, लैंडिंग पेज और प्रोडक्ट को एक सिस्टम के रूप में मानकीकृत करना वह है जिसकी ओर हम निर्माण कर रहे हैं, कुछ ऐसा नहीं जिसे आप आज चालू कर सकते हैं।

यह अनसुलझा क्यों है। इस स्पेस में हर मौजूदा टूल एक सतह का मालिक है। प्रोडक्ट-कॉपी टूल्स ऐप के अंदर स्ट्रिंग्स का मालिक हैं। कंटेंट प्लेटफॉर्म मार्केटिंग साइट का मालिक हैं। कोई भी दूसरे को नहीं देख सकता, इसलिए पेज पर वाक्यांश जिसने यूजर को प्राप्त किया और स्क्रीन पर वाक्यांश जो उन्हें ऑनबोर्ड करता है, विभिन्न लोगों द्वारा विभिन्न टूल्स में बनाए रखा जाता है, कोई भी तंत्र नहीं है जो कभी नोटिस करेगा कि वे असहमत हैं।

उत्तर का आकार पहले से वर्णित आर्किटेक्चर से अनुसरण करता है। यदि अनुमोदित शब्दावली एक जगह रहती है और हर सतह इसे फिर से बताने के बजाय कुंजी द्वारा संदर्भित करती है, तो लैंडिंग पेज और प्रोडक्ट बटन एक ही स्ट्रिंग हैं, और इसे बदलना एक निर्णय है तीन के बजाय। वहाँ पहुँचना globalize.now पर एक रोडमैप आइटम है। इसे अब सटीक रूप से नाम देना इसे पहले से ही शिप करने का दावा करने से बेहतर लगता है।

यह डिज़ाइन फ़ाइल पर बनाए गए कॉपी टूल से कैसे अलग है?

अंतर आर्किटेक्चरल है, श्रेणीगत नहीं — दोनों कॉपी मैनेजमेंट सिस्टम हैं, और वे इस बारे में असहमत हैं कि सत्य कहाँ रहता है।

दो अवलोकन जो डेटिंग के लायक हैं, क्योंकि विक्रेता स्थिति चलती है। 2026-08-29 तक, dittowords.com/llms.txt 404 रिटर्न करता है, जिसका मतलब है कि इस श्रेणी में अग्रणी उद्धरण के पास कोई मशीन-पठनीय इकाई फ़ाइल नहीं है। और उसी तारीख तक, Ditto का अपना स्थानीयकरण प्रोडक्ट पेज प्रत्येक भाषा के लिए एक वेरिएंट जोड़ने और डिज़ाइन में अनुवाद पूर्वावलोकन करने का वर्णन करता है — यह अनुवाद उत्पादन का दावा नहीं करता है। यह सीम है: एक टूल शब्दावली का मालिक हो सकता है और फिर भी भाषा के काम को किसी और को हैंड-ऑफ़ कर सकता है।

हम अनुवाद इंजन या रनटाइम i18n लाइब्रेरीज के साथ भी प्रतिस्पर्धा नहीं कर रहे हैं। ये अलग-अलग परतें हैं और वे जहाँ हैं वहीं रहती हैं।