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

React में कोई इन-बिल्ट i18n primitive नहीं आता है। पहले दिन आप जो लाइब्रेरी चुनते हैं, वह तय करती है कि अनुवाद कैसे स्टोर होंगे, वे बंडल तक कैसे पहुंचेंगे, और अगले कुछ वर्षों के लिए आपका कितना काम बढ़ जाएगा। अधिकांश टीमें लोकप्रियता के आधार पर चुनाव करती हैं, और फिर 2,000 कुंजियों पर पहुंचने के बाद उन्हें इसके नुकसानों का पता चलता है।

यह गाइड विपरीत दिशा में काम करता है: पहले अपने प्रोजेक्ट के बारे में कुछ सवालों के जवाब दें, और फिर उन जवाबों को उपयुक्त लाइब्रेरी से मिलाएँ। यह सादे React (Vite, React Router, TanStack Start) पर केंद्रित है। Next.js की अपनी बाधाएं हैं, जिन्हें Next.js तुलना में शामिल किया गया है।

विषय सूची

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

यह जाने बिना कि कौन सी पंक्तियाँ आपके लिए महत्वपूर्ण हैं, एक फीचर टेबल बेकार है। पहले इन्हें देखें।

1. ऐप कैसे रेंडर होता है? केवल SPA, हाइड्रेशन के साथ SSR, या React Server Components। Context-आधारित hooks SPA में हर जगह काम करते हैं। RSC के साथ, एक hook टेक्स्ट रेंडर करने वाले प्रत्येक घटक पर "use client" को बाध्य करता है, इसलिए आपको सर्वर-साइड API की भी आवश्यकता होगी।
2. अनुवाद कौन लिखता है? डेवलपर्स, TMS का उपयोग करने वाली एक इन-हाउस टीम, ICU फ़ाइलें देने वाली एक एजेंसी, या एक AI पाइपलाइन। यह किसी भी API विवरण से अधिक कैटलॉग प्रारूप को तय करता है।
3. कितने लोकेल्स और पेज हैं? दो लोकेल्स और पाँच पेज सब कुछ शिप करना वहन कर सकते हैं। दस लोकेल्स और पचास रूट्स ऐसा नहीं कर सकते, और लोडिंग रणनीति मुख्य लागत बन जाती है।
4. क्या आपको कुंजियों पर प्रकारों (types) की आवश्यकता है? t("checkout.totl") में एक टाइपो हर कुंजी-आधारित लाइब्रेरी में तब तक संकलित होता है जब तक कि आप स्वयं प्रकारों को वायर न करें। तय करें कि क्या यह स्वीकार्य है।
5. स्ट्रिंग में क्या शामिल है? सादा टेक्स्ट, बहुवचन (plurals), या बीच में <Link> वाले वाक्य। रिच सामग्री वह जगह है जहाँ अधिकांश API अजीब हो जाते हैं।
6. प्रोजेक्ट कितने समय तक चलेगा? तीन महीने के प्रोटोटाइप और पांच साल के उत्पाद को समान मात्रा में बिल्ड टूलिंग की आवश्यकता नहीं होती है।

उत्तर लिख लें। नीचे सब कुछ उनका संदर्भ देता है।

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

JavaScript i18n के पंद्रह वर्ष चार वास्तुकला तरंगों में फिट बैठते हैं, और जिन React लाइब्रेरीज़ की आप तुलना करेंगे वे विभिन्न तरंगों से आती हैं।

JavaScript i18n का इतिहास विस्तार से बताता है कि प्रत्येक तरंग ने पिछली समस्याओं का कैसे समाधान किया।

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

प्रत्येक React i18n लाइब्रेरी का आकार समान होता है: एक स्टोर, एक प्रोवाइडर, एक हुक। प्रोवाइडर जो कुछ भी प्राप्त करता है वह क्लाइंट बंडल में या हाइड्रेशन पेलोड में समाप्त होता है। इसलिए दो संरचनात्मक विकल्प हैं:

• केंद्रीकृत या स्कोप्ड सामग्री। ऐप के लिए एक en.json, या प्रति घटक (या प्रति नेमस्पेस) एक घोषणा।
• स्थिर या गतिशील आयात। स्टार्टअप पर सब कुछ बंडल किया गया, या सक्रिय लोकेल और रूट मांग पर प्राप्त किए गए।

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

