सही Svelte i18n लाइब्रेरी कैसे चुनें

Svelte i18n के लिए कुछ भी इन-बिल्ट प्रदान नहीं करता है। कोई $t नहीं, कोई locale primitive नहीं, कोई message format नहीं। प्रत्येक विकल्प एक third-party चयन है, और Svelte ecosystem वह जगह है जहाँ compile-time i18n सबसे आगे निकल गया है, इसलिए उम्मीदवार React या Vue की तुलना में एक-दूसरे से अधिक भिन्न हैं।

यह गाइड उन सवालों की सूची देती है जिनका उत्तर पहले दिया जाना चाहिए, फिर उन उत्तरों को svelte-i18n, Paraglide, typesafe-i18n, wuchale और Intlayer से मैप करती है, Vite + Svelte और SvelteKit दोनों के लिए।

विषय सूची

लाइब्रेरीज़ की तुलना करने से पहले उत्तर देने के लिए छह प्रश्न

1. Vite SPA या SvelteKit? एक SPA में module-level store सही है: एक टैब, एक उपयोगकर्ता, एक locale। SvelteKit पर वही singleton सर्वर पर समवर्ती अनुरोधों (concurrent requests) में साझा हो जाता है, और अनुरोध B, अनुरोध A की भाषा में रेंडर होता है। लाइब्रेरी या तो आपको per-request shape (context, locals) देती है या इसे आप पर छोड़ देती है।
2. अनुवाद कौन लिखता है? डेवलपर्स, एक TMS, ICU स्ट्रिंग्स डिलीवर करने वाली एजेंसी, या एक AI pipeline। svelte-i18n ICU बोलता है। Paraglide और typesafe-i18n अपने स्वयं के सिंटैक्स का उपयोग करते हैं। अपने वेंडर से मिलान करें।
3. कितने locales और पेज हैं? दो locales और पाँच पेज सब कुछ शिप कर सकते हैं। दस locales और चालीस routes ऐसा नहीं कर सकते, और runtime catalogs तथा compiled messages के बीच का अंतर मुख्य लागत बन जाता है।
4. क्या आपको keys पर types की आवश्यकता है? $_("cart.totl") svelte-i18n में एक runtime विफलता है। Compile-time लाइब्रेरीज़ इसे बनावट के आधार पर ही एक type error बना देती हैं।
5. Svelte 4 stores या Svelte 5 runes? Runes locale state के सिंटैक्स को बदलते हैं, साझा करने की समस्या को नहीं। लेकिन एक .ts फ़ाइल में $state एक सामान्य चर (plain variable) में संकलित होता है, इसलिए यदि आप Svelte 5 पर हैं तो लाइब्रेरी के runtime को rune-aware होना चाहिए।
6. क्या आप repo में generated files के साथ काम कर सकते हैं? Paraglide और typesafe-i18n दोनों आपके source tree में JavaScript या TypeScript उत्पन्न करते हैं। कुछ टीमें इसके साथ सहज हैं, दूसरों को प्रत्येक समानांतर शाखा (parallel branch) पर merge conflicts मिलते हैं।

उत्तरों को लिख लें। नीचे दी गई हर बात उन पर वापस संदर्भित होती है।

एक तस्वीर में परिदृश्य

Svelte i18n, React या Vue की तुलना में बाद में आया, और सीधे compile-time तरंगों पर चला गया।

JavaScript i18n का इतिहास प्रत्येक तरंग को विस्तार से कवर करता है।

वह निर्णय जो सबसे अधिक मायने रखता है: सामग्री कहाँ रहती है और कब लोड होती है

दो संरचनात्मक विकल्प सेटअप के बीच बंडल के अधिकांश अंतर को समझाते हैं:

• केंद्रीकृत या स्कोप्ड सामग्री। ऐप के लिए एक locales/en.json, या प्रति घटक एक घोषणा।
• Static या dynamic import। स्टार्टअप पर सब कुछ, या सक्रिय locale (और आदर्श रूप से सक्रिय route) मांग पर प्राप्त (fetch) किया जाता है।

