Zum Inhalt springen
Alle Leitfäden
Anleitung30 Min. Lesezeit

Wie man App-Store-Screenshots für 30+ Sprachen lokalisiert

Ein praktisches Playbook zum Ausliefern lokalisierter App-Store- und Google-Play-Screenshots, ohne Vorlagen pro Sprache zu forken. Behandelt Übersetzungsschlüssel-Struktur, Multi-Sprach-Fan-out, RTL-Handhabung, Schrift-Fallbacks und automatisierte Layout-QA.

Eric Isensee
Eric IsenseeFounder · Last updated 5. Mai 2026

TL;DR

Externalisieren Sie jede Bildunterschrift in einen Übersetzungsschlüssel, übersetzen Sie die Schlüssel (nicht die Artwork) und senden Sie dann eine API-Anfrage mit einer Liste von Sprachen. Screenshots.live rendert jede Sprache parallel aus derselben Vorlage — RTL, CJK und sprachspezifische Overrides werden vom Renderer übernommen.

Warum überhaupt Screenshots lokalisieren?

Apples eigene Entwickler-Forschung zeigt, dass Nutzer eine App deutlich wahrscheinlicher installieren, wenn das App-Store-Listing in ihrer Muttersprache ist. Dasselbe ist in Googles Lokalisierungs-Checkliste dokumentiert: Lokalisierte Listings konvertieren besser und ranken besser in der Suche. Nur Metadaten-Strings — Titel, Untertitel, Keywords — zu übersetzen, ohne Screenshots zu übersetzen, ist die häufigste halbe Maßnahme und lässt echte Conversion auf dem Tisch liegen, weil das Hero-Asset weiterhin auf Englisch ist.

Der Blocker für die meisten Teams ist operativ, nicht strategisch. Ein Fünf-Screenshot-Set in 30 Sprachen von Hand zu übersetzen bedeutet 150 Designdateien, 150 Review-Zyklen und 150 Chancen auf einen Tippfehler. Die Lösung ist, Screenshots wie jede andere lokalisierte UI zu behandeln: Schlüssel im Code, Texte in einem TMS, Layout durch einen Build-Step gerendert.

Wie sollten Sie Übersetzungsschlüssel strukturieren?

Verwenden Sie dieselbe Schlüsselstruktur wie Ihre In-App-Übersetzungen. Gruppieren Sie Schlüssel nach Screenshot-ID, dann nach Element-Rolle:

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."
    }
  }
}

Dann die entsprechende deutsche Datei:

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"
    }
  }
}

Die Schlüssel ändern sich nie. Nur die Werte ändern sich. Übersetzer arbeiten in ihrem TMS an der Wertespalte, ohne die Screenshots.live-Vorlage zu berühren.

Welche Sprachcodes sollten Sie verwenden?

Verwenden Sie BCP-47 konsistent. Verwenden Sie nur das Sprach-Subtag, wenn es keine regionale Variation gibt (de, fr, ja), und fügen Sie die Region nur hinzu, wenn die Varianten sinnvoll abweichen (en-GB vs en-US, pt-BR vs pt-PT, zh-Hans vs zh-Hant). Sowohl Apple als auch Google akzeptieren BCP-47, wobei sich ihre internen Codes leicht unterscheiden — siehe die App-Store-Connect-Sprachliste und Google Plays unterstützte Sprachen. Mappen Sie sie einmal in Ihrem CI-Skript.

Wie verteilt man Renderings über Sprachen?

Die API nimmt eine Template-ID, einen Übersetzungskatalog und ein Array von Sprachen entgegen. Sie gibt ein gerendertes PNG pro Sprache pro Gerät zurück:

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"
    }
  }'

Im Hintergrund parallelisiert der Renderer nach Sprache und Gerät. Ein 12-Sprachen × 4-Geräte-Rendering — 48 PNG-Dateien — ist typischerweise in unter 90 Sekunden abgeschlossen. Siehe die API-Rendering-Doku für die vollständige Anfrage-Struktur.

Wie geht man mit Right-to-Left-Sprachen um?

