Тестирование мультиязычности String Catalog: как автоматизировать удалённый Mac в 2026 году?

Статус перевода в редакторе нельзя считать доказательством готовности релиза. String Catalog действительно предназначен для управления языками, переводами, формами множественного числа и вариантами устройств, что описано в официальной документации о String Catalog. Но у многоязычного релиза есть как минимум три независимых слоя:

• извлечение — попала ли строка из SwiftUI, UIKit, storyboard, XIB или другого ресурса в каталог;
• использование — отображается ли нужный перевод в конкретном языке и регионе, не ломается ли интерполяция и разметка;
• поставка — вошли ли локализованные ресурсы в итоговый Archive и дальнейшую экспортируемую сборку.

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

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

Автоматизация должна начинаться с типа проекта, а не с одинакового набора команд. SwiftUI, UIKit и смешанные приложения имеют разные точки риска.

SwiftUI и новые строки

В SwiftUI строка должна быть вызвана способом, который система локализации может извлечь. Правила подготовки текста в SwiftUI и других частях кода описаны в документации Apple об извлечении локализуемых строк. Поэтому проверка должна искать не только пустые переводы, но и места, где разработчик использовал обычную строку вместо локализуемого API.

Минимальный набор тестовых примеров должен включать:

• короткий заголовок и длинную подпись;
• строку с одним или несколькими параметрами;
• форму множественного числа;
• значение, зависящее от устройства или доступной ширины;
• резервный вариант при отсутствии перевода.

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

UIKit и смешанные ресурсы

В старом проекте String Catalog может сосуществовать с .strings, .stringsdict, storyboard, XIB и локализуемыми значениями из Info.plist. Нельзя считать переход завершённым только потому, что часть ключей появилась в новом каталоге. Сначала нужно составить карту источников:

1. отметить, какие строки принадлежат App Target, расширению или Framework;
2. найти старые файлы и проверить, не дублируются ли их ключи в каталоге;
3. собрать приложение;
4. открыть Bundle каждого компонента;
5. пройти экран, который использует старый ресурс;
6. только после этого переносить следующий модуль.

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

Важно: отсутствие строки в редакторе, отсутствие перевода в каталоге и отсутствие ресурса в Archive — разные дефекты. Для каждого нужно сохранять отдельное свидетельство, иначе исправление будет основано на предположении.

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

• язык интерфейса;
• региональные форматы даты и времени;
• валюта и разделители чисел;
• формы множественного числа;
• направление письма справа налево;
• размер устройства и доступная ширина;
• наличие расширения, виджета или другого Target.

В Test Plan язык приложения и регион нужно задавать как независимые параметры. Это позволяет отличить перевод от формата данных: один и тот же язык может использоваться в разных регионах, а одинаковый регион не гарантирует одинаковую длину текста. Возможности Test Plan для организации и параметризации тестов описаны в официальном руководстве Apple.

Практический набор конфигураций строится так:

1. выбрать языки, которые действительно поддерживает приложение;
2. добавить по одному представителю для каждого важного регионального формата;
3. выбрать устройство, на котором критический экран имеет ограниченную ширину;
4. добавить вариант с направлением письма справа налево, если он поддерживается;
5. связать конфигурации с одним и тем же ключевым сценарием;
6. исключить комбинации, которые не проверяют отдельное условие.

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

String Catalog можно проверять в непрерывной интеграции, если разбить процесс на независимые задания. Одна длинная команда скрывает, на каком этапе возникла проблема: при извлечении, в симуляторе, при создании снимка или в Archive.

Рекомендуемая последовательность выглядит так:

1. Подготовить исходный код. Зафиксировать Scheme, Test Plan и список Target, затем убедиться, что рабочая копия не зависит от локального пути разработчика.
2. Проверить извлечение. Собрать проект и сопоставить ожидаемые ключевые сценарии с содержимым String Catalog. Новая строка должна либо попасть в каталог, либо иметь документированное исключение.
3. Экспортировать ресурсы при необходимости. Сохранить экспорт в отдельный артефакт, чтобы переводчик или ревьюер видел изменения, а не только зелёный статус в Xcode.
4. Запустить языковые конфигурации. Использовать Test Plan для выбранных языков и регионов, а не менять параметры вручную между прогонами.
5. Сохранить UI-доказательства. Архивировать скриншоты, логи и результат тестов с понятным именем конфигурации.
6. Собрать итоговый Archive. Проверить наличие ожидаемых локализаций в Bundle App, расширений и Framework.
7. Разделить решение. Ошибку перевода, визуальный дефект и сбой тестовой инфраструктуры направить в разные очереди исправления.

Команды xcodebuild следует запускать с явным указанием Scheme, Test Plan и каталога результатов. Важно сохранять файл .xcresult: он содержит структуру тестового запуска и помогает повторно проверить причину ошибки, вместо того чтобы ориентироваться на короткое сообщение в консоли.

