Сохранение выбора языка без принудительного редиректа реализуется через явное указание параметра языка в URL или использование локального хранилища браузера (localStorage/sessionStorage). Это обеспечивает пользователю контроль над языком интерфейса и предотвращает потерю настроек при обновлении страницы. Техническая база сайта, включая скорость обработки запросов и структуру маршрутизации, напрямую влияет на удобство использования мультиязычной версии.

Как реализовать сохранение выбора языка без принудительного редиректа: технические механизмы и архитектурные решения

Сохранение выбора языка пользователя без автоматического переключения страницы требует от системы запоминания предпочтения в моменте взаимодействия. Это достигается либо через явное указание параметра в адресной строке (URL), либо путем записи информации в локальное хранилище браузера. Первый метод обеспечивает стабильность при переходе между устройствами и поисковыми системами, второй — удобство для пользователя на одном устройстве. Выбор одного из подходов зависит от архитектуры проекта: статические сайты с генерацией страниц на лету или динамические приложения с клиентской рендерингом.

В основе работы лежит механизм определения языка через заголовок Accept-Language в HTTP-запросе и последующего сохранения этого значения. При первом визите сервер либо возвращает контент на языке по умолчанию, либо запрашивает выбор у пользователя. После подтверждения выбора система должна запомнить этот параметр. Для реализации используется cookie или LocalStorage. Cookie предпочтительны для сессий, где данные должны быть видны серверу при каждом запросе, тогда как LocalStorage подходит для клиентских приложений, где логика переключения языка реализуется на стороне JavaScript без участия бэкенда.

Архитектурное решение строится на разграничении ответственности между фронтендом и бэкендом. Если сайт использует серверную рендеринг (например, PHP или Python), то выбор языка должен передаваться в URL как параметр query string (например, ?lang=ru). Это позволяет поисковым роботам индексировать версии на разных языках отдельно и сохранять ссылки, ведущие к конкретному контенту. В случае клиентского рендеринга (React, Vue) логика определения языка может быть вынесена в отдельный хук или функцию инициализации, который проверяет наличие параметра в URL и, если его нет — читает значение из LocalStorage.

При использовании cookie важно учитывать атрибуты безопасности. Флаг SameSite=Strict или Lax влияет на то, как браузер отправляет куки при переходе между доменами. Для мультиязычных сайтов часто используют флаг Secure, чтобы данные передавались только по HTTPS. Также необходимо задать срок жизни cookie (Expires), который должен соответствовать жизненному циклу сессии пользователя или быть постоянным, если язык не меняется годами. При смене языка пользователем вручную в настройках сайта система должна обновлять значение cookie и перезагружать страницу или перерендерить контент.

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

Для обеспечения совместимости с SEO необходимо генерировать отдельные URL для каждого языка или использовать тег hreflang в мета-данных страницы. Это позволяет поисковым системам понимать, что контент доступен на разных языках и должен индексироваться отдельно. Если выбор языка сохраняется только в LocalStorage без отражения в URL, то при переходе по прямой ссылке из поиска пользователь увидит контент на языке по умолчанию, а не на том, который выбран в настройках браузера. Это снижает доверие к сайту и может привести к отказам от просмотра.

При реализации мультиязычности важно также учитывать производительность. Загрузка всех языковых версий контента сразу увеличивает вес страницы и замедляет работу. Оптимальным решением является динамическая подстановка текстов на основе выбранного языка, что позволяет сохранять скорость загрузки. Для этого используется механизм lazy loading или предварительной загрузки только необходимых ресурсов. Также стоит предусмотреть возможность быстрого переключения языка без полной перезагрузки страницы, используя технологию SSR (Server-Side Rendering) с поддержкой hydration на клиенте.

Практическая реализация на примере популярных стеков (React, Next.js, PHP/WordPress)

Выбор способа хранения выбора языка зависит от архитектуры вашего проекта. В динамических системах, таких как React или Next.js, предпочтительнее использовать локальное хранилище браузера (localStorage или sessionStorage). Это позволяет пользователю менять язык без перезагрузки страницы и сохраняет выбор даже после закрытия вкладки. Для серверных решений на PHP или WordPress стандартным подходом является сохранение параметра языка в URL-адресе. Такой метод обеспечивает прямую ссылку на конкретную языковую версию, что критически важно для SEO и удобства обмена ссылками.

