Симптом: после перевода подпись кнопки не помещается, а статичный макет этого не показывает. Быстрое решение: сначала просмотрите нужные языки в Xcode 27, затем проверьте критические экраны в симуляторе или на целевом устройстве; для этого дизайнеру нужен доступ к открываемому проекту, а не только к изображениям.
Эта последовательность подходит UI-дизайнерам, которым нужно найти обрезанный текст и сдвиги до передачи приложения пользователям. Она также поможет продуктовой команде договориться с разработчиком и локализатором о том, кто проверяет перевод, кто — поведение интерфейса и где фиксируются замечания.
Перед началом: согласуйте область проверки
Приёмка многоязычного интерфейса — не повторное согласование перевода и не проверка одного экспортированного экрана. Ваша задача — убедиться, что конкретные локализованные строки помещаются в реальный интерфейс, элементы не перекрываются, а направление чтения не противоречит языку. Затем нужно установить, сохраняется ли ожидаемое поведение при запуске приложения.
Нужен проект, который можно открыть в Xcode, или чётко оговорённый способ запустить подготовленный разработчиком предварительный просмотр. Из одного набора PNG или макетов в Figma вы не узнаете, как приложение ведёт себя с длинной динамической подписью, куда переносится текст при изменении доступной ширины и меняется ли расположение элементов при другом направлении письма.
Перед началом распределите ответственность:
- Дизайнер описывает ожидаемую компоновку и отмечает, какие элементы критичны: например, основная кнопка, заголовок, меню или уведомление об ошибке.
- Разработчик предоставляет проект и сведения о готовности экранов к проверке, а также помогает воспроизвести поведение, которое нельзя оценить в статичном макете.
- Локализатор или продуктовый редактор подтверждает, что строка действительно является актуальным переводом. Если перевод отсутствует или спорен, дизайнер не должен по умолчанию объявлять это дефектом вёрстки.
Для самого инструмента также важно зафиксировать версию: Apple указывает выпуск Xcode 27 от 14 сентября 2026 года в официальной записи о выпуске. Проверяйте проект в той версии, которую согласовали с командой, и сверяйтесь с примечаниями к выпуску Xcode 27, если поведение предварительного просмотра отличается от ожидаемого. Не переносите выводы о тестовой версии на стабильный выпуск без отдельного подтверждения.
Что подготовить до открытия проекта? Попросите разработчика передать актуальную версию проекта, указать доступный сценарий предпросмотра и назвать языки, которые уже заведены. Попросите локализатора пометить строки, требующие редакторского решения. Так вы не потратите время на диагностику интерфейса вокруг текста, который команда ещё не утвердила.
Передача проекта: подготовьте проверяемый набор
До первого просмотра сформируйте короткий перечень страниц и строк, по которым команда будет судить о готовности. В него стоит включить экран с основным действием, навигацию, форму с ошибкой или подтверждением и место с длинным описанием. Важно не количество экранов, а наличие разных типов текста и компонентов: короткая кнопка может выглядеть нормально, пока длинный заголовок или системное сообщение не начинает занимать дополнительную строку.
Сверьте перечень языков с разработчиком. Нельзя предполагать, что все переводы уже включены в проект или доступны в предпросмотре. Если выбранная локаль не появляется, сначала выясните, добавлена ли она и подключены ли необходимые строки; иначе вы можете записать отсутствие перевода как ошибку компоновки.
Попросите команду приложить ожидаемое поведение для спорных мест: допустим ли перенос кнопки на две строки, должен ли заголовок обрезаться или увеличивать высоту блока, как расположены элементы в интерфейсе справа налево. Уточнение этого контракта избавит от разночтений, когда один участник считает перенос приемлемым, а другой воспринимает его как поломку.
Распределите файлы и доступы заранее. Если вам предоставили только готовую сборку, вы сможете проверить запуск и переходы, но не обязательно получите тот же способ просмотра, что доступен в проекте. Если передан лишь макет, запросите у разработчика проект или демонстрацию нужного состояния. Windows-дизайнеру следует заранее согласовать доступ к Mac-среде с Xcode: макет в Figma остаётся полезным для сравнения, но сам по себе не открывает проект и не заменяет запуск приложения.
Первый проход: проверьте языковые версии в предпросмотре
SwiftUI Previews удобны для быстрого просмотра состояния интерфейса в процессе подготовки. Чтобы предварительный просмотр локализаций был полезен, попросите разработчика предоставить рабочую точку входа в проект, а затем переключайте локаль по согласованному перечню. Apple описывает предварительный просмотр локализаций в Xcode; если настройка недоступна в переданном проекте, не пытайтесь трактовать это как ошибку перевода — уточните, готова ли соответствующая конфигурация.
Для каждой локали проходите один и тот же сценарий:
- Посмотрите, действительно ли отображается выбранный язык, а не базовый вариант интерфейса.
- Сверьте заметные подписи с утверждённым переводом; если он расходится, отметьте это как вопрос к локализатору, не исправляя его самостоятельно.
- Проверьте основные действия, навигацию, сообщения об ошибках и длинные пояснения.
- Отмечайте конкретный экран, язык, текст и поведение: например, кнопка стала выше, соседний элемент перекрыт или фраза обрезана.
- Сделайте снимок состояния, который команда сможет сопоставить с проектом и ожидаемой компоновкой.
Не используйте предпросмотр как автоматическую проверку переводов. Он помогает увидеть выбранную конфигурацию и расположение элементов, но не решает, естественна ли формулировка, точен ли смысл и все ли строки переведены. Это отдельная работа локализатора и редактора. Аналогично отсутствие ошибки в одном состоянии не доказывает, что другие страницы или варианты текста ведут себя так же.
Компоновка и направление: разделите причины дефекта
После первого просмотра сгруппируйте замечания не по языкам, а по типу проблемы. Это ускоряет передачу команде: текстовая ошибка уходит редактору, дефект поведения — разработчику, а изменение ожидаемой иерархии — владельцу дизайн-решения.
- Текст и перевод: смысл не совпадает, терминология непоследовательна, строка отсутствует или требует редакторского решения. Передайте исходный и отображаемый варианты локализатору.
- Компоновка: текст обрезан, элемент перекрывает соседний, кнопка или блок не сохраняют нужную высоту. Передайте разработчику снимок и точное состояние экрана.
- Дизайн-решение: после перевода меняется визуальный акцент, длинный заголовок нарушает иерархию или прежняя плотность интерфейса выглядит неприемлемо. Согласуйте ожидаемый вариант с продуктовой командой до исправления.
- Направление: проверьте, соответствует ли порядок элементов ожиданиям языка с письмом справа налево. Не ограничивайтесь зеркальным расположением всей страницы: отдельно оцените навигацию, значки, поля и последовательность действий.
Не фиксируйте замечание словами «сломалась вёрстка». Укажите локаль, страницу, точный текст, ожидаемое и фактическое состояние, а также приложите снимок. Такой отчёт помогает отличить проблему строки от проблемы отображения и быстрее найти ответственного.
Запуск приложения: подтвердите поведение в симуляторе
Предпросмотр отвечает на вопрос о выбранном состоянии компоновки, но не заменяет проверку запущенного приложения. Переходите к симулятору, когда дефект может зависеть от навигации, действия пользователя, динамических данных или поведения нескольких экранов вместе. Если разработчик подготовил запускаемую сборку, согласуйте способ воспроизведения и снова выберите проверяемую локаль.
В симуляторе пройдите именно пользовательский сценарий, который может изменить состояние интерфейса: откройте нужную страницу, активируйте действие, проверьте ошибочное или подтверждённое состояние и вернитесь назад. Если текст появляется после ответа сервера или зависит от введённых данных, сохраните условия воспроизведения; снимок экрана без этого контекста может не помочь команде повторить проблему.
Проверьте критичные экраны при разных размерах окна или устройства, если такая проверка входит в задачу. Не делайте вывод, что все размеры поведут себя одинаково, исходя из одного скриншота. Доступность конкретных вариантов запуска зависит от проекта и согласованного окружения; документация Apple о запуске на симуляторах и физических устройствах описывает этот этап отдельно от предварительного просмотра.
Может ли языковой предпросмотр заменить симулятор? Нет, если нужно проверить переходы, динамическое содержимое или состояние приложения после действий пользователя. Предпросмотр пригоден для первичной проверки локализованного вида; симулятор позволяет пройти согласованный сценарий запуска. А если приёмка требует особенностей реального устройства, симулятор также не даёт окончательного подтверждения — потребуется проверка на целевом оборудовании. Apple отдельно описывает тестирование локализаций при запуске приложения.
И симулятор, и предварительный просмотр имеют границы. Они не доказывают автоматически, что все реальные устройства, настройки и пользовательские данные дадут одинаковый результат. Не пишите в отчёте «проверено на всех устройствах», если команда проверила только один сценарий в симуляторе. Укажите фактическую среду и оставьте целевое устройство для тех случаев, где это входит в критерии приёмки.
Выбор способа проверки: сопоставьте задачу и среду
Ниже — рабочее сравнение вариантов. Оценки качественные: они обозначают пригодность для указанной задачи, а не гарантируют одинаковую доступность каждого сценария во всех проектах.
| Способ | Что удобно проверить | Ограничение | Оценка для приёмки |
|---|---|---|---|
| Статичный макет или снимок | Сравнение с утверждённым визуальным решением | Не показывает поведение проекта, выбранную локаль при запуске и динамические состояния | Низкая как единственный способ |
| SwiftUI Previews в Xcode | Быстрый просмотр подготовленных состояний и локализаций | Не подтверждает все пользовательские сценарии и качество перевода | Высокая для первичного просмотра |
| Запуск в симуляторе | Навигацию, реакции интерфейса и динамические состояния в согласованном сценарии | Не является проверкой на целевом физическом устройстве | Высокая для проверки поведения |
| Запуск на целевом устройстве | Финальное поведение в согласованной физической среде | Требует самого устройства и соответствующего доступа | Наивысшая для тех случаев, где устройство входит в критерии |
Как провести такую приёмку, если основная рабочая машина работает под Windows? Не пытайтесь заменить Xcode экспортом из Figma: попросите разработчика предоставить проект и согласовать среду Mac, в которой вы сможете открыть его или проверить подготовленный запуск. Если проект требует действий, доступных только разработчику, зафиксируйте совместный сеанс и заранее определите, кто управляет запуском. Такой порядок помогает дизайнеру участвовать в проверке, не превращая её в самостоятельную настройку сборки.
Закрытие проверки: оформите замечания и повторите контроль
Чтобы замечания не терялись между дизайном, разработкой и переводом, используйте одну запись на каждый воспроизводимый дефект. Включите:
- локаль и точную страницу или состояние;
- отображаемую строку и, если важно, утверждённый вариант;
- шаги, после которых появляется проблема;
- фактический результат и ожидаемое поведение;
- снимок экрана и способ проверки — предпросмотр, симулятор или целевое устройство;
- ответственного: разработчика, локализатора или участника, принимающего дизайн-решение.
В отчёте отделяйте «не проверено» от «проверено, дефекта нет». Если физическое устройство не использовалось, укажите это явно. Apple описывает отдельные сценарии локализационной проверки при запуске, но наличие такой документации не означает, что одна процедура автоматически покрывает ваш продукт и все его пользовательские состояния.
Для повторяющейся работы с проектами на Mac сравните удалённый доступ с разовой помощью разработчика и собственной техникой. В руководстве MACGPU по удалённому Mac можно сверить общие условия такого рабочего сценария, а страница вариантов аренды MACGPU поможет оценить доступные коммерческие условия. Не выбирайте среду только по названию устройства: сначала проверьте, подходит ли она для доступа к нужному проекту, привычного управления интерфейсом и согласованного способа работы с симулятором.
Если у вас есть открываемый проект, начните с языкового предпросмотра, затем проверьте проблемные сценарии в симуляторе и оставьте проверку на целевом устройстве для случаев, где она требуется. Если Windows не позволяет выполнить нужную часть работы и самостоятельные проверки придётся повторять, удалённый Mac может быть удобнее ожидания свободного времени разработчика — при условии, что вам не нужны физические интерфейсы и команда согласовала такой доступ. На этом этапе сравните текущий процесс с арендой MACGPU: постоянная зависимость от чужого расписания, невозможность самостоятельно открыть проект и отсутствие регулярной среды для повторной проверки — реальные ограничения, но удалённая среда не заменит проверку на устройстве. Прежде чем выбирать её, посмотрите руководство MACGPU и убедитесь, что условия доступа соответствуют именно вашему проекту и критериям приёмки.