@intlayer/docs 8.9.4-canary.0 → 8.9.5

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (207) hide show
  1. package/dist/cjs/generated/docs.entry.cjs +20 -0
  2. package/dist/cjs/generated/docs.entry.cjs.map +1 -1
  3. package/dist/esm/generated/docs.entry.mjs +20 -0
  4. package/dist/esm/generated/docs.entry.mjs.map +1 -1
  5. package/dist/types/generated/docs.entry.d.ts +1 -0
  6. package/dist/types/generated/docs.entry.d.ts.map +1 -1
  7. package/docs/ar/benchmark/index.md +0 -3
  8. package/docs/ar/benchmark/nextjs.md +15 -6
  9. package/docs/ar/benchmark/solid.md +155 -0
  10. package/docs/ar/benchmark/svelte.md +148 -0
  11. package/docs/ar/benchmark/tanstack.md +12 -3
  12. package/docs/ar/benchmark/vue.md +160 -0
  13. package/docs/ar/configuration.md +16 -12
  14. package/docs/ar/dictionary/content_file.md +51 -1
  15. package/docs/ar/mcp_server.md +30 -17
  16. package/docs/ar/plugins/sync-po.md +333 -0
  17. package/docs/bn/configuration.md +16 -12
  18. package/docs/cs/configuration.md +16 -12
  19. package/docs/de/benchmark/index.md +0 -3
  20. package/docs/de/benchmark/nextjs.md +15 -6
  21. package/docs/de/benchmark/solid.md +155 -0
  22. package/docs/de/benchmark/svelte.md +148 -0
  23. package/docs/de/benchmark/tanstack.md +12 -3
  24. package/docs/de/benchmark/vue.md +160 -0
  25. package/docs/de/configuration.md +16 -12
  26. package/docs/de/dictionary/content_file.md +52 -2
  27. package/docs/de/mcp_server.md +29 -16
  28. package/docs/de/plugins/sync-po.md +332 -0
  29. package/docs/en/benchmark/nextjs.md +11 -2
  30. package/docs/en/benchmark/solid.md +22 -4
  31. package/docs/en/benchmark/svelte.md +17 -5
  32. package/docs/en/benchmark/tanstack.md +18 -3
  33. package/docs/en/benchmark/vue.md +17 -11
  34. package/docs/en/configuration.md +16 -13
  35. package/docs/en/dictionary/content_file.md +51 -1
  36. package/docs/en/mcp_server.md +31 -18
  37. package/docs/en/plugins/sync-po.md +333 -0
  38. package/docs/en-GB/benchmark/index.md +0 -3
  39. package/docs/en-GB/benchmark/nextjs.md +15 -6
  40. package/docs/en-GB/benchmark/solid.md +155 -0
  41. package/docs/en-GB/benchmark/svelte.md +148 -0
  42. package/docs/en-GB/benchmark/tanstack.md +12 -3
  43. package/docs/en-GB/benchmark/vue.md +160 -0
  44. package/docs/en-GB/configuration.md +15 -11
  45. package/docs/en-GB/dictionary/content_file.md +51 -1
  46. package/docs/en-GB/mcp_server.md +31 -18
  47. package/docs/en-GB/plugins/sync-po.md +333 -0
  48. package/docs/es/benchmark/index.md +0 -3
  49. package/docs/es/benchmark/nextjs.md +15 -6
  50. package/docs/es/benchmark/solid.md +155 -0
  51. package/docs/es/benchmark/svelte.md +148 -0
  52. package/docs/es/benchmark/tanstack.md +12 -3
  53. package/docs/es/benchmark/vue.md +160 -0
  54. package/docs/es/configuration.md +16 -12
  55. package/docs/es/dictionary/content_file.md +51 -1
  56. package/docs/es/mcp_server.md +30 -17
  57. package/docs/es/plugins/sync-po.md +333 -0
  58. package/docs/fr/benchmark/index.md +0 -3
  59. package/docs/fr/benchmark/nextjs.md +15 -6
  60. package/docs/fr/benchmark/solid.md +155 -0
  61. package/docs/fr/benchmark/svelte.md +148 -0
  62. package/docs/fr/benchmark/tanstack.md +12 -3
  63. package/docs/fr/benchmark/vue.md +160 -0
  64. package/docs/fr/configuration.md +16 -12
  65. package/docs/fr/dictionary/content_file.md +51 -1
  66. package/docs/fr/mcp_server.md +30 -17
  67. package/docs/fr/plugins/sync-po.md +333 -0
  68. package/docs/hi/benchmark/nextjs.md +15 -6
  69. package/docs/hi/benchmark/solid.md +155 -0
  70. package/docs/hi/benchmark/svelte.md +148 -0
  71. package/docs/hi/benchmark/tanstack.md +12 -3
  72. package/docs/hi/benchmark/vue.md +160 -0
  73. package/docs/hi/configuration.md +16 -12
  74. package/docs/hi/dictionary/content_file.md +51 -1
  75. package/docs/hi/mcp_server.md +31 -18
  76. package/docs/hi/plugins/sync-po.md +333 -0
  77. package/docs/id/benchmark/index.md +0 -3
  78. package/docs/id/benchmark/nextjs.md +15 -6
  79. package/docs/id/benchmark/solid.md +155 -0
  80. package/docs/id/benchmark/svelte.md +148 -0
  81. package/docs/id/benchmark/tanstack.md +12 -3
  82. package/docs/id/benchmark/vue.md +160 -0
  83. package/docs/id/configuration.md +16 -12
  84. package/docs/id/dictionary/content_file.md +51 -1
  85. package/docs/id/mcp_server.md +30 -17
  86. package/docs/id/plugins/sync-po.md +333 -0
  87. package/docs/it/benchmark/index.md +1 -4
  88. package/docs/it/benchmark/nextjs.md +15 -6
  89. package/docs/it/benchmark/solid.md +155 -0
  90. package/docs/it/benchmark/svelte.md +148 -0
  91. package/docs/it/benchmark/tanstack.md +12 -3
  92. package/docs/it/benchmark/vue.md +160 -0
  93. package/docs/it/configuration.md +16 -12
  94. package/docs/it/dictionary/content_file.md +51 -1
  95. package/docs/it/mcp_server.md +30 -17
  96. package/docs/it/plugins/sync-po.md +333 -0
  97. package/docs/ja/benchmark/index.md +5 -5
  98. package/docs/ja/benchmark/nextjs.md +15 -6
  99. package/docs/ja/benchmark/solid.md +155 -0
  100. package/docs/ja/benchmark/svelte.md +148 -0
  101. package/docs/ja/benchmark/tanstack.md +12 -3
  102. package/docs/ja/benchmark/vue.md +160 -0
  103. package/docs/ja/configuration.md +16 -12
  104. package/docs/ja/dictionary/content_file.md +50 -2
  105. package/docs/ja/intlayer_with_nextjs_no_locale_path.md +4 -3
  106. package/docs/ja/mcp_server.md +29 -16
  107. package/docs/ja/plugins/sync-po.md +333 -0
  108. package/docs/ko/benchmark/nextjs.md +15 -6
  109. package/docs/ko/benchmark/solid.md +155 -0
  110. package/docs/ko/benchmark/svelte.md +148 -0
  111. package/docs/ko/benchmark/tanstack.md +12 -3
  112. package/docs/ko/benchmark/vue.md +160 -0
  113. package/docs/ko/configuration.md +16 -12
  114. package/docs/ko/dictionary/content_file.md +51 -1
  115. package/docs/ko/intlayer_with_nextjs_no_locale_path.md +3 -2
  116. package/docs/ko/mcp_server.md +31 -18
  117. package/docs/ko/plugins/sync-po.md +333 -0
  118. package/docs/nl/configuration.md +16 -12
  119. package/docs/pl/benchmark/index.md +0 -3
  120. package/docs/pl/benchmark/nextjs.md +15 -6
  121. package/docs/pl/benchmark/solid.md +155 -0
  122. package/docs/pl/benchmark/svelte.md +148 -0
  123. package/docs/pl/benchmark/tanstack.md +12 -3
  124. package/docs/pl/benchmark/vue.md +160 -0
  125. package/docs/pl/configuration.md +16 -12
  126. package/docs/pl/dictionary/content_file.md +51 -1
  127. package/docs/pl/mcp_server.md +30 -17
  128. package/docs/pl/plugins/sync-po.md +333 -0
  129. package/docs/pt/benchmark/index.md +0 -3
  130. package/docs/pt/benchmark/nextjs.md +16 -7
  131. package/docs/pt/benchmark/solid.md +155 -0
  132. package/docs/pt/benchmark/svelte.md +148 -0
  133. package/docs/pt/benchmark/tanstack.md +13 -4
  134. package/docs/pt/benchmark/vue.md +160 -0
  135. package/docs/pt/configuration.md +16 -12
  136. package/docs/pt/dictionary/content_file.md +51 -1
  137. package/docs/pt/mcp_server.md +30 -17
  138. package/docs/pt/plugins/sync-po.md +333 -0
  139. package/docs/ru/benchmark/nextjs.md +15 -6
  140. package/docs/ru/benchmark/solid.md +155 -0
  141. package/docs/ru/benchmark/svelte.md +148 -0
  142. package/docs/ru/benchmark/tanstack.md +12 -3
  143. package/docs/ru/benchmark/vue.md +160 -0
  144. package/docs/ru/configuration.md +16 -12
  145. package/docs/ru/dictionary/content_file.md +52 -2
  146. package/docs/ru/mcp_server.md +30 -17
  147. package/docs/ru/plugins/sync-po.md +333 -0
  148. package/docs/tr/benchmark/index.md +0 -3
  149. package/docs/tr/benchmark/nextjs.md +15 -6
  150. package/docs/tr/benchmark/solid.md +155 -0
  151. package/docs/tr/benchmark/svelte.md +148 -0
  152. package/docs/tr/benchmark/tanstack.md +12 -3
  153. package/docs/tr/benchmark/vue.md +160 -0
  154. package/docs/tr/configuration.md +16 -12
  155. package/docs/tr/dictionary/content_file.md +51 -1
  156. package/docs/tr/mcp_server.md +31 -18
  157. package/docs/tr/plugins/sync-po.md +333 -0
  158. package/docs/uk/benchmark/nextjs.md +15 -6
  159. package/docs/uk/benchmark/solid.md +155 -0
  160. package/docs/uk/benchmark/svelte.md +148 -0
  161. package/docs/uk/benchmark/tanstack.md +12 -3
  162. package/docs/uk/benchmark/vue.md +160 -0
  163. package/docs/uk/configuration.md +16 -12
  164. package/docs/uk/dictionary/content_file.md +51 -1
  165. package/docs/uk/mcp_server.md +29 -16
  166. package/docs/uk/plugins/sync-po.md +333 -0
  167. package/docs/ur/configuration.md +16 -12
  168. package/docs/vi/benchmark/index.md +0 -3
  169. package/docs/vi/benchmark/nextjs.md +15 -6
  170. package/docs/vi/benchmark/solid.md +155 -0
  171. package/docs/vi/benchmark/svelte.md +148 -0
  172. package/docs/vi/benchmark/tanstack.md +12 -3
  173. package/docs/vi/benchmark/vue.md +160 -0
  174. package/docs/vi/configuration.md +16 -12
  175. package/docs/vi/dictionary/content_file.md +51 -1
  176. package/docs/vi/intlayer_with_nextjs_15.md +10 -57
  177. package/docs/vi/mcp_server.md +30 -17
  178. package/docs/vi/plugins/sync-po.md +333 -0
  179. package/docs/zh/benchmark/nextjs.md +15 -6
  180. package/docs/zh/benchmark/solid.md +155 -0
  181. package/docs/zh/benchmark/svelte.md +148 -0
  182. package/docs/zh/benchmark/tanstack.md +12 -3
  183. package/docs/zh/benchmark/vue.md +160 -0
  184. package/docs/zh/configuration.md +16 -12
  185. package/docs/zh/dictionary/content_file.md +51 -3
  186. package/docs/zh/mcp_server.md +31 -18
  187. package/docs/zh/plugins/sync-po.md +333 -0
  188. package/frequent_questions/ar/intlayerNode.md +3 -3
  189. package/frequent_questions/de/intlayerNode.md +3 -3
  190. package/frequent_questions/en/intlayerNode.md +3 -3
  191. package/frequent_questions/en-GB/intlayerNode.md +3 -3
  192. package/frequent_questions/es/intlayerNode.md +3 -3
  193. package/frequent_questions/fr/intlayerNode.md +3 -3
  194. package/frequent_questions/hi/intlayerNode.md +3 -3
  195. package/frequent_questions/id/intlayerNode.md +3 -3
  196. package/frequent_questions/it/intlayerNode.md +3 -3
  197. package/frequent_questions/ja/intlayerNode.md +3 -3
  198. package/frequent_questions/ko/intlayerNode.md +3 -3
  199. package/frequent_questions/pl/intlayerNode.md +3 -3
  200. package/frequent_questions/pt/intlayerNode.md +3 -3
  201. package/frequent_questions/ru/intlayerNode.md +3 -3
  202. package/frequent_questions/tr/intlayerNode.md +3 -3
  203. package/frequent_questions/uk/intlayerNode.md +3 -3
  204. package/frequent_questions/vi/intlayerNode.md +3 -3
  205. package/frequent_questions/zh/intlayerNode.md +3 -3
  206. package/package.json +8 -8
  207. package/src/generated/docs.entry.ts +20 -0
