Тестирование мультиязычных веб-приложений в Playwright опирается на точную эмуляцию пользовательских локалей, проверку корректности переключения языков, валидацию форматов дат и чисел, а также устойчивость локализованных интерфейсов к изменениям перевода. Подход требует систематизации, поскольку одно и то же действие может приводить к различным результатам в зависимости от выбранного языка и региона.
Playwright предоставляет механизмы управления локалью и параметрами
браузера. При запуске браузера можно указать locale, что
влияет на отображение интерфейсов, числовых форматов и календарей.
Пример настройки:
const { chromium } = require('@playwright/test');
(async () => {
const browser = await chromium.launch();
const context = await browser.newContext({
locale: 'fr-FR'
});
const page = await context.newPage();
await page.goto('https://example.com');
})();Важный момент: параметр locale отвечает за региональные
особенности. Для проверки только языка иногда достаточно симуляции
переключателя языка в самом приложении, если логика не привязана к
системным настройкам браузера.
Многие приложения используют собственный UI-переключатель. В тестах важно удостовериться, что:
• переключатель меняет видимый язык всех ключевых элементов • переключение не ломает верстку и не вызывает переполнений контейнеров • локализованный контент подтягивается асинхронно без артефактов
Пример перехода на другой язык внутри сценария:
await page.click('[data-testid="lang-switch-en"]');
await expect(page.locator('h1')).toHaveText('Welcome');Ключевой момент — тестирование не только перевода, но и поведения при задержках загрузки локализованных ресурсов.
Мультиязычные приложения адаптируют:
• формат даты • формат времени • формат числа и валюты • правила сортировки • регистр и слоги в локалях с особой морфологией
Например, при установке en-US дата может отображаться
как 12/31/2025, в de-DE —
31.12.2025. Для чисел 1,234.56 против
1 234,56.
Пример проверки формата цены:
await expect(page.locator('.price')).toHaveText(/^\d{1,3}(\s?\d{3})*,\d{2} €$/);Регулярные выражения помогают адаптировать проверки под различные нормы, избегая жёстких строковых сравнений.
Локализованный контент может быть:
• статическим: строки, хранящиеся в JSON-наборах или
.po/.xliff • динамическим:
данные, приходящие с сервера в зависимости от локали
Тестирование статических ресурсов фокусируется на корректности ключей и отсутствии пропущенных переводов. В динамическом случае важна синхронизация CDN, кэширование и состояние пользователя (например, настройки в профиле).
Для приложений с серверным рендерингом требуется проверить, что
локаль передаётся на сервер корректно через заголовки
Accept-Language или пользовательские параметры в URL.
Контексты Playwright упрощают тестирование разных локалей параллельно. Для каждого набора можно создать собственный конфигурационный блок:
const locales = ['en-US', 'ru-RU', 'es-ES'];
for (const locale of locales) {
test(`localization test for ${locale}`, async ({ browser }) => {
const context = await browser.newContext({ locale });
const page = await context.newPage();
await page.goto('https://app.test/');
await expect(page.locator('[data-testid="title"]')).toBeVisible();
});
}Такой подход масштабируется при добавлении новых языков.
В мультиязычных приложениях с SSR и SPA-подходами важно отслеживать:
• наличие тегов hreflang
• переключатели регионов •
канонические URL • корректность редиректов по
локали
Тесты должны фиксировать корректность метаданных так же строго, как визуальное отображение. Ошибки в SEO-метках приводят к дублированию индексации и неправильным региональным выдачам.
Переводы приводят к изменению длины строк. Тесты обязаны учитывать сценарии разрыва верстки:
• длинные немецкие и финские термины • фразы с указанием валют • уплотнение и переносы текста в азиатских языках
Проверки могут использовать визуальные снапшоты Playwright. Снапшоты фиксируют рендеринг и позволяют выявлять расхождения при переключении локали.
RTL-языки (арабский, иврит) меняют направление интерфейса. В тестах важно удостовериться, что:
• dir="rtl" устанавливается на нужные
элементы • порядок иконок и кнопок корректен
• таблицы и формы читаются справа налево
Азиатские локали требуют проверки:
• отсутствия пробельных зависимостей • поддержки иероглифов в инпутах • корректного выбора шрифтов
Playwright способен рендерить такие интерфейсы без дополнительной конфигурации, но тестировать изменения необходимо отдельно.
Формы адаптируются под локаль: валюты, даты, разделители и сообщения об ошибках. Например, некорректная дата может генерировать разные тексты ошибок.
Использование селекторов по ключам локализации предпочтительнее строкового сравнения. Вместо проверки полного текста часто применяются частичные проверки или тестирование ключей.
await expect(page.locator('.error-msg')).toContainText('invalid-date');Сами ключи остаются стабильными, независимо от перевода.
Мультиязычные приложения могут подгружать большие словари. При тестировании обращают внимание на:
• время загрузки ресурсов • поведение при холодном старте • влияние кэша браузера и CDN
В Playwright можно использовать трассировки и HAR-запись для анализа загрузки.
await context.tracing.start({ snapshots: true, screenshots: true });
// действия
await context.tracing.stop({ path: 'trace.zip' });Для мультиязычности удобно структурировать тесты по уровням:
UI-уровень: проверка отображения и целостности Данные: валидация форматов Инфраструктура: проверка заголовков и метаданных Интерактивность: переключение локали без перезагрузки Кросс-браузерность: локали в разных движках могут трактоваться по-разному
Такой подход помогает выстроить устойчивую и расширяемую систему тестирования.
В мультиязычных проектах часто используется fallback-язык. Тесты фиксируют:
• корректный откат к дефолтной локали • отсутствие пустых строк • поведение UI при недостающих ключах
При серверной локализации fallback может срабатывать на стороне API, что также требует проверки.
CI-конвейеры запускают мультиязычные тесты параллельно с помощью Playwright Test runner. Распараллеливание сокращает время выполнения. Важный аспект — генерация отчётов, где ошибки разбиваются по локалям, упрощая анализ.
Стратегия полезна при добавлении нового языка: весь набор тестов запускается на нём, позволяя выявить узкие места перевода и вёрстки.