В React-приложениях настройка переключения языка начинается с создания контекста (Context API) или использования библиотеки типа i18next. Данные о выбранном языке записываются в localStorage при первом выборе пользователем. При загрузке приложения код проверяет наличие записи в хранилище и, если она есть, сразу применяет соответствующий набор переводов. Если записи нет, система использует значение по умолчанию из конфигурации или параметр из URL. Этот подход гарантирует, что пользователь всегда видит интерфейс на том языке, который он выбрал ранее.

Next.js предлагает гибкость благодаря поддержке серверного рендеринга (SSR) и статической генерации (SSG). Для реализации мультиязычности без принудительного редиректа можно использовать middleware, которое анализирует URL. Если в адресе есть префикс языка (например, /ru/ или /en/) и он совпадает с предпочтением пользователя из хранилища, сервер отдает контент на этом языке. Важно настроить роутинг так, чтобы переход между языками происходил через клиентские навигационные события (client-side navigation), что предотвращает лишние запросы к серверу и сохраняет состояние приложения.

В PHP-проектах выбор языка часто реализуется через сессию или файл конфигурации. Однако для сохранения выбора без редиректа более надежным является запись параметра в URL. Например, если пользователь выбрал русский язык, ссылка на страницу будет выглядеть как example.com/ru/page. При каждом запросе скрипт проверяет наличие префикса /ru/ и подгружает соответствующие тексты из базы данных или файлов. Использование сессий допустимо, но они менее надежны для SEO, так как поисковые роботы могут не индексировать контент, привязанный к уникальным идентификаторам сессий.

WordPress требует установки плагина для управления языками, например WPML или Polylang. Эти инструменты позволяют сохранять выбор языка в URL и автоматически переключать интерфейс без перезагрузки страницы. В настройках плагина можно включить сохранение предпочтений пользователя в cookie или базу данных. При этом важно убедиться, что шаблон темы корректно обрабатывает языковые префиксы в URL, чтобы избежать дублирования контента. SEO-оптимизация достигается за счет правильной настройки канонических тегов и ссылок на языковые версии страниц.

Для оценки качества реализации проверьте поведение страницы при переключении языка. Откройте консоль разработчика и убедитесь, что нет ошибок доступа к хранилищу браузера. Загрузите страницу через инкогнито-режим: если выбор языка сохраняется после закрытия и открытия браузера, механизм работает корректно. Протестируйте переход по прямой ссылке с префиксом языка — страница должна отобразиться на нужном языке без автоматического перенаправления на дефолтную версию.

Ограничения браузеров и политик безопасности могут влиять на работу локального хранилища. Некоторые браузеры блокируют запись в localStorage, если сайт не использует HTTPS. В таких случаях необходимо использовать серверное сохранение языка в URL или cookie с флагом Secure. Также учитывайте, что очистка кэша браузера пользователя удалит выбор языка при использовании localStorage, поэтому для критически важных систем стоит предусмотреть резервное копирование выбора в базе данных.

При разработке мультиязычного сайта важно не перегружать его лишними запросами. Динамическая подстановка текстов на основе выбранного языка позволяет сохранить скорость загрузки и обеспечить плавный пользовательский опыт. Используйте механизмы lazy loading для подгрузки переводов только тех элементов, которые видны пользователю в данный момент. Это особенно актуально для крупных проектов с большим количеством контента на разных языках.

Критерии выбора подхода в зависимости от типа проекта и требований к SEO

Выбор стратегии сохранения языка зависит от архитектуры сайта, целей бизнеса и требований поисковых систем. Не существует универсального решения: то, что работает для корпоративного портала, может навредить интернет-магазину или блогу. Решение строится на балансе между удобством пользователя, скоростью загрузки страниц и возможностью поисковиков корректно индексировать контент.

Если проект ориентирован на коммерческие продажи (интернет-магазины, каталоги услуг), приоритетом является точность отображения контента под запрос пользователя. В таких случаях предпочтительнее использовать параметры в URL или cookie с высокой степенью защиты от очистки. Поисковые системы, такие как Яндекс и Google, умеют корректно обрабатывать такие сигналы, если они не создают дублей страниц. Важно убедиться, что каждая языковая версия имеет уникальный контент и правильные мета-теги, чтобы поисковик не считал страницы разными версиями одной и той же информации.