Удалённый Mac особенно полезен, когда проекту требуется постоянная среда с Xcode, симуляторами и тестовыми результатами. Для этого нужно проверить не только SSH-доступ. UI-тесты могут зависеть от графического сеанса, состояния симулятора, доступности Keychain и корректного входа пользователя. Поэтому процедура приёмки должна включать:

• запуск задания после разрыва SSH-сессии;
• повторный запуск после перезагрузки хоста;
• сохранение .xcresult и снимков в отдельный каталог;
• повторное выполнение после исправления одной строки;
• отсутствие зависимости от вручную открытого окна Xcode;
• понятное сообщение, если симулятор или графическая среда недоступны.

Описание локального тестирования разных вариантов языка стоит использовать вместе с настройками Test Plan, а не вместо них. Если локальный компьютер не может постоянно хранить среду сборки, можно сначала оценить варианты удалённого Mac для задач разработки, а затем отдельно проверить, соответствует ли выбранный доступ требованиям графических UI-тестов.

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

Чек-лист доказательств

• [ ] Все критические строки извлекаются ожидаемым способом.
• [ ] Для параметров и множественного числа проверены значения, а не только наличие ключа.
• [ ] Старые .strings и .stringsdict имеют владельца и план миграции.
• [ ] App, Extension и Framework проверены как отдельные источники ресурсов.
• [ ] В Test Plan разделены язык приложения и регион.
• [ ] Проверены даты, числа, валюты и направление письма там, где это важно.
• [ ] UI-тесты выполняются без ручного переключения параметров.
• [ ] Скриншоты содержат имя языка, региона и конфигурации.
• [ ] .xcresult сохраняется после каждого значимого прогона.
• [ ] Archive содержит ожидаемые локализации.
• [ ] Дефект перевода не смешан со сбоем удалённого хоста.
• [ ] После исправления есть повторный запуск того же сценария.

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

Как находить пропущенные строки

Сравниваются три источника: каталог, извлечённые ресурсы и ключевые пользовательские сценарии. Если строка видна в исходном коде, но не отображается в String Catalog, сначала проверяется способ вызова локализации. Если ключ есть в каталоге, но интерфейс показывает исходный текст, проверяются Bundle, Target и выбранный язык запуска.

Как проверять языки и регионы пакетно

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

Можно ли включить String Catalog в CI

Можно, если CI проверяет не только файл каталога. Минимальная цепочка включает сборку, выбранные языковые UI-тесты, сохранение результатов, создание Archive и проверку ресурсов в Bundle. При отсутствии графического сеанса этап UI нужно обозначить как недоступный, а не объявлять весь релиз успешно протестированным.

Как организовать удалённые UI-тесты и снимки

На удалённом Mac фиксируются Scheme, Test Plan, симулятор и каталог артефактов. Задания запускаются так, чтобы продолжать работу после закрытия SSH-сеанса, а результаты копируются после завершения. До включения проверки в обязательный релизный шлюз нужно воспроизвести запуск после перезагрузки и убедиться, что снимки получают уникальные имена.

Что обязательно проверить до отправки приложения

Проверяются не только полнота переводов, но и текстовые ограничения, числа, даты, валюты, множественное число, направление письма, Bundle и реальные ключевые сценарии. Отдельно оцениваются сертификаты, подпись и загрузка, однако локализационный шлюз должен завершаться раньше, если в Archive отсутствует ожидаемый язык или интерфейс показывает резервный текст.

• Если проект использует несколько Target, требует UI-тестов и должен регулярно запускаться без локального компьютера, выбирается постоянно доступный удалённый Mac с сохранением результатов.
• Если нужны только редкие ручные проверки одного языка, достаточно локального Mac или краткосрочного доступа; постоянная аренда не обязательна.
• Если сборка зависит от физического устройства, USB-периферии или длительной локальной отладки, следует оставить соответствующий локальный контур и не переносить на удалённый хост всё целиком.
• Если основная проблема — отсутствие стабильного места для Xcode, симуляторов и Archive, имеет смысл рассмотреть удалённую среду и заранее проверить условия доступа и поддержки.
• Если проект выполняет тяжёлые постоянные сборки и требует полного контроля над физическим оборудованием, нужно сравнить аренду с покупкой собственного Mac, учитывая обслуживание, доступность и резервный план.

Локальный ноутбук удобен для интерактивной работы, но его сон, нехватка диска, смена сети и занятость разработчика мешают регулярной проверке. Общая CI-среда без настоящего macOS не решает проблему Xcode, симулятора и Apple-специфичного Archive. Поэтому для временных релизных циклов или небольших команд аренда Mac у NUKCLOUD может оказаться практичнее покупки отдельного компьютера: среда доступна удалённо, а расходы не привязываются к приобретению оборудования. При этом для постоянной многолетней нагрузки и требований к физическим интерфейсам собственный Mac может быть рациональнее.

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