Lingui VS Intlayer: Tolok Ukur Internasionalisasi (i18n) React & Next.js

Lingui dan Intlayer adalah dua pustaka dalam tolok ukur ini yang mengandalkan kompiler daripada runtime murni. Lingui mengekstrak pesan dari makro saat build time dan mengompilasi katalog per lokal. Intlayer mengompilasi kamus per komponen dan melakukan tree-shake per lokal. Di atas kertas keduanya seharusnya sebanding. Angka-angka berikut menunjukkan di mana keduanya berbeda.

Data berasal dari Benchmark Bloom, sebuah rangkaian pengujian sumber terbuka yang membangun aplikasi yang sama dengan masing-masing pustaka dan mencatat apa yang sebenarnya diunduh serta dieksekusi oleh peramban.

tl;dr: Lingui paling mendekati Intlayer dalam hal JavaScript mentah per halaman: 115-120 KB vs 118.6 KB pada TanStack Start setelah lazy loading dikonfigurasi, 148.6 KB vs 141.3 KB pada Next.js. Namun celah melebar di aspek lain: komponen Lingui yang dikompilasi secara terisolasi berukuran 58-153 KB dibandingkan 6-8 KB untuk Intlayer, hidrasi membutuhkan 28-34 ms dibandingkan 11-14 ms, fallback lokal sumber membocorkan 3-15% string en ke halaman fr di setiap pengaturan optimal, dan mencapai pengaturan optimal tersebut membutuhkan ekstraksi, kompilasi, serta pemilihan katalog secara manual per rute. Intlayer mencapainya tanpa konfigurasi tambahan.

Ringkasan

• Lingui - Berbasis makro ( t`...` , <Trans>, msg), ICU MessageFormat, katalog .po / JSON, alur kerja lingui extract + lingui compile. Mengompilasi ID pesan menjadi hash pendek, mendukung pemuatan katalog dinamis per lokal. Sangat mapan, agnostik kerangka kerja, dukungan ekosistem penerjemah yang kuat seputar file .po.
• Intlayer - Model konten yang berpusat pada komponen. Kamus .content.ts ditempatkan berdampingan dengan komponen yang dilayaninya, kompiler build-time melakukan tree-shake dan lazy-load per komponen dan per lokal, tipe TypeScript yang ketat dihasilkan dari konten Anda, dan terjemahan yang hilang gagal pada saat build. Menyertakan middleware terintegrasi, pembantu SEO, Visual Editor / CMS, dan terjemahan berbantuan AI.

Tampilkan semua isi tabel

Tampilkan semua isi tabel

Buka tabel dalam modal untuk melihat semua isi data dengan jelas

Pustaka	Bintang GitHub	Total Komit	Komit Terakhir	Versi Pertama	Versi NPM	Unduhan NPM
aymericzip/intlayer				April 2024
lingui/js-lingui				Des 2016

Lencana diperbarui secara otomatis. Cuplikan data akan bervariasi seiring waktu.

Perbandingan fitur berdampingan

Tolok ukur

Apa yang diukur

Rangkaian Benchmark Bloom membangun aplikasi yang sama dengan setiap pustaka: 10 halaman (home, about, blog, careers, contact, FAQ, pricing, products, settings, team), 10 lokal (en, fr, es, de, it, pt, zh, ja, ko, ru), komponen identik, dan konten identik. Halaman diukur dalam en dan fr. Setiap pustaka diuji hingga empat strategi pemuatan, dari konfigurasi paling sederhana hingga optimal:

Intlayer tidak memerlukan varian "scoped": kompiler otomatis membatasi konten per komponen, sehingga baris static dan dynamic sudah ter-scope secara bawaan.

Untuk setiap build, pengujian mencatat:

• Ukuran pustaka (Lib size): ukuran gzip dari komponen kosong yang hanya mengimpor pustaka i18n. Biaya tetap runtime.
• JS Halaman (Page JS): JavaScript terkompresi gzip per halaman, dirata-ratakan di seluruh halaman dan lokal.
• % kebocoran lokal (Locale leak %): proporsi string terjemahan dalam JS terunduh yang berasal dari lokal yang tidak sedang dilihat pengguna (diuji pada en dan fr, sehingga 50% berarti "lokal terukur lainnya ada sepenuhnya"; dengan 10 lokal terbundel, pemborosan sebenarnya jauh lebih tinggi).
• % kebocoran halaman (Page leak %): proporsi string terjemahan dalam JS terunduh yang berasal dari halaman yang tidak sedang diakses pengguna.
• Rata-rata komponen (Component avg): ukuran gzip rata-rata dari setiap komponen yang dikompilasi secara terisolasi. Menunjukkan seberapa besar runtime i18n dan katalog yang diseret oleh satu komponen.
• Reaktivitas E2E: waktu antara memilih lokal baru hingga pembaruan html[lang] di DOM (Playwright, 5 iterasi).
• Hidrasi: durasi fase hidrasi React.

