Аудит и тестирование локализации мобильных приложений

Тестирование локализации мобильного приложения: типовые сбои

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

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

Форматы дат, чисел и единиц — второй класс отказов. 03/12 читается как март или декабрь в зависимости от локали, запятая против точки в десятичных дробях ломает ввод в полях, а правила множественного числа для русского (1 товар, 2 товара, 5 товаров) не закрываются простой подстановкой числа. Арабский и иврит добавляют зеркальную раскладку: иконки, стрелки и прогресс-бары должны разворачиваться вместе с текстом.

Тестирование локализации мобильного приложения идёт по матрице «экран × язык × устройство»: самый узкий и самый широкий экран, крупный системный шрифт, заведомо длинные строки, раскладка справа налево. Каждый язык фиксируется скриншотами — так видно и сам сбой, и то, что после правки вёрстка не поехала в остальных локалях.

Что даёт аудит перед релизом: эффект в сроках и дефектах

Регулярный аудит локализации переводит языковые дефекты из разряда «нашёл пользователь» в разряд «нашла проверка». Время приёмки версии сокращается с двух-трёх дней ручной вычитки на нескольких языках до нескольких часов прогона проверок и разбора отчёта — при этом проверяется не только перевод, но и вёрстка интерфейса: обрезка строк в кнопках, переносы, порядок элементов в раскладках с письмом справа налево.

Главный источник проблем — регресс языковых версий. Строки меняются при доработке основной ветки, и языковая версия молча теряет часть перевода: формы множественного числа для языков, где их несколько, склонения, форматирование дат и разделителей разрядов. Без проверки на каждой сборке такой дефект уходит в публикацию и всплывает уже в отзывах.

Отдельная цена — сроки выпуска релиза. Языковой дефект находят после публикации, и цикл «заявка → исправление → повторная приёмка» в App Store сдвигает дату выпуска на дни, а если релиз уже согласован с продвижением — на неделю. Проверки перед отправкой на модерацию убирают этот класс простоев целиком.

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

Способы проверки: ручной прогон, автотесты, гибридный подход

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

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

Этапы внедрения: от аудита до передачи команде

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

Как выстроена последовательность

1. Инвентаризация строк. Собираем все ресурсы локализации: строковые файлы, текст в разметке и коде, пуш-уведомления, письма, описания в магазинах приложений. На выходе — карта, где виден объём по каждому языку и точки правок.

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

3. Критерии приёмки. Договариваемся, что считаем дефектом, а что — допустимым отклонением, и в каком виде принимается отчёт. Без этого спор о неудачной формулировке не закрыть.

4. Автоматические прогоны. Часть проверок подключаем к сборке: незаполненные строки, разъехавшиеся подстановки и выход за глоссарий останавливают сборку до ручного этапа.

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

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

7. Передача регламента. Отдаём карту строк, набор правил, шаблон отчёта и инструкцию по добавлению нового языка.

Пакет передачи: конфигурации, схемы, политики доступа

Результат аудита локализации — не отчёт «на память», а рабочий пакет передачи: конфигурации, схемы и регламенты, по которым ваша команда дальше проверяет переводы сама. Всё складывается в репозиторий проекта и версионируется вместе с кодом, поэтому пакет не устаревает после смены подрядчика или ухода инженера.

• Конфигурация проверок — правила на пустые и непереведённые строки, дубли ключей, расхождения в подстановках и переполнение элементов интерфейса; запускается одной командой локально и на сборочном сервере.
• Карта экранов — таблица «экран → элемент → ключ строки → языки → статус»: видно, какие места закрыты автоматикой, а какие остались на ручную проверку.
• Матрица локалей — языки с направлением письма, форматами дат, чисел и порядком сортировки; новые локали добавляются по этой же схеме, без перестройки процесса.
• Политики доступа — кто из команды, переводчиков и подрядчиков правит файлы перевода, кто только предлагает правки и как изменения попадают в основную ветку.
• Схема хранения строк — где лежат ресурсы по платформам, какие форматы обмена поддерживаются и как одна строка переиспользуется в нескольких экранах.
• Регламент релиза — короткий чек-лист перед выкладкой: прогон конфигурации проверок, подтверждение правок переводчиком, фиксация состояния строк под конкретную версию.

