Ответ.

Первая волна автоматизации тестирования практически не касалась проверки локализации (i18n), поскольку основные рынки ориентировались на англоязычный интерфейс. Однако по мере глобализации приложений требования к качеству локализации выросли: интерфейс должен отображаться корректно на всех поддерживаемых языках, а текстовые ресурсы и форматированные строки должны подгружаться корректно в зависимости от выбранной локали.

Основная проблема — ручная проверка очень затратна, а автоматические тесты сложны из-за вариативности формата, контекста, специфики языков (например, право-налево или грамматические особенности). Возможно отсутствие перевода фрагмента, ошибки форматирования, нарушения верстки.

Решения включают работу с тестовыми данными для каждой локали, использование snapshot-тестов, сравнение UI-элементов с эталонами, внедрение проверяющих утилит по принципу "ключ-значение" для ресурсных файлов, автоматизированное извлечение и сравнение строк через API-интерфейсы и регулярную прогонку линтеров на ресурсных файлах.

Ключевые особенности:

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

Вопросы с подвохом.

Можно ли сделать универсальный тест, который валидирует любую локаль одним скриптом?

Отчасти да, но нюансы языков (падежи, род, направление ввода) часто требуют ручных корректировок или дополнительных условий в таких тестах. 100% универсальность невозможна.

Если файл перевода есть и успешно подгружен, значит ли это, что i18n-тест пройден?

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

Имеет ли смысл автоматизировать тестирование локализации для языков с < 1% пользователей?

Да, если бизнес-критичность даже одного пользователя велика, например, при выполнении контрактных обязательств или для рынков с особыми требованиями. Автоматизация существенно экономит ресурсы против ручных проверок.

Типовые ошибки и анти-паттерны

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

Пример из жизни

Негативный кейс

Команда внедрила автотесты на сравнение ключей в .po-файле с оригинальным английским текстом, считая, что одного этого достаточно. UI-тесты не писали — в релизе арабской версии оказалось, что весь текст съехал за пределы кнопок, а некоторые строки не переводились вовсе из-за неправильных ключей.

Плюсы:

Быстрое внедрение автоматизации по i18n.

Минусы:

Низкий уровень покрытия реальных пользовательских сценариев.
Существенные UX-ошибки остались незамеченными.

Позитивный кейс

Была реализована связка линтинга ресурсов и автотестов, которые каруселили интерфейс по всем языкам, делали скриншоты и сравнивали их с эталонной разметкой. Обнаружив смешение RTL/LTR элементов, команда обнаружила корневую причину и устранила её до релиза.