Hopp til innhold
Alle guider
Trinn-for-trinn-guide30 min lesetid

Slik lokaliserer du App Store-skjermbilder på over 30 språk

En praktisk håndbok for å levere lokaliserte skjermbilder til App Store og Google Play uten å splitte malene per språk. Dekker struktur for oversettelsesnøkler, utrulling på flere språk, RTL-håndtering, font-fallbacks og automatisert layout-QA.

Eric Isensee
Eric IsenseeFounder · Last updated 5. mai 2026

Kort oppsummert

Eksternaliser hver bildetekst til en oversettelsesnøkkel, oversett nøklene (ikke grafikken), og send så én API-forespørsel med en liste over språk. Screenshots.live rendrer alle språk parallelt fra samme mal – RTL, CJK og overstyringer per språk håndteres av rendreren.

Hvorfor i det hele tatt lokalisere skjermbilder?

Apples egen utviklerforskning viser at brukere er betydelig mer tilbøyelige til å installere en app når App Store-oppføringen er på morsmålet deres. Det samme er dokumentert i Googles lokaliseringssjekkliste: lokaliserte oppføringer konverterer bedre og rangeres høyere i søk. Å oversette kun metadata-strenger – tittel, undertittel, nøkkelord – uten å oversette skjermbildene er den vanligste halvveis-løsningen, og det gir deg redusert konvertering fordi hovedressursen fortsatt er på engelsk.

Det som blokkerer de fleste team er operasjonelt, ikke strategisk. Å oversette et sett med fem skjermbilder til 30 språk for hånd betyr 150 designfiler, 150 gjennomgangsrunder og 150 sjanser for skrivefeil. Løsningen er å behandle skjermbilder som ethvert annet lokalisert UI: nøkler i koden, tekst i et TMS, layout rendret av et byggetrinn.

Hvordan bør du strukturere oversettelsesnøkler?

Bruk samme nøkkelstruktur som for oversettelsene i appen din. Grupper nøklene etter skjermbilde-ID, og deretter etter elementrolle:

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

Og den tilsvarende tyske filen:

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

Nøklene endres aldri. Bare verdiene endres. Oversettere jobber med verdikolonnen i sitt TMS uten å måtte røre Screenshots.live-malen.

Hvilke språkkoder bør du bruke?

Bruk BCP-47 konsekvent. Bruk kun språkkoden når det ikke er noen regional variasjon (de, fr, ja) og legg til regionen kun når variantene avviker betydelig (en-GB vs. en-US, pt-BR vs. pt-PT, zh-Hans vs. zh-Hant). Både Apple og Google godtar BCP-47, selv om deres interne koder skiller seg noe – se App Store Connects språkliste og Google Plays støttede språk. Map dem én gang i CI-skriptet ditt.

Hvordan ruller du ut renderinger på tvers av språk?

API-et tar inn en mal-ID, en oversettelseskatalog og en liste over språk. Det returnerer én rendret PNG per språk per enhet:

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

Bak kulissene parallelliserer rendreren etter språk og enhet. En rendering for 12 språk × 4 enheter – 48 PNG-filer – fullføres vanligvis på under 90 sekunder. Se API-renderingdokumentasjonen for full forespørselsstruktur.

Hvordan håndterer du språk som leses fra høyre til venstre?

Arabisk (ar), hebraisk (he), persisk (fa) og urdu (ur) krever at hele layouten speilvendes – tekstjustering, bildeposisjoner, pilikoner og til og med rekkefølgen på grupper med flere elementer. Halvveis speiling (kun teksten, men ikke layouten) ser feil ut for innfødte lesere og svekker troverdigheten.

I Screenshots.live merker du malen med direction: "auto", og rendreren snur automatisk layout, tekstjustering og dekorative chevroner når den rendrer RTL-språk. Overstyr enkeltelementer med direction: "ltr" når noe må forbli venstre-til-høyre (et telefonnummer, en URL, en kodeblokk).

Hva med tekstoverstyringer per språk?

Noen språk passer rett og slett ikke i samme bildetekstboks. Tyske sammensatte substantiver kan være 40 % lengre enn engelske; japansk og kinesisk kan være 50 % kortere. Tillat tekstoverstyringer per språk uten å splitte malen:

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

Hva med fonter og CJK-glyfer?

Latinske skriftfonter (Inter, SF Pro, Roboto) mangler ofte CJK-, kyrilliske, devanagari- eller arabiske glyfer – teksten rendres som tofu-bokser. Konfigurer font-fallbacks per skrift:

  • Latin / kyrillisk / gresk: Inter, SF Pro, Roboto
  • CJK (japansk / koreansk / kinesisk): Noto Sans CJK
  • Arabisk / persisk / urdu: Noto Sans Arabic, IBM Plex Sans Arabic
  • Devanagari (hindi): Noto Sans Devanagari
  • Thai: Noto Sans Thai, Sarabun

Noto-familien dekker alle skriftsystemer Apple og Google støtter. Sett den som en fallback-kjede i malen – rendreren velger riktig font per kodepunkt, uten manuell innblanding.

Hvordan kvalitetssikrer du layouter i stor skala?

Manuell gjennomgang av 30 språk skalerer ikke. Automatiser de åpenbare feilmodusene:

  • Tekstoverflyt: render i kvart oppløsning, OCR resultatet og diff mot kildestrengen. Avvik betyr at tekst ble klippet.
  • Manglende glyfer: tell tofu-bokser i den rendrede PNG-en via en synsmodell eller pikselhistogram på Unicode-erstatningstegnet.
  • Tomme oversettelser: la byggjobben feile hvis et språk har mer enn 5 % manglende nøkler sammenlignet med engelsk.
  • Lengdebudsjetter: sett et hardt lengdetak per nøkkel. Hvis den tyske oversettelsen overskrider det, la byggjobben feile i stedet for å la overflyt komme ut i produksjon.

Hvordan laster du opp skjermbilder per språk?

Både App Store Connect og Google Play godtar skjermbilder per språk. Fastlane deliver leser fra fastlane/screenshots/<locale>/ og Fastlane supply leser fra fastlane/metadata/android/<locale>/images/phoneScreenshots/. Map rendrerens output til disse stiene, og resten er bare fastlane deliver / fastlane supply --skip_upload_apk.

Hva bør du gjøre videre?

Kombiner dette med vår guide til CI/CD-automatisering så lokalisering kjører ved hver release. Bruk flerplattformstøtte-funksjonen for å rulle ut til iOS-, Android- og web-butikker fra samme katalog.

Over 30 språk, én mal

Generer alle disse størrelsene automatisk

Slutt å endre størrelse på skjermbilder manuelt. Design én mal og render hver størrelse, enhet og lokalitet med ett enkelt API-kall.

Start gratis — Prøv Screenshots.live