10 января, 2026 Вкл. 10 января, 2026

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

Ваш сайт на WordPress перерос границы одной страны? Вы разрабатываете тему или плагин для международного сообщества? Тогда вы сталкиваетесь с двумя взаимосвязанными, но разными задачами: мультиязычность (i18n) — техническая возможность сайта работать на нескольких языках, и локализация (l10n) — адаптация контента и интерфейса под культурные и языковые особенности региона. Это не просто перевод кнопки «Submit». Это работа с переводами строк в коде, валютами, форматами дат, SEO-дублями и сложными переключателями. Давайте разберём всё: от выбора плагина для многоязычного сайта до правильной подготовки вашего кода для перевода.

Краткое содержание

Часть 1: Мультиязычность для сайтов: обзор плагинов и стратегий

Есть три основных подхода, каждый со своими плюсами и минусами.

Подход / Плагин	Как работает	Идеален для	Главный недостаток
Polylang	Создаёт отдельные записи/страницы для каждого языка, связывая их между собой.	Сайтов с полным контролем над контентом на каждом языке, где переводы не всегда 1:1.	Нет автоматического перевода (только в связке с сервисами).
WPML (платный)	Мощный комбайн. Также создаёт связанные дубли контента, но с огромным количеством настроек, поддержкой тем/плагинов и службой перевода.	Крупных коммерческих проектов с большим бюджетом и нуждой в экосистеме.	Высокая цена, может замедлять сайт.
Weglot / TranslatePress	Работают на уровне отображения: сканируют фронтенд, переводят текст и подменяют его через JavaScript или PHP. Можно редактировать.	Быстрого запуска мультиязычности на уже готовом сайте без переделки структуры.	Переводы могут быть неточны, SEO-реализация требует внимания.
Мультисайт (Multisite) с разными языками	Физически отдельные сайты в сети, каждый на своём языке. Управление — общее.	Очень крупных проектов с разными командами для каждого региона/языка.	Сложная синхронизация контента и настроек между сайтами.

Вывод: Для полного контроля и качества — Polylang или WPML. Для скорости и простоты — Weglot. Для полного разделения — Multisite.

Часть 2: Техническая подготовка темы/плагина к переводу (i18n для разработчиков)

Это обязательный этап, если вы хотите, чтобы вашу тему или плагин могли переводить.

1. Загрузка текстового домена (Text Domain):
В главном файле темы (style.css) или плагина укажите:

/*
Text Domain: my-awesome-theme
Domain Path: /languages
*/

В коде (например, в functions.php) загрузите переводы:

add_action( 'after_setup_theme', 'mytheme_load_textdomain' ); function mytheme_load_textdomain() { load_theme_textdomain( 'my-awesome-theme', get_template_directory() . '/languages' ); }

2. Оборачивайте ВСЕ строки для перевода в функциях:

__() — возвращает переведённую строку. Используйте для присвоения переменной.
php
```
$button_text = __( 'Read More', 'my-awesome-theme' );
```
_e() — выводит переведённую строку на экран.
php
```
_e( 'Posted on', 'my-awesome-theme' );
```

_n() — для множественного числа.

printf( _n( '%s comment', '%s comments', get_comments_number(), 'my-awesome-theme' ), get_comments_number() );

_x() — строка с контекстом, чтобы переводчик понимал, где она используется.
php
```
echo _x( 'Post', 'verb, to post something', 'my-awesome-theme' );
```

3. Никогда не разбивайте строки для перевода:

// ПЛОХО: Переводчик не поймёт контекст. echo __( 'Welcome, ', 'my-theme' ) . $username . __( ' to our site!', 'my-theme' ); // ХОРОШО: Цельная строка с плейсхолдером. printf( __( 'Welcome, %s to our site!', 'my-theme' ), $username );

Часть 3: Создание файлов перевода (.pot, .po, .mo)

