Hoe lokaliseer je een mobiele app

TABLE OF CONTENTS

Als je zoekt naar hoe je een mobiele app kunt lokaliseren, heb je meestal geen “vertaaltips” nodig. Je hebt een release-veilige workflow nodig die app-strings, layout, meervoudsregels, rechts-naar-links ondersteuning, screenshots en store-metadata dekt zonder het product te breken.

Dat is het belangrijkste verschil: lokalisatie van mobiele apps is niet alleen tekst vertalen. Het gaat om het aanpassen van de app, de productpagina en het QA-proces voor elke doelmarkt. Apple zegt dat de App Store beschikbaar is in 175 regio’s en 40 talen, terwijl Android 13 taalvoorkeuren per app op systeemniveau introduceerde. Met andere woorden, beide grote platformen gaan er nu vanuit dat taalkeuze een kernonderdeel van de productervaring is, geen bijzaak.

Deze gids doorloopt de praktische stappen voor iOS- en Android-teams.

In een oogopslag:

Scheid in-app lokalisatie van App Store- en Google Play-lokalisatie.
Externaliseer strings voordat je iets vertaalt.
Pak meervouden, variabelen, datums, valuta en RTL vroegtijdig aan.
Test met pseudotalen voordat je echte vertalingen uitbrengt.
Lokaliseer screenshots en store-assets, niet alleen beschrijvingen.

Wat lokalisatie van mobiele apps eigenlijk inhoudt

Lokalisatiewerk valt doorgaans in twee sporen uiteen.

1. In-app lokalisatie

Dit is het product zelf:

UI-strings
foutmeldingen en onboarding-teksten
datums, tijd, getallen, valuta en eenheden
meervouds- en geslachtsgevoelige strings
layout-uitbreiding en rechts-naar-links gedrag
afbeeldingen of pictogrammen die tekst of richtingsbetekenis bevatten

Apple beveelt expliciet aan om Xcode, Foundation API’s, Auto Layout, Unicode-ondersteuning, gelokaliseerde asset-catalogi en richtingsbewuste symbolen te gebruiken om apps voor te bereiden op wereldwijde markten. Android beveelt op vergelijkbare wijze locale-bewuste resources, app-taalondersteuning en RTL-bewuste layouts aan in plaats van hardgecodeerde tekst en positionering.

2. Lokalisatie van store-vermeldingen

Zo ontdekken gebruikers je app:

app-naam
ondertitel of korte beschrijving
volledige beschrijving
zoekwoorden
screenshots
app-previews of promotievideo’s

Behandel dit als een apart deliverable. Een goed gelokaliseerde app kan nog steeds ondermaats presteren als de productpagina generiek, onvertaald of visueel niet passend is voor de doelmarkt.

Begin met internationalisatie, niet met vertaling

Vertaling is de laatste stap in een pijplijn die begint met structuur.

Externaliseer strings en houd een compleet fallback-locale aan

Op Android waarschuwt Google dat je standaard res/values/strings.xml elke string moet definiëren die je app nodig heeft. Als het standaardbestand onvolledig is en het apparaat draait in een niet-ondersteund locale, kan de app niet laden en een foutmelding met een Force Close-knop tonen. Daarom begint lokalisatie met resource-hygiëne, niet met taalselectie.

Voor iOS beveelt Apple aan om voor de gebruiker zichtbare tekst en afbeeldingen te scheiden van uitvoerbare code, zodat ze als resourcebestanden kunnen worden gelokaliseerd. In moderne Apple-workflows zijn string catalogs de aanbevolen aanpak in Xcode 15 en later voor strings die meervouden bevatten.

Praktische regel:

codeer UI-tekst nooit hard in views of controllers
houd één canonieke brontaal aan
zorg ervoor dat elke voor de gebruiker zichtbare string een stabiele key, context en fallback heeft
voeg vertaalcommentaren toe voor dubbelzinnige strings

Een klein voorbeeld maakt dit makkelijker voor te stellen.

Android begint meestal met een standaard strings.xml-bestand:

<!-- Primary CTA on the checkout screen. Keep it short. -->
<string name="checkout_cta">Pay now</string>
<string name="welcome_title">Welcome back, %1$s</string>

Vervolgens leest je UI de resource in plaats van Engels hard te coderen:

Text(text = stringResource(R.string.checkout_cta))

Op Apple-platformen beheert Xcode 15+ vaak hetzelfde idee in een string catalog. Een vereenvoudigd Localizable.xcstrings-fragment kan er zo uitzien:

{
  "sourceLanguage": "en",
  "strings": {
    "Pay now": {
      "localizations": {
        "en": { "stringUnit": { "value": "Pay now" } },
        "fr": { "stringUnit": { "value": "Payer maintenant" } }
      }
    }
  }
}

Je hoeft het bestandsformaat niet uit je hoofd te leren. De operationele les is eenvoudiger: elke voor de gebruiker zichtbare string heeft één bron van waarheid nodig, voldoende context voor vertalers en een veilige fallback wanneer een locale onvolledig is.

Als je app ook gestructureerde taalbestanden levert, kan onze gids over Best JSON Translators in 2026 je helpen nadenken over automatisering en formaatbehoud.

Als je een directe tool-optie wilt voor app-resourcebestanden, is OpenL JSON Translator het bekijken waard. Het is ontworpen om .json-bestanden te vertalen zonder keys of structuur te breken, wat precies is wat je nodig hebt wanneer app-strings worden opgeslagen in machineleesbare lokalisatiebestanden. De workflow is eenvoudig: upload de JSON die is geëxporteerd uit je app, CMS of lokalisatiepijplijn, kies de doeltaal en download een vertaald JSON-bestand met dezelfde structuur. Volgens de productpagina ondersteunt het 100+ talen en bestanden tot 50 MB, waardoor het een praktisch first-pass hulpmiddel is voor app-lokalisatieteams die met gestructureerde content werken.

Ondersteun taalselectie op app-niveau

Gebruikers verwachten steeds vaker dat ze een app-taal kunnen kiezen los van hun apparaattaal.

Op Apple-platformen kunnen gebruikers hun voorkeurstaal voor een app onafhankelijk van de apparaattaal selecteren. Op Android heeft Android 13 een gecentraliseerde app-taalinstelling toegevoegd, en Google beveelt aan om automatische per-app taalondersteuning in te schakelen of je keuzemenu aan de officiële API’s te koppelen.

Dit is belangrijk voor echte producten. Tweetalige en meertalige gebruikers houden hun telefoon mogelijk in het Engels, maar geven de voorkeur aan een winkel-, bank- of bezorg-app in een andere taal. Als je app één taalmodel afdwingt, creëer je wrijving voordat de vertaalkwaliteit überhaupt ter sprake komt.

Gebruik de lokalisatiestack van het platform

Weersta de neiging om een parallel lokalisatiesysteem te bedenken, tenzij je er echt een nodig hebt.

Voor de meeste teams is de standaard platformstack voldoende:

iOS: string catalogs, Localizable.strings, .stringsdict, Foundation formatters, Auto Layout
Android: res/values/, locale-specifieke resourcemappen, LocaleConfig, setApplicationLocales(), supportsRtl

Aangepaste lokalisatie-infrastructuur is zinvol op zeer grote schaal, maar het voegt operationele overhead toe. Begin met het native systeem en breid alleen uit waar je echte pijnpunten ervaart.

Lokaliseer de onderdelen die de meeste teams missen

Teams vertalen vaak zichtbare zinnen en missen de productmechanismen eromheen.

Meervouden, variabelen en grammatica

Meervoudsregels zijn niet universeel. De Unicode CLDR-meervoudsregels definiëren categorieën zoals zero, one, two, few, many en other, en verschillende talen gebruiken verschillende subsets. Apple merkt op dat in oudere .stringsdict-workflows other de enige vereiste categorie is, maar het overslaan van taalspecifieke categorieën kan nog steeds grammaticaal onjuiste output opleveren. Android en iOS vertrouwen beide met reden op locale-bewuste meervoudsverwerking.

Dit is waar naïeve machinevertaling tekortschiet:

1 file vs 2 files is eenvoudig in het Engels
Slavische talen hebben vaak meer dan twee meervoudsvormen nodig
sommige talen veranderen zelfstandige naamwoorden, werkwoorden of omringende woorden samen

Bouw nooit meervouds-UI door fragmenten samen te voegen zoals "You have " + count + " messages". Gebruik in plaats daarvan platform-meervoudsresources.

Hier is de minimale vorm daarvan op elk platform.

Android:

<plurals name="files_remaining">
  <item quantity="one">%1$d file remaining</item>
  <item quantity="other">%1$d files remaining</item>
</plurals>

Text(text = pluralStringResource(R.plurals.files_remaining, count, count))

iOS legacy .stringsdict-voorbeeld:

