Mobiele App-lokalisatietests: De iOS- en Android-checklist voor wereldwijde releases

Je app werkt prima in het Engels. Dan boekt marketing een lancering in Duitsland, Japan en Brazilië, en plotseling wordt de knop “Continue” “Weitermachen”, komt de pushmelding om 3 uur ’s nachts lokale tijd binnen, en tonen de App Store-screenshots nog steeds prijzen in Amerikaanse dollars. Niets daarvan is een vertaalprobleem. Het is een mobiel QA-probleem, en het lijkt in niets op de QA die je voor de Engelse build hebt uitgevoerd.

Mobiele app-lokalisatietests controleren of een vertaalde app op iOS- en Android-toestellen in elke doelmarkt correct wordt weergegeven, functioneert en vindbaar is. Dit artikel richt zich op wat er werkelijk verandert wanneer lokalisatie-QA van het bureaublad naar een telefoon verhuist: de platform-API’s, de twee stores, de pushpayload, het toetsenbord en de fysieke apparaatmatrix. De algemene definities en het end-to-end-proces worden apart behandeld in ons overzicht van wat lokalisatie-QA-tests zijn. Alles hieronder is uitsluitend mobiel.

Wat er op het spel staat, is het benoemen waard. Sensor Tower meldt dat de wereldwijde omzet uit in-app-aankopen in 2025 167 miljard dollar bereikte, een stijging van 10,6% ten opzichte van het jaar ervoor, waarbij de groei werd gestimuleerd door niet-Engelstalige markten in West-Europa, Latijns-Amerika en APAC. Een lokalisatiebug in een topmarkt raakt rechtstreeks de omzet.

Wat we controleren bij kwaliteitscontrole van mobiele lokalisatie

Vertaalkwaliteit is één onderdeel van lokalisatie-QA en dekt op zichzelf misschien een kwart van wat er mis kan gaan. Wanneer een build op onze toestellen terechtkomt, kijken we naar vier oppervlakken tegelijk, en een bug in elk daarvan kan een lancering doen mislukken. Dit is ook waar het meeste werk plaatsvindt binnen onze lokalisatietestdiensten.

Taalkundige nauwkeurigheid in de context

Een tekenreeks die perfect leest in een spreadsheet kan fout zijn zodra deze in een knop terechtkomt. “Save”, vertaald als het Spaanse “Guardar”, is prima op een instellingenpagina en verwarrend in een winkelwagentje, waar “Guardar” “bewaren voor later” impliceert in plaats van “bevestigen”. Onze testers controleren tekenreeksen in hun daadwerkelijke UI-context, op een echt scherm, met echte data die erdoorheen stroomt. Placeholders zoals {username} en {count} krijgen speciale aandacht omdat een kapotte variabele vaak op een typefout lijkt totdat iemand merkt dat hij nooit wordt opgelost.

UI-integriteit nadat de teksten zijn ingevoegd

Vertaalde tekst heeft een lengte. Duits is ongeveer 30% langer dan Engels, Fins volgt op de voet, en CJK-scripts nemen minder horizontale ruimte in maar hebben een hogere regelhoogte. Op een iPhone-canvas van 375 pixels wordt dat verschil ofwel netjes afgebroken, ofwel breekt het tabbladen, navigatiekoppen en call-to-action-knoppen. We controleren tekstafkapping, overlappende knoppen, botsingen met de veilige zone op toestellen met een inkeping, en hoe de layout Dynamic Type op iOS en de lettergrootteschaal op Android doorstaat.

Regiogevoelig gedrag

Datums, valuta, telefoonnummerformaten, meeteenheden en zelfs sorteervolgorde veranderen met de regio van de gebruiker. Een prijs die “1,000.00 EUR” toont in Duitsland zou lokaal “1.000,00 €” moeten weergeven, met het symbool achter het getal. Op iOS en Android 13 en hoger staat regio los van taal, zodat een gebruiker de app in het Engels kan lezen terwijl hij metrische eenheden en de 24-uursklok verwacht. Hier wordt lokalisatietests voor mobiele applicaties niet-vanzelfsprekend: de verkeerde formatter is een functionele bug.

Store-gerichte oppervlakken die gebruikers zien voordat ze installeren

Het eerste gelokaliseerde oppervlak dat de meeste gebruikers tegenkomen, is de store-vermelding, niet de app. Titel, subtitel, beschrijving, screenshots en preview-video moeten overeenkomen met de taal in de app waar ze na het tikken op Installeren in terechtkomen. Als de App Store-pagina Duits belooft en de app opent in het Engels, stroomt de reviewsectie binnen 48 uur vol met eensterrenklachten.

