@intlayer/docs 9.4.2 → 9.4.3

package/blog/uk/date_time_number_formatting_locales.md

@@ -0,0 +1,216 @@
+---
+createdAt: 2026-09-02
+updatedAt: 2026-09-02
+title: "Форматування дат і чисел за локалями за допомогою Intl"
+description: Вам, швидше за все, не потрібна окрема бібліотека форматування. Як Intl працює з датами, числами, валютами та списками, ціна кешування і баг із часовим поясом у продакшені.
+keywords:
+  - форматування дати за локаллю
+  - Intl.DateTimeFormat
+  - Intl.NumberFormat
+  - toLocaleDateString
+  - форматування валюти locale
+  - відносний час
+slugs:
+  - blog
+  - date-time-number-formatting-locales
+author: aymericzip
+---
+
+# Форматування дат і чисел за локалями за допомогою Intl
+
+Переклад текстових рядків — це лише видима половина інтернаціоналізації (i18n). Інша половина, яка регулярно генерує звіти про помилки, це форматування: німецький користувач бачить `1,234.56` замість `1.234,56`, японський користувач бачить `08/02/2026` і сприймає це як серпень, або дата по-різному рендериться на сервері та клієнті, спричиняючи помилку гідратації в React.
+
+Жодна з цих ситуацій не вимагає сторонніх бібліотек. Стандартний `Intl` присутній у кожному сучасному середовищі виконання JavaScript.
+
+## Зміст
+
+<TOC/>
+
+## Почніть із видалення самописних хелперів для дат
+
+Майже в кожній кодовій базі є функція `formatDate`, написана ще до того, як хтось задумався про підтримку локалей. Вона жорстко фіксує порядок відображення, роздільник і переважно англійські назви місяців.
+
+```ts
+// Код, який слід видалити:
+const formatDate = (d: Date) =>
+  `${d.getMonth() + 1}/${d.getDate()}/${d.getFullYear()}`;
+```
+
+`Intl.DateTimeFormat` повністю замінює її та забезпечує коректний результат для будь-якої локалі:
+
+```ts
+new Intl.DateTimeFormat("de-DE", { dateStyle: "long" }).format(date);
+// "2. August 2026"
+new Intl.DateTimeFormat("ja-JP", { dateStyle: "long" }).format(date);
+// "2026年8月2日"
+```
+
+Те саме стосується чисел. Виклик `toFixed(2)` повсюдно повертає `1234.56`, що є неправильним для більшості країн Європи.
+
+## Що охоплює `Intl`
+
+| API                       | Сфера застосування                                           |
+| :------------------------ | :----------------------------------------------------------- |
+| `Intl.DateTimeFormat`     | Дати та час із готовими пресетами `dateStyle` / `timeStyle`  |
+| `Intl.NumberFormat`       | Десяткові дроби, валюти, відсотки, одиниці, компактний запис |
+| `Intl.RelativeTimeFormat` | "3 дні тому", "через 2 години"                               |
+| `Intl.ListFormat`         | "а, б і в" згідно з граматикою мови                          |
+| `Intl.PluralRules`        | Визначення граматичної категорії множини для чисел           |
+| `Intl.Collator`           | Коректне алфавітне сортування рядків з урахуванням мови      |
+
+`Intl.Collator` часто несправедливо забувають. Звичайний `array.sort()` на рядках сортує за кодовими точками Unicode, через що літери з діакритикою опиняються після літери `z`, а шведська `ö` потрапляє не на своє місце. Якщо ви сортуєте видимі користувачам списки, завжди використовуйте collator.
+
+```ts
+["zebra", "édouard", "apple"].sort(new Intl.Collator("uk").compare);
+// ["apple", "édouard", "zebra"]
+```
+
+## Віддавайте перевагу пресетам замість ручного збирання параметрів
+
+Параметри `dateStyle` та `timeStyle` дозволяють самій локалі визначити прийнятний порядок полів та роздільники. Ручне вказування `year`, `month` та `day` надає контроль, якого краще уникати, оскільки правильний порядок змінюється залежно від регіону, і ви ризикуєте замінити дані CLDR власними хибними припущеннями.
+
+```ts
+// Локаль сама обирає правильну структуру:
+new Intl.DateTimeFormat(locale, { dateStyle: "medium" }).format(d);
+
+// Власноруч нав'язана структура, некоректна в інших країнах:
+new Intl.DateTimeFormat(locale, {
+  year: "numeric",
+  month: "2-digit",
+  day: "2-digit",
+}).format(d);
+```
+
+Задавайте складові явно лише тоді, коли дизайн безапеляційно вимагає фіксованої ширини, наприклад у вузькій колонці таблиці.
+
+## Створення форматерів є ресурсомістким
+
+Це ключовий нюанс продуктивності. Ініціалізація `Intl.NumberFormat` супроводжується завантаженням значного обсягу даних локалі, і цей процес набагато важчий за наступний виклик `.format()`. Виконання цієї операції всередині циклу рендерингу на тисячу рядків спричиняє відчутні затримки.
+
+```ts
+// Перестворює форматер на кожному рядку (повільно):
+rows.map((r) => new Intl.NumberFormat(locale).format(r.total));
+
+// Створюється один раз і перевикористовується (швидко):
+const nf = new Intl.NumberFormat(locale);
+rows.map((r) => nf.format(r.total));
+```
+
+Функції `toLocaleDateString()` та `toLocaleString()` містять ту саму приховану ваду: кожен виклик створює новий форматер. Вони підходять для поодиноких випадків, але непридатні для списків.
+
+Кешуйте форматери за комбінацією локалі та набору опцій:
+
+```ts
+const cache = new Map<string, Intl.NumberFormat>();
+
+const getNumberFormat = (
+  locale: string,
+  options: Intl.NumberFormatOptions = {}
+) => {
+  const key = `${locale}:${JSON.stringify(options)}`;
+  let formatter = cache.get(key);
+  if (!formatter) {
+    formatter = new Intl.NumberFormat(locale, options);
+    cache.set(key, formatter);
+  }
+  return formatter;
+};
+```
+
+## Баг із часовим поясом, що проявляється лише в продакшені
+
+Ця проблема забрала чимало годин у багатьох команд. Сервер формує дату під час SSR, браузер виконує гідратацію на клієнті, і React аварійно завершує роботу через помилку hydration mismatch, оскільки два середовища згенерували різний текст.
+
+Причина: `Intl.DateTimeFormat` використовує системний часовий пояс хоста, якщо ви не передали його явно. Сервер продакшену налаштовано на UTC, а комп'ютер розробника — на локальний пояс. Тому локально помилка не відтворюється і проявляється лише після викатки.
+
+```ts
+// Сервер в UTC і браузер в UTC+2 розходяться в результатах. Помилка гідратації:
+new Intl.DateTimeFormat(locale, { dateStyle: "short" }).format(d);
+
+// Обидві сторони повністю узгоджені:
+new Intl.DateTimeFormat(locale, { dateStyle: "short", timeZone: "UTC" }).format(
+  d
+);
+```
+
+Три робочі підходи:
+
+- **Зафіксувати часовий пояс** на сервері та передавати його явно. Надійно та передбачувано, але всі бачать час у форматі UTC.
+- **Рендерити виключно на клієнті**, показуючи нейтральний плейсхолдер під час SSR. Точно для кожного користувача, але викликає легке мерехтіння.
+- **Зберігати часовий пояс користувача** і передавати його на сервер та клієнт. Найкращий досвід, що вимагає дещо більше інфраструктурного коду.
+
+Хоч би який шлях ви обрали, завжди вказуйте `timeZone` явно для будь-якої дати, яка рендериться і на сервері, і на клієнті. Дата без зазначеного поясу — це дата з двома різними значеннями.
+
+## Валюта потребує коду валюти, а не локалі
+
+Локаль і валюта — незалежні речі. `fr-FR` не означає автоматично розрахунки в євро: французький користувач може переглядати інвойс у доларах США.
+
+```ts
+new Intl.NumberFormat("fr-FR", { style: "currency", currency: "USD" }).format(
+  1234.5
+);
+// "1 234,50 $US"
+```
+
+Локаль відповідає за роздільники, групування цифр та розміщення символу. Валюта береться з бізнес-даних операції. Спроба вивести одне з іншого призводить до бухгалтерських помилок.
+
+Зверніть увагу на параметр `currencyDisplay`. В інтерфейсах, де сусідують різні валюти зі знаком долара ($), значення `"code"` знімає будь-яку неоднозначність між американськими, канадськими та австралійськими доларами.
+
+## Відносний час сприймається легше за точну дату
+
+Для недавніх дій формулювання "2 години тому" набагато зручніше за сухий часовий штамп, і `Intl.RelativeTimeFormat` якісно це локалізує.
+
+```ts
+new Intl.RelativeTimeFormat("uk", { numeric: "auto" }).format(-1, "day");
+// "учора"
+```
+
+Параметр `numeric: "auto"` забезпечує виведення "учора" замість неприродного "1 день тому".
+
+## Що додає Intlayer
+
+Intlayer загортає ці можливості у легкі хелпери з автоматичним кешуванням, звільняючи від ручного контролю над Map, та автоматично застосовує активну локаль без потреби передавати її на кожному кроці.
+
+```ts
+import {
+  number,
+  currency,
+  date,
+  relativeTime,
+  units,
+  compact,
+  list,
+} from "intlayer";
+
+number(1234.5); // "1 234,5"
+currency(1234.5, { currency: "EUR" }); // "1 234,50 €"
+date(new Date(), "short");
+relativeTime(now, twoHoursAgo, { unit: "hour", numeric: "auto" }); // "2 години тому"
+units(5, { unit: "kilometer", unitDisplay: "long" }); // "5 кілометрів"
+compact(1200); // "1,2 тис."
+list(["яблуко", "банан", "апельсин"]); // "яблуко, банан і апельсин"
+```
+
+Функція `date()` також підтримує пресети (`"short"`, `"long"`, `"dateOnly"`, `"timeOnly"`, `"full"`). Для React та Vue доступні хуки й composables, які дістають активну локаль безпосередньо з контексту.
+
+Це зручний прошарок кешування та підтримки локалі за замовчуванням над стандартним API платформи. Сама поведінка форматування повністю спирається на `Intl`. Докладні сигнатури доступні в [документації форматерів](https://github.com/aymericzip/intlayer/blob/main/docs/docs/uk/formatters.md).
+
+## Поширені помилки
+
+- **Виклик `toLocaleDateString()` без вказування локалі.** Використовує локаль середовища хоста, яка на сервері залежить від контейнера.
+- **Форматування в циклі без кешування.** Створення форматера споживає більшість процесорного часу.
+- **Відсутність `timeZone` на ізоморфних датах.** Провокує помилки гідратації, які неможливо виявити локально.
+- **Виведення валюти з коду мови.** `fr-FR` не гарантує використання євро.
+- **Звичайний `sort()` для видимого тексту.** Завжди використовуйте `Intl.Collator`.
+- **Ручний хардкод назв місяців чи днів.** Усі вони вже зібрані в CLDR для кожної мови.
+- **Залишення `numeric: "always"` для відносного часу.** Призводить до "1 день тому" там, де є природне слово учора.
+
+## Корисні матеріали
+
+- [Форматери та утиліти локалей: `number`, `currency`, `date`, `relativeTime`, `list`](https://github.com/aymericzip/intlayer/blob/main/docs/docs/uk/formatters.md)
+- [Довідник конфігурації](https://github.com/aymericzip/intlayer/blob/main/docs/docs/uk/configuration.md)
+- [Звіти про продуктивність фреймворків](https://github.com/aymericzip/intlayer/blob/main/docs/docs/uk/benchmark/index.md)
+- [Адаптер сумісності react-intl](https://github.com/aymericzip/intlayer/blob/main/docs/docs/uk/compat/react-intl.md)
+- [Формат повідомлень ICU: множина, вибір та чисельні шаблони](https://github.com/aymericzip/intlayer/blob/main/docs/blog/uk/icu_message_format.md)
+- [Як тестувати переклади, включно з форматерами та множиною](https://github.com/aymericzip/intlayer/blob/main/docs/blog/uk/i18n_testing_strategies.md)
+- [Що насправді охоплює інтернаціоналізація](https://github.com/aymericzip/intlayer/blob/main/docs/blog/uk/what_is_internationalization.md)

package/blog/uk/detecting_missing_translations.md

@@ -0,0 +1,202 @@
+---
+createdAt: 2026-09-02
+updatedAt: 2026-09-02
+title: "Як виявляти відсутні переклади раніше, ніж це зроблять ваші користувачі"
+description: Відсутні переклади викликають збої без жодних повідомлень. Чому фолбек приховує їх, які чотири рівні виявлення дійсно працюють і як ламати збірку на неперекладених ключах.
+keywords:
+  - знайти відсутні переклади
+  - відсутні ключі перекладу
+  - аудит i18n
+  - неперекладені рядки
+  - покриття перекладів
+  - i18n lint
+slugs:
+  - blog
+  - detecting-missing-translations
+author: aymericzip
+---
+
+# Як виявляти відсутні переклади раніше, ніж це зроблять ваші користувачі
+
+Відсутній переклад майже ніколи не викликає виняткових ситуацій у додатку. Залежно від вашої конфігурації, він або покаже англійський текст користувачеві в Японії, або виведе `checkout.summary.total` прямо на робочій сторінці в продакшені. Обидва випадки потрапляють у реліз, проходять код-рев'ю і виявляються клієнтом, а не вами.
+
+## Зміст
+
+<TOC/>
+
+## Це працює незалежно від бібліотеки, яку ви використовуєте
+
+Жодна порада тут не прив'язана до одного конкретного стеку. Описані нижче рівні виявлення функціонують однаково в i18next, react-i18next, next-intl, react-intl, vue-i18n, next-translate або Lingui, оскільки всі вони розв'язують ключі за однаковим принципом і зазнають збоїв аналогічно.
+
+Інструменти також портативні. Якщо ваші тексти зараз зберігаються в каталогах JSON, [плагін Sync JSON](https://github.com/aymericzip/intlayer/blob/main/docs/docs/uk/plugins/sync-json.md) підключає Intlayer до цих файлів, надаючи команди аудиту, заповнення та тестування без переміщення контенту і без зміни жодного імпорту:
+
+```ts fileName="intlayer.config.ts"
+import { syncJSON } from "@intlayer/sync-json-plugin";
+
+const config = {
+  plugins: [
+    syncJSON({
+      source: ({ key, locale }) => `./locales/${locale}/${key}.json`,
+      format: "i18next", // або "icu" для next-intl / react-intl
+    }),
+  ],
+};
+
+export default config;
+```
+
+Якщо ви бажаєте зберегти runtime API незмінним, [адаптери сумісності](https://github.com/aymericzip/intlayer/blob/main/docs/docs/uk/compat/index.md) створюють аліаси для `useTranslation`, `$t` тощо на рівні збирача пакетів. У будь-якому разі сприймайте наведені нижче команди як конкретну реалізацію ідеї, а не як непохитну вимогу.
+
+## Чому прогалини залишаються непомітними
+
+Кожна бібліотека i18n розв'язує ключ через один і той самий ланцюжок: знайти в активній локалі, відкотитися до типової локалі (fallback), а якщо це не вдалося — повернути сам строковий ключ. Саме цей останній крок створює проблему. Немає помилки, немає попередження на продакшені та немає провалених тестів, оскільки жодна ланка пайплайну не вважає відсутність перекладу аномалією.
+
+Фолбек лише погіршує ситуацію замість того, щоб допомагати. Сторінка, яка мовчки відрендерилася англійською мовою, виглядає цілком нормально для англомовного розробника та для будь-якої автоматизованої перевірки. Проблема помітна лише тій людині, яка не розуміє цього тексту.
+
+Тому питання полягає не в тому, "як обробляти відсутні переклади під час виконання". А в тому, "як зробити злиття коду з відсутнім перекладом принципово неможливим".
+
+## Чотири рівні, на яких їх можна перехопити
+
+Кожен рівень ловить те, що інші пропускають. Доцільно поєднувати декілька рівнів.
+
+| Рівень        | Що знаходить                                    | Що пропускає                                                |
+| :------------ | :---------------------------------------------- | :---------------------------------------------------------- |
+| Типи          | Ключі, яких взагалі не існує                    | Ключ існує, але не має значення в `ja`                      |
+| Лінтер        | Захардкоджені рядки, які ніколи не виносилися   | Ключі, відсутні в конкретному каталозі                      |
+| Аудит         | Покриття локалями кожного оголошеного ключа     | Текст, який взагалі ніколи не робили доступним до перекладу |
+| Тести рендеру | Ключі, які розв'язуються, але рендеряться хибно | Все, що не покрите тестами                                  |
+
+Найчастіша прогалина в командах — це третій рядок: розробники знають, що їхні ключі коректні за типами, але жоден інструмент не перевіряє наявність реального значення в кожній із вісімнадцяти мов.
+
+## Рівень 1: зробіть ключ типом, а не звичайним рядком
+
+`t("checkout.summry.total")` — це одрук, який без проблем компілюється. Якщо ваші ключі — прості рядки, кожне перейменування несе ризик у продакшені, а кожне видалення залишає ключі-сироти.
+
+Типізовані ключі перетворюють це на помилку збірки. `react-i18next` підтримує це через declaration merging, `next-intl` виводить типи зі структури повідомлень, Lingui генерує ідентифікатори з тексту джерела, а Intlayer генерує суворі типи з файлів оголошення контенту. Усі варіанти працюють; різниця полягає лише в обсязі налаштувань.
+
+Цей рівень є необхідним, але недостатнім. Типи описують структуру вашого типового каталогу. Вони нічого не кажуть про те, чи є в корейській локалі значення для цього ключа.
+
+## Рівень 2: лінтинг рядків, які так і не стали ключами
+
+Переклад, який ви не можете знайти, часто є тим, який ніколи не виносився в словники. Захардкоджений напис у компоненті невидимий для будь-якого аудиту каталогів, тому що для інструментів цього рядка просто не існує.
+
+Плагін ESLint для Intlayer вирішує це правилом `no-raw-text`, доповненим правилом `no-unused-content` для зворотної ситуації: контент оголошено, але він більше ніде не використовується.
+
+```js fileName="eslint.config.mjs"
+import intlayer from "@intlayer/eslint-plugin";
+
+export default [
+  intlayer.configs.recommended,
+  {
+    rules: {
+      "@intlayer/no-raw-text": "error",
+      "@intlayer/no-unused-content": "warn",
+    },
+  },
+];
+```
+
+`no-unused-content` оберігає каталоги від безкінечного розростання. Мертві ключі не ламають роботу програми, але необґрунтовано збільшують рахунки від бюро перекладів. Повний перелік правил наведено в [документації до плагіна ESLint](https://github.com/aymericzip/intlayer/blob/main/docs/docs/uk/eslint.md).
+
+## Рівень 3: аудит покриття локалей
+
+Це той самий рівень, який відповідає на головне запитання. Intlayer постачає його як команду CLI:
+
+```bash packageManager="npm"
+npx intlayer content test
+```
+
+Вона зчитує налаштовані локалі та оголошені словники, а потім детально звітує, яким ключам бракує яких мов і в якому файлі.
+
+Важлива деталь перед тим, як вбудовувати команду в пайплайни: **CLI виводить звіт, але завжди завершується з кодом 0.** Якщо ви додасте її в надії зламати збірку, ви отримаєте зелений білд із довгим списком у логах, який ніхто не прочитає. Для зупинки збірки використовуйте програмний API, описаний нижче.
+
+## Рівень 4: перевірка через assertions у тестовому наборі
+
+`listMissingTranslations()` повертає той самий аудит у вигляді об'єкта даних, що ідеально підходить для створення блокувального бар'єра збірки (build gate).
+
+```ts fileName="i18n.test.ts"
+/* @vitest-environment node */
+import { listMissingTranslations } from "intlayer/cli";
+import { describe, expect, it } from "vitest";
+
+describe("translations", () => {
+  it("has no missing required locales", async () => {
+    const result = await listMissingTranslations();
+
+    if (result.missingRequiredLocales.length > 0) {
+      console.log(result.missingTranslations);
+    }
+
+    expect(result.missingRequiredLocales).toHaveLength(0);
+  });
+});
+```
+
+Повертаються три поля з чітким розмежуванням:
+
+- `missingTranslations`: за кожним ключем вказано, яких саме мов бракує та з якого файлу. Це друкується у разі провалу тесту.
+- `missingLocales`: об'єднання всіх відсутніх мов за всіма ключами.
+- `missingRequiredLocales`: обмежено лише параметром `requiredLocales` у вашій конфігурації (або всіма локалями, якщо параметр не було задано).
+
+## `requiredLocales` робить перевірку життєздатною
+
+Підтримка вісімнадцяти мов не означає, що всі вісімнадцять мають бути готові на 100% для виконання деплою. Більшість команд поділяють мови на критичний рівень, що блокує реліз, та рівень, який доповнюється поступово.
+
+```ts fileName="intlayer.config.ts"
+import { Locales, type IntlayerConfig } from "intlayer";
+
+const config: IntlayerConfig = {
+  internationalization: {
+    locales: [
+      Locales.ENGLISH,
+      Locales.FRENCH,
+      Locales.JAPANESE,
+      Locales.POLISH,
+    ],
+    requiredLocales: [Locales.ENGLISH, Locales.FRENCH],
+    defaultLocale: Locales.ENGLISH,
+  },
+};
+
+export default config;
+```
+
+Без `requiredLocales` кожна оголошена локаль стає суворо обов'язковою, і збірка лишатиметься червоною, доки не з'явиться останній переклад. Це найчастіше призводить до того, що команди повністю вимикають цю перевірку.
+
+## Пошук прогалин, які вже потрапили в продакшен
+
+Описані рівні запобігають появі нових прогалин. Для додатка, який уже працює на продакшені, допомагають два підходи.
+
+**Псевдолокалізація.** Запустіть тестову локаль, де кожен рядок трансформується, наприклад `[!!! Ĉĥéçķöũţ !!!]`. Усе, що продовжує відображатися звичайною англійською, захардкоджене в коді. Це дозволяє за десять хвилин виявити те, чого аудит каталогів принципово не здатний помітити.
+
+**Краулінг власного сайту.** Якщо у вас локалізовані URL, завантажте вибірку сторінок для кожної мови та виконайте пошук рядків типової мови в HTML. Сторінка за адресою `/ja/`, що містить фразу "Add to cart", вказує або на відсутній переклад, або на неочікуваний фолбек.
+
+```bash
+curl -s https://example.com/ja/checkout | grep -c "Add to cart"
+```
+
+## Заповнення прогалин
+
+Коли ви знаєте, чого саме не вистачає, команда `intlayer fill` заповнює порожні поля, а опція `autoFill` може генерувати файли для кожної локалі безпосередньо під час створення контенту. Див. [autoFill](https://github.com/aymericzip/intlayer/blob/main/docs/docs/uk/autoFill.md).
+
+Слід усвідомлювати: автоматичне машинне заповнення перетворює _видиму_ прогалину на _невидиму_. Ключ отримав значення, аудит стає зеленим, але текст ще ніхто з людей не вичитував. Використовуйте це для розблокування релізу, але обов'язково передавайте критичні тексти на перевірку людині перед показом клієнтам. Це допоміжний каркас, а не остаточна відповідь.
+
+## Поширені помилки
+
+- **Сприймати фолбек як захисний механізм.** Це спосіб аварійного рендерингу, а не страховка. Сторінка, яка тихо показує англійський текст — це непомічена помилка.
+- **Покладатися на звіт CLI для блокування CI.** `intlayer content test` завершується з кодом нуль. Використовуйте assertion у тестах.
+- **Вимагати стовідсоткової присутності кожної локалі.** Перевірку видалять, щойно вона заблокує терміновий реліз.
+- **Аудит лише каталогів без перевірки реального екрана.** Захардкоджені рядки не можуть бути знайдені в каталозі за визначенням.
+- **Тестування виключно типової локалі.** Єдина локаль, яка гарантовано ніколи не буде відсутня.
+- **Зупинка процесу на машинному заповненні.** Зелений аудит без жодної перевірки якості тексту.
+
+## Корисні посилання
+
+- [Тестування вашого контенту: аудит CLI, програмний API та UI-асерти](https://github.com/aymericzip/intlayer/blob/main/docs/docs/uk/testing.md)
+- [Правила плагіна ESLint, включно з `no-raw-text` та `no-unused-content`](https://github.com/aymericzip/intlayer/blob/main/docs/docs/uk/eslint.md)
+- [autoFill: створення файлів декларацій для кожної локалі](https://github.com/aymericzip/intlayer/blob/main/docs/docs/uk/autoFill.md)
+- [Довідник конфігурації: `locales`, `requiredLocales`, `defaultLocale`](https://github.com/aymericzip/intlayer/blob/main/docs/docs/uk/configuration.md)
+- [Звіти про продуктивність між різними фреймворками](https://github.com/aymericzip/intlayer/blob/main/docs/docs/uk/benchmark/index.md)
+- [Адаптер сумісності з i18next](https://github.com/aymericzip/intlayer/blob/main/docs/docs/uk/compat/i18next.md)
+- [Що насправді охоплює інтернаціоналізація](https://github.com/aymericzip/intlayer/blob/main/docs/blog/uk/what_is_internationalization.md)
+- [Компонентна i18n проти централізованої](https://github.com/aymericzip/intlayer/blob/main/docs/blog/uk/per-component_vs_centralized_i18n.md)