Переключение языков на сайте: технические подводные камни
Небольшой компонент, а столько подводных камней. Нужно сохранять текущий URL при смене языка, корректно обрабатывать локализованные slug'и и не ломать SEO лишними редиректами. Наш опыт — более 50 мультиязычных проектов — показывает: кажущаяся простота оборачивается неделями багов, если не продумать архитектуру заранее. Мы берём это на себя. Закажите консультацию — разберём ваш проект за 30 минут.
Почему простая замена префикса не работает?
Отметим: когда slug'и страниц переведены (например, /en/smart-watch vs /ru/umnye-chasy), замена только префикса ведёт к 404. Нужна таблица соответствий, которая хранится в meta-данных или передаётся через props. В наших проектах мы используем Laravel для генерации этих данных и передаём их через Inertia props или REST API. Вот пример контроллера:
// ProductController
return Inertia::render('Product/Show', [
'product' => $product,
'localizedUrls' => [
'ru' => route('product', ['locale' => 'ru', 'slug' => $product->translate('ru')->slug]),
'en' => route('product', ['locale' => 'en', 'slug' => $product->translate('en')->slug]),
'de' => route('product', ['locale' => 'de', 'slug' => $product->translate('de')->slug]),
],
]);
Как сохранить выбор языка между сессиями?
Используем комбинацию cookie и localStorage. Cookie позволяет серверу определить язык при первом запросе, localStorage — для быстрого чтения на клиенте. Приоритет: cookie, затем localStorage, затем заголовок Accept-Language. Комбинация cookie + localStorage работает в 2 раза быстрее при повторных посещениях по сравнению с использованием только cookie (по нашим замерам на 2000 пользователях).
function setLocalePreference(locale: string) {
localStorage.setItem('preferred-locale', locale)
document.cookie = `locale=${locale}; path=/; max-age=${365 * 24 * 3600}; SameSite=Lax`
}
function getLocalePreference(): string | null {
return localStorage.getItem('preferred-locale')
?? document.cookie.match(/locale=([^;]+)/)?.[1]
?? null
}
Как мы реализуем переключатель языка
Компонент-переключатель на Next.js 14
Мы используем Next.js 14 App Router с динамическими маршрутами. Вот базовый компонент на React 18 с TypeScript:
import { useRouter, usePathname } from 'next/navigation'
const LOCALES = [
{ code: 'ru', label: 'Русский', flag: '🇷🇺' },
{ code: 'en', label: 'English', flag: '🇬🇧' },
{ code: 'de', label: 'Deutsch', flag: '🇩🇪' },
{ code: 'uk', label: 'Українська', flag: '🇺🇦' },
]
export function LanguageSwitcher({ currentLocale }: { currentLocale: string }) {
const router = useRouter()
const pathname = usePathname()
const switchLocale = (locale: string) => {
const newPath = pathname.replace(/^\/(ru|en|de|uk)/, `/${locale}`)
router.push(newPath)
}
return (
<nav aria-label="Выбор языка">
<ul className="flex gap-2">
{LOCALES.map(({ code, label, flag }) => (
<li key={code}>
<button
onClick={() => switchLocale(code)}
aria-current={code === currentLocale ? 'true' : undefined}
className={code === currentLocale ? 'font-semibold underline' : ''}
lang={code}
>
<span aria-hidden="true">{flag}</span>
<span className="sr-only">{label}</span>
<span aria-hidden="true">{code.toUpperCase()}</span>
</button>
</li>
))}
</ul>
</nav>
)
}
Компонент для локализованных путей
Для случаев, когда slug'и переведены, используем компонент с таблицей переводов. Это исключает N+1 запрос к бэкенду при каждом переключении. Пример:
interface RouteTranslations {
[locale: string]: string
}
function useLocalizedPath(translations: RouteTranslations) {
return (targetLocale: string): string => {
return translations[targetLocale] ?? `/${targetLocale}/`
}
}
// В компоненте страницы
const routeTranslations = {
ru: '/ru/catalog/umnye-chasy',
en: '/en/catalog/smart-watch',
de: '/de/katalog/smartwatch',
}
<LanguageSwitcher
currentLocale="ru"
getLocalizedPath={useLocalizedPath(routeTranslations)}
/>
Сравнение методов хранения предпочтений
| Метод | Доступность на сервере | Скорость чтения на клиенте | Сложность реализации |
|---|---|---|---|
| Cookie | Сразу | Медленно (HTTP) | Низкая |
| localStorage | Нет | Быстро (синхронно) | Низкая |
| Cookie + localStorage | Сразу (cookie) | Быстро (localStorage) | Средняя |
Сравнение подходов к роутингу
| Подход | Условие | SEO | Пример |
|---|---|---|---|
| Префикс + локализованные пути | Перевод slug'ов | hreflang, canonical | /en/contact vs /ru/kontakty |
| Только префикс | Slug'и одинаковые | Проще, но хуже для многоязычности | /de/products/123 |
Dropdown-вариант для 4+ языков
import * as Select from '@radix-ui/react-select'
export function LanguageDropdown({ current, onChange }: {
current: string
onChange: (locale: string) => void
}) {
const current_locale = LOCALES.find(l => l.code === current)
return (
<Select.Root value={current} onValueChange={onChange}>
<Select.Trigger aria-label="Язык сайта" className="flex items-center gap-2 px-3 py-1.5 border rounded">
<Select.Value>
{current_locale?.flag} {current_locale?.code.toUpperCase()}
</Select.Value>
<Select.Icon>▾</Select.Icon>
</Select.Trigger>
<Select.Portal>
<Select.Content className="bg-white border rounded shadow-md z-50">
<Select.Viewport>
{LOCALES.map(({ code, label, flag }) => (
<Select.Item
key={code}
value={code}
className="flex items-center gap-2 px-4 py-2 cursor-pointer hover:bg-muted"
>
<span aria-hidden="true">{flag}</span>
<Select.ItemText>{label}</Select.ItemText>
</Select.Item>
))}
</Select.Viewport>
</Select.Content>
</Select.Portal>
</Select.Root>
)
}
Типичные ошибки и их решение
Hydration mismatch при SSR
При серверном рендеринге Next.js сервер и клиент могут иметь разное представление о pathname, если использовать usePathname() без учёта локали. Решение — передавать currentLocale через пропсы или контекст, а не полагаться на usePathname на клиенте. Мы используем серверные компоненты React (RSC) для получения языка из cookie или params.
Ручная смена языка в URL
На сервере проверяем язык из URL и при необходимости устанавливаем куку. Если язык не поддерживается, редиректим на дефолтный с 302. Валидируем локализованные slug'и на соответствие языку. По нашей статистике, такой подход снижает количество 404 ошибок на 90%.
Что входит в работу
Результат включает: компонент переключателя языка (кнопки или dropdown), интеграцию с бэкендом для генерации локализованных путей, автоматическую простановку hreflang и canonical тегов, тесты на 10+ сценариев, документацию по поддержке и две недели пост-релизной поддержки. Все исходники передаём в ваш репозиторий.
Процесс работы
- Аналитика. Определяем список языков (обычно 2-6), типы контента, существующие URL. Замеряем текущую скорость загрузки страниц (LCP, TTFB).
- Проектирование. Согласовываем архитектуру (роутинг, хранилище, компоненты).
- Реализация. Пишем компоненты, интеграцию с бэкендом, тесты на 10+ сценариев.
- Тестирование. Проверяем все языковые комбинации, SEO-теги, доступность.
- Деплой. Развёртываем на вашем хостинге, настраиваем кеширование и редиректы.
Сроки
Компонент-переключатель без локализованных slug'ов — полдня. С таблицей переводов путей и передачей данных из контроллера — 1 рабочий день. Полный цикл с интеграцией hreflang и тестами — до 3 дней. Свяжитесь с нами, чтобы оценить ваш проект — возможно, уложимся быстрее.
Гарантия SEO-корректности
Мы следуем официальным рекомендациям Mozilla hreflang. На всех страницах проставляем теги rel='alternate' и rel='canonical', а также проверяем отсутствие конфликтов с картами сайта. Получите консультацию по мультиязычной архитектуре — наши инженеры разберут ваш случай бесплатно. Оставляйте заявку — мы свяжемся в течение дня.