next-intl مقابل Intlayer: مقارنة أداء التدويل (i18n) في React وNext.js

مكتبة next-intl هي أكثر مكتبات i18n شيوعاً لـ Next.js. وتعتبر Intlayer بديلاً قائماً على المترجم بنطاق محدد على مستوى المكونات. كلاهما يقدم حلول التدويل لتطبيقات App Router. والسؤال الأهم هو ما تكلفة كل منهما بمجرد بناء التطبيق.

هذا المقال ليس دليلاً تعليمياً، بل هو مقارنة مدعومة بالأرقام من Benchmark Bloom، وهو مشروع اختبار مفتوح المصدر يبني التطبيق نفسه مع كل مكتبة ويقيس ما يقوم المتصفح بتنزيله وتنفيذه فعلياً.

tl;dr: في نفس تطبيق Next.js، تضيف next-intl +12.6 كيلوبايت gzip من JavaScript على كل صفحة، مقابل +0.3 كيلوبايت لـ Intlayer. دون أي عمل إضافي، ترسل next-intl ~90% من سلاسل الصفحات الأجنبية مع كل صفحة. يتطلب الوصول إلى تسريب بنسبة 0% مع next-intl تحديد نطاقات مساحات الأسماء واستخدام pick(messages, [...]) لكل صفحة. بينما تصل Intlayer إلى 0% افتراضياً لأن مترجمها يحدد نطاق المحتوى لكل مكون. وإذا كنت تريد واجهة برمجة تطبيقات next-intl مع مخرجات Intlayer، فقد سجل محول @intlayer/next-intl 147.5 كيلوبايت لكل صفحة مقابل 153.6 كيلوبايت مع المكتبة الأصلية.

نظرة عامة

• next-intl - معيار مجتمع Next.js. قواميس JSON مركزية لكل لغة، دعم كامل لـ ICU MessageFormat، وتكامل وثيق مع معالجة طلبات Next.js ونظام التوجيه الخاص به.
• Intlayer - نموذج محتوى يتمحور حول المكونات. توضع ملفات .content.ts بجانب مكوناتها، ويقوم مترجم وقت البناء بتقليم الشجرة (tree-shaking) والتحميل الكسول للمحتوى لكل مكون ولكل لغة، مع توليد أنواع TypeScript صارمة تلقائياً.

اظهار جميع محتويات الجدول

اظهار جميع محتويات الجدول

افتح الجدول في نافذة منبثقة لعرض جميع محتويات البيانات بوضوح

المكتبة	نجوم GitHub	إجمالي التعديلات	آخر تعديل	الإصدار الأول	إصدار NPM	تنزيلات NPM
aymericzip/intlayer				أبريل 2024
amannn/next-intl				مارس 2021

يتم تحديث الشارات تلقائياً.

مقارنة الميزات جنباً إلى جنب

الاختبار

ما تم قياسه

تبني مجموعة Benchmark Bloom نفس التطبيق مع كل مكتبة: 10 صفحات (الرئيسية، من نحن، المدونة، الوظائف، اتصل بنا، الأسئلة الشائعة، الأسعار، المنتجات، الإعدادات، الفريق)، و10 لغات (en، fr، es، de، it، pt، zh، ja, ko, ru)، مع مكونات متطابقة ومحتوى متطابق. يتم قياس الصفحات باللغتين en وfr. يتم تطبيق كل مكتبة في ما يصل إلى أربع استراتيجيات تحميل:

لا تملك Intlayer متغيراً "مخصص النطاق" (scoped): يقوم المترجم تلقائياً بتحديد نطاق المحتوى لكل مكون، لذلك فإن صفي static وdynamic محصوران بالفعل.

لكل بناء، تسجل المجموعة:

