@intlayer/docs 7.5.13 → 7.5.14

package/blog/uk/per-component_vs_centralized_i18n.md

@@ -0,0 +1,248 @@
+---
+createdAt: 2025-09-10
+updatedAt: 2025-09-10
+title: Per-Component проти централізованого i18n: новий підхід з Intlayer
+description: Детальний огляд стратегій інтернаціоналізації в React: порівняння централізованого, per-key і per-component підходів та презентація Intlayer.
+keywords:
+  - i18n
+  - React
+  - Internationalization
+  - Intlayer
+  - Optimization
+  - Bundle Size
+slugs:
+  - blog
+  - per-component-vs-centralized-i18n
+---
+
+# Підхід per-component проти централізованого i18n
+
+Підхід per-component не є новим поняттям. Наприклад, в екосистемі Vue `vue-i18n` підтримує [i18n SFC (Single File Component)](https://vue-i18n.intlify.dev/guide/advanced/sfc.html). Nuxt також пропонує [переклади per-component](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>
+
+> У цьому блозі я не зосереджуватимусь на рішеннях на основі компілятора, які я вже розглянув тут: [Компілятор проти декларативного i18n](https://github.com/aymericzip/intlayer/blob/main/docs/blog/uk/compiler_vs_declarative_i18n.md).
+> Зауважте, що компіляторні i18n-рішення (наприклад, Lingui) лише автоматизують витяг та завантаження контенту. Під капотом вони часто мають ті самі обмеження, що й інші підходи.
+
+> Зауважте, що чим детальніше ви налаштовуєте спосіб отримання контенту, тим більший ризик додати додатковий стан і логіку в компоненти.
+
+Гранулярні підходи є більш гнучкими, ніж централізовані, але часто це компроміс. Навіть якщо ці бібліотеки рекламують "tree shaking", на практиці ви часто в кінцевому підсумку завантажуєте сторінку на всіх мовах.
+
+Отже, в загальних рисах рішення зводиться до наступного:
+
+- Якщо в вашому застосунку більше сторінок, ніж мов, варто віддавати перевагу гранулярному підходу.
+- Якщо мов більше, ніж сторінок, слід схилитися до централізованого підходу.
+
+Звісно, автори бібліотек усвідомлюють ці обмеження і пропонують обхідні шляхи.
+Серед них: розподіл на namespaces, динамічне завантаження JSON-файлів (`await import()`), або очищення контенту під час збірки.
+
+Водночас потрібно знати, що коли ви динамічно завантажуєте свій вміст, ви вводите додаткові запити до сервера. Кожен додатковий `useState` або хук означає ще один запит до сервера.
+
+> Щоб вирішити це питання, Intlayer пропонує групувати кілька визначень контенту під одним ключем — Intlayer потім об'єднає цей контент.
+
+Але з-поміж усіх цих рішень очевидно, що найпопулярнішим є централізований підхід.
+
+### Чому ж централізований підхід такий популярний?
+
+- По-перше, i18next було першим рішенням, яке стало широко використовуваним, і воно слідувало філософії, запозиченій із PHP та Java-архітектур (MVC), які базуються на суворому розділенні обов'язків (триманні контенту окремо від коду). Воно з'явилося в 2011 році, встановивши свої стандарти ще до масового переходу до архітектур на основі компонентів (наприклад, React).
+- Далі, коли бібліотека широко прийнята, змінити екосистему на інші патерни стає складно.
+- Використання централізованого підходу також спрощує роботу в Translation Management Systems, таких як Crowdin, Phrase або Localized.
+- Логіка підходу per-component складніша за централізований і вимагає додаткового часу на розробку, особливо коли потрібно вирішувати задачі на кшталт визначення місця розташування контенту.
+
+### Добре, але чому б просто не дотримуватися централізованого підходу?
+
+Дозвольте пояснити, чому це може бути проблематично для вашого додатка:
+
+- **Невикористані дані:**
+  Коли завантажується сторінка, часто підвантажується контент з усіх інших сторінок. (У додатку з 10 сторінок це означає 90% невикористаного контенту.) Відкриваєте модальне вікно з відкладеним завантаженням? Бібліотека i18n байдуже — вона все одно спочатку підвантажує рядки.
+- **Продуктивність:**
+  При кожному перерендері кожен ваш компонент отримує велике JSON-навантаження, що погіршує реактивність додатка в міру його зростання.
+- **Підтримка:**
+  Підтримка великих JSON-файлів болюча. Потрібно переходити між файлами, щоб додати переклад, переконуючись, що не бракує перекладів і не залишилося **orphan keys**.
+- **Дизайн-система:**
+  Воно створює несумісність із дизайн-системами (наприклад, компонентом `LoginForm`) і обмежує дублювання компонентів між різними додатками.
+
+**"Але ми винайшли Namespaces!"**
+
+Звісно, і це величезний крок уперед. Погляньмо на порівняння розміру основного бандла для налаштування Vite + React + React Router v7 + Intlayer. Ми змоделювали 20-сторінковий додаток.
+
+Перший приклад не включає lazy-loaded переклади за локалями і не використовує розбиття на неймспейси. Другий включає content purging + динамічне завантаження перекладів.
+
+| Оптимізований бандл                                                                                                        | Бандл без оптимізації                                                                                    |
+| -------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------- |
+| ![неоптимізований бандл](https://github.com/aymericzip/intlayer/blob/main/docs/assets/bundle_no_optimization.png?raw=true) | ![оптимізований бандл](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/uk/i18n_using_next-i18next.md), щоб побачити виклики, які становить (лише) дотримання найкращих практик).
+Внаслідок цього ті проєкти опиняються з проблемою масивного завантаження JSON, описаною раніше.
+
+> Зверніть увагу, що ця проблема не є специфічною для i18next, а характерна для всіх централізованих підходів, перелічених вище.
+
+Проте хочу нагадати, що не всі гранулярні підходи вирішують цю проблему. Наприклад, підходи `vue-i18n SFC` або `inlang` за замовчуванням не виконують відкладене завантаження перекладів за локалями (lazy load), тому ви просто замінюєте проблему розміру бандла на іншу.
+
+Більше того, без належного розділення обов'язків (separation of concerns) стає значно складніше витягувати та надавати ваші переклади перекладачам для перегляду.
+
+### Як підхід Intlayer на рівні компонентів вирішує це
+
+Intlayer виконує кілька кроків:
+
+1. **Declaration:** Оголосіть ваш контент будь-де у кодовій базі, використовуючи файли `*.content.{ts|jsx|cjs|json|json5|...}`. Це забезпечує розділення обов'язків, зберігаючи контент поруч із компонентами. Файл контенту може бути на одну локаль або мультимовним.
+2. **Опрацювання:** Intlayer запускає крок збірки для обробки JS-логіки, обробки fallback-значень для відсутніх перекладів, генерації типів 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({
+    uk: { title: "Мій заголовок" },
+    en: { title: "My title" },
+    fr: { title: "Mon titre" }
+  })
+}
+
+```
+
+**Опрацювання:** Intlayer будує словник на основі файлу `.content` та генерує:
+
+```json5
+// .intlayer/dynamic_dictionary/en/my-key.json
+{
+  "key": "my-key",
+  "content": { "title": "My title" },
+}
+```
+
+**Заміна:** Intlayer перетворює ваш компонент під час збірки застосунку.
+
+**- Режим статичного імпорту:**
+
+```tsx
+// Представлення компонента у синтаксисі, подібному до JSX
+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>;
+};
+```
+
+**- Режим динамічного імпорту:**
+
+```tsx
+// Представлення компонента у синтаксисі, подібному до JSX
+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 лише за потреби.
+
+**Ключові переваги цього компонентного підходу:**
+
+- Тримання оголошення контенту поруч із компонентами забезпечує кращу підтримуваність (наприклад, при переміщенні компонентів до іншого app або design system. Видалення папки компонента також видаляє пов'язаний контент, як ви, ймовірно, вже робите для ваших `.test`, `.stories`)
+
+- Підхід на рівні компоненту запобігає необхідності AI-агентам переходити по всіх ваших різних файлах. Він обробляє всі переклади в одному місці, зменшуючи складність завдання та кількість використовуваних токенів.
+
+### Обмеження
+
+Звісно, цей підхід має свої компроміси:
+
+- Важче підключатися до інших l10n-систем та додаткових інструментів.
+- Ви потрапляєте у залежність (що, по суті, вже відбувається з будь-яким i18n-рішенням через їхній специфічний синтаксис).
+
+Саме тому Intlayer намагається надати повний набір інструментів для i18n (100% безкоштовний і з відкритим вихідним кодом — OSS), включно з AI-перекладом за допомогою вашого власного AI-провайдера та API-ключів. Intlayer також надає інструменти для синхронізації ваших JSON-файлів, що працюють подібно до message formatters ICU / vue-i18n / i18next, щоб відобразити контент у їхніх специфічних форматах.

package/blog/vi/per-component_vs_centralized_i18n.md

@@ -0,0 +1,246 @@
+---
+createdAt: 2025-09-10
+updatedAt: 2025-09-10
+title: i18n theo thành phần so với i18n tập trung: Một cách tiếp cận mới với Intlayer
+description: Phân tích sâu các chiến lược quốc tế hóa trong React, so sánh các phương pháp tập trung, theo khóa và theo thành phần, và giới thiệu Intlayer.
+keywords:
+  - i18n
+  - React
+  - Quốc tế hóa
+  - Intlayer
+  - Tối ưu hóa
+  - Kích thước bundle
+slugs:
+  - blog
+  - per-component-vs-centralized-i18n
+---
+
+# i18n theo thành phần so với i18n tập trung
+
+Cách tiếp cận theo thành phần không phải là một khái niệm mới. Ví dụ, trong hệ sinh thái Vue, `vue-i18n` hỗ trợ [i18n SFC (Single File Component)](https://vue-i18n.intlify.dev/guide/advanced/sfc.html). Nuxt cũng cung cấp [bản dịch theo thành phần](https://i18n.nuxtjs.org/docs/guide/per-component-translations), và Angular sử dụng một mẫu tương tự thông qua [Feature Modules](https://v17.angular.io/guide/feature-modules) của nó.
+
+Ngay cả trong một ứng dụng Flutter, chúng ta thường thấy mẫu sau:
+
+```bash
+lib/
+└── features/
+    └── login/
+        ├── login_screen.dart
+        └── login_screen.i18n.dart  # <- Các bản dịch nằm ở đây
+```
+
+```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);
+}
+```
+
+Tuy nhiên, trong thế giới React, chúng ta chủ yếu thấy các cách tiếp cận khác nhau, mà tôi sẽ gom thành ba loại:
+
+<Columns>
+  <Column>
+
+**Cách tiếp cận tập trung** (i18next, next-intl, react-intl, lingui)
+
+- (không có namespaces) coi một nguồn duy nhất để truy xuất nội dung. Theo mặc định, bạn tải nội dung từ tất cả các trang khi ứng dụng của bạn tải.
+
+  </Column>
+  <Column>
+
+**Tiếp cận chi tiết** (intlayer, inlang)
+
+- phân nhỏ việc truy xuất nội dung theo key, hoặc theo component.
+
+  </Column>
+</Columns>
+
+> Trong blog này, tôi sẽ không tập trung vào các giải pháp dựa trên compiler, những cái tôi đã đề cập ở đây: [Compiler vs Declarative i18n](https://github.com/aymericzip/intlayer/blob/main/docs/blog/vi/compiler_vs_declarative_i18n.md).
+> Lưu ý rằng i18n dựa trên compiler (ví dụ: Lingui) chỉ đơn giản tự động hóa việc trích xuất và tải nội dung. Về bản chất, chúng thường chia sẻ những hạn chế tương tự với các phương pháp khác.
+
+> Lưu ý rằng càng phân nhỏ cách bạn truy xuất nội dung, bạn càng có nguy cơ đưa thêm trạng thái và logic vào các component.
+
+Granular approaches are more flexible than centralized ones, but it's often a tradeoff. Even if "tree shaking" is advertised by that libraries, in practice, you'll often end up loading a page in every language.
+
+So, broadly speaking, the decision breaks down like this:
+
+- Nếu ứng dụng của bạn có nhiều trang hơn số ngôn ngữ, bạn nên ưu tiên phương pháp granular.
+- Nếu bạn có nhiều ngôn ngữ hơn trang, bạn nên nghiêng về phương pháp tập trung.
+
+Tất nhiên, các tác giả thư viện nhận thức được những giới hạn này và cung cấp các cách khắc phục. Trong số đó: tách thành namespaces, tải động các file JSON (`await import()`), hoặc loại bỏ (purge) nội dung trong quá trình build.
+
+Đồng thời, bạn cần biết rằng khi bạn tải nội dung một cách động, bạn sẽ tạo thêm các yêu cầu tới server. Mỗi `useState` bổ sung hoặc hook đồng nghĩa với một yêu cầu server thêm.
+
+> Để khắc phục vấn đề này, Intlayer đề xuất gom nhiều định nghĩa nội dung dưới cùng một khóa; Intlayer sau đó sẽ hợp nhất những nội dung đó.
+
+Nhưng từ tất cả các giải pháp đó, rõ ràng rằng cách tiếp cận phổ biến nhất là cách tập trung.
+
+### Vậy tại sao phương pháp tập trung lại được ưa chuộng đến vậy?
+
+- Trước hết, i18next là giải pháp đầu tiên được sử dụng rộng rãi, theo triết lý lấy cảm hứng từ các kiến trúc PHP và Java (MVC), vốn dựa trên nguyên tắc tách biệt trách nhiệm nghiêm ngặt (giữ nội dung tách khỏi mã). Nó xuất hiện vào năm 2011, thiết lập các tiêu chuẩn của mình thậm chí trước cả khi có sự dịch chuyển mạnh mẽ sang kiến trúc dựa trên component (Component-Based Architectures) như React.
+- Sau đó, một khi một thư viện được chấp nhận rộng rãi, sẽ rất khó để chuyển cả hệ sinh thái sang các mô hình khác.
+- Việc sử dụng cách tiếp cận tập trung cũng khiến các công việc trong các hệ thống quản lý bản dịch như Crowdin, Phrase hoặc Localized trở nên dễ dàng hơn.
+- Logic đằng sau cách tiếp cận theo từng component phức tạp hơn so với cách tiếp cận tập trung và tốn thêm thời gian để phát triển, đặc biệt khi phải giải quyết các vấn đề như xác định nội dung nằm ở đâu.
+
+### Được, nhưng tại sao không chỉ gắn bó với cách tiếp cận tập trung?
+
+Hãy để tôi nói lý do điều đó có thể gây vấn đề cho ứng dụng của bạn:
+
+- **Dữ liệu không sử dụng:**
+  Khi một trang được tải, bạn thường tải luôn nội dung từ tất cả các trang khác. (Trong một ứng dụng 10 trang, đó là 90% nội dung bị tải nhưng không dùng). Bạn lazy-load một modal? Thư viện i18n cũng mặc kệ — nó vẫn tải các chuỗi lên trước.
+- **Hiệu năng:**
+  Mỗi lần re-render, từng component của bạn đều được hydrated với một payload JSON lớn, điều này ảnh hưởng đến tính phản ứng (reactivity) của app khi nó phát triển.
+- **Bảo trì:**
+  Quản lý các file JSON lớn rất đau đầu. Bạn phải nhảy giữa các file để chèn bản dịch, đảm bảo không thiếu bản dịch nào và không để lại các **khóa mồ côi (orphan keys)**.
+- **Hệ thống thiết kế:**
+  Điều đó tạo ra sự không tương thích với design systems (ví dụ: một component `LoginForm`) và hạn chế việc sao chép component giữa các ứng dụng khác nhau.
+
+**"Nhưng chúng ta đã phát minh ra Namespaces!"**
+
+Chắc chắn, và đó là một bước tiến lớn. Hãy xem so sánh kích thước main bundle của một cấu hình Vite + React + React Router v7 + Intlayer. Chúng tôi đã mô phỏng một ứng dụng 20 trang.
+
+Ví dụ đầu tiên không bao gồm việc lazy-load các bản dịch theo locale và không tách namespace. Ví dụ thứ hai bao gồm content purging + tải động các bản dịch.
+
+| Bundle tối ưu hóa                                                                                                         | Bundle không tối ưu hóa                                                                              |
+| ------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------- |
+| ![gói chưa được tối ưu](https://github.com/aymericzip/intlayer/blob/main/docs/assets/bundle_no_optimization.png?raw=true) | ![gói được tối ưu](https://github.com/aymericzip/intlayer/blob/main/docs/assets/bundle.png?raw=true) |
+
+Nhờ có namespaces, chúng ta đã chuyển từ cấu trúc này:
+
+```bash
+locale/
+├── en.json
+├── fr.json
+└── es.json
+```
+
+sang cấu trúc này:
+
+```bash
+locale/
+├── en/
+│   ├── common.json
+│   ├── navbar.json
+│   ├── footer.json
+│   ├── home.json
+│   └── about.json
+├── fr/
+│   └── ...
+└── es/
+    └── ...
+
+```
+
+Bây giờ bạn phải quản lý một cách chi tiết phần nội dung nào của ứng dụng nên được tải và ở đâu. Kết luận là đại đa số các dự án chỉ bỏ qua phần này vì tính phức tạp (xem hướng dẫn [next-i18next](https://github.com/aymericzip/intlayer/blob/main/docs/blog/vi/i18n_using_next-i18next.md) để thấy các thách thức mà việc (chỉ) tuân theo các best practices mang lại).
+Do đó, các dự án đó cuối cùng gặp phải vấn đề tải JSON khổng lồ đã được giải thích ở phần trước.
+
+> Lưu ý rằng vấn đề này không đặc thù cho i18next, mà áp dụng cho tất cả các phương pháp tập trung được liệt kê ở trên.
+
+Tuy nhiên, tôi muốn nhắc bạn rằng không phải mọi cách tiếp cận theo hướng phân mảnh đều giải quyết được vấn đề này. Ví dụ, các cách tiếp cận như `vue-i18n SFC` hay `inlang` không tự động lazy load bản dịch theo từng locale, nên bạn chỉ đang đánh đổi vấn đề kích thước bundle này sang một vấn đề khác.
+
+Hơn nữa, nếu không tách biệt rõ ràng các mối quan tâm (separation of concerns), việc trích xuất và cung cấp bản dịch cho người dịch để họ xem xét sẽ trở nên khó khăn hơn nhiều.
+
+### Cách tiếp cận per-component của Intlayer giải quyết vấn đề này
+
+Intlayer thực hiện theo một số bước:
+
+1. **Khai báo:** Khai báo nội dung ở bất kỳ đâu trong codebase của bạn bằng các file `*.content.{ts|jsx|cjs|json|json5|...}`. Điều này đảm bảo tách biệt các mối quan tâm trong khi vẫn giữ nội dung được colocated. Một file nội dung có thể là theo từng locale hoặc đa ngôn ngữ.
+2. **Xử lý:** Intlayer thực hiện một bước build để xử lý logic JS, xử lý các fallback cho bản dịch bị thiếu, sinh các kiểu TypeScript, quản lý nội dung trùng lặp, lấy nội dung từ CMS của bạn, và nhiều thứ khác.
+3. **Thanh lọc:** Khi ứng dụng của bạn được build, Intlayer sẽ loại bỏ nội dung không dùng (tương tự cách Tailwind quản lý các class) bằng cách thay thế nội dung như sau:
+
+**Khai báo:**
+
+```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({
+    en: { title: "My title" },
+    fr: { title: "Mon titre" }
+  })
+}
+
+```
+
+**Xử lý:** Intlayer xây dựng dictionary dựa trên file `.content` và sinh ra:
+
+```json5
+// .intlayer/dynamic_dictionary/en/my-key.json
+{
+  "key": "my-key",
+  "content": { "title": "My title" },
+}
+```
+
+**Thay thế:** Intlayer biến đổi component của bạn trong quá trình build ứng dụng.
+
+**- Chế độ Import Tĩnh:**
+
+```tsx
+// Biểu diễn component theo cú pháp tương tự JSX
+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>;
+};
+```
+
+**- Chế độ Import Động:**
+
+```tsx
+// Biểu diễn component theo cú pháp tương tự JSX
+export const MyComponent = () => {
+  const content = useDictionaryAsync({
+    en: () =>
+      import(".intlayer/dynamic_dictionary/en/my-key.json", {
+        with: { type: "json" },
+      }).then((mod) => mod.default),
+    // Tương tự cho các ngôn ngữ khác
+  });
+
+  return <h1>{content.title}</h1>;
+};
+```
+
+> `useDictionaryAsync` sử dụng cơ chế giống Suspense để chỉ tải JSON đã được địa phương hóa khi cần.
+
+**Lợi ích chính của cách tiếp cận theo thành phần này:**
+
+- Giữ khai báo nội dung gần với các components của bạn giúp việc bảo trì tốt hơn (ví dụ: di chuyển một component sang một app hoặc design system khác. Xóa thư mục component sẽ xóa luôn nội dung liên quan, giống như bạn có lẽ vẫn làm với các file `.test`, `.stories`)
+
+- Cách tiếp cận theo từng component ngăn các agent AI phải lục qua tất cả các file khác nhau của bạn. Nó xử lý tất cả các bản dịch tại một chỗ, giảm độ phức tạp của nhiệm vụ và lượng token sử dụng.
+
+### Hạn chế
+
+Tất nhiên, cách tiếp cận này đi kèm với những đánh đổi:
+
+- Khó kết nối với các hệ thống l10n khác và các tooling bổ sung.
+- Bạn có nguy cơ bị lock-in (điều này cơ bản đã xảy ra với bất kỳ giải pháp i18n nào do cú pháp đặc thù của chúng).
+
+Đó là lý do Intlayer cố gắng cung cấp một bộ công cụ hoàn chỉnh cho i18n (100% miễn phí và OSS), bao gồm dịch AI sử dụng AI Provider và API keys của riêng bạn. Intlayer cũng cung cấp công cụ để đồng bộ hóa JSON của bạn, hoạt động giống như các message formatter của ICU / vue-i18n / i18next để ánh xạ nội dung sang định dạng tương ứng.