AI-generated app को localize कैसे करें

यह guide बताती है कि AI-generated app को पहले internationalize और फिर localize कैसे करें: keys, locale files, extraction, glossaries और ऐसी automation के साथ जो तेज़ी से बदलते UI के बीच भी काम करती रहे। globalize.now AI-powered localization infrastructure है, जो हर push पर इन catalogs को Git के साथ aligned रखता है—एक बार setup करें, हर push पर auto-sync पाएं और manual file round trips से बचें। AI-first codebases अक्सर i18n layer क्यों छोड़ देते हैं, इसके लिए AI Code Broke Localization — And Nobody Fixed It पढ़ें। अलग-अलग tooling eras के industry context के लिए 3 Stages of Localization Development (And Why AI Changes Everything) देखें। जब repos अभी messy हों, तब vendor sequencing के लिए globalize.now vs Lokalise vs Crowdin और hands-on globalization walkthrough के लिए How to Globalize Your App with globalize.now पढ़ें।

---

“AI-generated app को localize करना” वास्तव में क्या मतलब रखता है?

Localization (l10n) वह है जो users देखते हैं: उनके locale के अनुसार सही भाषा, plurals, dates, currency और layout।

Internationalization (i18n) वह है जो engineers पहले करते हैं: user-visible text को addressable, reusable और बड़े पैमाने पर translate करने के लिए सुरक्षित बनाना।

“अभी localize नहीं कर सकते” वाली ज़्यादातर रुकावटें असल में i18n की रुकावटें होती हैं। Architecture को एक बार ठीक कर दें, तो localization archaeology project के बजाय operations problem बन जाती है।

---

Tools चुनने से पहले i18n architecture checklist में क्या होना चाहिए?

Translation coordination software या translation vendor चुनने से पहले सुनिश्चित करें कि ये building blocks मौजूद हैं—या इन्हें इसी क्रम में जोड़ने की योजना बनाएं:

• Runtime i18n library आपके stack (React, Next.js, Rails आदि) के लिए उपयुक्त हो और UI strings के लिए एक ही supported pattern दे।
• Stable translation keys (namespaced, hierarchical) इस्तेमाल करें; IDs के रूप में English sentences नहीं।
• Locale resource files (JSON, PO, YAML) repo में checked in हों या CI में generate होती हों।
• ICU-style plurals और variables dynamic phrases जैसे "{count} items" के लिए इस्तेमाल करें, ताकि translators grammar को सुरक्षित रूप से reorder कर सकें।
• String extraction pipeline हो, ताकि नया UI चुपचाप catalog को bypass न कर दे।

---

Velocity खोए बिना strings कैसे extract करें?

AI-generated repos में एक ही labels (“Save”, “Cancel”, “Learn more”) दर्जनों files में दोहराए जाते हैं। आपके extraction pass को यह करना चाहिए:

1. User-visible literals detect करें components, routes और shared UI primitives में—technical strings (CSS classes, analytics IDs और URLs, जब तक वे user-facing न हों) को छोड़कर।
2. Duplicates normalize करें और references के साथ एक ही key बनाएं, ताकि translators को meaning की एक ही unit दिखे।
3. Source locale emit करें (आमतौर पर English), जो हर नई key की canonical value हो।
4. Call sites rewrite करें ताकि team द्वारा तय i18n API का इस्तेमाल हो—mechanically, जिससे diff reviewable रहे।

React-style code में minimal before/after कुछ ऐसा दिखता है:

<button>Submit order</button>

Extraction और keying के बाद:

<button>{t("checkout.submit_order")}</button>

// locales/en.json
{
  "checkout.submit_order": "Submit order"
}

---

Languages को scale करने से पहले glossaries और style guides क्यों ज़रूरी हैं?

Machine translation तेज़ है। लेकिन अगर आप constraints तय न करें, तो हर screen अलग product जैसी लग सकती है। कई भाषाओं में scale करने से पहले लिखित रूप में तय करें:

• वे brand terms जिनका अनुवाद नहीं होना चाहिए (product name, feature names)।
• High-risk words (“contact”, “trial”, “billing”, “workspace”) के लिए preferred translations।
• Tone: formal या conversational, और second person या neutral।

उस glossary को अपने coordination stack या MT profile में feed करें, ताकि automated drafts आपकी team के पहले से लिए गए निर्णयों के अनुरूप रहें।

---

Automated checks को translation QA loop का आधार कैसे बनाएं?

जब keys locale files में flow होने लगें, तो modern loop यह है: MT draft → linter checks (length, placeholders, forbidden terms) → high-impact surfaces पर automated regression checks → ship → measure। Automation समय बचाती है; linter आपको टूटे हुए placeholders ship करने से बचाता है।