Для информационных ресурсов, блогов или сайтов с частым обновлением контента критична скорость загрузки. Здесь эффективнее использовать динамическую подстановку текста без изменения URL. Это позволяет избежать лишних запросов к серверу и удерживает пользователя на странице. Однако при этом необходимо настроить заголовки HTTP (например, Vary: Accept-Language), чтобы поисковики понимали, что контент меняется в зависимости от настроек браузера, а не является динамическим дублем.

При выборе между параметрами в URL и локальным хранилищем нужно учитывать поведение пользователей. Если часть аудитории часто очищает кэш или использует публичные устройства (например, в офисах или кафе), полагаться только на cookie небезопасно. В таких сценариях комбинация подходов работает надежнее: параметр в URL служит основным идентификатором, а локальное хранилище используется для быстрого переключения без перезагрузки страницы. Это особенно важно для мобильных пользователей, где каждый лишний запрос может замедлить работу.

SEO-требования диктуют необходимость четкой структуры ссылок. Если вы используете разные домены или поддомены для языковых версий (например, example.com/de и example.com/en), это упрощает задачу для поисковиков: каждая версия имеет свой URL, который легко проиндексировать. Но такой подход требует отдельного хостинга и настройки перенаправлений, что увеличивает затраты. Если же все версии находятся на одном домене, важно избегать дублирования контента. Используйте тег canonical, указывая на основную версию страницы, если контент идентичен, или обеспечивайте полную уникализацию текстов для каждого языка.

Оценка результата начинается с анализа поведения пользователей и позиций в поиске. Мониторьте метрики: время на сайте, конверсию по языкам, количество отказов. Если пользователи часто переходят на другие языковые версии вручную, значит, автоматическое определение не работает корректно. Проверьте индексацию через инструменты вебмастеров Яндекса и Google Search Console — убедитесь, что все версии страниц проиндексированы и не помечены как дубликаты.

Ограничения браузеров и политик безопасности также влияют на выбор метода. Современные браузеры блокируют доступ к cookie в режиме инкогнито или при смене домена. Это значит, что локальное хранилище нельзя использовать как единственный источник выбора языка для внешних ресурсов. Для таких случаев лучше применять параметры в URL или заголовки HTTP. Также учитывайте, что некоторые CMS и фреймворки по умолчанию не поддерживают мультиязычность без доработки — это может привести к ошибкам при сохранении настроек пользователя.

Практический пример: если вы разрабатываете сайт для международной компании с офисами в разных странах, используйте поддомены или гео-привязанные параметры. Если же проект локальный, но обслуживает русскоязычную и англоязычную аудиторию внутри одной страны, лучше использовать динамическую подстановку с проверкой заголовков браузера. В обоих случаях важно тестировать работу сайта в разных браузерах и на мобильных устройствах, чтобы убедиться, что выбор языка сохраняется корректно.

Типичная ошибка — игнорирование настроек сервера. Даже если клиентская часть настроена идеально, сервер может возвращать одну и ту же версию страницы всем пользователям независимо от их выбора. Убедитесь, что веб-сервер (Nginx, Apache) правильно обрабатывает заголовки Accept-Language и не игнорирует параметры в URL. Также проверьте работу с кэшированием: если кэш хранит версию страницы без учета языка, пользователи будут видеть неправильный контент после смены настроек.

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

Типичные ошибки при настройке мультиязычности и способы их устранения

Частой ошибкой является сохранение выбора языка только в сессии браузера (localStorage) без проверки актуальности контента. Пользователь меняет язык, но при перезагрузке страницы или переходе на новую подстраницу видит контент на старом языке, если сервер не подтверждает выбор. Это происходит из-за отсутствия механизма валидации предпочтений на стороне сервера.

Другая проблема — игнорирование параметра Accept-Language заголовка HTTP при первой навигации. Если скрипт принудительно устанавливает язык по умолчанию (например, русский) без анализа заголовка от браузера, пользователь с английским интерфейсом попадает на русскую версию сайта. Устранение: сервер должен отдавать контент на языке, который браузер запросил первым, либо использовать cookie для запоминания выбора, но только после успешной валидации контента.

