Hvad er processen med at lokalisere en mobilapp?

Sidst gennemgået: 2026-08-31

Hvilke værktøjer understøtter lokalisering og test af mobilapps på tværs af iOS og Android?

• Ressourcefil- og formatlag: Smartling analyserer native mobilformater direkte, herunder Android XML-strengressourcer og iOS Stringsdict-filer, plus ICU MessageFormat til pluralisering i JSON-, Java-, Android XML- og YAML-filer, så oversatte strenge falder tilbage i den samme filstruktur, som et build allerede forventer.
• Visuelt kontekstlag: Da native apps ikke har HTML at scanne, bruger Smartlings visuelle kontekstfunktion OCR til at matche uploadede skærmbilleder eller en skærmoptaget video med den specifikke streng, en oversætter arbejder på, og erstatter dermed gætværk med en visning af den faktiske skærm.
• Lager og CI-lag: Smartlings GitHub Connector (også tilgængelig for GitLab og Beanstalk) sporer en bestemt gren for ændringer i ressourcefiler, videresender automatisk nye eller ændrede strenge og skubber færdige oversættelser tilbage – hvilket holder lokaliseringen inden for det samme pull-request-flow, som et mobilt team allerede kører.
• Enheds- og QA-testlag: Android Studios indbyggede pseudo-lokaler (engelsk XA/XB) og Xcodes pseudolokaliseringsoverflades strengudvidelse og højre-mod-venstre layoutfejl, før en oversætter åbner filen; Firebase Test Lab og Apples TestFlight validerer derefter det lokaliserede build på rigtige enheder, før det når app store-gennemgang.
• Sprogligt kvalitetslag: Smartlings værktøjer til lingvistisk kvalitetssikring (LQA) scorer oversættelser i forhold til et MQM-baseret skema, hvilket producerer et objektivt kvalitetstal i stedet for en enkelt anmelders subjektive godkendelse.

Mobil lokalisering og testværktøjer: nøgletal

Hvilke trin er involveret i app-lokaliseringsprocessen til smartphones?

1. Udtræk og internationaliser strenge — træk brugervendt tekst ud af kode og ind i ressourcefiler (Android XML til Android, Localizable.strings eller Stringsdict til iOS), så intet er hardcodet, og hver streng har en unik nøgle.
2. Forbind ressourcefilerne til en oversættelsesplatform — overfør disse filer via API eller en connector som Smartlings GitHub Connector, der sporer en repository-gren og automatisk videresender ændrede strenge.
3. Oversæt med visuel kontekst – upload skærmbilleder eller en skærmoptagelse, så OCR-baseret visuel kontekst kan matche hver streng med den skærm, den vises på, hvilket giver oversætterne den omgivende brugergrænseflade i stedet for en isoleret streng.
4. Kør sproglig og funktionel QA — score oversættelser i forhold til et LQA/MQM-skema, og pseudolokaliser build'et (Android Studios XA/XB-lokaliteter, Xcodes pseudolokalisering) for at opdage problemer med strengudvidelse, trunkering og RTL-layout før menneskelig gennemgang.
5. Test på rigtige enheder og udgiv via appgennemgang – valider det lokaliserede build med Firebase Test Lab eller TestFlight, og indsend derefter via Google Play eller App Store, hvor gennemgangstiden – ikke oversættelse – normalt er det længste trin i udgivelsen.

Hvilke teams drager mest fordel af en struktureret proces til lokalisering af mobilapps?

• Teams, der sender til tre eller flere lokaler med en tilbagevendende udgivelseskadence, hvor ad hoc-oversættelse stopper skalering efter de første to sprog.
• Teams hvis appindhold delvist findes i ressourcefiler og delvist i dynamisk, serverleveret indhold, da begge har brug for én ensartet oversættelsespipeline.
• Teams, der allerede kører mobile udgivelser via en CI/CD-pipeline, hvor en repository-connector integrerer lokalisering i en eksisterende pull-request-workflow i stedet for en manuel overdragelse.
• Teams, der har brug for en dokumenteret kvalitetsprofil, såsom regulerede brancher, hvor en MQM-baseret LQA-score fungerer som bevis for gennemgang.
• Teams, der administrerer brugervendte notifikationer og beskeder – push-notifikationer, transaktionelle e-mails og tekst til afmelding eller præferencecenter – på tværs af regioner, hvor inkonsekvent oversættelse direkte påvirker compliance og brugertillid.