<plist version="1.0">
<dict>
  <key>%#@files@</key>
  <dict>
    <key>NSStringLocalizedFormatKey</key>
    <string>%#@files@</string>
    <key>files</key>
    <dict>
      <key>NSStringFormatSpecTypeKey</key>
      <string>NSStringPluralRuleType</string>
      <key>NSStringFormatValueTypeKey</key>
      <string>d</string>
      <key>one</key>
      <string>%d file remaining</string>
      <key>other</key>
      <string>%d files remaining</string>
    </dict>
  </dict>
</dict>
</plist>

In Xcode 15 en later beveelt Apple aan om meervouden in string catalogs af te handelen, maar het principe blijft hetzelfde: geef het platform één berichtpatroon en laat het de juiste taalvorm kiezen.

Voor diepere workflow-richtlijnen rond placeholders en gestructureerde strings, zie How to Translate Technical Docs Without Breaking Code.

Datums, getallen, valuta en eenheden

Apple beveelt expliciet aan om Foundation API’s te gebruiken voor het formatteren van datums, lengtes, gewichten, prijzen en valutasymbolen over locales heen. Hetzelfde principe geldt op Android: formatteer gegevens met locale-bewuste API’s in plaats van interpunctie, decimaaltekens of eenheidsvolgorde hard te coderen.

Typische fouten zijn onder andere:

03/04/2026 dat in verschillende regio’s iets anders betekent
hardgecodeerde dollartekens voor niet-USD-markten
1,234.56 dat onjuist wordt weergegeven in locales die komma’s als decimaalscheidingsteken gebruiken
meeteenheden die in het verkeerde systeem worden getoond

Als je app planning, facturering, bezorgvensters of analytics bevat, is dit onderdeel van lokalisatie, geen afwerking.

Layout-uitbreiding en rechts-naar-links ondersteuning

Engels is meestal compact. Duits wordt langer. Arabisch en Hebreeuws keren de leesrichting om. Een layout die er in het Engels goed uitziet, kan in andere locales ernstig breken.

Apple beveelt aan om te testen met pseudotalen, waaronder een rechts-naar-links pseudotaal en een dubbele-lengte pseudotaal, voordat je echte vertalingen importeert. Android beveelt aan om start en end te gebruiken in plaats van left en right, android:supportsRtl="true" in te schakelen en RTL-layouts op het apparaat te testen met Force RTL.

Je checklist hier is eenvoudig:

laat knoppen en labels groeien
vermijd tekstcontainers met vaste breedte voor belangrijke UI
spiegel directionele UI waar van toepassing
verifieer pictogrammen, chevrons, voortgangsstromen en carrousels in RTL
test gemengde-richting tekst zoals Arabische UI met Latijnse productnamen of couponcodes

Afbeeldingen, pictogrammen, screenshots en video

Apple’s lokalisatierichtlijnen maken een belangrijk punt dat veel teams over het hoofd zien: afbeeldingen kunnen ook worden gelokaliseerd. Dat omvat image sets, symbol sets en directionaliteit voor aangepaste symbolen. Als je screenshot Engelse UI bevat, Engelse tekst in banners of links-naar-rechts pijlen, dan is de screenshot zelf niet gelokaliseerd.

Dat is vooral belangrijk voor onboarding-schermen, tutorial-kaarten en App Store-assets. Gebruikers scheiden “marketingvisuals” niet mentaal van “producttaal.” Ze beoordelen de hele ervaring in één keer.

Lokaliseer je App Store- en Google Play-pagina’s apart

Dit is waar veel teams installaties verliezen, zelfs nadat ze het in-app werk goed hebben gedaan.

App Store-vereisten om rekening mee te houden

Apple beveelt aan om metadata te lokaliseren in App Store Connect, waaronder de app-beschrijving, zoekwoorden, app-previews en screenshots. Apple zegt ook dat je tot 10 screenshots op je productpagina kunt tonen, en tot 3 app-previews per ondersteund apparaatformaat en taal. App-previews kunnen tot 30 seconden lang zijn, en screenshots zijn nog belangrijker wanneer er geen preview aanwezig is, omdat de eerste één tot drie screenshots kunnen verschijnen in zoekresultaten.

Dat heeft twee implicaties:

Je eerste screenshots zijn vindbaarheids-assets, niet alleen documentatie.
Je moet screenshots en previews lokaliseren voor topprioriteitsmarkten in plaats van overal Engelse assets te hergebruiken.

Google Play-vereisten om rekening mee te houden