Ошибка дублирования страниц без указания hreflang-тегов приводит к проблемам с индексацией. Поисковые системы видят несколько версий одной страницы и не понимают, какую считать оригиналом. Решение: каждая языковая версия должна иметь уникальный URL (например, /en/page или /ru/page) и мета-тег <link rel="alternate" hreflang="…"> в head-секции.

Использование JavaScript для смены языка без обновления DOM полностью — частая ошибка на React/Next.js. Если компонент просто меняет текст внутри блока, а URL не обновляется, поисковики могут проиндексировать только одну версию страницы. Правильный подход: при смене языка обновлять URL (client-side routing) и пересобирать страницу или использовать SSR для генерации контента на нужном языке.

Принудительный редирект на язык по умолчанию без возможности выбора пользователем блокирует доступ к контенту. Если пользователь заходит с английского браузера, но сервер перекидывает его на русский, это снижает конверсию и ухудшает SEO. Устранение: реализовать логику «попробовать запомненный выбор -> проверить заголовок Accept-Language -> использовать язык контента», а не жесткий редирект.

Некорректная обработка кириллицы в URL при смене языка вызывает 404-ошибки. Если пользователь переходит на страницу /en/product, а сервер ожидает /ru/product, возникает ошибка. Решение: настроить правила маршрутизации так, чтобы они учитывали языковой суффикс или поддомен, и обеспечивать корректную генерацию ссылок в навигации.

Игнорирование различий в структуре контента между языками приводит к тому, что переводы не соответствуют оригиналу по смыслу. Например, меню может быть на русском, а описание товара — на английском. Устранение: использовать единый источник данных (CMS или API), где для каждого языка хранятся свои тексты, и динамически подгружать их в зависимости от выбранного языка.

Ошибка в настройке cookie-политики при сохранении выбора языка может привести к тому, что выбор не сохраняется между устройствами. Если пользователь заходит с телефона, а на компьютере выбрал английский, сайт показывает русский язык. Решение: использовать серверные cookie или хранилище на уровне домена, а не только локальное хранилище браузера.

Неучет требований GDPR и ФЗ-152 при сборе данных о выборе языка может привести к юридическим рискам. Если пользователь соглашается на обработку данных, но сайт сохраняет выбор языка без согласия, это нарушение. Устранение: добавить чекбокс согласия на использование cookie для сохранения предпочтений в политике конфиденциальности.

Использование устаревших методов смены языка через query-параметры (например, ?lang=ru) без поддержки сервером приводит к дублированию контента. Поисковики видят одну и ту же страницу с разными параметрами. Решение: настроить редирект на канонический URL без параметров или использовать поддомены (/ru/, /en/).

Ошибка в конфигурации веб-сервера (Nginx/Apache) при обработке языковых суффиксов вызывает 500-ошибки. Если правила маршрутизации не учитывают языковые префиксы, запрос на /en/page может вернуть ошибку. Устранение: проверить конфиги сервера и убедиться, что они корректно обрабатывают все возможные комбинации языков.

Некорректная обработка времени жизни cookie (TTL) приводит к тому, что выбор языка сбрасывается после выхода из браузера или очистки кэша. Решение: установить адекватный срок действия cookie (например, 1 год) и обеспечить их сохранение даже при закрытии браузера.

Игнорирование различий в форматах дат и валют между языками вызывает путаницу у пользователей. Например, дата может отображаться как DD.MM.YYYY на русском и MM/DD/YYYY на английском. Устранение: использовать библиотеки для форматирования (например, moment.js или date-fns) с учетом локали.

Ошибка в логике переключения языка при наличии нескольких поддоменов приводит к тому, что пользователь попадает на неправильный сайт. Решение: настроить DNS и правила маршрутизации так, чтобы каждый поддомен (/ru/, /en/) соответствовал своему языку и контенту.

Неучет различий в SEO-стратегии для разных языков приводит к потере позиций. Например, ключевые слова на английском могут отличаться от русских по смыслу. Решение: проводить отдельный аудит семантики для каждого языка и адаптировать контент под локальные запросы.

Ошибка в настройке аналитики (Google Analytics/Metrica) при смене языка приводит к тому, что трафик дублируется или не учитывается. Решение: настроить цели и события так, чтобы они учитывали языковой параметр и не дублировали данные.

Игнорирование различий в правах доступа к контенту между языками вызывает проблемы безопасности. Например, пользователь с английским доступом может получить русский контент, который должен быть скрыт. Решение: настроить правила доступа на уровне сервера или приложения.

