@intlayer/docs 9.0.0-canary.3 → 9.0.0-canary.5

package/docs/tr/releases/v7.md

@@ -25,6 +25,10 @@ author: aymericzip
 
 Intlayer v7'ye hoş geldiniz! Bu büyük sürüm, performans, tür güvenliği ve geliştirici deneyiminde önemli iyileştirmeler sunuyor. Aşağıda, geçiş notları ve pratik örneklerle birlikte öne çıkanlar yer almaktadır.
 
+## İçindekiler
+
+<TOC levels={[2]} maxDepth={1} />
+
 ## Öne Çıkanlar
 
 - Daha hızlı derlemeler için önbellekleme stratejisi
@@ -260,6 +264,126 @@ Bu, uygulamanız için daha hızlı indirme süreleri ve geliştirilmiş çalı
 
 ---
 
+## Otomatik Kod Biçimlendirmesi: formatCommand configuration
+
+v7, editör yapılandırmasında `formatCommand` seçeneğini tanıtarak, Intlayer tarafından yazıldığında içerik dosyalarını otomatik olarak biçimlendirmenizi sağlar. Bu, içerik bildirimi dosyalarınız arasında tutarlı kod stili ve biçimlendirmesini sağlar.
+
+Ayarlanmadığında, Intlayer biçim komutunu otomatik olarak algılamaya çalışacaktır. Şu komutları çözmeyi deneyerek: prettier, biome, eslint.
+
+### Konfigürasyon
+
+`formatCommand` seçeneği, `{{file}}` ifadesinin gerçek dosya yolu ile değiştirildiği bir string şablonunu kabul eder:
+
+```typescript fileName="intlayer.config.ts"
+export default {
+  content: {
+    formatCommand: 'bun x biome format "{{file}}" --write --log-level none',
+  },
+};
+```
+
+### Desteklenen formatters
+
+Dosya yollarını argüman olarak kabul eden herhangi bir kod formatteri kullanabilirsiniz:
+
+**Biome kullanarak:**
+
+```typescript
+formatCommand: 'bun x biome format "{{file}}" --write --log-level none';
+```
+
+**Prettier kullanarak:**
+
+```typescript
+formatCommand: 'npx prettier --write "{{file}}" --log-level silent';
+```
+
+**ESLint kullanarak:**
+
+```typescript
+formatCommand: 'npx eslint --fix "{{file}}" --quiet';
+```
+
+**Bun'ın yerleşik formatteri kullanarak:**
+
+```typescript
+formatCommand: 'bun format "{{file}}"';
+```
+
+### Faydalar
+
+- **Tutarlı biçimlendirme**: Tüm içerik dosyaları, projenizin stil yönergelerine göre otomatik olarak biçimlendirilir
+- **Geliştirici deneyimi**: Intlayer dosyaları yazdıktan sonra dosyaları manuel olarak biçimlendirmeye gerek yoktur
+- **Takım tutarlılığı**: Tüm takım üyelerinin içerik dosyalarına aynı biçimlendirmenin uygulanmasını sağlar
+- **CI/CD entegrasyonu**: İçerik dosyaları, otomatik iş akışlarında tutarlı biçimlendirmeyi korur
+
+### Nasıl çalışır
+
+Intlayer bir içerik bildirimi dosyasını (`.content.ts`, `.content.js`, vb.) yazdığında veya güncellediğinde, dosya üzerinde belirtilen format komutunu otomatik olarak çalıştırır. `{{file}}` yer tutucu gerçek dosya yolu ile değiştirilir ve komut projenin temel dizininde yürütülür.
+
+---
+
+## Sözlük Yapılandırması: Daha İyi Organizasyon ve Yapı
+
+v7, sözlük ile ilgili ayarlar için daha iyi bir organizasyon ve geliştirilmiş içerik yönetimi sağlayan yeni bir adanmış `dictionary` yapılandırma bölümü sunar.
+
+### Yeni dictionary yapılandırması
+
+`fill` özelliği, `content` bölümünden yeni `dictionary` bölümüne taşınmış, sorumlulukların daha net bir şekilde ayrılmasını sağlamıştır:
+
+**v6 yapılandırması:**
+
+```typescript fileName="intlayer.config.ts"
+export default {
+  content: {
+    autoFill: "./{{fileName}}.content.json",
+    contentDir: ["src"],
+  },
+};
+```
+
+**v7 yapılandırması:**
+
+```typescript fileName="intlayer.config.ts"
+export default {
+  content: {
+    contentDir: ["src"],
+  },
+  dictionary: {
+    fill: "./{{fileName}}.content.json",
+  },
+};
+```
+
+### Yeni yapının faydaları
+
+- **Daha net organizasyon**: Sözlüğe özgü ayarlar artık bir arada gruplandırılıyor
+- **Daha iyi sorunların ayrılması**: İçerik keşfi vs. sözlük işlemleri açıkça ayrılıyor
+- **Geliştirilmiş bakım kolaylığı**: Sözlükle ilgili konfigürasyonları anlamak ve değiştirmek daha kolay
+- **Gelecekteki genişletilebilirlik**: Sözlük bölümü ek sözlüğe özgü ayarları barındırabiliyor
+- **Kapsamlı sözlük yönetimi**: Yeni sözlükler oluşturmak ve yönetmek için `title`, `live`, `priority`, `tags`, `version` ve `description` gibi özellikleri içeriyor
+
+### Yapılandırma kullanımı
+
+Sözlük yapılandırması iki ana amaca hizmet eder:
+
+1. **Varsayılan Değerler**: İçerik bildirim dosyaları oluştururken varsayılan değerleri tanımlama
+2. **Fallback Davranışı**: Belirli alanlar tanımlanmadığında fallback değerleri sağlama, sözlük işlem davranışını global olarak tanımlamanıza izin verme
+
+Sözlük bölümü, sözlük yönetimi için kapsamlı özellikler içerir:
+
+- **`fill`**: İçerik oluşturma için otomatik doldurma davranışı
+- **`title`**: Yeni sözlükler için varsayılan başlık
+- **`live`**: Gerçek zamanlı güncellemeler için live senkronizasyon yapılandırması
+- **`priority`**: Sözlük çözümlemesi için öncelik ayarları
+- **`tags`**: İçerik organizasyonu için varsayılan etiketler
+- **`version`**: Sözlük güncellemeleri için sürüm yönetimi
+- **`description`**: Yeni içerik için varsayılan açıklama
+
+İçerik bildirim dosyaları ve yapılandırma değerlerinin nasıl uygulandığı hakkında daha fazla bilgi için bkz. [İçerik Dosyası Belgeleri](https://github.com/aymericzip/intlayer/blob/main/docs/docs/tr/dictionary/content_file.md).
+
+---
+
 ## Fill komutu: Daha iyi içerik yönetimi için güncellenmiş davranış
 
 v7, `fill` komutu için daha öngörülebilir ve esnek içerik yönetimi sağlayan geliştirilmiş bir davranış sunar:
@@ -407,6 +531,10 @@ Sistem otomatik olarak:
 - **`middleware.prefixDefault`**: `routing.mode` ile değiştirildi
 - **`middleware.noPrefix`**: `routing.mode` ile değiştirildi
 
+### Yeni konfigürasyonlar
+
+- **`editor.formatCommand`**: İçerik dosyalarının otomatik kod formatlaması için yeni seçenek
+
 ### Geçiş eşlemesi
 
 #### Konfigürasyon eşlemesi

package/docs/tr/releases/v9.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2026-06-14
-updatedAt: 2026-06-14
+updatedAt: 2026-06-23
 title: Yeni Intlayer v9 - Yenilikler Neler?
 description: Intlayer v9'daki yenilikleri keşfedin. Popüler i18n kütüphaneleri için doğrudan uyumlu paketler ve Koleksiyonlar, Varyantlar ve Dinamik Kayıtlar desteği sunuluyor.
 keywords:
@@ -216,6 +216,42 @@ Derleme zamanında, `@intlayer/swc` ve `@intlayer/babel` dosyalarınızı tarar
 
 ---
 
+## Vite Plugin: Bundled Compiler & Proxy
+
+`intlayer()` Vite eklentisi artık **compiler** ve **locale-routing proxy**'i doğrudan içeriyor, bu nedenle çoğu proje `vite.config.ts` içinde yalnızca tek bir eklentiye ihtiyaç duyuyor:
+
+```ts fileName="vite.config.ts"
+import { defineConfig } from "vite";
+import { intlayer } from "vite-intlayer";
+
+export default defineConfig({
+  plugins: [intlayer()],
+});
+```
+
+- **Compiler**: `compiler.enabled` ayarlandığında ve `compiler.output` yolu yapılandırıldığında otomatik olarak etkinleştirilir. Artık `intlayerCompiler()`'ı ayrı olarak kaydetmeniz gerekmez.
+- **Proxy**: Yeni `routing.enableProxy` seçeneğine göre otomatik olarak etkinleştirilir (varsayılan olarak `true`). Geliştirme, önizleme ve üretim SSR'de locale algılama / yönlendirme / yeniden yazma middleware'ini bağlar. Artık `intlayerProxy()`'ı ayrı olarak kaydetmeniz gerekmez.
+
+### `routing.enableProxy` seçeneği
+
+Yeni `routing.enableProxy` seçeneği, locale-routing proxy'sinin bağlanıp bağlanmadığını kontrol eder. Varsayılan değer `true`'dur. Locale yönlendirmesini kendiniz işlemek istediğinizde devre dışı bırakın:
+
+```ts fileName="intlayer.config.ts"
+import type { IntlayerConfig } from "intlayer";
+
+const config: IntlayerConfig = {
+  routing: {
+    enableProxy: false, // Varsayılan: true
+  },
+};
+
+export default config;
+```
+
+Bağımsız `intlayerCompiler()` ve `intlayerProxy()` eklentileri gelişmiş kurulumlar için dışa aktarılmaya devam eder. Bunları `intlayer()` ile birlikte kaydetmek güvenlidir — her eklenti kendisini çoğaltır ve yalnızca bir kez çalışır.
+
+---
+
 ## v8'den Geçiş Notları
 
 v8'den yükseltme yapıyorsanız, v9'un yıkıcı değişiklikler (breaking changes) içermediğini unutmayın. Ancak işte temel değişiklikler:

package/docs/tr/roadmap.md

@@ -32,6 +32,12 @@ Intlayer, uygulamalarınızda içeriği bildirme, yönetme ve güncelleme şekli
 
 ---
 
+## İçindekiler
+
+<TOC/>
+
+---
+
 ## Mevcut Özellikler
 
 ### 1. İçerik Bildirimi

package/docs/uk/benchmark/solid.md

@@ -118,6 +118,28 @@ style="border:none;"
 - **Scoped static**: Зберігає код організованим (логічне розділення) без складних додаткових мережевих запитів.
 - **Scoped dynamic**: Найкращий підхід для _code splitting_ та продуктивності. Мінімізує пам'ять, завантажуючи лише те, що потрібно поточному перегляду та активній локалі.
 
+### Що я вимірював:
+
+Я запустив одну й ту саму багатомовну програму в реальному браузері для кожного стеку, а потім записав, що насправді з'явилося на мережі та як довго тривав процес. Розміри наводяться **після звичайного стиснення веб-вмісту**, оскільки це ближче до того, що люди завантажують, ніж необроблене джерельне числення.
+
+- **Розмір бібліотеки інтернаціоналізації**: Після bundling, tree-shaking та мініфікації, розмір бібліотеки i18n — це розмір providers + hooks/primitives кода в порожній компоненті. Він не включає завантаження файлів перекладу. Це відповідає на питання про вартість бібліотеки до того, як ваш вміст потрапить у картину.
+
+- **JavaScript на сторінку**: Для кожного маршруту бенчмарку — скільки скрипту браузер витягує для цього відвідування, усереднено по сторінках у наборі (та по мовах, де звіт їх об'єднує). Важкі сторінки — повільні сторінки.
+
+- **Утечка з інших мов**: Це вміст однієї й тієї ж сторінки, але іншою мовою, який по помилці був би завантажений у проаудитовану сторінку. Цей вміст непотрібний і його слід уникати. (напр. вміст сторінки `/fr/about` в bundle сторінки `/en/about`)
+
+- **Утечка з інших маршрутів**: Та сама ідея для **інших екранів** у додатку: чи їхний вміст їде разом, коли ви відкрили лише одну сторінку. (напр. вміст сторінки `/en/about` в bundle сторінки `/en/contact`). Висока оцінка вказує на слабке розділення або занадто широкі bundle.
+
+- **Середній розмір bundle компоненти**: Звичайні елементи інтерфейсу вимірюються **один за одним** замість того, щоб приховуватися всередину одного гігантського числа програми. Це показує, чи інтернаціоналізація тихо збільшує повсякденні компоненти. Наприклад, якщо ваша компонента повторно рендерується, вона завантажить всі ці дані з пам'яті. Прикріплення гігантської JSON до будь-якої компоненти — це як підключення великого сховища невикористаних даних, що сповільнить роботу ваших компонент.
+
+- **Адаптивність перемикання мови**: Я перемикаю мову за допомогою контролю програми й розраховую, як довго це займає, поки сторінка явно не переключиться, що помітить відвідувач, а не мікрокрок у лабораторії.
+
+- **Робота рендерингу після зміни мови**: Вужчий наступний крок: скільки зусиль знадобилося інтерфейсу для перепалітури на нову мову, коли перемикання в польоті. Корисно, коли «відчутний» час і вартість фреймворку розходяться.
+
+- **Час завантаження початкової сторінки**: Від навігації до браузера, який вважає сторінку повністю завантаженою для сценаріїв, які я тестував. Добре для порівняння холодних запусків.
+
+- **Час гідратації**: Коли програма це виявляє, скільки часу клієнт витрачає на перетворення серверної HTML у щось, на що ви можете насправді клікнути. Тире в таблицях означає, що ця реалізація не надала надійної цифри гідратації в цьому бенчмарку.
+
 ## Зірки на GitHub
 
 Зірки на GitHub є потужним індикатором популярності проекту, довіри спільноти та довгострокової актуальності. Хоча вони не є прямим показником технічної якості, вони відображають, скільки розробників вважають проект корисним, стежать за його розвитком і, ймовірно, впровадять його. Для оцінки цінності проекту зірки допомагають порівняти інтерес до альтернатив і дають уявлення про зростання екосистеми.

package/docs/uk/benchmark/svelte.md

@@ -116,6 +116,28 @@ style="border:none;"
 - **Scoped static**: Зберігає код організованим (логічне розділення) без складних додаткових мережевих запитів.
 - **Scoped dynamic**: Найкращий підхід для _code splitting_ та продуктивності. Мінімізує пам'ять, завантажуючи лише те, що потрібно поточному перегляду та активній локалі.
 
+### Що я вимірював:
+
+Я запустив одну й ту ж багатомовну програму в реальному браузері для кожного стеку, а потім записав, що насправді з'явилося в мережі та скільки часу це зайняло. Розміри вказані **після звичайного веб-стиснення**, оскільки це ближче до того, що люди завантажують, ніж підрахунок сирового вихідного коду.
+
+- **Размер бібліотеки internationalization**: Після зв'язування, tree-shaking та мініфікації розмір бібліотеки i18n — це розмір коду провайдерів + stores в порожньому компоненті. Це не включає завантаження файлів перекладу. Це відповідає на питання, наскільки дорога бібліотека перед тим, як ваш вміст входить у гру.
+
+- **JavaScript на сторінку**: Для кожного маршруту бенчмарку — скільки скрипту браузер завантажує під час цього відвідування, усередненого на сторінках в наборі (та на локалях, де звіт їх об'єднує). Важкі сторінки — це повільні сторінки.
+
+- **Витік з інших локалей**: Це вміст однієї й тієї ж сторінки, але іншою мовою, який помилково завантажився б на перевіреній сторінці. Цей вміст непотрібний і його слід уникати. (наприклад, вміст сторінки `/fr/about` в комплекті `/en/about`)
+
+- **Витік з інших маршрутів**: Та ж ідея для **інших екранів** у програмі: чи їхній копія їде разом, коли ви відкрили лише одну сторінку. (наприклад, вміст сторінки `/en/about` в комплекті `/en/contact`). Високий показник вказує на слабкий розподіл або занадто широкі комплекти.
+
+- **Середній розмір комплекту компонентів**: Звичайні елементи інтерфейсу вимірюються **по одному** замість того, щоб ховатися всередині одного гігантського числа програми. Це показує, чи internationalization мовчки збільшує повсякденні компоненти. Наприклад, якщо ваш компонент перерендерується, він завантажить усі ці дані з пам'яті. Приєднання гігантського JSON до будь-якого компонента схоже на підключення великого сховища невикористаних даних, що сповільнить продуктивність ваших компонентів.
+
+- **Чутливість перемикача мови**: Я перемикаю мову за допомогою власного контролю програми та вимірюю, скільки часу займає, поки сторінка явно не переключиться, що помітить відвідувач, а не лабораторний мікро-крок.
+
+- **Робота рендерингу після зміни мови**: Вузький подальший крок: скільки зусиль знадобилося інтерфейсу, щоб перефарбуватися на нову мову після того, як перемикання розпочало свіжість. Корисно, коли «відчутний» час та вартість фреймворку розходяться.
+
+- **Час завантаження початкової сторінки**: Від навігації до браузера, що розглядає сторінку як повністю завантажену для сценаріїв, які я тестував. Добре для порівняння холодних стартів.
+
+- **Час гідрації**: Коли програма це розкриває, скільки часу клієнт витрачає на перетворення серверного HTML на щось, на що ви можете насправді натиснути. Тире в таблицях означає, що реалізація не надала надійного показника гідрації в цьому бенчмарку.
+
 ## Зірки на GitHub
 
 Зірки на GitHub є потужним індикатором популярності проекту, довіри спільноти та довгострокової актуальності. Хоча вони не є прямим показником технічної якості, вони відображають, скільки розробників вважають проект корисним, стежать за його розвитком і, ймовірно, впровадять його. Для оцінки цінності проекту зірки допомагають порівняти інтерес до альтернатив і дають уявлення про зростання екосистеми.

package/docs/uk/benchmark/tanstack.md

@@ -124,6 +124,28 @@ history:
 - **Scoped static**: Зберігає код структурованим (логічний поділ) без складних мережевих запитів.
 - **Scoped dynamic**: Найкращий підхід для _розділення коду_ (code splitting) та продуктивності. Мінімізує обсяг пам'яті, завантажуючи лише те, що потрібно поточному перегляду та активній локалі.
 
+### Що я вимірював:
+
+Я запустив одну й ту саму багатомовну програму в реальному браузері для кожного стеку, а потім записав, що насправді показувалося в мережі та скільки часу це займало. Розміри повідомляються **після звичайного стиснення в мережі**, оскільки це ближче до того, що люди завантажують, ніж до підрахунків сирцевого коду.
+
+- **Розмір бібліотеки інтернаціоналізації**: Після bundling, tree-shaking та мініфікації розмір бібліотеки i18n — це розмір постачальників (наприклад, `NextIntlClientProvider`) + код хуків (наприклад, `useTranslations`) в пустому компоненті. Він не включає завантаження файлів перекладу. Це показує, наскільки дорога бібліотека перш ніж ваш контент потрапить в картину.
+
+- **JavaScript на сторінку**: Для кожного маршруту бенчмарку, скільки скрипту браузер завантажує під час цього відвідування, усереднено по сторінках в наборі (і по локалям, де звіт їх об'єднує). Важкі сторінки — повільні сторінки.
+
+- **Витік з інших локалей**: Це контент однієї й тієї ж сторінки, але іншою мовою, який був би випадково завантажений у перевіреній сторінці. Цей контент не потрібний і його слід уникати. (наприклад, контент сторінки `/fr/about` у пакеті сторінки `/en/about`)
+
+- **Витік з інших маршрутів**: Та сама ідея для **інших екранів** у програмі: чи їхній копія йде разом, коли ви відкрили лише одну сторінку. (наприклад, контент сторінки `/en/about` у пакеті сторінки `/en/contact`). Високий бал натякає на слабке розділення або надто широкі пакети.
+
+- **Середній розмір пакету компонента**: Загальні частини користувацького інтерфейсу вимірюються **один за одним** замість того, щоб приховуватися всередину одного гігантського номера програми. Це показує, чи інтернаціоналізація тихо збільшує звичайні компоненти. Наприклад, якщо ваш компонент перерендерується, він завантажить всі ці дані з пам'яті. Приєднання великого JSON до будь-якого компонента подібно до підключення великого сховища непотрібних даних, що уповільнить продуктивність ваших компонентів.
+
+- **Чутливість перемикання мови**: Я змінюю мову за допомогою власного елемента керування програми та вимірюю, скільки часу пройде, поки сторінка явно не переключиться, що помітив би відвідувач, а не лабораторна мікрокроку.
+
+- **Робота з рендерингом після зміни мови**: Вужча подальша діяльність: скільки зусиль потребував інтерфейс, щоб перемалювати для нової мови, коли перемикання йде. Корисно, коли «відчутний» час та вартість фреймворку розходяться.
+
+- **Час завантаження початкової сторінки**: Від навігації до браузера, враховуючи, що сторінка повністю завантажена для сценаріїв, які я тестував. Добре для порівняння холодних запусків.
+
+- **Час гідратації**: Коли програма це розкриває, скільки часу клієнт витрачає на перетворення серверної HTML на те, що можна насправді клацнути. Тире в таблицях означає, що реалізація не надала надійної цифри гідратації у цьому бенчмарку.
+
 ## Зірки на GitHub
 
 Зірки на GitHub є потужним індикатором популярності проекту, довіри спільноти та довгострокової актуальності. Хоча вони не є прямим показником технічної якості, вони відображають, скільки розробників вважають проект корисним, стежать за його розвитком і, ймовірно, впровадять його. Для оцінки цінності проекту зірки допомагають порівняти інтерес до альтернатив і дають уявлення про зростання екосистеми.

package/docs/uk/cli/ci.md

@@ -140,6 +140,28 @@ steps:
     run: npx intlayer ci fill
 ```
 
+## Scaffolded GitHub Actions
+
+Коли ви запустите `intlayer init`, Intlayer виявляє ваш package manager (npm, yarn, pnpm або bun) і створює два GitHub Actions workflows у `.github/workflows/` з командами, які відповідають цьому package manager:
+
+- **`intlayer-fill.yml`** — На кожен pull request будує словники і запускає `intlayer fill --git-diff --mode complete` для генерування відсутніх перекладів для змінених словників, потім фіксує результат назад у гілку PR.
+- **`intlayer-test.yml`** — На кожен pull request будує словники і запускає `intlayer test`, завершуючи перевірку з помилкою, коли обов'язкові мови не мають перекладів.
+
+Існуючі файли workflows ніколи не перезаписуються. Щоб пропустити scaffolding повністю, запустіть:
+
+```bash
+npx intlayer init --no-github-actions
+```
+
+### Надання доступу до ШІ для робочого процесу заповнення
+
+Сгенерований `intlayer-fill.yml` вимагає доступу до ШІ. Доступні два варіанти (налаштовуються в блоці `env` робочого процесу):
+
+1. **Ваш власний ключ AI-провайдера** — Додайте секрет `AI_API_KEY` в налаштуваннях вашого репозиторію (Settings → Secrets and variables → Actions). Робочий процес передає його через `--provider`, `--model` та `--api-key`.
+2. **Ключі доступу до Intlayer CMS** — Додайте секрети `INTLAYER_CLIENT_ID` та `INTLAYER_CLIENT_SECRET` і підключіть їх до секції `editor` вашого `intlayer.config`. Ключі доступу до CMS надають доступ до ШІ через backend Intlayer.
+
+Робочий процес `intlayer-test.yml` не вимагає жодного доступу до ШІ.
+
 ## Обробка помилок
 
 - Якщо `INTLAYER_PROJECT_CREDENTIALS` не встановлено, команда завершиться з помилкою.

package/docs/uk/cli/fill.md

@@ -47,6 +47,14 @@ bun x intlayer fill
 - Зберігає існуючі переклади, не перезаписуючи їх.
 - Обробляє файли, частини та локалі паралельно, використовуючи систему черг для збільшення швидкості.
 
+## Ключові моменти:
+
+- Розбиває великі JSON файли на частини, щоб залишатися в межах контекстного вікна AI моделі.
+- Повторює переклад, якщо формат результату невірний.
+- Incorporates application and file-specific context for improved translation accuracy.
+- Зберігає існуючі переклади, не перезаписуючи їх.
+- Обробляє файли, частини та локалі паралельно, використовуючи систему черг для прискорення.
+
 ## Аліаси:
 
 - `npx intlayer dictionaries fill`

package/docs/uk/compat/i18n-js.md

@@ -0,0 +1,44 @@
+---
+createdAt: 2026-06-13
+updatedAt: 2026-06-13
+title: "Міграція з i18n-js на Intlayer"
+description: "Дізнайтеся, як перенести вашу програму з i18n-js на Intlayer за допомогою адаптера сумісності."
+keywords:
+  - i18n-js
+  - intlayer
+  - migration
+  - compat
+slugs:
+  - doc
+  - compatibility
+  - i18n-js
+history:
+  - version: 9.0.0
+    date: 2026-06-13
+    changes: "Init history"
+author: aymericzip
+---
+
+# Міграція з i18n-js на Intlayer
+
+Перехід з бібліотеки `i18n-js` на Intlayer — це високооптимізована міграція, розроблена для переведення великих конфігурацій перекладів у структуровану систему розділення файлів Intlayer.
+
+## Що робити
+
+Виконайте наступну команду налаштування у вашому репозиторії:
+
+```bash
+npx intlayer init
+```
+
+З підготовленим `intlayer.config.ts`, ви можете додати alias Intlayer до конфігурації вашого bundler, щоб будь-які імпорти `i18n-js` спрямовувалися на пакет сумісності `@intlayer/i18n-js`.
+
+## Що він робить під капотом
+
+`i18n-js` accesses namespaces through expressions like `i18n.t('scope.key', {name})` along with locale fallbacks and specific plural mappings.
+
+Under the hood:
+
+- **Interpolation:** The compat adapter easily parses `%{name}` mappings into your targeted runtime dictionary value.
+- **Pluralization:** Replaces `one/other` subkeys and maps them against Intlayer's powerful underlying plural mechanisms (`Intl.PluralRules`), abstracting away manual mappings.
+- **Locales:** Instead of loading monolithic language payloads at bootstrap, dictionaries are served up optimally based on the current context setup via the native Intlayer configuration.

package/docs/uk/compat/i18next.md

@@ -0,0 +1,59 @@
+---
+createdAt: 2026-06-13
+updatedAt: 2026-06-13
+title: "Перейти з i18next на Intlayer"
+description: "Дізнайтеся, як перенести вашу програму Vanilla JS/TS з i18next на Intlayer, використовуючи адаптер сумісності."
+keywords:
+  - i18next
+  - vanilla
+  - javascript
+  - typescript
+  - intlayer
+  - migration
+  - compat
+slugs:
+  - doc
+  - compatibility
+  - i18next
+history:
+  - version: 9.0.0
+    date: 2026-06-13
+    changes: "Init history"
+author: aymericzip
+---
+
+# Міграція з i18next на Intlayer
+
+Для детального покрокового посібника дивіться наш повний [Посібник з міграції з i18next](../migration_from_i18next_to_intlayer.md).
+
+Intlayer ідеально повторює основні характеристики виконання `i18next`. Використовуючи пакет compat, ваші Vanilla-додатки або внутрішні модулі можуть продовжувати використовувати звичний синтаксис.
+
+## Що робити
+
+Щоб розпочати, ініціалізуйте Intlayer у своєму проекті:
+
+```bash
+npx intlayer init
+```
+
+Якщо ви використовуєте Vite, включіть плагін Intlayer для маршрутизації імпортів до `@intlayer/i18next`:
+
+```typescript fileName="vite.config.ts"
+import { defineConfig } from "vite";
+import { i18nextVitePlugin } from "@intlayer/i18next/plugin";
+
+export default defineConfig({
+  plugins: [i18nextVitePlugin()],
+});
+```
+
+## Як це працює під капотом
+
+`i18nextVitePlugin` переспрямовує імпорти `i18next` на `@intlayer/i18next`, уникаючи збільшення розміру bundle через включення JSON файлів.
+
+Під капотом:
+
+- **Конфігурація екземпляра:** `createInstance` правильно парсить та застосовує fallbacks простору імен, одночасно використовуючи конвеєр компіляції Intlayer для отримання словників.
+- **Інтерполяція:** Нативна підтримка замін `{{name}}` та вкладеного `$t(key)` рекурсивно.
+- **Контекст і плюралізація:** Визначає та розв'язує формати суфіксів на кшталт `key_male` та `key_one`/`key_other`, оцінюючи їх за стандартом `Intl.PluralRules`.
+- **Повернення об'єктів:** Режим `returnObjects: true` безпечно витягує дерева з словників Intlayer.

package/docs/uk/compat/index.md

@@ -0,0 +1,51 @@
+---
+createdAt: 2026-06-13
+updatedAt: 2026-06-13
+title: "Адаптери сумісності Intlayer"
+description: "Мігруйте своє існуюче рішення i18n на Intlayer без зусиль, використовуючи адаптери сумісності."
+keywords:
+  - compat
+  - migration
+  - internationalization
+  - i18n
+  - Intlayer
+slugs:
+  - doc
+  - compatibility
+history:
+  - version: 9.0.0
+    date: 2026-06-13
+    changes: "Init history"
+author: aymericzip
+---
+
+# Compat адаптери Intlayer
+
+Міграція великої програми на нову бібліотеку інтернаціоналізації може бути складною. Щоб полегшити цей перехід, Intlayer надає **compat адаптери** для найпопулярніших i18n бібліотек в екосистемі.
+
+Ці пакети адаптерів надають **точно такий самий публічний API**, як ваші існуючі i18n бібліотеки, але делегують усю роботу перекладу в Intlayer під час виконання.
+
+## Як це працює
+
+Коли ви використовуєте compat adapter, вам не потрібно переписувати імпорти вашої програми або змінювати те, як ви користуєтеся translation hooks та компонентами. Замість цього, плагіни bundler Intlayer автоматично створюють alias ваших існуючих імпортів на Intlayer compat пакети.
+
+Наприклад, розробник замінює `import { useTranslation } from 'react-i18next'` на `import { useTranslation } from '@intlayer/react-i18next'` (робиться автоматично через плагін bundler), і програма продовжує працювати з перекладами, які тепер надаються з Intlayer словників. Ключі також типізовані щодо ваших Intlayer словників!
+
+## Доступні адаптери сумісності
+
+Виберіть вашу існуючу бібліотеку нижче, щоб дізнатися, як легко перейти:
+
+- [Vue I18n](./vue-i18n.md)
+- [Transloco](./transloco.md)
+- [React Intl](./react-intl.md)
+- [Svelte I18n](./svelte-i18n.md)
+- [React i18next](./react-i18next.md)
+- [Polyglot.js](./polyglot.md)
+- [NuxtJS I18n](./nuxtjs-i18n.md)
+- [NGX Translate](./ngx-translate.md)
+- [Next Translate](./next-translate.md)
+- [Next Intl](./next-intl.md)
+- [Next i18next](./next-i18next.md)
+- [i18next](./i18next.md)
+- [Lingui](./lingui.md)
+- [I18n-js](./i18n-js.md)

package/docs/uk/compat/lingui.md

@@ -0,0 +1,44 @@
+---
+createdAt: 2026-06-13
+updatedAt: 2026-06-13
+title: "Міграція з Lingui на Intlayer"
+description: "Дізнайтеся, як мігрувати вашу програму з Lingui на Intlayer, використовуючи адаптер сумісності."
+keywords:
+  - lingui
+  - intlayer
+  - migration
+  - compat
+slugs:
+  - doc
+  - compatibility
+  - lingui
+history:
+  - version: 9.0.0
+    date: 2026-06-13
+    changes: "Init history"
+author: aymericzip
+---
+
+# Міграція з Lingui на Intlayer
+
+Якщо ваш проект наразі використовує компіляцію на основі макросів Lingui, перехід на Intlayer дозволяє вам зберегти потужні робочі процеси макросів, одночасно підтримуючи їх нативно за допомогою стратегії JSON-компіляції Intlayer.
+
+## Що робити
+
+Для початку ініціалізуйте Intlayer у своєму проекті:
+
+```bash
+npx intlayer init
+```
+
+Це створює ваш `intlayer.config.ts`. Переконайтеся, що ви зберегли `@lingui/babel-plugin-lingui-macro` / `@lingui/swc-plugin` у вашому кроці збірки для запуску _перед_ компілятором Intlayer. Потім використовуйте alias плагіна bundler для маршрутизації `@lingui/core` та `@lingui/react` до `@intlayer/lingui`.
+
+## Як це працює під капотом
+
+Lingui використовує макроси (такі як `` t`Hello ${name}` `` та `<Trans>`), які компілюються в runtime-виклики типу `i18n._(id, values)`.
+
+Під капотом:
+
+- **Макроси:** Вони компілюються точно так же, як раніше, забезпечуючи відсутність порушень у вашому синтаксисі вихідного коду.
+- **Runtime-переклад:** Псевдонім `i18n._()` використовує словники Intlayer. Як явно названі ID, так і захешовані ID повністю відображаються за допомогою плагінів синхронізації `.po` Intlayer для безпечної агрегації та видалення ключів.
+- **Можливості ICU:** Підтримка плюралізації, вибору та варіантів ICU залишається стійкою завдяки уніфікованому ICU-парсеру Intlayer, забезпечуючи однакові результати рендерингу.

package/docs/uk/compat/next-i18next.md

@@ -0,0 +1,57 @@
+---
+createdAt: 2026-06-13
+updatedAt: 2026-06-13
+title: "Міграція з next-i18next на Intlayer"
+description: "Дізнайтеся, як перенести своє Next.js додаток з next-i18next на Intlayer за допомогою адаптера сумісності."
+keywords:
+  - next-i18next
+  - nextjs
+  - intlayer
+  - migration
+  - compat
+slugs:
+  - doc
+  - compatibility
+  - next-i18next
+history:
+  - version: 9.0.0
+    date: 2026-06-13
+    changes: "Init history"
+author: aymericzip
+---
+
+# Міграція з next-i18next на Intlayer
+
+Для повного та детального покрокового посібника, будь ласка, див. наш [Посібник з міграції next-i18next](../migration_from_next-i18next_to_intlayer.md).
+
+Intlayer прозоро обробляє всі реалізації Next.js Pages Router та App Router. Використання адаптера дозволяє вам перенести вашу реалізацію `next-i18next` без переписування коду.
+
+## Що робити
+
+Для початку виконайте:
+
+```bash
+npx intlayer init
+```
+
+Це створює необхідний файл конфігурації Intlayer. Щоб інтегрувати Intlayer в фоновому режимі, оновіть ваш `next.config.ts`:
+
+```typescript fileName="next.config.ts"
+import type { NextConfig } from "next";
+import { createNextI18nPlugin } from "@intlayer/next-i18next/plugin";
+
+const withIntlayer = createNextI18nPlugin();
+
+const nextConfig: NextConfig = {};
+
+export default withIntlayer(nextConfig);
+```
+
+## Що він робить під капотом
+
+`createNextI18nPlugin` поєднує нативну поведінку Next.js разом з основним плагіном `next-intlayer`, інжектуючи всі необхідні псевдоніми Webpack/Turbopack для `next-i18next`, `react-i18next` та `i18next`.
+
+Під капотом:
+
+- **`serverSideTranslations` & `appWithTranslation`:** Тепер вони функціонують як обгортки для внутрішніх завантажувачів Intlayer, обходячи велику статичну ін'єкцію JSON.
+- **Client hooks:** Негайно делегує до `@intlayer/react-i18next`, збереження всі функції форматування, множин та вкладених просторів імен.