Белорусская локализация сайта: настройка i18n, плюрализации и шрифтов

Почему локализация сайта на белорусский ломает вёрстку и поиск

Белорусский добавляют как «ещё один язык» — и получают набор сбоев, которые не видны на тестовых данных. Кириллица в белорусском требует дополнительных символов (ў, і), которых нет в латинских подмножествах шрифта: браузер подставляет системный fallback, метрики строки меняются, и текст в кнопке или колонке таблицы обрезается многоточием. Если кодировка страницы или базы не переведена на UTF-8 целиком, форма с полем «Імя» отдаёт вопросительные знаки, а валидация на сервере отклоняет корректный ввод.

Дубли страниц — вторая по частоте проблема. Локализованная версия открывается по отдельному адресу без языковых метатегов и канонических ссылок, и поисковик видит две конкурирующие страницы вместо одной с двумя языковыми вариантами. Редиректы по геолокации усугубляют: посетитель с белорусским языком в браузере попадает на перевод, а поисковый робот — на исходную версию, и обход заканчивается индексацией не той страницы.

Плюрализация ломает формы иначе. В белорусском три формы множественного числа, и правило «одна форма для всего» даёт «5 тавараў» там, где нужно «5 тавараў», но «2 тавары». Строки, зашитые в шаблоны и скрипты, при смене языка остаются на исходном — интерфейс становится наполовину переведённым, а заказчик узнаёт об этом от пользователей.

Цена каждого сбоя — не косметика: обрезанный текст снижает конверсию формы, дубли размывают позиции, неверный редирект отдаёт поисковому роботу не тот контент. Разбираем, как это закрывается на уровне конфигурации, а не ручной правки страниц.

Что даёт корректная белорусская версия: скорость, охват, надёжность

Рост доли органического трафика из Беларуси

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

Снижение отказов и рост конверсии

Человек, попавший на страницу на родном языке, быстрее находит нужный раздел и реже уходит сразу. Переведённые формы, кнопки и подсказки работают одинаково на всех этапах — от корзины до подтверждения заказа, поэтому посетитель не бросает оформление на середине. Отдельно проверяем склонение числительных и падежи: «1 тавар», «2 тавары», «5 тавараў» — без этого текст выглядит машинным и подрывает доверие.

Отсутствие дублей и штрафов за них

Белорусская и русская версии живут на разных адресах и связаны перекрёстными ссылками с указанием языка. Это снимает главную причину дублей: поисковик понимает, что перед ним две локали одного сайта, а не копии, и не понижает позиции. Канонические адреса и корректные языковые метки сохраняют накопленный вес страниц.

Скорость загрузки и охват аудитории

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

Подходы к локализации: ручная разметка, файлы переводов, внешние сервисы

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

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

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

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

Этапы внедрения белорусской локализации: от аудита до передачи

Локализация — это не перевод строк в файле, а изменение схемы данных, шаблонов и сборки. Начинаем с аудита: смотрим, где текст зашит в шаблоны, где приходит из базы, где формируется на стороне сервера, и какие места уже зависят от языка. На выходе — карта строк с пометкой риска: динамические подписи, склейка фраз, форматы дат и чисел, которые при смене языка ломаются первыми.

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

1. Аудит локализации. Инвентаризация строк, поиск зашитого текста, оценка объёма и точек риска.
2. Схема ключей. Единый формат именования, группы по разделам, правила для переменных и вложенности.
3. Настройка i18n. Подключение библиотеки, каталоги переводов, плюрализация, форматы дат, чисел и валют.
4. Шрифты и вёрстка. Подбор начертаний с полным набором символов, проверка переносов и растяжения блоков.
5. Тестирование. Прогон сценариев на белорусском, проверка длинных строк, псевдолокализация, регресс по остальным языкам.
6. Документация. Регламент добавления строк, глоссарий терминов, инструкция для контент-менеджера.
7. Передача. Демонстрация процесса, доступы к каталогам переводов, чек-лист для новых страниц.

Такой порядок убирает главную причину срывов — правки в вёрстке после того, как перевод уже готов. Строки и правила фиксируются до наполнения, поэтому новый язык добавляется копированием каталога, а не пересборкой шаблонов. Опишите вашу задачу — вернёмся с оценкой объёма и планом работ.

Артефакты локализации: файлы переводов, схемы ключей, регламенты

Локализация — это не только переведённые строки, но и набор артефактов, по которым команда дальше работает без нас. Ниже — что именно остаётся у заказчика на руках после вывода белорусской версии.