Waar iOS- en Android-lokalisatie uiteenlopen

Android heeft tot en met 2026 ongeveer 71-73% van de wereldwijde smartphoneleveringen in handen, terwijl iOS het grootste deel van de consumentenuitgaven aan apps binnenhaalt, volgens IDC’s Worldwide Quarterly Mobile Phone Tracker. Je hebt beide nodig, en de twee platforms behandelen regio-instellingen op werkelijk verschillende manieren.

iOS-taalmechanismen

iOS bewaart vertalingen in .strings-bestanden voor platte key-value-paren en .stringsdict-bestanden voor meervoudsvormen en vormen naar geslacht. Info.plist geeft aan welke regio’s de bundel ondersteunt via CFBundleLocalizations. NSLocalizedString haalt tijdens runtime de juiste tekenreeks op basis van de voorkeurstalen van de gebruiker, opgelost via de Bundle. Sinds iOS 13 kunnen gebruikers per app een andere taal kiezen via Instellingen → App → Taal zonder het hele toestel te veranderen, wat betekent dat QA halverwege een sessie van taal moet wisselen en moet controleren of gecachte tekenreeksen worden vernieuwd.

Android-taalmechanismen

Android gebruikt gekwalificeerde resourcemappen: values/, values-fr/, values-b+es+419/ voor Latijns-Amerikaans Spaans. Tekenreeksen staan in strings.xml, meervoudsvormen in plurals.xml, en Android doorloopt een terugvalketen als een regio ontbreekt. Sinds Android 13 (API 33) maken LocaleManager en AppCompatDelegate.setApplicationLocales() taalselectie per app mogelijk. Ondersteuning voor rechts-naar-links vereist android:supportsRtl=”true” in het manifest en de layoutattributen start/end in plaats van left/right.

Een snelle vergelijking om op je QA-whiteboard te zetten:

De mobiel-only QA-checklist

Hier zijn zes controles die alleen op een telefoon van belang zijn. Sla er een over, en de lancering zal het laten zien. De onderstaande secties variëren in vorm omdat de controles zelf dat ook doen; sommige passen bij lopende tekst, andere horen bij een lijst.

Tekstuitbreiding op een canvas van 375 pixels

Pseudo-lokaliseer voordat de echte vertalingen binnenkomen. Vervang Engelse tekenreeksen door verlengde Latijnse varianten (“Sëttîngß” in plaats van “Settings”) om in elke build layoutstress te forceren. Controleer liggende weergave, split-view op iPad en lettergrootteschaal ingesteld op 200% voor toegankelijkheid. Knoppen die er in het Engels krap uitzien, breken in het Duits zodra de vertalingen binnenkomen, en tegen die tijd is de sprint al voorbij.

RTL-layout op touch-UI

Arabisch, Hebreeuws, Urdu en Perzisch keren de hele interface om. Navigatiegebaren draaien om, chevrons spiegelen, voortgangsbalken vullen vanaf de tegenoverliggende rand, en videoschuifbalken bewegen in de tegenovergestelde richting. Iconen die beweging suggereren, moeten worden gespiegeld, terwijl merktekens en logo’s ongewijzigd blijven. Controleer of het toestel daadwerkelijk op Arabisch staat ingesteld, en let op de oppervlakken die de meeste teams vergeten: transactiegeschiedenis, uitlijning van chatberichten, foutmeldingen bij formuliervalidatie en aangepast getekende grafieken.

Pushmeldingen per regio

Lokalisatie van pushmeldingen gaat op manieren mis die moeilijk op te sporen zijn zonder speciale tests. APNs ondersteunt loc-key en loc-args, en FCM ondersteunt title_loc_key en body_loc_args, waarmee het besturingssysteem meldingen in de huidige taal van het toestel weergeeft in plaats van de taal die je server op het moment van verzenden aannam. Dit is belangrijk omdat een gebruiker de apptaal kan wijzigen nadat zijn pushtoken is geregistreerd. Testers moeten het volgende controleren:

• Afkapping van de meldingstekst op het vergrendelscherm, ongeveer 60 tekens op iOS en 65 op Android, afhankelijk van het toestel.
• Tijdgebonden verzendingen gebeuren op basis van de tijdzone van de ontvanger in plaats van UTC. Een “goedemorgen”-melding gepland om 8 uur UTC bereikt Tokio om 17 uur.
• Gedrag van stille uren, Niet storen en Focus-modus per regio.
• Rijke meldingsafbeeldingen met regiospecifieke inhoud, indien gebruikt.

