Internationalization, или i18n, — подготовка продукта к работе с разными языками и региональными правилами. Localization, или l10n, — адаптация для конкретной аудитории: перевод, форматы, контент и культурные особенности. Переведённые кнопки не гарантируют, что пользователь сможет ввести адрес, понять сумму или получить документ на нужном языке.
Для QA это сквозная проверка пользовательской цепочки. Язык интерфейса, регион, часовой пояс и валюта связаны, но не равны друг другу. Человек может читать по-русски, находиться в Казахстане и оформлять заказ в евро. Продукт должен обрабатывать именно согласованную модель настроек.
Откуда берётся локаль
Уточните приоритеты: URL, настройка профиля, выбор в интерфейсе, системный язык или заголовок браузера. Проверьте первый визит, повторный вход, другую вкладку и переход по внешней ссылке. Неявная смена языка после авторизации часто возникает из-за конфликта этих источников.
Запишите отдельные правила для гостя и пользователя с профилем. Переключение языка должно сохранять смысл текущей страницы и введённые данные в пределах требований. Если выбранный перевод недоступен, нужен определённый fallback, а не случайная смесь языков.
Перевод и полнота контента
Проверяйте основной интерфейс, валидацию, пустые состояния, сообщения сервера, письма, уведомления и выгрузки. Строки, которые QA видит редко, чаще остаются на исходном языке. Поиск пропущенных ключей полезно автоматизировать, но он не оценивает смысл перевода.
Отдельно проверяйте переменные, множественное число, род и склонения. Склейка «Удалено» плюс число плюс «файлов» легко ломает грамматику. Для примера используйте 0, 1, 2, 5, 11 и 21 объект, сверяя ожидаемые формулировки с утверждённым переводом.
Макет и направление письма
Длинный перевод не должен прятать действие или перекрывать цену. Псевдолокализация помогает находить жёстко заданные размеры и непереводимые строки до готовности переводов. Она не подтверждает естественность языка и корректность регионального контента.
Для письма справа налево проверяют направление, порядок навигации, смешанный текст, номера и иконки. Не каждую иконку следует зеркалить: смысл конкретного элемента определяют дизайн и правила продукта. Убедитесь также, что выделение, копирование и редактирование смешанной строки остаются понятными.
Числа, деньги и единицы
Разделители тысяч и дробной части различаются. Поле может показывать «1 234,50», но передавать в API нормализованное число. QA проверяет и отображение, и разбор ввода, и итоговый расчёт, чтобы форматирование не превратилось в изменение суммы.
Валюта — отдельное бизнес-значение, а не просто символ рядом с числом. Не меняйте её автоматически только из-за языка, если такой логики нет в требованиях. Проверяйте точность, округление, отрицательные суммы, нулевые значения и совпадение суммы в интерфейсе, письме и документе.
Даты и часовые пояса
Разделяйте календарную дату, локальное время и момент времени. День рождения не должен сдвигаться при смене часового пояса. Встреча, напротив, может показываться в местном времени пользователя с сохранением одного момента на сервере.
Сформируйте примеры около полуночи и на границах месяцев. Если продукт работает в регионах с сезонным переводом часов, добавьте неоднозначное и отсутствующее локальное время. Проверяйте, что фильтр «за день» использует согласованный часовой пояс, а не настройки компьютера тестировщика по умолчанию.
Имена, адреса и поиск
Не ограничивайте тестовые имена латиницей. Используйте пробелы, дефисы, апострофы, диакритические знаки и длинные значения в рамках требований. Не у каждой страны есть привычный для команды индекс, область или одинаковый порядок частей адреса.
Поиск и сортировка требуют собственных правил: учитываются ли регистр, диакритика, разные формы записи? Проверьте одинаковый текст после копирования из внешнего источника. Визуально похожие Unicode-строки могут иметь разное внутреннее представление; ожидание нормализации должно быть согласовано с разработчиками.
Практический пример: международная доставка
Для тестового магазина подготовьте два профиля с разными языками, один заказ в фиксированной валюте и адрес с нелатинскими символами. Зафиксируйте сумму, время создания и идентификатор заказа до переключений.
- 1.Откройте заказ по прямой ссылке и смените язык. Ожидается сохранение заказа, валюты, количества и введённого адреса.
- 2.Введите дробное количество допустимым для выбранной локали способом. Ожидается однозначная нормализация либо понятная ошибка до отправки некорректной суммы.
- 3.Сравните время в двух часовых поясах. Ожидается тот же момент времени и корректная локальная дата по правилам продукта.
- 4.Получите тестовое письмо и документ. Ожидаются согласованные язык, сумма и адрес без потерянных символов.
Проверяйте язык ошибок отдельно: серверный отказ при неправильном индексе не должен возвращать пользователю внутренний ключ перевода.
Доступность и технические признаки
У веб-страницы должен быть корректный язык документа, а у фрагментов на другом языке — соответствующие признаки, когда они нужны. Это влияет на произношение экранного диктора и другие средства обработки текста. Перевод видимой подписи не гарантирует перевод доступного имени элемента.
Для альтернативных языковых URL проверьте навигацию, сохранение параметров и согласованные метаданные. Эти проверки дополняют редакторскую оценку, но не заменяют её. Естественность формулировок и культурную уместность лучше подтверждать с человеком, владеющим языком аудитории.
Ошибки и критерии завершения
Главные ошибки — отождествлять язык со страной, проверять только главную страницу, копировать ожидаемые строки из самого приложения и считать автоматический перевод окончательным эталоном. Ещё одна ловушка — исправить обрезанную подпись уменьшением шрифта, сделав интерфейс трудным для чтения.
Готовность подтверждают пройденные ключевые сценарии, полнота перевода, правильность региональных данных и отсутствие блокирующих проблем ввода. В отчёте полезно разделить технические дефекты, вопросы перевода и отсутствующие продуктовые правила: исправляют их разные специалисты.