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

next-intl Next.js के लिए सबसे लोकप्रिय i18n लाइब्रेरी है। Intlayer एक कंपाइलर-आधारित, घटक-क्षेत्रीय विकल्प है। दोनों App Router एप्लिकेशन का स्थानीयकरण करते हैं। सवाल यह है कि ऐप बनने के बाद प्रत्येक की लागत क्या है।

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

संक्षेप में (tl;dr): next-intl केवल अपने रनटाइम के लिए प्रत्येक पेज पर +12.6 KB gzip जोड़ता है, और अपने सामान्य सेटअप (static और dynamic) में ~90% अन्य पेजों की स्ट्रिंग्स लीक करता है। उस लीकेज को हटाने के लिए कैटलॉग को नेमस्पेस में विभाजित करना और प्रत्येक पेज के लिए मैन्युअल रूप से चुनना पड़ता है, जो एक कठिन काम है। इसके विपरीत, Intlayer का कंपाइलर बिना किसी अतिरिक्त कॉन्फ़िगरेशन के 0% लीकेज, 3 गुना छोटे कंपोनेंट्स, और बेस ऐप से केवल +0.3 KB अधिक साइज़ सुनिश्चित करता है।

संक्षेप में

• next-intl - Next.js समुदाय का मानक। प्रति भाषा केंद्रीकृत JSON डिक्शनरी, पूर्ण ICU MessageFormat समर्थन, और Next.js अनुरोध हैंडलिंग और राउटिंग के साथ गहरा एकीकरण।
• Intlayer - कंपोनेंट-केंद्रित कंटेंट मॉडल। .content.ts फाइलें अपने कंपोनेंट्स के बगल में बैठती हैं, बिल्ड-टाइम कंपाइलर उन्हें प्रति कंपोनेंट और प्रति लोकेल ट्री-शेक और लेज़ी-लोड करता है, और स्वचालित रूप से सख्त TypeScript प्रकार उत्पन्न करता है।

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

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

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

लाइब्रेरी	GitHub स्टार्स	कुल कमिट्स	अंतिम कमिट	पहला संस्करण	NPM संस्करण	NPM डाउनलोड्स
aymericzip/intlayer				अप्रैल 2024
amannn/next-intl				मार्च 2021

बैज स्वचालित रूप से अपडेट होते हैं।

आमने-सामने सुविधा तुलना

बेंचमार्क

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

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

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

प्रत्येक बिल्ड के लिए, सुइट रिकॉर्ड करता है:

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

नीचे दिए गए आंकड़े 2026-09-12 के रन से हैं, जिसमें next-intl 4.14.2 और intlayer 9.5.1 शामिल हैं।

Next.js (App Router) पर परिणाम

अपनी पसंद के मेट्रिक्स और लाइब्रेरी चुनें:

परिणामों को कैसे समझें

• रनटाइम लागत। बेस एप्लिकेशन 141.0 KB प्रति पेज है। next-intl इसे 153.6 KB (प्रत्येक पेज पर +12.6 KB gzip) तक ले जाता है, जबकि Intlayer इसे केवल 141.3 KB (+0.3 KB) तक ले जाता है।
• लीकेज। सबसे आम सेटअप (static और dynamic) में, next-intl हर पेज पर ~90% अन्य पेजों की सामग्री भेजता है, क्योंकि पूरी en.json क्लाइंट प्रोवाइडर में जाती है। 0% तक पहुँचने के लिए सावधानीपूर्वक मैनुअल विभाजन की आवश्यकता होती है, जबकि Intlayer स्वचालित रूप से 0% पर है।
• कंपोनेंट साइज़। useTranslations() को कॉल करने वाला कंपोनेंट औसतन 21.8 KB का होता है; useIntlayer() के साथ वही कंपोनेंट केवल 6.9 KB का होता है।

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

TanStack Start (use-intl) पर परिणाम

use-intl next-intl का फ्रेमवर्क-अज्ञेय कोर है। वही API, वही संदेश प्रारूप। TanStack Start पर intlayer के साथ इसकी तुलना Next.js-विशिष्ट भागों को समीकरण से हटा देती है।

परिणामों को कैसे समझें

