अंतर्दृष्टि
लोकैल समानता: AI से वेबसाइट अनुवाद
Locale parity, यानी लोकैल समानता, वह मानक है जो translated वेबसाइट और localized वेबसाइट को अलग करता है. अगर कोई AI coding agent multilingual काम संभालने वाला है, तो उसे यही मानक चाहिए; ऐसा prompt नहीं जो कहे, “site को Spanish में translate कर दो.”
एक-वाक्य test: हर intentional locale के लिए, इंसान और crawler दोनों को source का coherent twin मिलना चाहिए: वही jobs-to-be-done pages, सही language signals, adapted search language, intact structure, और proof कि कुछ drift नहीं हुआ.
ज्यादातर teams strings पर रुक जाती हैं. Agents उस failure को तेज कर देते हैं. यह article end to end लोकैल समानता define करता है और दिखाता है कि agents SEO तोड़े बिना websites कैसे translate करें.
“Translated” sites फिर भी fail क्यों होती हैं
en.json के साथ es.json ship करना पूरा काम लग सकता है. Users और Google सहमत नहीं होते.
Common failure modes:
- Missing siblings. English में
/pricingहै; Spanish में 404. Hreflang ghosts की ओर point करता है. - “Localized” page पर English chrome. Nav, cookies या CTAs अभी भी Book a call कहते हैं जबकि hero Spanish है.
- गलत document language. हर locale पर
<html lang="en">;og:localeen_USपर अटका हुआ. - Broken crawl identity. दो sitemap entrypoints, relative hreflang, या noindex placeholders पर hreflang.
- Calqued keywords. French-Canadian titles अगर literal English calques हैं, तो वे नहीं पकड़ते कि लोग सच में कैसे search करते हैं.
- Structure drift. German में
{name}placeholder गिर गया; Arabic बिनाdir="rtl"; schemainLanguageURL से contradict करता है.
Translation coverage green दिख सकती है जबकि लोकैल समानता red हो. Key counters template drift, SERP language या reciprocal alternates नहीं पकड़ते.
इस काम के हिस्सों के लिए narrow “parity” tools पहले से मौजूद हैं: catalog key diffs, या currency और phone schema के लिए international signal checks. उपयोगी. अधूरे. लोकैल समानता agent-driven website localization के लिए पूरा bar है.
Standard के बिना AI agents इसे और खराब क्यों करते हैं
Coding agents जल्दी बड़े diffs produce करने में बहुत अच्छे हैं. जोखिम भी यही है.
Playbook के बिना agents अक्सर:
- हर string को एक pass में machine-translate करते हैं.
- Dictionary से English titles दूसरे locales में copy कर देते हैं.
- “Helpful” बनने के लिए
Accept-Languagemiddleware जोड़ते हैं. /404और drafts सहित हर path के लिए hreflang emit करते हैं.- Verification skip कर देते हैं क्योंकि build अभी भी TypeScript pass कर गया.
Definition of done के बिना speed multilingual debt बनाती है जो progress जैसा दिखता है. लोकैल समानता वही definition of done है.
अगर आप इस playbook का packaged version चाहते हैं—checklists, translation guidance और offline HTML checkers—तो free MIT i18n Agent GitHub package लें और Cursor या Claude Code में clone करें.
लोकैल समानता की पांच परतें
| Layer | यह किस सवाल का जवाब देती है | Failure कैसा दिखता है |
|---|---|---|
| Route & content | क्या intentional pages twins के रूप में मौजूद हैं? | Soft-404s, orphan EN links, incomplete money-page set |
| Document & crawl | क्या crawlers language cluster पर भरोसा करते हैं? | गलत lang, broken hreflang, dual sitemaps |
| Meaning | क्या copy उस market की language और search में काम करती है? | Calques, tone mismatches, unused local queries |
| Structure | क्या twin अभी भी काम करता है? | Dropped placeholders, missing plurals, LTR Arabic, wrong schema URLs |
| Verification | क्या regressions build fail करा सकते हैं? | अगले agent PR के बाद silent drift |
1. Route और content parity
तय करें कि हर locale में कौन से pages intentional हैं: money pages, insights, legal, tools. Default locale unprefixed हो या हमेशा prefixed; एक strategy चुनें और consistent रहें.
Agents को ये rules follow करने चाहिए:
- हर locale के लिए वही intentional route tree बनाएं, या अगर page सच में मौजूद नहीं है तो उसे hreflang से omit करें.
- Internal links in-locale रखें (
/es/about, Spanish page से/aboutनहीं). - Twins पर वही noindex policy apply करें (
/coffee, placeholders, agent markdown mirrors). - Locales में stable slugs prefer करें ताकि alternates cleanly map हों.
Content collections (MDX/Markdown), department data files और UI chrome अलग translation layers हैं. Agents को तीनों inventory करने चाहिए; केवल messages/*.json नहीं.
2. Document और crawl parity
यह multilingual SEO hygiene है. गलत हुआ तो Google cluster पर भरोसा नहीं करेगा.
हर indexable locale URL पर minimum signals:
- Self-referencing absolute canonical
- Matching
og:url - Localized title और description
- Locale registry से
<html lang>औरdir(जहां उचित हो BCP47) - BCP47 codes (
fr-CA,zh-CN) के साथ reciprocalhreflangset और default-locale URL की ओर point करताx-default - Noindex pages पर कोई hreflang (या
og:locale:alternate) नहीं - एक public sitemap entrypoint जिसकी xhtml alternates
<head>से agree करें - Correct
inLanguageऔर locale-correct entity URLs वाला structured data
Anti-patterns: geo-IP force redirects, dual sitemap identities, relative hreflang, registry में न होने वाले locale codes invent करना.
3. Meaning parity
Meaning parity वह जगह है जहां localization string replacement होना बंद करती है.
Agents को चाहिए:
- एक glossary बनाए रखें (product names, locked URLs, terms जिन्हें translate नहीं करना).
- हर market के लिए style guide follow करें (Canadian French ≠ France French; neutral LatAm Spanish ≠ Spain-only idioms).
- English keyword maps को literal translate करने के बजाय local SERPs के लिए keywords adapt करें; हर URL पर एक primary intent.
- Local clarity और CTR के लिए H1s, titles और metas rewrite करें; brand entities consistent रखें.
- Thin machine translation reject करें जो Search Console में soft-404 बन जाएगी.
Meaning parity वही है जिसे AI Search surfaces reward करती हैं: user की language में clear entities और answers, Spanish URL के नीचे English paragraphs नहीं.
4. Structure parity
जो twin garbage render करे, वह twin नहीं है.
Check करें:
- Interpolation / ICU placeholders source से match करें (
{count},<0>…</0>tags). - Plural और select branches target language की जरूरतों (CLDR) से match करें, English forms की copy से नहीं.
- RTL locales को
dir="rtl"और readable fonts मिलें; CJK को appropriate typography मिले. - Dates, numbers और currencies दिखने पर locale-aware formatting use करें.
- JSON-LD हर page पर English-only paths या
enlanguage hard-code न करे.
Catalog-only parity scripts यहां मदद करते हैं. वे necessary हैं, sufficient नहीं; उन्हें dist/ पर HTML और schema checks के साथ pair करें.
5. Verification parity
अगर agent proof के बिना merge कर सकता है, तो drift guaranteed है.
Verification parity का मतलब:
- Generated HTML पर build-time gates: title, description, H1, canonical,
og:url,lang, hreflang completeness, noindex rules. - Locale inventory tests: हर intentional money page हर live locale में मौजूद है (या explicitly excluded है).
- Deploy के बाद production spot-checks: live head tags, sitemap identity, analytics
page_locale, RTL sample. - Agent-readable reports ताकि अगला run findings fix करे, blind re-translation नहीं.
Rank & Beyond हमारी अपनी multilingual site पर इसी class के checks चलाता है. Reusable skill pack वही discipline दूसरे repos के लिए encode करता है.
Agent anti-patterns (इन्हें ship न करें)
| Anti-pattern | नुकसान क्यों होता है |
|---|---|
Geo-IP या Accept-Language hard redirects |
Cache fragmentation, crawler confusion, trapped users |
| Noindex / 404 / drafts पर hreflang | Language clusters pollute करता है |
| Dual sitemap entrypoints | Crawl identity split करता है |
| “Localization” के रूप में English keyword calques | Local demand language miss होती है |
| Glossary के बिना one-shot MT dump | Tone और product-term drift |
| Locked brand या booking URLs translate करना | Conversions और trust तोड़ता है |
| Route twins के बिना locale को “live” declare करना | 404 की ओर hreflang |
जब कोई agent “convenience” के लिए इनमें से कुछ propose करे, change reject करें.
AI agents को website कैसे translate करनी चाहिए
Localization को phased engineering workflow मानें, single prompt नहीं.
Phase A — Discover
- Framework, routing, i18n libraries और content sources detect करें.
- Current locales, default locale और URL strategy inventory करें.
- Money pages, insights/blog, legal और noindex utilities अलग करें.
- Locked external IDs note करें (booking links, analytics IDs) जिन्हें invent नहीं करना.
Phase B — Plan
- Locale registry लिखें या update करें (codes, labels,
htmlLang,dir, OG locale, BCP47). - Market priority set करें (हर spoke × हर locale explode करने से पहले primary markets deepen करें).
- हर locale के लिए adapted queries वाली keyword map draft करें; English calques नहीं.
- Risks flag करें: RTL, CJK, legal copy, thin pages.
Phase C — Implement technical SEO
- Helpers wire करें:
localizePath,alternatePath, locale-from-pathname. - Canonical, OG, hreflang, sitemap i18n और schema URLs emit करें.
- Language choice UI में रखें; redirects force न करें.
robots.txt, sitemap URL और agent indexes (llms.txt,agent.json) align करें.
Phase D — Translate और transcreate
- UI chrome, structured data copy और long-form content को separate passes में localize करें.
- Glossary और style guide apply करें; titles/metas को SERP language के लिए adapt करें.
- Code, placeholders और locked strings preserve करें.
- Priority markets में H1, title, meta और FAQs पर human review prefer करें.
Phase E — Verify
dist/या URL list पर HTML auditors run करें.- Missing hreflang, lang mismatches, og/canonical drift और noindex alternates पर CI fail करें.
- Deploy के बाद production spot-check करें.
- Record करें कि क्या intentional debt है और क्या blockers हैं.
यही लोकैल समानता operating loop के रूप में है. जो agents केवल Phase D करते हैं, वे translators हैं. जो agents A–E complete करते हैं, वे localizers हैं.
Practical checklist जिसे आप PR में paste कर सकते हैं
किसी भी multilingual PR के लिए इसे definition of done की तरह use करें:
- Locale registry codes और
dirके लिए single source of truth है - हर live locale के लिए intentional routes मौजूद हैं (या alternates missing pages omit करते हैं)
- In-locale internal links; non-EN pages पर accidental EN leaks नहीं
- हर indexable twin पर canonical ===
og:url - केवल indexable pages पर full reciprocal BCP47 hreflang +
x-default - Titles/descriptions localized और unique हैं; keywords adapted हैं, calqued नहीं
- Placeholders/plurals/RTL/schema structure intact है
- एक sitemap entrypoint; noindex routes excluded हैं
- Build gate regressions पर fail होता है
- कम से कम एक non-EN money page के लिए production spot-check complete है
i18n Agent GitHub package पाएं
अगर आप चाहते हैं कि agents default रूप से इस playbook को follow करें, तो हर sprint checklist reinvent करने के बजाय skill install करें.
Free MIT i18n Agent package लें — public GitHub repo खोलें, Cursor या Claude Code में clone करें और AGENTS.md / CLAUDE.md को SKILL.md की ओर point करें.
Inside: phased agent workflow, multilingual SEO checklist, translation playbook, और hreflang, canonical/og:url, lang mismatches तथा noindex alternate mistakes के लिए offline Python checkers.
जिन founders को केवल localization नहीं, broader revenue system चाहिए, वे BeyondOS™ देखें और समझें कि Website, SEO और Content departments एक plan के तहत memory कैसे share करते हैं.
लोकैल समानता FAQ
क्या लोकैल समानता सिर्फ SEO के लिए है?
नहीं. SEO crawl layer है. लोकैल समानता UX completeness, structural integrity और CI proof को भी cover करती है. Site translated query पर rank कर सकती है और फिर भी users को fail कर सकती है अगर RTL, CTAs या placeholders गलत हैं.
क्या day one पर हर insight हर language में चाहिए?
नहीं. Demand unclear हो तो English spokes पहले ship करें; winners के लिए priority markets (उदाहरण के लिए Canadian French, फिर Spanish) localize करें; बाकी locales को clear winners या existing parity के लिए maintain करें. Intentional pages के बिना hreflang में किसी locale को live declare न करें.
क्या एक agent prompt TMS को replace कर सकता है?
कई product marketing sites के लिए strict playbook, glossary और CI gates वाला agent काफी है, खासकर जब translations repo में रहती हैं. बहुत सारे human translators वाले बड़े continuous programs में TMS अभी भी मदद करता है. दोनों cases में लोकैल समानता quality bar है.
Start करने का fastest तरीका क्या है?
Locales और money pages inventory करें, document/crawl signals fix करें, फिर adapted SERP copy के साथ chrome और top URLs translate करें. i18n Agent package install करें ताकि अगला agent run rewrite करने से पहले audit करे.