स्थिर आयातों के साथ केंद्रीकृत सामग्री दोनों अक्षों के साथ बढ़ती है: 10 पृष्ठ गुणा 10 लोकेल्स का अर्थ है प्रत्येक पृष्ठ पर 300 KB टेक्स्ट। गतिशील आयात लोकेल अक्ष को हटा देते हैं। स्कोपिंग पेज अक्ष को हटा देती है। केवल संयोजन ही स्थिर रहता है।

यह लाइब्रेरी का गुण नहीं है, यह अनुशासन का गुण है। react-i18next को नेमस्पेस और लेज़ी बैकएंड के साथ स्कोप किया जा सकता है। use-intl को प्रति रूट विभाजित किया जा सकता है। लेकिन कोई भी इसे लागू नहीं करता है, और एक साझा <Button> जो t("common:cta") तक पहुंचता है, चुपचाप common को प्रत्येक रूट की निर्भरता बना देता है। बेंचमार्क इसे "अन्य रूट्स से रिसाव" और "अन्य लोकेल्स से रिसाव" के रूप में मापता है, और यहीं से लाइब्रेरीज़ के बीच अधिकांश अंतर आता है।

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

उम्मीदवार

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

संख्याएं बेंचमार्क के संस्करणों का एक स्नैपशॉट हैं और रिलीज के साथ बदलती हैं। केवल आकार पर निर्णय लेने से पहले अपने स्वयं के ऐप पर बेंचमार्क चलाएं।

तालिका दो चीजें नहीं दिखाती है। Paraglide लगभग कोई लाइब्रेरी शिप नहीं करता क्योंकि यह आपके रिपॉजिटरी में कोड जनरेट करता है, जिसका अर्थ है प्रत्येक कमिट से पहले एक पुनर्जनन चरण और जनरेटेड फ़ाइलों पर मर्ज टकराव। और Intlayer को एक बंडलर प्लगइन (vite-intlayer या समकक्ष) की आवश्यकता होती है, इसलिए यह नो-बिल्ड सेटअप में नहीं चल सकता।

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

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

ईमानदार सीमाएँ, क्योंकि हर विकल्प में वे होती हैं।

• react-i18next: सेट में सबसे भारी, इसका अपना बहुवचन प्रारूप, प्रकारों को बनाए रखने की ज़िम्मेदारी आपकी है, अप्रयुक्त कुंजियाँ चुपचाप जमा होती हैं।
• react-intl: विस्तृत DX (useIntl() फिर formatMessage({ id })), कई नोड्स से बंधा वैश्विक इंस्टेंस।
• use-intl: शुरू करने में सरल, अनुकूलित करने में कष्टदायी। नेमस्पेस, गतिशील लोडिंग और प्रकार एक साथ विकास को बहुत धीमा कर देते हैं।
• Lingui: अतिरिक्त extract / compile बिल्ड चरण, कई ओवरलैपिंग सिंटैक्स (t(), टैग किए गए टेम्पलेट, i18n.t(), <Trans>) जो मनुष्यों और AI सहायकों दोनों को भ्रमित करते हैं।
• Paraglide: रेपो में जनरेट की गई फाइलें, React बेंचमार्क में ट्री-शेकिंग प्रभावी नहीं हुई, और लोकेल को स्टोर के बजाय प्रत्येक नोड पर स्टोरेज से पढ़ा जाता है।
• Tolgee: कोई कुंजी प्रकार नहीं, कठिन ऑनबोर्डिंग, इन-कॉन्टेक्स्ट संपादन इसका मुख्य विक्रय बिंदु है।
• Intlayer: अनिवार्य बिल्ड प्लगइन, छोटा इकोसिस्टम, आंशिक ICU समर्थन, डिज़ाइन द्वारा पूरे कोडबेस में फैली सामग्री जिससे एक अनुवादक के लिए एक JSON निर्यात करने के लिए टूलिंग की आवश्यकता होती है।
• gt-react, lingo.dev: बेंचमार्क में अनुशंसित नहीं: बिल्ड पर कोटा त्रुटियां, वेंडर लॉक-इन, और प्रतिक्रियाशीलता समस्याएं जिनके लिए प्रोवाइडर री-रेंडर को बाध्य करना पड़ा।

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

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