• सरल use-intl सेटअप बेस ऐप की तुलना में प्रति पेज 68.8 KB अधिक JS भेजता है।
• dynamic मोड में, use-intl 119.4 KB पर आता है, लेकिन फिर भी 89.8% पेज लीकेज वहन करता है।
• कंपोनेंट के स्तर पर वास्तुकला का अंतर स्पष्ट है: use-intl के साथ 76-87 KB बनाम Intlayer के साथ 6-8 KB।
• लोकेल स्विचिंग Intlayer के साथ 2x-4x तेज़ है (3 ms बनाम 7-21 ms)।

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

अंतर क्यों है? केंद्रीकृत कैटलॉग बनाम कंपाइल की गई डिक्शनरी

next-intl क्लासिक मॉडल का पालन करता है: प्रति लोकेल एक JSON, जो getRequestConfig में लोड होता है, NextIntlClientProvider में पास होता है, और t("namespace.key") द्वारा पढ़ा जाता है।

.
├── messages
│   ├── en.json
│   └── fr.json
└── src
    ├── i18n
    │   ├── request.ts
    │   └── routing.ts
    ├── middleware.ts
    └── app
        └── [locale]
            ├── layout.tsx
            └── about
                └── page.tsx

रनटाइम यह नहीं जान सकता कि कोई पेज किन कुंजियों का उपयोग करेगा, इसलिए संपूर्ण कैटलॉग भेजना ही सुरक्षित डिफ़ॉल्ट है।

वहां तक न पहुँचने की लागत दो अक्षों पर एक साथ बढ़ती है, पृष्ठ और भाषाएँ:

Intlayer जिम्मेदारी को बदल देता है। सामग्री सीधे कंपोनेंट के बगल में घोषित की जाती है:

.
├── intlayer.config.ts
└── src
    ├── middleware.ts
    └── app
        └── [locale]
            ├── layout.tsx
            └── about
                ├── page.tsx
                └── page.content.ts
    └── components
        └── Counter
            ├── index.tsx
            └── index.content.ts

बिल्ड समय पर, कंपाइलर देखता है कि कौन सा कंपोनेंट कौन सी डिक्शनरी इम्पोर्ट करता है, और केवल सक्रिय लोकेल के लिए उन डिक्शनरी को बंडल करता है।

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

डेवलपर अनुभव

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

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

"use client";

import { useState } from "react";
import { useTranslations, useFormatter } from "next-intl";

export const Counter = () => {
  const t = useTranslations("counter");
  const format = useFormatter();
  const [count, setCount] = useState(0);

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

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>
  );
};

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

डिज़ाइन सिस्टम के घटक (जैसे नेवबार, फूटर, कार्ड) अक्सर सर्वर कंपोनेंट होते हैं जिन्हें क्लाइंट कंपोनेंट के चिल्ड्रन के रूप में रेंडर किया जाता है, इसलिए वे async नहीं हो सकते।

type ServerCounterProps = {
  t: (key: string) => string;
  formattedCount: string;
};

export const ServerCounter = ({ t, formattedCount }: ServerCounterProps) => (
  <div>
    <p>{formattedCount}</p>
    <button aria-label={t("label")}>{t("increment")}</button>
  </div>
);

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>
  );
};

मेटाडेटा (Metadata)

import type { Metadata } from "next";
import { getTranslations } from "next-intl/server";
import { routing } from "@/i18n/routing";

const localizedPath = (locale: string, path: string) =>
  locale === routing.defaultLocale ? path : `/${locale}${path}`;

export const generateMetadata = async ({
  params,
}: {
  params: Promise<{ locale: string }>;
}): Promise<Metadata> => {
  const { locale } = await params;
  const t = await getTranslations({ locale, namespace: "about" });

  const languages = Object.fromEntries(
    routing.locales.map((l) => [l, localizedPath(l, "/about")])
  );

  return {
    title: t("title"),
    description: t("description"),
    alternates: {
      canonical: localizedPath(locale, "/about"),
      languages: { ...languages, "x-default": "/about" },
    },
  };
};

import { getIntlayer, getMultilingualUrls } from "intlayer";
import type { Metadata } from "next";
import type { LocalPromiseParams } from "next-intlayer";

