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