@intlayer/docs 9.5.6 → 9.5.8

package/blog/vi/i18next_vs_intlayer.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2026-09-13
-updatedAt: 2026-09-13
+updatedAt: 2026-09-22
 title: "i18next vs Intlayer: Đo kiểm và So sánh chi tiết năm 2026"
 description: "Đo lường react-i18next và next-i18next so với Intlayer trên Next.js và TanStack Start. Kích thước bundle, rò rỉ nội dung, tốc độ phản hồi khi chuyển ngôn ngữ và trải nghiệm lập trình viên."
 keywords:
@@ -25,6 +25,8 @@ author: aymericzip
 
 # i18next VS Intlayer | Đo kiểm đa ngôn ngữ (i18n) cho React & Next.js
 
+![i18next VS Intlayer](https://github.com/aymericzip/intlayer/blob/main/docs/assets/i18next-next-intl-intlayer.webp?raw=true)
+
 `i18next` là framework i18n phổ biến nhất trong hệ sinh thái JavaScript. Thông qua `react-i18next` và `next-i18next`, nó đang vận hành phần lớn các ứng dụng React và Next.js. Intlayer là một giải pháp thay thế hiện đại dựa trên trình biên dịch và cô lập phạm vi theo từng component.
 
 Bài viết này so sánh hai giải pháp dựa trên số liệu đo lường thực tế thay vì danh sách tính năng đơn thuần. Các số liệu được trích xuất từ [Benchmark Bloom](https://github.com/intlayer-org/benchmark-bloom) - một bộ đo lường nguồn mở xây dựng cùng một ứng dụng mẫu trên từng thư viện và ghi nhận chính xác những gì trình duyệt tải về.
@@ -99,6 +101,10 @@ Các chỉ số đo lường:
 
 ### Kết quả trên Next.js (`next-i18next`)
 
+Chọn các chỉ số và thư viện bạn quan tâm:
+
+<I18nBenchmark framework="nextjs" vertical/>
+
 | Thư viện                               | Chiến lược     | Dung lượng Lib (gz) | JS TB mỗi trang (gz) | Rò rỉ ngôn ngữ | Rò rỉ trang | Kích thước TB Comp (gz) | Phản hồi E2E | Thời gian Hydrate |
 | -------------------------------------- | -------------- | ------------------: | -------------------: | -------------: | ----------: | ----------------------: | -----------: | ----------------: |
 | **base** (không i18n)                  | -              |              0.0 KB |             141.0 KB |           0.0% |        0.0% |                  0.9 KB |      13.4 ms |           11.8 ms |
@@ -119,6 +125,15 @@ Các chỉ số đo lường:
 - **Kích thước từng component**: Một component gọi `useTranslation()` được đóng gói trong khoảng 26 đến 79 KB; trong khi component tương đương dùng `useIntlayer()` chỉ nặng 6.9 KB.
 - **Độ trễ khi hydrate**: Thời gian hydrate tăng vọt lên 27.7 ms ở cấu hình `dynamic` do thực thể i18next cần khởi tạo và nạp backend tại client trước khi React có thể hoàn tất quá trình hydrate.
 
+<ClickToOpenIframe
+src="https://intlayer.org/markdown?url=https%3A%2F%2Fraw.githubusercontent.com%2Fintlayer-org%2Fbenchmark-i18n%2Fmain%2Freport%2Fscripts%2Fsummarize-nextjs.md"
+width="100%"
+height="600px"
+style="border:none;"
+/>
+
+> Bảng đầy đủ, từng thư viện và từng chiến lược, trong [báo cáo benchmark Next.js](https://intlayer.org/vi/doc/benchmark/nextjs).
+
 ### Kết quả trên TanStack Start (`react-i18next`)
 
 Cùng ứng dụng kiểm thử trên nền tảng TanStack Start sử dụng trực tiếp `react-i18next` nhằm loại bỏ các yếu tố can thiệp riêng của Next.js:
@@ -141,8 +156,19 @@ Cùng ứng dụng kiểm thử trên nền tảng TanStack Start sử dụng tr
 - Chế độ `static` của Intlayer đã mặc định đạt **0% rò rỉ trang** vì nó chỉ đóng gói các từ điển được import bởi component của trang đó. Bật `importMode: 'dynamic'` sẽ triệt tiêu hoàn toàn rò rỉ ngôn ngữ.
 - **Kích thước component**: 24-27 KB ở `react-i18next` so với 6-8 KB ở Intlayer. `useTranslation()` luôn gắn chặt từng component với instance i18next toàn cục.
 
+<ClickToOpenIframe
+src="https://intlayer.org/markdown?url=https%3A%2F%2Fraw.githubusercontent.com%2Fintlayer-org%2Fbenchmark-i18n%2Fmain%2Freport%2Fscripts%2Fsummarize-tanstack.md"
+width="100%"
+height="600px"
+style="border:none;"
+/>
+
+> Bảng đầy đủ trong [báo cáo benchmark TanStack Start](https://intlayer.org/vi/doc/benchmark/tanstack).
+
 ## Nguyên nhân của sự chênh lệch: Global Instance vs Từ điển biên dịch
 
+![Centralized catalogs versus per-component dictionaries](https://github.com/aymericzip/intlayer/blob/main/docs/assets/project_stucture_18n_vs_intlayer.png?raw=true)
+
 `i18next` được xây dựng từ năm 2012 theo hướng runtime: một instance toàn cục nắm giữ kho tài nguyên, các plugin mở rộng nó và hàm `t()` tìm khóa khi render. Thiết kế này đem lại tính linh hoạt cao nhưng tạo ra gánh nặng lớn về dung lượng:
 
 ```bash
@@ -166,7 +192,13 @@ Cùng ứng dụng kiểm thử trên nền tảng TanStack Start sử dụng tr
                 └── page.tsx     # phải tự biết rằng trang này cần ["common", "about"]
 ```
 
-Instance toàn cục không thể biết trước component sẽ gọi những khóa nào; vì vậy nó buộc phải lưu trữ toàn bộ các namespace được chỉ định nạp. Muốn tối ưu, **bạn** phải chia nhỏ danh mục, **bạn** phải liệt kê các namespace cần thiết cho từng trang, và **bạn** phải duy trì danh sách này khi component di chuyển. Đúng như [ghi chú benchmark](https://github.com/intlayer-org/benchmark-bloom/blob/main/report/NOTE.md) đã chỉ ra: "Vừa duy trì an toàn kiểu dữ liệu vừa quản lý đúng namespace cho từng trang thực sự là một cơn ác mộng".
+Instance toàn cục không thể biết trước component sẽ gọi những khóa nào; vì vậy nó buộc phải lưu trữ toàn bộ các namespace được chỉ định nạp. Muốn tối ưu, **bạn** phải chia nhỏ danh mục, **bạn** phải liệt kê các namespace cần thiết cho từng trang, và **bạn** phải duy trì danh sách này khi component di chuyển.
+
+Chi phí gia tăng đồng thời trên hai trục, trang và ngôn ngữ:
+
+![Theoretical content leakage by architecture](https://github.com/aymericzip/intlayer/blob/main/docs/assets/theorical_content_leakage.webp?raw=true)
+
+Đúng như [ghi chú benchmark](https://github.com/intlayer-org/benchmark-bloom/blob/main/report/NOTE.md) đã chỉ ra: "Vừa duy trì an toàn kiểu dữ liệu vừa quản lý đúng namespace cho từng trang thực sự là một cơn ác mộng".
 
 Intlayer loại bỏ hoàn toàn instance toàn cục. Nội dung được khai báo ngay cạnh component và trình biên dịch sẽ giải quyết cây phụ thuộc vào lúc build:
 
@@ -193,7 +225,8 @@ Intlayer loại bỏ hoàn toàn instance toàn cục. Nội dung được khai
 
 ### Khởi tạo cấu hình
 
-**next-i18next (App Router)**
+<Tabs defaultTab="intlayer" group="techno">
+<Tab label="next-i18next" value="i18next">
 
 ```ts fileName="src/app/i18n/server.ts"
 import { createInstance } from "i18next";
@@ -228,7 +261,8 @@ export const initI18next = async (
 
 Bên cạnh đó, bạn phải viết thêm `I18nProvider` ở phía client, khai báo `generateStaticParams` và quản lý mảng `namespaces` trên từng trang.
 
-**Intlayer**
+</Tab>
+<Tab label="Intlayer" value="intlayer">
 
 ```ts fileName="intlayer.config.ts"
 import { type IntlayerConfig, Locales } from "intlayer";
@@ -264,9 +298,13 @@ const LocaleLayout: NextLayoutIntlayer = async ({ children, params }) => {
 export default LocaleLayout;
 ```
 
+</Tab>
+</Tabs>
+
 ### Component phía Client
 
-**react-i18next**
+<Tabs defaultTab="intlayer" group="techno">
+<Tab label="react-i18next" value="i18next">
 
 ```json fileName="src/locales/en/about.json"
 {
@@ -304,7 +342,8 @@ export const Counter = () => {
 
 > Trang hiển thị component này bắt buộc phải nạp namespace `about`, và `t("counter.label")` sẽ chỉ là chuỗi thông thường nếu chưa mở rộng `CustomTypeOptions`.
 
-**Intlayer**
+</Tab>
+<Tab label="Intlayer" value="intlayer">
 
 ```ts fileName="src/components/Counter/index.content.ts"
 import { t, type Dictionary } from "intlayer";
@@ -345,9 +384,13 @@ export const Counter = () => {
 
 `label` và `increment` đều được kiểm tra kiểu dữ liệu nghiêm ngặt; gõ sai tên sẽ báo lỗi TypeScript ngay lập tức, và nếu thiếu bản dịch tiếng Pháp thì quá trình build sẽ bị dừng lại.
 
+</Tab>
+</Tabs>
+
 ### Component phía Server đồng bộ
 
-**next-i18next**
+<Tabs defaultTab="intlayer" group="techno">
+<Tab label="next-i18next" value="i18next">
 
 ```tsx fileName="src/components/ServerCounter.tsx"
 type ServerCounterProps = {
@@ -366,7 +409,8 @@ export const ServerCounter = ({ t, locale, count }: ServerCounterProps) => (
 
 Trang cha phải gọi `i18n.getFixedT(locale, "about")` rồi truyền `t` và `locale` xuống dưới dạng props.
 
-**Intlayer**
+</Tab>
+<Tab label="Intlayer" value="intlayer">
 
 ```tsx fileName="src/components/ServerCounter.tsx"
 import { useIntlayer } from "next-intlayer/server";
@@ -385,6 +429,9 @@ export const ServerCounter = ({ count }: { count: number }) => {
 };
 ```
 
+</Tab>
+</Tabs>
+
 ## Giữ nguyên API của i18next, nhận ngay hiệu năng của Intlayer
 
 Bạn không cần phải viết lại toàn bộ component để đạt được kết quả benchmark trên. `@intlayer/i18next`, `@intlayer/react-i18next` và `@intlayer/next-i18next` đóng vai trò là các adapter tương thích trực tiếp: các lệnh gọi `useTranslation`, `t()`, `<Trans>`, xử lý số nhiều và ngữ cảnh vẫn hoạt động bình thường, được vận hành bởi các từ điển do trình biên dịch Intlayer cung cấp.
@@ -415,18 +462,85 @@ Xem hướng dẫn chuyển đổi: [i18next](https://intlayer.org/vi/doc/migrat
 
 ## Khi nào nên chọn giải pháp nào?
 
-- **Chọn i18next**: Nếu bạn phụ thuộc chặt chẽ vào hệ sinh thái plugin (bộ nhận diện đặc thù, backend chuyên biệt, ICU, Locize), cần bản địa hóa ở cả ngoài React (Node services, vanilla JS, các framework khác), đội ngũ của bạn đã rất thành thạo, hoặc nền tảng dịch thuật bắt buộc định dạng `locales/{lng}/{ns}.json`. Hãy dành thời gian để quản lý namespace và bản đồ route nếu hiệu năng là ưu tiên hàng đầu.
-- **Chọn Intlayer**: Nếu bạn muốn **nội dung đặt ngay tại component**, **an toàn kiểu dữ liệu TypeScript nghiêm ngặt**, **báo lỗi thiếu bản dịch khi build**, **tự động tree-shaking và lazy loading không tốn công**, chuyển đổi ngôn ngữ tức thì, hỗ trợ component server đồng bộ và các công cụ biên tập tích hợp sẵn (Visual Editor, CMS, dịch thuật AI, máy chủ MCP). Rất thích hợp cho dự án dạng module lớn và Design Systems.
-- **Chọn adapter `@intlayer/*-i18next`**: Nếu bạn đã có ứng dụng chạy i18next và muốn tối ưu hóa kích thước bundle và tốc độ phản hồi ngay lập tức mà không phải refactor mã nguồn.
+<AccordionGroup>
+<Accordion header="Chọn i18next">
+
+Nếu bạn phụ thuộc chặt chẽ vào hệ sinh thái plugin (bộ nhận diện đặc thù, backend chuyên biệt, ICU, Locize), cần bản địa hóa ở cả ngoài React (Node services, vanilla JS, các framework khác), đội ngũ của bạn đã rất thành thạo, hoặc nền tảng dịch thuật bắt buộc định dạng `locales/{lng}/{ns}.json`. Hãy dành thời gian để quản lý namespace và bản đồ route nếu hiệu năng là ưu tiên hàng đầu.
+
+</Accordion>
+<Accordion header="Chọn Intlayer">
+
+Bạn mong muốn **nội dung theo phạm vi component**, **TypeScript nghiêm ngặt**, **phát hiện thiếu khóa trong thời gian build**, **tree-shaking và lazy loading không tốn công sức**, chuyển đổi ngôn ngữ tức thì, server component đồng bộ và các công cụ biên tập tích hợp sẵn ([Visual Editor](https://intlayer.org/vi/doc/concept/editor), [CMS](https://intlayer.org/vi/doc/concept/cms), [dịch thuật AI](https://intlayer.org/vi/doc/concept/auto-fill), [MCP server](https://intlayer.org/vi/doc/mcp-server)). Đặc biệt phù hợp cho các codebase dạng module quy mô lớn và design system.
+
+</Accordion>
+<Accordion header="Chọn adapter @intlayer/*-i18next">
+
+Bạn đã sử dụng i18next và muốn tối ưu dung lượng bundle cùng độ phản hồi mà không cần viết lại component. Các tệp `locales/{lng}/{ns}.json` hiện tại vẫn là nguồn chân lý duy nhất. Được đo lường song song trong [i18next vs @intlayer/i18next](https://intlayer.org/vi/blog/i18next-vs-intlayer-i18next).
+
+</Accordion>
+</AccordionGroup>
+
+## FAQ (Câu hỏi thường gặp)
+
+<FAQ>
+
+<Question title="Tại sao i18next lại nặng hơn nhiều so với các thư viện khác?">
+
+Nó được thiết kế như một runtime độc lập với framework: một global instance, một pipeline plugin, một kho lưu trữ tài nguyên, một bộ phân giải khóa. Sự linh hoạt đó được biên dịch vào từng bundle. Một component rỗng chỉ import thư viện đã tốn **19.7 KB gzip** với `next-i18next` so với **5.5 KB** của `next-intlayer`, và chi phí đó phải trả trên mọi trang bất kể nội dung của bạn nặng bao nhiêu.
+
+</Question>
+
+<Question title="Lazy loading với backend có giải quyết được vấn đề không?">
+
+Nó giảm dung lượng byte, nhưng không giải quyết được độ trễ. Chuyển sang `i18next-resources-to-backend` tiết kiệm ~49 KB mỗi trang nhưng lại thêm một round-trip mạng khi chuyển đổi ngôn ngữ: **123 ms** trong cấu hình `dynamic` và **185 ms** trong `scoped-static`, so với **3-4 ms** của Intlayer. Thời gian hydration cũng tăng lên 27.7 ms vì instance phải phân giải backend trước khi React có thể hydrate.
+
+</Question>
+
+<Question title="Tôi có thể đạt 0% rò rỉ nội dung với i18next không?">
+
+Có, với `scoped-dynamic`: một namespace cho mỗi route, một backend tài nguyên và một bảng ánh xạ trang - namespace bạn tự quản lý thủ công. Kích thước trang đạt 163.4 KB trên Next.js, vẫn cao hơn **+22 KB** so với 141.3 KB của Intlayer vốn không cần bất kỳ cấu hình nào. Xem [tối ưu hóa bundle](https://intlayer.org/vi/doc/concept/bundle-optimization).
+
+</Question>
+
+<Question title="Tôi có phải viết lại các component để di chuyển không?">
+
+Không. `@intlayer/i18next`, `@intlayer/react-i18next` và `@intlayer/next-i18next` giữ nguyên `useTranslation`, `t()`, `<Trans>`, `{{interpolation}}`, các dạng số nhiều `_one` / `_other`, hậu tố ngữ cảnh và `returnObjects`. Chỉ một dòng plugin trong `next.config.ts` hoặc `vite.config.ts`. Chi tiết từng bước trong [hướng dẫn di chuyển next-i18next](https://intlayer.org/vi/doc/migration/next-i18next).
+
+</Question>
+
+<Question title="Điều gì xảy ra với các plugin i18next của tôi?">
+
+Các backend và plugin phát hiện ngôn ngữ vẫn được chấp nhận nhưng ở trạng thái bất hoạt: không còn gì để tải hoặc phát hiện trong thời gian chạy. Việc phát hiện ngôn ngữ trở thành cấu hình định tuyến của Intlayer (tiền tố URL, cookie, header). Nếu ứng dụng của bạn lấy bản dịch từ CMS tại thời điểm yêu cầu, hãy sử dụng [Intlayer CMS](https://intlayer.org/vi/doc/concept/cms) hoặc lệnh `intlayer pull` / `push` thay thế.
+
+</Question>
+
+</FAQ>
 
 ## Các bài so sánh liên quan
 
-- [next-intl vs Intlayer](https://intlayer.org/vi/blog/next-intl-vs-intlayer) (cùng benchmark)
-- [Lingui vs Intlayer](https://intlayer.org/vi/blog/lingui-vs-intlayer) (cùng benchmark)
-- [vue-i18n vs Intlayer benchmark](https://intlayer.org/vi/blog/vue-i18n-vs-intlayer-benchmark) (cùng benchmark)
+Cùng benchmark, các thư viện khác:
+
+- [next-intl vs Intlayer](https://intlayer.org/vi/blog/next-intl-vs-intlayer)
+- [Lingui vs Intlayer](https://intlayer.org/vi/blog/lingui-vs-intlayer)
+- [vue-i18n vs Intlayer benchmark](https://intlayer.org/vi/blog/vue-i18n-vs-intlayer-benchmark)
 - [next-i18next vs next-intl vs Intlayer](https://intlayer.org/vi/blog/next-i18next-vs-next-intl-vs-intlayer)
 - [react-i18next vs react-intl vs Intlayer](https://intlayer.org/vi/blog/react-i18next-vs-react-intl-vs-intlayer)
+
+Tìm hiểu sâu hơn về i18next:
+
+- [i18next vs @intlayer/i18next](https://intlayer.org/vi/blog/i18next-vs-intlayer-i18next), đo lường adapter trên cùng một ứng dụng
 - [i18next có bị lỗi thời không?](https://intlayer.org/vi/blog/is-i18next-outdated)
+- [Sử dụng Intlayer với i18next](https://intlayer.org/vi/blog/intlayer-with-i18next) và [với react-i18next](https://intlayer.org/vi/blog/intlayer-with-react-i18next)
+- [Cách quốc tế hóa ứng dụng Next.js với next-i18next](https://intlayer.org/vi/blog/nextjs-internationalization-using-next-i18next)
+
+Tài liệu tham khảo:
+
+- [Báo cáo benchmark Next.js](https://intlayer.org/vi/doc/benchmark/nextjs) và [báo cáo benchmark TanStack Start](https://intlayer.org/vi/doc/benchmark/tanstack)
+- Adapter tương thích: [i18next](https://intlayer.org/vi/doc/compatibility/i18next), [react-i18next](https://intlayer.org/vi/doc/compatibility/react-i18next), [next-i18next](https://intlayer.org/vi/doc/compatibility/next-i18next)
+- Hướng dẫn di chuyển: [i18next](https://intlayer.org/vi/doc/migration/i18next), [react-i18next](https://intlayer.org/vi/doc/migration/react-i18next), [next-i18next](https://intlayer.org/vi/doc/migration/next-i18next)
+- [Tối ưu hóa bundle](https://intlayer.org/vi/doc/concept/bundle-optimization) và [trình biên dịch Intlayer](https://intlayer.org/vi/doc/compiler)
+- [i18n theo component vs i18n tập trung](https://intlayer.org/vi/blog/per-component-vs-centralized-i18n)
+- [i18n dựa trên compiler vs khai báo](https://intlayer.org/vi/blog/compiler-vs-declarative-i18n)
 
 ## Lượt gắn sao trên GitHub
 

package/blog/vi/is_intlayer_lighter_than_paraglide.md

@@ -0,0 +1,284 @@
+---
+createdAt: 2026-09-23
+updatedAt: 2026-09-23
+title: Intlayer có nhẹ hơn Paraglide không?
+description: Paraglide trông gần như miễn phí trong các bài kiểm chuẩn i18n vì mã nguồn của nó được tạo trực tiếp vào kho lưu trữ của bạn. Cùng tìm hiểu xem dung lượng đó thực sự đi đâu, tại sao việc đọc locale trên từng nút lại gây tốn tài nguyên và cách tải động của Intlayer chỉ gửi một ngôn ngữ thay vì tất cả.
+keywords:
+  - Paraglide
+  - Intlayer
+  - Quốc tế hóa
+  - i18n
+  - Bundle size
+  - Tree shaking
+  - Benchmark
+  - Blog
+slugs:
+  - blog
+  - is-intlayer-lighter-than-paraglide
+author: aymericzip
+---
+
+# Intlayer có nhẹ hơn Paraglide không?
+
+Có.
+
+`Paraglide` nổi tiếng là giải pháp i18n nhẹ nhất hiện nay, và thoạt nhìn bảng [benchmark](https://intlayer.org/vi/doc/benchmark/tanstack) cũng đồng tình với điều đó: kích thước thư viện của nó gần như bằng không. Tuy nhiên, kích thước thư viện bằng không không đồng nghĩa với việc không có byte nào được gửi đến trình duyệt. Nó chỉ có nghĩa là các byte đó nằm ở một nơi mà chỉ số này không quét tới.
+
+<TOC/>
+
+## Những điểm cốt lõi
+
+**Kích thước thư viện bị ẩn đi chứ không hề biến mất:**
+
+Paraglide tạo runtime và các hàm thông điệp ngay trong codebase của bạn. Đoạn mã đó vẫn được gửi tới trình duyệt, nhưng được tính là mã của _chính bạn_, chứ không phải của thư viện.
+
+**Không có provider không phải là một món hời miễn phí:**
+
+Mỗi lần gọi `m.my_key()` đều tự giải quyết locale độc lập, đọc cookie hoặc bộ nhớ lưu trữ cho từng node được render, thay vì đọc một lần duy nhất từ context.
+
+**Không có cơ chế tải động (Dynamic Loading):**
+
+Paraglide import tất cả ngôn ngữ của một thông điệp vào client bundle. Ngược lại, Intlayer với `importMode: 'dynamic'` hoặc `'fetch'` chỉ tải duy nhất ngôn ngữ đang được hiển thị.
+
+**Tree shaking không được đảm bảo:**
+
+Trong một số bài kiểm tra hiệu năng của chúng tôi, tính năng tree shaking được quảng cáo của Paraglide đã không hoạt động. Hãy kiểm tra bundle thực tế của bạn.
+
+## Dung lượng của Paraglide thực sự nằm ở đâu?
+
+Trong các báo cáo kiểm chuẩn, chỉ số "kích thước thư viện" đo lường provider và các hook của mỗi thư viện i18n bên trong một component rỗng, trước khi có bất kỳ nội dung nào được thêm vào.
+
+| Thư viện (TanStack Start)     | Dung lượng lib (gz) | Dung lượng lib (min) |
+| ----------------------------- | ------------------- | -------------------- |
+| `@inlang/paraglide-js@2.15.1` | 1.8 KB              | 4.5 KB               |
+| `react-intlayer@9.5.1`        | 5.0 KB              | 15.2 KB              |
+
+Nếu chỉ nhìn riêng số liệu này, Paraglide dường như chiến thắng. Nhưng Paraglide là một trình biên dịch: nó đọc các tệp `messages/*.json` và tạo một thư mục `paraglide/` trong kho mã của bạn, chứa tệp `runtime.js` (phát hiện ngôn ngữ, chiến lược cookie và storage, bản địa hóa URL) cùng một hàm JavaScript cho mỗi thông điệp.
+
+```bash
+src/paraglide/
+├── runtime.js      # phát hiện locale, chiến lược, helper URL
+├── server.js
+├── messages.js     # re-export tất cả thông điệp
+└── messages/
+    ├── _index.js
+    ├── en.js
+    └── fr.js
+```
+
+Vì mã này nằm trong thư mục `src/` và bạn import nó qua đường dẫn tương đối, bundler sẽ tính nó vào ứng dụng của bạn chứ không phải một gói trong `node_modules`. Cột kích thước thư viện hiển thị gần như bằng không, trong khi logic tương tự vẫn được chuyển vào bundle trang của bạn.
+
+Việc tự động sinh mã không phải là ý tưởng tồi: runtime được sinh ra chỉ bao gồm logic mà cấu hình của bạn yêu cầu (chiến lược tiền tố, cookie so với local storage, v.v.). Intlayer đạt được kết quả tương tự theo cách khác, bằng cách chèn các biến môi trường vào thời điểm build để bundler tự động loại bỏ các nhánh mã không được sử dụng. Cả hai giải pháp đều nhẹ hơn từ 3 đến 10 lần so với `i18next` hoặc `next-intl`.
+
+Vì vậy, so sánh công bằng không nằm ở kích thước thư viện. Đó là **lượng JavaScript thực sự được gửi trên mỗi trang**.
+
+## Dung lượng trang thực tế qua đo đạc
+
+Ứng dụng TanStack Start, 10 trang, đo trên các route `en` và `fr`, nén bằng gzip:
+
+| Cấu hình                           | JS trang TB (gz) | So với gốc  | Rò rỉ locale | Rò rỉ trang khác |
+| ---------------------------------- | ---------------- | ----------- | ------------ | ---------------- |
+| Gốc (không i18n)                   | 111.0 KB         | -           | 0.0%         | 0.0%             |
+| `paraglide` (mọi chiến lược)       | 125.1 KB         | +14.1 KB    | 49.7%        | 0.0%             |
+| `intlayer` (`importMode: static`)  | 125.8 KB         | +14.8 KB    | 50.0%        | 0.0%             |
+| `intlayer` (`importMode: dynamic`) | **118.6 KB**     | **+7.6 KB** | **0.0%**     | **0.0%**         |
+
+Next.js 16 App Router, cùng ứng dụng:
+
+| Cấu hình         | JS trang TB (gz) | So với gốc  |
+| ---------------- | ---------------- | ----------- |
+| Gốc (không i18n) | 141.0 KB         | -           |
+| `paraglide-next` | 155.3 KB         | +14.3 KB    |
+| `next-intlayer`  | **141.3 KB**     | **+0.3 KB** |
+
+<I18nBenchmark framework="tanstack" vertical/>
+
+> Dữ liệu đầy đủ có trong [báo cáo benchmark TanStack Start](https://intlayer.org/vi/doc/benchmark/tanstack) và [báo cáo benchmark Next.js](https://intlayer.org/vi/doc/benchmark/nextjs). Từng bundle có thể được kiểm tra tại [kho lưu trữ benchmark](https://github.com/intlayer-org/benchmark-i18n).
+
+Hai điểm nổi bật rõ ràng:
+
+- Ở chế độ `static`, Intlayer gửi lượng nội dung gần như tương đương Paraglide (125.8 KB so với 125.1 KB). Điều này hoàn toàn dễ hiểu: cả hai đều bao gồm mọi ngôn ngữ của các thông điệp mà trang sử dụng.
+- Paraglide giữ nguyên kích thước 125.1 KB dù áp dụng bất kỳ chiến lược nào, bởi vì nó không hỗ trợ chế độ tải động. Mỗi hàng trong bảng trên tương đương với chế độ tĩnh.
+
+## Không có Provider: Ý tưởng tưởng chừng tốt nhưng không phải
+
+Paraglide không cần provider. Bạn import một thông điệp và gọi nó:
+
+```tsx fileName="Hero.tsx"
+import { m } from "../paraglide/messages.js";
+
+export const Hero = () => (
+  <section>
+    <h1>{m.hero_title()}</h1>
+    <p>{m.hero_description()}</p>
+    <button>{m.hero_cta()}</button>
+  </section>
+);
+```
+
+Không context, không wrapper, không hook. Nhìn qua có vẻ đơn giản hơn. Nhưng thông tin ngôn ngữ vẫn phải được lấy từ một nơi nào đó. Mỗi hàm thông điệp được tạo ra trông gần giống thế này (dạng rút gọn):
+
+```js fileName="paraglide/messages/_index.js"
+export const hero_title = (inputs = {}, options = {}) => {
+  const locale = options.locale ?? getLocale(); // được xử lý mỗi lần hàm được gọi
+
+  if (locale === "en") return en.hero_title(inputs);
+  if (locale === "fr") return fr.hero_title(inputs);
+  // ...mỗi ngôn ngữ một nhánh
+};
+```
+
+Và hàm `getLocale()` duyệt qua các chiến lược đã cấu hình (cookie, local storage, URL, locale mặc định) để tìm ngôn ngữ hiện tại. Do đó, mỗi node văn bản bạn render (`<>{m.my_key()}</>`) đều tự thực hiện việc giải quyết locale riêng, bao gồm cả thao tác đọc `document.cookie` trong trình duyệt. Một trang có 200 chuỗi dịch sẽ thực hiện giải quyết locale 200 lần trong mỗi lượt render, và lặp lại liên tục sau mỗi lần re-render.
+
+Một thư viện dùng provider chỉ đọc locale **một lần duy nhất**, lưu vào context (hoặc signal, hoặc store), và mỗi node chỉ việc đọc giá trị đã có sẵn trong bộ nhớ. Provider chỉ tốn vài trăm byte. Bỏ qua provider sẽ làm hao tốn chu kỳ CPU trong mỗi lần render, và điều này thể hiện rõ ràng trong bài benchmark: thời gian tải trang và tốc độ chuyển đổi ngôn ngữ của Paraglide luôn xếp sau Intlayer trên TanStack Start (thời gian tải trang 22.1 ms so với 14.6 ms, độ phản hồi E2E 4.3 ms so với 3.2 ms).
+
+## Trải nghiệm lập trình viên (DX)
+
+Nguồn dữ liệu gốc của Paraglide là JSON, nhưng bạn không bao giờ import trực tiếp tệp JSON. Bạn import tệp `.js` được tạo ra:
+
+<Tabs defaultTab="intlayer" group="techno">
+  <Tab label="Paraglide" value="paraglide">
+
+```json fileName="messages/en.json"
+{
+  "hero_title": "Ship your app in every language"
+}
+```
+
+```json fileName="messages/vi.json"
+{
+  "hero_title": "Phát hành ứng dụng của bạn bằng mọi ngôn ngữ"
+}
+```
+
+```tsx fileName="Hero.tsx"
+// Chỉ tồn tại sau khi trình biên dịch tạo lại từ JSON
+import { m } from "../paraglide/messages.js";
+
+export const Hero = () => <h1>{m.hero_title()}</h1>;
+```
+
+  </Tab>
+  <Tab label="Intlayer" value="intlayer">
+
+```ts fileName="Hero.content.ts"
+import { t, type Dictionary } from "intlayer";
+
+export default {
+  key: "hero",
+  content: {
+    title: t({
+      vi: "Phát hành ứng dụng của bạn bằng mọi ngôn ngữ",
+      en: "Ship your app in every language",
+    }),
+  },
+} satisfies Dictionary;
+```
+
+```tsx fileName="Hero.tsx"
+import { useIntlayer } from "react-intlayer";
+
+export const Hero = () => {
+  const { title } = useIntlayer("hero");
+
+  return <h1>{title}</h1>;
+};
+```
+
+  </Tab>
+</Tabs>
+
+Quy trình phát triển này mang lại những bất tiện:
+
+- Mỗi thay đổi đối với tệp JSON đều yêu cầu tạo lại mã trước khi import có thể nhận diện hoặc type được cập nhật.
+- Thư mục sinh ra `paraglide/` hoặc phải được commit lên git (gây ra xung đột merge trên các tệp sinh tự động ở mọi PR chỉnh sửa nội dung), hoặc bị bỏ qua (đòi hỏi bước biên dịch trước mỗi lần kiểm tra type, test và chạy CI).
+- Mọi chuỗi văn bản đều biến thành lời gọi hàm. Các hằng số trở thành `m.key()` ở khắp mọi nơi, ngay cả ở những vị trí chỉ cần một giá trị tĩnh đơn thuần.
+
+## Tree Shaking: Hãy kiểm tra bundle của bạn
+
+Lời hứa hẹn lớn nhất của Paraglide là các thông điệp không dùng đến sẽ được loại bỏ thông qua tree shaking, vì mỗi thông điệp là một export độc lập. Trong thử nghiệm với Svelte + Vite, tính năng này hoạt động đúng như quảng cáo.
+
+Nhưng trong các môi trường khác thì không như vậy. Trong lần thử nghiệm trên [Next.js](https://intlayer.org/vi/doc/benchmark/nextjs), các trang của Paraglide nặng hơn ứng dụng gốc tới 14 KB, trong khi `next-intlayer` chỉ thêm 0.3 KB. Các bài đo trước đó trên TanStack Start cũng cho thấy thông điệp từ những trang khác bị kéo vào bundle của route hiện tại.
+
+Tree shaking phụ thuộc chặt chẽ vào bundler (Turbopack, Rolldown, Rollup), cách thức import thông điệp (`import { m }` so với `import * as m`) và khả năng phân tích tác dụng phụ (side-effects). Nếu bạn chọn Paraglide vì kích thước nhỏ gọn, hãy mở công cụ phân tích bundle và kiểm tra xem điều đó có thực sự đúng với ứng dụng của bạn hay không.
+
+## Không có cơ chế tải động
+
+Đây là giới hạn về mặt kiến trúc. Paraglide không có cách nào để tải từng ngôn ngữ một: mỗi hàm thông điệp đều import tĩnh phần triển khai của từng ngôn ngữ, do đó toàn bộ ngôn ngữ đều kết thúc trong client bundle của bạn.
+
+Với 2 ngôn ngữ, bạn đã lãng phí một nửa dữ liệu dịch thuật, khớp với mức ~50% rò rỉ locale được đo lường ở trên. Với 10 ngôn ngữ, con số lãng phí lên tới 90%. Với 30 ngôn ngữ, con số này là 97%.
+
+Chuyển sang tải động cũng không thể giải quyết triệt để: với mỗi thông điệp là một hàm riêng biệt, việc lazy load từng hàm sẽ tạo ra hàng nghìn request qua mạng.
+
+Intlayer cho phép bạn linh hoạt lựa chọn theo phạm vi toàn cục hoặc trên từng từ điển:
+
+```ts fileName="intlayer.config.ts"
+import { Locales, type IntlayerConfig } from "intlayer";
+
+const config: IntlayerConfig = {
+  internationalization: {
+    locales: [Locales.ENGLISH, Locales.FRENCH, Locales.SPANISH],
+    defaultLocale: Locales.ENGLISH,
+  },
+  dictionary: {
+    importMode: "dynamic", // 'static' | 'dynamic' | 'fetch'
+  },
+};
+
+export default config;
+```
+
+| `importMode` | Dữ liệu được gửi tới client                                  | So sánh với Paraglide            |
+| ------------ | ------------------------------------------------------------ | -------------------------------- |
+| `static`     | Tất cả ngôn ngữ của các từ điển trang đang sử dụng           | Về lý thuyết cùng dung lượng     |
+| `dynamic`    | Chỉ ngôn ngữ hiện tại, tải theo cơ chế lazy cho từng từ điển | **Nhẹ hơn N lần** với N ngôn ngữ |
+| `fetch`      | Chỉ ngôn ngữ hiện tại, lấy trực tiếp qua Live Sync API       | **Nhẹ hơn N lần** với N ngôn ngữ |
+
+Nhờ [chuyển đổi trong quá trình build](https://intlayer.org/vi/doc/concept/bundle-optimization) và chế độ `importMode: 'static'`, Intlayer về mặt lý thuyết tải lượng nội dung hoàn toàn giống với Paraglide. Với `'dynamic'` hoặc `'fetch'`, nó chỉ tải những gì ngôn ngữ hiện tại cần: đối với ứng dụng có N ngôn ngữ, dung lượng dịch thuật nhẹ hơn N lần so với Paraglide.
+
+## Những trường hợp Paraglide vẫn phù hợp
+
+<AccordionGroup>
+<Accordion header="Svelte + Vite với số lượng ít ngôn ngữ">
+
+Nếu hệ thống của bạn dùng Svelte với Vite và bạn chỉ hỗ trợ 2 đến 3 ngôn ngữ, tree shaking hoạt động hiệu quả như mong đợi và chi phí tăng thêm cho các ngôn ngữ khác vẫn ở mức nhỏ.
+
+</Accordion>
+<Accordion header="Quy trình làm việc có sẵn với inlang">
+
+Nếu đội ngũ của bạn đã sử dụng hệ sinh thái inlang (Fink, Sherlock, plugin định dạng thông điệp), Paraglide sẽ tích hợp một cách tự nhiên.
+
+</Accordion>
+</AccordionGroup>
+
+## Trải nghiệm trực tiếp trên ứng dụng của bạn
+
+Kiểm tra dung lượng và hiện tượng rò rỉ ngôn ngữ trên ứng dụng đang chạy thực tế với công cụ miễn phí [i18n SEO Scanner](https://intlayer.org/i18n-seo-scanner):
+
+<ClickToOpenIframe src="https://intlayer.org/i18n-seo-scanner" width="100%" height="600px" style="border:none;"/>
+
+Cài đặt Intlayer:
+
+```bash packageManager="npm"
+npx intlayer init --interactive
+```
+
+```bash packageManager="pnpm"
+pnpm dlx intlayer init --interactive
+```
+
+```bash packageManager="yarn"
+yarn dlx intlayer init --interactive
+```
+
+```bash packageManager="bun"
+bunx intlayer init --interactive
+```
+
+## Đọc thêm
+
+- [Benchmark i18n TanStack Start](https://intlayer.org/vi/doc/benchmark/tanstack)
+- [Benchmark i18n Next.js](https://intlayer.org/vi/doc/benchmark/nextjs)
+- [Tối ưu hóa Bundle và `importMode`](https://intlayer.org/vi/doc/concept/bundle-optimization)
+- [Cách chọn thư viện i18n phù hợp cho React](https://intlayer.org/vi/blog/how-to-pick-react-i18n-library)
+- [Lợi ích của quốc tế hóa dựa trên trình biên dịch](https://intlayer.org/vi/blog/compiler-vs-declarative-i18n)