Hoppa till innehåll
Alla guider
Steg-för-steg-guide30 min läsning

Så lokaliserar du App Store-skärmbilder för 30+ språk

En praktisk handbok för att leverera lokaliserade skärmbilder till App Store och Google Play utan att behöva en separat mall per språk. Täcker struktur för översättningsnycklar, utfläkning till flera språk, RTL-hantering, typsnittsfallback och automatiserad layout-QA.

Eric Isensee
Eric IsenseeFounder · Last updated 5 maj 2026

TL;DR

Externalisera varje bildtext till en översättningsnyckel, översätt nycklarna (inte grafiken) och skicka sedan en API-förfrågan med en lista över språk. Screenshots.live renderar varje språk parallellt från samma mall — RTL, CJK och språkspecifika överskrivningar hanteras av renderaren.

Varför ska du över huvud taget lokalisera skärmbilder?

Apples egen utvecklarforskning visar att användare är betydligt mer benägna att installera en app när App Store-listningen är på deras modersmål. Samma sak dokumenteras i Googles checklista för lokalisering: lokaliserade listningar konverterar bättre och rankar högre i sökningen. Att översätta enbart metadatasträngar — titel, undertitel, sökord — utan att översätta skärmbilderna är den vanligaste halvmesyren, och den lämnar verklig konvertering på bordet eftersom huvudbilden fortfarande är på engelska.

Stoppklossen för de flesta team är operativ, inte strategisk. Att översätta en uppsättning på fem skärmbilder till 30 språk för hand innebär 150 designfiler, 150 granskningscykler och 150 chanser till stavfel. Lösningen är att behandla skärmbilder som vilket annat lokaliserat gränssnitt som helst: nycklar i koden, texten i ett TMS, layouten renderad i ett byggsteg.

Hur ska du strukturera översättningsnycklar?

Använd samma nyckelstruktur som för dina översättningar i appen. Gruppera nycklar efter skärmbilds-ID och därefter efter elementroll:

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

Och motsvarande tysk fil:

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

Nycklarna ändras aldrig. Endast värdena ändras. Översättarna arbetar i värdekolumnen i sitt TMS utan att röra Screenshots.live-mallen.

Vilka språkkoder ska du använda?

Använd BCP-47 konsekvent. Använd endast språk-subtaggen när det inte finns någon regional variation (de, fr, ja) och lägg till regionen endast när varianterna skiljer sig åt på ett betydelsefullt sätt (en-GB mot en-US, pt-BR mot pt-PT, zh-Hans mot zh-Hant). Både Apple och Google accepterar BCP-47, även om deras interna koder skiljer sig något — se App Store Connects språklista och Google Plays språk som stöds. Mappa dem en gång i ditt CI-skript.

Hur fläker du ut renderingar över språk?

API:t tar emot ett mall-ID, en översättningskatalog och en array med språk. Det returnerar en renderad 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"
    }
  }'

Bakom kulisserna parallelliserar renderaren per språk och per enhet. En rendering med 12 språk × 4 enheter — 48 PNG-filer — slutförs vanligtvis på under 90 sekunder. Se API-dokumentationen för rendering för den fullständiga förfrågningsformen.

Hur hanterar du höger-till-vänster-språk?

Arabiska (ar), hebreiska (he), persiska (fa) och urdu (ur) kräver att hela layouten speglas — textjustering, bildpositioner, pilikoner och till och med ordningen i grupper med flera element. Halvspegling (att bara vända texten men inte layouten) ser fel ut för läsare med språket som modersmål och skadar trovärdigheten.

I Screenshots.live markerar du mallen med direction: "auto" så vänder renderaren automatiskt på layouten, textjusteringen och dekorativa pilar när RTL-språk renderas. Skriv över enskilda element med direction: "ltr" när något måste förbli vänster-till-höger (ett telefonnummer, en URL, ett kodblock).

Vad gäller för språkspecifika textöverskrivningar?

Vissa språk får helt enkelt inte plats i samma textruta. Tyska sammansatta substantiv kan vara 40 % längre än engelska; japanska och kinesiska kan vara 50 % kortare. Tillåt språkspecifika textöverskrivningar utan att splittra mallen:

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

Vad gäller för typsnitt och CJK-glyfer?

Typsnitt med latinsk skrift (Inter, SF Pro, Roboto) saknar ofta CJK-, kyrilliska, devanagari- eller arabiska glyfer — texten renderas som tofu-rutor. Konfigurera typsnittsfallback per skriftsystem:

  • Latin / kyrilliska / grekiska: Inter, SF Pro, Roboto
  • CJK (japanska / koreanska / kinesiska): Noto Sans CJK
  • Arabiska / persiska / urdu: Noto Sans Arabic, IBM Plex Sans Arabic
  • Devanagari (hindi): Noto Sans Devanagari
  • Thai: Noto Sans Thai, Sarabun

Noto-familjen täcker varje skriftsystem som Apple och Google stöder. Sätt den som en fallback-kedja i mallen — renderaren väljer rätt typsnitt per kodpunkt, utan manuellt ingripande.

Hur QA:ar du layouter i stor skala?

Manuell granskning av 30 språk skalar inte. Automatisera de uppenbara felmoderna:

  • Textöversvämning: rendera i kvartsupplösning, OCR:a resultatet och jämför med källsträngen. Avvikelser betyder att texten klipptes.
  • Saknade glyfer: räkna tofu-rutor i den renderade PNG-filen via en visionsmodell eller pixelhistogram för Unicodes ersättningstecken.
  • Tomma översättningar: låt bygget misslyckas om något språk har mer än 5 % saknade nycklar jämfört med engelska.
  • Längdbudgetar: sätt en hård längdgräns per nyckel. Om den tyska översättningen överskrider den, låt bygget misslyckas i stället för att låta översvämningen gå i produktion.

Hur laddar du upp skärmbilder per språk?

Både App Store Connect och Google Play accepterar skärmbilder per språk. Fastlane deliver läser från fastlane/screenshots/<locale>/ och Fastlane supply läser från fastlane/metadata/android/<locale>/images/phoneScreenshots/. Mappa renderarens utdata till dessa sökvägar, så är resten bara fastlane deliver / fastlane supply --skip_upload_apk.

Vad ska du göra härnäst?

Kombinera detta med vår guide för CI/CD-automatisering så att lokaliseringen körs vid varje release. Använd funktionen för stöd för flera plattformar för att fläka ut till iOS-, Android- och webbutiker från samma katalog.

30+ språk, en mall

Generera alla dessa storlekar automatiskt

Sluta ändra storlek på skärmdumpar manuellt. Designa en mall och rendera varje storlek, enhet och språk med ett enda API-anrop.

Kom igång gratis — Prova Screenshots.live