Как локализовать скриншоты App Store на 30+ языков

Зачем вообще локализовать скриншоты?

Собственное исследование разработчиков Apple показывает, что пользователи значительно чаще устанавливают приложение, когда страница в App Store представлена на их родном языке. То же самое описано в чек-листе локализации Google: локализованные карточки лучше конвертируют и выше ранжируются в поиске. Перевод только метаданных — заголовка, подзаголовка, ключевых слов — без перевода скриншотов является самой распространённой полумерой и оставляет реальную конверсию на столе, потому что главный визуальный актив остаётся на английском.

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

Как структурировать ключи перевода?

Используйте ту же структуру ключей, что и для переводов внутри приложения. Группируйте ключи по ID скриншота, затем по роли элемента:

{
  "screenshots": {
    "01_home": {
      "headline": "Build faster.",
      "subhead": "Ship every store size in one API call.",
      "badge": "New"
    },
    "02_pricing": {
      "headline": "Plans for every team.",
      "cta": "Start free"
    },
    "03_api": {
      "headline": "Built for developers.",
      "subhead": "REST, Fastlane, and GitHub Actions out of the box."
    }
  }
}

Затем соответствующий немецкий файл:

{
  "screenshots": {
    "01_home": {
      "headline": "Schneller bauen.",
      "subhead": "Alle Store-Formate mit einem API-Call.",
      "badge": "Neu"
    },
    "02_pricing": {
      "headline": "Pläne für jedes Team.",
      "cta": "Kostenlos starten"
    }
  }
}

Ключи никогда не меняются. Меняются только значения. Переводчики работают со столбцом значений в своей TMS, не затрагивая шаблон Screenshots.live.

Какие коды локалей использовать?

Используйте BCP-47 единообразно. Применяйте только подтег языка, если нет региональных вариаций (de, fr, ja), и добавляйте регион только тогда, когда варианты значимо различаются (en-GB и en-US, pt-BR и pt-PT, zh-Hans и zh-Hant). И Apple, и Google принимают BCP-47, хотя их внутренние коды немного различаются — см. список локалей App Store Connect и поддерживаемые языки Google Play. Сопоставьте их один раз в своём CI-скрипте.

Как развернуть рендеринг по локалям?

API принимает ID шаблона, каталог переводов и массив локалей. В ответ возвращается по одному отрисованному PNG на каждую локаль и устройство:

curl -X POST https://api.screenshots.live/v1/renders \
  -H "Authorization: Bearer $SCREENSHOTSLIVE_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "templateId": "tpl_app_release_v3",
    "locales": ["en", "de", "es", "fr", "pt-BR", "it", "nl", "ja", "ko", "zh-Hans", "ar", "he"],
    "devices": ["iphone-6.7", "iphone-6.1", "ipad-12.9", "phone-android"],
    "translations": {
      "en": "@translations/en.json",
      "de": "@translations/de.json",
      "es": "@translations/es.json"
    }
  }'

Под капотом рендерер распараллеливает работу по локалям и устройствам. Рендеринг 12 локалей × 4 устройства — 48 PNG-файлов — обычно завершается менее чем за 90 секунд. Полный формат запроса см. в документации API по рендерингу.

Как обрабатывать языки с письмом справа налево?

Арабский (ar), иврит (he), персидский (fa) и урду (ur) требуют зеркалирования всего макета — выравнивания текста, положения изображений, иконок-стрелок и даже порядка групп из нескольких элементов. Частичное зеркалирование (только переворот текста, но не макета) выглядит для носителей языка неправильно и подрывает доверие.

В Screenshots.live пометьте шаблон как direction: "auto", и рендерер автоматически перевернёт макет, выравнивание текста и декоративные шевроны при отрисовке RTL-локалей. Переопределяйте отдельные элементы значением direction: "ltr", когда что-то должно остаться слева направо (номер телефона, URL, блок кода).

А как насчёт переопределений текста для отдельных локалей?

Некоторые языки просто не помещаются в один и тот же блок подписи. Немецкие составные существительные могут быть на 40% длиннее английских; японский и китайский — на 50% короче. Разрешите переопределения текста для отдельных локалей без создания форка шаблона:

{
  "screenshots.01_home.headline": {
    "en": "Build faster.",
    "de": "Schneller bauen.",
    "fi": "Rakenna nopeammin.",
    "ja": "もっと速く。"
  },
  "screenshots.01_home.subhead": {
    "en": "Ship every store size in one API call.",
    "de": "Alle Formate mit einem Aufruf.",
    "ja": "ワンコールで全サイズ対応。"
  }
}

А как насчёт шрифтов и глифов CJK?

Шрифты латиницы (Inter, SF Pro, Roboto) часто не имеют глифов CJK, кириллицы, деванагари или арабицы — текст отображается как пустые квадратики (тофу). Настройте фолбэки шрифтов для каждой системы письма:

• Латиница / Кириллица / Греческий: Inter, SF Pro, Roboto
• CJK (японский / корейский / китайский): Noto Sans CJK
• Арабский / Персидский / Урду: Noto Sans Arabic, IBM Plex Sans Arabic
• Деванагари (хинди): Noto Sans Devanagari
• Тайский: Noto Sans Thai, Sarabun

Семейство Noto покрывает все системы письма, поддерживаемые Apple и Google. Установите его как цепочку фолбэков в шаблоне — рендерер выберет правильный шрифт для каждой кодовой точки без ручного вмешательства.

Как проводить QA макетов в масштабе?

Ручная проверка 30 локалей не масштабируется. Автоматизируйте очевидные сценарии сбоев:

• Переполнение текста: отрисуйте в четверти разрешения, прогоните результат через OCR, сравните с исходной строкой. Несовпадения означают, что текст был обрезан.
• Отсутствующие глифы: посчитайте квадратики тофу в отрисованном PNG с помощью vision-модели или гистограммы пикселей по символу замены Unicode.
• Пустые переводы: завершайте сборку с ошибкой, если в какой-либо локали отсутствует более 5% ключей по сравнению с английским.
• Бюджеты по длине: установите жёсткое ограничение длины для каждого ключа. Если немецкий перевод его превышает, валите сборку, а не давайте переполнению попасть в релиз.

Как загружать скриншоты по локалям?

И App Store Connect, и Google Play принимают скриншоты для каждой локали. Fastlane deliver читает из fastlane/screenshots/<locale>/, а Fastlane supply — из fastlane/metadata/android/<locale>/images/phoneScreenshots/. Сопоставьте вывод вашего рендерера с этими путями — и всё, что останется, это fastlane deliver / fastlane supply --skip_upload_apk.

Что делать дальше?

Объедините это с нашим руководством по автоматизации CI/CD, чтобы локализация запускалась при каждом релизе. Используйте возможность мультиплатформенной поддержки, чтобы развернуть генерацию на iOS, Android и веб-магазины из одного и того же каталога.