CLI-style tooling आपको repo में बचे हुए काम की मात्रा पर तेज़ feedback दे सकती है, कुछ इस तरह:

✔ Scanned 312 files
✔ Found 1,284 user-visible literals
✔ Proposed 920 translation keys (364 duplicates merged)
✔ Wrote locales/en.json

Next: sync translation-ready keys to your coordination tool or run an MT batch with glossary v1

---

कौन-से agent prompts localization refactors को reviewable बनाए रखते हैं?

ये prompts मानकर चलते हैं कि आप tests और code review वाले repo में काम कर रहे हैं। इन्हें ऐसे diffs तैयार करने के लिए लिखा गया है जिन पर आप भरोसा कर सकें—चुपचाप होने वाले बड़े refactors के लिए नहीं।

Refactor से पहले UI strings की inventory कैसे बनाएं?

You are analyzing a TypeScript React codebase for localization readiness.

Task: List every pattern where user-visible English might appear (JSX text, string props that render to the DOM, template literals interpolated into UI, aria-label/title/placeholder, toasts, empty states). Exclude className values, internal IDs, and URLs that are not shown to users.

Output: a table with columns: file path, line range, example string, recommended next step (extract key / ignore / needs product decision).

Minimal typed t() API को सुरक्षित तरीके से कैसे introduce करें?

Add a minimal i18n helper used across the app: a typed t(key, vars?) function backed by JSON locale files in /locales. Do not translate yet—only wire English as the source locale.

Constraints:
- Keys use dot namespaces: "section.component.purpose"
- Support ICU-style pluralization for keys that need counts
- Add a dev-only warning when t() is called with a missing key

Show the file tree you created and example usage in two existing components.

Literals को namespaced keys में mechanically कैसे extract करें?

Refactor the following files to replace user-visible string literals with t("…") keys.

Rules:
- Prefer stable semantic keys, not English sentences as keys
- Deduplicate identical UI strings to one key
- Keep string interpolation correct using ICU message patterns
- Do not change layout/styling except where required by the refactor

After edits, print a JSON object mapping each new key to its English source string for translators.

ऐसी glossary CSV का draft कैसे तैयार करें जिस पर translators भरोसा कर सकें?

From locales/en.json and the product marketing pages in this repo, propose a glossary CSV with columns: term_en, part_of_speech, definition_for_translators, do_not_translate (true/false), allowed_synonyms, notes_for_de.

Flag terms that are legally sensitive (pricing, trials, refunds) and terms that are ambiguous in software ("session", "organization", "member").

कौन-सा CI guardrail नए hardcoded English को codebase में आने से रोकता है?

Add a CI script that fails if new user-visible English literals appear in JSX outside of tests/fixtures.

Implementation guidance:
- Use the repo's existing package manager and test runner
- Provide a small allowlist file for exceptions (brand strings, intentional English)
- Print actionable file/line references on failure

Include README notes for how engineers should add exceptions responsibly.

---

क्या आपको अब भी इन prompts को हाथ से paste करना पड़ता है?

तेज़ी से देखें तो, नहीं। जब यह guide पहली बार लिखी गई थी, तब अपने agent में prompts copy-paste करना इस loop को चलाने का practical तरीका था। तब से tooling agent के भीतर आ गई है: coding agents अब MCP server के ज़रिए सीधे localization call कर सकते हैं, इसलिए extraction, keying और translation sync आपके paste किए हुए prompts के बजाय agent द्वारा किए गए tool calls बन जाते हैं। Setup के लिए Introducing the globalize.now MCP देखें और यह बदलाव architecture के स्तर पर क्यों महत्वपूर्ण है, इसके लिए Localization is becoming an agent skill, not an SDK पढ़ें।

ऊपर दिए गए prompts review checklists के रूप में अब भी उपयोगी हैं—वे बताते हैं कि एक अच्छा agent-driven i18n refactor क्या-क्या करे, चाहे उन्हें कोई human paste करे या agent skill उन्हें encode करे। किसी भी automated refactor को इसी कसौटी पर परखें: reviewable diffs, stable keys, ICU-safe interpolation और regressions रोकने वाला CI guardrail।

---

AI-built products को localize करते समय आपको कौन-सी long-term constraint याद रखनी चाहिए?

Localization कोई एक sprint नहीं—यह आपके future self के साथ किया गया contract है। अगर आप keys, catalogs और automation में एक बार निवेश करते हैं, तो हर नया AI-generated screen दुनिया भर में ship करना सस्ता होता जाता है।