i18next बनाम Intlayer | React और Next.js अंतर्राष्ट्रीयकरण (i18n) बेंचमार्क

i18next जावास्क्रिप्ट इकोसिस्टम में सबसे व्यापक रूप से उपयोग किया जाने वाला i18n फ्रेमवर्क है। react-i18next और next-i18next के माध्यम से यह अनगिनत React और Next.js एप्लिकेशनों को संचालित करता है। Intlayer एक आधुनिक, कंपाइलर-आधारित और कंपोनेंट-स्कोप्ड विकल्प है।

यह लेख केवल फीचर लिस्ट के बजाय वास्तविक मापों के आधार पर दोनों की तुलना करता है। सभी आंकड़े Benchmark Bloom से लिए गए हैं, जो एक ओपन-सोर्स बेंचमार्क सूट है जो प्रत्येक लाइब्रेरी के साथ समान एप्लिकेशन बनाता है और ब्राउज़र द्वारा वास्तव में डाउनलोड किए गए डेटा को रिकॉर्ड करता है।

संक्षेप में (tl;dr): i18next बेंचमार्क में सबसे भारी रनटाइम है: साधारण सेटअप में Next.js पर प्रति पेज +77 KB gzip, और पूर्ण नेमस्पेस + लेज़ी-लोडिंग अनुकूलन के बाद भी +22 KB जोड़ता है। जबकि Intlayer केवल +0.3 KB जोड़ता है। पूर्ण रूप से स्कोप्ड कॉन्फ़िगरेशन को छोड़कर, प्रत्येक i18next सेटअप अन्य पेजों के लगभग 90% अनुवादित स्ट्रिंग्स को लीक करता है; Intlayer डिफ़ॉल्ट रूप से 0% लीक करता है। लेज़ी-लोडेड बैकएंड के साथ भाषा बदलने में react-i18next में 123-185 ms लगे, जबकि Intlayer में केवल 3-4 ms। @intlayer/next-i18next एडेप्टर i18next API को बनाए रखता है और मूल के 218.5 KB के मुकाबले 150.7 KB प्रति पेज पर आ गया।

मुख्य बिंदु

• i18next / react-i18next / next-i18next - परिपक्व, प्लगइन्स से भरपूर, और फ्रेमवर्क-अज्ञेयवादी। नेमस्पेस, लैंग्वेज डिटेक्टर्स, बैकएंड्स, प्लगइन के जरिए ICU, और रिच कंटेंट के लिए <Trans> का समर्थन। कंटेंट locales/{lng}/{ns}.json में केंद्रीकृत रहता है। शक्तिशाली है, लेकिन प्रत्येक अनुकूलन (नेमस्पेस विभाजन, प्रति पेज लोडिंग, टाइप सुरक्षा) मैन्युअल कॉन्फ़िगरेशन मांगता है।
• Intlayer - कंपोनेंट-केंद्रित कंटेंट मॉडल। .content.ts शब्दकोश उसी कंपोनेंट के बगल में स्थित होते हैं जिसे वे सेवा प्रदान करते हैं, बिल्ड-टाइम कंपाइलर कंपोनेंट और लोकेल के आधार पर ट्री-शेकिंग और लेज़ी-लोडिंग करता है, कंटेंट से स्वचालित रूप से सख्त TypeScript प्रकार उत्पन्न होते हैं, और अनुवाद छूटने पर बिल्ड तुरंत फेल हो जाता है। मिडलवेयर, SEO हेल्पर्स, विजुअल एडिटर / CMS और AI अनुवाद प्रदान करता है।

सभी तालिका सामग्री दिखाएं

सभी तालिका सामग्री दिखाएं

सभी डेटा सामग्री को स्पष्ट रूप से देखने के लिए तालिका को मोडल में खोलें

लाइब्रेरी	GitHub स्टार्स	कुल कमिट्स	अंतिम कमिट	पहला संस्करण	NPM संस्करण	NPM मासिक डाउनलोड
aymericzip/intlayer				अप्रैल 2024
i18next/i18next				जनवरी 2012
i18next/react-i18next				दिसंबर 2015
i18next/next-i18next				नवंबर 2018

बैज अपने आप अपडेट होते हैं। आंकड़े समय के साथ बदल सकते हैं।

तुलनात्मक फीचर विश्लेषण

बेंचमार्क परिणाम

क्या मापा गया