यह ग्राफ़ 1 से 10 पेजों के एक सैद्धांतिक ऐप के लिए पेलोड का अनुमान लगाता है, जिसका 1 से 10 locales में अनुवाद किया गया है, प्रति पेज लगभग 30 KB टेक्स्ट के साथ।

svelte-i18n डिफ़ॉल्ट रूप से ऊपर-बाएँ में बैठता है: register("fr", () => import("./fr.json")) आपको प्रति locale dynamic loading देता है, लेकिन एक locale catalog एक सिंगल ऑब्जेक्ट होता है और इसे लोड करने से हर पेज की कॉपी लोड हो जाती है। Paraglide एक दिलचस्प मामला है: क्योंकि हर संदेश का अपना export होता है, tree-shaking आपको पेज का अक्ष मुफ़्त में दे देता है, और Svelte benchmark पुष्टि करता है कि यह Vite + Svelte पर विज्ञापित रूप से काम करता है (यह React और Next.js बेंचमार्क में नहीं हुआ था)। Intlayer प्रति-घटक घोषणाओं के माध्यम से उसी कोने तक पहुँचता है।

यदि प्रश्न 3 का आपका उत्तर "कई पेज" था, तो किसी भी API प्राथमिकता से अधिक इस खंड को महत्व दें। Per-component बनाम centralized i18n पोस्ट इसी ट्रेड-ऑफ के रखरखाव पक्ष को कवर करती है।

उम्मीदवार

लाइब्रेरी के आकार Svelte benchmark से हैं: 10-पेज, 10-locale ऐप पर बंडलिंग, tree-shaking और minification के बाद एक खाली घटक में store प्लस accessor। सामग्री को अलग से मापा जाता है।

संख्याएं बेंचमार्क के संस्करणों पर एक स्नैपशॉट हैं। अकेले आकार पर निर्णय लेने से पहले इसे अपने ऐप पर चलाएं। टाइप सुरक्षा: 5/5 का अर्थ है कि URL फॉर्मेटर और हेल्पर्स सहित कुंजियाँ, पैरामीटर और हर लोकेल बिना किसी मैन्युअल सेटअप के जाँचे जाते हैं।

Paraglide का शून्य के करीब लाइब्रेरी आकार इसकी संरचना के कारण है: runtime आपके रिपॉजिटरी में उत्पन्न होता है। Intlayer को vite-intlayer की आवश्यकता होती है, इसलिए यह बिल्ड चरण के बिना नहीं चल सकता है।

कमिट गतिविधि

कमिट्स दिखाते हैं कि हर प्रोजेक्ट में कितना काम हो रहा है। एक मोनोरेपो अपने हर प्रकाशित पैकेज को गिनता है, इसलिए इस संख्या को गुणवत्ता नहीं, बल्कि गतिविधि का संकेत मानें।

npm डाउनलोड

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

AI असिस्टेंट इस प्रभाव को और बढ़ाते हैं। next-intl, i18next और vue-i18n उस कोड में हर जगह हैं जिस पर वे प्रशिक्षित हुए, इसलिए वे विकल्पों की तुलना किए बिना इन्हें डिफ़ॉल्ट रूप से सुझाते हैं। हर सुझाव डाउनलोड बढ़ाता है, जो अगले सुझाव को बढ़ावा देता है। डाउनलोड की संख्या नहीं, बेंचमार्क के आधार पर तुलना करें।

अपने उत्तरों का एक लाइब्रेरी से मिलान करें

प्रत्येक लाइब्रेरी कहाँ कम पड़ती है

• svelte-i18n: सेट का सबसे भारी, कोई key types नहीं, कोई per-route splitting नहीं, module-level store जो SvelteKit पर अनुरोधों के पार लीक होता है जब तक कि आप स्वयं context वायर न करें।
• typesafe-i18n: एक watcher प्रक्रिया, repo में generated files, और एक रिपॉजिटरी जो हाल ही में अधिक सक्रिय नहीं रही है।
• Paraglide: generated files को repo में कमिट किया जाता है और हर पुश से पहले पुन: उत्पन्न किया जाता है, समानांतर शाखाओं पर merge conflicts, और locale को store के बजाय प्रत्येक संदेश कॉल पर cookie या storage से पढ़ा जाता है, जिससे locale परिवर्तन पर काम बढ़ता है।
• wuchale: दिलचस्प निष्कर्षण विचार, अभी भी शुरुआती। React बेंचमार्क में प्रतिक्रियाशीलता संबंधी समस्याओं का सामना करना पड़ा जिसके लिए प्रदाता री-रेंडर को बाध्य करना पड़ा, और प्रलेखन पतला है।
• Intlayer: अनिवार्य build plugin, छोटा इकोसिस्टम, आंशिक ICU समर्थन, और डिज़ाइन द्वारा पूरे कोडबेस में फैली हुई सामग्री, इसलिए अनुवादक के लिए एक JSON निर्यात करने के लिए टूलिंग की आवश्यकता होती है।

