Wat is het proces van het lokaliseren van een mobiele app?

Laatst beoordeeld: 2026-08-31

Welke tools ondersteunen mobiele app-lokalisatie en testen op iOS en Android?

• Resource-bestand- en formaatlaag: Smartling parseert rechtstreeks native mobiele formaten, waaronder Android XML-stringresources en iOS Stringsdict-bestanden, plus ICU MessageFormat voor meervoudsvorming in JSON-, Java-, Android XML- en YAML-bestanden, zodat vertaalde strings terugkeren naar dezelfde bestandsstructuur die een build al verwacht.
• Visuele contextlaag: omdat native apps geen HTML hoeven te scannen, gebruikt de functie 'Visuele context' van Smartling OCR om geüploade schermafbeeldingen of een schermopname te koppelen aan de specifieke tekenreeks waaraan een vertaler werkt. Hierdoor wordt giswerk vervangen door een weergave van het daadwerkelijke scherm.
• Repository en CI-laag: Smartling's GitHub Connector (ook beschikbaar voor GitLab en Beanstalk) volgt een gespecificeerde branch voor wijzigingen in resourcebestanden, stuurt nieuwe of gewijzigde strings automatisch door en schuift voltooide vertalingen terug — waardoor de lokalisatie binnen dezelfde pull-request flow blijft die een mobiel team al uitvoert.
• Apparaat- en QA-testlaag: De ingebouwde pseudo-locaties van Android Studio (Engels XA/XB) en Xcode's pseudolokalisatie-oppervlakte-stringuitbreiding en rechts-naar-links lay-out bugs voordat een vertaler het bestand opent; Firebase Test Lab en Apple's TestFlight valideren vervolgens de gelokaliseerde build op echte apparaten voordat deze in de app store wordt beoordeeld.
• Taalkundige kwaliteitslaag: De Linguistic Quality Assurance (LQA)-tools van Smartling scoren vertalingen aan de hand van een MQM-gebaseerd schema, waarbij een objectief kwaliteitsgetal wordt opgeleverd in plaats van de subjectieve goedkeuring van een enkele reviewer.

Tools voor mobiele lokalisatie en testen: belangrijke cijfers

Welke stappen zijn er betrokken bij het lokalisatieproces van apps voor smartphones?

1. Extraheer en internationaliseer tekenreeksen — haal de voor de gebruiker zichtbare tekst uit de code en sla deze op in resourcebestanden (Android XML voor Android, Localizable.strings of Stringsdict voor iOS), zodat niets hardgecodeerd is en elke tekenreeks een unieke sleutel heeft.
2. Koppel de bronbestanden aan een vertaalplatform — push die bestanden via een API of een connector zoals de GitHub Connector van Smartling, die een repository-branch bijhoudt en gewijzigde strings automatisch doorstuurt.
3. Vertaal met visuele context — upload screenshots of een schermopname zodat OCR-gebaseerde Visual Context elke string kan koppelen aan het scherm waarop hij verschijnt, waardoor vertalers de omringende UI krijgen in plaats van een geïsoleerde string.
4. Voer taalkundige en functionele kwaliteitscontrole uit : beoordeel vertalingen aan de hand van een LQA/MQM-schema en pseudolokaliseer de build (Android Studio's XA/XB-locales, Xcode's pseudolokalisatie) om problemen met tekenreeksuitbreiding, afkapping en RTL-lay-out op te sporen vóór handmatige controle.
5. Test op echte apparaten en breng het uit via app-review — valideer de gelokaliseerde build met Firebase Test Lab of TestFlight, dien het vervolgens in via Google Play of de App Store, waar de beoordelingstijd — en niet vertaling — meestal de langste stap in de release is.

Welke teams profiteren het meest van een gestructureerd proces voor de lokalisatie van mobiele apps?

• Teams verzenden naar drie of meer locaties in een terugkerende release-cadens, waarbij ad hoc vertaling stopt met schalen na de eerste twee talen.
• Teams waarvan de app-inhoud deels in resourcebestanden en deels in dynamische, door de server aangeleverde content is opgeslagen, hebben voor beide een consistente vertaalpipeline nodig.
• Teams die al mobiele releases uitvoeren via een CI/CD-pipeline, waarbij een repository-connector lokalisatie in een bestaande pull-request-workflow integreert in plaats van een handmatige overdracht.
• Teams die een gedocumenteerd kwaliteitsrecord nodig hebben, zoals in gereguleerde sectoren waar een op MQM gebaseerde LQA-score als bewijs van beoordeling fungeert.
• Teams beheren gebruikersgerichte meldingen en berichten — pushmeldingen, transactionele e-mails en afmeld- of voorkeurscentrumtekst — over regio's heen, waar inconsistente vertaling direct invloed heeft op compliance en gebruikersvertrouwen.

