@intlayer/docs 8.9.4-canary.0 → 8.9.5

package/docs/hi/plugins/sync-po.md

@@ -0,0 +1,333 @@
+---
+createdAt: 2026-05-10
+updatedAt: 2026-05-10
+title: Sync PO प्लगइन
+description: Intlayer शब्दकोशों को Gettext PO फ़ाइलों के साथ सिंक करें। अपने संदेशों को प्रबंधित करने, अनुवाद करने और परीक्षण करने के लिए Intlayer का उपयोग करते हुए अपने मौजूदा i18n को बनाए रखें।
+keywords:
+  - Intlayer
+  - Sync PO
+  - Gettext
+  - i18n
+  - अनुवाद
+slugs:
+  - doc
+  - plugin
+  - sync-po
+youtubeVideo: https://www.youtube.com/watch?v=MpGMxniDHNg
+history:
+  - version: 8.9.4
+    date: 2026-05-10
+    changes: "Sync PO प्लगइन का प्रारंभिक दस्तावेज़ीकरण"
+---
+
+# Sync PO (i18n ब्रिज) - ICU / i18next समर्थन के साथ Sync PO
+
+अपने मौजूदा i18n स्टैक के ऐड-ऑन के रूप में Intlayer का उपयोग करें। यह प्लगइन आपके Gettext PO संदेशों को Intlayer शब्दकोशों के साथ सिंक में रखता है ताकि आप:
+
+- अपने मौजूदा PO-आधारित अनुवाद वर्कफ़्लो को बनाए रख सकें।
+- अपने ऐप को रिफैक्टर किए बिना Intlayer (CLI, CI, प्रदाता, CMS) के साथ अपने संदेशों को प्रबंधित और अनुवाद कर सकें।
+- प्रत्येक पारिस्थितिकी तंत्र को लक्षित करते हुए ट्यूटोरियल और SEO सामग्री भेज सकें, जबकि Intlayer को PO प्रबंधन परत के रूप में सुझा सकें।
+
+नोट्स और वर्तमान दायरा:
+
+- CMS के लिए बाहरीकरण अनुवादों और क्लासिक टेक्स्ट के लिए काम करता है।
+- PO प्रविष्टियों के भीतर प्रविष्टि, बहुवचन/ICU, या अन्य पुस्तकालयों की उन्नत रनटाइम सुविधाओं के लिए अभी तक कोई समर्थन नहीं है।
+- विज़ुअल एडिटर अभी तक तृतीय-पक्ष i18n आउटपुट के लिए समर्थित नहीं है।
+
+### इस प्लगइन का उपयोग कब करें
+
+- आप पहले से ही अपने अनुवादों के लिए Gettext PO फ़ाइलों का उपयोग करते हैं।
+- आप अपने रेंडरिंग रनटाइम को बदले बिना AI-सहायता प्राप्त फिल, CI में टेस्ट और कंटेंट ऑप्स चाहते हैं।
+
+## इंस्टॉलेशन
+
+```bash
+pnpm add -D @intlayer/sync-po-plugin
+# या
+npm i -D @intlayer/sync-po-plugin
+```
+
+## प्लगइन्स
+
+यह पैकेज दो प्लगइन्स प्रदान करता है:
+
+- `loadPO`: Intlayer शब्दकोशों में PO फ़ाइलें लोड करें।
+  - इस प्लगइन का उपयोग स्रोत से PO फ़ाइलों को लोड करने के लिए किया जाता है और इसे Intlayer शब्दकोशों में लोड किया जाएगा। यह पूरे कोडबेस को स्कैन कर सकता है और विशिष्ट PO फ़ाइलों को खोज सकता है।
+    इस प्लगइन का उपयोग किया जा सकता है:
+    - यदि आप एक i18n लाइब्रेरी का उपयोग करते हैं जो आपकी PO फ़ाइलों को लोड करने के लिए एक विशिष्ट स्थान लागू करती है, लेकिन आप अपनी सामग्री घोषणा को अपने कोड बेस में जहां चाहें वहां रखना चाहते हैं।
+    - इसका उपयोग तब भी किया जा सकता है जब आप रिमोट स्रोत (जैसे: CMS, एक API, आदि) से अपने संदेश प्राप्त करना चाहते हैं और अपने संदेशों को PO फ़ाइलों में संग्रहीत करना चाहते हैं।
+
+  > हुड के तहत, यह प्लगइन पूरे कोडबेस को स्कैन करेगा और विशिष्ट PO फ़ाइलों को खोजेगा और उन्हें Intlayer शब्दकोशों में लोड करेगा।
+  > ध्यान दें कि यह प्लगइन आउटपुट और अनुवादों को वापस PO फ़ाइलों में नहीं लिखेगा।
+
+- `syncPO`: Intlayer शब्दकोशों के साथ PO फ़ाइलों को सिंक्रनाइज़ करें।
+  - इस प्लगइन का उपयोग Intlayer शब्दकोशों के साथ PO फ़ाइलों को सिंक्रनाइज़ करने के लिए किया जाता है। यह दिए गए स्थान को स्कैन कर सकता है और विशिष्ट PO फ़ाइलों के पैटर्न से मेल खाने वाले PO को लोड कर सकता है। यदि आप दूसरी i18n लाइब्रेरी का उपयोग करते हुए Intlayer के लाभ प्राप्त करना चाहते हैं तो यह प्लगइन उपयोगी है।
+
+## दोनों प्लगइन्स का उपयोग करना
+
+```ts fileName="intlayer.config.ts"
+import { Locales, type IntlayerConfig } from "intlayer";
+import { loadPO, syncPO } from "@intlayer/sync-po-plugin";
+
+const config: IntlayerConfig = {
+  internationalization: {
+    locales: [Locales.ENGLISH, Locales.FRENCH, Locales.SPANISH],
+    defaultLocale: Locales.ENGLISH,
+  },
+
+  // अपनी वर्तमान PO फ़ाइलों को Intlayer शब्दकोशों के साथ सिंक में रखें
+  plugins: [
+    /**
+     * src में उन सभी PO फ़ाइलों को लोड करेगा जो {key}.i18n.po पैटर्न से मेल खाती हैं
+     */
+    loadPO({
+      source: ({ key }) => `./src/**/${key}.i18n.po`,
+      locale: Locales.ENGLISH,
+      priority: 1, // यह सुनिश्चित करता है कि ये PO फ़ाइलें `./locales/en/${key}.po` की फ़ाइलों पर प्राथमिकता लें
+    }),
+    /**
+     * लोड करेगा, और आउटपुट और अनुवादों को वापस locales निर्देशिका में PO फ़ाइलों में लिखेगा
+     */
+    syncPO({
+      source: ({ key, locale }) => `./locales/${locale}/${key}.po`,
+      priority: 0,
+    }),
+  ],
+};
+
+export default config;
+```
+
+## `syncPO` प्लगइन
+
+### त्वरित शुरुआत
+
+प्लगइन को अपने `intlayer.config.ts` में जोड़ें और इसे अपनी मौजूदा PO संरचना पर इंगित करें।
+
+```ts fileName="intlayer.config.ts"
+import { Locales, type IntlayerConfig } from "intlayer";
+import { syncPO } from "@intlayer/sync-po-plugin";
+
+const config: IntlayerConfig = {
+  internationalization: {
+    locales: [Locales.ENGLISH, Locales.FRENCH, Locales.SPANISH],
+    defaultLocale: Locales.ENGLISH,
+  },
+
+  // अपनी वर्तमान PO फ़ाइलों को Intlayer शब्दकोशों के साथ सिंक में रखें
+  plugins: [
+    syncPO({
+      // प्रति-लोकेल, प्रति-नेमस्पेस लेआउट
+      source: ({ key, locale }) => `./locales/${locale}/${key}.po`,
+    }),
+  ],
+};
+
+export default config;
+```
+
+वैकल्पिक: प्रति लोकेल एकल फ़ाइल:
+
+```ts fileName="intlayer.config.ts"
+import { Locales, type IntlayerConfig } from "intlayer";
+import { syncPO } from "@intlayer/sync-po-plugin";
+
+const config: IntlayerConfig = {
+  internationalization: {
+    locales: [Locales.ENGLISH, Locales.FRENCH],
+    defaultLocale: Locales.ENGLISH,
+  },
+  plugins: [
+    syncPO({
+      source: ({ locale }) => `./locales/${locale}.po`,
+    }),
+  ],
+};
+
+export default config;
+```
+
+#### यह कैसे काम करता है
+
+- पढ़ें: प्लगइन आपके `source` बिल्डर से PO फ़ाइलों की खोज करता है और उन्हें Intlayer शब्दकोशों के रूप में लोड करता है।
+- लिखें: बिल्ड और फिल के बाद, यह स्थानीयकृत PO को वापस उन्हीं पथों पर लिखता है (उचित Gettext हेडर के साथ)।
+- ऑटो-फिल: प्लगइन प्रत्येक शब्दकोश के लिए एक `autoFill` पथ घोषित करता है। `intlayer fill` चलाने से डिफ़ॉल्ट रूप से आपकी PO फ़ाइलों में केवल गायब अनुवाद अपडेट होते हैं।
+
+API:
+
+```ts
+syncPO({
+  source: ({ key, locale }) => string, // आवश्यक
+  location?: string, // वैकल्पिक लेबल, डिफ़ॉल्ट: "sync-po::path/to/source"
+  priority?: number, // संघर्ष समाधान के लिए वैकल्पिक प्राथमिकता, डिफ़ॉल्ट: 0
+});
+```
+
+### एकाधिक PO स्रोत और प्राथमिकता
+
+आप विभिन्न PO स्रोतों को सिंक्रनाइज़ करने के लिए एकाधिक `syncPO` प्लगइन्स जोड़ सकते हैं। यह तब उपयोगी होता है जब आपके प्रोजेक्ट में कई अनुवाद स्रोत या अलग-अलग PO संरचनाएं हों।
+
+#### प्राथमिकता प्रणाली
+
+जब कई प्लगइन्स एक ही शब्दकोश कुंजी को लक्षित करते हैं, तो `priority` पैरामीटर यह निर्धारित करता है कि कौन सा प्लगइन प्राथमिकता लेता है:
+
+- उच्च प्राथमिकता संख्याएँ कम प्राथमिकता वाली संख्याओं पर जीतती हैं
+- `.content` फ़ाइलों की डिफ़ॉल्ट प्राथमिकता `0` है
+- प्लगइन्स की डिफ़ॉल्ट प्राथमिकता `0` है
+- समान प्राथमिकता वाले प्लगइन्स को कॉन्फ़िगरेशन में दिखाई देने वाले क्रम में संसाधित किया जाता है
+
+```ts fileName="intlayer.config.ts"
+import { Locales, type IntlayerConfig } from "intlayer";
+import { syncPO } from "@intlayer/sync-po-plugin";
+
+const config: IntlayerConfig = {
+  internationalization: {
+    locales: [Locales.ENGLISH, Locales.FRENCH],
+    defaultLocale: Locales.ENGLISH,
+  },
+
+  plugins: [
+    // प्राथमिक PO स्रोत (उच्चतम प्राथमिकता)
+    syncPO({
+      source: ({ key, locale }) => `./locales/${locale}/${key}.po`,
+      location: "main-translations",
+      priority: 10,
+    }),
+
+    // फॉलबैक PO स्रोत (कम प्राथमिकता)
+    syncPO({
+      source: ({ locale }) => `./fallback-locales/${locale}.po`,
+      location: "fallback-translations",
+      priority: 5,
+    }),
+
+    // लीगेसी PO स्रोत (सबसे कम प्राथमिकता)
+    syncPO({
+      source: ({ locale }) => `/my/other/app/legacy/${locale}/messages.po`,
+      location: "legacy-translations",
+      priority: 1,
+    }),
+  ],
+};
+
+export default config;
+```
+
+## Load PO प्लगइन
+
+### त्वरित शुरुआत
+
+मौजूदा PO फ़ाइलों को Intlayer शब्दकोशों के रूप में प्राप्त करने के लिए प्लगइन को अपने `intlayer.config.ts` में जोड़ें। यह प्लगइन केवल पढ़ने के लिए है (डिस्क पर कोई लेखन नहीं):
+
+```ts fileName="intlayer.config.ts"
+import { Locales, type IntlayerConfig } from "intlayer";
+import { loadPO } from "@intlayer/sync-po-plugin";
+
+const config: IntlayerConfig = {
+  internationalization: {
+    locales: [Locales.ENGLISH, Locales.FRENCH, Locales.SPANISH],
+    defaultLocale: Locales.ENGLISH,
+  },
+
+  plugins: [
+    // अपने स्रोत ट्री में कहीं भी स्थित PO संदेशों को प्राप्त करें
+    loadPO({
+      source: ({ key }) => `./src/**/${key}.i18n.po`,
+      // प्रति प्लगइन इंस्टेंस एक एकल लोकेल लोड करें (कॉन्फ़िगरेशन defaultLocale के लिए डिफ़ॉल्ट)
+      locale: Locales.ENGLISH,
+      priority: 0,
+    }),
+  ],
+};
+
+export default config;
+```
+
+वैकल्पिक: प्रति-लोकेल लेआउट, अभी भी केवल-पढ़ने के लिए (केवल चयनित लोकेल लोड किया गया है):
+
+```ts fileName="intlayer.config.ts"
+import { Locales, type IntlayerConfig } from "intlayer";
+import { loadPO } from "@intlayer/sync-po-plugin";
+
+const config: IntlayerConfig = {
+  internationalization: {
+    locales: [Locales.ENGLISH, Locales.FRENCH],
+    defaultLocale: Locales.ENGLISH,
+  },
+  plugins: [
+    loadPO({
+      // इस पैटर्न से केवल Locales.FRENCH के लिए फ़ाइलें प्राप्त की जाएंगी
+      source: ({ key, locale }) => `./locales/${locale}/${key}.po`,
+      locale: Locales.FRENCH,
+    }),
+  ],
+};
+
+export default config;
+```
+
+### यह कैसे काम करता है
+
+- खोज: आपके `source` बिल्डर से एक ग्लब बनाता है और मिलान करने वाली PO फ़ाइलें एकत्र करता है।
+- प्राप्ति: प्रत्येक PO फ़ाइल को प्रदान किए गए `locale` के साथ Intlayer शब्दकोश के रूप में लोड करता है।
+- केवल-पढ़ने के लिए: आउटपुट फ़ाइलों को लिखता या प्रारूपित नहीं करता है; यदि आपको राउंड-ट्रिप सिंक की आवश्यकता है तो `syncPO` का उपयोग करें।
+- ऑटो-फिल तैयार: एक `fill` पथ परिभाषित करता है ताकि `intlayer content fill` गायब कुंजियों को पॉप्युलेट कर सके।
+
+### API
+
+```ts
+loadPO({
+  // आपके PO के पथ बनाएं। `locale` वैकल्पिक है यदि आपकी संरचना में कोई लोकेल सेगमेंट नहीं है
+  source: ({ key, locale }) => string,
+
+  // इस प्लगइन इंस्टेंस द्वारा लोड किए गए शब्दकोशों के लिए लक्षित लोकेल
+  // कॉन्फ़िगरेशन configuration.internationalization.defaultLocale के लिए डिफ़ॉल्ट
+  locale?: Locale,
+
+  // स्रोत की पहचान करने के लिए वैकल्पिक लेबल
+  location?: string, // डिफ़ॉल्ट: "plugin"
+
+  // अन्य स्रोतों के खिलाफ संघर्ष समाधान के लिए उपयोग की जाने वाली प्राथमिकता
+  priority?: number, // डिफ़ॉल्ट: 0
+});
+```
+
+### व्यवहार और परंपराएं
+
+- यदि आपके `source` मास्क में लोकेल प्लेसहोल्डर शामिल है, तो केवल चयनित `locale` की फ़ाइलें प्राप्त की जाती हैं।
+- यदि आपके मास्क में कोई `{key}` सेगमेंट नहीं है, तो डिक्शनरी कुंजी "index" है।
+- कुंजियाँ आपके `source` बिल्डर में `{key}` प्लेसहोल्डर को प्रतिस्थापित करके फ़ाइल पथों से ली गई हैं।
+- प्लगइन केवल खोजी गई फ़ाइलों का उपयोग करता है और गायब लोकेल या कुंजियों का निर्माण नहीं करता है।
+- `fill` पथ आपके `source` से अनुमानित है और जब आप ऑप्ट-इन करते हैं तो CLI के माध्यम से गायब मानों को अपडेट करने के लिए उपयोग किया जाता है।
+
+## संघर्ष समाधान
+
+जब एक ही अनुवाद कुंजी कई PO स्रोतों में मौजूद होती है:
+
+1. उच्चतम प्राथमिकता वाला प्लगइन अंतिम मान निर्धारित करता है
+2. गायब कुंजियों के लिए निम्न प्राथमिकता स्रोतों का उपयोग फॉलबैक के रूप में किया जाता है
+3. यह आपको नई संरचनाओं में धीरे-धीरे माइग्रेट करते हुए लीगेसी अनुवादों को बनाए रखने की अनुमति देता है
+
+## CLI
+
+सिंक्रनाइज़ की गई PO फ़ाइलों को अन्य `.content` फ़ाइलों की तरह माना जाएगा। इसका मतलब है, सिंक्रनाइज़ की गई PO फ़ाइलों के लिए सभी intlayer कमांड उपलब्ध होंगे। इसमें शामिल हैं:
+
+- गायब अनुवाद हैं या नहीं, यह परीक्षण करने के लिए `intlayer content test`
+- सिंक्रनाइज़ की गई PO फ़ाइलों को सूचीबद्ध करने के लिए `intlayer content list`
+- गायब अनुवादों को भरने के लिए `intlayer content fill`
+- सिंक्रनाइज़ की गई PO फ़ाइलों को पुश करने के लिए `intlayer content push`
+- सिंक्रनाइज़ की गई PO फ़ाइलों को पुल करने के लिए `intlayer content pull`
+
+अधिक जानकारी के लिए [Intlayer CLI](https://github.com/aymericzip/intlayer/blob/main/docs/docs/en/cli/index.md) देखें।
+
+## सीमाएँ (वर्तमान)
+
+- तृतीय-पक्ष पुस्तकालयों को लक्षित करते समय कोई प्रविष्टि या बहुवचन/ICU समर्थन नहीं।
+- विज़ुअल एडिटर अभी तक गैर-Intlayer रनटाइम के लिए उपलब्ध नहीं है।
+- केवल PO सिंक्रनाइज़ेशन; गैर-PO कैटलॉग प्रारूप समर्थित नहीं हैं।
+
+## यह क्यों मायने रखता है
+
+- हम स्थापित i18n समाधानों की सिफारिश कर सकते हैं और Intlayer को ऐड-ऑन के रूप में स्थान दे सकते हैं।
+- हम उनके SEO/कीवर्ड्स का लाभ उठाते हैं ट्यूटोरियल्स के साथ जो PO को प्रबंधित करने के लिए Intlayer का सुझाव देते हुए समाप्त होते हैं।
+- लक्षित दर्शकों को "नए प्रोजेक्ट" से "i18n का उपयोग करने वाली किसी भी टीम" तक विस्तारित करता है।

package/docs/id/benchmark/index.md

@@ -30,6 +30,3 @@ Laporan terperinci dan dokumentasi teknis untuk setiap framework tersedia di baw
 - [**Vue Benchmark Report**](https://github.com/aymericzip/intlayer/blob/main/docs/docs/en/benchmark/vue.md)
 - [**Solid Benchmark Report**](https://github.com/aymericzip/intlayer/blob/main/docs/docs/en/benchmark/solid.md)
 - [**Svelte Benchmark Report**](https://github.com/aymericzip/intlayer/blob/main/docs/docs/en/benchmark/svelte.md)
-- [**Vue Benchmark Report**](https://github.com/aymericzip/intlayer/blob/main/docs/docs/en/benchmark/vue.md)
-- [**Solid Benchmark Report**](https://github.com/aymericzip/intlayer/blob/main/docs/docs/en/benchmark/solid.md)
-- [**Svelte Benchmark Report**](https://github.com/aymericzip/intlayer/blob/main/docs/docs/en/benchmark/svelte.md)

package/docs/id/benchmark/nextjs.md

@@ -61,6 +61,13 @@ Karena masalah ini sulit, banyak solusi tersedia—beberapa berfokus pada DX (De
 
 Intlayer mencoba mengoptimalkan di semua dimensi ini.
 
+## TL;DR
+
+- **Intlayer** & **next-translate**: Pilihan terbaik untuk performa Next.js, menawarkan footprint terkecil dan dukungan render statis terbaik.
+- **next-intl**: Opsi paling tren, tetapi berat dan kompleks untuk dioptimalkan bagi aplikasi besar.
+- **next-i18next**: Populer dan kaya plugin, tetapi membawa beban bundle yang signifikan (~3× Intlayer).
+- **Hindari**: **gt-next** dan **lingo.dev** karena masalah performa yang parah, ketergantungan pada vendor (vendor lock-in), dan bug yang merusak build.
+
 ## Uji aplikasi Anda
 
 Untuk mengungkap masalah ini, saya membangun pemindai gratis yang dapat Anda coba [di sini](https://intlayer.org/i18n-seo-scanner).
@@ -99,14 +106,14 @@ Terakhir, `Intlayer` menerapkan optimisasi waktu build sehingga `useIntlayer('ku
 Untuk benchmark ini, kami membandingkan library berikut:
 
 - `Base App` (Tanpa library i18n)
-- `next-intlayer` (v8.7.5)
+- `next-intlayer` (v8.7.12)
 - `next-i18next` (v16.0.5)
 - `next-intl` (v4.9.1)
 - `@lingui/core` (v5.3.0)
 - `next-translate` (v3.1.2)
 - `next-international` (v1.3.1)
 - `@inlang/paraglide-js` (v2.15.1)
-- `tolgee` (v7.0.0)
+- `@tolgee/react` (v7.0.0)
 - `@lingo.dev/compiler` (v0.4.0)
 - `wuchale` (v0.22.11)
 - `gt-next` (v6.16.5)
@@ -161,10 +168,10 @@ Masalah yang ditemui:
 
 **(General Translation)** (`gt-next@6.16.5`):
 
-- Untuk aplikasi 110kb, `gt-react` menambahkan lebih dari 440kb ekstra.
+- Untuk aplikasi 110kb, `gt-next` menambahkan lebih dari 440kb ekstra.
 - `Quota Exceeded, please upgrade your plan` pada build pertama dengan General Translation.
 - Terjemahan tidak dirender; saya mendapatkan error `Error: <T> used on the client-side outside of <GTProvider>`, yang tampaknya merupakan bug pada library.
-- Saat menerapkan **gt-tanstack-start-react**, saya juga menemukan [masalah](https://github.com/generaltranslation/gt/issues/1210#event-24510646961) dengan library tersebut: `does not provide an export named 'printAST' - @formatjs/icu-messageformat-parser`, yang membuat aplikasi rusak. Setelah melaporkan masalah ini, pengelola memperbaikinya dalam waktu 24 jam.
+- Saat menerapkan **gt-next**, saya juga menemukan [masalah](https://github.com/generaltranslation/gt/issues/1210#event-24510646961) dengan library tersebut: `does not provide an export named 'printAST' - @formatjs/icu-messageformat-parser`, yang membuat aplikasi rusak. Setelah melaporkan masalah ini, pengelola memperbaikinya dalam waktu 24 jam.
 - Library ini memblokir rendering statis halaman Next.js.
 
 **(Lingo.dev)** (`@lingo.dev/compiler@0.4.0`):
@@ -186,9 +193,11 @@ Ide di balik `Wuchale` menarik tetapi belum layak. Saya menemui masalah reaktivi
 Secara pribadi saya tidak suka harus membuat ulang file JS sebelum setiap push, yang menciptakan risiko konflik merge konstan melalui PR. Alat ini juga tampak lebih fokus pada Vite daripada Next.js.
 Terakhir, dibandingkan dengan solusi lain, Paraglide tidak menggunakan store (misalnya React context) untuk mengambil lokal saat ini untuk merender konten. Untuk setiap node yang di-parsing, ia akan meminta lokal dari localStorage / cookie dst. Ini mengarah pada eksekusi logika yang tidak perlu yang berdampak pada reaktivitas komponen.
 
+> Catatan tentang paraglide: solusi ini menyuntikkan kode ke dalam basis kode Anda untuk impor, akibatnya metrik 'ukuran lib' dalam laporan benchmark hampir 0. Pembuatan kode (code generation) adalah hal yang baik, karena fungsi yang digunakan hanya akan mencakup logika yang diperlukan (semua awalan vs tanpa awalan, cookie vs penyimpanan, dll.). Sebagai perbandingan, Intlayer melakukan pemfilteran ini melalui injeksi variabel lingkungan dalam build untuk memaksa bundler melakukan tree-shake pada konten tergantung pada logikanya. Berkat ini, paraglide dan intlayer berakhir menjadi solusi yang 6 hingga 10 kali lebih ringan daripada i18next atau next-intl.
+
 ### 3 — Solusi yang dapat diterima
 
-**(Tolgee)** (`tolgee@7.0.0`):
+**(Tolgee)** (`@tolgee/react@7.0.0`):
 
 `Tolgee` mengatasi banyak masalah yang disebutkan sebelumnya. Saya merasa lebih sulit untuk mengadopsinya daripada alat serupa. Ia tidak memberikan type safety, yang juga membuat pendeteksian kunci yang hilang saat compile time lebih sulit. Saya harus membungkus fungsi Tolgee dengan fungsi saya sendiri untuk menambahkan deteksi kunci yang hilang.
 
@@ -216,7 +225,7 @@ Format pesan juga berbeda: `next-intl` menggunakan ICU MessageFormat, sementara
 
 `next-translate` adalah rekomendasi utama saya jika Anda menyukai API bergaya `t()`. Ini elegan melalui `next-translate-plugin`, memuat namespace melalui `getStaticProps` dengan loader Webpack / Turbopack. Ini juga merupakan opsi teringan di sini (~2,5kb). Untuk namespacing, mendefinisikan namespace per halaman atau rute di config dipikirkan dengan matang dan lebih mudah dipelihara daripada alternatif utama seperti **next-intl** atau **next-i18next**. Di versi `3.1.2`, saya mencatat bahwa rendering statis tidak berfungsi; Next.js kembali ke rendering dinamis.
 
-**(Intlayer)** (`next-intlayer@8.7.5`):
+**(Intlayer)** (`next-intlayer@8.7.12`):
 
 Saya tidak akan secara pribadi menilai `next-intlayer` demi objektivitas, karena itu adalah solusi saya sendiri.
 

package/docs/id/benchmark/solid.md

@@ -0,0 +1,155 @@
+---
+createdAt: 2026-04-20
+updatedAt: 2026-04-21
+title: Solusi i18n Terbaik untuk Solid di Tahun 2026 - Laporan Benchmark
+description: Bandingkan pustaka internasionalisasi (i18n) Solid seperti solid-primitives, solid-i18next, dan Intlayer. Laporan performa mendetail tentang ukuran bundle, kebocoran, dan reaktivitas.
+keywords:
+  - benchmark
+  - i18n
+  - intl
+  - solid
+  - performa
+  - intlayer
+slugs:
+  - doc
+  - benchmark
+  - solid
+author: Aymeric PINEAU
+applicationTemplate: https://github.com/intlayer-org/benchmark-i18n-solid-template
+history:
+  - version: 8.7.12
+    date: 2026-01-06
+    changes: "Inisialisasi benchmark"
+---
+
+# Pustaka i18n Solid — Laporan Benchmark 2026
+
+Halaman ini adalah laporan benchmark untuk solusi i18n pada Solid.
+
+## Daftar Isi
+
+<Toc/>
+
+## Benchmark Interaktif
+
+<I18nBenchmark framework="vite-solid" vertical/>
+
+## Referensi hasil:
+
+<iframe 
+  src="https://intlayer.org/markdown?url=https%3A%2F%2Fraw.githubusercontent.com%2Fintlayer-org%2Fbenchmark-i18n%2Fmain%2Freport%2Fscripts%2Fsummarize-vite_solid.md" 
+  width="100%" 
+  height="600px"
+  style="border:none;">
+</iframe>
+
+> https://intlayer.org/markdown?url=https%3A%2F%2Fraw.githubusercontent.com%2Fintlayer-org%2Fbenchmark-i18n%2Fmain%2Freport%2Fscripts%2Fsummarize-vite_solid.md
+
+Lihat repositori benchmark lengkap [di sini](https://github.com/intlayer-org/benchmark-i18n/tree/main).
+
+## Pendahuluan
+
+Solusi internasionalisasi adalah salah satu dependensi terberat dalam aplikasi Solid. Risiko utamanya adalah mengirimkan konten yang tidak perlu: terjemahan untuk halaman lain dan bahasa lain dalam satu bundle rute.
+
+Seiring berkembangnya aplikasi Anda, masalah tersebut dapat dengan cepat membengkak JavaScript yang dikirim ke klien dan memperlambat navigasi.
+
+Dalam praktiknya, untuk implementasi yang paling tidak dioptimalkan, halaman yang diinternasionalisasi bisa berakhir beberapa kali lebih berat daripada versi tanpa i18n.
+
+Dampak lainnya adalah pada pengalaman pengembang (DX): bagaimana Anda mendeklarasikan konten, tipe data, organisasi namespace, pemuatan dinamis, dan reaktivitas saat bahasa berubah.
+
+## TL;DR
+
+- **Intlayer**: Pilihan yang direkomendasikan untuk aplikasi Solid profesional yang membutuhkan fitur canggih dan optimasi (v8.7.12).
+- **@solid-primitives/i18n**: Alternatif ringan yang sangat baik untuk proyek sederhana, meskipun tidak memiliki fitur canggih seperti lazy loading.
+- **solid-i18next**: Opsi standar tetapi berat (~4.7× Intlayer) dengan kelemahan yang sama seperti React i18next.
+- **Paraglide**: Pendekatan inovatif tetapi DX yang kompleks dan masalah tree-shaking di beberapa pengaturan.
+
+## Uji aplikasi Anda
+
+Untuk mendeteksi masalah kebocoran i18n dengan cepat, saya menyiapkan pemindai gratis yang tersedia [di sini](https://intlayer.org/i18n-seo-scanner).
+
+<iframe src="https://intlayer.org/i18n-seo-scanner" width="100%" height="600px" style="border:none;"/>
+
+## Masalahnya
+
+Dua tuas sangat penting untuk membatasi biaya aplikasi multibahasa:
+
+- Pisahkan konten berdasarkan halaman / namespace agar Anda tidak memuat seluruh kamus saat tidak dibutuhkan.
+- Muat bahasa yang tepat secara dinamis, hanya saat dibutuhkan.
+
+Memahami batasan teknis dari pendekatan ini:
+
+**Pemuatan dinamis**
+
+Tanpa pemuatan dinamis, sebagian besar solusi menyimpan pesan dalam memori sejak render pertama, yang menambah overhead signifikan untuk aplikasi dengan banyak rute dan bahasa.
+
+Dengan pemuatan dinamis, Anda menerima kompromi: JS awal yang lebih sedikit, tetapi terkadang permintaan ekstra saat mengganti bahasa.
+
+**Pemisahan konten (Splitting)**
+
+Sintaks yang dibangun di sekitar `t('a.b.c')` sangat nyaman tetapi sering kali mendorong penyimpanan objek JSON besar saat runtime. Model tersebut membuat tree-shaking sulit kecuali pustaka menawarkan strategi pemisahan per halaman yang nyata.
+
+## Metodologi Penelitian
+
+Untuk benchmark ini, kami membandingkan pustaka berikut:
+
+- `Base App` (Tanpa pustaka i18n)
+- `solid-intlayer` (v8.7.12)
+- `@solid-primitives/i18n` (v2.2.1)
+- `solid-i18next` (v17.0.2)
+- `@inlang/paraglide-js` (v2.17.0)
+
+Framework yang digunakan adalah `Solid` dengan aplikasi multibahasa yang terdiri dari **10 halaman** dan **10 bahasa**.
+
+Kami membandingkan **empat strategi pemuatan**:
+
+| Strategia            | Tanpa namespace (global)                            | Dengan namespace (scoped)                                                        |
+| :------------------- | :-------------------------------------------------- | :------------------------------------------------------------------------------- |
+| **Pemuatan statis**  | **Static**: Segalanya di memori saat startup.       | **Scoped static**: Dipisah berdasarkan namespace; segalanya dimuat saat startup. |
+| **Pemuatan dinamis** | **Dynamic**: Pemuatan sesuai permintaan per bahasa. | **Scoped dynamic**: Pemuatan granular per namespace dan bahasa.                  |
+
+## Ringkasan strategi
+
+- **Static**: Sederhana; tidak ada latensi jaringan setelah pemuatan awal. Kekurangan: ukuran bundle besar.
+- **Dynamic**: Mengurangi beban awal (lazy-loading). Ideal bila Anda memiliki banyak bahasa.
+- **Scoped static**: Menjaga kode tetap teratur (pemisahan logis) tanpa permintaan jaringan ekstra yang kompleks.
+- **Scoped dynamic**: Pendekatan terbaik untuk _code splitting_ dan performa. Meminimalkan memori dengan hanya memuat apa yang dibutuhkan oleh tampilan saat ini dan bahasa yang aktif.
+
+## Hasil secara mendetail
+
+### 1 — Solusi yang harus dihindari
+
+> Tidak ada solusi yang jelas untuk dihindari dalam ekosistem Solid.
+
+### 2 — Solusi yang dapat diterima
+
+**(solid-i18next)** (`solid-i18next@17.0.2`):
+
+`solid-i18next` mungkin merupakan opsi yang paling populer karena merupakan salah satu yang pertama memenuhi kebutuhan i18n aplikasi JavaScript. Ia juga memiliki serangkaian plugin komunitas yang luas untuk masalah tertentu.
+
+Paketnya berat (~14.6kb, yang mana sekitar 4.7× `solid-intlayer`).
+
+Namun, ia memiliki kelemahan utama yang sama dengan stack yang dibangun di atas `t('a.b.c')`: optimasi dimungkinkan tetapi sangat memakan waktu, dan proyek besar berisiko terkena praktik buruk (namespace + pemuatan dinamis + tipe).
+
+**(@solid-primitives/i18n)** (`@solid-primitives/i18n@2.2.1`):
+
+Solid primitive sangat ringan dan efisien. Saya merekomendasikan solusi tersebut untuk proyek ringan, tetapi fitur-fiturnya mungkin cepat terasa kurang untuk solusi profesional yang mencakup manajemen cookie, pengalihan proxy, formatter, dll.
+Ia juga tidak memiliki lazy loading dan scoping namespace untuk optimasi ukuran halaman.
+
+**(Paraglide)** (`@inlang/paraglide-js@2.17.0`):
+
+`Paraglide` menawarkan pendekatan yang inovatif dan dipikirkan dengan matang. Meskipun demikian, dalam benchmark ini, tree-shaking yang diiklankan perusahaan mereka tidak berhasil untuk implementasi saya. Alur kerja dan DX juga lebih kompleks daripada opsi lainnya.
+Secara pribadi saya tidak suka harus meregenerasi file JS sebelum setiap push, yang menciptakan risiko konflik merge yang konstan melalui PR.
+Terakhir, dibandingkan dengan solusi lain, Paraglide tidak menggunakan store (misalnya Solid signal) untuk mengambil locale saat ini guna merender konten. Untuk setiap node yang di-parse, ia akan meminta locale dari localStorage / cookie dll. Hal ini menyebabkan eksekusi logika yang tidak perlu yang berdampak pada reaktivitas komponen.
+
+### 3 — Rekomendasi
+
+**(Intlayer)** (`solid-intlayer@8.7.12`):
+
+Saya tidak akan menilai `solid-intlayer` secara pribadi demi objektivitas, karena ini adalah solusi saya sendiri.
+
+### Catatan pribadi
+
+Catatan ini bersifat pribadi dan tidak memengaruhi hasil benchmark. Namun, di dunia i18n Anda sering melihat konsensus seputar pola seperti `const t = useTranslation('xx')` + `<>{t('xx.xx')}</>` untuk konten terjemahan.
+
+Dalam aplikasi Solid, menginjeksi fungsi sebagai `JSX.Element` menurut pandangan saya adalah sebuah anti-pattern. Hal ini juga menambah kompleksitas yang dapat dihindari dan overhead eksekusi JavaScript (meskipun hampir tidak terlihat).