Przejdź do treści
Wszystkie przewodniki
Poradnik krok po kroku30 min czytania

Jak zlokalizować zrzuty ekranu w App Store w ponad 30 językach

Praktyczny przewodnik po publikowaniu zlokalizowanych zrzutów ekranu w App Store i Google Play bez forkowania szablonów dla każdego języka. Obejmuje strukturę kluczy tłumaczeniowych, równoległe renderowanie wielu wersji językowych, obsługę RTL, fallbacki czcionek oraz automatyczną kontrolę jakości układu.

Eric Isensee
Eric IsenseeFounder · Last updated 5 maja 2026

TL;DR

Wyodrębnij każdy podpis do klucza tłumaczeniowego, tłumacz klucze (a nie grafiki), a następnie wyślij jedno żądanie API z listą wersji językowych. Screenshots.live renderuje wszystkie wersje językowe równolegle z tego samego szablonu — RTL, CJK i nadpisania per język obsługuje renderer.

Po co w ogóle lokalizować zrzuty ekranu?

Badania deweloperskie Apple pokazują, że użytkownicy znacznie chętniej instalują aplikację, gdy jej strona w App Store jest w ich ojczystym języku. To samo udokumentowano w liście kontrolnej lokalizacji Google: zlokalizowane strony konwertują lepiej i wyżej rankują w wyszukiwarce. Tłumaczenie jedynie metadanych — tytułu, podtytułu, słów kluczowych — bez tłumaczenia zrzutów ekranu to najczęstszy półśrodek, który zostawia realną konwersję na stole, bo główny zasób wciąż jest po angielsku.

Dla większości zespołów blokerem jest aspekt operacyjny, a nie strategiczny. Ręczne przetłumaczenie zestawu pięciu zrzutów ekranu na 30 języków oznacza 150 plików projektowych, 150 cykli przeglądu i 150 okazji do literówki. Rozwiązaniem jest traktowanie zrzutów ekranu jak każdego innego zlokalizowanego UI: klucze w kodzie, teksty w TMS, układ renderowany w kroku build.

Jak ustrukturyzować klucze tłumaczeniowe?

Stosuj tę samą strukturę kluczy co w tłumaczeniach wewnątrz aplikacji. Grupuj klucze według ID zrzutu ekranu, a następnie według roli elementu:

translations/en.json
json
{
  "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."
    }
  }
}

I odpowiadający temu plik niemiecki:

translations/de.json
json
{
  "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"
    }
  }
}

Klucze nigdy się nie zmieniają. Zmieniają się tylko wartości. Tłumacze pracują na kolumnie wartości w swoim TMS, nie dotykając szablonu Screenshots.live.

Jakich kodów wersji językowych używać?

Stosuj BCP-47 konsekwentnie. Używaj samego podtagu języka, gdy nie ma wariantu regionalnego (de, fr, ja) i dodawaj region tylko wtedy, gdy warianty znacząco się różnią (en-GB vs en-US, pt-BR vs pt-PT, zh-Hans vs zh-Hant). Zarówno Apple, jak i Google akceptują BCP-47, choć ich wewnętrzne kody nieco się różnią — zobacz listę wersji językowych App Store Connect oraz obsługiwane języki Google Play. Zmapuj je raz w skrypcie CI.

Jak rozesłać renderowanie do wszystkich wersji językowych?

API przyjmuje ID szablonu, katalog tłumaczeń i tablicę wersji językowych. Zwraca jeden wyrenderowany plik PNG na każdą wersję językową i każde urządzenie:

render.sh
bash
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"
    }
  }'

Pod maską renderer paralelizuje pracę po wersjach językowych i urządzeniach. Renderowanie 12 wersji językowych × 4 urządzenia — 48 plików PNG — zazwyczaj kończy się w mniej niż 90 sekund. Pełny kształt żądania znajdziesz w dokumentacji renderowania API.

Jak obsłużyć języki pisane od prawej do lewej?