Wanneer is een volledig lokalisatieprogramma niet de juiste eerste investering?

• Een pre-launch app die nog steeds de product-markt fit valideert in één markt — vertaling is een geschonken kost totdat het kernproduct stabiel is.
• Een eenmalige vertaling naar één extra taal zonder geplande updatefrequentie, waarbij een lichtere, eenmalige vertaalronde mogelijk kosteneffectiever is dan een op connectoren gebaseerde pipeline.
• Een app met slechts een paar honderd gebruikersgerichte strings, waar handmatige bestandsoverdracht nog steeds beheersbaar kan zijn zonder geautomatiseerde tools.

Wat moet je controleren voordat je een lokale mobiele app uitstuurt?

Passen de vertaalde teksten nog steeds bij de gebruikersinterface?
Pseudolocaliseer de build eerst — zowel de XA/XB-locales van Android als de pseudolokalisatie van Xcode zelf breiden Engelse UI-tekst uit en markeren deze opnieuw — zodat afkappingen en lay-outproblemen zichtbaar worden voordat een vertaler het bestand opent.

Is elke string beoordeeld met visuele context, niet op zichzelf?
Een string die wordt vertaald zonder het scherm te zien, is een veelvoorkomende bron van contextblinde fouten; het koppelen van screenshots of schermopnames aan strings via OCR geeft taalkundigen de daadwerkelijke gebruikersinterface om vanuit te werken.

Wordt de kwaliteit van vertalingen gemeten, of wordt deze slechts aangenomen?
Laat vertalingen door een Linguistic Quality Assurance-schema lopen met een MQM-gebaseerde score in plaats van te vertrouwen op de subjectieve goedkeuring van één reviewer.

Worden meldingen en accountbeheerteksten — inclusief de tekst voor afmelden en het voorkeurencentrum — volgens dezelfde standaard gelokaliseerd als de hoofdapp?
Pushmeldingen, transactionele e-mails en afmeldprocedures worden vaak buiten de hoofdbestanden van de app beheerd en worden daardoor over het hoofd gezien bij een lokalisatieaudit. Dit leidt tot een gebrek aan vertrouwen bij de gebruiker en een tekortkoming in de naleving van regelgeving.

Is de build vóór indiening op echte apparaten getest?
Voer de gelokaliseerde build uit via Firebase Test Lab of TestFlight tegen de daadwerkelijke doelmarkt-apparaatmix, aangezien alleen testen in de simulator problemen met lettertyperendering en OS-versieproblemen mist.

Wordt de app store-vermelding apart gelokaliseerd van de in-app-teksten?
Een vertaalde app die alleen in het Engels wordt aangeboden in de Google Play Store of App Store, verliest het conversievoordeel van lokalisatie nog voordat een gebruiker de app opent.

Hoe ondersteunt Smartling de lokalisatie van mobiele apps?

Smartling ondersteunt native mobiele lokalisatie direct binnen de bestandsformaten die een iOS- of Android-build al gebruikt — Android XML-stringresources, iOS Stringsdict-bestanden en ICU MessageFormat voor pluralisatie — dus vertaalde content valt terug in een build zonder een aparte conversiestap. Omdat native apps geen HTML hebben voor een browsergebaseerde tool om te scannen, gebruikt Smartling's Visual Context-functie OCR om geüploade screenshots of schermopgenomen video exact te matchen met de string waarop een vertaler werkt, waardoor het giswerk van het vertalen van UI-tekst zonder zicht op het scherm wordt weggenomen.

Voor teams die mobiele releases uitvoeren via GitHub, GitLab of Beanstalk, houdt de Repository Connector van Smartling – inclusief een speciale GitHub Connector – een specifieke branch bij, stuurt automatisch nieuwe of gewijzigde strings in resourcebestanden door en pusht voltooide vertalingen terug. Hierdoor blijft lokalisatie binnen dezelfde pull-request workflow die een mobiel ontwikkelingsteam al gebruikt. De kwaliteit van vertalingen wordt beoordeeld met behulp van Smartling's tools voor taalkundige kwaliteitsborging. Deze tools passen een op MQM gebaseerd schema toe, waardoor een lokalisatieteam kan verwijzen naar een objectief kwaliteitscijfer in plaats van de subjectieve mening van een reviewer.