Створення багатомовних Next.js-додатків з next-intl

Вступ

Всі веб-сайти fluxLab.dev підтримують кілька мов. Наш портфоліо-сайт обслуговує англійську та українську, а продукти на кшталт Jobber побудовані з інтернаціоналізацією від першого дня. Ми використовуємо next-intl з Next.js App Router для чистої, типобезпечної реалізації.

Чому next-intl?

Ми оцінили три варіанти:

next-intl: першокласна підтримка App Router, типобезпечний доступ до повідомлень, SEO-дружня маршрутизація
next-i18next: зрілий, але розрахований на Pages Router, незручний з App Router
react-intl: низькорівневий, потребує більше шаблонного коду

next-intl переміг, бо природно інтегрується з Server Components та надає маршрути з префіксами локалей (/en/projects, /uk/projects) з коробки.

Структура проєкту

src/
  i18n/
    config.ts      → Визначення локалей
    routing.ts     → Конфігурація маршрутів
    request.ts     → Визначення локалі на сервері
    navigation.ts  → Локалізовані Link і redirect
  messages/
    en.json        → Англійські переклади
    uk.json        → Українські переклади
  app/
    [locale]/
      page.tsx     → Сторінки з урахуванням локалі
      layout.tsx   → Провайдер локалі

Файли перекладів

Ми організовуємо переклади за сторінкою чи функціоналом, а не за компонентом:

{
  "metadata": {
    "title": "fluxLab.dev — Software Development Studio",
    "description": "We build modern web & mobile applications."
  },
  "nav": {
    "home": "Home",
    "projects": "Projects",
    "services": "Services"
  },
  "projects": {
    "title": "Our Projects",
    "visitSite": "Visit Site",
    "features": "Key Features"
  }
}

Ця структура масштабується краще, ніж файли на кожен компонент, бо пов'язані переклади залишаються разом.

Server Components

У серверних компонентах використовуємо getTranslations:

export default async function ProjectsPage() {
  const t = await getTranslations('projects');
  return <h1>{t('title')}</h1>;
}

Жодного клієнтського JavaScript не додається. Переклад визначається під час збірки для статичних сторінок.

Клієнтські компоненти

Для інтерактивних компонентів використовуємо useTranslations:

'use client';

export function Header() {
  const t = useTranslations('nav');
  return <nav>{t('home')}</nav>;
}

SEO-аспекти

Багатомовні сайти потребують додаткової уваги до SEO:

URL з префіксами локалей

Кожна сторінка має унікальний URL для кожної мови: /en/projects/jobber і /uk/projects/jobber. Пошукові системи індексують кожну версію окремо.

Hreflang-теги

Ми генеруємо альтернативні мовні посилання в метаданих:

alternates: {
  canonical: url,
  languages: {
    en: `${SITE_URL}/en${path}`,
    uk: `${SITE_URL}/uk${path}`,
    'x-default': `${SITE_URL}/en${path}`,
  },
}

Це повідомляє Google, яку версію показувати україномовним чи англомовним користувачам. Запис x-default визначає сторінку для всіх інших відвідувачів; ми вказуємо в ньому англійську версію.

Перекладені мета-описи

Кожна сторінка має унікальний мета-опис для кожної мови — а не лише перекладені заголовки. Це покращує CTR для кожної локалі.

Покриття Sitemap

Наш sitemap генерує URL для кожної комбінації сторінка × локаль. Для нашого портфоліо-сайту із 6 проєктами, 11 записами блогу та вакансіями це близько 60 записів у sitemap, кожен з яких перелічує свої мовні альтернативи.

Типові помилки

Не перекладайте URL — /uk/проекти виглядає розумно, але ламає закладки та аналітику
Не перенаправляйте автоматично за IP — дайте користувачам обрати мову; пошуковим системам потрібен доступ до всіх версій
Не забувайте стандартну локаль — перенаправляйте /projects на /en/projects послідовно
Перекладайте alt-текст — зображення потребують локалізованих описів для доступності та SEO

Висновок

next-intl робить інтернаціоналізацію простою в застосунках Next.js App Router. З правильним SEO-налаштуванням (hreflang, локалізовані sitemap, перекладені метадані) підтримка кількох мов стає конкурентною перевагою, а не тягарем на підтримку.

Розробляєте продукт для кількох ринків? Ми створюємо багатомовні Next.js-застосунки і для клієнтів: дивіться наші послуги.