Mobilapplokalisering: komplett resursguide

Lokalisering (ofta förkortat L10n) är arbetet med att anpassa en app, dess butiks­närvaro och dess stödjande marknadsföring för användare i specifika språk, regioner och kulturella sammanhang. Det är mer än översättning. En komplett lokalisering inkluderar översatt UI-text, översatt butiksmetadata, översatta skärmdumpstexter, språk­korrekt valuta- och datumformatering, kulturellt lämpliga bilder, regionspecifika betalmetoder (UPI i Indien, Pix i Brasilien, iDEAL i Nederländerna) och anpassade juridiska upplysningar. Att hoppa över någon av dessa läses av lokala användare som en halvhjärtad utländsk produkt.

App Store och Google Play visar lokaliserade listningar för användare på deras föredragna språk automatiskt — om du har tillhandahållit dem. Om du inte har det ser användaren din standard­engelska listning, vilket avsevärt sänker konverteringen på icke-engelska marknader. Frågan är sällan ”ska vi lokalisera” utan ”vilka marknader först, och hur djupt”.

Apples och Googles egen publicerade data bekräftar vad oberoende ASO-forskning konsekvent visar: lokaliserade skärmdumpar flyttar installations­konvertering mycket mer än lokaliserade titlar eller beskrivningar. Anledningen är informationstäthet. En skärmdump kommunicerar produkt, språkstöd, varumärkes­polering och kulturell passform i ett enda visuellt ögonblick. En lokaliserad titel kommunicerar bara att appen finns på ditt språk.

Lyften är inte enhetlig. Östasiatiska marknader (Japan, Korea, Kina, Taiwan) visar historiskt den största installationslyften från lokaliserade skärmdumpar — ofta 30–60 % över engelska standardvärden — eftersom dessa marknader är mest skeptiska till olokaliserade listningar. Europeiska marknader är typiskt 10–25 % lyft, och engelskbehärskande icke-engelsktalande marknader (Nederländerna, Sverige, Finland) ser ibland bara 5–15 %. Planera lokaliserings­investeringar efter förväntad lyft, inte enbart efter marknadsstorlek.

För de flesta appar är de högsta-ROI-första­vågslokaliseringarna: tyska (de), franska (fr), spanska (es), italienska (it), portugisiska (Brasilien) (pt-BR), japanska (ja), förenklad kinesiska (zh-Hans) och koreanska (ko). Dessa täcker marknaderna med störst installationsvolym + högst lyft från lokalisering. En andra våg lägger ofta till: ryska (ru), polska (pl), holländska (nl), turkiska (tr), arabiska (ar), vietnamesiska (vi) och traditionell kinesiska (zh-Hant).

Apple och Google stöder avsevärt fler språk än så här (Apple har 175+ kombinationer av språk/land), men långsvansen rättfärdigar sällan ansträngningen om inte din produkt har specifik marknadspassform där. Börja med åtta, mät konverteringslyft per marknad och expandera till de marknader som returnerar starkast signal.

Tre tillvägagångssätt: (1) Skicka texter till en professionell översättningstjänst (Smartling, Lokalise, Crowdin) — högst kvalitet, långsammast leverans, dyrast per språk. (2) Använd en LLM (GPT-4o, Claude, Gemini) för en första passering och låt modersmålstalare granska — snabbt, billigt, förvånansvärt bra för kort marknadsföringstext. (3) Anlita modersmålstalare som konsulter direkt via Upwork eller Fiverr — ofta den bästa balansen för team i tidiga skeden.

Vilket du än väljer, maskinöversätt aldrig en skärmdumpstext och leverera den utan mänsklig granskning. Marknadsföringstext har för hög hävstång för ogranskad automatisk översättning. Kostnaden för en klumpig japansk text är hundratals förlorade installationer; granskning kostar 5–20 USD per språk.

Det är här de flesta team snubblar. Att översätta ”$19.99/month” till ”19,99 $/Monat” är fel i en tysk listning — det ska vara ”19,99 €/Monat”. Valutakonvertering till rättvis köpkraftsparitet, språk­korrekta decimaltecken (komma i större delen av Europa, punkt i USA/Storbritannien), enhetssystem (cm vs. tum), datumformat (DD/MM/ÅÅÅÅ vs. MM/DD/ÅÅÅÅ vs. ÅÅÅÅ-MM-DD) och tidsformat (12h vs. 24h) behöver alla renderas per språk.

Det renaste mönstret är att hålla alla språkberoende värden utanför själva skärmdumpsmallen och injicera dem vid renderingstid från en datafil per språk. Det är vad dynamiska mallar och YAML-konfiguration är till för: en mall, N språkdatafiler, M renderingar.

Arabiska, hebreiska, persiska och urdu är höger-till-vänster-skript. Att lokalisera skärmdumpar för dessa marknader betyder mer än att byta text — hela layouten speglas typiskt. CTA-knappen flyttar från höger till vänster, navigeringsfält vänds, framstegsindikatorer flippar riktning och även viss ikonografi (bakåt-pilar, send-knappar) behöver speglas.

För RTL-marknader, behandla skärmdumpsmallen som en separat artefakt, inte ett översättningsskikt. Lyften från en korrekt speglad arabisk skärmdump vs. en vänster-till-höger arabisk skärmdump är stor; lyften från att förbättra en redan speglad skärmdump är liten. Få layouten rätt först.