Я часто вижу, как разработчики испытывают трудности с i18next. И действительно, это технология интернационализации, которую нелегко освоить.

Несмотря на это, i18next остаётся решением по умолчанию, которое ChatGPT рекомендует для внедрения i18n. Мы слишком часто попадаемся на удочку страниц «Get Started» (да, оно работает, но действительно ли это сделано правильно?).

На практике я замечаю, что многие проекты пропускают самые критичные аспекты интернационализации, особенно связанные с SEO: перевод метаданных, теги hreflang, локализация ссылок, настройка sitemap и robots.txt.

Что ещё хуже, почти половина проектов, использующих i18next (особенно после роста популярности ИИ), не структурируют контент по неймспейсам или же загружают все неймспейсы при каждом запросе.

Последствия? Вы можете заставлять каждого пользователя загружать контент всех страниц на всех языках, даже если он посещает только одну страницу. Например: при 10 страницах и 10 языках 99% загружаемого контента никогда не будет использовано. Совет: используйте анализатор бандла, чтобы выявить это.

Чтобы решить проблему, я подготовил руководство о том, как правильно интернационализировать приложение Next.js 16 с i18next в 2025 году.

Вот ссылка: https://intlayer.org/ru/blog/nextjs-internationalization-using-next-i18next

Next.js i18n битва: next-intl vs next-i18next vs Intlayer
Добавление нескольких языков в приложение Next.js может быть сложным: большие JSON-файлы, отсутствующие переводы, запутанная конфигурация.
Вот краткий обзор:
next-intl – лёгкий, простой, отлично подходит для небольших проектов.
next-i18next – функционально богатый, много плагинов, но требует больше настроек и поддержки.
Intlayer – современное решение для Next.js: контент на уровне компонентов, безопасность TypeScript, проверки на этапе сборки, SEO-помощники и опциональный визуальный редактор.
Если вы хотите масштабируемую, модульную и безопасную i18n для ваших Next.js 13+ приложений, Intlayer стоит попробовать.
📖 Полное сравнение здесь: https://intlayer.org/blog/next-i18next-vs-next-intl-vs-intlayer

Хватит fine-tuning. Просто постройте RAG-пайплайн.

Я всё чаще вижу, как люди делают fine-tuning LLM под задачи, где это вообще не нужно.
В большинстве случаев вам не нужен очередной «наполовину дообученный» модельный франкенштейн — вам нужен RAG (Retrieval-Augmented Generation).

Почему:

• Fine-tuning дорогой, медленный и хрупкий.

• В большинстве кейсов не нужно «учить» модель — достаточно дать правильный контекст.

• С RAG модель всегда актуальна: обновили документацию → обновили эмбеддинги → готово.

Чтобы доказать это, я собрал ассистента по документации на RAG:

• Документация режется на чанки и эмбеддится

• Запросы пользователей матчатся через косинусное сходство

• GPT отвечает с нужным контекстом

• Каждый запрос логируется → вы видите, с чем юзеры сталкиваются (пробелы в доках, запросы фич, инсайты по продукту)

👉 Живое демо: intlayer.org/doc/chat
👉 Полный разбор + код + шаблон: intlayer.org/blog/rag-powered-documentation-assistant

Моё мнение:
Для большинства задач с документацией и продуктом fine-tuning мёртв.
RAG проще, дешевле и куда более поддерживаемый.

Но, может быть, я не прав. Что думаете?
Есть ли будущее у связки fine-tuning + RAG, или RAG — очевидное решение для 80% кейсов?

P.S.: это перевод поста с английского на русский при помощи ChatGPT.

Заголовок: Я переписал react-query | Легковесный хук для асинхронного получения данных и кэширования в React

Привет всем!

Я разработал легковесный React-хук, аналогичный React Query, с основными функциями: получение данных, кэширование, повторные попытки и др. Он компактнее и проще в настройке. Полный код доступен на GitHub и в npm как api-refetch.

Зачем создавать собственный хук?

1. Легковесность: React Query и SWR мощные, но крупные. Мой хук идеален, когда важен размер пакета, особенно для зависимостей вроде Intlayer.

2. Настройка и оптимизация: Возможность хранения данных в локальном хранилище и управления параллельными запросами. Копируя или клонируя код, можно удалить ненужные функции, уменьшив размер бандла и повысив производительность.

3. Без провайдера: Избегаю использования Context Provider для глобального доступа, предлагая версию на базе Zustand.

4. Учебное упражнение: Понимание внутренностей кэширования и управления состоянием.

Создание собственного хука позволило сосредоточиться на нужных функциях, сохраняя библиотеку маленькой и понятной.

Функции

• Получение данных и управление состоянием: Загрузка, ошибки, успешные данные.

• Кэширование и хранение: Через React или Zustand, поддержка локального хранилища.

• Повторные попытки и валидация: Настраиваемые лимиты и интервалы.

• Активация и инвалидизация: Управление запросами в зависимости от других данных.

• Параллельные запросы: Предотвращение дублирования запросов при монтировании нескольких компонентов.

Пример использования

Установка

Клонируйте репозиторий или установите через npm:

npm install api-refetch

Быстрый пример

import { AsyncStateProvider, useAsync } from "api-refetch";

function App() {
  return (
    <AsyncStateProvider>
      <UserDetails />
    </AsyncStateProvider>
  );
}

const fetchUserData = async () => {
  return new Promise((resolve) => {
    setTimeout(() => {
      resolve({ name: "John Doe" });
    }, 1000);
  });
};

const UserDetails = () => {
  const { isLoading, data, error, revalidate } = useAsync(
    "userDetails",
    fetchUserData,
    {
      enable: true,
      cache: true,
      store: true,
      retryLimit: 3,
      retryTime: 10000,
      autoFetch: true,
      revalidation: true,
      revalidateTime: 300000,
      onSuccess: (data) => console.log("Данные получены:", data),
      onError: (error) => console.error("Ошибка:", error),
    }
  );

  if (isLoading) return <div>Загрузка...</div>;
  if (error) return <div>Ошибка: {error}</div>;
  return (
    <div>
      <h1>{data?.name}</h1>
      <button onClick={revalidate}>Обновить</button>
    </div>
  );
};

Попробуйте api-refetch, сообщите об ошибках или внесите вклад. Обратная связь приветствуется!

GitHub: api-refetch

Счастливого кодинга!