i18next बनाम @intlayer/i18next: समान API, पूरी तरह भिन्न बंडल

@intlayer/i18next, @intlayer/react-i18next और @intlayer/next-i18next अनुकूलता (compat) एडेप्टर हैं। वे उसी i18next API को प्रदर्शित करते हैं जिसका उपयोग आपका कोड पहले से कर रहा है (useTranslation, t(), <Trans>, i18n.changeLanguage(), getFixedT, serverSideTranslations...) और इसे Intlayer द्वारा संकलित शब्दकोशों से प्रस्तुत करते हैं। घटक नहीं बदलते; केवल उनके नीचे का रनटाइम बदलता है।

यह लेख एक ही Next.js एप्लिकेशन पर उस प्रतिस्थापन को मापता है, जिसे एक बार next-i18next के साथ और एक बार @intlayer/next-i18next के साथ बनाया गया है। आंकड़े Benchmark Bloom से लिए गए हैं। लाइब्रेरी के रूप में i18next और Intlayer की तुलना के लिए, i18next बनाम Intlayer पढ़ें। यह लेख इस बात पर केंद्रित है कि जब आप अपने कोड को वैसे ही रखते हैं जैसा वह है, तो एडेप्टर क्या बदलता है।

संक्षेप में (tl;dr): उसी Next.js ऐप पर, next-i18next को @intlayer/next-i18next से बदलने पर प्रति-पेज JavaScript का आकार gzip में 218.5 KB से घटकर 150.7 KB हो गया (प्राथमिक सेटअप में) और इसने पूरी तरह से अनुकूलित next-i18next सेटअप (163.4 KB) को 12.7 KB से पीछे छोड़ दिया। औसत घटक 78.5 KB से घटकर 9.7 KB हो गया, बाहरी-पेज स्ट्रिंग लीकेज ~90% से घटकर 0% हो गया, हाइड्रेशन का समय 15.6 ms से घटकर 11.3 ms हो गया, और रनटाइम 19.7 KB से घटकर 9.4 KB हो गया। किसी भी घटक को संपादित नहीं किया गया; केवल एक प्रोवाइडर फ़ाइल बदली गई। i18next प्लगइन्स (बैकएंड, भाषा संसूचक) स्वीकार किए जाते हैं लेकिन वे कुछ नहीं करते, क्योंकि रनटाइम पर लोड करने या पता लगाने के लिए कुछ नहीं बचता है।

@intlayer/i18next क्या है

i18next एक रनटाइम है। i18n.init({ resources }) या कोई बैकएंड प्लगइन locales/{lng}/{ns}.json को एक ग्लोबल इंस्टेंस में लोड करता है; useTranslation("about") घटक को इससे जोड़ता है; t("title") रेंडर समय पर कुंजी की खोज करता है। नेमस्पेस, लेज़ी लोडिंग, प्रति-पेज नेमस्पेस सूचियाँ और टाइप सुरक्षा को कॉन्फ़िगर और प्रबंधित करना आपकी ज़िम्मेदारी होती है।

एडेप्टर API को बनाए रखते हैं और ग्लोबल इंस्टेंस को प्रतिस्थापित करते हैं:

