@intlayer/docs 8.9.4-canary.0 → 8.9.5

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

@@ -0,0 +1,333 @@
+---
+createdAt: 2026-05-10
+updatedAt: 2026-05-10
+title: Plugin Sync PO
+description: Đồng bộ hóa từ điển Intlayer với các tệp Gettext PO. Giữ nguyên i18n hiện tại của bạn trong khi sử dụng Intlayer để quản lý, dịch và kiểm tra các tin nhắn của bạn.
+keywords:
+  - Intlayer
+  - Sync PO
+  - Gettext
+  - i18n
+  - dịch thuật
+slugs:
+  - doc
+  - plugin
+  - sync-po
+youtubeVideo: https://www.youtube.com/watch?v=MpGMxniDHNg
+history:
+  - version: 8.9.4
+    date: 2026-05-10
+    changes: "Tài liệu ban đầu cho plugin Sync PO"
+---
+
+# Sync PO (cầu nối i18n) - Đồng bộ hóa PO với hỗ trợ ICU / i18next
+
+Sử dụng Intlayer như một tiện ích bổ sung cho ngăn xếp i18n hiện có của bạn. Plugin này giữ cho các tin nhắn Gettext PO của bạn đồng bộ với từ điển Intlayer để bạn có thể:
+
+- Giữ nguyên quy trình dịch thuật dựa trên PO hiện tại của bạn.
+- Quản lý và dịch các tin nhắn của bạn với Intlayer (CLI, CI, nhà cung cấp, CMS) mà không cần cấu trúc lại ứng dụng của bạn.
+- Cung cấp các hướng dẫn và nội dung SEO nhắm mục tiêu đến từng hệ sinh thái, đồng thời đề xuất Intlayer như một lớp quản lý PO.
+
+Ghi chú và phạm vi hiện tại:
+
+- Việc bên ngoài hóa sang CMS hoạt động cho các bản dịch và văn bản cổ điển.
+- Chưa hỗ trợ cho việc chèn, số nhiều/ICU hoặc các tính năng runtime nâng cao của các thư viện khác trong chính các mục nhập PO.
+- Trình chỉnh sửa trực quan chưa được hỗ trợ cho các đầu ra i18n của bên thứ ba.
+
+### Khi nào nên sử dụng plugin này
+
+- Bạn đã sử dụng các tệp Gettext PO cho các bản dịch của mình.
+- Bạn muốn điền dữ liệu có hỗ trợ AI, kiểm tra trong CI và vận hành nội dung mà không cần thay đổi runtime kết xuất của mình.
+
+## Cài đặt
+
+```bash
+pnpm add -D @intlayer/sync-po-plugin
+# hoặc
+npm i -D @intlayer/sync-po-plugin
+```
+
+## Plugin
+
+Gói này cung cấp hai plugin:
+
+- `loadPO`: Tải các tệp PO vào từ điển Intlayer.
+  - Plugin này được sử dụng để tải các tệp PO từ một nguồn và sẽ được tải vào từ điển Intlayer. Nó có thể quét toàn bộ mã nguồn và tìm kiếm các tệp PO cụ thể.
+    Plugin này có thể được sử dụng:
+    - nếu bạn sử dụng một thư viện i18n áp đặt một vị trí cụ thể để tải các tệp PO của bạn, nhưng bạn muốn đặt khai báo nội dung của mình ở bất cứ đâu bạn muốn trong mã nguồn.
+    - Nó cũng có thể được sử dụng nếu bạn muốn tìm nạp các tin nhắn của mình từ một nguồn từ xa (ví dụ: CMS, API, v.v.) và lưu trữ các tin nhắn của bạn trong các tệp PO.
+
+  > Bên dưới, plugin này sẽ quét toàn bộ mã nguồn và tìm kiếm các tệp PO cụ thể và tải chúng vào từ điển Intlayer.
+  > Lưu ý rằng plugin này sẽ không ghi kết quả đầu ra và các bản dịch ngược lại vào các tệp PO.
+
+- `syncPO`: Đồng bộ hóa các tệp PO với từ điển Intlayer.
+  - Plugin này được sử dụng để đồng bộ hóa các tệp PO với từ điển Intlayer. Nó có thể quét vị trí đã cho và tải PO khớp với mẫu cho các tệp PO cụ thể. Plugin này hữu ích nếu bạn muốn nhận được các lợi ích của Intlayer trong khi sử dụng một thư viện i18n khác.
+
+## Sử dụng cả hai plugin
+
+```ts fileName="intlayer.config.ts"
+import { Locales, type IntlayerConfig } from "intlayer";
+import { loadPO, syncPO } from "@intlayer/sync-po-plugin";
+
+const config: IntlayerConfig = {
+  internationalization: {
+    locales: [Locales.ENGLISH, Locales.FRENCH, Locales.SPANISH],
+    defaultLocale: Locales.ENGLISH,
+  },
+
+  // Giữ các tệp PO hiện tại của bạn đồng bộ với từ điển Intlayer
+  plugins: [
+    /**
+     * Sẽ tải tất cả các tệp PO trong src khớp với mẫu {key}.i18n.po
+     */
+    loadPO({
+      source: ({ key }) => `./src/**/${key}.i18n.po`,
+      locale: Locales.ENGLISH,
+      priority: 1, // Đảm bảo các tệp PO này được ưu tiên hơn các tệp tại `./locales/en/${key}.po`
+    }),
+    /**
+     * Sẽ tải và ghi kết quả đầu ra và bản dịch ngược lại vào các tệp PO trong thư mục locales
+     */
+    syncPO({
+      source: ({ key, locale }) => `./locales/${locale}/${key}.po`,
+      priority: 0,
+    }),
+  ],
+};
+
+export default config;
+```
+
+## Plugin `syncPO`
+
+### Bắt đầu nhanh
+
+Thêm plugin vào `intlayer.config.ts` của bạn và trỏ nó vào cấu trúc PO hiện có của bạn.
+
+```ts fileName="intlayer.config.ts"
+import { Locales, type IntlayerConfig } from "intlayer";
+import { syncPO } from "@intlayer/sync-po-plugin";
+
+const config: IntlayerConfig = {
+  internationalization: {
+    locales: [Locales.ENGLISH, Locales.FRENCH, Locales.SPANISH],
+    defaultLocale: Locales.ENGLISH,
+  },
+
+  // Giữ các tệp PO hiện tại của bạn đồng bộ với từ điển Intlayer
+  plugins: [
+    syncPO({
+      // Bố cục theo từng locale, từng namespace
+      source: ({ key, locale }) => `./locales/${locale}/${key}.po`,
+    }),
+  ],
+};
+
+export default config;
+```
+
+Thay thế: một tệp duy nhất cho mỗi locale:
+
+```ts fileName="intlayer.config.ts"
+import { Locales, type IntlayerConfig } from "intlayer";
+import { syncPO } from "@intlayer/sync-po-plugin";
+
+const config: IntlayerConfig = {
+  internationalization: {
+    locales: [Locales.ENGLISH, Locales.FRENCH],
+    defaultLocale: Locales.ENGLISH,
+  },
+  plugins: [
+    syncPO({
+      source: ({ locale }) => `./locales/${locale}.po`,
+    }),
+  ],
+};
+
+export default config;
+```
+
+#### Cách hoạt động
+
+- Đọc: plugin khám phá các tệp PO từ trình xây dựng `source` của bạn và tải chúng dưới dạng từ điển Intlayer.
+- Ghi: sau khi xây dựng và điền dữ liệu, nó ghi PO đã bản địa hóa ngược lại các đường dẫn tương ứng (với các tiêu đề Gettext thích hợp).
+- Tự động điền: plugin khai báo một đường dẫn `autoFill` cho mỗi từ điển. Chạy `intlayer fill` sẽ chỉ cập nhật các bản dịch bị thiếu trong các tệp PO của bạn theo mặc định.
+
+API:
+
+```ts
+syncPO({
+  source: ({ key, locale }) => string, // bắt buộc
+  location?: string, // nhãn tùy chọn, mặc định: "sync-po::path/to/source"
+  priority?: number, // ưu tiên tùy chọn để giải quyết xung đột, mặc định: 0
+});
+```
+
+### Nhiều nguồn PO và mức độ ưu tiên
+
+Bạn có thể thêm nhiều plugin `syncPO` để đồng bộ hóa các nguồn PO khác nhau. Điều này hữu ích khi bạn có nhiều nguồn dịch hoặc cấu trúc PO khác nhau trong dự án của mình.
+
+#### Hệ thống ưu tiên
+
+Khi nhiều plugin nhắm mục tiêu cùng một khóa từ điển, tham số `priority` sẽ xác định plugin nào được ưu tiên:
+
+- Số ưu tiên cao hơn sẽ thắng số thấp hơn
+- Mức độ ưu tiên mặc định của các tệp `.content` là `0`
+- Mức độ ưu tiên mặc định của các plugin là `0`
+- Các plugin có cùng mức độ ưu tiên được xử lý theo thứ tự chúng xuất hiện trong cấu hình
+
+```ts fileName="intlayer.config.ts"
+import { Locales, type IntlayerConfig } from "intlayer";
+import { syncPO } from "@intlayer/sync-po-plugin";
+
+const config: IntlayerConfig = {
+  internationalization: {
+    locales: [Locales.ENGLISH, Locales.FRENCH],
+    defaultLocale: Locales.ENGLISH,
+  },
+
+  plugins: [
+    // Nguồn PO chính (mức ưu tiên cao nhất)
+    syncPO({
+      source: ({ key, locale }) => `./locales/${locale}/${key}.po`,
+      location: "main-translations",
+      priority: 10,
+    }),
+
+    // Nguồn PO dự phòng (mức ưu tiên thấp hơn)
+    syncPO({
+      source: ({ locale }) => `./fallback-locales/${locale}.po`,
+      location: "fallback-translations",
+      priority: 5,
+    }),
+
+    // Nguồn PO cũ (mức ưu tiên thấp nhất)
+    syncPO({
+      source: ({ locale }) => `/my/other/app/legacy/${locale}/messages.po`,
+      location: "legacy-translations",
+      priority: 1,
+    }),
+  ],
+};
+
+export default config;
+```
+
+## Plugin Load PO
+
+### Bắt đầu nhanh
+
+Thêm plugin vào `intlayer.config.ts` của bạn để nạp các tệp PO hiện có dưới dạng từ điển Intlayer. Plugin này chỉ dành cho việc đọc (không ghi vào đĩa):
+
+```ts fileName="intlayer.config.ts"
+import { Locales, type IntlayerConfig } from "intlayer";
+import { loadPO } from "@intlayer/sync-po-plugin";
+
+const config: IntlayerConfig = {
+  internationalization: {
+    locales: [Locales.ENGLISH, Locales.FRENCH, Locales.SPANISH],
+    defaultLocale: Locales.ENGLISH,
+  },
+
+  plugins: [
+    // Nạp các tin nhắn PO nằm ở bất kỳ đâu trong cây mã nguồn của bạn
+    loadPO({
+      source: ({ key }) => `./src/**/${key}.i18n.po`,
+      // Tải một locale duy nhất cho mỗi phiên bản plugin (mặc định là defaultLocale của cấu hình)
+      locale: Locales.ENGLISH,
+      priority: 0,
+    }),
+  ],
+};
+
+export default config;
+```
+
+Thay thế: bố cục theo từng locale, vẫn chỉ dành cho việc đọc (chỉ locale được chọn mới được tải):
+
+```ts fileName="intlayer.config.ts"
+import { Locales, type IntlayerConfig } from "intlayer";
+import { loadPO } from "@intlayer/sync-po-plugin";
+
+const config: IntlayerConfig = {
+  internationalization: {
+    locales: [Locales.ENGLISH, Locales.FRENCH],
+    defaultLocale: Locales.ENGLISH,
+  },
+  plugins: [
+    loadPO({
+      // Chỉ các tệp cho Locales.FRENCH mới được nạp từ mẫu này
+      source: ({ key, locale }) => `./locales/${locale}/${key}.po`,
+      locale: Locales.FRENCH,
+    }),
+  ],
+};
+
+export default config;
+```
+
+### Cách hoạt động
+
+- Khám phá: xây dựng một glob từ trình xây dựng `source` của bạn và thu thập các tệp PO phù hợp.
+- Nạp: tải từng tệp PO dưới dạng từ điển Intlayer với `locale` được cung cấp.
+- Chỉ đọc: không ghi hoặc định dạng các tệp đầu ra; sử dụng `syncPO` nếu bạn cần đồng bộ hóa hai chiều.
+- Sẵn sàng tự động điền: xác định một đường dẫn `fill` để `intlayer content fill` có thể điền các khóa bị thiếu.
+
+### API
+
+```ts
+loadPO({
+  // Xây dựng các đường dẫn đến PO của bạn. `locale` là tùy chọn nếu cấu trúc của bạn không có phân đoạn locale
+  source: ({ key, locale }) => string,
+
+  // Locale mục tiêu cho các từ điển được tải bởi phiên bản plugin này
+  // Mặc định là configuration.internationalization.defaultLocale
+  locale?: Locale,
+
+  // Nhãn tùy chọn để xác định nguồn
+  location?: string, // mặc định: "plugin"
+
+  // Mức độ ưu tiên được sử dụng để giải quyết xung đột với các nguồn khác
+  priority?: number, // mặc định: 0
+});
+```
+
+### Hành vi và quy ước
+
+- Nếu mặt nạ `source` của bạn bao gồm một trình giữ chỗ locale, chỉ các tệp cho `locale` được chọn mới được nạp.
+- Nếu không có phân đoạn `{key}` trong mặt nạ của bạn, khóa từ điển là "index".
+- Các khóa được lấy từ đường dẫn tệp bằng cách thay thế trình giữ chỗ `{key}` trong trình xây dựng `source` của bạn.
+- Plugin chỉ sử dụng các tệp được khám phá và không tạo ra các locale hoặc khóa bị thiếu.
+- Đường dẫn `fill` được suy ra từ `source` của bạn và được sử dụng để cập nhật các giá trị bị thiếu thông qua CLI khi bạn chọn tham gia.
+
+## Giải quyết xung đột
+
+Khi cùng một khóa dịch tồn tại trong nhiều nguồn PO:
+
+1. Plugin có mức độ ưu tiên cao nhất sẽ xác định giá trị cuối cùng
+2. Các nguồn ưu tiên thấp hơn được sử dụng làm dự phòng cho các khóa bị thiếu
+3. Điều này cho phép bạn duy trì các bản dịch cũ trong khi dần chuyển sang các cấu trúc mới
+
+## CLI
+
+Các tệp PO đã đồng bộ hóa sẽ được coi như các tệp `.content` khác. Điều đó có nghĩa là, tất cả các lệnh intlayer sẽ khả dụng cho các tệp PO đã đồng bộ hóa. Bao gồm:
+
+- `intlayer content test` để kiểm tra xem có bản dịch nào bị thiếu không
+- `intlayer content list` để liệt kê các tệp PO đã đồng bộ hóa
+- `intlayer content fill` để điền các bản dịch bị thiếu
+- `intlayer content push` để đẩy các tệp PO đã đồng bộ hóa
+- `intlayer content pull` để kéo các tệp PO đã đồng bộ hóa
+
+Xem [Intlayer CLI](https://github.com/aymericzip/intlayer/blob/main/docs/docs/en/cli/index.md) để biết thêm chi tiết.
+
+## Hạn chế (hiện tại)
+
+- Không hỗ trợ chèn hoặc số nhiều/ICU khi nhắm mục tiêu đến các thư viện bên thứ ba.
+- Trình chỉnh sửa trực quan chưa khả dụng cho các runtime không phải Intlayer.
+- Chỉ đồng bộ hóa PO; các định dạng danh mục không phải PO không được hỗ trợ.
+
+## Tại sao điều này lại quan trọng
+
+- Chúng ta có thể đề xuất các giải pháp i18n đã được thiết lập và định vị Intlayer như một tiện ích bổ sung.
+- Chúng ta tận dụng SEO/từ khóa của họ bằng các hướng dẫn kết thúc bằng việc đề xuất Intlayer để quản lý PO.
+- Mở rộng đối tượng có thể tiếp cận từ “các dự án mới” sang “bất kỳ nhóm nào đã sử dụng i18n”.

package/docs/zh/benchmark/nextjs.md

@@ -61,6 +61,13 @@ i18n 库的另一个影响是开发速度变慢。将组件转换为支持多语
 
 Intlayer 尝试在这些维度上进行优化。
 
+## TL;DR
+
+- **Intlayer** & **next-translate**: Next.js 性能的最佳选择，提供最小的体积和最佳的静态渲染支持。
+- **next-intl**: 最热门的选择，但体积庞大且对于大型应用优化复杂。
+- **next-i18next**: 流行且插件丰富，但打包体积显著（约为 Intlayer 的 3 倍）。
+- **应避免**: **gt-next** 和 **lingo.dev**，因为存在严重的性能问题、供应商锁定以及导致构建失败的 Bug。
+
 ## 测试你的应用
 
 为了发现这些问题，我构建了一个免费扫描器，你可以在[这里](https://intlayer.org/i18n-seo-scanner)试用。
@@ -99,14 +106,14 @@ Intlayer 尝试在这些维度上进行优化。
 在此基准测试中，我们对比了以下库：
 
 - `Base App`（无 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 @@ Intlayer 尝试在这些维度上进行优化。
 
 **(General Translation)** (`gt-next@6.16.5`):
 
-- 对于一个 110kb 的应用，`gt-react` 额外增加了超过 440kb。
+- 对于一个 110kb 的应用，`gt-next` 额外增加了超过 440kb。
 - 第一次使用 General Translation 构建就提示 `Quota Exceeded, please upgrade your plan`（配额超出，请升级计划）。
 - 翻译未渲染；我收到了错误 `Error: <T> used on the client-side outside of <GTProvider>`，这似乎是库的一个 Bug。
-- 在实施 **gt-tanstack-start-react** 时，我还遇到了该库的一个[问题](https://github.com/generaltranslation/gt/issues/1210#event-24510646961)：`does not provide an export named 'printAST' - @formatjs/icu-messageformat-parser`，这导致应用崩溃。在报告此问题后，维护者在 24 小时内修复了它。
+- 在实施 **gt-next** 时，我还遇到了该库的一个[问题](https://github.com/generaltranslation/gt/issues/1210#event-24510646961)：`does not provide an export named 'printAST' - @formatjs/icu-messageformat-parser`，这导致应用崩溃。在报告此问题后，维护者在 24 小时内修复了它。
 - 该库阻塞了 Next.js 页面的静态渲染。
 
 **(Lingo.dev)** (`@lingo.dev/compiler@0.4.0`):
@@ -186,9 +193,11 @@ Intlayer 尝试在这些维度上进行优化。
 就个人而言，我不喜欢每次推送到代码库前都要重新生成 JS 文件，这通过 PR 产生了持续的合并冲突风险。该工具似乎也更关注 Vite 而非 Next.js。
 最后，与其他解决方案相比，Paraglide 不使用存储（如 React Context）来检索当前语言环境以渲染内容。对于解析的每个节点，它都会从 localStorage / Cookie 等请求语言环境。这导致了影响组件响应性的不必要逻辑执行。
 
+> 关于 Paraglide 的说明：该解决方案通过将代码注入到你的代码库中进行导入，因此在基准测试报告中，“库体积”指标几乎为 0。代码生成是一件好事，因为所使用的函数将仅包含必要的逻辑（全前缀 vs 无前缀、Cookie vs 存储等）。相比之下，Intlayer 通过在构建中注入环境变量来强制打包工具根据逻辑对内容进行 Tree-shaking。得益于此，Paraglide 和 Intlayer 最终成为比 i18next 或 next-intl 轻 6 到 10 倍的解决方案。
+
 ### 3 — 可接受的解决方案
 
-**(Tolgee)** (`tolgee@7.0.0`):
+**(Tolgee)** (`@tolgee/react@7.0.0`):
 
 `Tolgee` 解决了前面提到的许多问题。我发现它比类似的工具更难采用。它不提供类型安全，这增加了在编译时捕捉缺失键的难度。我不得不使用自己的函数封装 Tolgee 的函数，以添加缺失键检测。
 
@@ -216,7 +225,7 @@ Intlayer 尝试在这些维度上进行优化。
 
 如果你喜欢 `t()` 风格的 API，`next-translate` 是我的主要推荐方案。它通过 `next-translate-plugin` 优雅运作，利用 Webpack / Turbopack loader 通过 `getStaticProps` 加载命名空间。它也是这些方案中最轻量的（约 2.5kb）。对于命名空间拆分，在配置中为每个页面或路由定义命名空间的设计非常周到，比 **next-intl** 或 **next-i18next** 等主要替代方案更易于维护。在版本 `3.1.2` 中，我注意到静态渲染无法工作，Next.js 会回退到动态渲染。
 
-**(Intlayer)** (`next-intlayer@8.7.5`):
+**(Intlayer)** (`next-intlayer@8.7.12`):
 
 出于客观性考量，我不会亲自评价 `next-intlayer`，因为这是我自己的解决方案。
 

package/docs/zh/benchmark/solid.md

@@ -0,0 +1,155 @@
+---
+createdAt: 2026-04-20
+updatedAt: 2026-04-21
+title: 2026 年 Solid 最佳 i18n 解决方案 - 基准报告
+description: 比较 Solid 国际化（i18n）库，如 solid-primitives、solid-i18next 和 Intlayer。关于包大小、泄漏和反应性的详细性能报告。
+keywords:
+  - benchmark
+  - i18n
+  - intl
+  - solid
+  - performance
+  - 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: "初始化基准"
+---
+
+# Solid i18n 库 - 2026 基准报告
+
+此页面是 Solid 上 i18n 解决方案的基准报告。
+
+## 目录
+
+<Toc/>
+
+## 交互式基准
+
+<I18nBenchmark framework="vite-solid" vertical/>
+
+## 结果参考：
+
+<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
+
+查看完整的基准仓库 [此处](https://github.com/intlayer-org/benchmark-i18n/tree/main)。
+
+## 简介
+
+国际化解决方案是 Solid 应用中最重的依赖项之一。主要风险是发送不必要的内容：单个路由包中包含其他页面和其他语言的翻译。
+
+随着应用增长，这个问题会迅速增加发送到客户端의 JavaScript，并减慢导航速度。
+
+实际上，对于优化最差的实现，国际化页面的重量可能是非 i18n 版本的几倍。
+
+另一个影响是开发者体验（DX）：如何声明内容、类型、命名空间组织、动态加载以及语言更改时的反应性。
+
+## TL;DR
+
+- **Intlayer**: 需要高级功能和优化的专业 Solid 应用的推荐选择（v8.7.12）。
+- **@solid-primitives/i18n**: 简单项目的绝佳轻量级替代方案，但缺乏延迟加载等高级功能。
+- **solid-i18next**: 标准但沉重的选项（约为 Intlayer 的 4.7 倍），具有与 React i18next 相同的缺点。
+- **Paraglide**: 创新的方法，但在某些设置中 DX 复杂且存在 tree-shaking 问题。
+
+## 测试您的应用
+
+为了快速发现 i18n 泄漏问题，我建立了一个免费扫描仪，可在 [此处](https://intlayer.org/i18n-seo-scanner) 试用。
+
+<iframe src="https://intlayer.org/i18n-seo-scanner" width="100%" height="600px" style="border:none;"/>
+
+## 问题所在
+
+限制多语言应用成本有两个关键杠杆：
+
+- 按页面 / 命名空间拆分内容，这样在不需要时就不会加载整个字典
+- 仅在需要时动态加载正确的语言
+
+了解这些方案的技术限制：
+
+**动态加载**
+
+如果没有动态加载，大多数解决方案会从首次渲染开始将消息保留在内存中，这对于具有许多路由和语言的应用会产生显著开销。
+
+使用动态加载，您接受一个权衡：减少初始 JS，但有时在切换语言时会有额外的请求。
+
+**内容拆分**
+
+围绕 `t('a.b.c')` 构建的语法非常方便，但往往鼓励在运行时保留大型 JSON 对象。这种模式使 tree-shaking 变得困难，除非库提供真正的按页面拆分策略。
+
+## 研究方法
+
+在此基准测试中，我们比较了以下库：
+
+- `Base App`（无 i18n 库）
+- `solid-intlayer` (v8.7.12)
+- `@solid-primitives/i18n` (v2.2.1)
+- `solid-i18next` (v17.0.2)
+- `@inlang/paraglide-js` (v2.17.0)
+
+框架是 `Solid`，应用包含 **10 个页面** 和 **10 种语言**。
+
+我们比较了 **四种加载策略**：
+
+| 策略         | 无命名空间（全局）                     | 具有命名空间（分层/scoped）                             |
+| :----------- | :------------------------------------- | :------------------------------------------------------ |
+| **静态加载** | **Static**: 启动时所有内容都在内存中。 | **Scoped static**: 按命名空间拆分；启动时加载所有内容。 |
+| **动态加载** | **Dynamic**: 按需按语言加载。          | **Scoped dynamic**: 按命名空间和语言进行细粒度加载。    |
+
+## 策略摘要
+
+- **静态 (Static)**: 简单；初始加载后无网络延迟。缺点：包体积大。
+- **动态 (Dynamic)**: 减轻初始重量（懒加载）。当您有多种语言时非常理想。
+- **分层静态 (Scoped static)**: 保持代码有序（逻辑分离），无需复杂的额外网络请求。
+- **分层动态 (Scoped dynamic)**: _代码拆分_ 和性能的最佳方法。通过仅加载当前视图和活动语言所需的内容来最小化内存使用。
+
+## 结果详情
+
+### 1 - 应当避免的解决方案
+
+> Solid 生态系统中没有明确应当避免的解决方案。
+
+### 2 - 可接受的解决方案
+
+**(solid-i18next)** (`solid-i18next@17.0.2`):
+
+`solid-i18next` 可能是最受欢迎的选项，因为它是最早满足 JavaScript 应用 i18n 需求的解决方案之一。它还拥有一套广泛的社区插件来解决特定问题。
+
+该包很重（~14.6kb，约为 `solid-intlayer` 的 4.7 倍）。
+
+尽管如此，它与基于 `t('a.b.c')` 构建的栈具有相同的主要缺点：优化是可能的，但非常耗时，且大型项目面临不良实践（命名空间 + 动态加载 + 类型）的风险。
+
+**(@solid-primitives/i18n)** (`@solid-primitives/i18n@2.2.1`):
+
+Solid primitive 非常轻量且高效，我推荐将其用于轻量级项目，但对于包含 cookie 管理、代理重定向、格式化器等在内的专业解决方案，它可能会迅速显现功能不足。
+它还缺乏延迟加载和分层命名空间以进行页面大小优化。
+
+**(Paraglide)** (`@inlang/paraglide-js@2.17.0`):
+
+`Paraglide` 提供了一种创新且深思熟虑的方法。尽管如此，在此基准测试中，他们宣传的 tree-shaking 在我的实现中没有按预期工作。工作流程和 DX 也比其他选项更复杂。
+我个人不喜欢在每次推送前重新生成 JS 文件，这会通过 PR 在开发者之间造成持续的合并冲突风险。
+最后，与其他解决方案相比，Paraglide 不使用 store（例如 Solid signal）来检索当前语言以渲染内容。对于解析的每个节点，它都会从 localStorage / cookie 等请求语言。这导致执行不必要的逻辑，从而影响组件的反应性。
+
+### 3 - 建议
+
+**(Intlayer)** (`solid-intlayer@8.7.12`):
+
+出于客观性考虑，我个人不会对 `solid-intlayer` 做出评价，因为它是我的个人解决方案。
+
+### 个人笔记
+
+此笔记仅代表个人观点，不影响基准测试结果。尽管如此，在 i18n 领域，您经常会看到围绕 `const t = useTranslation('xx')` + `<>{t('xx.xx')}</>` 模式的翻译内容共识。
+
+在 Solid 应用中，将函数作为 `JSX.Element` 注入在我的观点中是一种反模式。它还增加了可避免的复杂性和 JavaScript 执行开销（即使几乎察觉不到）。