Lokalisering av mobilapper: komplett ressursguide

Lokalisering (ofte forkortet til L10n) er arbeidet med å tilpasse en app, dens butikk-tilstedeværelse og dens støttende markedsføring for brukere i spesifikke språk, regioner og kulturelle kontekster. Det er mer enn oversettelse. En komplett lokalisering inkluderer oversatt UI-tekst, oversatt butikk-metadata, oversatte skjermbilde-undertekster, lokalitets-korrekt valuta- og dato-formatering, kulturelt passende bilder, region-spesifikke betalingsmetoder (UPI i India, Pix i Brasil, iDEAL i Nederland) og tilpassede juridiske avsløringer. Å hoppe over én av disse leses av lokale brukere som et halvhjertet utenlandsk produkt.

App Store og Google Play viser lokaliserte oppføringer til brukere på deres foretrukne språk automatisk — hvis du har gitt dem. Hvis du ikke har det, ser brukeren standard engelsk-oppføringen din, noe som betydelig demper konvertering i ikke-engelske markeder. Spørsmålet er sjelden 'bør vi lokalisere', men 'hvilke markeder først, og hvor dypt'.

Apples og Googles egne publiserte data bekrefter det uavhengig ASO-research konsekvent viser: lokaliserte skjermbilder flytter installasjons-konvertering mye mer enn lokaliserte titler eller beskrivelser. Grunnen er informasjonstetthet. Et skjermbilde kommuniserer produkt, språk-dekning, brand-finish og kulturell passform i et enkelt visuelt øyeblikk. En lokalisert tittel kommuniserer kun at appen finnes på språket ditt.

Løftet er ikke uniformt. Øst-asiatiske markeder (Japan, Korea, Kina, Taiwan) viser historisk det største installasjons-løftet fra lokaliserte skjermbilder — ofte 30–60 % over engelske standarder — fordi de markedene er mest skeptiske til ulokaliserte oppføringer. Europeiske markeder er typisk 10–25 % løft, og engelsk-flytende ikke-engelsk-talende markeder (Nederland, Sverige, Finland) ser noen ganger kun 5–15 %. Planlegg lokaliserings-investering etter forventet løft, ikke etter markedsstørrelse alene.

For de fleste apper er de første-bølge-lokaliseringene med høyest ROI: tysk (de), fransk (fr), spansk (es), italiensk (it), portugisisk (Brasil) (pt-BR), japansk (ja), forenklet kinesisk (zh-Hans) og koreansk (ko). Disse dekker markedene med det største installasjonsvolumet + høyeste løftet fra lokalisering. En andre bølge legger ofte til: russisk (ru), polsk (pl), nederlandsk (nl), tyrkisk (tr), arabisk (ar), vietnamesisk (vi) og tradisjonell kinesisk (zh-Hant).

Apple og Google støtter betydelig flere lokaliteter enn dette (Apple har 175+ språk-/landskombinasjoner), men den lange halen rettferdiggjør sjelden innsatsen med mindre produktet ditt har spesifikk markedstilpasning der. Start med de åtte, mål konverterings-løft per marked, og utvid til hvilke markeder som returnerer det sterkeste signalet.

Tre tilnærminger: (1) Send undertekster til en profesjonell oversettelses-tjeneste (Smartling, Lokalise, Crowdin) — høyest kvalitet, tregest gjennomløpstid, dyrest per lokalitet. (2) Bruk en LLM (GPT-4o, Claude, Gemini) for et første pass og la morsmålstalere gjennomgå — raskt, billig, overraskende godt for kort markedsføringstekst. (3) Lei morsmålstalende kontraktører direkte via Upwork eller Fiverr — ofte den beste balansen for tidlig-fase-team.

Uansett hva du velger, maskinoversett aldri en skjermbilde-undertekst og lever den uten en menneskelig gjennomgang. Markedsføringstekst er for verdifull for un-gjennomgått automatisk oversettelse. Kostnaden ved en klønete japansk undertekst er hundrevis av tapte installasjoner; gjennomgang koster $5–20 per lokalitet.

Dette er der de fleste team snubler. Å oversette '$19,99/måned' til '19,99 $/Monat' er feil i en tysk oppføring — det bør være '19,99 €/Monat'. Valutakonvertering ved fair purchasing-power parity, lokalitets-korrekte desimalskilletegn (komma i det meste av Europa, punktum i USA/Storbritannia), enhetssystemer (cm vs. tommer), datoformater (DD/MM/ÅÅÅÅ vs. MM/DD/ÅÅÅÅ vs. ÅÅÅÅ-MM-DD) og tidsformater (12t vs. 24t) må alle rendres per lokalitet.

Det reneste mønsteret er å holde alle lokalitets-avhengige verdier ute av selve skjermbilde-malen og injisere dem ved render-tid fra en per-lokalitet-datafil. Det er det dynamiske maler og YAML-config er for: én mal, N lokalitets-datafiler, M renderinger.

Arabisk, hebraisk, persisk og urdu er høyre-til-venstre-skrifter. Å lokalisere skjermbilder for disse markedene betyr mer enn å bytte tekst — hele layouten speiles vanligvis. CTA-knappen flytter seg fra høyre til venstre, navigasjonslinjer snur, fremdriftsindikatorer flipper retning, og til og med noe ikonografi (tilbake-piler, send-knapper) må speiles.

For RTL-markeder, behandle skjermbilde-malen som en separat artefakt, ikke et oversettelses-overlegg. Løftet fra et riktig speilet arabisk skjermbilde vs. et venstre-til-høyre arabisk skjermbilde er stort; løftet fra å forbedre et allerede speilet skjermbilde er lite. Få layouten riktig først.