@intlayer/docs 9.5.1 → 9.5.2

package/docs/zh/benchmark/nextjs.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2026-04-20
-updatedAt: 2026-05-18
+updatedAt: 2026-09-11
 title: 2026 年 Next.js 最佳 i18n 解决方案 - 基准测试报告
 description: 对比 next-intl、next-i18next 和 Intlayer 等 Next.js 国际化 (i18n) 库。关于打包体积、泄漏和响应性的详细性能报告。
 keywords:
@@ -17,6 +17,9 @@ slugs:
 author: aymericzip
 applicationTemplate: https://github.com/intlayer-org/benchmark-i18n
 history:
+  - version: 9.5.1
+    date: 2026-09-11
+    changes: "更新基准测试结果"
   - version: 8.9.8
     date: 2026-05-18
     changes: "添加 GitHub 明星对比"
@@ -56,7 +59,7 @@ style="border:none;"
 
 随着应用规模的增长，打包体积会呈指数级增长，这会明显影响性能。
 
-例如，在最糟糕的情况下，国际化后的页面体积可能会增加接近 4 倍。
+例如，在最糟糕的情况下，国际化后的页面体积可能会增加接近 2 倍。
 
 i18n 库的另一个影响是开发速度变慢。将组件转换为支持多语言的内容非常耗时。
 
@@ -68,7 +71,7 @@ Intlayer 尝试在这些维度上进行优化。
 
 - **Intlayer** & **next-translate**: Next.js 性能的最佳选择，提供最小的体积和最佳的静态渲染支持。
 - **next-intl**: 最热门的选择，但体积庞大且对于大型应用优化复杂。
-- **next-i18next**: 流行且插件丰富，但打包体积显著（约为 Intlayer 的 3 倍）。
+- **next-i18next**: 流行且插件丰富，但打包体积显著（约为 Intlayer 的 3.5 倍）。
 - **应避免**: **gt-next** 和 **lingo.dev**，因为存在严重的性能问题、供应商锁定以及导致构建失败的 Bug。
 
 ## 测试你的应用
@@ -109,19 +112,21 @@ Intlayer 尝试在这些维度上进行优化。
 在此基准测试中，我们对比了以下库：
 
 - `Base App`（无 i18n 库）