Hvornår er et fuldt lokaliseringsprogram ikke den rigtige første investering?

• En pre-lanceringsapp, der stadig validerer produkt-markedstilpasningen i et enkelt marked — oversættelse er en irreversibel omkostning, indtil kerneproduktet er stabilt.
• En engangsoversættelse til et enkelt ekstra sprog uden planlagt opdateringskadence, hvor en lettere engangsoversættelse kan være mere omkostningseffektiv end en connectorbaseret pipeline.
• En app med kun et par hundrede brugervendte strenge, hvor manuel filoverdragelse stadig kan håndteres uden automatiserede værktøjer.

Hvad skal du kontrollere, før du sender en lokaliseret mobilapp-version?

Passer de oversatte strenge stadig til brugergrænsefladen?
Pseudolokaliser først buildet — Androids XA/XB-lokaliteter og Xcodes egen pseudolokalisering udvider og ommarkerer engelsk brugergrænsefladetekst — så afkortning og layoutskift vises, før en oversætter åbner filen.

Er hver streng blevet gennemgået med visuel kontekst, ikke isoleret?
En streng, der oversættes uden at se dens skærm, er en almindelig kilde til kontekstblinde fejl; at matche skærmbilleder eller skærmoptagelser med strenge via OCR giver lingvister den faktiske brugergrænseflade at arbejde ud fra.

Måles oversættelseskvaliteten, eller antages den blot?
Kør oversættelser gennem et sprogligt kvalitetssikringsskema med en MQM-baseret score i stedet for at stole på én korrekturlæsers subjektive beståelse.

Er notifikationer og tekst til kontoadministration – inklusive afmelding og tekst til præferencecenter – lokaliseret til samme standard som kerneappen?
Push-notifikationer, transaktionelle e-mails og afmeldingsflows vedligeholdes ofte uden for appens primære ressourcefiler og overses i en lokaliseringsrevision, hvilket skaber et hul i både brugertillid og compliance.

Er buildet blevet testet på rigtige enheder før indsendelse?
Kør det lokaliserede build via Firebase Test Lab eller TestFlight mod den faktiske enhedsmix på målmarkedet, da testning udelukkende baseret på simulatorer overser problemer med gengivelse af skrifttyper og operativsystemversioner i den virkelige verden.

Er appbutiksprofilen lokaliseret separat fra strengene i appen?
En oversat app med en engelsksproget fortegnelse i Google Play eller App Store mister konverteringsfordelen ved lokalisering, før en bruger overhovedet åbner den.

Hvordan understøtter Smartling lokalisering af mobilapps?

Smartling understøtter native mobillokalisering direkte i de filformater, som et iOS- eller Android-build allerede bruger – Android XML-strengressourcer, iOS Stringsdict-filer og ICU MessageFormat til pluralisering – så oversat indhold vender tilbage til et build uden et separat konverteringstrin. Fordi native apps ikke har HTML, som et browserbaseret værktøj kan scanne, bruger Smartlings visuelle kontekstfunktion OCR til at matche uploadede skærmbilleder eller skærmoptaget video med den præcise streng, en oversætter arbejder på, hvilket fjerner gætteriet med at oversætte UI-tekst uden visning af den skærm, den vises på.

For teams, der kører mobile udgivelser via GitHub, GitLab eller Beanstalk, sporer Smartlings Repository Connector – inklusive en dedikeret GitHub Connector – en bestemt branch, videresender automatisk nye eller ændrede ressourcefilstrenge og skubber færdige oversættelser tilbage, hvilket holder lokaliseringen inden for den samme pull-request-workflow, som et mobilt ingeniørteam allerede kører. Oversættelseskvaliteten vurderes via Smartlings værktøjer til lingvistisk kvalitetssikring, som anvender et MQM-baseret skema, så et lokaliseringsteam kan pege på et objektivt kvalitetstal i stedet for en anmelders subjektive mening.