प्रत्येक विकल्प कोड में कैसा दिखता है

वही घटक, एक शीर्षक और एक बहुवचन के साथ एक कार्ट सारांश, प्रत्येक उम्मीदवार के साथ लिखा गया है। दिलचस्प हिस्सा मार्कअप नहीं है, यह है कि सामग्री कहाँ रहती है, locale कैसे संग्रहीत होता है, और टाइप चेकर क्या जानता है।

{
  "cart": {
    "title": "Your cart",
    "items": "{count, plural, one {# item} other {# items}}"
  }
}

{
  "cart": {
    "title": "Votre panier",
    "items": "{count, plural, one {# article} other {# articles}}"
  }
}

{
  "cart": {
    "title": "Tu carrito",
    "items": "{count, plural, one {# artículo} other {# artículos}}"
  }
}

<script lang="ts">
  import { _ } from "svelte-i18n";

  let { count }: { count: number } = $props();
</script>

<section>
  <h2>{$_("cart.title")}</h2>
  <p>{$_("cart.items", { values: { count } })}</p>
</section>

{
  "cart_title": "Your cart",
  "cart_items": "{count} items"
}

{
  "cart_title": "Votre panier",
  "cart_items": "{count} articles"
}

{
  "cart_title": "Tu carrito",
  "cart_items": "{count} artículos"
}

<script lang="ts">
  import { m } from "$lib/paraglide/messages.js";

  let { count }: { count: number } = $props();
</script>

<section>
  <h2>{m.cart_title()}</h2>
  <p>{m.cart_items({ count })}</p>
</section>

import type { BaseTranslation } from "../i18n-types";

const en = {
  cart: {
    title: "Your cart",
    items: "{count} item{{s}}",
  },
} satisfies BaseTranslation;

export default en;

import type { Translation } from "../i18n-types";

const fr = {
  cart: {
    title: "Votre panier",
    items: "{count} article{{s}}",
  },
} satisfies Translation;

export default fr;

import type { Translation } from "../i18n-types";

const es = {
  cart: {
    title: "Tu carrito",
    items: "{count} artículo{{s}}",
  },
} satisfies Translation;

export default es;

<script lang="ts">
  import LL from "$i18n/i18n-svelte";

  let { count }: { count: number } = $props();
</script>

<section>
  <h2>{$LL.cart.title()}</h2>
  <p>{$LL.cart.items({ count })}</p>
</section>

import { plural, t, type Dictionary } from "intlayer";

const cartSummaryContent = {
  key: "cart-summary",
  content: {
    title: t({ en: "Your cart", fr: "Votre panier", es: "Tu carrito" }),
    items: t({
      en: plural({ one: "{{count}} item", other: "{{count}} items" }),
      fr: plural({ one: "{{count}} article", other: "{{count}} articles" }),
      es: plural({ one: "{{count}} artículo", other: "{{count}} artículos" }),
    }),
  },
} satisfies Dictionary;

export default cartSummaryContent;

<script lang="ts">
  import { useIntlayer } from "svelte-intlayer";

  let { count }: { count: number } = $props();
  const content = useIntlayer("cart-summary");
</script>

<section>
  <h2>{$content.title}</h2>
  <p>{$content.items(count)}</p>
</section>

पहले से ही svelte-i18n पर हैं? @intlayer/svelte-i18n compat adapter पैकेज को बंडलर स्तर पर उपनाम (alias) देता है ताकि $_, $date, $number और आपकी फ्लैट कुंजियाँ काम करती रहें जबकि Intlayer सामग्री परोसता है।