Arabski (ar), hebrajski (he), perski (fa) i urdu (ur) wymagają lustrzanego odbicia całego układu — wyrównania tekstu, pozycji obrazów, ikon strzałek, a nawet kolejności grup wieloelementowych. Częściowe odbicie (samo odwrócenie tekstu bez zmiany układu) wygląda nieprawidłowo dla rodzimych użytkowników i podważa wiarygodność.

W Screenshots.live oznacz szablon atrybutem direction: "auto", a renderer automatycznie odwróci układ, wyrównanie tekstu i ozdobne strzałki podczas renderowania wersji RTL. Nadpisz pojedyncze elementy wartością direction: "ltr", gdy coś musi pozostać od lewej do prawej (numer telefonu, URL, blok kodu).

A co z nadpisaniami tekstu per wersja językowa?

Niektóre języki po prostu nie mieszczą się w tym samym polu podpisu. Niemieckie rzeczowniki złożone potrafią być o 40% dłuższe niż angielskie; japońskie i chińskie mogą być o 50% krótsze. Pozwól na nadpisania tekstu per wersja językowa bez forkowania szablonu:

translations/overrides.json
json
{
  "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": "ワンコールで全サイズ対応。"
  }
}

A co z czcionkami i znakami CJK?

Czcionki dla pisma łacińskiego (Inter, SF Pro, Roboto) często nie zawierają znaków CJK, cyrylicy, dewanagari czy arabskich — tekst renderuje się jako kwadraciki tofu. Skonfiguruj fallbacki czcionek per pismo:

  • Łacińskie / cyrylica / greckie: Inter, SF Pro, Roboto
  • CJK (japoński / koreański / chiński): Noto Sans CJK
  • Arabski / perski / urdu: Noto Sans Arabic, IBM Plex Sans Arabic
  • Dewanagari (hindi): Noto Sans Devanagari
  • Tajski: Noto Sans Thai, Sarabun

Rodzina Noto pokrywa wszystkie pisma obsługiwane przez Apple i Google. Ustaw ją jako łańcuch fallbacków w szablonie — renderer dobiera odpowiednią czcionkę dla każdego punktu kodowego, bez ręcznej interwencji.

Jak prowadzić QA układów w skali?

Ręczny przegląd 30 wersji językowych nie skaluje się. Zautomatyzuj oczywiste tryby awarii:

  • Przepełnienie tekstu: wyrenderuj w jednej czwartej rozdzielczości, zrób OCR wyniku, porównaj ze stringiem źródłowym. Niezgodności oznaczają, że tekst został przycięty.
  • Brakujące znaki: policz kwadraciki tofu w wyrenderowanym pliku PNG za pomocą modelu wizyjnego lub histogramu pikseli na unikodowym znaku zastępczym.
  • Puste tłumaczenia: zatrzymaj build, jeśli jakakolwiek wersja językowa ma więcej niż 5% brakujących kluczy względem angielskiej.
  • Limity długości: ustaw twardy limit długości per klucz. Jeśli niemieckie tłumaczenie go przekroczy, zatrzymaj build, zamiast pozwolić, by przepełnienie poszło na produkcję.

Jak przesłać zrzuty ekranu per wersja językowa?

Zarówno App Store Connect, jak i Google Play akceptują zrzuty ekranu per wersja językowa. Fastlane deliver czyta z fastlane/screenshots/<locale>/, a Fastlane supply czyta z fastlane/metadata/android/<locale>/images/phoneScreenshots/. Zmapuj wyjście swojego renderera na te ścieżki, a reszta to po prostu fastlane deliver / fastlane supply --skip_upload_apk.

Co dalej?

Połącz to z naszym poradnikiem automatyzacji CI/CD, aby lokalizacja uruchamiała się przy każdym wydaniu. Skorzystaj z funkcji obsługi wielu platform, aby rozsyłać do iOS, Androida i sklepów webowych z tego samego katalogu.

Ponad 30 wersji językowych, jeden szablon

Generuj wszystkie te rozmiary automatycznie

Przestań ręcznie zmieniać rozmiar zrzutów ekranu. Zaprojektuj jeden szablon i wyrenderuj każdy rozmiar, urządzenie i język jednym wywołaniem API.

Zacznij za darmo — wypróbuj Screenshots.live