Angka-angka di bawah ini berasal dari pengujian tanggal 2026-09-12 menggunakan @lingui/react 6.6.0 dan intlayer 9.5.1. Aplikasi pengujian sengaja dibuat kecil (beberapa lusin string per lokal), sehingga persentase kebocoran menggambarkan sebuah pola: angka ini meningkat seiring bertambahnya konten Anda sementara biaya runtime tetap konstan.

Hasil pada Next.js

Pilih metrik dan pustaka yang Anda minati:

Cara membaca hasil

• Biaya runtime. Komponen kosong membutuhkan 11.9 KB gzip dengan Lingui, dibandingkan 5.5 KB dengan Intlayer. Pada halaman penuh, konfigurasi terbaik Lingui berada pada +7.3 KB di atas Intlayer (148.6 vs 141.3 KB); Intlayer hanya bertambah +0.3 KB di atas aplikasi dasar.
• Konfigurasi sederhana berbiaya mahal. Memuat setiap katalog terkompilasi di awal menghasilkan 207.4 KB per halaman, +66 KB di atas aplikasi dasar. Setengah dari string yang diuji berasal dari lokal yang salah, dan 90% dari halaman yang salah.
• Pemuatan dinamis memperbaiki lokal, bukan halaman. Dengan satu katalog per lokal, kebocoran halaman tetap berada pada ~90%: seluruh katalog fr dikirimkan pada setiap halaman berbahasa Prancis. Untuk mencapai 0% kebocoran halaman, diperlukan pengaturan scoped-dynamic: satu katalog per rute, diekstrak dan dikompilasi secara terpisah, serta dipilih secara manual pada setiap halaman.
• Fallback lokal sumber bocor. Bahkan dalam pengaturan yang dioptimalkan, 3-15% string en tetap terkirim di dalam halaman fr. Makro Lingui menjaga pesan sumber tetap tersedia sebagai fallback, sehingga ikut masuk ke dalam bundle bersama terjemahan. Intlayer menyelesaikan fallback pada saat build dan hanya mengirimkan lokal yang aktif.
• Ukuran komponen membengkak pada scoped-dynamic. Setiap komponen yang dikompilasi secara terisolasi rata-rata berukuran 152.6 KB, karena katalog setiap rute dapat diakses dari komponen yang mengimpornya. Komponen yang sama dengan useIntlayer() hanya berukuran rata-rata 6.9 KB.

Tabel lengkap, setiap pustaka dan setiap strategi, dalam laporan tolok ukur Next.js.

Hasil pada TanStack Start

Cara membaca hasil

• Dalam hal JavaScript per halaman, Lingui unggul tipis. dynamic Lingui mencapai 115.2 KB, 3.4 KB di bawah Intlayer (118.6 KB). Katalog terkompilasi Lingui dengan hash ID sangat ringkas, dan router TanStack Start membagi rute dengan sangat baik sehingga kebocoran halaman sudah 0% pada baris dynamic.
• Segala hal lainnya berpihak pada Intlayer. Hidrasi membutuhkan waktu 28-34 ms pada Lingui berbanding 11-14 ms pada Intlayer: i18n.load() + i18n.activate() dijalankan di klien sebelum React dapat melakukan hidrasi. Komponen yang dikompilasi secara terisolasi berukuran 58-148 KB berbanding 6-8 KB. Kebocoran lokal tidak pernah mencapai 0% (4-9%) karena fallback lokal sumber.
• Pergantian lokal pada pengaturan teroptimasi berlangsung lambat. scoped-dynamic Lingui membutuhkan waktu 42 ms untuk memperbarui html[lang]: katalog rute baru harus diambil, dimuat, dan diaktifkan sebelum perubahan terlihat. Intlayer beralih dalam 3-4 ms pada kedua mode.
• Baris static Intlayer sudah memiliki 0% kebocoran halaman karena hanya kamus yang diimpor oleh komponen halaman yang dibundel. Satu baris konfigurasi (importMode: 'dynamic') menghapus kebocoran lokal juga.
• @intlayer/lingui mempertahankan sintaks makro Lingui dan menyajikannya dari kamus Intlayer. Pendekatan ini mengorbankan sedikit ukuran halaman (137 KB, karena runtime makro tetap ada) demi komponen yang lebih kecil (12.8 KB) dan hidrasi yang lebih cepat daripada Lingui bawaan. Ini adalah langkah migrasi, bukan tujuan akhir.