Google Play behandelt lokalisatie van vermeldingen ook als een eigen workflow. Play Console laat je gelokaliseerde tekst, screenshots in de doeltaal en gelokaliseerde grafische assets toevoegen. Als je tekstvertalingen toevoegt zonder gelokaliseerde grafische assets, zegt Google dat de standaardtaal-visuals nog steeds worden getoond.

Google merkt ook op dat als je geen eigen store-vermeldingsvertalingen toevoegt, gebruikers mogelijk een automatische vertaling zien met een melding dat deze automatisch is gegenereerd. Dat is nuttig als fallback, maar geen sterke strategie voor markttoetreding.

Een bijzonder relevante huidige functie: Play Console zegt dat het continu app-strings kan vertalen met behulp van Gemini-modellen zonder kosten. Meer specifiek zegt Google dat dit van toepassing is op app-strings uit strings.xml in app-bundels die zijn geüpload naar conceptreleases, en dat je de gegenereerde vertalingen kunt bekijken in een ingebouwde emulator voordat je publiceert. Dat is een krachtige manier om first-pass dekking te versnellen, maar het moet nog steeds worden gevolgd door menselijke review voor kritieke flows.

Bouw een release- en QA-workflow

Een goed lokalisatieproces gaat minder over sneller vertalen en meer over het uitbrengen van minder verrassingen.

Stap 1. Kies doellocales bewust

Begin niet met “vertaal alles in 20 talen.”

Begin met:

je huidige downloadmix
landen die je actief ondersteunt
facturering, juridische en klantenservice-dekking
of je zowel de app als de store-vermelding samen kunt lokaliseren

Eén markt end-to-end uitleveren verslaat meestal vijf markten halverwege.

Stap 2. Maak lokalisatie-klare assets

Voordat de vertaling begint, bevries en bereid voor:

bronstrings met context
screenshotlijst per locale
woordenlijst en productnaamregels
placeholder-regels
tekenlimietrichtlijnen voor store-teksten
locale-specifieke review-eigenaren

Als de app aparte repo’s of meerdere bestandsformaten gebruikt, standaardiseer naamgeving en extractie vroegtijdig.

Stap 3. Test eerst met pseudolokalisatie

Op Apple-platformen, gebruik dubbele-lengte en rechts-naar-links pseudotalen. Op Android, test niet-ondersteunde locales, Force RTL en app-taalinstellingen. Dit vangt:

afgekapte knoppen
bijgesneden headers
verborgen tekst
verkeerde uitlijning
niet-gelokaliseerde strings
hardgecodeerde links/rechts-aannames

Dit is een van de goedkoopste QA-passes die je kunt uitvoeren.

Stap 4. Voer taalkundige QA uit op echte apparaten

Nadat vertalingen zijn opgeleverd:

test kritieke flows in elke doeltaal
vergelijk het gedrag van systeemtaal en app-taal
verifieer meervoudsgedrag en placeholders
controleer betalingen, datums en adressen
bekijk screenshots en store-vermeldingen in de markt

Als een bug onboarding, checkout, identiteitsverificatie of notificaties beïnvloedt, behandel het als een release-blocker.

Een checklist voor de eerste lokalisatiesprint

Als dit je eerste serieuze uitrol is, houd de sprint klein genoeg om schoon af te ronden:

Die checklist is opzettelijk beperkt. Eén locale met een schone app-ervaring en gesynchroniseerde store-assets leert je veel meer dan een gehaaste lancering over veel markten.

Praktijkvoorbeelden

De bovenstaande kernideeën zijn niet theoretisch.

DoorDash bouwde vertaling als een platformprobleem

In 2022 zei DoorDash dat het al meer dan een miljoen strings in vier talen had vertaald en het onboarden van nieuwe talen had teruggebracht van uren ontwikkelaarsinspanning naar één commando in één minuut. De interessante les is niet alleen schaal. Het is structuur: DoorDash scheidde statische en dynamische strings, voegde woordenlijst- en stijlgidsondersteuning toe, en bouwde beveiligingen om te voorkomen dat onvertaalde strings erdoorheen glippen.

In een DoorDash-blogpost van 2 februari 2026 zei het bedrijf dat zijn herbouwde onboardingplatform nu aanmeldingen aanstuurt in alle DoorDash-markten en snelle internationale lanceringen ondersteunt met naadloze lokalisatie. Dat is precies hoe volwassen lokalisatie eruitziet: herbruikbare workflows, regionale flexibiliteit en minder eenmalige workarounds.

Meta behandelde lokalisatie als zowel een taalprobleem als een app-grootteprobleem

