Визуальное тестирование многоязычных сайтов: обнаружение i18n-регрессий, которые никто не проверяет
Многоязычное визуальное тестирование: процесс автоматизированной проверки визуальной целостности сайта или приложения на всех его языковых версиях, обнаруживающий специфические для интернационализации регрессии — переполнения текста, поломки RTL-layout, проблемы типографских интервалов, усечения и визуальные несоответствия между языками.
Мы ведём сайт на 9 языках. Это не маркетинговое заявление — это ежедневная операционная реальность, которая научила нас тому, что большинство команд обнаруживают слишком поздно: каждый язык ломает ваш интерфейс по-своему.
Интернационализация (i18n) — хорошо документированная техническая проблема на стороне разработки. Современные фреймворки корректно обрабатывают файлы переводов, маршрутизацию по locale, форматы дат и чисел. Что плохо документировано — и ещё хуже тестируется — это визуальное влияние каждого языка на вёрстку.
Согласно данным W3C Internationalization Working Group, длина текста может варьироваться от 50% до 300% между языками для одного и того же контента. Кнопка «Submit» по-английски — «Absenden» по-немецки и «Envoyer» по-французски. Одна и та же CSS, разная ширина текста. И именно здесь начинаются проблемы.
Почему многоязычные сайты — визуальный кошмар
Большинство команд разработки проектируют и тестируют интерфейс на одном языке — обычно английском. Дизайн утверждается на английском. Функциональные тесты выполняются на английском. Демо для клиента проводится на английском. А когда приходят переводы, они внедряются в интерфейс без систематической визуальной проверки.
Это равносильно тому, как если бы вы построили дом с мебелью определённого размера, а затем заменили её предметами разных размеров, не проверив, проходят ли они в двери.
Проблема длины текста
Немецкий — бич дизайнеров интерфейсов. Английское слово «settings» по-немецки превращается в «Einstellungen» — на 60% длиннее. «User management» — в «Benutzerverwaltung». «Download now» — в «Jetzt herunterladen».
Это не анекдотичные случаи. Согласно данным W3C, среднее расширение текста с английского на немецкий составляет 30% для предложений и может превышать 200% для отдельных слов (таких как подписи кнопок и пункты навигации). Финский, нидерландский и греческий демонстрируют аналогичное расширение.
Конкретный результат: кнопки, текст которых переносится на две строки и ломает layout. Меню навигации, где элементы перекрываются. Заголовки, усечённые многоточием, тогда как английская версия отображается полностью. Карточки товаров, высота которых варьируется от одного языка к другому, создавая неровные сетки.
Проблема RTL-языков
Арабский, иврит, персидский и урду пишутся справа налево (RTL — Right To Left). Это не просто перевёрнутый текст — это весь layout, который должен быть зеркально отражён. Навигация справа, панель поиска слева, маркированные списки начинаются справа, направленные иконки (стрелки, шевроны) должны быть перевёрнуты.
CSS сделал значительный прогресс с логическими свойствами (margin-inline-start вместо margin-left, padding-inline-end вместо padding-right). Но на практике многие сайты всё ещё используют физические свойства, которые не инвертируются автоматически в RTL. И даже с логическими свойствами некоторые элементы требуют специальной обработки — тени, направленные градиенты, асимметричные скругления границ.
Типичные RTL-баги включают текст, начинающийся с неправильного края контейнера, элементы, перекрывающиеся из-за отступов в неверном направлении, направленные иконки, указывающие не туда, метки и поля форм, которые не выровнены, а также смешанный контент (арабский текст с английскими техническими терминами), дающий непредсказуемые результаты отображения.
Проблема CJK-систем письма
Китайский, японский и корейский (CJK) создают уникальные типографские вызовы. CJK-символы моноширинные (каждый символ занимает квадрат одинаковой ширины), что создаёт визуально отличные интервалы от латинского текста. Правила переноса строк другие — китайский может разрывать строку между любыми символами, а японский имеет сложные правила о пунктуации в начале и конце строки.
Рендеринг CJK-шрифтов сложнее. Файлы шрифтов значительно тяжелее (полный китайский шрифт покрывает тысячи символов), что может влиять на время загрузки и создавать мерцание невидимого текста (FOIT) или мерцание нестилизованного текста (FOUT), которого не существует с латинскими языками.
Часто игнорируемый побочный эффект: CJK-символы имеют естественную высоту строки, отличную от латинских символов. line-height: 1.5, создающая воздушный, читаемый текст на английском, может казаться слишком тесной или слишком свободной на китайском. Настройка line-height для каждого языка возможна, но редко делается.
Проблема сложных скриптов
Тайский, хинди (деванагари), бенгальский и другие языки используют сложные скрипты, где символы комбинируются, складываются вертикально или меняют форму в зависимости от позиции в слове. Рендеринг этих скриптов сильно зависит от движка рендеринга браузера и используемого шрифта.
Хинди с комбинируемыми символами может потребовать большей высоты строки, чем ожидается. Тайский текст, не разделяющий слова пробелами, может создавать неожиданные переносы строк. Эти проблемы невидимы, если ваша команда не читает эти языки — а так часто и бывает.
Почему визуальное тестирование — единственный масштабируемый ответ
Перед лицом этих проблем классические подходы не работают.
Ручное тестирование носителями языка — самый интуитивный и наименее масштабируемый подход. Найти носителя для каждого из ваших языков, обучить его систематически проверять каждую страницу и повторять при каждом релизе — это роскошь, которую большинство команд не может себе позволить. И даже с носителями ручная проверка пропускает тонкие регрессии (изменение интервала на 4 пикселя невидимо невооружённым глазом при однократном просмотре).
Автоматизированные функциональные тесты проверяют, что переведённый контент присутствует, но не то, как он выглядит. Тест Playwright, проверяющий, содержит ли page.locator('.hero-title').textContent() непустой текст, пройдёт, даже если этот текст выходит за контейнер и перекрывает CTA-кнопку ниже.
Ревью дизайна по скриншотам — распространённая, но несистематическая практика. Кто-то делает скриншоты немецкой версии, публикует их в Slack-канале, дизайнер мельком просматривает их между встречами. Это лучше, чем ничего. Это далеко от достаточного.
Автоматизированное визуальное тестирование решает проблему в масштабе, потому что оно делает именно то, что ни один другой метод не делает надёжно: систематически сравнивает визуальный рендеринг каждой страницы, на каждом языке, при каждом релизе. Переполнение немецкого текста обнаруживается. Сломанный RTL-layout обнаруживается. Изменение китайских интервалов обнаруживается. Без вмешательства человека, без носителей языка, без ручного ревью.
Что конкретно обнаруживает многоязычное визуальное тестирование
Вот категории регрессий, которые визуальное тестирование систематически отслеживает на многоязычных сайтах.
Переполнения текста
Самый частый сценарий. CSS-контейнер имеет фиксированную ширину или max-width, которая подходит для английского, но не для немецкого или финского. Текст выходит за контейнер, перекрывает другие элементы или намеренно усекается.
Визуальное тестирование обнаруживает это, потому что переполнение меняет позицию или видимость элементов на странице. Это измеримая разница между baseline (где текст не переполнялся) и текущим захватом (где он переполняется).
Поломки RTL-layout
Компонент, отображающийся корректно в LTR, но чей layout сломан в RTL. Flexbox, направление которого не инвертируется. position: absolute; right: 10px, который в RTL должен быть left: 10px, но им не является. Асимметричный padding, создающий пространство не в том месте.
Эти баги особенно коварны, потому что команда разработки, которая обычно работает в LTR, никогда не видит их в своём ежедневном рабочем процессе. Визуальное тестирование делает их видимыми без необходимости переключать рабочий язык.
Несоответствия высоты компонентов
В сетке карточек, если одна карточка имеет более длинный заголовок на немецком, чем на английском, её высота увеличивается — что нарушает выравнивание всей сетки. Та же проблема возникает с кнопками, элементами навигации, строками таблиц и пунктами списков.
Визуальное тестирование отслеживает эти несоответствия, потому что оно сравнивает визуальную структуру полной страницы, а не изолированные элементы. Неровная сетка — обнаруживаемая разница.
Отсутствующие или некорректно отображаемые шрифты
Ваш сайт использует веб-шрифт, покрывающий латинские символы, но не арабские или китайские. Браузер возвращается к системному шрифту, меняя общий внешний вид страницы для этих языков. Или хуже — определённые символы отображаются как пустые прямоугольники (печально известные «тофу»).
Визуальное тестирование обнаруживает эти изменения типографского рендеринга, потому что английский baseline использует правильный шрифт, а если fallback даёт визуально отличный результат на другом языке, сравнение помечает это.
Проблемы локализованных изображений и иконок
Некоторые сайты локализуют изображения — скриншоты продукта на местном языке, переведённые маркетинговые баннеры, адаптированные для рынка иконки. Если локализованное изображение имеет неправильные размеры, неправильное соотношение сторон или усечённый текст, визуальное тестирование обнаруживает это так же, как любое другое визуальное изменение.
Наш опыт с 9 языками
Мы ведём delta-qa.com на 9 языках. Не ради тщеславия, а потому что наш рынок международный, и мы считаем, что каждый пользователь заслуживает опыта на своём языке.
Этот опыт научил нас урокам, которые мы хотели бы усвоить иначе.
Каждое добавление языка выявляет баги в существующих языках. Когда мы добавили арабскую версию (RTL), мы обнаружили, что некоторые компоненты имели жёстко заданные отступы (margin-left: 16px вместо margin-inline-start: 16px), которые не вызывали проблем в LTR, но ломали layout в RTL. Исправление этих компонентов улучшило качество кода для всех языков.
Переводы поступают непрерывно, не все сразу. Многоязычный сайт никогда не «завершён». Каждый новый контент, каждое изменение текста, каждое обновление документации должны быть переведены. И каждый перевод — потенциальная визуальная регрессия — более длинный текст, переполняющий контейнер, отсутствующий перевод, отображающий технический ключ, потерянное форматирование.
Ручная проверка 9 языков — фантазия. Визуально проверять каждую страницу на 9 языках после каждого развёртывания — это неподъёмный объём работы. Если на вашем сайте 30 страниц, это 270 проверок за развёртывание, не считая мобильных и планшетных viewport'ов. Автоматизированное визуальное тестирование — единственный реалистичный подход.
Многоязычные баги — последние в очереди на исправление. В иерархии приоритетов баг, влияющий только на финскую или японскую версию, систематически отправляется в конец очереди. Автоматизированное визуальное тестирование обеспечивает видимость этих багов, обнаруживая и сообщая о них на том же уровне, что и баги английской версии.
Как структурировать многоязычное визуальное тестирование
Если вы управляете многоязычным сайтом и хотите интегрировать визуальное тестирование, вот подход, который мы рекомендуем.
Определите матрицу покрытия
Вам, вероятно, не нужно тестировать каждую страницу на каждом языке при каждом релизе. Определите критические комбинации.
Языки высокого риска: языки с наибольшим расширением текста (немецкий, финский), RTL-языки (арабский, иврит) и CJK-языки (китайский, японский, корейский). Эти языки дают самые частые и самые заметные регрессии.
Страницы высокого риска: страницы с множеством короткого текста в ограниченных контейнерах (навигация, кнопки, формы, карточки товаров). Страницы с длинным контентом (статьи, документация) менее рискованны, потому что текст течёт естественно.
Приоритетная матрица — это пересечение обоих: тестируйте ваши страницы высокого риска на ваших языках высокого риска. Именно здесь вы найдёте 80% регрессий.
Создайте baseline для каждого языка
У каждого языка свой baseline. Немецкая версия вашей главной страницы — отдельный baseline от английской версии. При сравнении вы сравниваете сегодняшнюю немецкую версию с немецкой версией из последнего релиза — а не с английской версией.
Это важное различие. Многоязычное визуальное тестирование не сравнивает языки между собой (они должны быть разными). Оно сравнивает каждый язык с самим собой во времени, чтобы обнаруживать регрессии.
Автоматизируйте переключение языков
Чтобы эффективно захватывать разные языковые версии, ваш инструмент тестирования должен уметь переходить к каждой версии. С no-code инструментом вроде Delta-QA вы просто переходите по URL каждой языковой версии (например /de/, /ar/, /zh/), и инструмент захватывает соответствующий рендеринг.
Обрабатывайте динамический переведённый контент
Некоторый контент закономерно меняется между захватами — даты, цены, акции. Настройте ваш инструмент на исключение этих динамических зон из сравнения, иначе каждый захват будет вызывать ложные срабатывания на контенте, который меняется естественным образом.
Интегрируйте визуальное тестирование в workflow перевода
Самый рискованный момент для многоязычного сайта — не развёртывание кода, а обновление перевода. Новый файл перевода с более длинными строками, другим форматированием или отсутствующими ключами может сломать интерфейс. Запускайте визуальное тестирование после каждого обновления перевода, а не только после развёртываний кода.
Доступные инструменты
Выбор инструмента визуального тестирования для многоязычного сайта зависит от вашего технического контекста и объёма языков.
Delta-QA особенно хорошо подходит, потому что no-code-подход позволяет захватывать любую языковую версию просто переходом по URL. Структурный алгоритм нечувствителен к различиям рендеринга шрифтов между языками — он сравнивает CSS-свойства, а не пиксели. Это значительное преимущество при тестировании языков с разными системами письма, где типографский рендеринг существенно различается.
Playwright предлагает возможности screenshot-тестирования, которые можно параметризовать по locale, но каждое визуальное утверждение должно быть закодировано, а управление baseline'ами для каждого языка в Git-репозитории быстро становится сложным при большом количестве комбинаций язык/страница/viewport.
Percy и Applitools обрабатывают многоязычность через своё облако с возможностями группировки по языкам. Их модель оплаты за snapshot может стать дорогой, когда количество комбинаций язык/страница/viewport умножает количество захватов.
FAQ
Как бороться с текстом, переполняющим контейнер на определённых языках?
Визуальное тестирование обнаруживает переполнение, но исправление — задача дизайна и разработки. Технические решения включают использование гибких контейнеров (min-width вместо фиксированного width), overflow-wrap: break-word для очень длинных слов и условные CSS-классы для каждого языка для корректировки размеров шрифтов или интервалов при необходимости. Наиболее надёжный подход — проектировать сразу под самый длинный язык: если дизайн выдерживает немецкий, он выдержит всё.
Нужно ли тестировать все языки при каждом релизе?
Нет, если у вас много языков. Приоритизируйте, систематически тестируя языки высокого риска (немецкий, арабский, китайский) и страницы высокого риска (навигация, формы, карточки). Проводите полный прогон всех языков на всех страницах периодически — например раз в месяц — и при каждом крупном обновлении переводов.
Как тестировать RTL-языки, когда никто в команде не читает по-арабски?
Именно в этом заключается сила автоматизированного визуального тестирования: вам не нужно читать язык, чтобы обнаруживать регрессии. Инструмент сравнивает текущую RTL-версию с предыдущим RTL-baseline. Если layout изменился, если элемент сдвинулся, если текст переполняет контейнер — это обнаруживается независимо от языка. Вам не нужно знать арабский, чтобы заметить, что блок текста вышел за пределы контейнера.
Как отличить i18n-баг от намеренного изменения перевода?
Следуя стандартному workflow валидации: когда визуальное тестирование помечает различие, вы выясняете причину. Если различие соответствует задокументированному обновлению перевода, вы обновляете baseline. Если оно появилось без запланированного изменения перевода, это регрессия — изменение CSS, повлиявшее на конкретный язык, или отсутствующий ключ перевода, отображающий значение по умолчанию.
Каково SEO-влияние визуально сломанного многоязычного сайта?
Значительное. Google оценивает пользовательский опыт для каждого языка отдельно через Core Web Vitals и сигналы качества страницы. Сломанный layout на немецком с переполняющимся текстом и перекрывающимися элементами ухудшает сигналы качества для немецкой версии, независимо от качества английской версии. Каждая языковая версия оценивается отдельно. Систематическое визуальное тестирование обеспечивает согласованность качества на всех версиях.
Работает ли Delta-QA с CJK-шрифтами и сложными скриптами?
Delta-QA сравнивает вычисленные CSS-свойства, а не пиксели, что делает его нечувствительным к различиям типографского рендеринга между языками. Независимо от того, использует ли ваша страница латинские, китайские, арабские или деванагари символы, структурный алгоритм анализирует одни и те же свойства — размеры, позиции, цвета, интервалы. Если китайский символ меняет высоту элемента или арабское слово переполняет контейнер, изменение обнаруживается через структурные свойства, а не через сравнение пикселей.
Заключение
Многоязычный сайт — это не переведённый сайт. Это отдельный продукт на каждом языке — с визуальными, типографскими и layout-ограничениями, которые радикально различаются. Тестировать только английскую версию и надеяться, что остальные последуют — значит игнорировать реальность интернационализации.
Автоматизированное визуальное тестирование — единственный масштабируемый способ поддерживать визуальное качество на всех ваших языковых версиях. Оно обнаруживает то, что никто не проверяет — немецкие переполнения, арабские RTL-поломки, CJK-несоответствия — и делает это при каждом релизе, без носителей языка, без ручного ревью, без компромиссов.
Каждый ваш пользователь, независимо от языка, заслуживает интерфейса, который визуально работает. Многоязычное визуальное тестирование — это способ гарантировать это.