@intlayer/docs 9.5.2 → 9.5.4-canary.0

package/blog/vi/vue-i18n_vs_intlayer-vue-i18n.md

@@ -0,0 +1,288 @@
+---
+createdAt: 2026-09-13
+updatedAt: 2026-09-13
+title: "vue-i18n vs @intlayer/vue-i18n: API Giống Nhau, Bundle Khác"
+description: Những thay đổi khi một ứng dụng Vue 3 giữ các lệnh gọi vue-i18n của nó nhưng phục vụ chúng qua bộ điều hợp tương thích @intlayer/vue-i18n. JavaScript mỗi trang, kích thước runtime, kích thước thành phần và rò rỉ được đo lường trên cùng một mã Vite + Vue, cộng với những gì bộ điều hợp giữ lại, bỏ qua và không thể thay thế.
+keywords:
+  - vue-i18n
+  - "@intlayer/vue-i18n"
+  - Intlayer
+  - Compat adapter
+  - Migration
+  - Internationalization
+  - i18n
+  - Benchmark
+  - Bundle size
+  - Blog
+  - Vue
+  - Nuxt
+  - Vite
+slugs:
+  - blog
+  - vue-i18n-vs-intlayer-vue-i18n
+author: aymericzip
+---
+
+# vue-i18n VS @intlayer/vue-i18n | API Giống Nhau, Bundle Khác
+
+`@intlayer/vue-i18n` là một compat adapter: nó expose API của `vue-i18n` (`createI18n`, `useI18n`, `t()`, `d()`, `n()`, `$t`, `v-t`, `i18n.global.locale`...) và phục vụ nó từ các dictionaries được biên dịch bởi Intlayer. Các file `.vue` của bạn không thay đổi. Cái mà `t("footer.github")` được bind tới thì có.
+
+Bài viết này đo lường việc thay thế đó trên cùng một ứng dụng Vite + Vue 3, được xây dựng một lần với `vue-i18n` và một lần với adapter. Các con số đến từ [Benchmark Bloom](https://github.com/intlayer-org/benchmark-bloom). Để so sánh `vue-i18n` và Intlayer như các thư viện, hãy đọc [vue-i18n vs Intlayer](https://intlayer.org/blog/vue-i18n-vs-intlayer) và [benchmark vue-i18n vs Intlayer](https://intlayer.org/blog/vue-i18n-vs-intlayer-benchmark). Bài này nói về những gì adapter thay đổi khi bạn giữ các component của mình như cũ.
+
+<TOC/>
+
+> **tl;dr**: Trên cùng một ứng dụng Vite + Vue 3, thay thế `vue-i18n` bằng `@intlayer/vue-i18n` đã giảm JavaScript trên mỗi trang từ **134.9 KB xuống 47.0 KB** gzip (ứng dụng không có i18n nặng 41.3 KB), runtime từ **24.3 KB xuống 7.9 KB**, thành phần trung bình từ **196 KB xuống 8.4 KB**, và rò rỉ chuỗi trang nước ngoài từ **90% xuống 0%**, mà không chỉnh sửa bất kỳ tệp `.vue` nào. `createI18n({ messages })` tiếp tục hoạt động như một fallback; xóa các import JSON để có được những con số trên. Các khối SFC `<i18n>` và `setLocaleMessage()` runtime là hai tính năng không được chuyển đổi qua.
+
+## `@intlayer/vue-i18n` là gì
+
+`vue-i18n` là một runtime. `createI18n({ messages: { en, fr, ... } })` xây dựng một instance toàn cục chứa mọi message của mọi locale; `useI18n()` liên kết mỗi component với nó; `t("footer.github")` duyệt cây tại thời điểm render. Thiết kế đó là điều làm cho các khối SFC `<i18n>` và `setLocaleMessage()` trở nên có thể, và nó cũng là lý do tại sao đồ thị phụ thuộc của mọi component đều bao gồm toàn bộ cây.
+
+`@intlayer/vue-i18n` giữ lại API và thay thế cây:
+
+1. **Import aliasing.** `vueI18nVitePlugin()` từ `@intlayer/vue-i18n/plugin` bao bọc `vite-intlayer` và thêm một `resolve.alias` để `vue-i18n` được phân giải thành `@intlayer/vue-i18n`. Không có import nào được đổi tên.
+2. **JSON as source of truth.** Plugin `syncJSON` đọc file `locales/{locale}.json` của bạn với `format: "vue-i18n"` (vì vậy interpolation `{name}`, `{0}` list và plurals pipe `"car | cars"` được phân tích chính xác) và ghi lại các bản dịch khi CLI hoặc CMS cập nhật chúng.
+3. **Call-site binding.** Bước tối ưu hóa Intlayer viết lại các call site `useI18n()` để component nhận các dictionaries từ các key của nó, trong locale đang hoạt động, dưới dạng import mà bundler có thể truy vết và tách.
+
+```vue fileName="src/components/Footer.vue"
+<!-- Mã của bạn, không thay đổi -->
+<script setup lang="ts">
+import { useI18n } from "vue-i18n";
+
+const { t } = useI18n();
+</script>
+
+<template>
+  <a href="https://github.com/intlayer-org/benchmark-bloom">{{
+    t("footer.github")
+  }}</a>
+</template>
+```
+
+```ts fileName="Những gì trình biên dịch phát ra (đơn giản hóa)"
+import _dicHash_footer from "../.intlayer/dictionaries/footer.mjs";
+import { useDictionary as useI18n } from "@intlayer/vue-i18n";
+
+const { t } = useI18n(_dicHash_footer);
+```
+
+Thành phần không còn truy cập toàn bộ cây thông báo toàn cục. Nó chỉ truy cập `footer`. Đó là lý do tại sao cột kích thước thành phần dưới đây giảm từ 196 KB xuống 8 KB.
+
+## Những gì adapter giữ lại, bỏ qua và không thay thế
+
+| `vue-i18n` API                                                      | Với `@intlayer/vue-i18n`                                                                                        |
+| ------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------- |
+| `useI18n()` → `{ t, d, n, te, tm, rt, locale, availableLocales }`   | ✅ Được giữ lại. `t` keys được gõ theo các từ điển của bạn                                                      |
+| `t("key", { name })`, `t("key", [a, b])`, `t("key", count)`         | ✅ Được giữ lại. `{name}`, `{0}` và plurals phân tách bằng dấu gạch chéo được phân giải như trước               |
+| `d(date, "long")`, `n(value, "currency")`                           | ✅ Được giữ lại. `datetimeFormats` / `numberFormats` từ `createI18n()` được sử dụng, được hỗ trợ bởi `Intl` gốc |
+| `i18n.global.locale.value = "fr"`                                   | ✅ Được giữ lại. Một `WritableComputedRef` được hỗ trợ bởi client của Intlayer; phản ứng hoạt động như trước    |
+| `$t`, `$tc`, `$te`, `$tm`, `$rt`, `$d`, `$n`, `$i18n` (Options API) | ✅ Được giữ lại. Được đăng ký trên `app.config.globalProperties` bởi `app.use(i18n)`                            |
+| `v-t` directive                                                     | ✅ Được giữ lại                                                                                                 |
+| `legacy: true`                                                      | ✅ Được chấp nhận                                                                                               |
+| `createI18n({ messages })`                                          | ⚠️ `messages` được sử dụng như một **fallback runtime** với cảnh báo dev. Xóa các import JSON để giảm bundle    |
+| `setLocaleMessage()`, `mergeLocaleMessage()`                        | ❌ Cảnh báo và không làm gì. Runtime message loading được thay thế bằng build-time dictionaries                 |
+| SFC `<i18n>` custom blocks                                          | ❌ Không được đọc. Di chuyển các messages đó vào locale JSON (hoặc một `.content.ts` bên cạnh component)        |
+| `@nuxtjs/i18n`                                                      | ⚠️ Adapter riêng biệt, xem [tài liệu tương thích Nuxt](https://intlayer.org/doc/compatibility/nuxtjs-i18n)      |
+
+## Bài kiểm tra
+
+### Những gì đã được đo lường
+
+[Benchmark Bloom](https://github.com/intlayer-org/benchmark-bloom) suite xây dựng **cùng một ứng dụng Vite + Vue 3** với mỗi setup: **10 trang** (home, about, blog, careers, contact, FAQ, pricing, products, settings, team), **10 locales** (`en`, `fr`, `es`, `de`, `it`, `pt`, `zh`, `ja`, `ko`, `ru`), các components và nội dung giống hệt nhau. Các trang được đo lường trong `en` và `fr`.
+
+Cả hai đều được xây dựng trong cấu hình **tĩnh**, cấu hình mà hầu hết các dự án Vue sử dụng: đối với `vue-i18n`, mỗi locale JSON được import và truyền vào `createI18n({ messages })`; đối với adapter, các components giống nhau với `vite.config.ts` và `intlayer.config.ts` được thay đổi và import `messages` được loại bỏ. `vue-intlayer` native được bao gồm để tham khảo.
+
+Đối với mỗi build, suite ghi lại:
+
+- **Kích thước thư viện**: kích thước gzip (và minified) của một component rỗng chỉ import thư viện i18n.
+- **Page JS**: gzip JavaScript được tải xuống trên mỗi trang, được lấy trung bình trên tất cả các trang và locale.
+- **Locale leak %**: phần chia của các chuỗi được dịch trong JS được tải xuống thuộc về một locale mà người dùng **không** xem.
+- **Page leak %**: phần chia của các chuỗi được dịch trong JS được tải xuống thuộc về một trang mà người dùng **không** ở trên.
+- **Component avg**: kích thước gzip trung bình của mỗi component được biên dịch riêng lẻ.
+- **E2E reactivity**: thời gian treo tường giữa lúc chọn một locale mới và `html[lang]` cập nhật trong DOM (Playwright, 5 lần lặp).
+- **Page load**: `PerformanceNavigationTiming.duration`.
+
+> Các con số dưới đây được lấy từ lần chạy ngày **2026-09-12** với `vue-i18n` 11.4.0 và `@intlayer/vue-i18n` 9.5.1. Ứng dụng kiểm tra được thiết kế cố ý nhỏ (một vài chục chuỗi mỗi locale), do đó tỷ lệ phần trăm rò rỉ mô tả một **mẫu**: chúng tăng lên khi nội dung của bạn tăng lên trong khi chi phí runtime vẫn cố định.
+
+### Kết quả trên Vite + Vue 3
+
+| Setup                    | Strategy | Lib size (gz) | Lib size (min) | Page JS avg (gz) | Locale leak | Page leak | Component avg (gz) | E2E reactivity |  Page load |
+| ------------------------ | -------- | ------------: | -------------: | ---------------: | ----------: | --------: | -----------------: | -------------: | ---------: |
+| **base** (no i18n)       | -        |        0.0 KB |         0.0 KB |          41.3 KB |        0.0% |         - |             1.1 KB |         1.8 ms |    10.8 ms |
+| `vue-i18n`               | static   |       24.3 KB |        83.2 KB |         134.9 KB |       50.0% |     90.0% |           196.0 KB |         2.8 ms |    13.6 ms |
+| **`@intlayer/vue-i18n`** | static   |    **7.9 KB** |    **23.2 KB** |      **47.0 KB** |   **15.0%** |  **0.0%** |         **8.4 KB** |     **1.5 ms** | **9.3 ms** |
+| `vue-intlayer` (native)  | static   |        3.9 KB |        11.1 KB |          57.1 KB |       56.8% |      0.0% |             7.7 KB |         4.5 ms |    13.8 ms |
+| `vue-intlayer` (native)  | dynamic  |        3.9 KB |        11.1 KB |          59.8 KB |       50.0% |      0.0% |             6.5 KB |         4.0 ms |    15.8 ms |
+
+> Cột page-leak của ứng dụng cơ sở được để trống: không có thư viện i18n, quá trình fingerprinting nhặt các chuỗi hard-coded trong các chunk được chia sẻ và con số không có ý nghĩa.
+
+**Cách đọc nó**
+
+- **88 KB ít hơn trên mỗi trang, cùng các component.** `vue-i18n` đưa ứng dụng 41.3 KB lên **134.9 KB**. Bản build adapter của cùng các component đạt **47.0 KB**, vượt quá ứng dụng cơ sở 5.7 KB. Phần lớn sự khác biệt là 74.9 KB của `src/locales` mà `createI18n({ messages })` kéo vào từng trang và adapter không bao giờ bundle như một khối.
+- **Runtime thu nhỏ 3x.** Một component trống chỉ import `vue-i18n` tốn **24.3 KB gzip / 83.2 KB minified**: `@intlify/core-base`, message compiler và runtime. Adapter tốn **7.9 KB / 23.2 KB**, phần lớn là Intlayer's core cộng với `vue-i18n` API surface.
+- **Components: nhỏ gọn 23x.** Một component `useI18n()` được compile riêng lẻ trung bình **196 KB**, vì `t` được bind với instance mà giữ mọi message của mọi locale. Với adapter, component tương tự trung bình **8.4 KB**: nó chỉ load dictionary riêng của nó.
+- **Rò rỉ.** `vue-i18n` gửi mỗi locale và chuỗi của mỗi trang trên mỗi trang: rò rỉ locale 50% (trên hai locale được fingerprint; với mười locale được bundled, lãng phí thực tế cao hơn), rò rỉ trang 90%. Adapter giảm rò rỉ trang xuống **0%** vì mỗi component chỉ import các dictionaries của nó. Rò rỉ locale là 15% trong lần chạy `static` này; `importMode: 'dynamic'` là cài đặt loại bỏ nó, và cấu hình đó không phải là một phần của lần chạy Vue này.
+- **Reactivity và page load.** Chuyển đổi locale rẻ tiền cho cả hai (1.5-2.8 ms); hệ thống reactivity của Vue làm cho nó diễn ra một khi các message đã ở trong bộ nhớ. Page load giảm từ 13.6 ms xuống **9.3 ms**, phù hợp với 88 KB JavaScript ít hơn để phân tích.
+- **Về các hàng gốc.** `vue-intlayer` trong lần chạy này đã đóng gói mọi locale ở chế độ `static` và đạt 57.1 KB với runtime 3.9 KB; các từ điển đồng bộ của adapter mang ít chuỗi locale ngoài hơn, do đó con số trên mỗi trang thấp hơn. Runtime gốc vẫn là nhẹ nhất trong ba cái, và mô hình `.content.ts` của nó là nơi các khối `<i18n>` SFC tìm thấy tương đương của chúng.
+
+## Tại sao các số liệu thay đổi
+
+Không có gì thay đổi trong `src/components/`, vì vậy những lợi ích đến từ những gì `useI18n` được ràng buộc với.
+
+**Với `vue-i18n`**, binding là global instance. `createI18n({ messages: { en, fr, ... } })` là một import chứa toàn bộ; mọi component gọi `useI18n()` đều có thể truy cập tất cả nó, vì vậy bundler không thể split dưới instance. Tối ưu hóa có nghĩa là _bạn_ phải split `en.json` theo route, gọi `setLocaleMessage()` trong router guard, và giữ route-to-file map chính xác khi components di chuyển.
+
+```bash
+.
+├── locales
+│   ├── en.json                    # chuỗi của mọi trang
+│   └── fr.json
+└── src
+    ├── i18n.ts                    # createI18n({ messages: { en, fr, ... } })
+    ├── main.ts                    # app.use(i18n)
+    └── components
+        └── Footer.vue             # useI18n(); t("footer.github")
+```
+
+**Với `@intlayer/vue-i18n`**, binding là dictionary. `syncJSON` biến mỗi key cấp cao nhất của `en.json` thành một dictionary; bước optimize chuyển cho component những cái mà các key của nó đặt tên, như imports mà bundler theo dõi và chia tách per page.
+
+```bash
+.
+├── intlayer.config.ts             # syncJSON({ format: "vue-i18n", source: ... })
+├── locales
+│   ├── en.json                    # unchanged, still the source of truth
+│   └── fr.json
+├── .intlayer/                     # generated: one dictionary per top-level key, per locale
+└── src
+    ├── i18n.ts                    # createI18n({})   ← messages import removed
+    ├── main.ts                    # app.use(i18n)    ← unchanged
+    └── components
+        └── Footer.vue             # useI18n(); t("footer.github")  ← unchanged
+```
+
+Import `messages` trong `i18n.ts` là dòng duy nhất cần xóa. Đó là 88 KB.
+
+## Migration trong ba bước
+
+<Steps>
+<Step number={1} title="Cài đặt">
+
+```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
+```
+
+Lệnh phát hiện `vue-i18n`, cài đặt `intlayer`, `vue-intlayer`, `@intlayer/vue-i18n` và `@intlayer/sync-json-plugin`, và điền sẵn `intlayer.config.ts`. Giữ `vue-i18n` được cài đặt: nó là một peer dependency và cung cấp các types.
+
+</Step>
+<Step number={2} title="Trỏ Intlayer tới các tệp locale của bạn">
+
+```ts fileName="intlayer.config.ts"
+import { Locales, type IntlayerConfig } from "intlayer";
+import { syncJSON } from "@intlayer/sync-json-plugin";
+
+const config: IntlayerConfig = {
+  internationalization: {
+    locales: [Locales.ENGLISH, Locales.FRENCH, Locales.SPANISH],
+    defaultLocale: Locales.ENGLISH,
+  },
+  dictionary: {
+    // "static" gói tất cả các locale; "dynamic" tải cái đang hoạt động theo yêu cầu
+    importMode: "dynamic",
+    format: "vue-i18n",
+  },
+  plugins: [
+    syncJSON({
+      // vue-i18n dialect: {name}, {0}, "car | cars"
+      format: "vue-i18n",
+      source: ({ locale }) => `./locales/${locale}.json`,
+      location: "locales",
+    }),
+  ],
+};
+
+export default config;
+```
+
+`locales/{locale}.json` vẫn ở vị trí của nó. Mỗi khóa cấp cao nhất (`footer`, `hero`...) trở thành một dictionary.
+
+</Step>
+<Step number={3} title="Thêm plugin và xóa import messages">
+
+```ts fileName="vite.config.ts"
+import { defineConfig } from "vite";
+import vue from "@vitejs/plugin-vue";
+import { vueI18nVitePlugin } from "@intlayer/vue-i18n/plugin";
+
+export default defineConfig({
+  plugins: [vue(), vueI18nVitePlugin()],
+});
+```
+
+```ts fileName="src/i18n.ts"
+import { createI18n } from "vue-i18n";
+
+// Trước: createI18n({ locale: "en", messages: { en, fr, es } })
+export const i18n = createI18n({ locale: "en" });
+```
+
+`vueI18nVitePlugin()` bao bọc `vite-intlayer` (theo dõi nội dung, biên dịch từ điển, bước tối ưu hóa) và tạo alias `vue-i18n` thành adapter. Xóa import `messages` là cách loại bỏ 88 KB; giữ lại nó giữ cho ứng dụng hoạt động nhưng ship cả hai.
+
+</Step>
+</Steps>
+
+### Những gì bạn có thể xóa sau đó
+
+| File / pattern                                                  | Lý do                                                                                     |
+| --------------------------------------------------------------- | ----------------------------------------------------------------------------------------- |
+| `import en from "./locales/en.json"` và những cái khác tương tự | Chỉ được sử dụng làm fallback bởi adapter. Đây là nơi 88 KB đến từ                        |
+| `setLocaleMessage()` trong router guards                        | Không hoạt động. Quá trình loading per-route giờ đây là công việc của compiler            |
+| `@intlify/unplugin-vue-i18n`                                    | Không cần thiết: nó precompiles messages và SFC blocks mà adapter không đọc               |
+| SFC `<i18n>` blocks                                             | Không được đọc; di chuyển chúng sang locale JSON hoặc một `.content.ts` cho mỗi component |
+
+### Những gì bạn nhận được ngoài việc tiết kiệm bytes
+
+- **Typed keys.** `t("footer.github")` được gõ so với compiled `footer` dictionary; một đường dẫn sai là lỗi TypeScript thay vì key được render dưới dạng text.
+- **`npx intlayer test`** làm cho CI thất bại nếu thiếu key trong bất kỳ locale nào. **`npx intlayer fill`** dịch các key bị thiếu bằng provider key của bạn (OpenAI, Anthropic, Mistral, Gemini...) và ghi lại chúng vào `locales/{locale}.json`.
+- **Visual Editor và CMS** hoạt động trên cùng JSON, vì vậy những người không phải developer có thể chỉnh sửa thông qua UI và các file sẽ được cập nhật.
+- **Di chuyển tăng dần đến `.content.ts`.** Bất kỳ component nào cũng có thể chuyển từ `useI18n()` sang `useIntlayer("footer")` với một file content cùng vị trí. Các từ điển JSON và `.content.ts` tồn tại cùng nhau và hợp nhất.
+
+## Những giới hạn cần biết trước khi bắt đầu
+
+- **Các khối SFC `<i18n>` không được đọc.** Nếu các tin nhắn của bạn nằm bên trong các component, chúng cần được di chuyển đến các file locale (hoặc đến `.content.ts`, đó là ý tưởng tương tự nhưng có kiểu dữ liệu).
+- **Tải tin nhắn trong thời gian chạy không còn nữa.** `setLocaleMessage()` và `mergeLocaleMessage()` cảnh báo và trả về. Các bản dịch được tìm nạp từ CMS trong thời gian chạy cần Intlayer's CMS hoặc các lệnh `intlayer pull` / `push`.
+- **`messages` là một fallback, không miễn phí.** Giữ lại các import JSON trong `createI18n()` sẽ giữ 75 KB trong bundle. Xóa chúng khi `intlayer test` vượt qua.
+- **Adapter không phải là runtime gốc.** 7.9 KB so với 3.9 KB cho `vue-intlayer`. Khi mọi component đã chuyển sang `useIntlayer`, hãy loại bỏ nó.
+
+## Khi nào sử dụng cái nào?
+
+- **Ở lại trên `vue-i18n`** nếu ứng dụng của bạn phụ thuộc vào các khối SFC `<i18n>`, vào các luồng `setLocaleMessage()` runtime, hoặc nếu 90 KB cho mỗi trang không phải là mối quan tâm cho khán giả của bạn.
+- **Sử dụng `@intlayer/vue-i18n`** nếu bạn đang dùng `vue-i18n` và muốn giảm 88 KB, các component nhỏ hơn 23 lần, 0% page leakage, các key được gõ và kiểm tra CI mà không cần chỉnh sửa tệp `.vue`. Đây là điểm vào cho một codebase `vue-i18n` hiện có.
+- **Đi native (`vue-intlayer`)** cho các dự án mới, hoặc khi adapter đã hoàn thành công việc của nó. Nó có runtime nhẹ nhất (3.9 KB) và mô hình `.content.ts` cho từng component thay thế các khối `<i18n>` bằng nội dung được gõ.
+
+## Những so sánh liên quan
+
+- [vue-i18n vs Intlayer](https://intlayer.org/blog/vue-i18n-vs-intlayer) (tính năng và DX)
+- [vue-i18n vs Intlayer benchmark](https://intlayer.org/blog/vue-i18n-vs-intlayer-benchmark) (các thư viện, cùng benchmark)
+- [next-intl vs @intlayer/next-intl](https://intlayer.org/blog/next-intl-vs-intlayer-next-intl) (cùng chuỗi adapter)
+- [i18next vs @intlayer/i18next](https://intlayer.org/blog/i18next-vs-intlayer-i18next) (cùng chuỗi adapter)
+- [Lingui vs @intlayer/lingui](https://intlayer.org/blog/lingui-vs-intlayer-lingui) (cùng chuỗi adapter)
+- [Hướng dẫn di chuyển: vue-i18n to Intlayer](https://intlayer.org/doc/migration/vue-i18n)
+- [Tài liệu tham khảo bộ chuyển đổi tương thích: vue-i18n](https://intlayer.org/doc/compatibility/vue-i18n), [Nuxt i18n](https://intlayer.org/doc/compatibility/nuxtjs-i18n)
+
+## Kết luận
+
+`@intlayer/vue-i18n` thay đổi những gì `useI18n()` được liên kết đến: từ một instance toàn cục chứa mọi thông báo của mọi locale đến một dictionary được biên dịch cho component đó. Trên cùng một ứng dụng Vite + Vue 3 mà **nhỏ hơn 88 KB trên mỗi trang**, một **runtime nhỏ hơn 3 lần**, **các component nhỏ hơn 23 lần** và **0% page leakage**, cho một tệp cấu hình, một dòng plugin và một import bị xóa. Các khối `<i18n>` SFC và tải thông báo runtime là hai điều mà nó không hỗ trợ, và runtime `vue-intlayer` native vẫn còn nhỏ hơn một nửa.
+
+Tất cả dữ liệu thô, các ứng dụng thử nghiệm và các script đều có trong [kho lưu trữ Benchmark Bloom](https://github.com/intlayer-org/benchmark-bloom). Chạy nó bằng chính bạn.
+
+Tham khảo [tài liệu 'Why Intlayer?'](https://intlayer.org/doc/why) để biết thêm chi tiết.

package/blog/vi/vue-i18n_vs_intlayer.md

@@ -235,7 +235,7 @@ Sử dụng `intlayer`, bạn có thể khai báo nội dung theo định dạng
 
 Sao trên GitHub là một chỉ số mạnh mẽ về độ phổ biến của dự án, sự tin tưởng của cộng đồng và tính liên quan lâu dài. Mặc dù không phải là thước đo trực tiếp về chất lượng kỹ thuật, chúng phản ánh số lượng nhà phát triển thấy dự án hữu ích, theo dõi tiến trình của nó và có khả năng áp dụng nó. Để ước tính giá trị của một dự án, sao giúp so sánh mức độ thu hút giữa các lựa chọn thay thế và cung cấp cái nhìn sâu sắc về sự phát triển của hệ sinh thái.
 
-[![Biểu đồ Lịch sử Sao](https://api.star-history.com/svg?repos=intlify/vue-i18n&repos=aymericzip/intlayer&type=Date)](https://www.star-history.com/#intlify/vue-i18n&aymericzip/intlayer)
+[![Biểu đồ Lịch sử Sao](https://api.star-history.com/svg?repos=intlify/vue-i18n&repos=aymericzip/intlayer&type=Date)](https://star-history.com/#intlify/vue-i18n&aymericzip/intlayer)
 
 ## Kết luận
 

package/blog/zh/history_of_i18n.md

@@ -49,7 +49,7 @@ author: aymericzip
 
 本文梳理了 2011 至 2026 年间的技术变迁：剖析每一代工具所试图攻克的问题、各自的得失，以及前端整体架构演进对当今国际化实现的深远影响。
 
-![JavaScript 国际化库生态演进](https://github.com/aymericzip/intlayer/blob/main/docs/assets/cloud_i18n_logo.png?raw=true)
+![JavaScript 国际化库生态演进](https://github.com/aymericzip/intlayer/blob/main/docs/assets/cloud_i18n_logo.webp?raw=true)
 
 ## 目录
 
@@ -149,87 +149,87 @@ Jan Mühlemann 为快速成长的 React 社区带来了 `i18next` 适配，早
 
 <Tab label="JavaScript 基础层" value="javascript">
 
-| 首次发布      | 工具类库                             | 旨在解决的核心问题                                                                                            | 关键创新亮点                                                                                                                     |
-| ------------- | ------------------------------------ | ------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------- |
-| 2012 年 1 月  | `i18next`                            | 在不绑定特定框架的前提下，统一浏览器与 Node.js 端的运行时键值字典查找。                                       | 采用插件化运行时架构，将翻译核心逻辑与加载器、环境检测器及缓存机制解耦。                                                         |
-| 2021 年 2 月  | `typesafe-i18n`                      | 避免因未约束类型的字符串键导致的运行时静默报错和插值异常。                                                    | 直接从翻译对象生成强类型翻译函数，运行时零额外依赖。                                                                             |
-| 2023 年 10 月 | `paraglide` (`@inlang/paraglide-js`) | 消除运行时字典遍历、沉重的语法解析器以及客户端包体积膨胀。                                                    | 将消息直接编译为纯 ECMAScript 模块和易于 Tree-shaking 优化的原生 JavaScript 函数。                                               |
-| 2024 年 4 月  | `intlayer`                           | 替换难以维护的大型命名空间，杜绝跨页面文案泄露，降低团队 Git 合并冲突，并补齐 TypeScript 时代的类型安全短板。 | 将 `.content` 声明文件与组件代码就近组织以实现精细拆分，自动生成 TypeScript 类型推导，内建可视化 CMS 与基于 AI 的 CLI 翻译工具。 |
-| 2025 年 6 月  | `wuchale`                            | 消除开发阶段手动剥离文本字符串并为每条内容生造翻译键名的繁琐步骤。                                            | 基于 AST 抽象语法树在构建期自动捕获行内文本，并直接编译为无包装层的本地化函数。                                                  |
+| 首次发布      | 工具类库                             | 作者                                                         | 旨在解决的核心问题                                                                                            | 关键创新亮点                                                                                                                     |
+| ------------- | ------------------------------------ | ------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------- |
+| 2012 年 1 月  | `i18next`                            | Jan Mühlemann (`@jamuhl`)                                    | 在不绑定特定框架的前提下，统一浏览器与 Node.js 端的运行时键值字典查找。                                       | 采用插件化运行时架构，将翻译核心逻辑与加载器、环境检测器及缓存机制解耦。                                                         |
+| 2021 年 2 月  | `typesafe-i18n`                      | Ivan Hofer (`@ivanhofer`)                                    | 避免因未约束类型的字符串键导致的运行时静默报错和插值异常。                                                    | 直接从翻译对象生成强类型翻译函数，运行时零额外依赖。                                                                             |
+| 2023 年 10 月 | `paraglide` (`@inlang/paraglide-js`) | Samuel Stroschein (`@samuelstroschein`) / Inlang (`@inlang`) | 消除运行时字典遍历、沉重的语法解析器以及客户端包体积膨胀。                                                    | 将消息直接编译为纯 ECMAScript 模块和易于 Tree-shaking 优化的原生 JavaScript 函数。                                               |
+| 2024年8月     | `intlayer`                           | Aymeric Pineau (`@aymericzip`)                               | 替换难以维护的大型命名空间，杜绝跨页面文案泄露，降低团队 Git 合并冲突，并补齐 TypeScript 时代的类型安全短板。 | 将 `.content` 声明文件与组件代码就近组织以实现精细拆分，自动生成 TypeScript 类型推导，内建可视化 CMS 与基于 AI 的 CLI 翻译工具。 |
+| 2025 年 6 月  | `wuchale`                            | Kidus Adugna (`@K1DV5`)                                      | 消除开发阶段手动剥离文本字符串并为每条内容生造翻译键名的繁琐步骤。                                            | 基于 AST 抽象语法树在构建期自动捕获行内文本，并直接编译为无包装层的本地化函数。                                                  |
 
 </Tab>
 
 <Tab label="React" value="react">
 
-| 首次发布      | 工具类库         | 旨在解决的核心问题                                                                                | 关键创新亮点                                                                                                          |
-| ------------- | ---------------- | ------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------- |
-| 2014 年 6 月  | `react-intl`     | 统一 React 中数字、日期、货币以及复杂复数语法的格式化规范。                                       | 提供遵循 ICU MessageFormat 和 ECMA-402 规范的声明式组件（`<FormattedMessage>`、`<FormattedDate>`）。                  |
-| 2015 年 12 月 | `react-i18next`  | 为 React 提供贴合组件声明习惯且支持响应式刷新状态的 `i18next` 绑定。                              | 伴随 React 持续演进，从早期的 HOC 架构迭代至 `<Trans>` JSX 插值组件与 `useTranslation` Hook。                         |
-| 2018 年 1 月  | `@lingui/react`  | 减少运行时 ICU 语法解析器对客户端包体积造成的性能负担。                                           | 利用 Babel/SWC 编译宏，在构建时将 `<Trans>` 和 `t` 预编译为体积小巧的索引数组。                                       |
-| 2020 年 12 月 | `use-intl`       | 为 React 打造轻量、以 Hook 为核心并深度整合类型安全的现代化方案。                                 | 推出体验流畅的 `useTranslations` 与 `useFormatter` Hook，提供全面的 TypeScript 类型约束。                             |
-| 2021 年 2 月  | `@tolgee/react`  | 缩短开发者、翻译人员与产品设计之间的沟通与反馈链路。                                              | 支持浏览器内的上下文行内编辑，用户可通过 Alt 键点击文案即时修改并自动生成界面快照。                                   |
-| 2024 年 4 月  | `react-intlayer` | 专为 React 组件生命周期量身打造，摆脱中心化 JSON 字典、臃肿命名空间以及跨页面内容互相干扰的顽疾。 | 专为 React 渲染优化的 `useIntlayer` Hook，自动派生 TypeScript 严谨类型，组件级构建按需拆分，支持实时可视化 CMS 同步。 |
-| 2024 年 7 月  | `gt-react`       | 自动化人工导出翻译文件、交接流转及持续维护的繁复流程。                                            | 基于云原生体系，通过机器翻译流水线在 React 组件内直接实现由 AI 驱动的自动化本地化。                                   |
-| 2025 年 8 月  | `@wuchale/jsx`   | 免除在 JSX 中手动定义文案键名以及引入冗长翻译 Hook 的样板代码。                                   | 通过 AST 语法转换自动提取原始 JSX 文本节点，并将其就地编译为本地化后的等效代码。                                      |
+| 首次发布      | 工具类库         | 作者                           | 旨在解决的核心问题                                                                                | 关键创新亮点                                                                                                          |
+| ------------- | ---------------- | ------------------------------ | ------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------- |
+| 2014 年 6 月  | `react-intl`     | Yahoo! / FormatJS              | 统一 React 中数字、日期、货币以及复杂复数语法的格式化规范。                                       | 提供遵循 ICU MessageFormat 和 ECMA-402 规范的声明式组件（`<FormattedMessage>`、`<FormattedDate>`）。                  |
+| 2015 年 12 月 | `react-i18next`  | Jan Mühlemann (`@jamuhl`)      | 为 React 提供贴合组件声明习惯且支持响应式刷新状态的 `i18next` 绑定。                              | 伴随 React 持续演进，从早期的 HOC 架构迭代至 `<Trans>` JSX 插值组件与 `useTranslation` Hook。                         |
+| 2018 年 1 月  | `@lingui/react`  | Tomáš Ehrlich (`@tricoder42`)  | 减少运行时 ICU 语法解析器对客户端包体积造成的性能负担。                                           | 利用 Babel/SWC 编译宏，在构建时将 `<Trans>` 和 `t` 预编译为体积小巧的索引数组。                                       |
+| 2020 年 12 月 | `use-intl`       | Jan Amann (`@amannn`)          | 为 React 打造轻量、以 Hook 为核心并深度整合类型安全的现代化方案。                                 | 推出体验流畅的 `useTranslations` 与 `useFormatter` Hook，提供全面的 TypeScript 类型约束。                             |
+| 2021 年 2 月  | `@tolgee/react`  | Jan Cizmar (`@jcizmar`)        | 缩短开发者、翻译人员与产品设计之间的沟通与反馈链路。                                              | 支持浏览器内的上下文行内编辑，用户可通过 Alt 键点击文案即时修改并自动生成界面快照。                                   |
+| 2024年8月     | `react-intlayer` | Aymeric Pineau (`@aymericzip`) | 专为 React 组件生命周期量身打造，摆脱中心化 JSON 字典、臃肿命名空间以及跨页面内容互相干扰的顽疾。 | 专为 React 渲染优化的 `useIntlayer` Hook，自动派生 TypeScript 严谨类型，组件级构建按需拆分，支持实时可视化 CMS 同步。 |
+| 2024 年 7 月  | `gt-react`       | Ernest McCarter (`@eoinest`)   | 自动化人工导出翻译文件、交接流转及持续维护的繁复流程。                                            | 基于云原生体系，通过机器翻译流水线在 React 组件内直接实现由 AI 驱动的自动化本地化。                                   |
+| 2025年6月     | `@wuchale/jsx`   | Kidus Adugna (`@K1DV5`)        | 免除在 JSX 中手动定义文案键名以及引入冗长翻译 Hook 的样板代码。                                   | 通过 AST 语法转换自动提取原始 JSX 文本节点，并将其就地编译为本地化后的等效代码。                                      |
 
 </Tab>
 
 <Tab label="Next.js" value="nextjs">
 
-| 首次发布      | 工具类库                                    | 旨在解决的核心问题                                                                                        | 关键创新亮点                                                                                                                                      |
-| ------------- | ------------------------------------------- | --------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------- |
-| 2018 年 11 月 | `next-i18next`                              | 在 Next.js Pages Router 中借助 `i18next` 支持 SSR 服务端渲染与 SSG 静态导出，避免客户端出现链式数据请求。 | 提供 `serverSideTranslations` 与 `appWithTranslation`，将本地化命名空间按需注入页面 Props。                                                       |
-| 2019 年 12 月 | `next-translate`                            | 简化 Next.js Pages Router 项目中的国际化配置门槛并降低打包体积。                                          | 采用 Webpack Loader 插件架构，在构建阶段自动按页面仅注入该页所需的语言命名空间。                                                                  |
-| 2020 年 11 月 | `next-intl`                                 | 全面适配 Next.js App Router、React Server Components (RSC) 以及流式服务端渲染架构。                       | 原生集成 Next.js App Router 中间件、Server Actions 以及异步 Server Components，在服务端完成处理而不向客户端强行发送 JS。                          |
-| 2022 年 7 月  | `next-international`                        | 在维持极低客户端打包体积的前提下，为 Next.js 提供严苛的 TypeScript 类型校验。                             | 针对作用域明确的翻译键生成严格类型推导，并为 App Router 和 Pages Router 提供轻量化适配器。                                                        |
-| 2024 年 4 月  | `paraglide-next` (`@inlang/paraglide-next`) | 将构建期预编译、无运行时代价的理念引入 Next.js App Router 与 Pages Router。                               | 结合中间件路由与支持 Tree-shaking 的轻量消息函数，彻底避免在 RSC 及客户端包中运行时解析 JSON 数据。                                               |
-| 2024 年 4 月  | `next-intlayer`                             | 提供无需在跨组件层级时繁琐传递 `t()` 函数或字典 Props 的 Next.js 专用服务端组件适配层。                   | 允许在同步 Server Components 中直接调用 `useIntlayer` 而无需 Prop-drilling，具备无串行等待的服务端渲染、国际化路由中间件以及可视化 CMS 同步能力。 |
-| 2024 年 9 月  | `gt-next`                                   | 利用人工智能翻译技术，自动化生成 Next.js 多语言内容并处理动态本地化路由。                                 | 面向 App Router 深度集成，将云端机器翻译服务与 Next.js Edge 中间件及缓存架构相结合。                                                              |
+| 首次发布      | 工具类库                                    | 作者                                                         | 旨在解决的核心问题                                                                                        | 关键创新亮点                                                                                                                                      |
+| ------------- | ------------------------------------------- | ------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------- |
+| 2018 年 11 月 | `next-i18next`                              | Isaac Hinman (`@isaachinman`)                                | 在 Next.js Pages Router 中借助 `i18next` 支持 SSR 服务端渲染与 SSG 静态导出，避免客户端出现链式数据请求。 | 提供 `serverSideTranslations` 与 `appWithTranslation`，将本地化命名空间按需注入页面 Props。                                                       |
+| 2020年12月    | `next-translate`                            | Arvin Wiyono (`@arvinn`) / Vinissimus (`@vinissimus`)        | 简化 Next.js Pages Router 项目中的国际化配置门槛并降低打包体积。                                          | 采用 Webpack Loader 插件架构，在构建阶段自动按页面仅注入该页所需的语言命名空间。                                                                  |
+| 2020年12月    | `next-intl`                                 | Jan Amann (`@amannn`)                                        | 全面适配 Next.js App Router、React Server Components (RSC) 以及流式服务端渲染架构。                       | 原生集成 Next.js App Router 中间件、Server Actions 以及异步 Server Components，在服务端完成处理而不向客户端强行发送 JS。                          |
+| 2022 年 7 月  | `next-international`                        | Tom Dussaix (`@tom-dussaix`)                                 | 在维持极低客户端打包体积的前提下，为 Next.js 提供严苛的 TypeScript 类型校验。                             | 针对作用域明确的翻译键生成严格类型推导，并为 App Router 和 Pages Router 提供轻量化适配器。                                                        |
+| 2023年10月    | `paraglide-next` (`@inlang/paraglide-next`) | Samuel Stroschein (`@samuelstroschein`) / Inlang (`@inlang`) | 将构建期预编译、无运行时代价的理念引入 Next.js App Router 与 Pages Router。                               | 结合中间件路由与支持 Tree-shaking 的轻量消息函数，彻底避免在 RSC 及客户端包中运行时解析 JSON 数据。                                               |
+| 2024年8月     | `next-intlayer`                             | Aymeric Pineau (`@aymericzip`)                               | 提供无需在跨组件层级时繁琐传递 `t()` 函数或字典 Props 的 Next.js 专用服务端组件适配层。                   | 允许在同步 Server Components 中直接调用 `useIntlayer` 而无需 Prop-drilling，具备无串行等待的服务端渲染、国际化路由中间件以及可视化 CMS 同步能力。 |
+| 2024年7月     | `gt-next`                                   | Ernest McCarter (`@eoinest`)                                 | 利用人工智能翻译技术，自动化生成 Next.js 多语言内容并处理动态本地化路由。                                 | 面向 App Router 深度集成，将云端机器翻译服务与 Next.js Edge 中间件及缓存架构相结合。                                                              |
 
 </Tab>
 
 <Tab label="Vue 与 Nuxt" value="vue">
 
-| 首次发布      | 工具类库       | 旨在解决的核心问题                                                                      | 关键创新亮点                                                                                                                             |
-| ------------- | -------------- | --------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------- |
-| 2014 年 5 月  | `vue-i18n`     | 为 Vue 应用提供符合框架直觉且深度结合响应式特性的国际化方案。                           | 深度集成 Vue 响应式系统，提供模板指令 (`v-t`)、`$t` 辅助函数，并支持在单文件组件内使用自定义 `<i18n>` 代码块。                           |
-| 2017 年 11 月 | `@nuxt/i18n`   | 处理 Nuxt 项目中的多语言 URL 动态路由、SEO hreflang 规范标签以及 SSR 注水一致性。       | 全栈式路由模块，可自动生成带前缀或独立域名的本地化路由、SEO Meta 头信息，并支持语言分片懒加载。                                          |
-| 2019 年 8 月  | `fluent-vue`   | 优雅应对 Vue 项目中多语言复杂的语法性、格位变化以及非对称语言表述结构。                 | 将 Mozilla 的 Project Fluent 语法规范深度接入 Vue，无需再为复杂的语法变体编写冗长嵌套的判断分支。                                        |
-| 2025 年 4 月  | `vue-intlayer` | 专为 Vue 3 Composition API 与 Nuxt 打造的原生 Intlayer 方案，彻底避免全局命名空间污染。 | 专为 Vue 3 依赖追踪打造的高效 `useIntlayer` Composable，具备清晰的组件级隔离、完备的 TypeScript 自动补全能力并支持直接连接可视化编辑器。 |
+| 首次发布      | 工具类库       | 作者                                        | 旨在解决的核心问题                                                                      | 关键创新亮点                                                                                                                             |
+| ------------- | -------------- | ------------------------------------------- | --------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------- |
+| 2014 年 5 月  | `vue-i18n`     | Kazupon (`@kazupon`)                        | 为 Vue 应用提供符合框架直觉且深度结合响应式特性的国际化方案。                           | 深度集成 Vue 响应式系统，提供模板指令 (`v-t`)、`$t` 辅助函数，并支持在单文件组件内使用自定义 `<i18n>` 代码块。                           |
+| 2017 年 11 月 | `@nuxt/i18n`   | Nuxt 社区                                   | 处理 Nuxt 项目中的多语言 URL 动态路由、SEO hreflang 规范标签以及 SSR 注水一致性。       | 全栈式路由模块，可自动生成带前缀或独立域名的本地化路由、SEO Meta 头信息，并支持语言分片懒加载。                                          |
+| 2020年8月     | `fluent-vue`   | Mozilla (`@mozilla`) / Demivan (`@demivan`) | 优雅应对 Vue 项目中多语言复杂的语法性、格位变化以及非对称语言表述结构。                 | 将 Mozilla 的 Project Fluent 语法规范深度接入 Vue，无需再为复杂的语法变体编写冗长嵌套的判断分支。                                        |
+| 2025年1月     | `vue-intlayer` | Aymeric Pineau (`@aymericzip`)              | 专为 Vue 3 Composition API 与 Nuxt 打造的原生 Intlayer 方案，彻底避免全局命名空间污染。 | 专为 Vue 3 依赖追踪打造的高效 `useIntlayer` Composable，具备清晰的组件级隔离、完备的 TypeScript 自动补全能力并支持直接连接可视化编辑器。 |
 
 </Tab>
 
 <Tab label="Angular" value="angular">
 
-| 首次发布     | 工具类库            | 旨在解决的核心问题                                                                                     | 关键创新亮点                                                                                                       |
-| ------------ | ------------------- | ------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------ |
-| 2017 年 2 月 | `ngx-translate`     | 无需针对每门语言单独打包多份构建产物，即可在 Angular 运行时实现动态多语言翻译。                        | 推出 `TranslateService` 与 `translate` Pipe，支持异步动态载入语言包并即时切换当前语言。                            |
-| 2019 年 7 月 | `@ngneat/transloco` | 解决早期 Angular 国际化工具中普遍存在的性能瓶颈、缺乏模块作用域隔离以及功能缺失等问题。                | 提供结构型指令 (`*transloco`)、按需加载特性模块的作用域文案隔离、SSR 服务端支持以及自动化提取 CLI 工具。           |
-| 2019 年 9 月 | `@angular/localize` | 现代化重构 Angular 内置的编译期 i18n 方案，避免每种语言都需要完整重新编译整个 TypeScript 项目。        | 引入带标签的模板字符串 `$localize`，由 Ivy 编译器引擎作为极速的构建后置步骤直接替换植入。                          |
-| 2021 年 2 月 | `@tolgee/ngx`       | 将多人协同的界面上下文翻译与应用快照采集流程整合进 Angular 日常开发工作流。                            | 提供与 Tolgee 直连的 Angular Pipe 与指令，方便直接在浏览器界面中查看并调整文案。                                   |
-| 2025 年 4 月 | `angular-intlayer`  | 专为现代 Angular 技术栈（Signals 响应式原语、Standalone 独立组件与 SSR）量身打造的原生 Intlayer 方案。 | 结合 Angular 变更检测特性的 Signal 响应式内容绑定，原生兼容 Standalone 依赖注入，并支持与可视化 CMS 保持实时同步。 |
+| 首次发布     | 工具类库            | 作者                                                         | 旨在解决的核心问题                                                                                     | 关键创新亮点                                                                                                       |
+| ------------ | ------------------- | ------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------ |
+| 2017 年 2 月 | `ngx-translate`     | Olivier Combe (`@ocombe`)                                    | 无需针对每门语言单独打包多份构建产物，即可在 Angular 运行时实现动态多语言翻译。                        | 推出 `TranslateService` 与 `translate` Pipe，支持异步动态载入语言包并即时切换当前语言。                            |
+| 2019 年 7 月 | `@ngneat/transloco` | Netanel Basal (`@NetanelBasal`) & Shahar Kazaz (`@shahar_k`) | 解决早期 Angular 国际化工具中普遍存在的性能瓶颈、缺乏模块作用域隔离以及功能缺失等问题。                | 提供结构型指令 (`*transloco`)、按需加载特性模块的作用域文案隔离、SSR 服务端支持以及自动化提取 CLI 工具。           |
+| 2019 年 9 月 | `@angular/localize` | Angular 团队 (@angular)                                      | 现代化重构 Angular 内置的编译期 i18n 方案，避免每种语言都需要完整重新编译整个 TypeScript 项目。        | 引入带标签的模板字符串 `$localize`，由 Ivy 编译器引擎作为极速的构建后置步骤直接替换植入。                          |
+| 2021 年 2 月 | `@tolgee/ngx`       | Jan Cizmar (`@jcizmar`)                                      | 将多人协同的界面上下文翻译与应用快照采集流程整合进 Angular 日常开发工作流。                            | 提供与 Tolgee 直连的 Angular Pipe 与指令，方便直接在浏览器界面中查看并调整文案。                                   |
+| 2026年3月    | `angular-intlayer`  | Aymeric Pineau (`@aymericzip`)                               | 专为现代 Angular 技术栈（Signals 响应式原语、Standalone 独立组件与 SSR）量身打造的原生 Intlayer 方案。 | 结合 Angular 变更检测特性的 Signal 响应式内容绑定，原生兼容 Standalone 依赖注入，并支持与可视化 CMS 保持实时同步。 |
 
 </Tab>
 
 <Tab label="Svelte 与 SvelteKit" value="svelte">
 
-| 首次发布      | 工具类库          | 旨在解决的核心问题                                                                 | 关键创新亮点                                                                                                           |
-| ------------- | ----------------- | ---------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------- |
-| 2018 年 7 月  | `svelte-i18n`     | 提供一套天然契合 Svelte 响应式 Stores 机制的声明式国际化库。                       | 依托 Store 封装的 `$t` 查找函数，确保在语言切换时对 DOM 节点执行细粒度的高效就地更新。                                 |
-| 2021 年 12 月 | `sveltekit-i18n`  | 在 SvelteKit 框架中整洁处理服务端渲染 (SSR) 与基于页面路由的代码分片与文案加载。   | 采用模块化加载架构，仅针对当前激活的 SvelteKit 路由抓取必要的文案条目与格式化工具。                                    |
-| 2021 年 11 月 | `@tolgee/svelte`  | 让 Svelte 应用能够便捷实现基于界面运行上下文的可视化文案编辑。                     | 提供深度集成 Tolgee 上下文编辑浮层和自动化界面截屏工具的 Svelte Store 绑定机制。                                       |
-| 2025 年 4 月  | `svelte-intlayer` | 专为 Svelte 5 全新 Runes 机制与 SvelteKit 框架量身定制的高性能 Intlayer 实现方案。 | 深度结合 Svelte 5 Runes (`$state`) 的响应式内容绑定，组件级 `.content` 独立声明文件，免配置构建插件与可视化 CMS 界面。 |
-| 2025 年 7 月  | `@wuchale/svelte` | 消除在 Svelte 组件中繁琐定义字典与频繁手动引入 `$t` 函数的固定模板负担。           | 提供专属 Svelte 预处理器，在构建期分析模板并直接把文本节点转换为零包装层的本地化产物。                                 |
+| 首次发布      | 工具类库          | 作者                           | 旨在解决的核心问题                                                                 | 关键创新亮点                                                                                                           |
+| ------------- | ----------------- | ------------------------------ | ---------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------- |
+| 2018 年 7 月  | `svelte-i18n`     | Kaisermann (`@kaisermann`)     | 提供一套天然契合 Svelte 响应式 Stores 机制的声明式国际化库。                       | 依托 Store 封装的 `$t` 查找函数，确保在语言切换时对 DOM 节点执行细粒度的高效就地更新。                                 |
+| 2021 年 12 月 | `sveltekit-i18n`  | Ivan Fevrier (`@ivanfevrier`)  | 在 SvelteKit 框架中整洁处理服务端渲染 (SSR) 与基于页面路由的代码分片与文案加载。   | 采用模块化加载架构，仅针对当前激活的 SvelteKit 路由抓取必要的文案条目与格式化工具。                                    |
+| 2021 年 11 月 | `@tolgee/svelte`  | Jan Cizmar (`@jcizmar`)        | 让 Svelte 应用能够便捷实现基于界面运行上下文的可视化文案编辑。                     | 提供深度集成 Tolgee 上下文编辑浮层和自动化界面截屏工具的 Svelte Store 绑定机制。                                       |
+| 2025年10月    | `svelte-intlayer` | Aymeric Pineau (`@aymericzip`) | 专为 Svelte 5 全新 Runes 机制与 SvelteKit 框架量身定制的高性能 Intlayer 实现方案。 | 深度结合 Svelte 5 Runes (`$state`) 的响应式内容绑定，组件级 `.content` 独立声明文件，免配置构建插件与可视化 CMS 界面。 |
+| 2025 年 7 月  | `@wuchale/svelte` | Kidus Adugna (`@K1DV5`)        | 消除在 Svelte 组件中繁琐定义字典与频繁手动引入 `$t` 函数的固定模板负担。           | 提供专属 Svelte 预处理器，在构建期分析模板并直接把文本节点转换为零包装层的本地化产物。                                 |
 
 </Tab>
 
 <Tab label="SolidJS" value="solid">
 
-| 首次发布     | 工具类库                 | 旨在解决的核心问题                                                               | 关键创新亮点                                                                                                                          |
-| ------------ | ------------------------ | -------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------- |
-| 2021 年 9 月 | `@solid-primitives/i18n` | 打造完美契合 SolidJS 超细粒度响应式更新范式的原生 i18n 基础原语。                | 基于 Signal 响应式原语的翻译解析机制，无需依赖虚拟 DOM 即可直接更新对应真实 DOM 节点，杜绝任何多余重渲染。                            |
-| 2025 年 4 月 | `solid-intlayer`         | 专为 SolidJS 及 SolidStart 框架特性深度优化的原生高性能 Intlayer 方案。          | 针对 Solid 细粒度响应式原语量身设计的轻量内容绑定，消除虚拟 DOM 开销，提供完整的 TypeScript Schema 智能补全，并无缝集成可视化编辑器。 |
-| 2026 年 6 月 | `@lingui/solid`          | 将编译期宏提取逻辑与完善的 ICU MessageFormat 语法解析能力扩展引入 SolidJS 领域。 | 针对 Solid 响应式架构精心优化的宏编译逻辑，在构建时将消息文本转换为运行时代价极低的精简结构。                                         |
+| 首次发布     | 工具类库                 | 作者                           | 旨在解决的核心问题                                                               | 关键创新亮点                                                                                                                          |
+| ------------ | ------------------------ | ------------------------------ | -------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------- |
+| 2021 年 9 月 | `@solid-primitives/i18n` | SolidJS 社区                   | 打造完美契合 SolidJS 超细粒度响应式更新范式的原生 i18n 基础原语。                | 基于 Signal 响应式原语的翻译解析机制，无需依赖虚拟 DOM 即可直接更新对应真实 DOM 节点，杜绝任何多余重渲染。                            |
+| 2025年7月    | `solid-intlayer`         | Aymeric Pineau (`@aymericzip`) | 专为 SolidJS 及 SolidStart 框架特性深度优化的原生高性能 Intlayer 方案。          | 针对 Solid 细粒度响应式原语量身设计的轻量内容绑定，消除虚拟 DOM 开销，提供完整的 TypeScript Schema 智能补全，并无缝集成可视化编辑器。 |
+| 2026 年 6 月 | `@lingui/solid`          | Tomáš Ehrlich (`@tricoder42`)  | 将编译期宏提取逻辑与完善的 ICU MessageFormat 语法解析能力扩展引入 SolidJS 领域。 | 针对 Solid 响应式架构精心优化的宏编译逻辑，在构建时将消息文本转换为运行时代价极低的精简结构。                                         |
 
 </Tab>
 
@@ -237,7 +237,7 @@ Jan Mühlemann 为快速成长的 React 社区带来了 `i18next` 适配，早
 
 ## JavaScript i18n 的四大架构发展阶段
 
-![JavaScript i18n 类库技术演进图谱](https://github.com/aymericzip/intlayer/blob/main/docs/assets/history_i18n.png?raw=true)
+![JavaScript i18n 类库技术演进图谱](https://github.com/aymericzip/intlayer/blob/main/docs/assets/history_i18n.webp?raw=true)
 
 回顾近十五年的技术探索，JavaScript 国际化的演化路径可划分为四个鲜明的架构纪元：
 
@@ -287,7 +287,7 @@ Jan Mühlemann 为快速成长的 React 社区带来了 `i18next` 适配，早
 
 随着通用大模型将高质量翻译的综合成本降低至极低水平，市场上也涌现出新一代工具：
 
-- 诸如 Paraglide 的 **linguo.dev** 或 **General Translation** (`gt-react`, `gt-next`) 等产品，尝试通过专属付费订阅与云端代理服务介入这一流程。
+- 诸如 **lingo.dev** 或 **General Translation** (`gt-react`, `gt-next`) 等产品，尝试通过专属付费订阅与云端代理服务介入这一流程。
 - 相比之下，**Intlayer** 选择在开源 CLI 中直接提供原生的 AI 自动化翻译支持，允许团队直接接入自有的 API 密钥（如 OpenAI、Anthropic、Mistral 或 Google Gemini）。没有中间商加价与订阅捆绑，纯粹按所选模型的底层实际调用消耗计费。
 
 ### 超越传统 i18n：面向未来的多语言内容体系