Создайте POT-файл (шаблон): Используйте инструменты вроде Poedit (настройте сканирование PHP-файлов) или команду WP-CLI:
bash
```
wp i18n make-pot /path/to/your-theme/ /path/to/your-theme/languages/my-theme.pot
```
Этот файл содержит все строки, готовые для перевода.
Переводчики создают PO-файлы: На основе POT они создают my-theme-ru_RU.po (читаемый человеком файл) и вносят туда перевод.
Компиляция в MO-файл: Poedit или WP-CLI компилируют PO в бинарный .mo файл, который WordPress использует для быстрой загрузки переводов.
bash
```
wp i18n make-mo /path/to/your-theme/languages/
```
Автоматизация через package.json: Для продвинутых тем можно настроить сборку переводов как часть процесса сборки (используя @wordpress/scripts).

Часть 4: Локализация (l10n): что кроме текста?

Форматы даты и времени: Используйте встроенные функции WordPress date_i18n() и настройки из админки.
php
```
echo date_i18n( get_option( 'date_format' ), strtotime( $post->post_date ) );
```
Числа, валюты, единицы измерения: Для WooCommerce или каталогов используйте функции локализации WC (wc_price()) или PHP-функцию number_format_i18n().
RTL (справа налево) поддержка: В style.css укажите RTL stylesheet: rtl.css. WordPress автоматически подключит его для RTL-языков (арабский, иврит). Пишите CSS-правила с учётом margin-left/margin-right, используйте логические свойства (margin-inline-start).
Локализация медиа: Иногда для разных регионов нужны разные изображения (например, с другими людьми или надписями). Реализуйте через ACF или специальные плагины мультиязычности.

Часть 5: SEO для мультиязычных сайтов: hreflang и не только

Без этого поисковики запутаются в дублях и понизят ранжирование.

Атрибут hreflang: Указывает поисковику, что у страницы есть аналоги на других языках. Плагины вроде Polylang, WPML генерируют их автоматически, но нужно проверить в исходном коде.
html
```
<link rel="alternate" hreflang="ru" href="https://site.ru/page/" /> <link rel="alternate" hreflang="en" href="https://site.ru/en/page/" /> <link rel="alternate" hreflang="x-default" href="https://site.ru/" />
```
Разные домены или поддомены? site.de, de.site.com или site.com/de/?
- Разные домены (site.de): Лучше для локального SEO, но сложнее в управлении.
- Поддомены (de.site.com): Технически проще.
- Подпапки (site.com/de/): Рекомендуемый способ. Проще, всё на одном домене, разделение логичное.
  Выбор зависит от проекта, но подпапки — часто лучший старт.
Локализация SEO-метатегов: Убедитесь, что у каждой языковой версии страницы свой уникальный Title, Description и ключевые слова на целевом языке.

Часть 6: Пользовательский опыт (UX) для многоязычного сайта

Языковой переключатель: Должен быть интуитивным. Используйте флаги? Внимание: Флаг — это символ страны, а не языка (испанский в Испании и Мексике — один язык, но разные флаги). Лучше использовать названия языков на самом языке (e.g., «Español», «English»).
Определение языка браузера: Можно автоматически перенаправлять пользователя на подходящую языковую версию, но всегда оставляйте выбор и возможность переключиться.
Локализация форм: Поля «Имя» и «Фамилия» в разных культурах имеют разный порядок и значение. Адаптируйте, если возможно.

Заключение

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

Чек-лист для разработчика:

Все ли строки в моём коде обёрнуты в функции перевода (__(), _e())?
Создал ли я .pot файл и положил в папку /languages?
Использую ли я date_i18n() и подобные функции для локализуемых данных?
Протестировал ли я тему с RTL-языком?

Чек-лист для владельца сайта:

Выбрал ли я стратегию и плагин (Polylang/WPML/Weglot), соответствующий моим ресурсам?
Настроил ли я атрибуты hreflang и проверил в Google Search Console?
Удобен ли языковой переключатель для пользователя?
Все ли метаданные и ALT-теги изображений переведены?

Интернет глобален. Дайте вашему контенту шанс быть услышанным на многих языках.