OS-niveauformatters, geen hardgecodeerde tekenreeksen

Overal waar je in de UI een datum, valuta, telefoonnummer of meeteenheid ziet, controleer of dit via de platformformatter verloopt. Op iOS betekent dat DateFormatter, NumberFormatter en MeasurementFormatter. Op Android DateFormat.getDateInstance() en NumberFormat.getCurrencyInstance(). Hardgecodeerde opmaak zoals String.format(“$%.2f”, price) is de meest voorkomende bron van regiogebonden bugs en een van de makkelijkste om in codereview te ontdekken voordat het ooit bij QA terechtkomt.

Toetsenborden, autocorrectie en dictie

Japanse, Chinese en Koreaanse IME’s veranderen de hoogte van het invoerveld wanneer de suggestiebalk verschijnt, wat op kleinere schermen een verzendknop achter het toetsenbord kan duwen. Cyrillisch en Devanagari vereisen andere tekenvalidatie-regex dan Latijnse schriften. Autocorrectie kan in de ene taal stilzwijgend een eigennaam verminken en in een andere ongemoeid laten. Test elk formulierveld met het daadwerkelijke toetsenbord dat de doelgebruiker zal gebruiken, niet met de Engelse standaard.

Taal wisselen op het toestel zonder herstart

Zowel iOS 13+ als Android 13+ staat gebruikers toe de apptaal te wisselen zonder het toestel opnieuw op te starten. Als je app tekenreeksen cachet bij het opstarten en ze nooit opnieuw inleest, blijft de helft van de UI in de oude taal totdat de gebruiker de app geforceerd afsluit. Wissel tijdens QA halverwege een sessie van taal, navigeer door elke belangrijke flow en bevestig dat elk scherm wordt bijgewerkt. Deze bug is gebruikelijk, stil en komt alleen aan het licht op echte toestellen bij echte gebruikers. Dezelfde kloof met echte apparaten komt terug in de bredere reeks van uitdagingen bij mobiel testen, waar regiobugs en OEM-eigenaardigheden vaak samen voorkomen.

Lokalisatie-QA voor App Store- en Play Store-vermeldingen

Storemetadata is niet de app, maar het is het eerste gelokaliseerde oppervlak dat een gebruiker ziet. Twee stores, twee workflows, twee sets valkuilen, en beide indieningen kunnen worden afgewezen om problemen die QA had moeten opmerken.

App Store Connect

App Store-lokalisatie op iOS verloopt via App Store Connect, waar elke regio zijn eigen titel (30 tekens), subtitel (30), trefwoordveld (100), promotietekst (170), beschrijving (tot 4000), screenshots per toestelformaat, preview-video’s en “Wat is er nieuw” per release krijgt. App Store Connect-lokalisatie kent een specifieke valkuil: tekenaantallen worden berekend op basis van codepunten, dus Japanse katakana of Chinese hanzi in een titel kunnen de visuele breedte stilzwijgend overschrijden, zelfs als ze binnen het aantal tekens vallen. Controleer of de screenshots van elke regio de daadwerkelijk gelokaliseerde in-app-UI gebruiken, in plaats van de Engelse UI met een vertaald bijschrift erbovenop geplakt.

Google Play Console

Play Store-lokalisatie op Android wordt beheerd in Google Play Console onder Storevermelding, met titel (30), korte beschrijving (80), volledige beschrijving (4000), featuregrafiek, screenshots en promovideo per taal. Aangepaste storevermeldingen laten je verschillende content aanbieden per land, voorregistratiestatus of installatiestatus. Het formulier voor gegevensveiligheid moet ook worden gelokaliseerd. Eén bewuste controle: bevestig dat de automatische vertaling van Google Play is uitgeschakeld als je menselijke vertalingen hebt uitgebracht, omdat automatisch vertaalde metadata bovenop menselijke tekst inconsistente gebruikersgerichte tekst creëert en de conversie schaadt.

Een storevermelding die volledige lokalisatie belooft terwijl de app zelf half vertaald blijft, zal sneller eensterrenrecensies verdienen dan enige andere lanceerfout. Beoordelingen dalen, en ASO-ranglijsten volgen.

Het probleem van de matrix met echte apparaten

