@intlayer/docs 8.9.4 → 8.9.6-canary.0

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 执行开销（即使几乎察觉不到）。

package/docs/zh/benchmark/svelte.md

@@ -0,0 +1,148 @@
+---
+createdAt: 2026-04-20
+updatedAt: 2026-04-21
+title: 2026 年 Svelte 最佳 i18n 解决方案 - 基准报告
+description: 比较 Svelte 国际化（i18n）库，如 svelte-i18n、Paraglide 和 Intlayer。关于包大小、泄漏和反应性的详细性能报告。
+keywords:
+  - benchmark
+  - i18n
+  - intl
+  - svelte
+  - performance
+  - intlayer
+slugs:
+  - doc
+  - benchmark
+  - svelte
+author: Aymeric PINEAU
+applicationTemplate: https://github.com/intlayer-org/benchmark-i18n-svelte-template
+history:
+  - version: 8.7.12
+    date: 2026-01-06
+    changes: "初始化基准"
+---
+
+# Svelte i18n 库 - 2026 基准报告
+
+此页面是 Svelte 上 i18n 解决方案的基准报告。
+
+## 目录
+
+<Toc/>
+
+## 交互式基准
+
+<I18nBenchmark framework="vite-svelte" vertical/>
+
+## 结果参考：
+
+<iframe 
+  src="https://intlayer.org/markdown?url=https%3A%2F%2Fraw.githubusercontent.com%2Fintlayer-org%2Fbenchmark-i18n%2Fmain%2Freport%2Fscripts%2Fsummarize-vite_svelte.md" 
+  width="100%" 
+  height="600px"
+  style="border:none;">
+</iframe>
+
+> https://intlayer.org/markdown?url=https%3A%2F%2Fraw.githubusercontent.com%2Fintlayer-org%2Fbenchmark-i18n%2Fmain%2Freport%2Fscripts%2Fsummarize-vite_svelte.md
+
+查看完整的基准仓库 [此处](https://github.com/intlayer-org/benchmark-i18n/tree/main)。
+
+## 简介
+
+国际化解决方案是 Svelte 应用中最重的依赖项之一。主要风险是发送不必要的内容：单个路由包中包含其他页面和其他语言的翻译。
+
+随着应用增长，这个问题会迅速增加发送到客户端的 JavaScript，并减慢导航速度。
+
+实际上，对于优化最差的实现，国际化页面的重量可能是非 i18n 版本的几倍。
+
+另一个影响是开发者体验（DX）：如何声明内容、类型、命名空间组织、动态加载以及语言更改时的反应性。
+
+## TL;DR
+
+- **Intlayer**: 性能最高效的选择（v8.7.12），占用空间最小。
+- **Paraglide**: tree-shaking 的有力竞争者，但开发者体验更复杂，且有反应性开销。
+- **svelte-i18n**: 功能完善且是 Svelte 的标准，但包重量大得多（约为 Intlayer 的 7 倍）。
+
+## 测试您的应用
+
+为了快速发现 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 库）
+- `svelte-intlayer` (v8.7.12)
+- `svelte-i18n` (v4.0.1)
+- `@inlang/paraglide-js` (v2.17.0)
+
+框架是 `Svelte`，应用包含 **10 个页面** 和 **10 种语言**。
+
+我们比较了 **四种加载策略**：
+
+| 策略         | 无命名空间（全局）                     | 具有命名空间（分层/scoped）                             |
+| :----------- | :------------------------------------- | :------------------------------------------------------ |
+| **静态加载** | **Static**: 启动时所有内容都在内存中。 | **Scoped static**: 按命名空间拆分；启动时加载所有内容。 |
+| **动态加载** | **Dynamic**: 按需按语言加载。          | **Scoped dynamic**: 按命名空间和语言进行细粒度加载。    |
+
+## 策略摘要
+
+- **静态 (Static)**: 简单；初始加载后无网络延迟。缺点：包体积大。
+- **动态 (Dynamic)**: 减轻初始重量（懒加载）。当您有多种语言时非常理想。
+- **分层静态 (Scoped static)**: 保持代码有序（逻辑分离），无需复杂的额外网络请求。
+- **分层动态 (Scoped dynamic)**: _代码拆分_ 和性能的最佳方法。通过仅加载当前视图和活动语言所需的内容来最小化内存使用。
+
+## 结果详情
+
+### 1 - 应当避免的解决方案
+
+> Svelte 生态系统中没有明确应当避免的解决方案。
+
+### 2 - 可接受的解决方案
+
+**(Paraglide)** (`@inlang/paraglide-js@2.17.0`):
+
+`Paraglide` 提供了一种创新且深思熟虑的方法。在 Vite + Svelte 应用中，他们宣传的 tree-shaking 按预期工作，这很棒。
+但在 React + TanStack Start 的情况下，tree-shaking 没有按预期工作，Next.js 也是如此。尽管如此，在 Svelte 和 TanStack Start 项目中使用 Paraglide 还是值得关注的。
+工作流程和 DX 也比其他选项更复杂。
+我个人不喜欢在每次推送前重新生成 JS 文件，这会通过 PR 在开发者之间造成持续的合并冲突风险。该工具似乎也比 Next.js 更专注于 Vite。
+最后，与其他解决方案相比，Paraglide 不使用 store（例如 Svelte store）来检索当前语言以渲染内容。对于解析的每个节点，它都会从 localStorage / cookie 等请求语言。这导致执行不必要的逻辑，从而影响组件的反应性。
+
+> 关于 paraglide 的说明：该解决方案在您的代码库中注入代码进行导入，因此基准报告中的“库大小”指标几乎为 0。代码生成是一件好事，因为使用的函数将仅包含必要的逻辑（全局前缀 vs 无前缀、cookie vs 存储等）。相比之下，Intlayer 在构建期间通过注入环境变量来进行过滤，以迫使打包器根据逻辑对内容进行 tree-shake。得益于此，paraglide 和 intlayer 最终比 i18next 或 next-intl 轻 6 到 10 倍。
+
+**(svelte-i18n)** (`svelte-i18n@3.4.0`):
+
+此解决方案满足 Svelte 项目中 i18n 的所有需求。但正如 i18next 或其他主流 i18n 解决方案的情况一样，它有点重（~15.9kb，约为 `svelte-intlayer` 的 7 倍）。
+
+### 3 - 建议
+
+**(Intlayer)** (`svelte-intlayer@8.7.12`):
+
+出于客观性考虑，我个人不会对 `svelte-intlayer` 做出评价，因为它是我的个人解决方案。
+
+### 个人笔记
+
+此笔记仅代表个人观点，不影响基准测试结果。尽管如此，在 i18n 领域，您经常会看到围绕 `const t = useTranslation('xx')` + `<>{t('xx.xx')}</>` 模式的翻译内容共识。
+
+在 Svelte 应用中，将函数作为 `Slot` 注入在我的观点中是一种反模式。它还增加了可避免的复杂性和 JavaScript 执行开销（即使几乎察觉不到）。

package/docs/zh/benchmark/tanstack.md

@@ -57,6 +57,13 @@ history:
 
 另一个影响是开发体验（DX）：内容声明方式、类型、命名空间组织、动态加载以及语言环境更改时的响应性。
 
+## TL;DR
+
+- **Intlayer**: 为 TanStack Start 提供最佳性能和最小的打包体积 (v8.7.12)。
+- **react-i18next** & **use-intl**: 拥有庞大生态系统的成熟替代方案，但体积显著更大且优化更为复杂。
+- **Paraglide**: 创新的 Tree-shaking 理念，但在实际应用中并未生效。在 TanStack Start 中 DX 复杂且存在响应性开销。
+- **应当避免**: **General Translation (GT)** 和 **Lingo.dev**。由于严重的性能问题、AI 配额限制以及供应商锁定 (vendor lock-in)。
+
 ## 测试你的应用
 
 为了快速发现 i18n 泄漏问题，我建立了一个免费扫描器，你可以在[这里](https://intlayer.org/i18n-seo-scanner)试用。
@@ -87,12 +94,12 @@ history:
 在此基准测试中，我们对比了以下库：
 
 - `Base App`（无 i18n 库）
-- `react-intlayer` (v8.7.5-canary.0)
+- `react-intlayer` (v8.7.12)
 - `react-i18next` (v17.0.2)
 - `use-intl` (v4.9.1)
 - `@lingui/core` (v5.3.0)
 - `@inlang/paraglide-js` (v2.15.1)
-- `tolgee` (v7.0.0)
+- `@tolgee/react` (v7.0.0)
 - `react-intl` (v10.1.1)
 - `wuchale` (v0.22.11)
 - `gt-react` (vlatest)
@@ -150,7 +157,9 @@ history:
 
 `Paraglide` 提供了一种创新且经过深思熟虑的方法。即便如此，在此基准测试中，其公司宣称的 Tree-shaking 在我的 Next.js 实现或 TanStack Start 中并未生效。工作流和 DX 也比其他选项更复杂。就个人而言，我不喜欢每次推送到代码库前都要重新生成 JS 文件，这通过 PR 产生了持续的合并冲突风险。
 
-**(Tolgee)** (`tolgee@7.0.0`):
+> 关于 paraglide 的说明：该解决方案通过将代码注入到您的代码库中进行导入，因此基准测试报告中的“库体积”指标几乎为 0。代码生成是一件好事，因为所使用的函数将仅包含必要的逻辑（全部前缀 vs 无前缀、cookie vs 存储等）。相比之下，Intlayer 通过在构建中注入环境变量来进行过滤，以强制打包工具根据逻辑对内容进行 Tree-shake。得益于此，paraglide 和 intlayer 最终成为比 i18next 或 next-intl 轻 6-10 倍的解决方案。
+
+**(Tolgee)** (`@tolgee/react@7.0.0`):
 
 `Tolgee` 解决了前面提到的许多问题。我发现它比其他采用类似方法的工具更难上手。它不提供类型安全，这极大增加了在编译时捕捉缺失键的难度。我不得不使用自己的 API 封装 Tolgee 的 API 以添加缺失键检测。
 

package/docs/zh/benchmark/vue.md

@@ -0,0 +1,160 @@
+---
+createdAt: 2026-04-20
+updatedAt: 2026-04-21
+title: 2026 年 Vue 最佳 i18n 解决方案 - 基准报告
+description: 比较 Vue 国际化（i18n）库，如 vue-i18n、fluent-vue 和 Intlayer。关于包大小、泄漏和反应性的详细性能报告。
+keywords:
+  - benchmark
+  - i18n
+  - intl
+  - vue
+  - performance
+  - intlayer
+slugs:
+  - doc
+  - benchmark
+  - vue
+author: Aymeric PINEAU
+applicationTemplate: https://github.com/intlayer-org/benchmark-i18n-vue-template
+history:
+  - version: 8.7.12
+    date: 2026-01-06
+    changes: "初始化基准"
+---
+
+# Vue i18n 库 - 2026 基准报告
+
+此页面是 Vue 上 i18n 解决方案的基准报告。
+
+## 目录
+
+<Toc/>
+
+## 交互式基准
+
+<I18nBenchmark framework="vite-vue" vertical/>
+
+## 结果参考：
+
+<iframe 
+  src="https://intlayer.org/markdown?url=https%3A%2F%2Fraw.githubusercontent.com%2Fintlayer-org%2Fbenchmark-i18n%2Fmain%2Freport%2Fscripts%2Fsummarize-vite_vue.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_vue.md
+
+查看完整的基准仓库 [此处](https://github.com/intlayer-org/benchmark-i18n/tree/main)。
+
+## 简介
+
+国际化解决方案是 Vue 应用中最重的依赖项之一。主要风险是发送不必要的内容：单个路由包中包含其他页面和其他语言的翻译。
+
+随着应用增长，这个问题会迅速增加发送到客户端的 JavaScript，并减慢导航速度。
+
+实际上，对于优化最差的实现，国际化页面的重量可能是非 i18n 版本的几倍。
+
+另一个影响是开发者体验（DX）：如何声明内容、类型、命名空间组织、动态加载以及语言更改时的反应性。
+
+## TL;DR
+
+- **Intlayer**: 最轻量级的解决方案（v8.7.12），内置分层（scoping）和动态加载。
+- **vue-i18n**: 具有丰富生态系统的行业标准，但在大型应用中可能会显著变重且难以进行代码拆分优化。
+- **fluent-vue**: 创新的消息组织方式，但缺乏类型安全且极其沉重。
+
+## 测试您的应用
+
+为了快速发现 i18n 泄漏问题，我建立了一个免费扫描仪，可在 [此处](https://intlayer.org/i18n-seo-scanner) 试用。
+
+<iframe src="https://intlayer.org/i18n-seo-scanner" width="100%" height="600px" style="border:none;"/>
+
+## 问题所在
+
+限制多语言应用成本有两个关键杠杆：
+
+- 按页面 / 命名空间拆分内容，这样在不需要时就不会加载整个字典
+- 仅在需要时动态加载正确的语言
+
+了解这些方案的技术限制：
+
+**动态加载**
+
+如果没有动态加载，大多数解决方案会从首次渲染开始将消息保留在内存中，这对于具有许多路由和语言的应用会产生显著开销。
+
+使用动态加载，您接受一个权衡：减少初始 JS，但有时在切换语言时会有额外的请求。
+
+**内容拆分**
+
+围绕 `const { t } = useI18n()` + `t('a.b.c')` 构建的语法非常方便，但往往鼓励在运行时保留大型 JSON 对象。除非库提供真正的按页面拆分策略，否则这种模式使 tree-shaking 变得困难。
+
+## 研究方法
+
+在此基准测试中，我们比较了以下库：
+
+- `Base App`（无 i18n 库）
+- `vue-intlayer` (v8.7.12)
+- `vue-i18n` (v11.4.0)
+- `fluent-vue` (v3.8.2)
+
+框架是 `Vue`，应用包含 **10 个页面** 和 **10 种语言**。
+
+我们比较了 **四种加载策略**：
+
+| 策略         | 无命名空间（全局）                     | 具有命名空间（分层/scoped）                             |
+| :----------- | :------------------------------------- | :------------------------------------------------------ |
+| **静态加载** | **Static**: 启动时所有内容都在内存中。 | **Scoped static**: 按命名空间拆分；启动时加载所有内容。 |
+| **动态加载** | **Dynamic**: 按需按语言加载。          | **Scoped dynamic**: 按命名空间和语言进行细粒度加载。    |
+
+## 策略摘要
+
+- **静态 (Static)**: 简单；初始加载后无网络延迟。缺点：包体积大。
+- **动态 (Dynamic)**: 减轻初始重量（懒加载）。当您有多种语言时非常理想。
+- **分层静态 (Scoped static)**: 保持代码有序（逻辑分离），无需复杂的额外网络请求。
+- **分层动态 (Scoped dynamic)**: _代码拆分_ 和性能的最佳方法。通过仅加载当前视图和活动语言所需的内容来最小化内存使用。
+
+### 我测量了什么：
+
+我为每个栈在真实浏览器中运行了相同的多语言应用，然后记录了线路上实际显示的内容以及耗时。尺寸报告为**普通网络压缩后**的尺寸，因为这比原始源代码计数更接近人们实际下载的内容。
+
+- **国际化库大小**: 打包、tree-shaking 和压缩后，i18n 库的大小是空组件中 providers + composables 代码的大小。它不包括翻译文件的加载。它回答了在内容进入之前库本身有多“贵”。
+
+- **每页 JavaScript**: 对于每个基准路由，浏览器在访问时拉取的脚本量，在套件中的页面（以及报告汇总的语言）中取平均值。重的页面就是慢的页面。
+
+- **其他语言的泄漏 (Leakage)**: 指同一页面但另一种语言的内容，因错误而加载到被审计的页面中。这些内容是不必要的，应予以避免。（例如：`/fr/about` 页面内容出现在 `/en/about` 页面包中）
+
+- **其他路由的泄漏**: 应用中**其他屏幕**的同样想法：当你只打开一个页面时，它们的文案是否也随之而来。（例如：`/en/about` 页面内容出现在 `/en/contact` 页面包中）。高分暗示拆分较弱或包范围过宽。
+
+- **平均组件包大小**: 常见的 UI 部件被**逐一**测量，而不是隐藏在一个巨大的应用数字中。它显示国际化是否在静默地膨胀日常组件。例如，如果您的组件重新渲染，它将从内存加载所有这些数据。将巨大的 JSON 附加到任何组件就像连接一个庞大的未使用数据存储，这会减慢组件的性能。
+
+- **语言切换响应能力**: 我使用应用自带的控制切换语言，并计时直到页面清晰切换的时间，这是访问者会注意到的，而不是实验室的微小步骤。
+
+- **语言更改后的渲染工作**: 一个更细致的后续：一旦切换正在进行，界面为新语言重新绘制付出的努力。当“感觉到的”时间和框架成本不一致时很有用。
+
+- **初始页面加载时间**: 从导航到浏览器认为页面已完全加载（针对我测试的场景）的时间。适用于比较冷启动。
+
+- **哈イドレーション时间 (Hydration)**: 客户端将服务器 HTML 转换为可点击内容所花费的时间。表格中的破折号表示该实现在此基准测试中未提供可靠的哈イドレーション数字。
+
+## 结果详情
+
+### 1 - 应当避免的解决方案
+
+> Vue 生态系统中没有明确应当避免的解决方案。
+
+### 2 - 可接受的解决方案
+
+**(vue-i18n)** (`vue-i18n@11.4.0`):
+
+- **vue-i18n** 毫无疑问是 Vue 中最常用的 i18n 库，它具有大量功能和庞大的生态系统。但在底层，该解决方案相当沉重。即使 vue-i18n 集成了消息的懒加载，它也缺乏分层（scoping）功能。在经典的 Vue SPA 应用中没有问题，但对于使用 @nuxt/i18n 的 Nuxt 应用，它会导致所有页面的消息都包含在单个页面中。对于包含 10 个以上页面的大型 Nuxt 应用，这可能会变得非常成问题。
+
+该包非常重（~24.3kb，约为 `vue-intlayer` 的 9 倍）。
+
+**(fluent-vue)** (`fluent-vue@0.5.0`):
+
+- **fluent-vue** 通过 .ftl 格式提供了一种创新尝试。消息组织很棒，更容易上手。但在实践中，缺乏类型安全增加了错误风险，并且调试起来可能很快就会变得耗时。此外，该解决方案使用 vite 插件加载消息，强制将所有语言的所有内容加载到每个页面中。此外，这是一个极其沉重的解决方案（~92.7kb，约为 `vue-intlayer` 的 34 倍）。
+
+### 3 - 建议
+
+**(Intlayer)** (`vue-intlayer@8.7.12`):
+
+出于客观性考虑，我个人不会对 `vue-intlayer` 做出评价，因为它是我的个人解决方案。

package/docs/zh/configuration.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2024-08-13
-updatedAt: 2026-04-08
+updatedAt: 2026-05-12
 title: 配置
 description: 了解如何为您的应用程序配置 Intlayer。了解可用于根据您的需求自定义 Intlayer 的各种设置和选项。
 keywords:
@@ -14,6 +14,9 @@ slugs:
   - concept
   - configuration
 history:
+  - version: 8.9.4
+    date: 2026-05-12
+    changes: "添加对 LM Studio 提供者的支持"
   - version: 8.7.0
     date: 2026-04-08
     changes: "在构建配置中添加了 `prune` 和 `minify` 选项"
@@ -350,7 +353,7 @@ const config: IntlayerConfig = {
   ai: {
     /**
      * 使用的 AI 提供商。
-     * 选项：'openai', 'anthropic', 'mistral', 'deepseek', 'gemini', 'ollama', 'openrouter', 'alibaba', 'fireworks', 'groq', 'huggingface', 'bedrock', 'googlevertex', 'togetherai'
+     * 选项：'openai', 'anthropic', 'mistral', 'deepseek', 'gemini', 'ollama', 'openrouter', 'alibaba', 'fireworks', 'groq', 'huggingface', 'bedrock', 'googlevertex', 'togetherai', 'lmstudio'
      * 默认值：'openai'
      */
     provider: "openai",
@@ -919,16 +922,17 @@ Intlayer 支持多个 AI 提供商，以提供最大的灵活性。当前支持
 - **Groq**
 - **Amazon Bedrock**
 - **Together.ai**
-
-| 字段                 | 说明                                                                                 | 类型                                                                                                                                                                                                                                                                                                                                                                                           | 默认值      | 示例                                                          | 备注                                                                                                                                              |
-| -------------------- | ------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------- | ------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------- |
-| `provider`           | 要为 Intlayer AI 功能使用的提供商。                                                  | `'openai'` &#124; <br/> `'anthropic'` &#124; <br/> `'mistral'` &#124; <br/> `'deepseek'` &#124; <br/> `'gemini'` &#124; <br/> `'ollama'` &#124; <br/> `'openrouter'` &#124; <br/> `'alibaba'` &#124; <br/> `'fireworks'` &#124; <br/> `'groq'` &#124; <br/> `'huggingface'` &#124; <br/> `'bedrock'` &#124; <br/> `'googleaistudio'` &#124; <br/> `'googlevertex'` &#124; <br/> `'togetherai'` | `undefined` | `'anthropic'`                                                 | 不同的提供商需要不同的 API 密钥，且价格不同。                                                                                                     |
-| `model`              | 要为 AI 功能使用的 AI 模型。                                                         | `string`                                                                                                                                                                                                                                                                                                                                                                                       | 无          | `'gpt-4o-2024-11-20'`                                         | 具体模型取决于提供商。                                                                                                                            |
-| `temperature`        | 控制 AI 响应的随机性。                                                               | `number`                                                                                                                                                                                                                                                                                                                                                                                       | 无          | `0.1`                                                         | 温度越高 = 越具创造力且越不可靠。                                                                                                                 |
-| `apiKey`             | 所选提供商的您的 API 密钥。                                                          | `string`                                                                                                                                                                                                                                                                                                                                                                                       | 无          | `process.env.OPENAI_API_KEY`                                  | 应保持私密；使用环境变量。                                                                                                                        |
-| `applicationContext` | 有关应用程序的其他上下文，以帮助 AI 生成更准确的翻译（领域、目标受众、语气、术语）。 | `string`                                                                                                                                                                                                                                                                                                                                                                                       | 无          | `'我的自定义应用程序上下文'`                                  | 可用于添加规则（例如：`"您不应转换您的 URL"` ）。                                                                                                 |
-| `baseURL`            | AI API 的基础 URL。                                                                  | `string`                                                                                                                                                                                                                                                                                                                                                                                       | 无          | `'https://api.openai.com/v1'` <br/> `'http://localhost:5000'` | 可以指向本地或自定义的 AI API 端点。                                                                                                              |
-| `dataSerialization`  | AI 功能的数据序列化格式。                                                            | `'json'` &#124; <br/> `'toon'`                                                                                                                                                                                                                                                                                                                                                                 | `undefined` | `'toon'`                                                      | • `'json'`: 默认，可靠；使用更多 token。<br/>• `'toon'`: token 更少，但也更不稳定。<br/>• 将上下文作为额外参数（reasoning effort 等）传递给模型。 |
+- **LM Studio**
+
+| 字段                 | 说明                                                                                 | 类型                                                                                                                                                                                                                                                                                                                                                                                                                     | 默认值      | 示例                                                          | 备注                                                                                                                                              |
+| -------------------- | ------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ----------- | ------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `provider`           | 要为 Intlayer AI 功能使用的提供商。                                                  | `'openai'` &#124; <br/> `'anthropic'` &#124; <br/> `'mistral'` &#124; <br/> `'deepseek'` &#124; <br/> `'gemini'` &#124; <br/> `'ollama'` &#124; <br/> `'openrouter'` &#124; <br/> `'alibaba'` &#124; <br/> `'fireworks'` &#124; <br/> `'groq'` &#124; <br/> `'huggingface'` &#124; <br/> `'bedrock'` &#124; <br/> `'googleaistudio'` &#124; <br/> `'googlevertex'` &#124; <br/> `'togetherai'` &#124; <br/> `'lmstudio'` | `undefined` | `'anthropic'`                                                 | 不同的提供商需要不同的 API 密钥，且价格不同。                                                                                                     |
+| `model`              | 要为 AI 功能使用的 AI 模型。                                                         | `string`                                                                                                                                                                                                                                                                                                                                                                                                                 | 无          | `'gpt-4o-2024-11-20'`                                         | 具体模型取决于提供商。                                                                                                                            |
+| `temperature`        | 控制 AI 响应的随机性。                                                               | `number`                                                                                                                                                                                                                                                                                                                                                                                                                 | 无          | `0.1`                                                         | 温度越高 = 越具创造力且越不可靠。                                                                                                                 |
+| `apiKey`             | 所选提供商的您的 API 密钥。                                                          | `string`                                                                                                                                                                                                                                                                                                                                                                                                                 | 无          | `process.env.OPENAI_API_KEY`                                  | 应保持私密；使用环境变量。                                                                                                                        |
+| `applicationContext` | 有关应用程序的其他上下文，以帮助 AI 生成更准确的翻译（领域、目标受众、语气、术语）。 | `string`                                                                                                                                                                                                                                                                                                                                                                                                                 | 无          | `'我的自定义应用程序上下文'`                                  | 可用于添加规则（例如：`"您不应转换您的 URL"` ）。                                                                                                 |
+| `baseURL`            | AI API 的基础 URL。                                                                  | `string`                                                                                                                                                                                                                                                                                                                                                                                                                 | 无          | `'https://api.openai.com/v1'` <br/> `'http://localhost:5000'` | 可以指向本地或自定义的 AI API 端点。                                                                                                              |
+| `dataSerialization`  | AI 功能的数据序列化格式。                                                            | `'json'` &#124; <br/> `'toon'`                                                                                                                                                                                                                                                                                                                                                                                           | `undefined` | `'toon'`                                                      | • `'json'`: 默认，可靠；使用更多 token。<br/>• `'toon'`: token 更少，但也更不稳定。<br/>• 将上下文作为额外参数（reasoning effort 等）传递给模型。 |
 
 ---