Arabisch (ar), Hebräisch (he), Persisch (fa) und Urdu (ur) brauchen das gesamte Layout gespiegelt — Textausrichtung, Bildpositionen, Pfeil-Icons, sogar die Reihenfolge mehrelementiger Gruppen. Halbe Spiegelung (nur den Text drehen, aber nicht das Layout) wirkt für Muttersprachler falsch und schadet der Glaubwürdigkeit.

Markieren Sie in Screenshots.live die Vorlage mit direction: "auto" und der Renderer spiegelt Layout, Textausrichtung und dekorative Chevrons automatisch beim Rendern von RTL-Sprachen. Überschreiben Sie einzelne Elemente mit direction: "ltr", wenn etwas links-nach-rechts bleiben muss (eine Telefonnummer, eine URL, ein Code-Block).

Was ist mit sprachspezifischen Text-Overrides?

Manche Sprachen passen einfach nicht in dieselbe Bildunterschrift-Box. Deutsche Komposita können 40% länger als Englisch sein; Japanisch und Chinesisch können 50% kürzer sein. Erlauben Sie sprachspezifische Text-Overrides, ohne die Vorlage zu forken:

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

Was ist mit Schriften und CJK-Glyphen?

Lateinische Schriftarten (Inter, SF Pro, Roboto) fehlen oft CJK-, kyrillische, Devanagari- oder arabische Glyphen — Text rendert als Tofu-Boxen. Konfigurieren Sie Schrift-Fallbacks pro Schrift:

  • Latein / Kyrillisch / Griechisch: Inter, SF Pro, Roboto
  • CJK (Japanisch / Koreanisch / Chinesisch): Noto Sans CJK
  • Arabisch / Persisch / Urdu: Noto Sans Arabic, IBM Plex Sans Arabic
  • Devanagari (Hindi): Noto Sans Devanagari
  • Thai: Noto Sans Thai, Sarabun

Die Noto-Familie deckt jede Schrift ab, die Apple und Google unterstützen. Setzen Sie sie als Fallback-Kette in der Vorlage — der Renderer wählt pro Codepoint die richtige Schrift, ohne manuelles Eingreifen.

Wie macht man QA bei Layouts im großen Maßstab?

Manuelle Überprüfung von 30 Sprachen skaliert nicht. Automatisieren Sie die offensichtlichen Fehler-Modi:

  • Textüberlauf: in Viertel-Auflösung rendern, das Ergebnis OCRen, gegen den Quell-String diffen. Abweichungen bedeuten, dass Text abgeschnitten wurde.
  • Fehlende Glyphen: Tofu-Boxen im gerenderten PNG über ein Vision-Modell oder Pixel-Histogramm auf dem Unicode-Ersatzzeichen zählen.
  • Leere Übersetzungen: den Build fehlschlagen lassen, wenn eine Sprache mehr als 5% fehlende Schlüssel gegenüber Englisch hat.
  • Längen-Budgets: setzen Sie eine harte Längen-Obergrenze pro Schlüssel. Wenn die deutsche Übersetzung sie überschreitet, lassen Sie den Build fehlschlagen, statt Überlauf auszuliefern.

Wie lädt man sprachspezifische Screenshots hoch?

App Store Connect und Google Play akzeptieren beide Screenshots pro Sprache. Fastlane deliver liest aus fastlane/screenshots/<locale>/ und Fastlane supply liest aus fastlane/metadata/android/<locale>/images/phoneScreenshots/. Mappen Sie Ihre Renderer-Ausgabe auf diese Pfade, und der Rest ist nur fastlane deliver / fastlane supply --skip_upload_apk.

Was sollten Sie als Nächstes tun?

Kombinieren Sie das mit unserem CI/CD-Automatisierungs-Leitfaden, sodass Lokalisierung bei jedem Release läuft. Verwenden Sie das Multi-Plattform-Support-Feature, um aus demselben Katalog zu iOS, Android und Web-Stores zu fächern.

30+ Sprachen, eine Vorlage

Generieren Sie all diese Größen automatisch

Hören Sie auf, Screenshots manuell zu skalieren. Designen Sie eine Vorlage und rendern Sie jede Größe, jedes Gerät und jede Sprache mit einem einzigen API-Aufruf.

Kostenlos starten — Screenshots.live ausprobieren