Emulators liegen over de weergave van regio-instellingen. Xiaomi levert MIUI met zijn eigen lettertypestack die Devanagari- en Arabische glyphs kan verminken. Samsungs One UI overschrijft sommige Dynamic Type-gedragingen. Oudere iPhones zonder inkeping hebben andere wiskunde voor de veilige zone die gelokaliseerde bannertekst op het beginscherm kan breken. Fallback-kettens voor lettertypen verschillen per fabrikant, en een Chinese tekenreeks die er op een Pixel netjes uitziet, kan er verkeerd uitzien op een Vivo-telefoon die populair is in precies die markt.

Een pragmatische apparaatmatrix voor een lancering in Duitsland, Japan en Brazilië ziet er ongeveer zo uit:

• iPhone 15, iPhone 13, iPhone SE (2e generatie) voor huidige en oudere iOS-layouts
• Pixel 8 als referentie-Android
• Samsung Galaxy S23 voor One UI-gedrag
• Xiaomi Redmi Note 12 voor MIUI-lettertyperendering
• Eén tablet per platform (iPad en een 10-inch Android-tablet)

We testen om precies deze redenen alleen op echte apparaten, en het zit ingebakken in onze testpraktijk voor mobiele applicaties bij meer dan 300 producten. Simulators kunnen OEM-lettertypestacks, echt toetsenbordgedrag of de manier waarop een specifiek toestelmodel een melding op het vergrendelscherm weergeeft, niet nabootsen. Wanneer een bug opduikt in een vijfsterrenmarkt, is deze bijna altijd apparaatspecifiek, en het is bijna nooit iets wat de emulator zou hebben opgemerkt.

Voordat je op indienen klikt

Mobiele lokalisatie-QA is waar vertaling, platform-API’s, store-indieningen en apparaatfragmentatie allemaal samenkomen op dezelfde lanceerdatum. Doe één laag verkeerd, en de markt waarin je hebt geïnvesteerd, koelt af. Doe alle vier goed, en de app voelt native aan zodra een gebruiker hem opent, wat de hele reden is om te lokaliseren. Als je een lancering in meerdere markten plant en QA wilt die deze faalmodi bij honderden producten heeft gezien, neem contact met ons op, en we stemmen het af op je doelmarkten en apparaatprofiel.

FAQ

Hoe test je de lokalisatie van een mobiele app?

Begin met het overzetten van een echt toestel naar de doelregio, in plaats van een vlag op een emulator te wijzigen. Controleer vertalingen in context op elk scherm, controleer de UI op tekstuitbreiding en -afkapping, bevestig dat datums, valuta en telefoonformaten platformformatters gebruiken, test pushmeldingen en hun timing per tijdzone, en loop de storevermelding apart door in App Store Connect en Google Play Console. Doe dit allemaal op de daadwerkelijke toestellen die populair zijn in de doelmarkt, niet op wat er toevallig op je bureau ligt.

Wat is lokalisatietesten voor een mobiele app?

Het is een QA-discipline die controleert of een vertaalde mobiele app correct werkt voor gebruikers in een specifieke taal, regio en apparaatomgeving. Het omvat taalkundige nauwkeurigheid in context, UI-integriteit nadat tekenreeksen uitbreiden of inkrimpen, regiogevoelige opmaak voor datums en valuta, gedrag van pushmeldingen, storevermeldingsmetadata en weergave op echte toestellen van de OEM’s die populair zijn in die markt. Vertaling alleen is maar een deel ervan.

Wat is het verschil tussen lokalisatietests voor iOS en Android?

De platforms behandelen regio-instellingen via verschillende bestandsformaten, API’s en storeworkflows. iOS gebruikt .strings- en .stringsdict-bestanden met NSLocalizedString en dient metadata per regio in via App Store Connect. Android gebruikt gekwalificeerde resourcemappen en strings.xml met getQuantityString en beheert vermeldingen per taal in Google Play Console. Instellingen voor taal per app zijn geïntroduceerd in iOS 13 en Android 13. Fragmentatie is dieper op Android omdat OEM-schillen zoals MIUI en One UI de lettertyperendering veranderen, waardoor de apparaatmatrix groter uitvalt.

Heb ik echte apparaten nodig voor lokalisatie-QA?

Ja. Emulators kunnen OEM-lettertypestacks, toetsenbordgedrag, meldingsweergave op echte vergrendelschermen of de manier waarop regiospecifieke toestellen glyph-fallback afhandelen, niet nabootsen. Een Chinese tekenreeks die er op een Pixel-emulator netjes uitziet, kan er kapot uitzien op een Vivo-telefoon die die markt domineert. Vrijwel elke lokalisatiebug die de App Store- of Play Store-recensies bereikt, is apparaatspecifiek, en dat is waarom testen op echte apparaten een harde eis is voor een wereldwijde lancering.