Некорректная обработка ошибок при смене языка приводит к тому, что сайт показывает пустую страницу или ошибку 500. Решение: добавить обработку исключений и fallback-логику для отображения контента на языке по умолчанию при ошибке.

Игнорирование различий в юридических требованиях между странами (например, GDPR в Европе и ФЗ-152 в России) приводит к штрафам. Решение: адаптировать контент и политики конфиденциальности под каждую юрисдикцию.

Ошибка в настройке CDN при смене языка приводит к тому, что пользователь получает контент из другого региона. Решение: настроить правила кэширования на CDN так, чтобы они учитывали языковой параметр.

Неучет различий в скорости загрузки контента между языками (например, русский текст тяжелее английского) влияет на Core Web Vitals. Решение: оптимизировать размер файлов и использовать сжатие для каждого языка отдельно.

Игнорирование различий в доступности (accessibility) контента на разных языках приводит к тому, что пользователи с ограниченными возможностями не могут пользоваться сайтом. Решение: проверить контрастность шрифтов и структуру навигации для каждого языка.

Ошибка в настройке тестирования A/B для разных языков приводит к неверным выводам. Решение: проводить тесты отдельно для каждого языка и учитывать культурные особенности.

Некорректная обработка ссылок на внешние ресурсы (например, YouTube) при смене языка вызывает проблемы с доступом. Решение: проверять ссылки на внешние ресурсы и обеспечивать их корректную работу на всех языках.

Ограничения браузеров и политик безопасности, влияющие на сохранение предпочтений

Браузеры не предоставляют универсального API для хранения произвольных данных без участия пользователя. Стандартные механизмы — LocalStorage, SessionStorage и Cookies — имеют ограничения по объему (обычно до 5–10 Мб), срокам жизни и доступности в зависимости от контекста запроса. Это означает, что разработчик должен заранее планировать архитектуру хранения языковых настроек, учитывая эти технические рамки.

Политика безопасности Same-Origin Policy (SOP) запрещает скрипту на одной домене читать данные из хранилища другой домены. Если ваш сайт использует сторонние виджеты или аналитику с других доменов, они не смогут напрямую получить сохраненный выбор языка из LocalStorage вашего сайта. Это ограничение часто приводит к тому, что при переходе по ссылкам из внешних сервисов пользователь видит язык по умолчанию, а не тот, который он выбрал ранее на вашем ресурсе.

Cookies имеют более строгие ограничения: они могут быть только текстовыми, хранятся в отдельном файле и передаются с каждым запросом к серверу. Это создает нагрузку на сеть и увеличивает время отклика. Кроме того, современные браузеры активно блокируют third-party cookies, что делает невозможным использование их для хранения настроек на сторонних доменах без специальных разрешений пользователя (например, через Consent Mode).

SessionStorage исчезает при закрытии вкладки или браузера. Если пользователь открывает сайт с разных устройств или вкладок, настройки из SessionStorage не синхронизируются. Это критично для мультиязычных проектов, где важно сохранить выбор языка на всех устройствах пользователя. Для таких случаев требуется серверная часть, которая будет хранить предпочтения и передавать их клиенту.

Использование URL-параметров (например, ?lang=ru) как основного способа хранения выбора языка имеет свои плюсы и минусы. С одной стороны, это позволяет легко делиться ссылками с сохраненным языком и обеспечивает работу без JavaScript. С другой стороны, длинные URL могут быть неудобны для пользователя, а изменение параметра при копировании ссылки может привести к потере настройки, если сервер не настроен на автоматическое определение языка из заголовка Accept-Language.

При выборе стратегии хранения предпочтений важно учитывать баланс между удобством пользователя и требованиями безопасности. Хранение настроек в LocalStorage позволяет быстро загружать сайт без лишних запросов к серверу, но требует защиты от XSS-атак (скрипты не должны читать данные из хранилища). Серверное хранение обеспечивает синхронизацию между устройствами, но увеличивает задержку при первой загрузке страницы.

Для проектов с высокой нагрузкой или строгими требованиями к производительности рекомендуется комбинировать подходы: использовать URL-параметры для первичного определения языка и LocalStorage/SessionStorage для кэширования выбора пользователя. При этом сервер должен уметь определять язык по заголовкам Accept-Language, если пользователь очистил хранилище или открыл сайт с другого устройства.