Meta zegt dat ongeveer 57% van Facebook voor Android-gebruikers en 49% van Facebook voor iOS-gebruikers de app in een andere taal dan Engels gebruiken. In dezelfde publicatie zegt Meta dat het verwijderen van meegeleverde vertaalbestanden tot 16,6 MB bespaarde in de iOS-app en het mogelijk maakte om op Android bijna een dozijn extra talen toe te voegen zonder de app-grootte te vergroten.

De conclusie is ook nuttig voor kleinere teams: lokalisatie heeft technische consequenties. Het beïnvloedt de binary-grootte, het laden tijdens runtime, de levering van vertalingen en de release-mechanismen, niet alleen het schrijven van teksten.

Laatste checklist voor je uitbrengt

Gebruik dit als een laatste controle:

Alle voor de gebruiker zichtbare strings zijn geëxternaliseerd.
Standaard fallback-resources zijn compleet.
Meervouden en placeholders gebruiken platform-native lokalisatieondersteuning.
Datums, tijd, getallen, valuta en eenheden zijn locale-bewust.
RTL-layouts en gemengde-richting tekst zijn getest.
Store-vermeldingstekst is gelokaliseerd voor doelmarkten.
Screenshots en previews zijn gelokaliseerd voor prioriteitstalen.
In-app taalselectie werkt zoals verwacht op iOS en Android.
Taalkundige QA heeft de belangrijkste gebruikersroutes gedekt.

Slotgedachten

De eenvoudigste manier om over lokalisatie van mobiele apps te denken is: vertaal het product, lokaliseer de ervaring en test de release.

Als je dit voor het eerst doet, streef dan niet naar perfecte wereldwijde dekking op dag één. Kies een of twee strategische locales, lokaliseer de app en de store-pagina samen, voer een serieuze QA-pass uit en leer van echt gebruik. Als je al resourcebestanden en ontwikkelaargerichte content beheert, combineer deze workflow met How to Translate Technical Docs Without Breaking Code en Best JSON Translators in 2026.

Als je deze week maar één actie onderneemt, doe dan dit: kies 1 locale, voer 1 pseudolokalisatiepass uit en lokaliseer 1 bijpassende App Store- of Google Play-vermelding. Die driedelige test vertelt je meer over je gereedheid dan twintig locales parallel vertalen.

Als je een snelle eerste pass nodig hebt voor app-tekst, screenshots of gestructureerde taalbestanden, gebruik dan automatisering om het concept te versnellen en houd vervolgens een menselijke QA-stap aan voor de release. Dat is het onderdeel dat het vertrouwen van gebruikers beschermt en een “vertaald maar niet echt gelokaliseerd” lancering voorkomt.

Referenties

Apple Developer. Localization. https://developer.apple.com/localization/
Apple Developer. Creating Your Product Page. https://developer.apple.com/app-store/product-page/
Apple Developer. Upload app previews and screenshots. https://developer.apple.com/help/app-store-connect/manage-app-information/upload-app-previews-and-screenshots
Apple Developer. Localizing strings that contain plurals. https://developer.apple.com/documentation/xcode/localizing-strings-that-contain-plurals
Apple Developer. Testing Your Internationalized App. https://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPInternational/TestingYourInternationalApp/TestingYourInternationalApp.html
Apple Developer. Get it right (to left). https://developer.apple.com/videos/play/wwdc2022/10107/
Android Developers. Localize your app. https://developer.android.com/guide/topics/resources/localization
Android Developers. Per-app language preferences. https://developer.android.com/guide/topics/resources/app-languages
Android Developers. Support different languages and cultures. https://developer.android.com/training/basics/supporting-devices/languages
Google Play Console Help. Translate and localize your app. https://support.google.com/googleplay/android-developer/answer/9844778?hl=en
Google Play Console Help. Create and set up your app. https://support.google.com/googleplay/android-developer/answer/9859152?hl=en
Unicode CLDR. Plural Rules. https://cldr.unicode.org/index/cldr-spec/plural-rules
DoorDash Engineering. Building a Platform to Translate DoorDash into Multiple Languages. https://careersatdoordash.com/blog/building-a-platform-to-translate-doordash-into-multiple-languages/
DoorDash Engineering. Unified Dasher Onboarding: A modular platform to scale globally. https://careersatdoordash.com/blog/doordash-unified-dasher-onboarding-a-modular-platform-to-scale-globally/
Engineering at Meta. Language packs: Meta’s mobile localization solution. https://engineering.fb.com/2022/05/09/android/language-packs/