@intlayer/docs 8.9.4-canary.0 → 8.9.5

package/docs/ur/configuration.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2024-08-13
-updatedAt: 2026-04-03
+updatedAt: 2026-05-12
 title: ترتیب (Configuration)
 description: سیکھیں کہ اپنی ایپلیکیشن کے لیے Intlayer کو کیسے ترتیب دینا ہے۔ اپنی ضروریات کے مطابق Intlayer کو اپنی مرضی کے مطابق بنانے کے لیے دستیاب مختلف ترتیبات اور اختیارات کو سمجھیں۔
 keywords:
@@ -16,6 +16,9 @@ slugs:
   - concept
   - configuration
 history:
+  - version: 8.9.4
+    date: 2026-05-12
+    changes: "LM Studio فراہم کنندہ کے لیے سپورٹ شامل کریں"
   - version: 8.7.0
     date: 2026-04-07
     changes: "بلڈ کنفیگریشن میں `minify` اور `prune` کے اختیارات شامل کیے گئے۔"
@@ -352,7 +355,7 @@ const config: IntlayerConfig = {
   ai: {
     /**
      * استعمال کیا جانے والا AI فراہم کنندہ۔
-     * اختیارات: 'openai', 'anthropic', 'mistral', 'deepseek', 'gemini', 'ollama', 'openrouter', 'alibaba', 'fireworks', 'groq', 'huggingface', 'bedrock', 'googlevertex', 'togetherai'
+     * اختیارات: 'openai', 'anthropic', 'mistral', 'deepseek', 'gemini', 'ollama', 'openrouter', 'alibaba', 'fireworks', 'groq', 'huggingface', 'bedrock', 'googlevertex', 'togetherai', 'lmstudio'
      * ڈیفالٹ: 'openai'
      */
     provider: "openai",
@@ -918,16 +921,17 @@ Intlayer زیادہ سے زیادہ لچک کو یقینی بنانے کے لی
 - **Groq**
 - **Amazon Bedrock**
 - **Together.ai**
-
-| فیلڈ                 | وضاحت                                                                                                                           | قسم                                                                                                                                                                                                                                                                                                                                                                                            | ڈیفالٹ      | مثال                                                          | نوٹ                                                                                                                                                         |
-| -------------------- | ------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------- | ------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| `provider`           | Intlayer AI خصوصیات کے لیے استعمال کیا جانے والا فراہم کنندہ۔                                                                   | `'openai'` &#124; <br/> `'anthropic'` &#124; <br/> `'mistral'` &#124; <br/> `'deepseek'` &#124; <br/> `'gemini'` &#124; <br/> `'ollama'` &#124; <br/> `'openrouter'` &#124; <br/> `'alibaba'` &#124; <br/> `'fireworks'` &#124; <br/> `'groq'` &#124; <br/> `'huggingface'` &#124; <br/> `'bedrock'` &#124; <br/> `'googleaistudio'` &#124; <br/> `'googlevertex'` &#124; <br/> `'togetherai'` | `undefined` | `'anthropic'`                                                 | مختلف فراہم کنندگان کے لیے مختلف API کلیدوں کی ضرورت ہوتی ہے اور ان کی قیمتوں کا ڈھانچہ بھی مختلف ہوتا ہے۔                                                  |
-| `model`              | AI خصوصیات میں استعمال ہونے والا AI ماڈل۔                                                                                       | `string`                                                                                                                                                                                                                                                                                                                                                                                       | کوئی نہیں   | `'gpt-4o-2024-11-20'`                                         | مخصوص ماڈلز فراہم کنندہ پر منحصر ہیں۔                                                                                                                       |
-| `temperature`        | AI کے جوابات میں بے ترتیبی (randomness) کو کنٹرول کرتا ہے۔                                                                      | `number`                                                                                                                                                                                                                                                                                                                                                                                       | کوئی نہیں   | `0.1`                                                         | زیادہ ٹمپریچر = زیادہ تخلیقی لیکن کم قابل اعتماد جوابات۔                                                                                                    |
-| `apiKey`             | منتخب کردہ فراہم کنندہ کے لیے آپ کی API کلید۔                                                                                   | `string`                                                                                                                                                                                                                                                                                                                                                                                       | کوئی نہیں   | `process.env.OPENAI_API_KEY`                                  | خفیہ رکھیں؛ انوائرمنٹ ویری ایبلز میں محفوظ کریں۔                                                                                                            |
-| `applicationContext` | آپ کی ایپلیکیشن کے بارے میں اضافی تناظر تاکہ AI کو زیادہ درست ترجمے تیار کرنے میں مدد ملے (ڈومین، ٹارگٹ آڈینس، لہجہ، اصطلاحات)۔ | `string`                                                                                                                                                                                                                                                                                                                                                                                       | کوئی نہیں   | `'میرا اپنا ایپلیکیشن تناظر'`                                 | قواعد شامل کرنے کے لیے استعمال کیا جا سکتا ہے (مثلاً: `"آپ کو اپنے URLs کا ترجمہ نہیں کرنا چاہیے"`)۔                                                        |
-| `baseURL`            | AI API کے لیے بنیادی URL۔                                                                                                       | `string`                                                                                                                                                                                                                                                                                                                                                                                       | کوئی نہیں   | `'https://api.openai.com/v1'` <br/> `'http://localhost:5000'` | کسی مقامی یا کسٹم AI API اینڈ پوائنٹ سے رجوع کر سکتا ہے۔                                                                                                    |
-| `dataSerialization`  | AI خصوصیات کے لیے ڈیٹا سیریلائزیشن فارمیٹ۔                                                                                      | `'json'` &#124; <br/> `'toon'`                                                                                                                                                                                                                                                                                                                                                                 | `undefined` | `'toon'`                                                      | • `'json'`: ڈیفالٹ، قابل اعتماد؛ زیادہ ٹوکن لیتا ہے۔<br/>• `'toon'`: کم ٹوکن، کم مستحکم۔<br/>• ماڈل کو اضافی پیرامیٹرز بھیجتا ہے (استدلال کی کوششیں وغیرہ)۔ |
+- **LM Studio**
+
+| فیلڈ                 | وضاحت                                                                                                                           | قسم                                                                                                                                                                                                                                                                                                                                                                                                                      | ڈیفالٹ      | مثال                                                          | نوٹ                                                                                                                                                         |
+| -------------------- | ------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ----------- | ------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `provider`           | Intlayer AI خصوصیات کے لیے استعمال کیا جانے والا فراہم کنندہ۔                                                                   | `'openai'` &#124; <br/> `'anthropic'` &#124; <br/> `'mistral'` &#124; <br/> `'deepseek'` &#124; <br/> `'gemini'` &#124; <br/> `'ollama'` &#124; <br/> `'openrouter'` &#124; <br/> `'alibaba'` &#124; <br/> `'fireworks'` &#124; <br/> `'groq'` &#124; <br/> `'huggingface'` &#124; <br/> `'bedrock'` &#124; <br/> `'googleaistudio'` &#124; <br/> `'googlevertex'` &#124; <br/> `'togetherai'` &#124; <br/> `'lmstudio'` | `undefined` | `'anthropic'`                                                 | مختلف فراہم کنندگان کے لیے مختلف API کلیدوں کی ضرورت ہوتی ہے اور ان کی قیمتوں کا ڈھانچہ بھی مختلف ہوتا ہے۔                                                  |
+| `model`              | AI خصوصیات میں استعمال ہونے والا AI ماڈل۔                                                                                       | `string`                                                                                                                                                                                                                                                                                                                                                                                                                 | کوئی نہیں   | `'gpt-4o-2024-11-20'`                                         | مخصوص ماڈلز فراہم کنندہ پر منحصر ہیں۔                                                                                                                       |
+| `temperature`        | AI کے جوابات میں بے ترتیبی (randomness) کو کنٹرول کرتا ہے۔                                                                      | `number`                                                                                                                                                                                                                                                                                                                                                                                                                 | کوئی نہیں   | `0.1`                                                         | زیادہ ٹمپریچر = زیادہ تخلیقی لیکن کم قابل اعتماد جوابات۔                                                                                                    |
+| `apiKey`             | منتخب کردہ فراہم کنندہ کے لیے آپ کی API کلید۔                                                                                   | `string`                                                                                                                                                                                                                                                                                                                                                                                                                 | کوئی نہیں   | `process.env.OPENAI_API_KEY`                                  | خفیہ رکھیں؛ انوائرمنٹ ویری ایبلز میں محفوظ کریں۔                                                                                                            |
+| `applicationContext` | آپ کی ایپلیکیشن کے بارے میں اضافی تناظر تاکہ AI کو زیادہ درست ترجمے تیار کرنے میں مدد ملے (ڈومین، ٹارگٹ آڈینس، لہجہ، اصطلاحات)۔ | `string`                                                                                                                                                                                                                                                                                                                                                                                                                 | کوئی نہیں   | `'میرا اپنا ایپلیکیشن تناظر'`                                 | قواعد شامل کرنے کے لیے استعمال کیا جا سکتا ہے (مثلاً: `"آپ کو اپنے URLs کا ترجمہ نہیں کرنا چاہیے"`)۔                                                        |
+| `baseURL`            | AI API کے لیے بنیادی URL۔                                                                                                       | `string`                                                                                                                                                                                                                                                                                                                                                                                                                 | کوئی نہیں   | `'https://api.openai.com/v1'` <br/> `'http://localhost:5000'` | کسی مقامی یا کسٹم AI API اینڈ پوائنٹ سے رجوع کر سکتا ہے۔                                                                                                    |
+| `dataSerialization`  | AI خصوصیات کے لیے ڈیٹا سیریلائزیشن فارمیٹ۔                                                                                      | `'json'` &#124; <br/> `'toon'`                                                                                                                                                                                                                                                                                                                                                                                           | `undefined` | `'toon'`                                                      | • `'json'`: ڈیفالٹ، قابل اعتماد؛ زیادہ ٹوکن لیتا ہے۔<br/>• `'toon'`: کم ٹوکن، کم مستحکم۔<br/>• ماڈل کو اضافی پیرامیٹرز بھیجتا ہے (استدلال کی کوششیں وغیرہ)۔ |
 
 ---
 

package/docs/vi/benchmark/index.md

@@ -30,6 +30,3 @@ Báo cáo chi tiết và tài liệu kỹ thuật cho từng framework nằm bê
 - [**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/vi/benchmark/nextjs.md

@@ -61,6 +61,13 @@ Vì bài toán này khó, nên có nhiều giải pháp tồn tại — một s
 
 Intlayer cố gắng tối ưu hóa trên tất cả các khía cạnh này.
 
+## TL;DR
+
+- **Intlayer** & **next-translate**: Những lựa chọn tốt nhất cho hiệu năng của Next.js, mang lại kích thước nhỏ nhất và hỗ trợ render tĩnh tốt nhất.
+- **next-intl**: Tùy chọn hợp thời nhất, nhưng nặng và phức tạp để tối ưu hóa cho các ứng dụng lớn.
+- **next-i18next**: Phổ biến và giàu plugin, nhưng mang lại gánh nặng bundle đáng kể (~3× Intlayer).
+- **Tránh**: **gt-next** và **lingo.dev** do các vấn đề hiệu năng nghiêm trọng, phụ thuộc vào nhà cung cấp (vendor lock-in) và các lỗi gây hỏng build.
+
 ## Kiểm tra ứng dụng của bạn
 
 Để làm rõ các vấn đề này, tôi đã xây dựng một trình quét miễn phí mà bạn có thể thử [tại đây](https://intlayer.org/i18n-seo-scanner).
@@ -99,14 +106,14 @@ Cuối cùng, `Intlayer` áp dụng một tối ưu hóa tại thời điểm bu
 Đối với benchmark này, chúng tôi đã so sánh các thư viện sau:
 
 - `Base App` (Không sử dụng thư viện 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 @@ Các vấn đề gặp phải:
 
 **(General Translation)** (`gt-next@6.16.5`):
 
-- Đối với một ứng dụng 110kb, `gt-react` thêm vào hơn 440kb dữ liệu dư thừa.
+- Đối với một ứng dụng 110kb, `gt-next` thêm vào hơn 440kb dữ liệu dư thừa.
 - Thông báo `Quota Exceeded, please upgrade your plan` ngay trong lần xây dựng đầu tiên với General Translation.
 - Các bản dịch không được hiển trị; tôi nhận được lỗi `Error: <T> used on the client-side outside of <GTProvider>`, dường như là một lỗi trong thư viện.
-- Trong khi triển khai **gt-tanstack-start-react**, tôi cũng gặp phải một [vấn đề](https://github.com/generaltranslation/gt/issues/1210#event-24510646961) với thư viện: `does not provide an export named 'printAST' - @formatjs/icu-messageformat-parser`, khiến ứng dụng bị hỏng. Sau khi báo cáo vấn đề này, người duy trì đã khắc phục nó trong vòng 24 giờ.
+- Trong khi triển khai **gt-next**, tôi cũng gặp phải một [vấn đề](https://github.com/generaltranslation/gt/issues/1210#event-24510646961) với thư viện: `does not provide an export named 'printAST' - @formatjs/icu-messageformat-parser`, khiến ứng dụng bị hỏng. Sau khi báo cáo vấn đề này, người duy trì đã khắc phục nó trong vòng 24 giờ.
 - Thư viện ngăn cản việc render tĩnh các trang Next.js.
 
 **(Lingo.dev)** (`@lingo.dev/compiler@0.4.0`):
@@ -186,9 +193,11 @@ Các vấn đề gặp phải:
 Cá nhân tôi không thích việc phải tạo lại các tệp JS trước mỗi lần đẩy mã (push), điều này tạo ra rủi ro xung đột merge liên tục qua PR. Công cụ này cũng có vẻ tập trung vào Vite hơn là Next.js.
 Cuối cùng, so với các giải pháp khác, Paraglide không sử dụng store (ví dụ: React context) để lấy ngôn ngữ hiện tại nhằm render nội dung. Đối với mỗi nút (node) được phân tích, nó sẽ yêu cầu ngôn ngữ từ localStorage / cookie v.v. Điều này dẫn đến việc thực thi logic không cần thiết ảnh hưởng đến tính phản ứng của component.
 
+> Ghi chú về paraglide: giải pháp này đưa mã vào cơ sở mã của bạn để import, kết quả là chỉ số 'kích thước thư viện' trong báo cáo benchmark gần bằng 0. Việc tạo mã (code generation) là một điều tốt, vì hàm được sử dụng sẽ chỉ bao gồm logic cần thiết (toàn bộ tiền tố so với không có tiền tố, cookie so với lưu trữ, v.v.). So sánh với điều này, Intlayer thực hiện việc lọc này thông qua các lần chèn biến môi trường trong quá trình build để buộc bundler phải loại bỏ mã thừa (tree-shake) cho nội dung tùy thuộc vào logic. Nhờ đó, paraglide và intlayer cuối cùng trở thành các giải pháp nhẹ hơn từ 6 đến 10 lần so với i18next hoặc next-intl.
+
 ### 3 — Các giải pháp chấp nhận được
 
-**(Tolgee)** (`tolgee@7.0.0`):
+**(Tolgee)** (`@tolgee/react@7.0.0`):
 
 `Tolgee` giải quyết được nhiều vấn đề đã đề cập trước đó. Tôi thấy việc áp dụng nó khó hơn so với các công cụ tương tự. Nó không cung cấp tính an toàn kiểu dữ liệu (type safety), điều này cũng khiến việc phát hiện các khóa bị thiếu tại thời điểm biên dịch trở nên khó khăn hơn. Tôi đã phải bao bọc các hàm của Tolgee bằng các hàm của riêng mình để thêm tính năng phát hiện khóa bị thiếu.
 
@@ -216,7 +225,7 @@ Các định dạng thông báo cũng khác nhau: `next-intl` sử dụng ICU Me
 
 `next-translate` là khuyến nghị chính của tôi nếu bạn thích một API theo kiểu `t()`. Nó vận hành thanh thoát thông qua `next-translate-plugin`, tải các namespace qua `getStaticProps` với một trình tải Webpack / Turbopack. Nó cũng là tùy chọn nhẹ nhất ở đây (~2.5kb). Đối với việc phân namespace, việc định nghĩa các namespace theo từng trang hoặc route trong cấu hình được cân nhắc kỹ lưỡng và dễ bảo trì hơn so với các lựa chọn thay thế chính như **next-intl** hay **next-i18next**. Ở phiên bản `3.1.2`, tôi nhận thấy rằng việc render tĩnh không hoạt động; Next.js đã quay trở lại việc render động.
 
-**(Intlayer)** (`next-intlayer@8.7.5`):
+**(Intlayer)** (`next-intlayer@8.7.12`):
 
 Tôi sẽ không đích thân đánh giá `next-intlayer` vì tính khách quan, vì đây là giải pháp của riêng tôi.
 

package/docs/vi/benchmark/solid.md

@@ -0,0 +1,155 @@
+---
+createdAt: 2026-04-20
+updatedAt: 2026-04-21
+title: Giải pháp i18n tốt nhất cho Solid năm 2026 - Báo cáo Benchmark
+description: So sánh các thư viện quốc tế hóa (i18n) Solid như solid-primitives, solid-i18next và Intlayer. Báo cáo hiệu suất chi tiết về kích thước bundle, rò rỉ và tính phản ứng.
+keywords:
+  - benchmark
+  - i18n
+  - intl
+  - solid
+  - hiệu suất
+  - 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: "Khởi tạo benchmark"
+---
+
+# Thư viện i18n cho Solid — Báo cáo Benchmark 2026
+
+Trang này là báo cáo benchmark cho các giải pháp i18n trên Solid.
+
+## Mục lục
+
+<Toc/>
+
+## Benchmark tương tác
+
+<I18nBenchmark framework="vite-solid" vertical/>
+
+## Tham chiếu kết quả:
+
+<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
+
+Xem toàn bộ kho lưu trữ benchmark [tại đây](https://github.com/intlayer-org/benchmark-i18n/tree/main).
+
+## Giới thiệu
+
+Các giải pháp quốc tế hóa là một trong những phụ thuộc nặng nhất trong một ứng dụng Solid. Rủi ro chính là việc gửi nội dung không cần thiết: bản dịch cho các trang khác và các ngôn ngữ khác trong bundle của một route duy nhất.
+
+Khi ứng dụng của bạn phát triển, vấn đề đó có thể nhanh chóng làm bùng nổ lượng JavaScript gửi đến client và làm chậm quá trình điều hướng.
+
+Trong thực tế, đối với các triển khai ít được tối ưu hóa nhất, một trang quốc tế hóa có thể nặng hơn gấp nhiều lần so với phiên bản không có i18n.
+
+Tác động khác là đối với trải nghiệm nhà phát triển (DX): cách bạn khai báo nội dung, kiểu (types), tổ chức namespace, tải động và tính phản ứng khi thay đổi ngôn ngữ.
+
+## TL;DR
+
+- **Intlayer**: Lựa chọn được đề xuất cho các ứng dụng Solid chuyên nghiệp cần các tính năng nâng cao và tối ưu hóa (v8.7.12).
+- **@solid-primitives/i18n**: Giải pháp thay thế gọn nhẹ tuyệt vời cho các dự án đơn giản, mặc dù thiếu các tính năng nâng cao như lazy loading.
+- **solid-i18next**: Tùy chọn tiêu chuẩn nhưng nặng (~4.7 lần Intlayer) với các nhược điểm tương tự như React i18next.
+- **Paraglide**: Cách tiếp cận sáng tạo nhưng DX phức tạp và vấn đề tree-shaking trong một số thiết lập.
+
+## Kiểm tra ứng dụng của bạn
+
+Để nhanh chóng phát hiện các vấn đề rò rỉ i18n, tôi đã thiết lập một trình quét miễn phí có sẵn [tại đây](https://intlayer.org/i18n-seo-scanner).
+
+<iframe src="https://intlayer.org/i18n-seo-scanner" width="100%" height="600px" style="border:none;"/>
+
+## Vấn đề
+
+Hai đòn bẩy là thiết yếu để hạn chế chi phí của một ứng dụng đa ngôn ngữ:
+
+- Chia nhỏ nội dung theo trang / namespace để bạn không tải toàn bộ từ điển khi không cần thiết.
+- Tải ngôn ngữ chính xác một cách linh hoạt, chỉ khi cần thiết.
+
+Hiểu các hạn chế kỹ thuật của các phương pháp này:
+
+**Tải động (Dynamic loading)**
+
+Nếu không có tải động, hầu hết các giải pháp giữ tin nhắn trong bộ nhớ từ lần render đầu tiên, điều này làm tăng đáng kể overhead cho các ứng dụng có nhiều route và ngôn ngữ.
+
+Với tải động, bạn chấp nhận một sự đánh đổi: ít JS ban đầu hơn, nhưng đôi khi có thêm một request khi chuyển đổi ngôn ngữ.
+
+**Chia tách nội dung (Splitting)**
+
+Các cú pháp được xây dựng xung quanh `t('a.b.c')` rất tiện lợi nhưng thường khuyến khích giữ các đối tượng JSON lớn khi runtime. Mô hình đó làm cho tree-shaking trở nên khó khăn trừ khi thư viện cung cấp một chiến lược chia tách thực sự theo từng trang.
+
+## Phương pháp nghiên cứu
+
+Đối với benchmark này, chúng tôi đã so sánh các thư viện sau:
+
+- `Base App` (Không có thư viện i18n)
+- `solid-intlayer` (v8.7.12)
+- `@solid-primitives/i18n` (v2.2.1)
+- `solid-i18next` (v17.0.2)
+- `@inlang/paraglide-js` (v2.17.0)
+
+Framework là `Solid` với một ứng dụng đa ngôn ngữ gồm **10 trang** và **10 ngôn ngữ**.
+
+Chúng tôi đã so sánh **bốn chiến lược tải**:
+
+| Chiến lược   | Không có namespace (toàn cục)                   | Có namespace (phạm vi/scoped)                                      |
+| :----------- | :---------------------------------------------- | :----------------------------------------------------------------- |
+| **Tải tĩnh** | **Static**: Mọi thứ trong bộ nhớ khi khởi động. | **Scoped static**: Chia theo namespace; mọi thứ tải khi khởi động. |
+| **Tải động** | **Dynamic**: Tải theo yêu cầu cho mỗi ngôn ngữ. | **Scoped dynamic**: Tải chi tiết theo namespace và ngôn ngữ.       |
+
+## Tóm tắt chiến lược
+
+- **Static**: Đơn giản; không có độ trễ mạng sau lần tải đầu tiên. Nhược điểm: kích thước bundle lớn.
+- **Dynamic**: Giảm trọng lượng ban đầu (lazy-loading). Lý tưởng khi bạn có nhiều ngôn ngữ.
+- **Scoped static**: Giữ cho mã được tổ chức (tách biệt logic) mà không cần các request mạng bổ sung phức tạp.
+- **Scoped dynamic**: Phương pháp tốt nhất cho _code splitting_ và hiệu suất. Giảm thiểu bộ nhớ bằng cách chỉ tải những gì chế độ xem hiện tại và ngôn ngữ đang hoạt động cần.
+
+## Kết quả chi tiết
+
+### 1 — Các giải pháp cần tránh
+
+> Không có giải pháp rõ ràng nào cần tránh trong hệ sinh thái Solid.
+
+### 2 — Các giải pháp chấp nhận được
+
+**(solid-i18next)** (`solid-i18next@17.0.2`):
+
+`solid-i18next` có lẽ là tùy chọn phổ biến nhất vì đây là một trong những giải pháp đầu tiên đáp ứng nhu cầu i18n của các ứng dụng JavaScript. Nó cũng có một bộ plug-in cộng đồng rộng lớn cho các vấn đề cụ thể.
+
+Package này nặng (~14.6kb, gấp khoảng 4.7 lần `solid-intlayer`).
+
+Tuy nhiên, nó có cùng những nhược điểm chính như các stack được xây dựng trên `t('a.b.c')`: có thể tối ưu hóa nhưng rất tốn thời gian và các dự án lớn có nguy cơ áp dụng các phương pháp không tốt (namespace + tải động + kiểu).
+
+**(@solid-primitives/i18n)** (`@solid-primitives/i18n@2.2.1`):
+
+Solid primitive cực kỳ nhẹ và hiệu quả. Tôi khuyên dùng giải pháp đó cho các dự án nhẹ, nhưng nó có thể nhanh chóng thiếu các tính năng cho các giải pháp chuyên nghiệp bao gồm quản lý cookie, chuyển hướng proxy, formatter, v.v.
+Nó cũng thiếu lazy loading và scoping namespace để tối ưu hóa kích thước trang.
+
+**(Paraglide)** (`@inlang/paraglide-js@2.17.0`):
+
+`Paraglide` đưa ra một cách tiếp cận sáng tạo, được cân nhắc kỹ lưỡng. Mặc dù vậy, trong benchmark này, tree-shaking mà công ty họ quảng cáo đã không hoạt động cho triển khai của tôi. Workflow và DX cũng phức tạp hơn các tùy chọn khác.
+Cá nhân tôi không thích việc phải tạo lại các file JS trước mỗi lần push, điều này tạo ra rủi ro xung đột merge liên tục thông qua các PR.
+Cuối cùng, so với các giải pháp khác, Paraglide không sử dụng store (ví dụ: Solid signal) để truy xuất ngôn ngữ hiện tại để render nội dung. Đối với mỗi node được phân tích cú pháp, nó sẽ yêu cầu ngôn ngữ từ localStorage / cookie, v.v. Nó dẫn đến việc thực thi logic không cần thiết ảnh hưởng đến tính phản ứng của component.
+
+### 3 — Khuyến nghị
+
+**(Intlayer)** (`solid-intlayer@8.7.12`):
+
+Tôi sẽ không đích thân đánh giá `solid-intlayer` vì tính khách quan, vì đó là giải pháp của chính tôi.
+
+### Ghi chú cá nhân
+
+Ghi chú này mang tính cá nhân và không ảnh hưởng đến kết quả benchmark. Tuy nhiên, trong thế giới i18n, bạn thường thấy sự đồng thuận xung quanh một mẫu như `const t = useTranslation('xx')` + `<>{t('xx.xx')}</>` cho nội dung được dịch.
+
+Trong các ứng dụng Solid, việc đưa một hàm vào như một `JSX.Element` theo quan điểm của tôi là một anti-pattern. Nó cũng thêm vào sự phức tạp có thể tránh được và overhead thực thi JavaScript (ngay cả khi nó khó nhận thấy).

package/docs/vi/benchmark/svelte.md

@@ -0,0 +1,148 @@
+---
+createdAt: 2026-04-20
+updatedAt: 2026-04-21
+title: Giải pháp i18n tốt nhất cho Svelte năm 2026 - Báo cáo Benchmark
+description: So sánh các thư viện quốc tế hóa (i18n) Svelte như svelte-i18n, Paraglide và Intlayer. Báo cáo hiệu suất chi tiết về kích thước bundle, rò rỉ và tính phản ứng.
+keywords:
+  - benchmark
+  - i18n
+  - intl
+  - svelte
+  - hiệu suất
+  - intlayer
+slugs:
+  - doc
+  - benchmark
+  - svelte
+author: Aymeric PINEAU
+applicationTemplate: https://github.com/intlayer-org/benchmark-i18n-svelte-template
+history:
+  - version: 8.7.12
+    date: 2026-01-06
+    changes: "Khởi tạo benchmark"
+---
+
+# Thư viện i18n cho Svelte — Báo cáo Benchmark 2026
+
+Trang này là báo cáo benchmark cho các giải pháp i18n trên Svelte.
+
+## Mục lục
+
+<Toc/>
+
+## Benchmark tương tác
+
+<I18nBenchmark framework="vite-svelte" vertical/>
+
+## Tham chiếu kết quả:
+
+<iframe 
+  src="https://intlayer.org/markdown?url=https%3A%2F%2Fraw.githubusercontent.com%2Fintlayer-org%2Fbenchmark-i18n%2Fmain%2Freport%2Fscripts%2Fsummarize-vite_svelte.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_svelte.md
+
+Xem toàn bộ kho lưu trữ benchmark [tại đây](https://github.com/intlayer-org/benchmark-i18n/tree/main).
+
+## Giới thiệu
+
+Các giải pháp quốc tế hóa là một trong những phụ thuộc nặng nhất trong một ứng dụng Svelte. Rủi ro chính là việc gửi nội dung không cần thiết: bản dịch cho các trang khác và các ngôn ngữ khác trong bundle của một route duy nhất.
+
+Khi ứng dụng của bạn phát triển, vấn đề đó có thể nhanh chóng làm bùng nổ lượng JavaScript gửi đến client và làm chậm quá trình điều hướng.
+
+Trong thực tế, đối với các triển khai ít được tối ưu hóa nhất, một trang quốc tế hóa có thể nặng hơn gấp nhiều lần so với phiên bản không có i18n.
+
+Tác động khác là đối với trải nghiệm nhà phát triển (DX): cách bạn khai báo nội dung, kiểu (types), tổ chức namespace, tải động và tính phản ứng khi thay đổi ngôn ngữ.
+
+## TL;DR
+
+- **Intlayer**: Lựa chọn hiệu quả nhất về hiệu suất (v8.7.12) với dấu chân (footprint) nhỏ nhất.
+- **Paraglide**: Đối thủ nặng ký cho tree-shaking nhưng có trải nghiệm nhà phát triển phức tạp hơn và overhead về tính phản ứng.
+- **svelte-i18n**: Toàn diện và tiêu chuẩn cho Svelte, nhưng mang trọng lượng bundle lớn hơn nhiều (~7 lần Intlayer).
+
+## Kiểm tra ứng dụng của bạn
+
+Để nhanh chóng phát hiện các vấn đề rò rỉ i18n, tôi đã thiết lập một trình quét miễn phí có sẵn [tại đây](https://intlayer.org/i18n-seo-scanner).
+
+<iframe src="https://intlayer.org/i18n-seo-scanner" width="100%" height="600px" style="border:none;"/>
+
+## Vấn đề
+
+Hai đòn bẩy là thiết yếu để hạn chế chi phí của một ứng dụng đa ngôn ngữ:
+
+- Chia nhỏ nội dung theo trang / namespace để bạn không tải toàn bộ từ điển khi không cần thiết.
+- Tải ngôn ngữ chính xác một cách linh hoạt, chỉ khi cần thiết.
+
+Hiểu các hạn chế kỹ thuật của các phương pháp này:
+
+**Tải động (Dynamic loading)**
+
+Nếu không có tải động, hầu hết các giải pháp giữ tin nhắn trong bộ nhớ từ lần render đầu tiên, điều này làm tăng đáng kể overhead cho các ứng dụng có nhiều route và ngôn ngữ.
+
+Với tải động, bạn chấp nhận một sự đánh đổi: ít JS ban đầu hơn, nhưng đôi khi có thêm một request khi chuyển đổi ngôn ngữ.
+
+**Chia tách nội dung (Splitting)**
+
+Các cú pháp được xây dựng xung quanh `t('a.b.c')` rất tiện lợi nhưng thường khuyến khích giữ các đối tượng JSON lớn khi runtime. Mô hình đó làm cho tree-shaking trở nên khó khăn trừ khi thư viện cung cấp một chiến lược chia tách thực sự theo từng trang.
+
+## Phương pháp nghiên cứu
+
+Đối với benchmark này, chúng tôi đã so sánh các thư viện sau:
+
+- `Base App` (Không có thư viện i18n)
+- `svelte-intlayer` (v8.7.12)
+- `svelte-i18n` (v4.0.1)
+- `@inlang/paraglide-js` (v2.17.0)
+
+Framework là `Svelte` với một ứng dụng đa ngôn ngữ gồm **10 trang** và **10 ngôn ngữ**.
+
+Chúng tôi đã so sánh **bốn chiến lược tải**:
+
+| Chiến lược   | Không có namespace (toàn cục)                   | Có namespace (phạm vi/scoped)                                      |
+| :----------- | :---------------------------------------------- | :----------------------------------------------------------------- |
+| **Tải tĩnh** | **Static**: Mọi thứ trong bộ nhớ khi khởi động. | **Scoped static**: Chia theo namespace; mọi thứ tải khi khởi động. |
+| **Tải động** | **Dynamic**: Tải theo yêu cầu cho mỗi ngôn ngữ. | **Scoped dynamic**: Tải chi tiết theo namespace và ngôn ngữ.       |
+
+## Tóm tắt chiến lược
+
+- **Static**: Đơn giản; không có độ trễ mạng sau lần tải đầu tiên. Nhược điểm: kích thước bundle lớn.
+- **Dynamic**: Giảm trọng lượng ban đầu (lazy-loading). Lý tưởng khi bạn có nhiều ngôn ngữ.
+- **Scoped static**: Giữ cho mã được tổ chức (tách biệt logic) mà không cần các request mạng bổ sung phức tạp.
+- **Scoped dynamic**: Phương pháp tốt nhất cho _code splitting_ và hiệu suất. Giảm thiểu bộ nhớ bằng cách chỉ tải những gì chế độ xem hiện tại và ngôn ngữ đang hoạt động cần.
+
+## Kết quả chi tiết
+
+### 1 — Các giải pháp cần tránh
+
+> Không có giải pháp rõ ràng nào cần tránh trong hệ sinh thái Svelte.
+
+### 2 — Các giải pháp chấp nhận được
+
+**(Paraglide)** (`@inlang/paraglide-js@2.17.0`):
+
+`Paraglide` đưa ra một cách tiếp cận sáng tạo, được cân nhắc kỹ lưỡng. Trong ngữ cảnh của một ứng dụng Vite + Svelte, tree-shaking mà công ty họ quảng cáo hoạt động như mong đợi, điều này thật tuyệt vời.
+Nhưng trong trường hợp React + TanStack Start, tree-shaking không hoạt động như mong đợi, Next.js cũng vậy. Điều đó có nghĩa là, việc sử dụng Paraglide trong một dự án Svelte và TanStack Start sẽ đáng để kiểm tra lại.
+Workflow và DX cũng phức tạp hơn các tùy chọn khác.
+Cá nhân tôi không thích việc phải tạo lại các file JS trước mỗi lần push, điều này tạo ra rủi ro xung đột merge liên tục thông qua các PR. Công cụ này dường như cũng tập trung vào Vite hơn là Next.js.
+Cuối cùng, so với các giải pháp khác, Paraglide không sử dụng store (ví dụ: Svelte store) để truy xuất ngôn ngữ hiện tại để render nội dung. Đối với mỗi node được phân tích cú pháp, nó sẽ yêu cầu ngôn ngữ từ localStorage / cookie, v.v. Nó dẫn đến việc thực thi logic không cần thiết ảnh hưởng đến tính phản ứng của component.
+
+> Lưu ý về paraglide: giải pháp này đưa mã vào mã nguồn của bạn cho các import; do đó, chỉ số 'lib size' trong báo cáo benchmark gần như bằng 0. Việc tạo mã (Code generation) là một điều tốt, bởi vì hàm được sử dụng sẽ chỉ bao gồm logic cần thiết (prefix ở mọi nơi so với không prefix, cookie so với storage, v.v.). So với đó, Intlayer thực hiện việc lọc này thông qua việc đưa biến môi trường vào build để buộc bundler thực hiện tree-shaking nội dung tùy thuộc vào logic. Nhờ đó, paraglide và intlayer cuối cùng là các giải pháp nhẹ hơn từ 6 đến 10 lần so với i18next hoặc next-intl.
+
+**(svelte-i18n)** (`svelte-i18n@3.4.0`):
+
+Giải pháp này đáp ứng tất cả các nhu cầu i18n trong một dự án Svelte. Nhưng giống như trường hợp của i18next hoặc các giải pháp i18n lớn khác, nó hơi nặng (~15.9kb, gấp khoảng 7 lần `svelte-intlayer`).
+
+### 3 — Khuyến nghị
+
+**(Intlayer)** (`svelte-intlayer@8.7.12`):
+
+Tôi sẽ không đích thân đánh giá `svelte-intlayer` vì tính khách quan, vì đó là giải pháp của chính tôi.
+
+### Ghi chú cá nhân
+
+Ghi chú này mang tính cá nhân và không ảnh hưởng đến kết quả benchmark. Tuy nhiên, trong thế giới i18n, bạn thường thấy sự đồng thuận xung quanh một mẫu như `const t = useTranslation('xx')` + `<>{t('xx.xx')}</>` cho nội dung được dịch.
+
+Trong các ứng dụng Svelte, việc đưa một hàm vào như một `Slot` theo quan điểm của tôi là một anti-pattern. Nó cũng thêm vào sự phức tạp có thể tránh được và overhead thực thi JavaScript (ngay cả khi nó khó nhận thấy).

package/docs/vi/benchmark/tanstack.md

@@ -57,6 +57,13 @@ Trong thực tế, đối với các triển khai ít được tối ưu hóa nh
 
 Tác động khác là đối với trải nghiệm phát triển (DX): cách bạn khai báo nội dung, các kiểu dữ liệu, tổ chức namespace, tải động và tính phản ứng khi ngôn ngữ thay đổi.
 
+## TL;DR
+
+- **Intlayer**: Cung cấp hiệu năng tốt nhất và kích thước bundle nhỏ nhất (v8.7.12) cho TanStack Start.
+- **react-i18next** & **use-intl**: Các lựa chọn thay thế thuần thục với hệ sinh thái lớn, nhưng nặng hơn đáng kể và phức tạp hơn để tối ưu hóa.
+- **Paraglide**: Ý tưởng tree-shaking sáng tạo nhưng không hoạt động trong thực tế. DX phức tạp và chi phí phản ứng trên TanStack Start.
+- **Cần tránh**: **General Translation (GT)** và **Lingo.dev** do các vấn đề hiệu năng nghiêm trọng, giới hạn hạn mức AI và bị ràng buộc vào nhà cung cấp (vendor lock-in).
+
 ## Kiểm tra ứng dụng của bạn
 
 Để nhanh chóng phát hiện các vấn đề rò rỉ i18n, tôi đã thiết lập một trình quét miễn phí có sẵn [tại đây](https://intlayer.org/i18n-seo-scanner).
@@ -87,12 +94,12 @@ Các cú pháp được xây dựng xung quanh `const t = useTranslation()` + `t
 Đối với benchmark này, chúng tôi đã so sánh các thư viện sau:
 
 - `Base App` (Không sử dụng thư viện i18n)
-- `react-intlayer` (v8.7.5-canary.0)
+- `react-intlayer` (v8.7.12)
 - `react-i18next` (v17.0.2)
 - `use-intl` (v4.9.1)
 - `@lingui/core` (v5.3.0)
 - `@inlang/paraglide-js` (v2.15.1)
-- `tolgee` (v7.0.0)
+- `@tolgee/react` (v7.0.0)
 - `react-intl` (v10.1.1)
 - `wuchale` (v0.22.11)
 - `gt-react` (vlatest)
@@ -150,7 +157,9 @@ Các vấn đề gặp phải:
 
 `Paraglide` mang đến một phương pháp tiếp cận sáng tạo và được cân nhắc kỹ lưỡng. Dù vậy, trong benchmark này, khả năng loại bỏ mã thừa mà công ty họ quảng cáo đã không hoạt động cho triển khai Next.js hoặc cho TanStack Start của tôi. Quy trình làm việc và trải nghiệm phát triển cũng phức tạp hơn các tùy chọn khác. Cá nhân tôi không phải là fan của việc phải tạo lại các tệp JS trước mỗi lần đẩy mã, điều này tạo ra rủi ro xung đột merge liên tục cho các nhà phát triển qua PR.
 
-**(Tolgee)** (`tolgee@7.0.0`):
+> Lưu ý về paraglide: giải pháp này đưa mã vào mã nguồn của bạn cho các lần nhập; kết quả là, chỉ số 'lib size' trong báo cáo benchmark gần như bằng 0. Việc tạo mã (Code generation) là một điều tốt, vì hàm được sử dụng sẽ chỉ bao gồm logic cần thiết (tiền tố ở mọi nơi so với không có tiền tố, cookie so với lưu trữ, v.v.). So với đó, Intlayer thực hiện việc lọc này thông qua việc đưa các biến môi trường vào bản dựng để buộc trình đóng gói (bundler) thực hiện tree-shake nội dung tùy thuộc vào logic. Nhờ đó, paraglide và intlayer cuối cùng là những giải pháp nhẹ hơn từ 6 đến 10 lần so with i18next hoặc next-intl.
+
+**(Tolgee)** (`@tolgee/react@7.0.0`):
 
 `Tolgee` giải quyết được nhiều vấn đề đã đề cập trước đó. Tôi thấy việc bắt đầu với Tolgee khó khăn hơn so với các công cụ khác có phương pháp tiếp cận tương tự. Nó không cung cấp tính an toàn kiểu dữ liệu, điều này cũng khiến việc phát hiện các khóa bị thiếu tại thời điểm biên dịch trở nên khó khăn hơn nhiều. Tôi đã phải bao bọc các API của Tolgee bằng các API của riêng mình để thêm tính năng phát hiện khóa bị thiếu.