प्रतिबद्ध होने से पहले

एक सुविधा तालिका आपको बताती है कि आज एक लाइब्रेरी क्या करती है। ये बिंदु आपको बताते हैं कि इसके साथ रहना कैसा होगा।

रिपॉजिटरी गतिविधि की जाँच करें।

कमिट्स, समस्या प्रतिक्रिया समय, और क्या अंतिम लघु रिलीज़ इस वर्ष थी। बिना किसी अनुरक्षक (maintainer) के एक मजबूत डिज़ाइन भविष्य में होने वाला एक माइग्रेशन है।

npm डाउनलोड द्वारा चयन न करें।

सबसे अधिक स्थापित लाइब्रेरी वह है जो पहले शिप की गई थी, वह नहीं जो 2026 Svelte कोडबेस के अनुकूल हो। डाउनलोड इतिहास को मापते हैं, उपयुक्तता को नहीं।

पूछें कि अनुरक्षक को कौन भुगतान करता है, और वे क्या बेचते हैं।

svelte-i18n को Crowdin द्वारा समर्थित किया गया है, जैसे next-intl और vue-i18n। i18next को Locize द्वारा समर्थित किया गया है। Tolgee, Paraglide (inlang) और Intlayer प्रत्येक अपना प्लेटफ़ॉर्म चलाते हैं। एक वेंडर जिसका राजस्व होस्ट किए गए अनुवाद से आता है, उसके पास आपके टूलचेन के अंदर अनुवाद को मुफ़्त बनाने का बहुत कम कारण होता है। Intlayer इस सेट में एकमात्र ऐसा है जो आपकी अपनी API key के साथ CLI के माध्यम से AI अनुवाद और एक CMS शिप करता है जिसे आप स्वयं होस्ट कर सकते हैं।

क्या यह AI-agent तैयार है?

एजेंट अभी भी i18n के साथ संघर्ष करते हैं: वे locales भूल जाते हैं, keys का आविष्कार करते हैं, और संदेश सिंटैक्स मिलाते हैं। क्या लाइब्रेरी Agent Skills या एक MCP server शिप करती है ताकि एजेंट सामग्री को सूचीबद्ध, भर और परीक्षण कर सके? और क्या सामग्री लोडिंग डिफ़ॉल्ट रूप से अनुकूलित है, या किसी को हर तिमाही में नेमस्पेस और लेज़ी आयात की समीक्षा करनी होगी?

बॉक्स से बाहर टाइप सुरक्षा।

"अतिरिक्त वायरिंग के साथ टाइप किया जा सकता है" नहीं बल्कि "एक गलत कुंजी एक नए इंस्टॉल पर tsc को विफल करती है"। जाँचें कि उस कुंजी के साथ क्या होता है जो मौजूद नहीं है, और उस locale के साथ जिसमें एक अनुवाद गायब है।

अप्रयुक्त सामग्री का पता लगाना।

कैटलॉग केवल बढ़ते हैं। Intlayer का बिल्ड अप्रयुक्त फ़ील्ड्स को हटा देता है और उन्हें लॉग करता है (build.purge)। Paraglide आर्किटेक्चर द्वारा वहाँ पहुँचता है, क्योंकि एक अनकॉल्ड संदेश फ़ंक्शन tree-shaken होता है। बाकी सब कुछ सफाई को आप पर छोड़ देता है।

डेवलपर अनुभव।

पहली अनुवादित स्ट्रिंग तक सेटअप समय, एक LSP या VS Code extension जो होवर पर अनुवाद दिखाता है और घोषणा पर कूदता है, भरने, परीक्षण करने और पुश करने के लिए एक CLI, आपके कंपोनेंट्स से हार्ड-कोडेड स्ट्रिंग्स निकालने वाला एक कंपाइलर या एक्सट्रैक्टर ताकि हर स्ट्रिंग को कुंजी-दर-कुंजी प्रबंधित न करना पड़े, और गैर-डेवलपर्स के लिए बिना पुल रिक्वेस्ट के सामग्री संपादित करने का एक तरीका (visual editor या CMS)।

अक्सर पूछे जाने वाले प्रश्न

आगे पढ़ना

यही गाइड