{
  "title": "Your cart",
  "items_one": "{{count}} item",
  "items_other": "{{count}} items"
}

import type { FC } from "react";
import { useTranslation } from "react-i18next";

export const CartSummary: FC<{ count: number }> = ({ count }) => {
  const { t } = useTranslation("cart");

  return (
    <section>
      <h2>{t("title")}</h2>
      <p>{t("items", { count })}</p>
    </section>
  );
};

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

import type { FC } from "react";
import { FormattedMessage, useIntl } from "react-intl";

export const CartSummary: FC<{ count: number }> = ({ count }) => {
  const intl = useIntl();

  return (
    <section>
      <h2>
        <FormattedMessage id="cart.title" />
      </h2>
      <p>{intl.formatMessage({ id: "cart.items" }, { count })}</p>
    </section>
  );
};

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

import type { FC } from "react";
import { useTranslations } from "use-intl";

export const CartSummary: FC<{ count: number }> = ({ count }) => {
  const t = useTranslations("Cart");

  return (
    <section>
      <h2>{t("title")}</h2>
      <p>{t("items", { count })}</p>
    </section>
  );
};

msgid "Your cart"
msgstr "Votre panier"

msgid "{count, plural, one {# item} other {# items}}"
msgstr "{count, plural, one {# article} other {# articles}}"

import type { FC } from "react";
import { Plural, Trans } from "@lingui/react/macro";

export const CartSummary: FC<{ count: number }> = ({ count }) => (
  <section>
    <h2>
      <Trans>Your cart</Trans>
    </h2>
    <p>
      <Plural value={count} one="# item" other="# items" />
    </p>
  </section>
);

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

import type { FC } from "react";
import { m } from "../paraglide/messages.js";

export const CartSummary: FC<{ count: number }> = ({ count }) => (
  <section>
    <h2>{m.cart_title()}</h2>
    <p>{m.cart_items({ count })}</p>
  </section>
);

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

const cartSummaryContent = {
  key: "cart-summary",
  content: {
    title: t({
      hi: "आपकी कार्ट",
      en: "Your cart",
      fr: "Votre panier",
      es: "Tu carrito",
    }),
    items: t({
      hi: plural({ one: "{{count}} आइटम", other: "{{count}} आइटम" }),
      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;

import type { FC } from "react";
import { useIntlayer } from "react-intlayer";

export const CartSummary: FC<{ count: number }> = ({ count }) => {
  const { title, items } = useIntlayer("cart-summary");

  return (
    <section>
      <h2>{title}</h2>
      <p>{items(count)}</p>
    </section>
  );
};

पहले से ही react-i18next, react-intl या Lingui पर हैं? कम्पैट एडॉप्टर (react-i18next, react-intl, Lingui) बंडलर स्तर पर आयात को एलियास करते हैं ताकि मौजूदा API घटक दर घटक आगे बढ़ते समय काम करता रहे। माइग्रेशन गाइड बाकी को कवर करता है।

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

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

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

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

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

सबसे अधिक स्थापित लाइब्रेरी वह है जिसे पहले भेजा गया था, वह नहीं जो 2026 React कोडबेस में फिट बैठती है। डाउनलोड इतिहास को मापते हैं, उपयुक्तता को नहीं।

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

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

क्या यह AI-एजेंट के लिए तैयार है?

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

आउट ऑफ द बॉक्स प्रकार सुरक्षा (Type safety)।

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

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

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

डेवलपर अनुभव (Developer experience)।

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

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

आगे पढ़ना

• i18n लाइब्रेरी बेंचमार्क: बंडल आकार, रिसाव और लोकेल-स्विच समय और TanStack Start रिपोर्ट
• React i18n: प्रोवाइडर मॉडल कैसे काम करता है और इसकी लागत क्या है
• react-i18next बनाम react-intl बनाम Intlayer, फीचर दर फीचर
• next-i18next बनाम next-intl बनाम Intlayer
• JavaScript i18n का इतिहास
• कंपाइलर बनाम घोषणात्मक i18n
• प्रति-घटक बनाम केंद्रीकृत i18n
• बिल्ड समय पर बंडल अनुकूलन कैसे काम करता है
• Vite + React ऐप में i18n सेट अप करें
• Vue, Svelte और Solid के लिए समान गाइड