Benchmark Bloom सूट प्रत्येक लाइब्रेरी के साथ समान एप्लिकेशन बनाता है: 10 पेज (home, about, blog, careers, contact, FAQ, pricing, products, settings, team), 10 भाषाएँ (en, fr, es, de, it, pt, zh, ja, ko, ru), समान कंपोनेंट्स और समान कंटेंट। परीक्षण अंग्रेजी और फ्रेंच में किए गए। प्रत्येक लाइब्रेरी को चार लोडिंग रणनीतियों में परखा गया:

Intlayer में कोई "scoped" संस्करण नहीं है: कंपाइलर स्वचालित रूप से प्रति कंपोनेंट सामग्री को अलग करता है, इसलिए इसके static और dynamic विकल्प पहले से ही अनुकूलित हैं।

प्रत्येक बिल्ड के लिए दर्ज किए गए मेट्रिक्स:

• Lib size: केवल i18n लाइब्रेरी आयात करने वाले खाली कंपोनेंट का gzip आकार।
• Page JS: प्रति पेज डाउनलोड किया गया औसत JavaScript gzip आकार।
• Locale leak %: डाउनलोड किए गए JS में उन अनुवादित स्ट्रिंग्स का अनुपात जो उस भाषा से संबंधित हैं जिसे उपयोगकर्ता नहीं देख रहा है।
• Page leak %: डाउनलोड किए गए JS में उन अनुवादित स्ट्रिंग्स का अनुपात जो उस पेज से संबंधित हैं जिस पर उपयोगकर्ता नहीं है।
• Component avg: अलग से कंपाइल किए गए प्रत्येक कंपोनेंट का औसत gzip आकार।
• E2E reactivity: नई भाषा चुनने और DOM में html[lang] अपडेट होने के बीच का वास्तविक समय (Playwright, 5 पुनरावृत्तियाँ)।
• Hydration: React के हाइड्रेशन चरण की अवधि।

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

Next.js पर परिणाम (next-i18next)

डेटा का विश्लेषण

• रनटाइम लागत: react-i18next के साथ i18next का कोर सबसे भारी रनटाइम है: खाली कंपोनेंट के लिए 19.7 KB gzip, जबकि next-intlayer के लिए केवल 5.5 KB।
• साधारण सेटअप की उच्च लागत: init() में इनलाइन resources से 218.5 KB प्रति पेज बनता है, जो बेस ऐप से +77.5 KB अधिक है। हर पेज हर नेमस्पेस को ढोता है।
• अनुकूलन में भारी मेहनत: बैकएंड (dynamic) पर जाने से 49 KB की बचत होती है लेकिन फिर भी अन्य पेजों के 90% स्ट्रिंग्स लीक होते हैं। रूट स्तर पर नेमस्पेस विभाजित करने (scoped-dynamic) पर 0% लीकेज के साथ आकार 163.4 KB हो जाता है, जो फिर भी Intlayer (141.3 KB) से +22.4 KB प्रति पेज भारी है।
• कंपोनेंट आकार: useTranslation() का उपयोग करने वाला कंपोनेंट 26-79 KB में कंपाइल होता है; वही कंपोनेंट useIntlayer() के साथ केवल 6.9 KB में कंपाइल होता है।
• हाइड्रेशन: dynamic सेटअप में हाइड्रेशन 27.7 ms तक बढ़ जाता है क्योंकि React के हाइड्रेट होने से पहले i18next इंस्टेंस को क्लाइंट पर बैकएंड हल करना पड़ता है।

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

Next.js की विशेषताओं को अलग करके TanStack Start पर शुद्ध react-i18next के साथ समान परीक्षण:

डेटा का विश्लेषण

• साधारण react-i18next ऐप बेस ऐप की तुलना में प्रति पेज +69 KB अधिक डेटा भेजता है, और हाइड्रेशन में 85 ms (बेस का 4 गुना) का समय लगता है क्योंकि पहली रेंडरिंग से पहले पूरे रिसोर्स ट्री को प्रोसेस किया जाता है।
• भाषा बदलने में देरी: बैकएंड के जरिए लेज़ी-लोडिंग करते समय भाषा बदलने पर नेटवर्क राउंड-ट्रिप की आवश्यकता होती है: dynamic में 123 ms और scoped-static में 185 ms। जबकि Intlayer दोनों मोड में 3-4 ms में DOM अपडेट करता है।
• पूरी तरह से अनुकूलित scoped-dynamic 127.2 KB पर पहुँचता है, जो फिर भी Intlayer के dynamic से +8.6 KB अधिक है, और इसके लिए रूट-टू-नेमस्पेस मैप व Suspense बाउंड्री की आवश्यकता पड़ी।
• Intlayer का static विकल्प पहले से ही 0% पेज लीकेज देता है क्योंकि केवल वर्तमान पेज के कंपोनेंट्स द्वारा आयातित शब्दकोश ही बंडल होते हैं। importMode: 'dynamic' चालू करने से भाषा लीकेज भी पूरी तरह समाप्त हो जाती है।
• कंपोनेंट आकार: react-i18next में प्रति कंपोनेंट 24-27 KB बनाम Intlayer में 6-8 KB।