Важно также учитывать поведение пользователей в разных регионах. Например, в некоторых странах браузеры блокируют LocalStorage без явного согласия пользователя на обработку данных. Это требует реализации механизмов получения разрешения (consent) перед записью настроек в хранилище. Игнорирование этого требования может привести к потере данных о выборе языка у части пользователей.

При разработке мультиязычных сайтов необходимо тестировать работу с разными версиями браузеров и устройствами. Старые версии Internet Explorer или Safari могут не поддерживать современные API для работы с хранилищем. Кроме того, некоторые мобильные браузеры имеют ограничения на объем LocalStorage, что может привести к потере настроек при длительном использовании приложения.

Для обеспечения совместимости рекомендуется использовать библиотеки-обертки (например, localStorage-safe), которые автоматически обрабатывают ошибки и предоставляют единый интерфейс для работы с хранилищем. Это позволяет избежать дублирования кода и упрощает поддержку проекта в будущем.

При настройке серверной части важно правильно конфигурировать заголовки ответа (Set-Cookie) для управления сессиями пользователей. Если cookie имеет флаг Secure, он будет передаваться только по HTTPS, что повышает безопасность, но может вызвать проблемы на внутренних сетях без шифрования. Также следует учитывать срок жизни cookie и возможность их очистки пользователем через настройки браузера.

В заключение, выбор способа хранения выбора языка зависит от конкретных требований проекта: необходимости синхронизации между устройствами, требований к производительности и уровня безопасности. Рекомендуется начинать с простого подхода (URL-параметры + LocalStorage) и постепенно переходить к более сложным решениям при росте нагрузки или появлении новых требований.

Вопросы и ответы

Как избежать потери выбора языка при переходе с HTTPS на HTTP или наоборот?

Используйте протокол `https://` для всех запросов, включая те, что идут из `localStorage`. Браузеры блокируют запись данных в хранилище, если сайт загружен по незащищённому протоколу. Если ваш проект работает только на HTTP, настройте редирект на HTTPS или используйте `sessionStorage`, но помните о его ограничении: данные исчезают после закрытия вкладки.

Что делать, если пользователь очищает кэш браузера?

Выбор языка, сохранённый в `localStorage` или `Cookies`, будет удалён вместе с кэшем. Это нормальное поведение для локальных хранилищ. Если критично сохранять выбор независимо от очистки кэша, используйте серверные куки (если политика безопасности позволяет) или предложите пользователю сохранить настройки в аккаунте.

Можно ли хранить язык только в URL без использования хранилища браузера?

Да, это стандартный подход для SEO. Параметр языка (например, `/ru/` или `?lang=ru`) передаётся поисковым системам и другим устройствам пользователя. Минус: при каждом запросе сервер должен определять язык по URL, что увеличивает нагрузку на бэкенд. Плюс: полная совместимость с кросс-девайсными сценариями.

Как решить проблему, когда `localStorage` заполняется и новые данные не записываются?

Обычно это происходит при превышении лимита в 5–10 Мб. Для хранения одного параметра языка это маловероятно. Если проблема возникает, проверьте, нет ли других скриптов, которые активно пишут в `localStorage`. Удалите лишние данные или перенесите их на сервер.

По теме

// Пример правильной логики сохранения выбора языка без принудительного редиректа
const saveLanguagePreference = (lang) => {
  if (!localStorage.getItem('preferredLang')) {
    localStorage.setItem('preferredLang', lang);
  }
};

const getLanguageFromHeader = () => {
  const acceptLang = navigator.language || navigator.userLanguage;
  return acceptLang.split(',')[0].split('-')[0]; // Возвращает код языка (например, 'en')
};

const renderPage = (lang) => {
  if (!lang) lang = getLanguageFromHeader();
  saveLanguagePreference(lang);
  // Рендеринг контента на выбранном языке
};
# Пример конфигурации Nginx для обработки языковых суффиксов
location / {
  if ($arg_lang = 'en') {
    rewrite ^/(.*)$ /en/$1 last;
  }
  if ($arg_lang = 'ru') {
    rewrite ^/(.*)$ /ru/$1 last;
  }
  # Логика для сохранения выбора языка
  set $lang $arg_lang;
  proxy_pass http://backend;
}

Похожие статьи