• Файлы переводов — исходные каталоги строк в формате, который читает ваша платформа (JSON, YAML или PO), с разделением по пространствам имён: интерфейс, письма, ошибки, юридические тексты. Каждый файл версионируется в репозитории, поэтому история правок и откат доступны так же, как для кода.
• Карта ключей — таблица соответствия: ключ, значение на белорусском, контекст использования, экран или шаблон, где строка выводится. По ней редактор без доступа к коду понимает, что и где менять, а разработчик видит, какие ключи ещё не задействованы.
• Регламент обновления — порядок действий при добавлении новой строки: кто заводит ключ, как он попадает в каталог, какие проверки проходят переводы перед выкладкой. Без этого правила локализация расползается уже на втором релизе.
• Политики доступа — роли для переводчиков, редакторов и разработчиков: кто может править тексты, кто только предлагает изменения, кто утверждает. Права разграничены так, чтобы правка строк не открывала доступ к остальной системе.
• Инструкции для редакторов — как работать с плюрализацией и падежными формами белорусского, какие термины считаются утверждёнными, где смотреть глоссарий. Отдельно фиксируем правила для чисел, дат и валют.
• Схема подключения шрифтов и раскладок — какие начертания используются для белорусских символов, как проверена корректность отображения на разных устройствах и в разных браузерах.
• Чек-лист приёмки — набор проверок перед релизом: полнота перевода, отсутствие обрезанных строк в интерфейсе, корректная работа переключателя языков, сохранение выбора пользователя.

Эти артефакты передаём в вашем репозитории и в виде читаемой документации — чтобы поддержку можно было вести своими силами или передать другой команде без восстановления контекста с нуля.

Кейс: как белорусская версия ускорила загрузку и убрала дубли

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

Что было до

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

Что изменили

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

Что стало

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

Яндекс и другие поисковые системы такие сигналы учитывают одинаково — корректные языковые метаданные снимают конкуренцию версий между собой.

Чем отличается локализация от перевода и когда нужна плюрализация

Перевод — это замена строк в интерфейсе. Локализация — это когда сайт ведёт себя как本地ный: числа, даты, форматы адресов, порядок имени и фамилии, разделители разрядов, валюта, единицы измерения и правила склонения подставляются по правилам языка, а не по остаточному принципу. Перевели кнопку — получили перевод. Настроили i18n — получили продукт, который не ломается при смене языка.

Ключевая разница проявляется на динамических данных. Строка «5 товаров» при переводе превращается в две формы, а в белорусском их больше: «1 тавар», «2 тавары», «5 тавараў». Если в коде зашита одна форма, при любом количестве выведется «тавараў» — и это заметит каждый носитель. Поэтому плюрализация — не украшение, а обязательный слой поверх словаря.

Правила склонения в белорусском опираются на три категории: единственное число, немногочисленное (2, 3, 4) и множественное (5 и больше, а также 11–14). Числительные вроде 21, 22, 25 наследуют форму последней цифры, но 11–14 всегда идут по множественному. Это описывается в правилах ICU-плюрализации, и движок сам выбирает нужную форму по числу — программисту не нужно писать условия вручную.

Отдельная история — падежи. «1 тавар у кошыку», «2 тавары ў кошыку», «5 тавараў у кошыку» — предлог и окончание меняются вместе с числом. Если строки собираются конкатенацией, порядок слов и падежи развалятся при первом же изменении фразы. Поэтому локализация требует целых шаблонов с подстановкой, а не склейки кусков.

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

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

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

Как поддерживать переводы, когда контент меняется каждую неделю?

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

Что с SEO — не потеряем ли позиции в поиске?

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

Если ваш случай не попал в эти три — опишите задачу, вернёмся с оценкой и планом работ.

Обсудим вашу задачу по локализации сайта на белорусский

Чтобы оценка локализации на белорусский была точной, а не «на глаз», нам нужен доступ к исходникам или к рабочей копии проекта. Дальше мы смотрим, как устроен вывод текста: статичные строки в шаблонах, строки из базы, тексты в скриптах и письмах — у каждого источника свой способ подключения словарей. От этого зависит и объём работ, и то, где плюрализация и падежи потребуют ручных правил, а где обойдётся стандартной конфигурацией.

Отдельная часть оценки — вёрстка и шрифты. Белорусские «ў» и «і» ломают макеты, рассчитанные на кириллицу без этих знаков: строки становятся длиннее, кнопки переносятся, обрезаются заголовки. Мы заранее проверяем, поддерживают ли подключённые шрифты нужные глифы, и закладываем в план замену гарнитуры или настройку резервных начертаний.

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

Что войдёт в работу:

• инвентаризация всех источников текста и оценка объёма перевода;
• настройка словарей и переключателя языков без потери текущих адресов страниц;
• правила плюрализации и склонений для белорусского;
• проверка шрифтов и правка вёрстки под удлинение строк;
• локализация служебных писем, уведомлений и системных сообщений;
• тестовый стенд с обоими языками и чек-лист приёмки;
• регламент поддержки и порядок добавления новых строк.

Опишите задачу — какой у вас проект, на каком этапе локализация и что уже сделано по переводу. Вернёмся с оценкой сроков и планом работ, разложенным по этапам.

Работы ведём на профессиональном оборудовании и с проверенным набором инструментов — клиент получает предсказуемый результат без сюрпризов при обновлениях.