पहले runtime i18n library जोड़ें, फिर Copilot द्वारा पहले से लिखी गई strings को convert करें और उसके बाद नई hardcoded strings को आने से रोकें। अधिकांश टीमें आख़िरी चरण में गलती करती हैं, क्योंकि repository instructions file उन सभी surfaces तक नहीं पहुँचती जहाँ से Copilot code लिखता है। Chat और coding agent इसे पढ़ते हैं, inline autocomplete नहीं। globalize.now AI-powered localization infrastructure है, जो codebase को एक बार convert करके वे keys और locale files तैयार करता है जिन्हें आपकी i18n library पढ़ती है।
Instructions file जोड़ने के बाद भी Copilot strings को hardcode क्यों करता रहता है?
क्योंकि instructions file सबसे तेज़ वाले workflow से जुड़ी ही नहीं है। VS Code के documentation में स्पष्ट लिखा है कि टाइप करते समय मिलने वाली inline suggestions में custom instructions को ध्यान में नहीं रखा जाता। और अधिकांश लोग अपने दिन का सबसे बड़ा हिस्सा इसी mode में बिताते हैं।
इसलिए आपने जो rule लिखा है, वह वास्तविक है और तब लागू होता है जब आप chat में Copilot से सवाल पूछते हैं या coding agent को कोई task देते हैं। लेकिन जब आप JSX tag टाइप करके greyed-out completion पर Tab दबाते हैं, तब यह लागू नहीं होता। दोनों तरीकों से committed code बनता है, लेकिन केवल एक ने आपका rule पढ़ा है।
Copilot के कौन-से surfaces आपकी instructions पढ़ते हैं?
तीन surfaces आपकी repository में code लिखते हैं, और तीनों का व्यवहार एक जैसा नहीं है।
| Surface | क्या instructions पढ़ता है? | Output कहाँ जाता है |
|---|---|---|
| Inline completions | नहीं | सीधे उस file में जिसे आप edit कर रहे हैं |
| Chat और agent mode | हाँ | Editor में आपके review के लिए edits |
| Coding agent | हाँ | आपके review के लिए एक draft pull request |
इस समस्या के लिए coding agent तीनों में सबसे सुविधाजनक है। आप उसे कोई issue assign करते हैं, वह background में काम करता है और draft pull request खोलता है, इसलिए उसका output ऐसी जगह आता है जहाँ reviewer पहले से देखता है। Inline completions बिना किसी gate के सीधे पहुँच जाती हैं।
Copilot project में i18n कैसे सेट अप करें?
सबसे पहले अपने framework के लिए उपयुक्त runtime library चुनें। Next.js App Router के लिए next-intl, किसी भी अन्य React app के लिए react-i18next और compile-time extraction तथा PO catalogs के लिए Lingui चुनें। हमने इन तीनों की तुलना next-intl vs react-i18next vs Lingui में की है।
Lovable या Bolt के विपरीत Copilot किसी एक framework तक सीमित नहीं है। इसलिए stack का सवाल वास्तव में खुला है और library का चुनाव आपका है। लेकिन क्रम तय है: library install करें, पहले से मौजूद strings को convert करें और उसके बाद prevention पर ध्यान दें। ऐसे codebase पर prevention rule लिखने से, जहाँ अभी भी 90 प्रतिशत English hardcoded है, आपको मापने के लिए कुछ नहीं मिलता।
.github/copilot-instructions.md में क्या होना चाहिए?
इस path पर मौजूद repository instructions file अपने-आप detect हो जाती है और workspace में chat requests पर लागू होती है। GitHub की अपनी guidance है कि हर instruction छोटी और self-contained हो, उसके पीछे का कारण बताया जाए और वह चीज़ें शामिल न की जाएँ जिन्हें linter पहले से enforce करता है। इस guidance का पालन करने वाला i18n section छोटा होता है:
## User-facing text
- User-facing text belongs in the message catalog, never in a component literal.
- Use the translation function from our i18n library for every visible string.
- Reason: a literal cannot be translated and does not show up as a missing key,
so it ships silently in one language.
- Add new English values to the source catalog only. Never hand-edit other locales.
- Not user-facing: test names, log lines, error codes, internal constants.
आख़िरी पंक्ति जितनी दिखती है, उससे कहीं अधिक महत्वपूर्ण है। जो rules जरूरत से ज़्यादा जगह लागू होते हैं, उन्हें लोग नज़रअंदाज़ करने लगते हैं। अगर कोई rule agent को log messages wrap करने को कहे, तो वह पूरे section को शोर समझना सीख जाएगा। अगर अभी आपके पास कोई instructions file नहीं है, तो VS Code chat में init command से आपके codebase के आधार पर एक draft बना सकता है। यह blank file से बेहतर शुरुआत है।
क्या path-specific instructions file बेहतर काम कर सकती है?
हाँ, और यही वह सुविधा है जो Copilot में मौजूद है लेकिन अन्य जगहों की editor rules files में नहीं। .instructions.md पर समाप्त होने वाली files, जिन्हें .github/instructions के अंतर्गत रखा जाता है, अपने frontmatter में applyTo glob रखती हैं और agent के matching file को छूने पर ही load होती हैं।
---
name: 'UI strings'
description: 'String handling rules for components'
applyTo: '**/*.{jsx,tsx}'
---
Every visible string in this file must come from the catalog.
Key format is feature.element.state, lowerCamelCase.
If you add a key here, add its English value to the source catalog in the same change.
Rule को component files तक सीमित रखने से वह विश्वसनीय बना रहता है। यह वहीं लागू होता है जहाँ user-facing text मौजूद है और आपकी API routes तथा migration scripts में शांत रहता है। अगर repository root में पहले से AGENTS.md या CLAUDE.md है, तो Copilot उन्हें भी हमेशा लागू रहने वाली instructions के रूप में पढ़ता है। इसलिए कई agents चलाने वाली टीम को हर tool के लिए अलग file की जरूरत नहीं होती।
Instructions से छूट जाने वाली strings को क्या पकड़ता है?
CI में lint rule, क्योंकि इस stack में यही एकमात्र layer है जो build fail कर सकती है। Instructions केवल संभावना बदलती हैं; failing check नतीजा बदलता है। हमने why AI agents keep adding hardcoded strings में इस enforcement layer को विस्तार से समझाया है, और यही setup Copilot repository में भी बिना बदलाव के लागू होता है।
Copilot-विशिष्ट अतिरिक्त सुरक्षा pull request है। Repository instructions Copilot code review पर भी लागू होती हैं, ठीक वैसे ही जैसे chat पर। इसलिए वही file generation को दिशा देने के साथ coding agent के draft PR पर आने वाली review comments को भी दिशा देती है। इससे आपको ऐसा gate मिलता है जिसे inline autocomplete पार नहीं कर सकता—और यह इस लेख की शुरुआत में बताए गए gap का समाधान करने के सबसे करीब है।
इनमें से कोई भी उपाय repository में पहले से मौजूद debt को खत्म नहीं करता और न ही कोई locale file भरता है। Review में कोई literal पकड़ना केवल यह बताता है कि एक string missing है। उसे key करना, translate करना और बाकी locales को sync से बाहर होने से बचाए रखना अब भी किसी को करना होगा।
globalize.now की भूमिका कहाँ आती है?
यह catalog तैयार करने वाली layer में काम करता है—वह हिस्सा जिसे आपकी i18n library या instructions file में से कोई नहीं संभालता। आप app में repository connect करते हैं और यह codebase को एक बार convert करके hardcoded strings को keys से बदलता है तथा locale files बनाता है। इस one-time conversion के बाद, आपके commits से जुड़ी नई catalog units का अनुवाद push jobs करती हैं।
Output JSON या PO में मिलता है, इसलिए catalogs उसी format में आते हैं जिसे आपकी runtime library पहले से पढ़ती है। यही तरीका दूसरे agentic editors पर भी लागू होता है: Claude Code और Cursor अलग दिशा से इसी समस्या का सामना करते हैं, और Next.js codebase के लिए step-by-step तरीका adding i18n to an AI-built Next.js app में है। developer docs में conversion की अधिक जानकारी है और plans pricing page पर उपलब्ध हैं।
संक्षेप में
Instructions file लिखें, component files के लिए path-specific rule लागू करें और CI में lint rule जोड़ें, ताकि Copilot को बताई गई बात और Copilot द्वारा लिखे गए code के बीच का gap shipped English string के बजाय red build बन जाए। फिर backlog को एक बार convert करें, ताकि rule के पास सुरक्षित रखने के लिए एक consistent आधार हो।
globalize.now आपके ऐप्लिकेशन की हार्डकोडेड कॉपी को अनुवाद-तैयार locale फ़ाइलों में बदल देता है और जैसे-जैसे आप नई रिलीज़ करते हैं, उन्हें अपडेट रखता है।
globalize.now को निःशुल्क आजमाएं