Когда Next.js перешел с Pages Router на App Router и убрал встроенную поддержку i18n‑роутинга, библиотека next-intl стала стандартом по умолчанию для большинства команд. Ян Аманн проделал отличную работу по ее поддержке, и долгое время это был самый надежный выбор для мультиязычных проектов.
Всем привет!
Долго я возился с маркдауном в своих проектах и, честно говоря, знатно подгорел. Первая проблема — это вечный выбор библиотеки.
С одной стороны, есть «конструкторы» типа unified, remark и rehype. Штуки мощные, но настраивать весь этот AST‑конвейер и систему плагинов — это какой‑то оверхед и лишняя сложность, имхо.
С другой стороны, есть @next/mdx, который вроде и ок, но слишком завязан на страницах и вообще не умеет работать на клиенте.
Раньше я обычно выбирал что‑то вроде markdown‑to‑jsx или react‑markdown.
DX у них приятнее, работают и на клиенте, и на сервере, весят мало.
Но вот беда: они «из коробки» не переваривают HTML или MDX, и ты снова вязнешь в настройке плагинов. А если добавить туда i18n (типа i18next или next‑intl), начинается настоящий ад. Куча if/else в коде, чтобы отрендерить нужный язык, и бандл раздувается до небес. Плюс вечные косяки с front‑matter. Ну и до недавнего времени всё это было только для React.
В общем, решил я написать свое решение для intlayer. Чтобы просто работало.
Недавно я перенёс Intlayer (решение для i18n) — монорепозиторий, состоящий из нескольких приложений (Next.js, Vite, React, design-system и т. д.) — с pnpm на Bun.
Кратко (TL;DR): если бы я знал заранее, я бы, вероятно, не делал этого.
Я думал, что это займёт пару часов. В итоге ушло около 20 часов.
Меня привлекло обещание «всё в одном» и впечатляющие показатели производительности.
Я попробовал, я собрал — всё билдилось молниеносно, круто.
Затем я сделал коммит… и столкнулся с первой проблемой.
Всем привет! Хочу поделиться своим подходом к созданию чат-бота с функцией «умной документации» для проекта, над которым я работаю. **Я не являюсь экспертом в области ИИ, поэтому любые предложения и улучшения приветствуются!**
Цель этой статьи — **не** создавать очередной туториал по сборке чат-бота с OpenAI. Таких материалов уже достаточно.
Вместо этого я расскажу, как **индексировать документацию**, разделив её на **удобоваримые фрагменты**, создать для них **векторные представления (эмбеддинги)** с помощью OpenAI и выполнять **поиск по схожести**, чтобы находить наиболее релевантную информацию по пользовательскому запросу.
В моем случае документация представлена файлами в формате Markdown, но это может быть любой текст, объект базы данных и т.д.
---
## Зачем?
Потому что бывает сложно найти нужную информацию. Я хотел создать чат-бота, который может отвечать на вопросы по определенной теме и предоставлять соответствующий контекст из документации.
Такой ассистент может использоваться в разных сценариях:
- **Быстрые ответы на частые вопросы**
- **Поиск по документации как в Algolia**
- **Помощь пользователям в навигации по документации**
- **Анализ пользовательских вопросов и хранение их для анализа**
---
## Краткое содержание
Ниже приведены три основные части решения:
1. Чтение файлов документации
2. Индексация документации (разбиение, перекрытие, эмбеддинги)
3. Поиск по документации и интеграция с чат-ботом
---
## 1. Чтение файлов документации
Вместо того чтобы жестко прописывать текст, вы можете просканировать папку и найти все `.md` файлы с помощью `glob`.
If you’re building a multilingual React Native (or web) app, you’ve probably tried react‑i18next, i18n‑js, LinguiJS, or similar libraries.
But in every project, the same issues come up:
❌ Unused key‑value pairs are never removed
❌ Content gets duplicated
❌ Ensuring format consistency across languages is painful
❌ i18next doesn’t generate TypeScript types by default — so t(“my.key”) won’t throw even if it’s been deleted
❌ Localization platforms like Lokalise or Locize get expensive fast
Frustrated by these challenges, I waited for a better solution... then decided to build one myself: Intlayer.