Hoe je App Store-screenshots in 30+ talen lokaliseert

Waarom screenshots überhaupt lokaliseren?

Apple's eigen developer-onderzoek toont aan dat gebruikers significant vaker een app installeren wanneer de App Store-vermelding in hun moedertaal staat. Hetzelfde wordt vastgelegd in Google's lokalisatiechecklist: gelokaliseerde vermeldingen converteren beter en scoren hoger in zoekresultaten. Alleen metadata-strings vertalen — titel, ondertitel, trefwoorden — zonder de screenshots te vertalen is de meest voorkomende halve maatregel, en je laat daarmee echte conversie liggen omdat het hero-asset nog steeds in het Engels is.

Het knelpunt voor de meeste teams is operationeel, niet strategisch. Een set van vijf screenshots handmatig naar 30 talen vertalen betekent 150 designbestanden, 150 reviewcycli en 150 kansen op een typefout. De oplossing is om screenshots als elke andere gelokaliseerde UI te behandelen: sleutels in code, copy in een TMS, layout gerenderd door een buildstap.

Hoe structureer je vertaalsleutels?

Gebruik dezelfde sleutelstructuur als voor je in-app-vertalingen. Groepeer sleutels per screenshot-ID, daarna per element-rol:

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

Vervolgens het bijbehorende Duitse bestand:

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

De sleutels veranderen nooit. Alleen de waarden veranderen. Vertalers werken in hun TMS aan de waardekolom zonder de Screenshots.live-template aan te raken.

Welke locale-codes moet je gebruiken?

Gebruik BCP-47 consistent. Gebruik alleen het taal-subtag wanneer er geen regionale variatie is (de, fr, ja) en voeg de regio alleen toe wanneer de varianten betekenisvol verschillen (en-GB versus en-US, pt-BR versus pt-PT, zh-Hans versus zh-Hant). Zowel Apple als Google accepteert BCP-47, hoewel hun interne codes licht verschillen — zie de locale-lijst van App Store Connect en de ondersteunde talen van Google Play. Map ze één keer in je CI-script.

Hoe verspreid je renders over locales?

De API neemt een template-ID, een vertaalcatalogus en een array van locales. Hij retourneert één gerenderde PNG per locale per device:

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

Achter de schermen parallelliseert de renderer per locale en per device. Een render van 12 locales × 4 devices — 48 PNG-bestanden — is doorgaans in minder dan 90 seconden klaar. Zie de API-renderingdocumentatie voor de volledige opzet van het verzoek.

Hoe ga je om met right-to-left-talen?

Arabisch (ar), Hebreeuws (he), Perzisch (fa) en Urdu (ur) vereisen dat de volledige layout wordt gespiegeld — tekstuitlijning, afbeeldingsposities, pijliconen en zelfs de volgorde van groepen met meerdere elementen. Half spiegelen (alleen de tekst flippen, maar niet de layout) ziet er voor moedertaalsprekers verkeerd uit en schaadt de geloofwaardigheid.

Markeer in Screenshots.live de template met direction: "auto" en de renderer flipt automatisch layout, tekstuitlijning en decoratieve chevrons bij het renderen van RTL-locales. Overschrijf individuele elementen met direction: "ltr" wanneer iets links-naar-rechts moet blijven (een telefoonnummer, een URL, een codeblok).

Hoe zit het met per-locale tekst-overrides?

Sommige talen passen simpelweg niet in dezelfde captionbox. Duitse samenstellingen kunnen 40% langer zijn dan Engels; Japans en Chinees kunnen 50% korter zijn. Sta per-locale tekst-overrides toe zonder de template te forken:

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

Hoe zit het met fonts en CJK-glyphs?

Latijnse fonts (Inter, SF Pro, Roboto) missen vaak CJK-, Cyrillische, Devanagari- of Arabische glyphs — tekst rendert dan als tofu-blokjes. Configureer font-fallbacks per script:

• Latijn / Cyrillisch / Grieks: Inter, SF Pro, Roboto
• CJK (Japans / Koreaans / Chinees): Noto Sans CJK
• Arabisch / Perzisch / Urdu: Noto Sans Arabic, IBM Plex Sans Arabic
• Devanagari (Hindi): Noto Sans Devanagari
• Thai: Noto Sans Thai, Sarabun

De Noto-familie dekt elk script dat Apple en Google ondersteunen. Zet het als fallback-keten in de template — de renderer kiest het juiste font per code point, zonder handmatige tussenkomst.

Hoe doe je QA op layouts op grote schaal?

Handmatige review van 30 locales schaalt niet. Automatiseer de voor de hand liggende faalmodi:

• Tekstoverflow: render op een kwart resolutie, OCR het resultaat en diff tegen de bronstring. Mismatches betekenen dat tekst is afgeknipt.
• Ontbrekende glyphs: tel tofu-blokjes in de gerenderde PNG via een vision-model of een pixelhistogram op het Unicode-replacement-character.
• Lege vertalingen: laat de build falen als een locale meer dan 5% ontbrekende sleutels heeft ten opzichte van Engels.
• Lengtebudgetten: stel een harde lengtelimiet per sleutel in. Als de Duitse vertaling die overschrijdt, laat dan de build falen in plaats van overflow uit te leveren.

Hoe upload je per-locale screenshots?

Zowel App Store Connect als Google Play accepteren screenshots per locale. Fastlane deliver leest uit fastlane/screenshots/<locale>/ en Fastlane supply leest uit fastlane/metadata/android/<locale>/images/phoneScreenshots/. Map de output van je renderer naar die paden en de rest is gewoon fastlane deliver / fastlane supply --skip_upload_apk.

Wat moet je nu doen?

Combineer dit met onze CI/CD-automatiseringsgids zodat lokalisatie bij elke release draait. Gebruik de multi-platform-ondersteuningsfunctie om vanuit dezelfde catalogus uit te rollen naar iOS, Android en webstores.