-- `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-intlayer` (v9.5.1)
+- [`@intlayer/next-intl`](https://github.com/aymericzip/intlayer/blob/main/docs/docs/zh/compat/next-intl.md) (v9.5.1)
+- [`@intlayer/next-i18next`](https://github.com/aymericzip/intlayer/blob/main/docs/docs/zh/compat/next-i18next.md) (v9.5.1)
+- `next-i18next` (v16.3.0)
+- `next-intl` (v4.14.2)
+- `@lingui/core` (v6.6.0)
+- `next-translate` (v3.2.0)
 - `next-international` (v1.3.1)
 - `@inlang/paraglide-js` (v2.15.1)
-- `@tolgee/react` (v7.0.0)
-- `@lingo.dev/compiler` (v0.4.0)
-- `wuchale` (v0.22.11)
-- `gt-next` (v6.16.5)
+- `@tolgee/react` (v7.2.0)
+- `@lingo.dev/compiler` (v0.4.12)
+- `wuchale` (v0.26.6)
+- `gt-next` (v11.1.24)
 
-我使用了 `Next.js` 版本 `16.2.4` 以及 App Router。
+我使用了 `Next.js` 版本 `16.3.4` 以及 App Router。
 
 我构建了一个拥有 **10 个页面**和 **10 种语言**的多语言应用。
 
@@ -175,15 +180,15 @@ GitHub 星数是项目受欢迎程度、社区信任和长期相关性的有力
 
 遇到的问题：
 
-**(General Translation)** (`gt-next@6.16.5`):
+**(General Translation)** (`gt-next@11.1.24`):
 
-- 对于一个 110kb 的应用，`gt-next` 额外增加了超过 440kb。
+- 对于一个 141kb 的应用，`gt-next` 额外增加了超过 50kb。
 - 第一次使用 General Translation 构建就提示 `Quota Exceeded, please upgrade your plan`（配额超出，请升级计划）。
 - 翻译未渲染；我收到了错误 `Error: <T> used on the client-side outside of <GTProvider>`，这似乎是库的一个 Bug。
 - 在实施 **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`):
+**(Lingo.dev)** (`@lingo.dev/compiler@0.4.12`):
 
 - AI 配额超出，完全阻塞了构建--这意味着不付钱就无法发布到生产环境。
 - 编译器丢失了近 40% 的翻译内容。我不得不将所有的 `.map` 重写为扁平的组件块才使其工作。
@@ -192,7 +197,7 @@ GitHub 星数是项目受欢迎程度、社区信任和长期相关性的有力
 
 ### 2 - 实验性解决方案
 
-**(Wuchale)** (`wuchale@0.22.11`):
+**(Wuchale)** (`wuchale@0.26.6`):
 
 `Wuchale` 背后的想法很有趣，但尚不可行。我遇到了响应性问题，不得不强制重新渲染 Provider 才能使应用工作。文档也相当不清晰，增加了上手难度。
 
@@ -202,21 +207,21 @@ GitHub 星数是项目受欢迎程度、社区信任和长期相关性的有力
 就个人而言，我不喜欢每次推送到代码库前都要重新生成 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 倍的解决方案。
+> 关于 Paraglide 的说明：该解决方案通过将代码注入到你的代码库中进行导入，因此在基准测试报告中，“库体积”指标几乎为 0。代码生成是一件好事，因为所使用的函数将仅包含必要的逻辑（全前缀 vs 无前缀、Cookie vs 存储等）。相比之下，Intlayer 通过在构建中注入环境变量来强制打包工具根据逻辑对内容进行 Tree-shaking。得益于此，Paraglide 和 Intlayer 最终成为比 i18next 或 next-intl 轻 3 到 8 倍的解决方案。
 
 ### 3 - 可接受的解决方案
 
-**(Tolgee)** (`@tolgee/react@7.0.0`):
+**(Tolgee)** (`@tolgee/react@7.2.0`):
 
 `Tolgee` 解决了前面提到的许多问题。我发现它比类似的工具更难采用。它不提供类型安全，这增加了在编译时捕捉缺失键的难度。我不得不使用自己的函数封装 Tolgee 的函数，以添加缺失键检测。
 
-**(Next Intl)** (`next-intl@4.9.1`):
+**(Next Intl)** (`next-intl@4.14.2`):
 
-`next-intl` 是目前最热门的选项，也是 AI Agent 推荐最多的，但在我看来这是错误的。入门很容易，但在实践中，减少泄漏的优化非常复杂。结合动态加载 + 命名空间 + TypeScript 类型会极大降低开发速度。包体积也相当大（`NextIntlClientProvider` + `useTranslations` 约为 13kb，是 `next-intlayer` 的两倍多）。**next-intl** 曾会阻塞 Next.js 页面的静态渲染。它提供了一个名为 `setRequestLocale()` 的辅助工具。对于 `en.json` / `fr.json` 这样的集中式文件，这似乎得到了部分解决，但当内容拆分为 `en/shared.json` / `fr/shared.json` / `es/shared.json` 等命名空间时，静态渲染仍然会失效。
+`next-intl` 是目前最热门的选项，也是 AI Agent 推荐最多的，但在我看来这是错误的。入门很容易，但在实践中，减少泄漏的优化非常复杂。结合动态加载 + 命名空间 + TypeScript 类型会极大降低开发速度。包体积也相当大（`NextIntlClientProvider` + `useTranslations` 约为 14.7kb，是 `next-intlayer` 的 2.5 倍多）。**next-intl** 曾会阻塞 Next.js 页面的静态渲染。它提供了一个名为 `setRequestLocale()` 的辅助工具。对于 `en.json` / `fr.json` 这样的集中式文件，这似乎得到了部分解决，但当内容拆分为 `en/shared.json` / `fr/shared.json` / `es/shared.json` 等命名空间时，静态渲染仍然会失效。
 
-**(Next I18next)** (`next-i18next@16.0.5`):
+**(Next I18next)** (`next-i18next@16.3.0`):
 
-`next-i18next` 可能最受欢迎，因为它是 JavaScript 应用中最早的 i18n 解决方案之一。它拥有许多社区插件。它与 `next-intl` 有着相同的重大缺点。包体积特别大（`I18nProvider` + `useTranslation` 约为 18kb，约为 `next-intlayer` 的 3 倍）。
+`next-i18next` 可能最受欢迎，因为它是 JavaScript 应用中最早的 i18n 解决方案之一。它拥有许多社区插件。它与 `next-intl` 有着相同的重大缺点。包体积特别大（`I18nProvider` + `useTranslation` 约为 19.7kb，约为 `next-intlayer` 的 3.5 倍）。
 
 消息格式也不同：`next-intl` 使用 ICU MessageFormat，而 `i18next` 使用自己的格式。
 
@@ -224,17 +229,17 @@ GitHub 星数是项目受欢迎程度、社区信任和长期相关性的有力
 
 `next-international` 也解决了上述问题，但与 `next-intl` 或 `next-i18next` 差异不大。它包含了用于特定命名空间翻译的 `scopedT()`，但使用它对打包体积几乎没有影响。
 
-**(Lingui)** (`@lingui/core@5.3.0`):
+**(Lingui)** (`@lingui/core@6.6.0`):
 
 `Lingui` 常受赞誉。就个人而言，我觉得围绕 `lingui extract` / `lingui compile` 的工作流比其他方案更复杂，且没有明显的优势。我还注意到语法不统一，容易误导 AI（例如 `t()`、`t''`、`i18n.t()`、`<Trans>`）。
 
 ### 4 - 推荐方案
 
-**(Next Translate)** (`next-translate@3.1.2`):
+**(Next Translate)** (`next-translate@3.2.0`):
 
-如果你喜欢 `t()` 风格的 API，`next-translate` 是我的主要推荐方案。它通过 `next-translate-plugin` 优雅运作，利用 Webpack / Turbopack loader 通过 `getStaticProps` 加载命名空间。它也是这些方案中最轻量的（约 2.5kb）。对于命名空间拆分，在配置中为每个页面或路由定义命名空间的设计非常周到，比 **next-intl** 或 **next-i18next** 等主要替代方案更易于维护。在版本 `3.1.2` 中，我注意到静态渲染无法工作，Next.js 会回退到动态渲染。
+如果你喜欢 `t()` 风格的 API，`next-translate` 是我的主要推荐方案。它通过 `next-translate-plugin` 优雅运作，利用 Webpack / Turbopack loader 通过 `getStaticProps` 加载命名空间。它也是这些方案中最轻量的之一（约 3.5kb）。对于命名空间拆分，在配置中为每个页面或路由定义命名空间的设计非常周到，比 **next-intl** 或 **next-i18next** 等主要替代方案更易于维护。在版本 `3.1.2` 中，我注意到静态渲染无法工作，Next.js 会回退到动态渲染。
 
-**(Intlayer)** (`next-intlayer@8.7.12`):
+**(Intlayer)** (`next-intlayer@9.5.1`):
 
 出于客观性考量，我不会亲自评价 `next-intlayer`，因为这是我自己的解决方案。
 

package/docs/zh/benchmark/solid.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2026-04-20
-updatedAt: 2026-05-18
+updatedAt: 2026-09-11
 title: 2026 年 Solid 最佳 i18n 解决方案 - 基准报告
 description: 比较 Solid 国际化（i18n）库，如 solid-primitives、solid-i18next 和 Intlayer。关于Bundle 大小、泄漏和反应性的详细性能报告。
 keywords:
@@ -17,6 +17,9 @@ slugs:
 author: aymericzip
 applicationTemplate: https://github.com/intlayer-org/benchmark-i18n-solid-template
 history:
+  - version: 9.5.1
+    date: 2026-09-11
+    changes: "更新基准测试结果"
   - version: 8.9.8
     date: 2026-05-18
     changes: "添加 GitHub 明星对比"
@@ -61,9 +64,9 @@ history:
 
 ## TL;DR
 
-- **Intlayer**: 需要高级功能和优化的专业 Solid 应用的推荐选择（v8.7.12）。
+- **Intlayer**: 需要高级功能和优化的专业 Solid 应用的推荐选择（v9.5.0）。
 - **@solid-primitives/i18n**: 简单项目的绝佳轻量级替代方案，但缺乏延迟加载等高级功能。
-- **solid-i18next**: 标准但沉重的选项（约为 Intlayer 的 4.7 倍），具有与 React i18next 相同的缺点。
+- **solid-i18next**: 标准但沉重的选项（约为 Intlayer 的 3.5 倍），具有与 React i18next 相同的缺点。
 - **Paraglide**: 创新的方法，但在某些设置中 DX 复杂且存在 tree-shaking 问题。
 
 ## 测试您的应用
@@ -96,10 +99,10 @@ history:
 在此基准测试中，我们比较了以下库：
 
 - `Base App`（无 i18n 库）
-- `solid-intlayer` (v8.7.12)
+- `solid-intlayer` (v9.5.0)
 - `@solid-primitives/i18n` (v2.2.1)
-- `solid-i18next` (v17.0.2)
-- `@inlang/paraglide-js` (v2.17.0)
+- `i18next` (v26.0.8) + `@mbarzda/solid-i18next` (v1.4.1)
+- `@inlang/paraglide-js` (v2.25.1)
 
 框架是 `Solid`，应用包含 **10 个页面** 和 **10 种语言**。
 
@@ -153,11 +156,11 @@ GitHub 星数是项目受欢迎程度、社区信任和长期相关性的有力
 
 ### 2 - 可接受的解决方案
 
-**(solid-i18next)** (`solid-i18next@17.0.2`):
+**(solid-i18next)** (`i18next@26.0.8`):
 
 `solid-i18next` 可能是最受欢迎的选项，因为它是最早满足 JavaScript 应用 i18n 需求的解决方案之一。它还拥有一套广泛的社区插件来解决特定问题。
 
-该包很重（~14.6kb，约为 `solid-intlayer` 的 4.7 倍）。
+该包很重（~14.9kb，约为 `solid-intlayer` 的 3.5 倍）。
 
 尽管如此，它与基于 `t('a.b.c')` 构建的栈具有相同的主要缺点：优化是可能的，但非常耗时，且大型项目面临不良实践（命名空间 + 动态加载 + 类型）的风险。
 
@@ -166,7 +169,7 @@ GitHub 星数是项目受欢迎程度、社区信任和长期相关性的有力
 Solid primitive 非常轻量且高效，我推荐将其用于轻量级项目，但对于包含 cookie 管理、代理重定向、格式化器等在内的专业解决方案，它可能会迅速显现功能不足。
 它还缺乏延迟加载和分层命名空间以进行页面大小优化。
 
-**(Paraglide)** (`@inlang/paraglide-js@2.17.0`):
+**(Paraglide)** (`@inlang/paraglide-js@2.25.1`):
 
 `Paraglide` 提供了一种创新且深思熟虑的方法。尽管如此，在此基准测试中，他们宣传的 tree-shaking 在我的实现中没有按预期工作。工作流程和 DX 也比其他选项更复杂。
 我个人不喜欢在每次推送前重新生成 JS 文件，这会通过 PR 在开发者之间造成持续的合并冲突风险。
@@ -174,7 +177,7 @@ Solid primitive 非常轻量且高效，我推荐将其用于轻量级项目，
 
 ### 3 - 建议
 
-**(Intlayer)** (`solid-intlayer@8.7.12`):
+**(Intlayer)** (`solid-intlayer@9.5.0`):
 
 出于客观性考虑，我个人不会对 `solid-intlayer` 做出评价，因为它是我的个人解决方案。
 

package/docs/zh/benchmark/svelte.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2026-04-20
-updatedAt: 2026-05-18
+updatedAt: 2026-09-11
 title: 2026 年 Svelte 最佳 i18n 解决方案 - 基准报告
 description: 比较 Svelte 国际化（i18n）库，如 svelte-i18n、Paraglide 和 Intlayer。关于Bundle 大小、泄漏和反应性的详细性能报告。
 keywords:
@@ -17,6 +17,9 @@ slugs:
 author: aymericzip
 applicationTemplate: https://github.com/intlayer-org/benchmark-i18n-svelte-template
 history:
+  - version: 9.5.1
+    date: 2026-09-11
+    changes: "更新基准测试结果"
   - version: 8.9.8
     date: 2026-05-18
     changes: "添加 GitHub 明星对比"
@@ -62,9 +65,9 @@ history:
 
 ## TL;DR
 
-- **Intlayer**: 性能最高效的选择（v8.7.12），占用空间最小。
+- **Intlayer**: 性能最高效的选择（v9.5.0），占用空间最小。
 - **Paraglide**: tree-shaking 的有力竞争者，但开发者体验更复杂，且有反应性开销。
-- **svelte-i18n**: 功能完善且是 Svelte 的标准，但包重量大得多（约为 Intlayer 的 7 倍）。
+- **svelte-i18n**: 功能完善且是 Svelte 的标准，但包重量大得多（约为 Intlayer 的 4.5 倍）。
 
 ## 测试您的应用
 
@@ -96,9 +99,9 @@ history:
 在此基准测试中，我们比较了以下库：
 
 - `Base App`（无 i18n 库）
-- `svelte-intlayer` (v8.7.12)
+- `svelte-intlayer` (v9.5.0)
 - `svelte-i18n` (v4.0.1)
-- `@inlang/paraglide-js` (v2.17.0)
+- `@inlang/paraglide-js` (v2.25.1)
 
 框架是 `Svelte`，应用包含 **10 个页面** 和 **10 种语言**。
 
@@ -152,7 +155,7 @@ GitHub 星数是项目受欢迎程度、社区信任和长期相关性的有力
 
 ### 2 - 可接受的解决方案
 
-**(Paraglide)** (`@inlang/paraglide-js@2.17.0`):
+**(Paraglide)** (`@inlang/paraglide-js@2.25.1`):
 
 `Paraglide` 提供了一种创新且深思熟虑的方法。在 Vite + Svelte 应用中，他们宣传的 tree-shaking 按预期工作，这很棒。
 但在 React + TanStack Start 的情况下，tree-shaking 没有按预期工作，Next.js 也是如此。尽管如此，在 Svelte 和 TanStack Start 项目中使用 Paraglide 还是值得关注的。
@@ -162,13 +165,13 @@ GitHub 星数是项目受欢迎程度、社区信任和长期相关性的有力
 
 > 关于 paraglide 的说明：该解决方案在您的代码库中注入代码进行导入，因此基准报告中的“库大小”指标几乎为 0。代码生成是一件好事，因为使用的函数将仅包含必要的逻辑（全局前缀 vs 无前缀、cookie vs 存储等）。相比之下，Intlayer 在构建期间通过注入环境变量来进行过滤，以迫使打包器根据逻辑对内容进行 tree-shake。得益于此，paraglide 和 intlayer 最终比 i18next 或 next-intl 轻 6 到 10 倍。
 
-**(svelte-i18n)** (`svelte-i18n@3.4.0`):
+**(svelte-i18n)** (`svelte-i18n@4.0.1`):
 
-此解决方案满足 Svelte 项目中 i18n 的所有需求。但正如 i18next 或其他主流 i18n 解决方案的情况一样，它有点重（~15.9kb，约为 `svelte-intlayer` 的 7 倍）。
+此解决方案满足 Svelte 项目中 i18n 的所有需求。但正如 i18next 或其他主流 i18n 解决方案的情况一样，它有点重（~16.6kb，约为 `svelte-intlayer` 的 4.5 倍）。
 
 ### 3 - 建议
 
-**(Intlayer)** (`svelte-intlayer@8.7.12`):
+**(Intlayer)** (`svelte-intlayer@9.5.0`):
 
 出于客观性考虑，我个人不会对 `svelte-intlayer` 做出评价，因为它是我的个人解决方案。
 

package/docs/zh/benchmark/tanstack.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2026-04-20
-updatedAt: 2026-05-18
+updatedAt: 2026-09-11
 title: 2026 年 TanStack Start 最佳 i18n 解决方案 - 基准测试报告
 description: 对比 react-i18next、use-intl 和 Intlayer 等 TanStack Start 国际化库。关于打包体积、泄漏和响应性的详细性能报告。
 keywords:
@@ -17,6 +17,9 @@ slugs:
 author: aymericzip
 applicationTemplate: https://github.com/intlayer-org/benchmark-i18n-tanstack-start-template
 history:
+  - version: 9.5.1
+    date: 2026-09-11
+    changes: "更新基准测试结果"
   - version: 8.9.8
     date: 2026-05-18
     changes: "添加 GitHub 明星对比"
@@ -62,7 +65,7 @@ history:
 
 ## TL;DR
 
-- **Intlayer**: 为 TanStack Start 提供最佳性能和最小的打包体积 (v8.7.12)。
+- **Intlayer**: 为 TanStack Start 提供最佳性能和最小的打包体积 (v9.5.1)。
 - **react-i18next** & **use-intl**: 拥有庞大生态系统的成熟替代方案，但体积显著更大且优化更为复杂。
 - **Paraglide**: 创新的 Tree-shaking 理念，但在实际应用中并未生效。在 TanStack Start 中 DX 复杂且存在响应性开销。
 - **应当避免**: **General Translation (GT)** 和 **Lingo.dev**。由于严重的性能问题、AI 配额限制以及供应商锁定 (vendor lock-in)。
@@ -97,16 +100,18 @@ history:
 在此基准测试中，我们对比了以下库：
 
 - `Base App`（无 i18n 库）
-- `react-intlayer` (v8.7.12)
-- `react-i18next` (v17.0.2)
-- `use-intl` (v4.9.1)
-- `@lingui/core` (v5.3.0)
+- `react-intlayer` (v9.5.1)
+- `@intlayer/use-intl` (v9.5.1)
+- [`@intlayer/lingui`](https://github.com/aymericzip/intlayer/blob/main/docs/docs/zh/compat/lingui.md) (v9.5.1)
+- `react-i18next` (v17.0.13)
+- `use-intl` (v4.14.2)
+- `@lingui/core` (v6.6.0)
 - `@inlang/paraglide-js` (v2.15.1)
-- `@tolgee/react` (v7.0.0)
-- `react-intl` (v10.1.1)
-- `wuchale` (v0.22.11)
-- `gt-react` (vlatest)
-- `lingo.dev` (v0.133.9)
+- `@tolgee/react` (v7.2.0)
+- `react-intl` (v10.1.26)
+- `wuchale` (v0.26.6)
+- `gt-react` (v10.18.3)
+- `lingo.dev` (v0.138.7)
 
 框架使用 `TanStack Start`，构建了一个拥有 **10 个页面**和 **10 种语言**的多语言应用。
 
@@ -160,15 +165,15 @@ GitHub 星数是项目受欢迎程度、社区信任和长期相关性的有力
 
 遇到的问题：
 
-**(General Translation)** (`gt-react@latest`):
+**(General Translation)** (`gt-react@10.18.3`):
 
-- 对于一个约 110kb 的应用，`gt-react` 额外增加了超过 440kb（参考同个基准测试中 Next.js 实现的量级）。
+- 对于一个约 111kb 的应用，`gt-react` 额外增加了超过 170kb（参考同个基准测试中 Next.js 实现的量级）。
 - 第一次使用 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 小时内修复了它。
 - 这些库通过 `initializeGT()` 函数使用了一种反模式，阻碍了打包包进行干净的 Tree-shaking。
 
-**(Lingo.dev)** (`lingo.dev@0.133.9`):
+**(Lingo.dev)** (`lingo.dev@0.138.7`):
 
 - AI 配额超出（或服务端依赖受阻），使得不付钱的情况下构建或部署极具风险。
 - 编译器丢失了近 40% 的翻译内容。我不得不将所有的 `.map` 重写为扁平的组件块才使其工作。
@@ -178,7 +183,7 @@ GitHub 星数是项目受欢迎程度、社区信任和长期相关性的有力
 
 ### 2 - 实验性解决方案
 
-**(Wuchale)** (`wuchale@0.22.11`):
+**(Wuchale)** (`wuchale@0.26.6`):
 
 `Wuchale` 背后的想法很有趣，但尚非可行方案。我遇到了该库的响应性问题，不得不强制重新渲染 Provider 才能让应用在 TanStack Start 上运行。文档也相当模糊，增加了上手难度。
 
@@ -188,9 +193,9 @@ GitHub 星数是项目受欢迎程度、社区信任和长期相关性的有力
 
 `Paraglide` 提供了一种创新且经过深思熟虑的方法。即便如此，在此基准测试中，其公司宣称的 Tree-shaking 在我的 Next.js 实现或 TanStack Start 中并未生效。工作流和 DX 也比其他选项更复杂。就个人而言，我不喜欢每次推送到代码库前都要重新生成 JS 文件，这通过 PR 产生了持续的合并冲突风险。
 
-> 关于 paraglide 的说明：该解决方案通过将代码注入到您的代码库中进行导入，因此基准测试报告中的“库体积”指标几乎为 0。代码生成是一件好事，因为所使用的函数将仅包含必要的逻辑（全部前缀 vs 无前缀、cookie vs 存储等）。相比之下，Intlayer 通过在构建中注入环境变量来进行过滤，以强制打包工具根据逻辑对内容进行 Tree-shake。得益于此，paraglide 和 intlayer 最终成为比 i18next 或 next-intl 轻 6-10 倍的解决方案。
+> 关于 paraglide 的说明：该解决方案通过将代码注入到您的代码库中进行导入，因此基准测试报告中的“库体积”指标几乎为 0。代码生成是一件好事，因为所使用的函数将仅包含必要的逻辑（全部前缀 vs 无前缀、cookie vs 存储等）。相比之下，Intlayer 通过在构建中注入环境变量来进行过滤，以强制打包工具根据逻辑对内容进行 Tree-shake。得益于此，paraglide 和 intlayer 最终成为比 i18next 或 next-intl 轻 3-10 倍的解决方案。
 
-**(Tolgee)** (`@tolgee/react@7.0.0`):
+**(Tolgee)** (`@tolgee/react@7.2.0`):
 
 `Tolgee` 解决了前面提到的许多问题。我发现它比其他采用类似方法的工具更难上手。它不提供类型安全，这极大增加了在编译时捕捉缺失键的难度。我不得不使用自己的 API 封装 Tolgee 的 API 以添加缺失键检测。
 
@@ -198,37 +203,37 @@ GitHub 星数是项目受欢迎程度、社区信任和长期相关性的有力
 
 在 TanStack Start 上，我也遇到了响应性问题：当locale改变时，我必须强制提供者重新渲染并订阅locale-change事件，以便在另一种语言中加载时行为正确。
 
-**(use-intl)** (`use-intl@4.9.1`):
+**(use-intl)** (`use-intl@4.14.2`):
 
 `use-intl` 是 React 生态中最时髦的“intl”成员（与 `next-intl` 同系），常被 AI Agent 推荐，但在我看来，在性能优先的环境下这是错误的。入门相对简单，但在实践中，优化和限制泄漏的过程相当复杂。同样，结合动态加载 + 命名空间 + TypeScript 类型会极大降低开发速度。
 
 在 TanStack Start 上你可以避开 Next.js 特有的陷阱（`setRequestLocale`、静态渲染），但核心问题是一样的：如果没有严格的规范，打包包很快会承载过多消息，而且维护每条路由的命名空间会变得非常痛苦。
 
-**(react-i18next)** (`react-i18next@17.0.2`):
+**(react-i18next)** (`react-i18next@17.0.13`):
 
 `react-i18next` 可能最受欢迎，因为它是最早满足 JavaScript 应用 i18n 需求的方案之一。它还针对特定问题拥有广泛的社区插件。
 
 尽管如此，它与基于 `t('a.b.c')` 的技术栈有着相同的重大缺点：优化是可能的，但非常耗时，且大型项目容易陷入不良实践（命名空间 + 动态加载 + 类型）。
 
-该 package 特别重（~17.3kb，约为 `react-intlayer` 的 3.5 倍）。
+该 package 特别重（~18.4kb，约为 `react-intlayer` 的 3.5 倍）。
 
 消息格式也不同：`use-intl` 使用 ICU MessageFormat，而 `i18next` 使用自己的格式--如果混合使用它们，会增加工具链或迁移的复杂度。
 
-**(Lingui)** (`@lingui/core@5.3.0`):
+**(Lingui)** (`@lingui/core@6.6.0`):
 
 `Lingui` 常受赞誉。就个人而言，我觉得围绕 `lingui extract` / `lingui compile` 的工作流比其他方案更复杂，且在此 TanStack Start 基准测试中没有明显的优势。我还注意到语法不统一，容易误导 AI（例如 `t()`、`t''`、`i18n.t()`、`<Trans>`）。
 
-**(react-intl)** (`react-intl@10.1.1`):
+**(react-intl)** (`react-intl@10.1.26`):
 
 `react-intl` 是来自 Format.js 团队的高性能实现。但 DX 依然繁琐：`const intl = useIntl()` + `intl.formatMessage({ id: "xx.xx" })` 增加了复杂度和额外的 JavaScript 开销，并将全局 i18n 实例绑定到了 React 树中的许多节点。
 
-该 package 也很重（~14.4kb，大约是 `react-intlayer` 的 3 倍）。
+该 package 也很重（~15.3kb，大约是 `react-intlayer` 的 3 倍）。
 
 ### 4 - 推荐方案
 
 在本次 TanStack Start 基准测试中，没有与 `next-translate`（Next.js 插件 + `getStaticProps`）直接对应的方案。对于那些确实想要 `t()` API 且拥有成熟生态的团队，`react-i18next` 和 `use-intl` 仍是“合理”的选择，但要做好投入大量时间进行优化以避免泄漏的准备。
 
-**(Intlayer)** (`react-intlayer@8.7.12`):
+**(Intlayer)** (`react-intlayer@9.5.1`):
 
 出于客观性考量，我不会亲自评价 `react-intlayer`，因为这是我自己的解决方案。
 

package/docs/zh/benchmark/vue.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2026-04-20
-updatedAt: 2026-05-18
+updatedAt: 2026-09-11
 title: 2026 年 Vue 最佳 i18n 解决方案 - 基准报告
 description: 比较 Vue 国际化（i18n）库，如 vue-i18n、fluent-vue 和 Intlayer。关于Bundle 大小、泄漏和反应性的详细性能报告。
 keywords:
@@ -17,6 +17,9 @@ slugs:
 author: aymericzip
 applicationTemplate: https://github.com/intlayer-org/benchmark-i18n-vue-template
 history:
+  - version: 9.5.1
+    date: 2026-09-11
+    changes: "更新基准测试结果"
   - version: 8.9.8
     date: 2026-05-18
     changes: "添加 GitHub 明星对比"
@@ -62,7 +65,7 @@ style="border:none;"
 
 ## TL;DR
 
-- **Intlayer**: 最轻量级的解决方案（v8.7.12），内置分层（scoping）和动态加载。
+- **Intlayer**: 最轻量级的解决方案（v9.5.0），内置分层（scoping）和动态加载。
 - **vue-i18n**: 具有丰富生态系统的行业标准，但在大型应用中可能会显著变重且难以进行代码拆分优化。
 - **fluent-vue**: 创新的消息组织方式，但缺乏类型安全且极其沉重。
 
@@ -96,7 +99,8 @@ style="border:none;"
 在此基准测试中，我们比较了以下库：
 
 - `Base App`（无 i18n 库）
-- `vue-intlayer` (v8.7.12)
+- `vue-intlayer` (v9.5.0)
+- [`@intlayer/vue-i18n`](https://github.com/aymericzip/intlayer/blob/main/docs/docs/zh/compat/vue-i18n.md) (v9.5.1)
 - `vue-i18n` (v11.4.0)
 - `fluent-vue` (v3.8.2)
 
@@ -156,14 +160,14 @@ GitHub 星数是项目受欢迎程度、社区信任和长期相关性的有力
 
 - **vue-i18n** 毫无疑问是 Vue 中最常用的 i18n 库，它具有大量功能和庞大的生态系统。但在底层，该解决方案相当沉重。即使 vue-i18n 集成了消息的懒加载，它也缺乏分层（scoping）功能。在经典的 Vue SPA 应用中没有问题，但对于使用 @nuxt/i18n 的 Nuxt 应用，它会导致所有页面的消息都包含在单个页面中。对于包含 10 个以上页面的大型 Nuxt 应用，这可能会变得非常成问题。
 
-该包非常重（~24.3kb，约为 `vue-intlayer` 的 9 倍）。
+该包非常重（~24.3kb，约为 `vue-intlayer` 的 6 倍）。
 
-**(fluent-vue)** (`fluent-vue@0.5.0`):
+**(fluent-vue)** (`fluent-vue@3.8.2`):
 
-- **fluent-vue** 通过 .ftl 格式提供了一种创新尝试。消息组织很棒，更容易上手。但在实践中，缺乏类型安全增加了错误风险，并且调试起来可能很快就会变得耗时。此外，该解决方案使用 vite 插件加载消息，强制将所有语言的所有内容加载到每个页面中。此外，这是一个极其沉重的解决方案（~92.7kb，约为 `vue-intlayer` 的 34 倍）。
+- **fluent-vue** 通过 .ftl 格式提供了一种创新尝试。消息组织很棒，更容易上手。但在实践中，缺乏类型安全增加了错误风险，并且调试起来可能很快就会变得耗时。此外，该解决方案使用 vite 插件加载消息，强制将所有语言的所有内容加载到每个页面中。此外，这是一个极其沉重的解决方案（~29.7kb，约为 `vue-intlayer` 的 7.5 倍）。
 
 ### 3 - 建议
 
-**(Intlayer)** (`vue-intlayer@8.7.12`):
+**(Intlayer)** (`vue-intlayer@9.5.0`):
 
 出于客观性考虑，我个人不会对 `vue-intlayer` 做出评价，因为它是我的个人解决方案。

package/docs/zh/cli/build.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2024-08-11
-updatedAt: 2025-11-22
+updatedAt: 2026-09-12
 title: 构建字典
 description: 了解如何从内容声明文件构建您的 Intlayer 字典。
 keywords:
@@ -14,6 +14,9 @@ slugs:
   - cli
   - build
 history:
+  - version: 9.5.2
+    date: 2026-09-12
+    changes: "添加 `--ci` 标志"
   - version: 8.1.5
     date: 2026-02-23
     changes: "添加 checkTypes 选项"
@@ -92,6 +95,10 @@ bun x intlayer build --watch
 
   > 示例：`npx intlayer build --no-cache`
 
+- **`--ci`**：在 monorepo 的每个 Intlayer 项目中执行该命令（在项目目录内运行时仅处理当前项目）。可通过 `INTLAYER_PROJECT_CREDENTIALS`（将项目路径映射到 `{ "clientId", "clientSecret" }` 的 JSON 对象）为每个项目注入凭据。
+
+  > 示例：`npx intlayer build --ci`
+
 - **`--check-types`**: 检查内容声明文件的类型。
 
   > 示例： `npx intlayer build --check-types`

package/docs/zh/cli/configuration.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2024-08-11
-updatedAt: 2025-11-22
+updatedAt: 2026-09-12
 title: 管理配置
 description: 了解如何获取并推送您的 Intlayer 配置到 CMS。
 keywords:
@@ -51,6 +51,7 @@ bun x intlayer configuration get
 - **`--base-dir`**：指定项目的基础目录。
 - **`--verbose`**：启用详细日志以进行调试。（默认通过 CLI 设置为 true）
 - **`--no-cache`**：禁用缓存。
+- **`--ci`**：在 monorepo 的每个 Intlayer 项目中执行该命令（在项目目录内运行时仅处理当前项目）。可通过 `INTLAYER_PROJECT_CREDENTIALS`（将项目路径映射到 `{ "clientId", "clientSecret" }` 的 JSON 对象）为每个项目注入凭据。
 
 ## 推送配置
 
@@ -84,5 +85,6 @@ bun x intlayer configuration push
 - **`--base-dir`**：指定项目的基础目录。
 - **`--verbose`**：启用详细日志以便调试。（CLI 默认启用）
 - **`--no-cache`**：禁用缓存。
+- **`--ci`**：在 monorepo 的每个 Intlayer 项目中执行该命令（在项目目录内运行时仅处理当前项目）。可通过 `INTLAYER_PROJECT_CREDENTIALS`（将项目路径映射到 `{ "clientId", "clientSecret" }` 的 JSON 对象）为每个项目注入凭据。
 
 通过推送配置，您的项目将完全集成到 Intlayer CMS 中，实现团队间无缝的词典管理。

package/docs/zh/cli/doc-review.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2024-08-11
-updatedAt: 2026-06-17
+updatedAt: 2026-09-12
 title: 审核文档
 description: 学习如何审核不同语言版本的文档文件，以确保质量、一致性和完整性。
 keywords:
@@ -16,6 +16,9 @@ slugs:
   - cli
   - doc-review
 history:
+  - version: 9.5.2
+    date: 2026-09-12
+    changes: "添加 `--ci` 标志"
   - version: 9.0.0
     date: 2026-06-17
     changes: "添加 --log 选项"
@@ -136,6 +139,10 @@ bun x intlayer doc review
 
   > 示例: `npx intlayer doc review --base-dir ./docs --env-file .env.production.local`
 
+- **`--ci`**：在 monorepo 的每个 Intlayer 项目中执行该命令（在项目目录内运行时仅处理当前项目）。可通过 `INTLAYER_PROJECT_CREDENTIALS`（将项目路径映射到 `{ "clientId", "clientSecret" }` 的 JSON 对象）为每个项目注入凭据。
+
+  > 示例: `npx intlayer doc review --ci`
+
 **日志选项:**
 
 - **`--verbose`**: 启用详细日志以便调试。（CLI 默认启用）

package/docs/zh/cli/doc-translate.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2024-08-11
-updatedAt: 2025-11-22
+updatedAt: 2026-09-12
 title: 翻译文档
 description: 学习如何使用 AI 翻译服务自动翻译文档文件。
 keywords:
@@ -112,6 +112,10 @@ bun x intlayer doc translate
 
   > 示例: `npx intlayer doc translate --base-dir ./docs --env-file .env.production.local`
 
+- **`--ci`**：在 monorepo 的每个 Intlayer 项目中执行该命令（在项目目录内运行时仅处理当前项目）。可通过 `INTLAYER_PROJECT_CREDENTIALS`（将项目路径映射到 `{ "clientId", "clientSecret" }` 的 JSON 对象）为每个项目注入凭据。
+
+  > 示例: `npx intlayer doc translate --ci`
+
 **日志选项:**
 
 - **`--verbose`**: 启用详细日志以便调试。（CLI 默认启用）

package/docs/zh/cli/extract.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2024-08-11
-updatedAt: 2025-11-22
+updatedAt: 2026-09-12
 title: 提取字符串
 description: 了解如何将组件中的字符串提取到靠近组件的 .content 文件中。
 keywords:
@@ -69,6 +69,7 @@ bun x intlayer extract
 - **`--env`**：指定环境。
 - **`--env-file`**：提供自定义的环境文件。
 - **`--verbose`**：启用详细日志。
+- **`--ci`**：在 monorepo 的每个 Intlayer 项目中执行该命令（在项目目录内运行时仅处理当前项目）。可通过 `INTLAYER_PROJECT_CREDENTIALS`（将项目路径映射到 `{ "clientId", "clientSecret" }` 的 JSON 对象）为每个项目注入凭据。
 
 **必需的插件：**
 

package/docs/zh/cli/fill.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2024-08-11
-updatedAt: 2025-11-22
+updatedAt: 2026-09-12
 title: 填充字典
 description: 学习如何使用 AI 填充、审核和翻译您的字典。
 keywords:
@@ -161,6 +161,10 @@ Affected dictionary keys for processing: app, comp-test, hello-world, lang-switc
 
   > 示例：`npx intlayer build --no-cache`
 
+- **`--ci`**：在 monorepo 的每个 Intlayer 项目中执行该命令（在项目目录内运行时仅处理当前项目）。可通过 `INTLAYER_PROJECT_CREDENTIALS`（将项目路径映射到 `{ "clientId", "clientSecret" }` 的 JSON 对象）为每个项目注入凭据。
+
+  > 示例：`npx intlayer fill --ci`
+
 **准备选项：**
 
 - **`--build`**：在推送之前构建字典以确保内容是最新的。设置为 true 将强制构建，false 将跳过构建，undefined 将允许使用构建缓存。