• حجم المكتبة (Lib size): حجم gzip لمكون فارغ يستورد مكتبة i18n فقط.
• JS للصفحة (Page JS): متوسط حجم JavaScript بتنسيق gzip الذي تم تنزيله لكل صفحة.
• نسبة تسرب اللغة (Locale leak %): نسبة السلاسل التي تنتمي إلى لغة لا يعرضها المستخدم.
• نسبة تسرب الصفحة (Page leak %): نسبة السلاسل التي تنتمي إلى صفحة لا يتصفحها المستخدم.
• متوسط حجم المكون (Component avg): متوسط حجم gzip لكل مكون تم تجميعه بمعزل.
• تفاعلية E2E: الوقت المنقضي بين اختيار لغة جديدة وتحديث html[lang] في الـ DOM.
• الترطيب (Hydration): مدة مرحلة ترطيب React.

الأرقام أدناه مأخوذة من اختبار بتاريخ 2026-09-12 باستخدام next-intl 4.14.2 وintlayer 9.5.1.

النتائج على Next.js (App Router)

اختر المقاييس والمكتبات التي تهمك:

كيف تقرأ هذه النتائج

• تكلفة وقت التشغيل. يزن التطبيق الأساسي 141.0 كيلوبايت لكل صفحة. ترفعه next-intl إلى 153.6 كيلوبايت (+12.6 كيلوبايت gzip في كل صفحة)، بينما يرفعه Intlayer إلى 141.3 كيلوبايت فقط (+0.3 كيلوبايت).
• التسريب. في الإعدادين الأكثر استخداماً (static وdynamic)، ترسل next-intl ما يقرب من ~90% من سلاسل الصفحات الأخرى في كل صفحة، لأن ملف en.json كاملاً يدخل في مزود العميل. يتطلب الوصول إلى 0% تقسيماً يدوياً دقيقاً. أما Intlayer فيحقق 0% تلقائياً.
• حجم المكون. المكون الذي يستدعي useTranslations() يُترجم في المتوسط إلى 21.8 كيلوبايت؛ والمكون نفسه مع useIntlayer() يبلغ 6.9 كيلوبايت فقط. وفي وضع scoped-static تقفز مكونات next-intl إلى 80.1 كيلوبايت لأن كل مكون يُضمن مساحة أسمائه داخلياً.

الجدول الكامل، لكل مكتبة واستراتيجية، في تقرير قياس أداء Next.js.

النتائج على TanStack Start (use-intl)

تعتبر use-intl النواة المستقلة عن أي إطار عمل لمكتبة next-intl. نفس واجهة برمجة التطبيقات ونفس تنسيق الرسائل. مقارنتها مع intlayer على TanStack Start تزيل العوامل الخاصة بـ Next.js من المعادلة.

كيف تقرأ هذه النتائج

• يرسل الإعداد البسيط لـ use-intl ما مقداره 68.8 كيلوبايت أكثر من JavaScript لكل صفحة مقارنة بالتطبيق الأساسي.
• في وضع dynamic، يصل use-intl إلى 119.4 كيلوبايت، لكنه لا يزال يحمل تسرباً للصفحات بنسبة 89.8%.
• يظهر الفارق المعماري بوضوح في حجم المكونات: 76-87 كيلوبايت مع use-intl مقابل 6-8 كيلوبايت مع Intlayer.
• تبديل اللغة أسرع بمرتين إلى أربع مرات مع Intlayer (3 مللي ثانية مقابل 7-21 مللي ثانية).

الجدول الكامل في تقرير قياس أداء 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، اضبط dictionary.importMode: 'dynamic' في intlayer.config.ts. راجع دليل تحسين الحزمة.

تجربة المطور

مكون العميل (Client Component)

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

مكونات الخادم المتزامنة (Server Components)

غالباً ما تكون عناصر واجهة المستخدم المشتركة (شريط التنقل، التذييل، البطاقات) مكونات خادم تُعرض كأبناء لمكونات العميل، لذا لا يمكن أن تكون غير متزامنة (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" },
    },
  };
};

الاحتفاظ بـ API الخاص بـ next-intl مع مخرجات Intlayer