export const generateMetadata = async ({
  params,
}: LocalPromiseParams): Promise<Metadata> => {
  const { locale } = await params;
  const metadata = getIntlayer("about-metadata", locale);
  const multilingualUrls = getMultilingualUrls("/about");

  return {
    ...metadata,
    alternates: {
      canonical: multilingualUrls[locale as keyof typeof multilingualUrls],
      languages: { ...multilingualUrls, "x-default": "/about" },
    },
  };
};

next-intl API बनाए रखें, Intlayer का आउटपुट प्राप्त करें

उपरोक्त बेंचमार्क परिणाम प्राप्त करने के लिए आपको अपने कंपोनेंट्स को दोबारा लिखने की आवश्यकता नहीं है। @intlayer/next-intl एक ड्रॉप-इन एडेप्टर है: यह useTranslations, getTranslations, useFormatter, t.rich() और ICU प्लुरल्स को बनाए रखता है, और उन्हें Intlayer डिक्शनरी से परोसता है।

import type { NextConfig } from "next";
import { createNextIntlPlugin } from "@intlayer/next-intl/plugin";

const withIntlayer = createNextIntlPlugin();

const nextConfig: NextConfig = {};

export default withIntlayer(nextConfig);

बेंचमार्क में, बिना किसी कोड परिवर्तन के, इसी ऐप का कंपैट बिल्ड प्रति पेज 153.6 KB से घटकर 147.5 KB, कंपोनेंट साइज़ 21.8 KB से घटकर 8.1 KB, और पेज लीकेज ~90% से घटकर 0% हो गया। आपकी मौजूदा messages/{locale}.json फाइलें JSON सिंक प्लगइन के माध्यम से सत्य का स्रोत बनी रह सकती हैं।

चरण-दर-चरण प्रक्रिया के लिए next-intl माइग्रेशन गाइड देखें।

कब किसे चुनें?

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

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

वही बेंचमार्क, अन्य लाइब्रेरीज़:

next-intl पर गहराई से जानें:

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

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

GitHub STARS

GitHub स्टार किसी प्रोजेक्ट की लोकप्रियता, सामुदायिक विश्वास और दीर्घकालिक प्रासंगिकता का एक मजबूत संकेतक हैं।

कमिट गतिविधि

स्टार लोकप्रियता दिखाते हैं। कमिट दिखाते हैं कि किसी प्रोजेक्ट में कितना काम लगा है। लिखते समय Intlayer में लगभग 7,500 कमिट हैं, जो यहाँ तुलना की गई अधिकांश लाइब्रेरी से ज़्यादा हैं और next-intl या next-i18next से लगभग 5 गुना।

Intlayer एक मोनोरेपो है, इसलिए इस संख्या में हर फ़्रेमवर्क पैकेज, CLI और डॉक्स शामिल हैं। कमिट को गुणवत्ता नहीं, गतिविधि का संकेत मानें।

npm डाउनलोड

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

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

निष्कर्ष

next-intl एक ठोस, अच्छी तरह से अनुरक्षित लाइब्रेरी है, और बेंचमार्क पुष्टि करता है कि यह Next.js पर एक अच्छा विकल्प है। लेकिन इसका केंद्रीकृत कैटलॉग मॉडल हर अनुकूलन का भार डेवलपर पर डालता है: सरल सेटअप लगभग 90% अन्य पेजों की सामग्री लीक करता है, और अकेले रनटाइम की लागत प्रत्येक पेज पर +12.6 KB gzip होती है।

Intlayer उस काम को कंपाइलर में स्थानांतरित करता है। प्रति-कंपोनेंट डिक्शनरी, प्रति-लोकेल लेज़ी लोडिंग और अप्रयुक्त सामग्री को हटाना बिल्ड आउटपुट हैं। परिणाम: +0.3 KB प्रति पेज, 0% लीकेज, कंपोनेंट्स 3 गुना छोटे, और TanStack Start पर लोकेल स्विचिंग 2x-4x तेज़।

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

अधिक विवरण के लिए 'Why Intlayer?' दस्तावेज़ देखें।