@intlayer/docs 7.5.13 → 7.5.14

package/blog/ru/per-component_vs_centralized_i18n.md

@@ -0,0 +1,251 @@
+---
+createdAt: 2025-09-10
+updatedAt: 2025-09-10
+title: i18n на уровне компонента против централизованного: новый подход с Intlayer
+description: Глубокое погружение в стратегии интернационализации в React, сравнение централизованного, по-ключевого и по-компонентного подходов, и представление Intlayer.
+keywords:
+  - i18n
+  - React
+  - Интернационализация
+  - Intlayer
+  - Оптимизация
+  - Размер бандла
+slugs:
+  - blog
+  - per-component-vs-centralized-i18n
+---
+
+# По-компонентный vs централизованный i18n
+
+Подход по компонентам — не новое понятие. Например, в экосистеме Vue `vue-i18n` поддерживает [i18n SFC (Single File Component)](https://vue-i18n.intlify.dev/guide/advanced/sfc.html). Nuxt также предлагает [переводы на уровне компонента](https://i18n.nuxtjs.org/docs/guide/per-component-translations), а Angular использует похожий паттерн через свои [Feature Modules](https://v17.angular.io/guide/feature-modules).
+
+Даже в Flutter-приложении часто встречается следующий паттерн:
+
+```bash
+lib/
+└── features/
+    └── login/
+        ├── login_screen.dart
+        └── login_screen.i18n.dart  # <- Переводы находятся здесь
+```
+
+```dart fileName='lib/features/login/login_screen.i18n.dart'
+import 'package:i18n_extension/i18n_extension.dart';
+
+extension Localization on String {
+  static var _t = Translations.byText("en") +
+      {
+        "Hello": {
+          "en": "Hello",
+          "fr": "Bonjour",
+        },
+      };
+
+  String get i18n => localize(this, _t);
+}
+```
+
+Однако в мире React мы в основном видим разные подходы, которые я сгруппирую в три категории:
+
+<Columns>
+  <Column>
+
+**Централизованный подход** (i18next, next-intl, react-intl, lingui)
+
+- (без пространств имён) рассматривает единый источник для получения контента. По умолчанию вы загружаете контент со всех страниц при загрузке приложения.
+
+  </Column>
+  <Column>
+
+**Гранулярный подход** (intlayer, inlang)
+
+- более тонко настраивает получение контента — по ключу или по компоненту.
+
+  </Column>
+</Columns>
+
+> В этом блоге я не буду фокусироваться на решениях, основанных на компиляции, которые я уже рассмотрел здесь: [Компилятор vs декларативный i18n](https://github.com/aymericzip/intlayer/blob/main/docs/blog/ru/compiler_vs_declarative_i18n.md).
+> Обратите внимание, что i18n, основанный на компиляции (например, Lingui), просто автоматизирует извлечение и загрузку контента. Под капотом они часто имеют те же ограничения, что и другие подходы.
+
+> Обратите внимание: чем тоньше вы разбиваете механизм получения контента, тем больше риск внедрения дополнительного состояния и логики в ваши компоненты.
+
+Гранулярные подходы более гибкие, чем централизованные, но часто это компромисс. Даже если библиотеки рекламируют "tree shaking", на практике вы часто в итоге будете загружать страницу на каждом языке.
+
+В целом решение сводится к следующему:
+
+- Если в вашем приложении страниц больше, чем языков, стоит отдавать предпочтение гранулярному подходу.
+- Если языков больше, чем страниц, стоит склоняться к централизованному подходу.
+
+Разработчики библиотек, разумеется, знают об этих ограничениях и предлагают обходные решения. Среди них: разделение на namespaces, динамическая загрузка JSON-файлов (`await import()`), или очистка контента на этапе сборки.
+
+В то же время следует учитывать, что при динамической подгрузке контента вы создаёте дополнительные запросы к серверу. Каждое дополнительное `useState` или hook означает ещё один запрос к серверу.
+
+> Чтобы решить эту проблему, Intlayer предлагает группировать несколько определений контента под одним и тем же ключом; Intlayer затем объединит этот контент.
+
+Исходя из всего этого, очевидно, что наиболее популярным подходом является централизованный.
+
+### Почему же централизованный подход так популярен?
+
+/// Во-первых, i18next был первым решением, ставшим широко используемым, следуя философии, вдохновлённой архитектурами PHP и Java (MVC), которые опираются на строгую сегрегацию обязанностей (содержание отделено от кода). Он появился в 2011 году, установив свои стандарты ещё до масштабного перехода к компонентно-ориентированным архитектурам (например, React).
+
+- Затем, как только библиотека становится широко принятой, переход экосистемы на другие паттерны становится затруднительным.
+- Использование централизованного подхода также упрощает работу с системами управления переводами, такими как Crowdin, Phrase или Localized.
+- Логика подхода per-component более сложна, чем у централизованного, и требует дополнительного времени на разработку, особенно когда приходится решать такие задачи, как определение местоположения контента.
+
+### Хорошо, но почему просто не придерживаться централизованного подхода?
+
+Давайте я объясню, почему это может стать проблемой для вашего приложения:
+
+- **Неиспользуемые данные:**
+  Когда загружается страница, вы часто загружаете содержимое со всех остальных страниц. (В приложении из 10 страниц это 90% загруженного, но неиспользуемого контента). Ленивая загрузка модального окна? Библиотека i18n всё равно не обращает внимания — она сначала загружает строки.
+
+- **Производительность:**
+  При каждом повторном рендере каждый ваш компонент гидратируется массивной JSON‑нагрузкой, что негативно влияет на реактивность приложения по мере его роста.
+
+- **Поддержка:**
+  Поддерживать большие JSON‑файлы болезненно. Приходится переходить между файлами, чтобы вставить перевод, при этом нужно следить, чтобы не было отсутствующих переводов и чтобы не осталось **orphan keys**.
+
+- **Дизайн‑система:**
+  Это создаёт несовместимость с design systems (например, компонент `LoginForm`) и ограничивает дублирование компонентов между разными приложениями.
+
+**"Но мы придумали Namespaces!"**
+
+Конечно, и это значительный шаг вперёд. Давайте сравним размер основного бандла для конфигурации `Vite + React + React Router v7 + Intlayer`. Мы симулировали 20-страничное приложение.
+
+Первый пример не включает ленивую загрузку переводов по локалям и не содержит разделения на namespaces. Во втором примере используется content purging + динамическая загрузка переводов.
+
+| Оптимизированный бандл                                                                                                         | Неоптимизированный бандл                                                                                     |
+| ------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------ |
+| ![неоптимизированный bundle](https://github.com/aymericzip/intlayer/blob/main/docs/assets/bundle_no_optimization.png?raw=true) | ![оптимизированный bundle](https://github.com/aymericzip/intlayer/blob/main/docs/assets/bundle.png?raw=true) |
+
+Таким образом, благодаря namespaces, мы перешли от этой структуры:
+
+```bash
+locale/
+├── en.json
+├── fr.json
+└── es.json
+```
+
+To this one:
+
+```bash
+locale/
+├── en/
+│   ├── common.json
+│   ├── navbar.json
+│   ├── footer.json
+│   ├── home.json
+│   └── about.json
+├── fr/
+│   └── ...
+└── es/
+    └── ...
+
+```
+
+Теперь вам нужно тонко управлять тем, какую часть контента вашего приложения следует загружать и где. В результате подавляющее большинство проектов просто пропускают эту часть из‑за сложности (см. руководство [next-i18next](https://github.com/aymericzip/intlayer/blob/main/docs/blog/ru/i18n_using_next-i18next.md), чтобы увидеть, какие вызовы представляет собой (даже) следование лучшим практикам).
+Вследствие этого такие проекты в конечном итоге сталкиваются с проблемой массовой загрузки JSON, описанной ранее.
+
+> Обратите внимание, что эта проблема не является специфичной для i18next, а относится ко всем централизованным подходам, перечисленным выше.
+
+Однако хочу напомнить, что не все гранулярные подходы решают эту проблему. Например, подходы `vue-i18n SFC` или `inlang` по сути не выполняют ленивую подгрузку переводов по локалям, поэтому вы просто меняете проблему размера бандла (bundle size) на другую.
+
+Кроме того, без правильного разделения ответственности становится гораздо сложнее извлечь и передать ваши переводы переводчикам для проверки.
+
+### Как покомпонентный подход Intlayer решает эту проблему
+
+Intlayer работает в несколько шагов:
+
+1. **Declaration:** Объявляйте ваш контент в любом месте codebase, используя файлы `*.content.{ts|jsx|cjs|json|json5|...}`. Это обеспечивает разделение ответственности при одновременном размещении контента рядом с кодом (colocated). Файл контента может быть для одной локали или мультиязычным.
+2. **Обработка:** Intlayer выполняет шаг сборки для обработки JS-логики, обработки отсутствующих переводов (fallbacks), генерации типов TypeScript, управления дублирующимся контентом, получения контента из вашей CMS и прочего.
+3. **Очистка:** Когда ваше приложение собирается, Intlayer удаляет неиспользуемый контент (немного похожим образом на то, как Tailwind управляет вашими классами), заменяя контент следующим образом:
+
+**Декларация:**
+
+```tsx
+// src/MyComponent.tsx
+export const MyComponent = () => {
+  const content = useIntlayer("my-key");
+  return <h1>{content.title}</h1>;
+};
+```
+
+```tsx
+// src/myComponent.content.ts
+export const {
+  key: "my-key",
+  content: t({
+    ru: { title: "Мой заголовок" },
+    en: { title: "My title" },
+    fr: { title: "Mon titre" }
+  })
+}
+
+```
+
+**Обработка:** Intlayer собирает словарь на основе файла `.content` и генерирует:
+
+```json5
+// .intlayer/dynamic_dictionary/en/my-key.json
+{
+  "key": "my-key",
+  "content": { "title": "Мой заголовок" },
+}
+```
+
+**Замена:** Intlayer преобразует ваш компонент во время сборки приложения.
+
+**- Режим статического импорта:**
+
+```tsx
+// Representation of the component in JSX-like syntax
+export const MyComponent = () => {
+  const content = useDictionary({
+    key: "my-key",
+    content: {
+      nodeType: "translation",
+      translation: {
+        en: { title: "Мой заголовок" },
+        fr: { title: "Мой заголовок" },
+      },
+    },
+  });
+
+  return <h1>{content.title}</h1>;
+};
+```
+
+**- Режим динамического импорта:**
+
+```tsx
+// Representation of the component in JSX-like syntax
+export const MyComponent = () => {
+  const content = useDictionaryAsync({
+    en: () =>
+      import(".intlayer/dynamic_dictionary/en/my-key.json", {
+        with: { type: "json" },
+      }).then((mod) => mod.default),
+    // То же самое для других языков
+  });
+
+  return <h1>{content.title}</h1>;
+};
+```
+
+> `useDictionaryAsync` использует механизм, похожий на Suspense, чтобы загружать локализованный JSON только по мере необходимости.
+
+**Ключевые преимущества этого подхода на уровне компонентов:**
+
+- Держать объявление контента рядом с компонентами повышает удобство сопровождения (например, при переносе компонентов в другое приложение или дизайн-систему. Удаление папки компонента также удаляет связанный контент, как вы, вероятно, уже делаете для ваших `.test`, `.stories`)
+
+- Подход «по компонентам» избавляет AI-агентов от необходимости перескакивать между множеством разных файлов. Он собирает все переводы в одном месте, снижая сложность задачи и количество используемых токенов.
+
+### Ограничения
+
+Разумеется, у такого подхода есть компромиссы:
+
+- Сложнее интегрироваться с другими l10n‑системами и дополнительным tooling'ом (инструментариями).
+- Возникает привязка к выбранному решению (что, по сути, уже характерно для любых i18n‑решений из‑за их специфического синтаксиса).
+
+Именно поэтому Intlayer стремится предоставить полный набор инструментов для i18n (100% бесплатно и с открытым исходным кодом), включая AI‑перевод с использованием вашего собственного AI Provider и API‑ключей. Intlayer также предоставляет tooling для синхронизации ваших JSON‑файлов, функционируя как message formatters ICU / vue-i18n / i18next для сопоставления контента с их специфичными форматами.

package/blog/tr/per-component_vs_centralized_i18n.md

@@ -0,0 +1,244 @@
+---
+createdAt: 2025-09-10
+updatedAt: 2025-09-10
+title: Bileşen-Başına vs Merkezileştirilmiş i18n: Intlayer ile Yeni Bir Yaklaşım
+description: React'te uluslararasılaştırma stratejilerine derinlemesine bir bakış; merkezi, per-key (anahtar-başına) ve bileşen-başına yaklaşımları karşılaştırır ve Intlayer'ı tanıtır.
+keywords:
+  - i18n
+  - React
+  - Uluslararasılaştırma
+  - Intlayer
+  - Optimizasyon
+  - Bundle Boyutu
+slugs:
+  - blog
+  - per-component-vs-centralized-i18n
+---
+
+# Bileşen-Başına (Per-Component) vs Merkezileştirilmiş (Centralized) i18n
+
+Bileşen başına yaklaşımı yeni bir kavram değildir. Örneğin, Vue ekosisteminde `vue-i18n` [SFC i18n (Single File Component)](https://vue-i18n.intlify.dev/guide/advanced/sfc.html) destekler. Nuxt ayrıca [bileşen başına çeviriler](https://i18n.nuxtjs.org/docs/guide/per-component-translations) sunar ve Angular, [Feature Modules](https://v17.angular.io/guide/feature-modules) aracılığıyla benzer bir desen kullanır.
+
+Hatta bir Flutter uygulamasında bile genellikle şu desenle karşılaşırız:
+
+```bash
+lib/
+└── features/
+    └── login/
+        ├── login_screen.dart
+        └── login_screen.i18n.dart  # <- Çeviriler burada yer alır
+```
+
+```dart fileName='lib/features/login/login_screen.i18n.dart'
+import 'package:i18n_extension/i18n_extension.dart';
+
+extension Localization on String {
+  static var _t = Translations.byText("en") +
+      {
+        "Hello": {
+          "en": "Hello",
+          "fr": "Bonjour",
+        },
+      };
+
+  String get i18n => localize(this, _t);
+}
+```
+
+Ancak React dünyasında genellikle farklı yaklaşımlar görüyoruz; bunları üç kategoride toplayacağım:
+
+<Columns>
+  <Column>
+
+**Merkezi yaklaşım** (i18next, next-intl, react-intl, lingui)
+
+- (namespace olmadan) içeriği almak için tek bir kaynak kullanır. Varsayılan olarak, uygulamanız yüklendiğinde tüm sayfalardaki içeriği yüklersiniz.
+
+  </Column>
+  <Column>
+
+**Granüler yaklaşım** (intlayer, inlang)
+
+- içerik alımını anahtar başına veya bileşen başına ince taneli olarak yapar.
+
+  </Column>
+</Columns>
+
+> Bu blogda, zaten burada ele aldığım derleyici tabanlı çözümlere odaklanmayacağım: [Derleyici vs Deklaratif i18n](https://github.com/aymericzip/intlayer/blob/main/docs/blog/tr/compiler_vs_declarative_i18n.md).
+> Derleyici tabanlı i18n (ör. Lingui) yalnızca içeriğin çıkarılmasını ve yüklenmesini otomatikleştirir. İçeride genellikle diğer yaklaşımlarla aynı sınırlamaları paylaşırlar.
+
+> İçeriği ne kadar ince taneli alırsanız, bileşenlerinize ekstra state ve mantık ekleme riski o kadar artar.
+
+Granüler yaklaşımlar merkezi olanlardan daha esnektir, ancak bu genellikle bir ödündür. Bu kütüphaneler "tree shaking" sunduklarını iddia etseler bile, pratikte genellikle bir sayfayı her dil için yüklersiniz.
+
+Genel olarak karar kabaca şu şekilde özetlenebilir:
+
+- Uygulamanızda dil sayısından daha fazla sayfa varsa, granüler yaklaşımı tercih etmelisiniz.
+- Sayfa sayısından daha fazla diliniz varsa, merkezi yaklaşıma yönelmelisiniz.
+
+Elbette, kütüphane yazarları bu sınırlamaların farkındadır ve çözüm yolları sağlarlar. Bunlar arasında: namespaces'lere bölme, JSON dosyalarını dinamik olarak yükleme (`await import()`), veya derleme zamanında içeriği temizleme yer alır.
+
+Aynı zamanda, içeriğinizi dinamik olarak yüklediğinizde sunucunuza ek istekler gönderdiğinizi bilmelisiniz. Her ek `useState` veya hook, ekstra bir sunucu isteği anlamına gelir.
+
+> Bu noktayı düzeltmek için, Intlayer birden fazla içerik tanımını aynı anahtar altında gruplamanızı önerir; Intlayer daha sonra bu içerikleri birleştirecektir.
+
+Ancak tüm bu çözümlere bakıldığında, en popüler yaklaşımın merkezi (centralized) yaklaşım olduğu açıktır.
+
+### Peki Merkezi yaklaşım neden bu kadar popüler?
+
+- Öncelikle, i18next yaygın olarak kullanılan ilk çözümdü; PHP ve Java mimarilerinden (MVC) esinlenen, sorumlulukların sıkı bir ayrımına (içeriği koddan ayrı tutma) dayanan bir felsefeyi takip etti. 2011'de ortaya çıktı ve Component-Based Architectures (React gibi) yönündeki büyük değişimden bile önce kendi standartlarını belirledi.
+- Sonra, bir kütüphane yaygın olarak benimsendiğinde, ekosistemi farklı yaklaşımlara kaydırmak zorlaşır.
+- Merkezi bir yaklaşım kullanmak ayrıca Crowdin, Phrase veya Localized gibi Çeviri Yönetim Sistemlerinde işleri kolaylaştırır.
+- Bileşen başına (per-component) yaklaşımın mantığı merkezi olandan daha karmaşıktır ve geliştirilmesi daha fazla zaman alır, özellikle içeriğin nerede bulunduğunu tespit etmek gibi problemleri çözmeniz gerektiğinde.
+
+### Peki, ama neden sadece Centralized bir yaklaşıma bağlı kalmayalım?
+
+Uygulamanız için neden sorunlu olabileceğini söyleyeyim:
+
+- **Kullanılmayan Veri:** Bir sayfa yüklendiğinde genellikle tüm diğer sayfaların içeriğini de yüklersiniz. (10 sayfalık bir uygulamada bu, yüklenen içeriğin %90'ının kullanılmaması demektir). Bir modal'ı tembel yükleme (lazy load) ile mi yüklüyorsunuz? i18n kütüphanesi umursamaz, önce yine de stringleri yükler.
+- **Performans:** Her yeniden render'da, bileşenlerinizin her biri devasa bir JSON payload ile hydrate edilir; bu, uygulamanız büyüdükçe reaktivitesini etkiler.
+- **Bakım:** Büyük JSON dosyalarını sürdürmek zahmetlidir. Bir çeviri eklemek için dosyalar arasında atlamanız gerekir; eksik çeviri olmadığından ve geride **orphan keys** kalmadığından emin olmalısınız.
+- **Tasarım sistemi:**
+  Bu, design system'lerle uyumsuzluk yaratır (örn. bir `LoginForm` bileşeni) ve bileşenlerin farklı uygulamalar arasında çoğaltılmasını kısıtlar.
+
+**"Ama Namespaces'i icat ettik!"**
+
+Evet, bu büyük bir ilerleme. Vite + React + React Router v7 + Intlayer kurulumu için ana bundle boyutunun karşılaştırmasına bakalım. 20 sayfalık bir uygulama simüle ettik.
+
+İlk örnek locale başına lazy-loaded çeviriler içermez ve namespace ayrımı yapmaz. İkinci örnek içerik temizleme + çeviriler için dinamik yükleme içerir.
+
+| Optimize edilmiş bundle                                                                                                        | Optimize edilmemiş bundle                                                                                    |
+| ------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------ |
+| ![optimize edilmemiş bundle](https://github.com/aymericzip/intlayer/blob/main/docs/assets/bundle_no_optimization.png?raw=true) | ![optimize edilmiş bundle](https://github.com/aymericzip/intlayer/blob/main/docs/assets/bundle.png?raw=true) |
+
+Bu nedenle namespaces sayesinde şu yapıdan şu yapıya geçtik:
+
+```bash
+locale/
+├── en.json
+├── fr.json
+└── es.json
+```
+
+To this one:
+
+```bash
+locale/
+├── en/
+│   ├── common.json
+│   ├── navbar.json
+│   ├── footer.json
+│   ├── home.json
+│   └── about.json
+├── fr/
+│   └── ...
+└── es/
+    └── ...
+
+```
+
+Artık uygulamanızın hangi içeriğinin nerede ve ne zaman yükleneceğini ince ayrıntısına kadar yönetmeniz gerekiyor. Sonuç olarak, karmaşıklık nedeniyle projelerin büyük çoğunluğu bu kısmı atlıyor (örneğin (sadece) iyi uygulamaları takip etmenin getirdiği zorlukları görmek için [next-i18next rehberi](https://github.com/aymericzip/intlayer/blob/main/docs/blog/tr/i18n_using_next-i18next.md)'ne bakın).
+Buna bağlı olarak, bu projeler daha önce açıklanan devasa JSON yükleme sorunuyla karşılaşıyor.
+
+> Not: Bu sorun yalnızca i18next'e özgü değildir; yukarıda listelenen tüm merkezi yaklaşımlar için geçerlidir.
+
+Ancak size hatırlatmak isterim ki tüm granüler yaklaşımlar bunu çözmez. Örneğin, `vue-i18n SFC` veya `inlang` yaklaşımları çevirileri her locale için varsayılan olarak tembel yükleme (lazy load) yapmaz; böylece paket boyutu sorununu başka bir sorunla takas etmiş olursunuz.
+
+Ayrıca, uygun bir sorumluluk ayrımı olmadan, çevirilerinizi inceleme için çevirmenlere çıkarmak ve sağlamak çok daha zor hale gelir.
+
+### Intlayer'ın bileşen başına yaklaşımı bunu nasıl çözer
+
+Intlayer birkaç adımda ilerler:
+
+1. **Deklarasyon:** İçeriğinizi kod tabanınızın herhangi bir yerine `*.content.{ts|jsx|cjs|json|json5|...}` dosyaları kullanarak tanımlayın. Bu, içeriği aynı konumda tutarken sorumlulukların ayrılmasını sağlar. Bir content dosyası locale başına veya çokdilli olabilir.
+2. **İşleme:** Intlayer, JS mantığını işlemek, eksik çeviri fallback'larını yönetmek, TypeScript tipleri üretmek, yinelenen içeriği yönetmek, CMS'inizden içerik almak ve daha fazlası için bir build adımı çalıştırır.
+3. **Temizleme:** Uygulamanız build edildiğinde, Intlayer kullanılmayan içeriği (Tailwind'in sınıfları nasıl yönettiğine biraz benzer şekilde) aşağıdaki gibi içerikleri değiştirerek temizler:
+
+**Deklarasyon:**
+
+```tsx
+// src/MyComponent.tsx
+export const MyComponent = () => {
+  const content = useIntlayer("my-key");
+  return <h1>{content.title}</h1>;
+};
+```
+
+```tsx
+// src/myComponent.content.ts
+export const {
+  key: "my-key",
+  content: t({
+    tr: { title: "Başlığım" },
+    en: { title: "My title" },
+    fr: { title: "Mon titre" }
+  })
+}
+
+```
+
+**İşleme:** Intlayer, `.content` dosyasına dayanarak sözlüğü oluşturur ve şunları üretir:
+
+```json5
+// .intlayer/dynamic_dictionary/en/my-key.json (JSON dosyası)
+{
+  "key": "my-key",
+  "content": { "title": "My title" },
+}
+```
+
+**Yerine Koyma:** Intlayer, uygulama derlemesi sırasında bileşeninizi dönüştürür.
+
+**- Statik İçe Aktarma Modu:**
+
+```tsx
+// Bileşenin JSX-benzeri sözdizimindeki gösterimi
+export const MyComponent = () => {
+  const content = useDictionary({
+    key: "my-key",
+    content: {
+      nodeType: "translation",
+      translation: {
+        en: { title: "My title" },
+        fr: { title: "Mon titre" },
+      },
+    },
+  });
+
+  return <h1>{content.title}</h1>;
+};
+```
+
+**- Dinamik İçe Aktarma Modu:**
+
+```tsx
+// Bileşenin JSX-benzeri sözdizimindeki gösterimi
+export const MyComponent = () => {
+  const content = useDictionaryAsync({
+    en: () =>
+      import(".intlayer/dynamic_dictionary/en/my-key.json", {
+        with: { type: "json" },
+      }).then((mod) => mod.default),
+    // Same for other languages
+  });
+
+  return <h1>{content.title}</h1>;
+};
+```
+
+> `useDictionaryAsync`, yalnızca gerektiğinde yerelleştirilmiş JSON'u yüklemek için Suspense-benzeri bir mekanizma kullanır.
+
+**Bu bileşen-bağımlı yaklaşımın ana faydaları:**
+
+- İçerik bildiriminizi bileşenlerinize yakın tutmak, daha iyi bakım kolaylığı sağlar (ör. bir bileşeni başka bir uygulamaya veya tasarım sistemine taşımak). Bileşen klasörünü silmek, ilgili içeriği de kaldırır; tıpkı muhtemelen `.test`, `.stories` dosyalarınız için yaptığınız gibi.
+
+- Bileşen başına yaklaşım, AI ajanlarının tüm farklı dosyalarınız arasında atlamasına gerek kalmasını engeller. Tüm çevirileri tek bir yerde ele alarak görevin karmaşıklığını ve kullanılan token miktarını sınırlar.
+
+### Sınırlamalar
+
+Elbette, bu yaklaşım bazı ödünler gerektirir:
+
+- Diğer l10n sistemlerine ve ek araçlara bağlanmak daha zor olur.
+- Bağımlı hale gelirsiniz (ki bu, belirli sözdizimleri nedeniyle zaten her i18n çözümünde olan bir durumdur).
+
+İşte bu yüzden Intlayer, kendi AI Provider ve API keys'inizi kullanarak AI çevirisini de içeren i18n için eksiksiz bir araç seti sağlamaya çalışır (100% ücretsiz ve OSS). Intlayer ayrıca JSON'unuzu senkronize etmeye yarayan araçlar da sağlar; bu araçlar ICU / vue-i18n / i18next mesaj formatlayıcıları gibi çalışarak içeriği bu özel formatlara eşler.