Перемикання мов на сайті: технічні підводні камені
Невеликий компонент, а стільки підводних каменів. Потрібно зберігати поточний 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', а також перевіряємо відсутність конфліктів з картами сайту. Отримайте консультацію з багатомовної архітектури — наші інженери розберуть ваш випадок безкоштовно. Залишайте заявку — ми зв'яжемося протягом дня.