यह अंतर क्यों है? ग्लोबल इंस्टेंस बनाम कंपाइल किए गए शब्दकोश

i18next को 2012 में एक रनटाइम के रूप में डिजाइन किया गया था: एक ग्लोबल इंस्टेंस संसाधन भंडार रखता है, प्लगइन्स इसे विस्तारित करते हैं, और रेंडर समय पर t() कुंजियों को खोजता है। यह इसे अत्यधिक लचीला बनाता है लेकिन भारी भी बनाता है:

.
├── i18n.ts                      # createInstance().use(...).use(...).init({...})
└── src
    ├── locales
    │   ├── en
    │   │   ├── common.json
    │   │   ├── home.json
    │   │   └── about.json
    │   └── fr
    │       ├── common.json
    │       ├── home.json
    │       └── about.json
    ├── components
    │   └── Counter.tsx          # useTranslation("about") + t("counter.label")
    └── app
        └── [locale]
            └── about
                └── page.tsx     # इसे जानना होगा कि इसे ["common", "about"] की आवश्यकता है

ग्लोबल इंस्टेंस यह अनुमान नहीं लगा सकता कि कंपोनेंट को किन कुंजियों की आवश्यकता होगी, इसलिए यह उन सभी नेमस्पेस को बनाए रखता है जिन्हें लोड करने के लिए कहा गया है। अनुकूलन का अर्थ है कि आप फाइलों को विभाजित करें, आप प्रत्येक पेज के लिए आवश्यक नेमस्पेस सूचीबद्ध करें, और कंपोनेंट बदलने पर उस सूची को बनाए रखें। जैसा कि बेंचमार्क रिपोर्ट में कहा गया है: "टाइप सुरक्षा बनाए रखना और यह जानना कि किस पेज पर कौन सा नेमस्पेस चाहिए, एक दुःस्वप्न है।"

Intlayer ग्लोबल इंस्टेंस को पूरी तरह समाप्त कर देता है। कंटेंट सीधे कंपोनेंट के बगल में घोषित होता है, और कंपाइलर बिल्ड समय पर निर्भरता ट्री को हल करता है:

.
├── intlayer.config.ts
└── src
    ├── components
    │   └── Counter
    │       ├── index.tsx        # useIntlayer("counter")
    │       └── index.content.ts
    └── app
        └── [locale]
            └── about
                ├── page.tsx
                └── page.content.ts

@intlayer/swc / @intlayer/babel यह पहचानता है कि कौन सा कंपोनेंट किस शब्दकोश को आयात करता है, केवल उन्हें और केवल सक्रिय भाषा के लिए बंडल करता है, और बाकी को हटा देता है। "scoped-dynamic" पैटर्न बिल्ड का स्वचालित परिणाम बन जाता है।

dynamic पंक्ति के परिणाम प्राप्त करने के लिए intlayer.config.ts में dictionary.importMode: 'dynamic' सेट करें। अधिक जानकारी के लिए बंडल ऑप्टिमाइज़ेशन दस्तावेज़ देखें।

डेवलपर अनुभव (DX)

सेटअप

next-i18next (App Router)

import { createInstance } from "i18next";
import { initReactI18next } from "react-i18next/initReactI18next";
import resourcesToBackend from "i18next-resources-to-backend";
import { defaultLocale } from "@/i18n.config";

const backend = resourcesToBackend(
  (locale: string, namespace: string) =>
    import(`../../locales/${locale}/${namespace}.json`)
);

export const initI18next = async (
  locale: string,
  namespaces: string[] = ["common"]
) => {
  const i18n = createInstance();
  await i18n
    .use(initReactI18next)
    .use(backend)
    .init({
      lng: locale,
      fallbackLng: defaultLocale,
      ns: namespaces,
      defaultNS: "common",
      interpolation: { escapeValue: false },
      react: { useSuspense: false },
    });
  return i18n;
};