Пакет рассчитан на инженера без контекста: по нему проверка запускается в первый же день, а не после пересказа в переписке.

Кейс: аудит локализации сократил отказы после обновления

Что было до аудита

Приложение заказчика выходило на восьми языках, а перевод приезжал одним файлом за пару дней до сборки. В немецкой и арабской локалях обрезались кнопки и заголовки карточек, даты и суммы оставались в формате исходного языка, часть интерфейса вообще шла на английском. Дефекты находили пользователи: в отзывах в Google Play появились упоминания кривого перевода, а поддержка получала обращения по путанице в шагах оплаты. Оценить масштаб было нечем — сборка одна, логи по локалям не различались, проверяли на одном языке и одном устройстве.

Что изменили

• Псевдолокализация: строки искусственно удлиняли до перевода — обрезания в вёрстке видно до работы переводчиков.
• Автотесты интерфейса по локалям: снимки экранов сравнивались с эталоном, расхождение выше порога помечалось дефектом.
• Глоссарий: термины, склонения, правила множественного числа и обращение к пользователю.
• Форматы дат, чисел и разделителей — через системные средства локали, а не строковые шаблоны.
• Матрица устройств и размеров экрана, включая режим справа налево и крупный системный шрифт.
• Набор проверок приёмки версии, привязанный к релизной ветке.

Метрики до и после

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

Чем отличается проверка перевода от приёмочных прогонов?

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

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

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

Разница подходов задаёт порядок работ. Сначала закрывают текстовый слой — правка в ресурсах не требует пересборки и повторного прогона. Затем идёт приёмочный прогон на каждой целевой языковой среде: установка, первый запуск, покупка, переключение языка на ходу. Успешный прогон на одной локали не гарантирует, что то же место не сломается на другой.

Сборки и форматы: частые вопросы перед стартом

Перед стартом аудита локализации всплывает один и тот же набор вопросов: как передать сборку, где искать строки, в каком порядке идут прогоны и что делать после правок. Ниже — короткие ответы, чтобы старт не растянулся на переписку.

Часть текстов приходит с сервера — вы их тоже покрываете?

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

В каком порядке идут прогоны?

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

Правки внесли — проверять всё заново?

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

Обсудим задачу: что нужно для оценки и плана

Чтобы вернуться с оценкой объёма и планом работ, а не с общими словами, нам нужны сборка и понимание, какие рынки для вас приоритетны. Ниже — то, что мы обычно запрашиваем на первом разговоре: если чего-то нет, часть данных восстановим сами по коду и тестовым учётным записям.

• Перечень локалей и приоритет рынков — от него зависит, сколько языковых веток проверяем вручную, а сколько закрываем псевдолокализацией и регулярными проверками.
• Файлы локализации в исходном виде (.strings, .xml, .json, XLIFF, ARB) и глоссарий — по ним видно, где перевод уже разошёлся с интерфейсом.
• Тестовая сборка и доступы: учётные записи, стенды, тестовые платёжные сценарии, канал внутреннего распространения сборок.
• Карта экранов с приоритетом: регистрация, оплата, оформление заказа, уведомления — их проверяем первыми и подробнее.
• Ограничения по длине строк и правила оформления дат, чисел, единиц измерения, адресов и телефонов.
• Требования к стилю и тону текста, а также кто на вашей стороне утверждает спорные формулировки.
• Релизный график: к какой дате нужен отчёт и есть ли окно на исправления до публикации.
• Какие дефекты локализации встречались раньше и что уже проверяли — чтобы не дублировать работу.

С таким набором мы размечаем объём проверок по локалям и сценариям, называем порядок старта и точки, где нужны доступы с вашей стороны. Опишите задачу в свободной форме — вернёмся с оценкой объёма и планом работ.