@@ -0,0 +1,155 @@
1
+ ---
2
+ createdAt: 2026-04-20
3
+ updatedAt: 2026-04-21
4
+ title: Найкраще i18n рішення для Solid у 2026 році — Звіт про бенчмарк
5
+ description: Порівняйте бібліотеки інтернаціоналізації (i18n) для Solid, такі як solid-primitives, solid-i18next та Intlayer. Детальний звіт про продуктивність щодо розміру бандла, витоків та реактивності.
6
+ keywords:
7
+ - benchmark
8
+ - i18n
9
+ - intl
10
+ - solid
11
+ - продуктивність
12
+ - intlayer
13
+ slugs:
14
+ - doc
15
+ - benchmark
16
+ - solid
17
+ author: Aymeric PINEAU
18
+ applicationTemplate: https://github.com/intlayer-org/benchmark-i18n-solid-template
19
+ history:
20
+ - version: 8.7.12
21
+ date: 2026-01-06
22
+ changes: "Ініціалізація бенчмарку"
23
+ ---
24
+
25
+ # Бібліотеки i18n для Solid — Звіт про бенчмарк 2026
26
+
27
+ Ця сторінка є звітом про бенчмарк рішень i18n на Solid.
28
+
29
+ ## Зміст
30
+
31
+ <Toc/>
32
+
33
+ ## Інтерактивний бенчмарк
34
+
35
+ <I18nBenchmark framework="vite-solid" vertical/>
36
+
37
+ ## Посилання на результати:
38
+
39
+ <iframe
40
+ src="https://intlayer.org/markdown?url=https%3A%2F%2Fraw.githubusercontent.com%2Fintlayer-org%2Fbenchmark-i18n%2Fmain%2Freport%2Fscripts%2Fsummarize-vite_solid.md"
41
+ width="100%"
42
+ height="600px"
43
+ style="border:none;">
44
+ </iframe>
45
+
46
+ > https://intlayer.org/markdown?url=https%3A%2F%2Fraw.githubusercontent.com%2Fintlayer-org%2Fbenchmark-i18n%2Fmain%2Freport%2Fscripts%2Fsummarize-vite_solid.md
47
+
48
+ Повний репозиторій бенчмарку можна знайти [тут](https://github.com/intlayer-org/benchmark-i18n/tree/main).
49
+
50
+ ## Вступ
51
+
52
+ Рішення для інтернаціоналізації є одними з найважчих залежностей у додатку Solid. Основний ризик полягає у відправці непотрібного контенту: перекладів для інших сторінок та інших локалей у бандлі одного маршруту.
53
+
54
+ З ростом вашого додатка ця проблема може швидко збільшити обсяг JavaScript, що надсилається клієнту, і сповільнити навігацію.
55
+
56
+ На практиці, для найменш оптимізованих реалізацій, інтернаціоналізована сторінка може виявитися в кілька разів важчою, ніж версія без i18n.
57
+
58
+ Інший вплив стосується досвіду розробника (DX): як ви оголошуєте контент, типи, організацію просторів імен, динамічне завантаження та реактивність при зміні локалі.
59
+
60
+ ## TL;DR
61
+
62
+ - **Intlayer**: Рекомендований вибір для професійних додатків Solid, які потребують розширених функцій та оптимізації (v8.7.12).
63
+ - **@solid-primitives/i18n**: Відмінна легка альтернатива для простих проєктів, хоча їй бракує розширених функцій, таких як lazy loading.
64
+ - **solid-i18next**: Стандартний, але важкий варіант (~4.7 рази більше за Intlayer) з тими ж недоліками, що і React i18next.
65
+ - **Paraglide**: Інноваційний підхід, але складний DX та проблеми з tree-shaking у деяких конфігураціях.
66
+
67
+ ## Протестуйте свій додаток
68
+
69
+ Щоб швидко виявити проблеми з витоком i18n, я налаштував безкоштовний сканер, доступний [тут](https://intlayer.org/i18n-seo-scanner).
70
+
71
+ <iframe src="https://intlayer.org/i18n-seo-scanner" width="100%" height="600px" style="border:none;"/>
72
+
73
+ ## Проблема
74
+
75
+ Два важелі є важливими для обмеження вартості багатомовного додатка:
76
+
77
+ - Розділіть контент за сторінками / просторами імен, щоб не завантажувати цілі словники, коли вони не потрібні.
78
+ - Завантажуйте потрібну локаль динамічно, тільки коли це необхідно.
79
+
80
+ Розуміння технічних обмежень цих підходів:
81
+
82
+ **Динамічне завантаження**
83
+
84
+ Без динамічного завантаження більшість рішень зберігають повідомлення в пам'яті з першого рендеру, що додає значне навантаження для додатків з багатьма маршрутами та локалями.
85
+
86
+ З динамічним завантаженням ви приймаєте компроміс: менше початкового JS, але іноді додатковий запит при зміні мови.
87
+
88
+ **Поділ контенту (Splitting)**
89
+
90
+ Синтаксис, побудований навколо `t('a.b.c')`, дуже зручний, але часто заохочує зберігати великі JSON-об'єкти під час виконання. Ця модель ускладнює tree-shaking, якщо бібліотека не пропонує реальної стратегії поділу на сторінки.
91
+
92
+ ## Методологія дослідження
93
+
94
+ Для цього бенчмарку ми порівняли наступні бібліотеки:
95
+
96
+ - `Base App` (Без бібліотеки i18n)
97
+ - `solid-intlayer` (v8.7.12)
98
+ - `@solid-primitives/i18n` (v2.2.1)
99
+ - `solid-i18next` (v17.0.2)
100
+ - `@inlang/paraglide-js` (v2.17.0)
101
+
102
+ Фреймворк — `Solid` з багатомовним додатком із **10 сторінок** і **10 мов**.
103
+
104
+ Ми порівняли **чотири стратегії завантаження**:
105
+
106
+ | Стратегія | Без просторів імен (глобально) | З просторами імен (scoped) |
107
+ | :------------------------- | :------------------------------------------------------ | :---------------------------------------------------------------------------- |
108
+ | **Статичне завантаження** | **Static**: Все в пам'яті при запуску. | **Scoped static**: Розділено за просторами імен; все завантажено при запуску. |
109
+ | **Динамічне завантаження** | **Dynamic**: Завантаження за запитом для кожної локалі. | **Scoped dynamic**: Детальне завантаження за простором імен та локаллю. |
110
+
111
+ ## Підсумок стратегій
112
+
113
+ - **Static**: Просто; немає затримки мережі після початкового завантаження. Мінус: великий розмір бандла.
114
+ - **Dynamic**: Зменшує початкову вагу (lazy-loading). Ідеально, коли у вас багато локалей.
115
+ - **Scoped static**: Зберігає код організованим (логічне розділення) без складних додаткових мережевих запитів.
116
+ - **Scoped dynamic**: Найкращий підхід для _code splitting_ та продуктивності. Мінімізує пам'ять, завантажуючи лише те, що потрібно поточному перегляду та активній локалі.
117
+
118
+ ## Результати детально
119
+
120
+ ### 1 — Рішення, яких слід уникати
121
+
122
+ > В екосистемі Solid немає очевидних рішень, яких слід уникати.
123
+
124
+ ### 2 — Прийнятні рішення
125
+
126
+ **(solid-i18next)** (`solid-i18next@17.0.2`):
127
+
128
+ `solid-i18next`, ймовірно, є найпопулярнішим варіантом, оскільки він був одним із перших, хто задовольнив потреби i18n у JavaScript-додатках. Він також має широкий набір плагінів спільноти для конкретних проблем.
129
+
130
+ Пакет важкий (~14.6kb, що приблизно в 4.7 рази більше за `solid-intlayer`).
131
+
132
+ Тим не менш, він має ті ж основні недоліки, що і стеки, побудовані на `t('a.b.c')`: оптимізація можлива, але забирає багато часу, а великі проєкти ризикують поганими практиками (простори імен + динамічне завантаження + типи).
133
+
134
+ **(@solid-primitives/i18n)** (`@solid-primitives/i18n@2.2.1`):
135
+
136
+ Solid primitive надзвичайно легкий і ефективний. Я рекомендую це рішення для легких проєктів, але в ньому може швидко не вистачити функцій для професійних рішень, що включають управління кукі, перенаправлення проксі, форматери тощо.
137
+ Йому також не вистачає lazy loading та скоупінгу просторів імен для оптимізації розміру сторінки.
138
+
139
+ **(Paraglide)** (`@inlang/paraglide-js@2.17.0`):
140
+
141
+ `Paraglide` пропонує інноваційний, добре продуманий підхід. Незважаючи на це, у цьому бенчмарку деревоподібне шейкінг (tree-shaking), яке рекламує їхня компанія, не спрацювало для моєї реалізації. Робочий процес і DX також складніші за інші варіанти.
142
+ Особисто я не прихильник того, щоб перегенерувати файли JS перед кожним пушем, що створює постійний ризик конфліктів при злитті через PR.
143
+ Нарешті, у порівнянні з іншими рішеннями, Paraglide не використовує стор (наприклад, Solid signal) для отримання поточної локалі для рендерингу контенту. Для кожного розібраного вузла він запитуватиме локаль з localStorage / cookie тощо. Це призводить до виконання непотрібної логіки, яка впливає на реактивність компонентів.
144
+
145
+ ### 3 — Рекомендації
146
+
147
+ **(Intlayer)** (`solid-intlayer@8.7.12`):
148
+
149
+ Я не буду особисто оцінювати `solid-intlayer` заради об'єктивності, оскільки це моє власне рішення.
150
+
151
+ ### Особиста примітка
152
+
153
+ Ця примітка є особистою і не впливає на результати бенчмарку. Тим не менш, у світі i18n часто можна побачити консенсус щодо патерну на кшталт `const t = useTranslation('xx')` + `<>{t('xx.xx')}</>` для перекладеного контенту.
154
+
155
+ У додатках Solid впорскування функції як `JSX.Element`, на мій погляд, є антипатерном. Це також додає зайву складність та накладні витрати на виконання JavaScript (навіть якщо це ледь помітно).
@@ -0,0 +1,148 @@
1
+ ---
2
+ createdAt: 2026-04-20
3
+ updatedAt: 2026-04-21
4
+ title: Найкраще i18n рішення для Svelte у 2026 році — Звіт про бенчмарк
5
+ description: Порівняйте бібліотеки інтернаціоналізації (i18n) для Svelte, такі як svelte-i18n, Paraglide та Intlayer. Детальний звіт про продуктивність щодо розміру бандла, витоків та реактивності.
6
+ keywords:
7
+ - benchmark
8
+ - i18n
9
+ - intl
10
+ - svelte
11
+ - продуктивність
12
+ - intlayer
13
+ slugs:
14
+ - doc
15
+ - benchmark
16
+ - svelte
17
+ author: Aymeric PINEAU
18
+ applicationTemplate: https://github.com/intlayer-org/benchmark-i18n-svelte-template
19
+ history:
20
+ - version: 8.7.12
21
+ date: 2026-01-06
22
+ changes: "Ініціалізація бенчмарку"
23
+ ---
24
+
25
+ # Бібліотеки i18n для Svelte — Звіт про бенчмарк 2026
26
+
27
+ Ця сторінка є звітом про бенчмарк рішень i18n на Svelte.
28
+
29
+ ## Зміст
30
+
31
+ <Toc/>
32
+
33
+ ## Інтерактивний бенчмарк
34
+
35
+ <I18nBenchmark framework="vite-svelte" vertical/>
36
+
37
+ ## Посилання на результати:
38
+
39
+ <iframe
40
+ src="https://intlayer.org/markdown?url=https%3A%2F%2Fraw.githubusercontent.com%2Fintlayer-org%2Fbenchmark-i18n%2Fmain%2Freport%2Fscripts%2Fsummarize-vite_svelte.md"
41
+ width="100%"
42
+ height="600px"
43
+ style="border:none;">
44
+ </iframe>
45
+
46
+ > https://intlayer.org/markdown?url=https%3A%2F%2Fraw.githubusercontent.com%2Fintlayer-org%2Fbenchmark-i18n%2Fmain%2Freport%2Fscripts%2Fsummarize-vite_svelte.md
47
+
48
+ Повний репозиторій бенчмарку можна знайти [тут](https://github.com/intlayer-org/benchmark-i18n/tree/main).
49
+
50
+ ## Вступ
51
+
52
+ Рішення для інтернаціоналізації є одними з найважчих залежностей у додатку Svelte. Основний ризик полягає у відправці непотрібного контенту: перекладів для інших сторінок та інших локалей у бандлі одного маршруту.
53
+
54
+ З ростом вашого додатка ця проблема може швидко збільшити обсяг JavaScript, що надсилається клієнту, і сповільнити навігацію.
55
+
56
+ На практиці, для найменш оптимізованих реалізацій, інтернаціоналізована сторінка може виявитися в кілька разів важчою, ніж версія без i18n.
57
+
58
+ Інший вплив стосується досвіду розробника (DX): як ви оголошуєте контент, типи, організацію просторів імен, динамічне завантаження та реактивність при зміні локалі.
59
+
60
+ ## TL;DR
61
+
62
+ - **Intlayer**: Найефективніший за продуктивністю вибір (v8.7.12) з найменшим слідом (footprint).
63
+ - **Paraglide**: Сильний претендент для tree-shaking, але має складніший досвід розробника та накладні витрати на реактивність.
64
+ - **svelte-i18n**: Комплексний та стандартний для Svelte, але несе значно більшу вагу бандла (~7 разів більше за Intlayer).
65
+
66
+ ## Протестуйте свій додаток
67
+
68
+ Щоб швидко виявити проблеми з витоком i18n, я налаштував безкоштовний сканер, доступний [тут](https://intlayer.org/i18n-seo-scanner).
69
+
70
+ <iframe src="https://intlayer.org/i18n-seo-scanner" width="100%" height="600px" style="border:none;"/>
71
+
72
+ ## Проблема
73
+
74
+ Два важелі є важливими для обмеження вартості багатомовного додатка:
75
+
76
+ - Розділіть контент за сторінками / просторами імен, щоб не завантажувати цілі словники, коли вони не потрібні.
77
+ - Завантажуйте потрібну локаль динамічно, тільки коли це необхідно.
78
+
79
+ Розуміння технічних обмежень цих підходів:
80
+
81
+ **Динамічне завантаження**
82
+
83
+ Без динамічного завантаження більшість рішень зберігають повідомлення в пам'яті з першого рендеру, що додає значне навантаження для додатків з багатьма маршрутами та локалями.
84
+
85
+ З динамічним завантаженням ви приймаєте компроміс: менше початкового JS, але іноді додатковий запит при зміні мови.
86
+
87
+ **Поділ контенту (Splitting)**
88
+
89
+ Синтаксис, побудований навколо `t('a.b.c')`, дуже зручний, але часто заохочує зберігати великі JSON-об'єкти під час виконання. Ця модель ускладнює tree-shaking, якщо бібліотека не пропонує реальної стратегії поділу на сторінки.
90
+
91
+ ## Методологія дослідження
92
+
93
+ Для цього бенчмарку ми порівняли наступні бібліотеки:
94
+
95
+ - `Base App` (Без бібліотеки i18n)
96
+ - `svelte-intlayer` (v8.7.12)
97
+ - `svelte-i18n` (v4.0.1)
98
+ - `@inlang/paraglide-js` (v2.17.0)
99
+
100
+ Фреймворк — `Svelte` з багатомовним додатком із **10 сторінок** і **10 мов**.
101
+
102
+ Ми порівняли **чотири стратегії завантаження**:
103
+
104
+ | Стратегія | Без просторів імен (глобально) | З просторами імен (scoped) |
105
+ | :------------------------- | :------------------------------------------------------ | :---------------------------------------------------------------------------- |
106
+ | **Статичне завантаження** | **Static**: Все в пам'яті при запуску. | **Scoped static**: Розділено за просторами імен; все завантажено при запуску. |
107
+ | **Динамічне завантаження** | **Dynamic**: Завантаження за запитом для кожної локалі. | **Scoped dynamic**: Детальне завантаження за простором імен та локаллю. |
108
+
109
+ ## Підсумок стратегій
110
+
111
+ - **Static**: Просто; немає затримки мережі після початкового завантаження. Мінус: великий розмір бандла.
112
+ - **Dynamic**: Зменшує початкову вагу (lazy-loading). Ідеально, коли у вас багато локалей.
113
+ - **Scoped static**: Зберігає код організованим (логічне розділення) без складних додаткових мережевих запитів.
114
+ - **Scoped dynamic**: Найкращий підхід для _code splitting_ та продуктивності. Мінімізує пам'ять, завантажуючи лише те, що потрібно поточному перегляду та активній локалі.
115
+
116
+ ## Результати детально
117
+
118
+ ### 1 — Рішення, яких слід уникати
119
+
120
+ > В екосистемі Svelte немає очевидних рішень, яких слід уникати.
121
+
122
+ ### 2 — Прийнятні рішення
123
+
124
+ **(Paraglide)** (`@inlang/paraglide-js@2.17.0`):
125
+
126
+ `Paraglide` пропонує інноваційний, добре продуманий підхід. У контексті додатка Vite + Svelte деревоподібне шейкінг (tree-shaking), яке рекламує їхня компанія, працювало як очікувалося, і це чудово.
127
+ Але у випадку React + TanStack Start tree-shaking не спрацював як очікувалося, те саме для Next.js. Тим не менш, використання Paraglide у проєкті Svelte та TanStack Start варто було б перевірити ще раз.
128
+ Робочий процес і DX також складніші за інші варіанти.
129
+ Особисто я не прихильник того, щоб перегенерувати файли JS перед кожним пушем, що створює постійний ризик конфліктів при злитті через PR. Інструмент також здається більш зосередженим на Vite, ніж на Next.js.
130
+ Нарешті, у порівнянні з іншими рішеннями, Paraglide не використовує стор (наприклад, Svelte store) для отримання поточної локалі для рендерингу контенту. Для кожного розібраного вузла він запитуватиме локаль з localStorage / cookie тощо. Це призводить до виконання непотрібної логіки, яка впливає на реактивність компонентів.
131
+
132
+ > Примітка щодо paraglide: рішення впорскує код у вашу кодову базу для імпорту; як результат, метрика 'lib size' у звіті бенчмарку становить майже 0. Генерація коду — це добре, тому що використана функція включатиме лише необхідну логіку (префікс скрізь проти відсутності префікса, кукі проти сховища тощо). Для порівняння, Intlayer виконує цю фільтрацію за допомогою впорскування змінних оточення під час збірки, щоб змусити бандлер виконувати tree-shaking контенту залежно від логіки. Завдяки цьому paraglide та intlayer стають у 6–10 разів легшими рішеннями, ніж i18next або next-intl.
133
+
134
+ **(svelte-i18n)** (`svelte-i18n@3.4.0`):
135
+
136
+ Це рішення задовольняє всі потреби i18n у проєкті Svelte. Але як і у випадку з i18next або іншими великими i18n рішеннями, воно трохи важке (~15.9kb, що приблизно в 7 разів більше за `svelte-intlayer`).
137
+
138
+ ### 3 — Рекомендації
139
+
140
+ **(Intlayer)** (`svelte-intlayer@8.7.12`):
141
+
142
+ Я не буду особисто оцінювати `svelte-intlayer` заради об'єктивності, оскільки це моє власне рішення.
143
+
144
+ ### Особиста примітка
145
+
146
+ Ця примітка є особистою і не впливає на результати бенчмарку. Тим не менш, у світі i18n часто можна побачити консенсус щодо патерну на кшталт `const t = useTranslation('xx')` + `<>{t('xx.xx')}</>` для перекладеного контенту.
147
+
148
+ У додатках Svelte впорскування функції як `Slot`, на мій погляд, є антипатерном. Це також додає зайву складність та накладні витрати на виконання JavaScript (навіть якщо це ледь помітно).
@@ -57,6 +57,13 @@ history:
57
57
 
58
58
  Інший вплив стосується досвіду розробника (DX): як ви оголошуєте контент, типи, організація просторів імен, динамічне завантаження та реактивність при зміні мови.
59
59
 
60
+ ## TL;DR
61
+
62
+ - **Intlayer**: Забезпечує найкращу продуктивність і найменший розмір бандла (v8.7.12) для TanStack Start.
63
+ - **react-i18next** та **use-intl**: Зрілі альтернативи з великими екосистемами, але значно важчі та складніші в оптимізації.
64
+ - **Paraglide**: Інноваційна ідея tree-shaking, яка не працює на практиці. Складний DX та накладні витрати реактивності в TanStack Start.
65
+ - **Уникайте**: **General Translation (GT)** та **Lingo.dev** через серйозні проблеми з продуктивністю, ліміти ШІ та прив'язку до вендора (vendor lock-in).
66
+
60
67
  ## Протестуйте свій додаток
61
68
 
62
69
  Щоб швидко виявити проблеми з витоком i18n, я налаштував безкоштовний сканер, доступний [тут](https://intlayer.org/i18n-seo-scanner).
@@ -87,12 +94,12 @@ history:
87
94
  Для цього бенчмарку ми порівняли наступні бібліотеки:
88
95
 
89
96
  - `Base App` (Без бібліотеки i18n)
90
- - `react-intlayer` (v8.7.5-canary.0)
97
+ - `react-intlayer` (v8.7.12)
91
98
  - `react-i18next` (v17.0.2)
92
99
  - `use-intl` (v4.9.1)
93
100
  - `@lingui/core` (v5.3.0)
94
101
  - `@inlang/paraglide-js` (v2.15.1)
95
- - `tolgee` (v7.0.0)
102
+ - `@tolgee/react` (v7.0.0)
96
103
  - `react-intl` (v10.1.1)
97
104
  - `wuchale` (v0.22.11)
98
105
  - `gt-react` (vlatest)
@@ -150,7 +157,9 @@ history:
150
157
 
151
158
  `Paraglide` пропонує інноваційний, добре продуманий підхід. Проте в цьому тесті рекламований компанією tree-shaking не спрацював ні для моєї реалізації на Next.js, ні для TanStack Start. Робочий процес і DX також складніші за інші варіанти. Особисто я не прихильник необхідності регенерувати JS-файли перед кожним пушем, що створює постійний ризик конфліктів під час злиття для розробників через PR.
152
159
 
153
- **(Tolgee)** (`tolgee@7.0.0`):
160
+ > Примітка щодо paraglide: це рішення впорскує код у вашу кодову базу для імпорту; як наслідок, метрика 'lib size' у звіті бенчмарку становить майже 0. Генерація коду — це добре, оскільки використовувана функція включатиме лише необхідну логіку (префікс усюди проти відсутності префікса, куки проти сховища тощо). Для порівняння, Intlayer виконує це фільтрування за допомогою впорскування змінних оточення в збірку, щоб змусити бандлер виконати tree-shake контенту залежно від логіки. Завдяки цьому paraglide та intlayer врешті-решт стають у 6–10 разів легшими рішеннями, ніж i18next або next-intl.
161
+
162
+ **(Tolgee)** (`@tolgee/react@7.0.0`):
154
163
 
155
164
  `Tolgee` вирішує багато зі згаданих проблем. Проте почати роботу з ним здалося мені важче, ніж з іншими інструментами з подібними підходами. Він не забезпечує типізацію, що значно ускладнює виявлення відсутніх ключів під час компіляції. Мені довелося обертати Tolgee API своїми рішеннями, щоб додати перевірку відсутніх ключів.
156
165
 
@@ -0,0 +1,160 @@
1
+ ---
2
+ createdAt: 2026-04-20
3
+ updatedAt: 2026-04-21
4
+ title: Найкраще i18n рішення для Vue у 2026 році — Звіт про бенчмарк
5
+ description: Порівняйте бібліотеки інтернаціоналізації (i18n) для Vue, такі як vue-i18n, fluent-vue та Intlayer. Детальний звіт про продуктивність щодо розміру бандла, витоків та реактивності.
6
+ keywords:
7
+ - benchmark
8
+ - i18n
9
+ - intl
10
+ - vue
11
+ - продуктивність
12
+ - intlayer
13
+ slugs:
14
+ - doc
15
+ - benchmark
16
+ - vue
17
+ author: Aymeric PINEAU
18
+ applicationTemplate: https://github.com/intlayer-org/benchmark-i18n-vue-template
19
+ history:
20
+ - version: 8.7.12
21
+ date: 2026-01-06
22
+ changes: "Ініціалізація бенчмарку"
23
+ ---
24
+
25
+ # Бібліотеки i18n для Vue — Звіт про бенчмарк 2026
26
+
27
+ Ця сторінка є звітом про бенчмарк рішень i18n на Vue.
28
+
29
+ ## Зміст
30
+
31
+ <Toc/>
32
+
33
+ ## Інтерактивний бенчмарк
34
+
35
+ <I18nBenchmark framework="vite-vue" vertical/>
36
+
37
+ ## Посилання на результати:
38
+
39
+ <iframe
40
+ src="https://intlayer.org/markdown?url=https%3A%2F%2Fraw.githubusercontent.com%2Fintlayer-org%2Fbenchmark-i18n%2Fmain%2Freport%2Fscripts%2Fsummarize-vite_vue.md"
41
+ width="100%"
42
+ height="600px"
43
+ style="border:none;">
44
+ </iframe>
45
+
46
+ > https://intlayer.org/markdown?url=https%3A%2F%2Fraw.githubusercontent.com%2Fintlayer-org%2Fbenchmark-i18n%2Fmain%2Freport%2Fscripts%2Fsummarize-vite_vue.md
47
+
48
+ Повний репозиторій бенчмарку можна знайти [тут](https://github.com/intlayer-org/benchmark-i18n/tree/main).
49
+
50
+ ## Вступ
51
+
52
+ Рішення для інтернаціоналізації є одними з найважчих залежностей у додатку Vue. Основний ризик полягає у відправці непотрібного контенту: перекладів для інших сторінок та інших локалей у бандлі одного маршруту.
53
+
54
+ З ростом вашого додатка ця проблема може швидко збільшити обсяг JavaScript, що надсилається клієнту, і сповільнити навігацію.
55
+
56
+ На практиці, для найменш оптимізованих реалізацій, інтернаціоналізована сторінка може виявитися в кілька разів важчою, ніж версія без i18n.
57
+
58
+ Інший вплив стосується досвіду розробника (DX): як ви оголошуєте контент, типи, організацію просторів імен, динамічне завантаження та реактивність при зміні локалі.
59
+
60
+ ## TL;DR
61
+
62
+ - **Intlayer**: Найлегше рішення (v8.7.12) з нативним скоупінгом (scoping) та динамічним завантаженням.
63
+ - **vue-i18n**: Галузевий стандарт з багатою екосистемою, але може стати значно важчим і важчим для оптимізації під code-splitting у великих додатках.
64
+ - **fluent-vue**: Інноваційна організація повідомлень, але не вистачає безпеки типів (type-safety) і виявляється надзвичайно важким рішенням.
65
+
66
+ ## Протестуйте свій додаток
67
+
68
+ Щоб швидко виявити проблеми з витоком i18n, я налаштував безкоштовний сканер, доступний [тут](https://intlayer.org/i18n-seo-scanner).
69
+
70
+ <iframe src="https://intlayer.org/i18n-seo-scanner" width="100%" height="600px" style="border:none;"/>
71
+
72
+ ## Проблема
73
+
74
+ Два важелі є важливими для обмеження вартості багатомовного додатка:
75
+
76
+ - Розділіть контент за сторінками / просторами імен, щоб не завантажувати цілі словники, коли вони не потрібні.
77
+ - Завантажуйте потрібну локаль динамічно, тільки коли це необхідно.
78
+
79
+ Розуміння технічних обмежень цих підходів:
80
+
81
+ **Динамічне завантаження**
82
+
83
+ Без динамічного завантаження більшість рішень зберігають повідомлення в пам'яті з першого рендеру, що додає значне навантаження для додатків з багатьма маршрутами та локалями.
84
+
85
+ З динамічним завантаженням ви приймаєте компроміс: менше початкового JS, але іноді додатковий запит при зміні мови.
86
+
87
+ **Поділ контенту (Splitting)**
88
+
89
+ Синтаксис, побудований навколо `const { t } = useI18n()` + `t('a.b.c')`, дуже зручний, але часто заохочує зберігати великі JSON-об'єкти під час виконання. Ця модель ускладнює tree-shaking, якщо бібліотека не пропонує реальної стратегії поділу на сторінки.
90
+
91
+ ## Методологія дослідження
92
+
93
+ Для цього бенчмарку ми порівняли наступні бібліотеки:
94
+
95
+ - `Base App` (Без бібліотеки i18n)
96
+ - `vue-intlayer` (v8.7.12)
97
+ - `vue-i18n` (v11.4.0)
98
+ - `fluent-vue` (v3.8.2)
99
+
100
+ Фреймворк — `Vue` з багатомовним додатком із **10 сторінок** і **10 мов**.
101
+
102
+ Ми порівняли **чотири стратегії завантаження**:
103
+
104
+ | Стратегія | Без просторів імен (глобально) | З просторами імен (scoped) |
105
+ | :------------------------- | :------------------------------------------------------ | :---------------------------------------------------------------------------- |
106
+ | **Статичне завантаження** | **Static**: Все в пам'яті при запуску. | **Scoped static**: Розділено за просторами імен; все завантажено при запуску. |
107
+ | **Динамічне завантаження** | **Dynamic**: Завантаження за запитом для кожної локалі. | **Scoped dynamic**: Детальне завантаження за простором імен та локаллю. |
108
+
109
+ ## Підсумок стратегій
110
+
111
+ - **Static**: Просто; немає затримки мережі після початкового завантаження. Мінус: великий розмір бандла.
112
+ - **Dynamic**: Зменшує початкову вагу (lazy-loading). Ідеально, коли у вас багато локалей.
113
+ - **Scoped static**: Зберігає код організованим (логічне розділення) без складних додаткових мережевих запитів.
114
+ - **Scoped dynamic**: Найкращий підхід для _code splitting_ та продуктивності. Мінімізує пам'ять, завантажуючи лише те, що потрібно поточному перегляду та активній локалі.
115
+
116
+ ### Що я вимірював:
117
+
118
+ Я запустив той самий багатомовний додаток у реальному браузері для кожного стека, а потім записав, що насправді пройшло мережею і скільки часу це зайняло. Розміри вказані **після звичайного веб-стиснення**, оскільки це ближче до того, що люди насправді завантажують, ніж необроблена кількість рядків вихідного коду.
119
+
120
+ - **Розмір бібліотеки інтернаціоналізації**: Після бандлінгу, tree-shaking та мініфікації розмір бібліотеки i18n — це розмір коду провайдерів + composables у порожньому компоненті. Він не включає завантаження файлів перекладу. Це відповідає на питання, наскільки "дорогою" є бібліотека до того, як ваш контент з'явиться в кадрі.
121
+
122
+ - **JavaScript на сторінку**: Для кожного маршруту бенчмарку, скільки скриптів завантажує браузер для цього відвідування, усереднено за сторінками в наборі (і за локалями). Важкі сторінки — це повільні сторінки.
123
+
124
+ - **Витік з інших локалей (Leakage)**: Це контент тієї ж сторінки, але іншою мовою, який помилково завантажується на сторінці, що перевіряється. Цей контент є непотрібним і його слід уникати (наприклад: контент сторінки `/fr/about` у бандлі сторінки `/en/about`).
125
+
126
+ - **Витік з інших маршрутів**: Та ж ідея для **інших екранів** у додатку: чи додається їхній текст, коли ви відкрили лише одну сторінку (наприклад: контент сторінки `/en/about` у бандлі сторінки `/en/contact`). Високий бал вказує на слабкий поділ або занадто широкі бандли.
127
+
128
+ - **Середній розмір бандла компонента**: Загальні елементи інтерфейсу вимірюються **по одному**, замість того щоб ховатися всередині одного гігантського числа додатка. Це показує, чи інтернаціоналізація непомітно роздуває повсякденні компоненти. Наприклад, якщо ваш компонент перерендерюється, він завантажуватиме всі ці дані з пам'яті. Прикріплення гігантського JSON до будь-якого компонента — це як підключення великого сховища невикористовуваних даних, що сповільнить продуктивність ваших компонентів.
129
+
130
+ - **Швидкість реакції на зміну мови**: Я змінюю мову за допомогою власного контролера додатка і вимірюю час, поки сторінка чітко не зміниться — те, що помітить відвідувач.
131
+
132
+ - **Робота рендерингу після зміни мови**: Більш точне спостереження: скільки зусиль доклав інтерфейс для перемальовування для нової мови після початку зміни. Корисно, коли "відчутний" час і витрати фреймворку розходяться.
133
+
134
+ - **Час початкового завантаження сторінки**: Від навігації до моменту, коли браузер вважає сторінку повністю завантаженою для сценаріїв, які я тестував. Добре для порівняння холодних стартів.
135
+
136
+ - **Час гідратації (Hydration)**: Час, який клієнт витрачає на перетворення серверного HTML на інтерактивний інтерфейс. Тире в таблицях означає, що ця реалізація не надала надійного показника гідратації в цьому бенчмарку.
137
+
138
+ ## Результати детально
139
+
140
+ ### 1 — Рішення, яких слід уникати
141
+
142
+ > В екосистемі Vue немає очевидних рішень, яких слід уникати.
143
+
144
+ ### 2 — Прийнятні рішення
145
+
146
+ **(vue-i18n)** (`vue-i18n@11.4.0`):
147
+
148
+ - **vue-i18n** безперечно є найбільш використовуваною бібліотекою i18n для Vue, вона має багато функцій і величезну екосистему. Але "під капотом" рішення досить важке. Навіть якщо vue-i18n інтегрує lazy loading для повідомлень, у ній відсутня функція скоупінгу (scoping). У випадку класичного Vue SPA додатка проблем немає, але для nuxt додатка, що використовує @nuxt/i18n, це призводить до включення повідомлень з усіх сторінок в одну. Для великого nuxt додатка з понад 10 сторінками це може стати справді проблематичним.
149
+
150
+ Пакет дуже важкий (~24.3kb, що приблизно в 9 разів більше за `vue-intlayer`).
151
+
152
+ **(fluent-vue)** (`fluent-vue@0.5.0`):
153
+
154
+ - **fluent-vue** пропонує спробу інновації через формат .ftl. Організація повідомлень чудова, легше почати роботу. Але на практиці відсутність безпеки типів підвищує ризик помилок і налагодження може швидко стати трудомістким. Більше того, це рішення завантажує повідомлення за допомогою плагіна vite, який змушує завантажувати весь контент усіма мовами на кожну сторінку. Крім того, це надзвичайно важке рішення (~92.7kb, що приблизно в 34 рази більше за `vue-intlayer`).
155
+
156
+ ### 3 — Рекомендації
157
+
158
+ **(Intlayer)** (`vue-intlayer@8.7.12`):
159
+
160
+ Я не буду особисто оцінювати `vue-intlayer` заради об'єктивності, оскільки це моє власне рішення.
@@ -1,6 +1,6 @@
1
1
  ---
2
2
  createdAt: 2024-08-13
3
- updatedAt: 2026-04-03
3
+ updatedAt: 2026-05-12
4
4
  title: Конфігурація
5
5
  description: Дізнайтеся, як налаштувати Intlayer для вашого додатка. Зрозумійте різні налаштування та параметри, доступні для адаптації Intlayer під ваші потреби.
6
6
  keywords:
@@ -14,6 +14,9 @@ slugs:
14
14
  - concept
15
15
  - configuration
16
16
  history:
17
+ - version: 8.9.4
18
+ date: 2026-05-12
19
+ changes: "Додано підтримку провайдера LM Studio"
17
20
  - version: 8.7.0
18
21
  date: 2026-04-07
19
22
  changes: "Додано параметри `minify` та `prune` до конфігурації збірки"
@@ -350,7 +353,7 @@ const config: IntlayerConfig = {
350
353
  ai: {
351
354
  /**
352
355
  * Використовуваний провайдер AI.
353
- * Варіанти: 'openai', 'anthropic', 'mistral', 'deepseek', 'gemini', 'ollama', 'openrouter', 'alibaba', 'fireworks', 'groq', 'huggingface', 'bedrock', 'googlevertex', 'togetherai'
356
+ * Варіанти: 'openai', 'anthropic', 'mistral', 'deepseek', 'gemini', 'ollama', 'openrouter', 'alibaba', 'fireworks', 'groq', 'huggingface', 'bedrock', 'googlevertex', 'togetherai', 'lmstudio'
354
357
  * За замовчуванням: 'openai'
355
358
  */
356
359
  provider: "openai",
@@ -916,16 +919,17 @@ Intlayer підтримує широкий спектр провайдерів A
916
919
  - **Groq**
917
920
  - **Amazon Bedrock**
918
921
  - **Together.ai**
919
-
920
- | Поле | Опис | Тип | За замовчуванням | Приклад | Примітки |
921
- | -------------------- | --------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------- | ------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
922
- | `provider` | Провайдер, який використовуватиметься для функцій AI в Intlayer. | `'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-ключів та мають різні ціни. |
923
- | `model` | Модель AI, яка використовуватиметься для функцій AI. | `string` | Немає | `'gpt-4o-2024-11-20'` | Конкретні моделі залежать від провайдера. |
924
- | `temperature` | Контролює випадковість відповідей AI. | `number` | Немає | `0.1` | Вища температура = креативніші та менш надійні відповіді. |
925
- | `apiKey` | Ваш API-ключ для вибраного провайдера. | `string` | Немає | `process.env.OPENAI_API_KEY` | Повинно зберігатися в секреті; використовуйте змінні середовища. |
926
- | `applicationContext` | Додатковий контекст про ваш додаток, щоб допомогти AI генерувати точніші переклади (домен, цільова аудиторія, тон, термінологія). | `string` | Немає | `'мій власний контекст додатка'` | Може використовуватися для додавання правил (наприклад: `"Ви не повинні перекладати свої URL"` ). |
927
- | `baseURL` | Базовий URL для AI API. | `string` | Немає | `'https://api.openai.com/v1'` <br/> `'http://localhost:5000'` | Може вказувати на локальні або власні кінцеві точки AI API. |
928
- | `dataSerialization` | Формат серіалізації даних для функцій AI. | `'json'` &#124; <br/> `'toon'` | `undefined` | `'toon'` | `'json'`: за замовчуванням, надійний; використовує більше токенів.<br/>• `'toon'`: менше токенів, менш стабільно.<br/>• Передає моделі контекст як додатковий параметр (reasoning effort тощо). |
922
+ - **LM Studio**
923
+
924
+ | Поле | Опис | Тип | За замовчуванням | Приклад | Примітки |
925
+ | -------------------- | --------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------------- | ------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
926
+ | `provider` | Провайдер, який використовуватиметься для функцій AI в Intlayer. | `'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-ключів та мають різні ціни. |
927
+ | `model` | Модель AI, яка використовуватиметься для функцій AI. | `string` | Немає | `'gpt-4o-2024-11-20'` | Конкретні моделі залежать від провайдера. |
928
+ | `temperature` | Контролює випадковість відповідей AI. | `number` | Немає | `0.1` | Вища температура = креативніші та менш надійні відповіді. |
929
+ | `apiKey` | Ваш API-ключ для вибраного провайдера. | `string` | Немає | `process.env.OPENAI_API_KEY` | Повинно зберігатися в секреті; використовуйте змінні середовища. |
930
+ | `applicationContext` | Додатковий контекст про ваш додаток, щоб допомогти AI генерувати точніші переклади (домен, цільова аудиторія, тон, термінологія). | `string` | Немає | `'мій власний контекст додатка'` | Може використовуватися для додавання правил (наприклад: `"Ви не повинні перекладати свої URL"` ). |
931
+ | `baseURL` | Базовий URL для AI API. | `string` | Немає | `'https://api.openai.com/v1'` <br/> `'http://localhost:5000'` | Може вказувати на локальні або власні кінцеві точки AI API. |
932
+ | `dataSerialization` | Формат серіалізації даних для функцій AI. | `'json'` &#124; <br/> `'toon'` | `undefined` | `'toon'` | • `'json'`: за замовчуванням, надійний; використовує більше токенів.<br/>• `'toon'`: менше токенів, менш стабільно.<br/>• Передає моделі контекст як додатковий параметр (reasoning effort тощо). |
929
933
 
930
934
  ---
931
935