لا يتعين عليك إعادة كتابة مكوناتك للحصول على أرقام الأداء الموضحة أعلاه. حزمة @intlayer/next-intl هي محول متوافق مباشرة: يحتفظ بـ useTranslations وgetTranslations وuseFormatter وt.rich() وصيغ الجمع في ICU، ويقدمها من قواميس Intlayer التي يترجمها مترجم 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 كيلوبايت إلى 147.5 كيلوبايت لكل صفحة، ومن 21.8 كيلوبايت إلى 8.1 كيلوبايت لكل مكون، ومن تسرب يقارب 90% إلى 0%، مع بقاء كود التطبيق دون أي تعديل. ويمكن لملفات messages/{locale}.json الحالية أن تظل مصدر الحقيقة عبر إضافة مزامنة JSON.

راجع دليل الانتقال من next-intl لاتباع الخطوات التفصيلية.

متى تختار أياً منهما؟

الأسئلة الشائعة

مقارنات ذات صلة

نفس المقارنة المرجعية، مكتبات أخرى:

المزيد حول next-intl:

وثائق مرجعية:

لفهم أصل هذه المكتبات، اقرأ تاريخ i18n في JavaScript.

نجوم GitHub

تعد نجوم GitHub مؤشراً قوياً على شعبية المشروع وثقة المجتمع وأهميته على المدى الطويل.

نشاط الالتزامات (commits)

تعكس النجوم الشعبية، بينما تعكس الالتزامات حجم العمل المبذول في المشروع. عند كتابة هذا المقال، يضم Intlayer نحو 7,500 التزام، أي أكثر من معظم المكتبات المقارنة هنا، ونحو 5 أضعاف next-intl أو next-i18next.

Intlayer مستودع أحادي (monorepo)، لذا يشمل هذا العدد كل حزم أطر العمل وأداة CLI والتوثيق. اقرأ الالتزامات كمؤشر على النشاط، لا على الجودة.

تنزيلات npm

تكافئ أعداد التنزيل الحلول الأقدم، لا الأفضل. فالمكتبة التي صدرت قبل سنوات لا تزال تُثبَّت في كل مشروع اختارها آنذاك، وفي كل تشغيل لـ CI، وفي كل حزمة تعتمد عليها. هذا الرقم يقيس الجمود أكثر مما يقيس اختيارًا جديدًا.

تضخّم مساعدات الذكاء الاصطناعي هذا الأثر. فـ next-intl وi18next وvue-i18n منتشرة في الشيفرة التي تدربت عليها، لذا تقترحها افتراضيًا دون مقارنة البدائل. كل اقتراح يضيف تنزيلات، تغذي بدورها الاقتراح التالي. قارن بناءً على الاختبار المعياري لا على عدد التنزيلات.

الخاتمة

next-intl مكتبة قوية ومصانة جيداً، ويؤكد الاختبار أنها خيار جيد على Next.js. لكن نموذج الكتالوج المركزي يضع كل عبء التحسين على عاتق المطور: الإعداد البسيط يسرب نحو 90% من محتوى الصفحات الأخرى، ووقت التشغيل وحده يكلف +12.6 كيلوبايت gzip في كل صفحة.

ينقل Intlayer هذا العمل بأكمله إلى المترجم. القواميس لكل مكون، والتحميل الكسول لكل لغة، وتطهير المحتوى غير المستخدم تصبح جميعها مخرجات بناء تلقائية. والنتيجة على نفس التطبيق: +0.3 كيلوبايت لكل صفحة، 0% تسرب، ومكونات أصغر بـ 3 مرات، وتبديل لغة أسرع بمرتين إلى 4 مرات على TanStack Start.

جميع البيانات الأولية والتطبيقات وسيناريوهات الاختبار متاحة في مستودع Benchmark Bloom. يمكنك تشغيلها بنفسك.

راجع وثيقة 'لماذا Intlayer؟' لمزيد من التفاصيل.