इसके अलावा क्लाइंट-साइड I18nProvider, generateStaticParams, और हर पेज पर namespaces सूची को बनाए रखना पड़ता है।

Intlayer

import { type IntlayerConfig, Locales } from "intlayer";

const config: IntlayerConfig = {
  internationalization: {
    locales: [Locales.ENGLISH, Locales.FRENCH],
    defaultLocale: Locales.ENGLISH,
  },
};

export default config;

import { getHTMLTextDir } from "intlayer";
import { IntlayerClientProvider, type NextLayoutIntlayer } from "next-intlayer";

const LocaleLayout: NextLayoutIntlayer = async ({ children, params }) => {
  const { locale } = await params;

  return (
    <html lang={locale} dir={getHTMLTextDir(locale)}>
      <body>
        <IntlayerClientProvider locale={locale}>
          {children}
        </IntlayerClientProvider>
      </body>
    </html>
  );
};

export default LocaleLayout;

क्लाइंट कंपोनेंट

react-i18next

{
  "counter": {
    "label": "Counter",
    "increment": "Increment"
  }
}

"use client";

import { useState } from "react";
import { useTranslation } from "react-i18next";

export const Counter = () => {
  const { t, i18n } = useTranslation("about");
  const [count, setCount] = useState(0);
  const numberFormat = new Intl.NumberFormat(i18n.language);

  return (
    <div>
      <p>{numberFormat.format(count)}</p>
      <button
        aria-label={t("counter.label")}
        onClick={() => setCount((c) => c + 1)}
      >
        {t("counter.increment")}
      </button>
    </div>
  );
};

इस कंपोनेंट को रेंडर करने वाले पेज को about नेमस्पेस लोड करना होगा, और CustomTypeOptions का विस्तार किए बिना t("counter.label") केवल एक सामान्य स्ट्रिंग है।

Intlayer

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

const counterContent = {
  key: "counter",
  content: {
    label: t({ en: "Counter", fr: "Compteur" }),
    increment: t({ en: "Increment", fr: "Incrémenter" }),
  },
} satisfies Dictionary;

export default counterContent;

"use client";

import { useState } from "react";
import { useIntlayer } from "next-intlayer";
import { useNumber } from "next-intlayer/format";

export const Counter = () => {
  const { label, increment } = useIntlayer("counter");
  const number = useNumber();
  const [count, setCount] = useState(0);

  return (
    <div>
      <p>{number(count)}</p>
      <button aria-label={label} onClick={() => setCount((c) => c + 1)}>
        {increment}
      </button>
    </div>
  );
};

label और increment पूरी तरह से टाइप-सुरक्षित हैं; वर्तनी की गलती TypeScript त्रुटि देती है और फ्रेंच अनुवाद गायब होने पर बिल्ड रुक जाता है।

सिंक्रोनस सर्वर कंपोनेंट

next-i18next

type ServerCounterProps = {
  t: (key: string) => string;
  locale: string;
  count: number;
};

export const ServerCounter = ({ t, locale, count }: ServerCounterProps) => (
  <div>
    <p>{new Intl.NumberFormat(locale).format(count)}</p>
    <button aria-label={t("counter.label")}>{t("counter.increment")}</button>
  </div>
);

पेज को i18n.getFixedT(locale, "about") कॉल करके t और locale को Props के रूप में नीचे भेजना पड़ता है।

Intlayer

import { useIntlayer } from "next-intlayer/server";
import { useNumber } from "next-intlayer/server/format";

export const ServerCounter = ({ count }: { count: number }) => {
  const { label, increment } = useIntlayer("counter");
  const number = useNumber();

  return (
    <div>
      <p>{number(count)}</p>
      <button aria-label={label}>{increment}</button>
    </div>
  );
};

i18next API बनाए रखें, Intlayer का बेहतर प्रदर्शन पाएं

बेंचमार्क परिणामों का लाभ उठाने के लिए आपको अपने कंपोनेंट्स को फिर से लिखने की आवश्यकता नहीं है। @intlayer/i18next, @intlayer/react-i18next, और @intlayer/next-i18next ड्रॉप-इन एडेप्टर हैं: useTranslation, t(), <Trans>, {{interpolation}}, बहुवचन और संदर्भ प्रत्यय बिना किसी बदलाव के काम करते रहते हैं।

import type { NextConfig } from "next";
import { createNextI18nPlugin } from "@intlayer/next-i18next/plugin";