Tabel lengkap dalam laporan tolok ukur TanStack Start.

Mengapa ada perbedaan? Dua kompiler, dua unit kerja

Kedua pustaka melakukan kompilasi. Perbedaannya terletak pada apa yang mereka kompilasi.

Lingui mengompilasi katalog. Makro dalam kode sumber Anda diekstrak ke dalam file .po per lokal, lalu dikompilasi menjadi modul JS per lokal. Unit kerjanya adalah lokal. Membaginya lebih lanjut, berdasarkan rute atau komponen, berarti membuat beberapa katalog, mengonfigurasi lingui.config.ts untuk mengekstrak masing-masing dari kumpulan file yang berbeda, dan memuat katalog yang tepat di setiap rute. Instans runtime I18n bersifat global; setiap pemanggilan useLingui() menghubungkan komponen ke instans tersebut.

.
├── lingui.config.ts
└── src
    ├── i18n.ts                          # setupI18n(), load(), activate()
    ├── locales
    │   ├── en
    │   │   ├── messages.po
    │   │   └── messages.mjs             # output lingui compile
    │   └── fr
    │       ├── messages.po
    │       └── messages.mjs
    ├── components
    │   └── Counter.tsx                  # const { t } = useLingui(); t`Increment`
    └── routes
        └── $locale
            └── about.tsx                # await import(`../locales/${locale}/messages.mjs`)

Intlayer mengompilasi kamus. Setiap file .content.ts adalah kamus yang terikat pada sebuah kunci; kompiler mencari tahu komponen mana yang mengimpor kunci tersebut dan menghasilkan, per kamus dan per lokal, tepatnya JSON yang dibutuhkan komponen tersebut. Unit kerjanya adalah komponen. Pembatasan rute adalah konsekuensi alaminya: suatu halaman hanya menarik kamus dari komponen yang direndernya.

.
├── intlayer.config.ts
└── src
    ├── components
    │   └── Counter
    │       ├── index.tsx                # useIntlayer("counter")
    │       └── index.content.ts
    └── routes
        └── $locale
            ├── about.tsx
            └── about.content.ts

Itulah mengapa pola scoped-dynamic adalah output bawaan bagi Intlayer dan merupakan proyek konfigurasi manual yang rumit bagi Lingui. Kesenjangan melebar pada dua sumbu sekaligus, halaman dan bahasa:

Untuk mendapatkan angka pada baris dynamic, atur dictionary.importMode: 'dynamic' di intlayer.config.ts. Lihat panduan optimasi bundle.

Pengalaman pengembang

Pengaturan

import { defineConfig } from "@lingui/cli";

export default defineConfig({
  sourceLocale: "en",
  locales: ["en", "fr"],
  catalogs: [
    {
      path: "<rootDir>/src/locales/{locale}/messages",
      include: ["src"],
    },
  ],
});

import { setupI18n } from "@lingui/core";

export const loadCatalog = async (locale: string) => {
  const { messages } = await import(`./locales/${locale}/messages.mjs`);
  const i18n = setupI18n();
  i18n.load(locale, messages);
  i18n.activate(locale);
  return i18n;
};

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

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

export default config;

Komponen

import { useState } from "react";
import { useLingui } from "@lingui/react/macro";
import { Trans } from "@lingui/react/macro";

export const Counter = () => {
  const { t, i18n } = useLingui();
  const [count, setCount] = useState(0);

  return (
    <div>
      <p>{i18n.number(count)}</p>
      <button aria-label={t`Counter`} onClick={() => setCount((c) => c + 1)}>
        <Trans>Increment</Trans>
      </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;

import { useState } from "react";
import { useIntlayer } from "react-intlayer";
import { useNumber } from "react-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>
  );
};

Di luar komponen

Metadata, loader, fungsi server: di mana saja tanpa hierarki React.

import { setupI18n } from "@lingui/core";
import { msg } from "@lingui/core/macro";

const title = msg`About us`;

