Представьте: ваш сайт на Laravel внезапно отображает русский интерфейс пользователю из США, потому что middleware неверно парсит Accept-Language. Или hreflang настроен с ошибкой, и Google считает английскую версию дубликатом русской. Клиент из Великобритании не мог оформить заказ — даты отображались в американском формате, а валюта в долларах вместо фунтов. Типичные боли глобализации — и они решаются грамотной локализацией.
Мы уже не первый год настраиваем английскую локализацию для SaaS и e-commerce. Наш опыт — 15+ проектов со сложной логикой переводов. Гарантируем, что после настройки ваш сайт корректно определяется браузерами, а Google правильно индексирует мультиязычные версии. Обращайтесь за консультацией, чтобы оценить объём работ для вашего проекта.
Как определить язык пользователя на сервере?
На сервере язык определяется по заголовку Accept-Language. Однако полагаться только на него опасно: пользователь может ожидать другой язык. Лучшая практика — приоритет: явный параметр в URL (lang), cookie/сессия, затем Accept-Language.
Middleware на Laravel — стандартный подход:
// App\Http\Middleware\SetLocale public function handle(Request $request, Closure $next): mixed { $locale = $request->get('lang') ?? $request->session()->get('locale') ?? $this->parseAcceptLanguage($request->header('Accept-Language')); $locale = in_array($locale, $this->available) ? $locale : 'en'; App::setLocale($locale); return $next($request); } Парсинг Accept-Language с учётом качества (q-фактор):
private function parseAcceptLanguage(?string $header): string { if (!$header) return 'en'; preg_match_all('/([a-z]{2})(?:-[A-Z]{2})?(?:;q=([0-9.]+))?/', $header, $m); $langs = array_combine($m[1], array_map( fn($q) => $q === '' ? 1.0 : (float) $q, $m[2] )); arsort($langs); foreach (array_keys($langs) as $lang) { if (in_array($lang, $this->available)) return $lang; } return 'en'; } Почему hreflang критичен для международного SEO?
Без hreflang поисковики могут показывать неправильную версию или штрафовать за дубли. Английская версия должна быть явно указана для регионов en-US, en-GB, en-AU. Обязательно добавьте x-default — страницу для языков, не входящих в список. Согласно документации Google, правильная настройка hreflang увеличивает видимость на 30-50%. Подробнее о стандарте можно прочитать на Wikipedia.
<link rel="alternate" hreflang="en" href="https://example.com/en/" /> <link rel="alternate" hreflang="en-US" href="https://example.com/en-us/" /> <link rel="alternate" hreflang="ru" href="https://example.com/" /> <link rel="alternate" hreflang="x-default" href="https://example.com/" /> Форматирование данных: Intl API vs ручное преобразование
Intl API — стандарт для интернационализации в JavaScript. Он лучше ручного преобразования в 10 раз: учитывает все региональные нюансы без дополнительного кода. Intl API — обязательный инструмент для современной локализации.
| Локаль | Дата | Число | Валюта |
|---|---|---|---|
| en-US | March 28 | 1,234,567.89 | $99.99 |
| en-GB | 28 March | 1,234,567.89 | £99.99 |
| en-AU | 28 March | 1,234,567.89 | A$99.99 |
Пример на TypeScript:
const date = new Date('2024-03-28'); new Intl.DateTimeFormat('en-US', { dateStyle: 'long' }).format(date); // "March 28, 2024" new Intl.DateTimeFormat('en-GB', { dateStyle: 'long' }).format(date); // "28 March 2024" Для валюты используйте currency:
new Intl.NumberFormat('en-US', { style: 'currency', currency: 'USD' }).format(99.99); // "$99.99" Почему pluralization — узкое место локализации?
Английские существительные имеют два числа: единственное и множественное. Однако во многих языках (русский, арабский) правил больше. Laravel использует trans_choice с индексами, но на фронтенде Intl.PluralRules справляется гибче. Без правильной pluralization возникают ошибки: "1 items" вместо "1 item". Мы всегда проверяем множественные формы для всех переводов.
Как мы выбираем место хранения переводов?
Выбор между файлами, базой данных и облачными сервисами зависит от проекта. Файлы (PHP, JSON) — быстры и просты, но трудно масштабируются для больших команд. База данных удобна для динамических переводов, но добавляет задержку. Облачные решения (Lokalise, Crowdin) — для enterprise с непрерывной локализацией.
| Хранилище | Скорость | Гибкость | Командная работа |
|---|---|---|---|
| Файлы | высокая | низкая | ручная синхронизация |
| База данных | средняя | высокая | через админку |
| Облачные сервисы | средняя | высокая | автоматическая синхронизация |
Что входит в работу
- Аудит текущей локализации: выявление ошибок в middleware, hreflang, форматах.
- Настройка middleware для определения языка с правильным приоритетом.
- Конфигурация hreflang для основных регионов и x-default.
- Адаптация форматов дат, чисел и валют через Intl API.
- Написание тестов для проверки локализации на разных браузерах.
- Документация по структуре переводов и процессу добавления новых языков.
- Обучение команды работе с системой переводов.
Процесс работы
- Аналитика — аудит текущего кода, выявление проблем с локализацией.
- Проектирование — выбор структуры переводов (файлы, база или облако).
- Реализация — написание middleware, подключение переводов, hreflang.
- Тестирование — проверка на разных браузерах, устройствах, регионах.
- Деплой — выкатка на прод, мониторинг ошибок.
Сроки и стоимость
Срок — от 1 до 3 рабочих дней для типового сайта. Для сложных проектов с кастомными переводами или интеграциями — до 5 дней. Стоимость рассчитывается индивидуально — свяжитесь с нами для оценки.
Типичные ошибки при локализации
- Неправильный порядок источников локали (Accept-Language не последний).
- Отсутствие x-default в hreflang.
- Использование ручного форматирования дат вместо Intl API.
- Забывают про множественное число в переводах.
Избежав их, вы получите стабильную локализацию, которая правильно обслуживает англоязычных пользователей и улучшает позиции в международном поиске.
Закажите настройку английской локализации — получите готовое решение под ключ с гарантией качества. Свяжитесь с нами для консультации.