Метаданные изображений и работа с медиа в многоязычном WordPress

Что меняется вместе с языком, а что должно оставаться общим

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

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

Альтернативный текст: переводите смысл, а не имя файла

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

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

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

Подписи: переводите, когда они являются частью повествования страницы

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

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

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

Метаданные вложений: в основном общие, иногда учитывающие язык

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

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

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

Имена файлов и SEO изображений: полезно для поиска, но по умолчанию не цель перевода

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

С точки зрения SEO изображений имена файлов всё же могут иметь значение, потому что они влияют на то, как ресурс называется и организуется. Но в многоязычном WordPress более сильный языковой сигнал обычно исходит от окружающего текста страницы, переведённого альтернативного текста, подписей и собственной структуры маршрутизации и каноникализации страницы. Одно лишь переведённое имя файла не делает изображение по-настоящему локализованным, если видимый текст вокруг него остаётся на другом языке.

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

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

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

Такое разделение полезно, потому что оно позволяет избежать ненужного дублирования двоичных ресурсов. Оно также означает, что медиатека и слой контента не обязаны следовать одной и той же модели перевода. Изображение может быть общим для всех языков, в то время как метаданные на уровне страницы, которые его описывают, локализуются для каждого языка.

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

Как решить, что переводить

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

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

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