1. आयात उपनामकरण (Import aliasing)। @intlayer/next-i18next/plugin का createNextI18nPlugin() (या withI18next) withIntlayer को लपेटता है और Webpack / Turbopack उपनाम जोड़ता है ताकि next-i18next, react-i18next और i18next अपने समकक्ष @intlayer/* पैकेजों पर हल हो सकें। Vite पर, @intlayer/react-i18next/plugin से reactI18nextVitePlugin() यही कार्य करता है। किसी भी आयात का नाम बदलने की आवश्यकता नहीं होती।
2. JSON एकमात्र सत्य स्रोत के रूप में। syncJSON प्लगइन आपकी मौजूदा locales/{lng}/{ns}.json फ़ाइलों को format: "i18next" के साथ पढ़ता है (ताकि {{name}}, $t() नेस्टिंग, _one / _other और संदर्भ प्रत्यय ठीक से पार्स हों) और जब CLI या CMS उन्हें अपडेट करता है तो अनुवाद वापस लिखता है।
3. कॉल-साइट बाइंडिंग। Intlayer अनुकूलन पास useTranslation("about") को एक ऐसे कॉल में फिर से लिखता है जो सीधे सक्रिय लोकेल में about शब्दकोश प्राप्त करता है। घटक ग्लोबल स्टोर तक पहुंचना बंद कर देता है।

// आपका कोड, अपरिवर्तित
import { useTranslation } from "react-i18next";

const About = () => {
  const { t } = useTranslation("about");
  return <h1>{t("title")}</h1>;
};

import _dicHash_about from "../.intlayer/dictionaries/about.mjs";
import { useDictionary as useTranslation } from "@intlayer/react-i18next";

const About = () => {
  const { t } = useTranslation(_dicHash_about);
  return <h1>{t("title")}</h1>;
};

यह पुनर्लेखन ही नीचे दिए गए घटक-आकार और पेज-लीकेज स्तंभों को बेहतर बनाता है।

एडेप्टर क्या रखते हैं, क्या अनदेखा करते हैं और क्या प्रतिस्थापित नहीं कर सकते

बेंचमार्क

क्या मापा गया था

Benchmark Bloom सुइट प्रत्येक सेटअप के साथ समान एप्लिकेशन बनाता है: 10 पेज (होम, अबाउट, ब्लॉग, करियर, संपर्क, एफएक्यू, मूल्य निर्धारण, उत्पाद, सेटिंग्स, टीम), 10 लोकेल (en, fr, es, de, it, pt, zh, ja, ko, ru), समान घटक और समान सामग्री। पेजों को en और fr में मापा जाता है।

next-i18next को चार लोडिंग रणनीतियों में बनाया गया था, प्रत्येक लोकेल के JSON को resources में आयात करने (static) से लेकर प्रति रूट एक नेमस्पेस तक, जिसे बैकएंड के माध्यम से लोड किया गया था (scoped-dynamic)। एडेप्टर को प्राथमिक सेटअप के समान घटकों पर बनाया गया था, जिसमें केवल next.config.ts, intlayer.config.ts और प्रोवाइडर फ़ाइल बदली गई थी। इसमें कोई मैन्युअल "scoped" संस्करण नहीं है: कंपाइलर प्रति घटक सामग्री को स्वचालित रूप से सीमित करता है।

प्रत्येक बिल्ड के लिए, परीक्षण रिकॉर्ड करता है:

• लाइब्रेरी आकार: एक खाली घटक का gzip आकार जो केवल i18n लाइब्रेरी आयात करता है।
• पेज JS: सभी पेजों और लोकेलों में औसत रूप से प्रति पेज डाउनलोड किया गया gzip जावास्क्रिप्ट।
• लोकेल लीकेज %: डाउनलोड किए गए JS में अनुवादित स्ट्रिंग्स का हिस्सा जो उस लोकेल से संबंधित है जिसे उपयोगकर्ता नहीं देख रहा है।
• पेज लीकेज %: डाउनलोड किए गए JS में अनुवादित स्ट्रिंग्स का हिस्सा जो उस पेज से संबंधित है जिस पर उपयोगकर्ता नहीं है।
• घटक औसत: अलगाव में संकलित प्रत्येक घटक का औसत gzip आकार।
• E2E प्रतिक्रियाशीलता: एक नया लोकेल चुनने और DOM में html[lang] अपडेट होने के बीच का वास्तविक समय (Playwright, 5 पुनरावृत्तियां)।
• हाइड्रेशन: React हाइड्रेशन चरण की अवधि।

नीचे दिए गए आंकड़े 12-09-2026 के परीक्षण से आते हैं, जिसमें next-i18next 16.3.0 (react-i18next 17.0.13, i18next 26.4.2) और @intlayer/next-i18next 9.5.1 शामिल हैं। परीक्षण एप्लिकेशन जानबूझकर छोटा रखा गया है, इसलिए लीकेज प्रतिशत एक पैटर्न का वर्णन करते हैं: वे आपकी सामग्री के साथ बढ़ते हैं जबकि रनटाइम लागत स्थिर रहती है।

Next.js पर परिणाम

वे मेट्रिक्स और लाइब्रेरी चुनें जिनकी आपको परवाह है:

इसे कैसे समझें

• प्राथमिक सेटअप से प्रति पेज 68 KB कम। resources: { en, fr, ... } हर पेज पर हर लोकेल और हर नेमस्पेस भेजता है: 218.5 KB। समान घटकों का एडेप्टर बिल्ड 150.7 KB पर आता है। यह next-i18next के सर्वश्रेष्ठ कॉन्फ़िगरेशन (163.4 KB) को भी 12.7 KB से हराता है, क्योंकि अकेले i18next रनटाइम का वजन 19.7 KB है जबकि एडेप्टर का केवल 9.4 KB है।
• बिना किसी घटक को छुए लीकेज 0% हो जाता है। पूरी तरह से विभाजित सेटअप को छोड़कर प्रत्येक next-i18next सेटअप बाहरी पेजों की लगभग 90% स्ट्रिंग्स भेजता है। dynamic पंक्ति वास्तव में दिखती स्थिति से बदतर है: यह पेज लीकेज को कहीं भी कम नहीं करती और 50% लोकेल लीकेज जोड़ती है, क्योंकि प्रति-लोकेल बैकएंड अभी भी संपूर्ण translation नेमस्पेस को खींचता है। एडेप्टर मूल कोड से 0% / 0% तक पहुंचता है।
• घटक: 8 गुना छोटे। अलगाव में संकलित एक useTranslation() घटक इनलाइन resources के साथ औसत 78.5 KB और बैकएंड के साथ 26-27 KB होता है, क्योंकि t ग्लोबल स्टोर से बंधा होता है। एडेप्टर के साथ यह औसतन 9.7 KB हो जाता है।
• तेज़ हाइड्रेशन और भाषा बदलना। हाइड्रेशन 15.6 ms से घटकर 11.3 ms हो जाता है (और dynamic सेटअप में 27.7 ms से, जहाँ बैकएंड फ़ेच महत्वपूर्ण पथ पर स्थित होता है)। लोकेल बदलना 15-16 ms से घटकर 11-12 ms हो जाता है।
• एडेप्टर मूल रनटाइम नहीं है। next-intlayer बेस ऐप से केवल +0.3 KB अधिक यानी 141.3 KB पर पहुंचता है। एडेप्टर Intlayer के कोर के ऊपर i18next API सतह (इंटरपोलेशन, बहुवचन और संदर्भ प्रत्यय समाधान, <Trans> टैग पार्सिंग) रखता है: 9.4 KB और मूल की तुलना में प्रति पेज +9.4 KB। यह एक पुल है, अंतिम गंतव्य नहीं।

पूरी तालिका, प्रत्येक लाइब्रेरी और रणनीति, Next.js बेंचमार्क रिपोर्ट में।

TanStack Start पर परिणाम (react-i18next)

Vite और TanStack Start के लिए, बेंचमार्क साधारण react-i18next की तुलना intlayer से करता है:

पूरी तालिका TanStack Start बेंचमार्क रिपोर्ट में।

Vite / TanStack Start पर react-i18next एडेप्टर इस परीक्षण का हिस्सा नहीं था। TanStack Start पर react-i18next बेसलाइन i18next बनाम Intlayer में है: बैकएंड lazy होने पर प्रति पेज 127-184 KB और लोकेल स्विच में 123-185 ms।

संख्याएँ क्यों बदलती हैं

components/ में कुछ भी नहीं बदला, इसलिए लाभ इस बात से आता है कि useTranslation किससे बंधा है।

i18next के साथ, बाइंडिंग ग्लोबल इंस्टेंस होती है। इसमें जो कुछ भी लोड किया गया था (static में सभी लोकेल, dynamic में सक्रिय लोकेल का पूरा नेमस्पेस) वह useTranslation() को कॉल करने वाले प्रत्येक घटक से सुलभ होता है। बंडलर इंस्टेंस में रखी गई सीमा से नीचे कोड को विभाजित नहीं कर सकता है, और रनटाइम यह नहीं जान सकता कि कोई घटक किन कुंजियों की मांग करेगा।

.
├── next-i18next.config.js
├── public/locales
│   ├── en/translation.json           # प्रत्येक पेज की स्ट्रिंग्स
│   └── fr/translation.json
├── i18n/i18n.ts                      # i18n.use(initReactI18next).init({ resources })
└── components
    ├── AppProviders.tsx              # <I18nextProvider i18n={i18n}>
    └── About.tsx                     # useTranslation(); t("about.title")

इंस्टेंस में जो कुछ भी होता है वह हर पेज पर भेजा जाता है, और अपव्यय दो अक्षों, पेज और लोकेल पर बढ़ता है:

@intlayer/next-i18next के साथ, बाइंडिंग सीधे शब्दकोश होती है। syncJSON प्रत्येक नेमस्पेस फ़ाइल को एक शब्दकोश में बदल देता है; अनुकूलन पास घटक को वह शब्दकोश सौंपता है जिसे वह निर्दिष्ट करता है, एक ऐसे आयात के रूप में जिसे बंडलर ट्रैक कर सकता है और प्रति पेज और प्रति लोकेल विभाजित कर सकता है।

.
├── intlayer.config.ts                # syncJSON({ format: "i18next", source: ... })
├── public/locales
│   ├── en/translation.json           # अपरिवर्तित, अभी भी सत्य का स्रोत
│   └── fr/translation.json
├── .intlayer/                        # जनरेट किया गया: प्रति नेमस्पेस, प्रति लोकेल एक शब्दकोश
└── components
    ├── AppProviders.tsx              # <IntlayerClientProvider locale={locale}>
    └── About.tsx                     # useTranslation(); t("about.title")  ← अपरिवर्तित

i18n/i18n.ts और इसका resources आयात बेकार कोड बन जाते हैं। यही 68 KB की बचत है।

तीन चरणों में माइग्रेशन

1. 1

   इंस्टॉल करें

   bash

   सामग्री कॉपी करें

   कोड कॉपी करें

   कोड को क्लिपबोर्ड पर कॉपी करें

   npx intlayer init --interactive
   

   कमांड i18next / react-i18next / next-i18next का पता लगाता है, intlayer, फ्रेमवर्क पैकेज (next-intlayer या react-intlayer), मेल खाने वाला @intlayer/* एडेप्टर और @intlayer/sync-json-plugin स्थापित करता है, और intlayer.config.ts को प्री-फ़िल करता है। मूल पैकेजों को स्थापित रखें: वे पीयर निर्भरता के रूप में कार्य करते हैं और प्रकार प्रदान करते हैं।

2. 2

   Intlayer को अपनी लोकेल फ़ाइलों पर निर्देशित करें

   intlayer.config.ts

   सामग्री कॉपी करें

   कोड कॉपी करें

   कोड को क्लिपबोर्ड पर कॉपी करें

   import { Locales, type IntlayerConfig } from "intlayer";
   import { syncJSON } from "@intlayer/sync-json-plugin";
   
   const config: IntlayerConfig = {
     internationalization: {
       locales: [Locales.ENGLISH, Locales.FRENCH, Locales.SPANISH],
       defaultLocale: Locales.ENGLISH,
     },
     dictionary: {
       importMode: "dynamic",
       format: "i18next",
     },
     plugins: [
       syncJSON({
         // i18next बोली: {{name}}, $t(key), key_one / key_other, key_male
         format: "i18next",
         // प्रति नेमस्पेस एक फ़ाइल: `useTranslation("about")` → about.json
         source: ({ locale, key }) => `./public/locales/${locale}/${key}.json`,
         location: "public/locales",
       }),
     ],
   };
   
   export default config;
   

   यदि आपके पास प्रति लोकेल केवल एक translation.json है (i18next का डिफ़ॉल्ट नेमस्पेस), तो splitKeys: false सेट करें ताकि पूरी फ़ाइल एक शब्दकोश बनी रहे और सामान्य useTranslation() काम करता रहे।

3. 3

   प्लगइन जोड़ें

   Next.jsVite / TanStack Start

   next.config.ts

   सामग्री कॉपी करें

   कोड कॉपी करें

   कोड को क्लिपबोर्ड पर कॉपी करें

   import type { NextConfig } from "next";
   import { withI18next } from "@intlayer/next-i18next/plugin";
   
   const nextConfig: NextConfig = {};
   
   export default withI18next(nextConfig);
   

   App Router पर, क्लाइंट घटक [locale] सेगमेंट से अपना लोकेल प्राप्त करते हैं। एडेप्टर का I18nextProvider कोई लोकेल नहीं लेता है, इसलिए इसे अपनी प्रोवाइडर फ़ाइल में एक बार बदलें:

   components/AppProviders.tsx

   सामग्री कॉपी करें

   कोड कॉपी करें

   कोड को क्लिपबोर्ड पर कॉपी करें

   "use client";
   
   import { IntlayerClientProvider } from "next-intlayer";
   import type { LocalesValues } from "intlayer";
   
   export const AppProviders = ({
     locale,
     children,
   }: {
     locale: LocalesValues;
     children: React.ReactNode;
   }) => (
     <IntlayerClientProvider locale={locale}>{children}</IntlayerClientProvider>
   );
   

   इसके नीचे का प्रत्येक घटक अभी भी सामान्य रूप से useTranslation() को कॉल करता है।

   vite.config.ts

   सामग्री कॉपी करें

   कोड कॉपी करें

   कोड को क्लिपबोर्ड पर कॉपी करें

   import { defineConfig } from "vite";
   import react from "@vitejs/plugin-react";
   import { reactI18nextVitePlugin } from "@intlayer/react-i18next/plugin";
   
   export default defineConfig({
     plugins: [react(), reactI18nextVitePlugin()],
   });
   

   reactI18nextVitePlugin() vite-intlayer को लपेटता है और react-i18next तथा i18next को उपनाम देता है। गैर-React प्रोजेक्ट के लिए, @intlayer/i18next/plugin से i18nextVitePlugin() अकेले i18next को उपनाम देता है।

इसके बाद आप क्या हटा सकते हैं

बाइट्स से परे आपको क्या लाभ मिलते हैं

• टाइप की गई कुंजियाँ। useTranslation("about") को संकलित about शब्दकोश के विरुद्ध टाइप किया गया है; t("does.not.exist") एक स्ट्रिंग लौटाने के बजाय एक TypeScript त्रुटि देता है।
• npx intlayer test किसी भी लोकेल में गायब कुंजी पर CI को रोक देता है। npx intlayer fill आपकी अपनी प्रदाता कुंजी (OpenAI, Anthropic, Mistral, Gemini...) के साथ गायब कुंजियों का अनुवाद करता है और उन्हें locales/{lng}/{ns}.json में वापस लिखता है।
• विजुअल एडिटर और CMS उसी JSON पर काम करते हैं, इसलिए अनुवादक UI के माध्यम से संपादन करते हैं और फ़ाइलें Git में अपडेट हो जाती हैं।
• .content.ts में क्रमिक स्थानांतरण। कोई भी घटक एक समर्पित सामग्री फ़ाइल के साथ useTranslation("about") से useIntlayer("about") पर स्विच कर सकता है। JSON और .content.ts शब्दकोश एक साथ शांतिपूर्वक काम करते हैं।

शुरू करने से पहले जानने योग्य सीमाएँ

फीचर तुलना

बाइट्स से आगे, हर विकल्प आपको क्या देता है:

रनटाइम आकार ऊपर वर्णित Next.js रन से लिए गए हैं।

कब किसका उपयोग करें?

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

संबंधित तुलनाएं

समान एडाप्टर श्रृंखला:

लाइब्रेरी की आमने-सामने तुलना:

संदर्भ दस्तावेज़:

Compat adapters:

Migration guides:

ये लाइब्रेरी कहाँ से आईं, यह समझने के लिए JavaScript i18n का इतिहास पढ़ें।

निष्कर्ष

i18next इस बेंचमार्क में सबसे भारी रनटाइम है, और एडेप्टर आपको इसके API को छोड़ने के लिए कहे बिना इसके अधिकांश भार को हटा देते हैं। उसी Next.js ऐप पर जो प्राथमिक सेटअप की तुलना में प्रति पेज 68 KB कम, हाथ से अनुकूलित सर्वोत्तम सेटअप से 12.7 KB कम, 8 गुना छोटे घटक, 0% लीकेज और 4 ms तेज़ हाइड्रेशन प्रदान करता है, वह भी केवल एक कॉन्फ़िग फ़ाइल, एक प्लगइन लाइन और एक प्रोवाइडर संपादन के साथ।

सभी परीक्षण डेटा, ऐप और स्क्रिप्ट Benchmark Bloom रिपॉजिटरी में उपलब्ध हैं।

अधिक जानकारी के लिए Intlayer क्यों? दस्तावेज़ देखें।