export const loader = async ({ params }: { params: { locale: string } }) => {
  const { messages } = await import(
    `../../locales/${params.locale}/messages.mjs`
  );
  const i18n = setupI18n({
    locale: params.locale,
    messages: { [params.locale]: messages },
  });

  return { title: i18n._(title) };
};

import { getIntlayer } from "intlayer";

export const loader = async ({ params }: { params: { locale: string } }) => {
  const { title } = getIntlayer("about-metadata", params.locale);

  return { title };
};

Pertahankan makro Lingui, dapatkan kamus Intlayer

@intlayer/lingui adalah adaptor pengganti langsung untuk @lingui/core dan @lingui/react. Makro tetap dikompilasi seperti biasa; pemanggilan runtime i18n._() yang dihasilkannya disajikan langsung dari kamus Intlayer, dengan plugin sinkronisasi .po yang menjaga katalog lama Anda tetap sinkron. Bentuk jamak dan seleksi ICU dirender secara identik.

import { defineConfig } from "vite";
import { lingui } from "@intlayer/lingui/plugin";

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

Biarkan @lingui/babel-plugin-lingui-macro / @lingui/swc-plugin tetap berada dalam pipeline build sebelum kompiler Intlayer. Lihat dokumentasi kompatibilitas Lingui.

Kapan harus memilih yang mana?

FAQ

Perbandingan terkait

Tolok ukur yang sama, pustaka lain:

Lebih lanjut:

Dokumen referensi:

Untuk memahami asal-usul pustaka-pustaka ini, baca sejarah i18n di JavaScript.

Bintang GitHub

Bintang GitHub adalah indikator kuat dari popularitas proyek, kepercayaan komunitas, dan relevansi jangka panjang. Meskipun bukan pengukuran langsung terhadap kualitas teknis, metrik ini mencerminkan berapa banyak pengembang yang menganggap proyek ini bermanfaat dan mengikutinya.

Aktivitas commit

Bintang menunjukkan popularitas. Commit menunjukkan seberapa banyak kerja yang masuk ke sebuah proyek. Saat tulisan ini dibuat, Intlayer memiliki sekitar 7.500 commit, lebih banyak dari sebagian besar library yang dibandingkan di sini, dan sekitar 5 kali lebih banyak dari next-intl atau next-i18next.

Intlayer adalah monorepo, jadi jumlah ini mencakup setiap paket framework, CLI, dan dokumentasi. Baca commit sebagai sinyal aktivitas, bukan kualitas.

Unduhan npm

Jumlah unduhan menghargai solusi yang paling lama, bukan yang terbaik. Library yang dirilis bertahun-tahun lalu masih diinstal oleh setiap proyek yang memilihnya saat itu, oleh setiap eksekusi CI, dan oleh setiap paket yang bergantung padanya. Angka ini lebih mengukur inersia daripada pilihan baru.

Asisten AI memperkuat efek ini. next-intl, i18next, dan vue-i18n ada di mana-mana dalam kode yang menjadi data latih mereka, sehingga mereka menyarankannya secara default tanpa membandingkan alternatif. Setiap saran menambah unduhan, yang kemudian mendorong saran berikutnya. Bandingkan berdasarkan benchmark, bukan jumlah unduhan.

Kesimpulan

Lingui adalah pustaka kombinasi runtime dan kompiler terkuat dalam tolok ukur ini. Katalog terkompilasi dengan hash ID memberikan efisiensi JavaScript per halaman yang hampir menyamai Intlayer, bahkan sedikit lebih kecil di TanStack Start. Jika ukuran bita per halaman adalah satu-satunya ukuran, keduanya akan seri.

Namun, bukan hanya itu yang penting. Kompiler Lingui hanya memproses hingga tingkat lokal; semua hal di bawahnya (katalog per rute, lazy loading, mencegah fallback bocor ke dalam bundle) adalah pekerjaan konfigurasi manual. Tolok ukur memperlihatkan biaya dari batasan tersebut: komponen 10-20x lebih besar, hidrasi 2-3x lebih lambat, kebocoran lokal 3-15% yang selalu ada, dan pergantian lokal memakan waktu 42 ms pada pengaturan optimal. Kompiler Intlayer bekerja pada tingkat komponen, sehingga angka-angka tersebut adalah 6-8 KB, 11-14 ms, 0%, dan 3-4 ms tanpa perlu konfigurasi tambahan.

Semua data mentah, aplikasi pengujian, dan skrip tersedia di repositori Benchmark Bloom. Anda dapat menjalankannya sendiri.

Lihat dokumen 'Mengapa Intlayer?' untuk informasi lebih lanjut.