const withIntlayer = createNextI18nPlugin();

const nextConfig: NextConfig = {};

export default withIntlayer(nextConfig);

import { defineConfig } from "vite";
import { reactI18nextVitePlugin } from "@intlayer/react-i18next/plugin";

export default defineConfig({
  plugins: [reactI18nextVitePlugin()],
});

बेंचमार्क में, उसी Next.js ऐप का संगत बिल्ड एप्लिकेशन कोड को छुए बिना 218.5 KB से 150.7 KB प्रति पेज, कंपोनेंट 78.5 KB से 9.7 KB, पेज लीकेज ~90% से 0%, और हाइड्रेशन 15.6 ms से घटकर 11.3 ms हो गया। आपकी मौजूदा locales/{lng}/{ns}.json फाइलें JSON सिंक प्लगइन के माध्यम से प्राथमिक डेटा स्रोत बनी रह सकती हैं।

माइग्रेशन गाइड देखें: i18next, react-i18next, next-i18next।

कब किसका चयन करें?

• i18next चुनें: यदि आपको इसके विशाल प्लगइन इकोसिस्टम की आवश्यकता है, आप React के बाहर भी स्थानीयकरण करते हैं (Node सेवाएँ, Vanilla JS, अन्य फ्रेमवर्क), आपकी टीम पहले से इसमें कुशल है, या कोई अनुवाद प्लेटफ़ॉर्म locales/{lng}/{ns}.json फ़ाइलों की अपेक्षा करता है। प्रदर्शन महत्वपूर्ण होने पर नेमस्पेस विभाजन और पेज मैपिंग के लिए समय निकालें।
• Intlayer चुनें: यदि आप कंपोनेंट-स्तरीय कंटेंट, सख्त TypeScript सुरक्षा, बिल्ड-समय पर अनुवाद सत्यापन, शून्य-प्रयास ट्री-शेकिंग और लेज़ी लोडिंग, त्वरित भाषा स्विचिंग, सिंक्रोनस सर्वर कंपोनेंट्स और अंतर्निहित संपादन उपकरण (विजुअल एडिटर, CMS, AI अनुवाद, MCP सर्वर) चाहते हैं। मॉड्यूलर कोडबेस और डिज़ाइन सिस्टम के लिए यह सर्वोत्तम है।
• @intlayer/*-i18next एडेप्टर चुनें: यदि आप पहले से ही i18next का उपयोग कर रहे हैं और कोड को फिर से लिखे बिना बंडल साइज और प्रतिक्रिया गति में सुधार चाहते हैं।

संबंधित तुलनात्मक लेख

• next-intl बनाम Intlayer (समान बेंचमार्क)
• Lingui बनाम Intlayer (समान बेंचमार्क)
• vue-i18n बनाम Intlayer बेंचमार्क (समान बेंचमार्क)
• next-i18next बनाम next-intl बनाम Intlayer
• react-i18next बनाम react-intl बनाम Intlayer
• क्या i18next पुराना हो चुका है?

GitHub स्टार्स

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

निष्कर्ष

i18next ने अपना सम्मानजनक स्थान बनाया है: यह हर जगह काम करता है, हर चीज़ के लिए प्लगइन प्रदान करता है, और इसे एक दशक से अधिक समय से संवारा गया है। लेकिन बेंचमार्क इसके रनटाइम-केंद्रित डिज़ाइन की लागत को उजागर करता है। सामान्य सेटअप प्रति पेज +70-77 KB gzip जोड़ता है, ~90% अन्य पेजों की सामग्री लीक करता है, और भाषा बदलने में 100 ms से अधिक समय लेता है। इसे शून्य तक ले जाना संभव है लेकिन उसके लिए भारी मैन्युअल प्रबंधन की आवश्यकता होती है।

Intlayer इस पूरे कार्य को कंपाइलर पर स्थानांतरित करता है। प्रति-कंपोनेंट शब्दकोश, प्रति-भाषा लेज़ी लोडिंग और अप्रयुक्त सामग्री को हटाना बिल्ड के स्वाभाविक परिणाम हैं। उसी ऐप पर: प्रति पेज केवल +0.3 KB, 0% लीकेज, कंपोनेंट्स 3-10 गुना छोटे, और भाषा स्विचिंग मात्र 3-4 ms में।

सभी आंकड़े, परीक्षण एप्लिकेशन और स्क्रिप्ट Benchmark Bloom रिपॉजिटरी में सार्वजनिक रूप से उपलब्ध हैं।

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