Checklist voor lokalisatietesten: alles wat u moet controleren naast vertalingen

Uw Duitse gebruikers zien een “Verzenden”-knop die wordt afgekort tot “Einre…”. Uw Arabische afrekenpagina wordt in spiegelbeeld weergegeven, waarbij de prijs aan de verkeerde kant staat uitgelijnd. Uw Japanse registratieformulier wijst elke naam af die langer is dan tien tekens. En elke afzonderlijke string in uw vertaalgeheugen is correct.

Vertaling is slechts één onderdeel van het internationaal uitrollen van een product. De rest is verificatiewerk dat de fouten opspoort die door vertaling alleen onopgemerkt blijven. De wereldwijde markt voor softwarelokalisatie stevent af op een waarde van 15,6 miljard dollar in 2032 met een jaarlijks groeipercentage van 10,6%. Dit betekent dat meer teams meer strings sneller in meer talen vertalen, waardoor de QA-kloof groter wordt. Deze checklist voor lokalisatietesten doorloopt de acht verificatielagen die opsporen wat bij vertaling stukgaat en waar elke laag doorgaans faalt. Teams die hun lokalisatie opschalen naar meer dan een handvol markten, kunnen leunen op gespecialiseerde lokalisatietestdiensten om alle acht lagen te dekken zonder de releasecycli te vertragen.

Vertaaltesten versus lokalisatietesten: waar ligt de grens?

Vertaaltesten beantwoorden één vraag: zijn de bronteksten taalkundig correct in de doeltaal? Dat is werk voor vertalers, woordenlijsten en taalkundige revisoren.

Lokalisatietesten beantwoorden er nog zeven. Volgen datumnotaties de lokale conventies? Worden invoervelden voor valuta, telefoonnummers en adressen gevalideerd volgens lokale regels? Behoudt de UI zijn vorm wanneer vertaalde strings langer zijn dan de brontekst? Komen betaalmethoden, belastinglogica en juridische disclaimers overeen met het betreffende rechtsgebied? Wordt de lay-out correct gespiegeld voor rechts-naar-links talen zoals Arabisch en Hebreeuws? De vertaler levert correcte strings op. Het QA-team verifieert of het product rondom die strings nog steeds werkt in de doeltaalregio.

Het als één taak beschouwen van beide is waar de meeste marktintroducties onnodig budget verliezen. Vertaling is de invoer. Verificatie is wat bewijst dat het product daadwerkelijk verzendklaar is.

De checklist voor lokalisatietesten in 8 lagen

Elke onderstaande laag dekt wat er stukgaat nadat de vertaling is voltooid, inclusief het verificatiewerk dat dit opspoort. De checklist is van toepassing op softwarelokalisatietesten voor web-, mobiele en SaaS-producten, met per laag aandacht voor regio-specifieke variaties.

Laag 1: taalkundige verificatie in context

Strings die in een spreadsheet worden beoordeeld, zien er prima uit. Strings die in de live UI worden bekeken, vertellen een ander verhaal. Een losse “Save” vertaalt naar Guardar in het Spaans, maar in een context die “geld besparen” betekent, wordt hetzelfde woord Ahorrar. Een spreadsheet-beoordelaar kan dat niet zien. Een native tester die door het eigenlijke scherm klikt, wel.

Deze laag omvat vier controles: consistentie van terminologie in schermen, e-mails en pushmeldingen; placeholders en HTML-tags die intact blijven na vertaling ({username}, <b>, %s); aansluiting bij lokale normen (formeel ‘vous’ versus informeel ‘tu’ in het Frans, de です/ます-vorm in het Japans); en homoniemen die worden beoordeeld op basis van de omgeving waarin ze verschijnen. Dit werk is grotendeels menselijk, en daarom verloopt het doorgaans via een handmatige testworkflow in plaats van een automatiseringssuite.

Laag 2: UI en lay-out onder druk

Talen dijen uit en krimpen in. Duitse strings zijn gemiddeld 30% langer dan Engelse. Fins kan wel 40% of meer groeien. Chinees en Japans comprimeren aanzienlijk; dat klinkt handig totdat gecentreerde lay-outs er skeletachtig uitzien en touch-targets kleiner worden dan een duim.

Pseudo-lokalisatie is hier het vangnet. Door bronstrings vóór enige echte vertaling te vervangen door kunstmatig verlengde teksten met accenten (bijv. [!!! Áccöùnt §ëttîngş !!!]), kunt u weken voor de go-live hardcoded strings, containers met vaste breedtes en hiaten in lettertypes opsporen. Dezelfde techniek brengt ontbrekende lettertekens (tofu-blokjes) voor Devanagari, Thais of Koreaans aan het licht die uw font-stack niet daadwerkelijk ondersteunt.

Ondersteuning voor rechts-naar-links verdient een aparte controle. Arabisch, Hebreeuws, Perzisch en Urdu vereisen gespiegelde lay-outs, omgedraaide voortgangsbalken, omgekeerde iconen en formulierlabels die aan de tegenovergestelde kant zijn uitgelijnd. RTL is ook een snijvlak van toegankelijkheid en lokalisatie, dus het loont om front-end testen en regiocontroles uit te voeren op dezelfde builds.

Laag 3: regio-afhankelijke gegevensformaten

Formatconventies zijn deterministisch en eenvoudig te testen; daarom is dit ook de laag die het vaakst wordt overgeslagen. Een kort overzicht van wat per regio moet worden geverifieerd:

De valkuil is gedeeltelijke implementatie. Teams lokaliseren het weergaveformaat, maar laten de invoervalidatie gekoppeld aan de bron-locale, waardoor een Duitse gebruiker 1.234,56 correct ziet staan, maar vervolgens een foutmelding krijgt als “geen geldig getal” wanneer ze het opnieuw invoeren.

Laag 4: meervoudsvorming, geslacht en ICU-regels

Het Engels heeft twee meervoudsvormen: één item en meer dan één. Het Pools heeft er vier. Het Arabisch heeft er zes. De meeste lokalisatiefouten in deze laag zijn terug te voeren op teams die de Engelse aanname hard-coderen in hun codebase: "You have " + count + " messages".

De oplossing is ICU MessageFormat met volledige dekking voor meervoudssleutels (_one, _few, _many, _other) en testgevallen per vorm per locale. Geslacht voegt nog een dimensie toe. Een zin als “Mark sent his file” gaat ervan uit dat bezittelijke voornaamwoorden het onderwerp volgen; dit werkt in het Engels, maar valt uit elkaar in talen waar het bezittelijk voornaamwoord afhangt van het zelfstandig naamwoord dat bezeten wordt.

Verificatiewerk is hier beperkt maar essentieel: één testgeval per meervoudsvorm per ondersteunde locale, plus contracttests op elke variabele-substitutie. Sla deze laag over en u lanceert de bug 1 messages waar uw gebruikers screenshots van zullen maken om ze online te delen.

Laag 5: culturele en visuele geschiktheid

Iconen, kleuren, beelden en voorbeeldgegevens dragen betekenissen met zich mee die niet zomaar de grens oversteken. Een duim-omhoog-icoon is positief in de meeste westerse markten, maar aanstootgevend in delen van het Midden-Oosten en West-Afrika. Rood staat voor geluk in China, gevaar in de VS en rouw in delen van Zuid-Afrika. Een uil staat voor wijsheid in de ene cultuur en voor ongeluk in de andere.

Dit is ook waar formulierontwerp stilletjes gebruikers uitsluit. Invoervelden voor namen met één regel werken niet voor Spaanstalige gebruikers met twee achternamen. Tekenlimieten ingesteld voor Latijnse schriften snijden Arabische en CJK-namen af. Voorbeeldgegevens die vooraf zijn ingevuld met “John Smith” en “4 juli 1990” zien er in elke locale buiten het Amerikaans-Engels slordig uit.

Culturele verificatie is zelden onderdeel van een geautomatiseerde suite. Er zijn lokale testers nodig die elk oppervlak reviewen aan de hand van een geschreven culturele checklist die is gekoppeld aan elke doelmarkt.

Laag 6: functioneel gedrag per locale

Hier ontdekken de meeste lanceringen dat hun go-to-market-plan een UI-oefening was in plaats van een productstrategie. Het functionele oppervlak van uw product verandert per locale en elke verandering vereist verificatie.

Lokale betaalmethoden: iDEAL in Nederland, Boleto in Brazilië, Konbini in Japan, UPI in India, SEPA binnen de EU. Stripe plus PayPal dekt slechts een fractie van de wereldwijde werkelijkheid bij het afrekenen. Belasting- en btw-logica: tarieven, inclusieve vs. exclusieve prijzen, lokaal conforme facturen. Juridische teksten en toestemming: AVG (GDPR) in de EU, LGPD in Brazilië, PIPL in China, CCPA in Californië, leeftijdsgrenzen en cookiebanners die voldoen aan lokale regels. Regiospecifieke feature-flags voor mogelijkheden die in bepaalde jurisdicties geblokkeerd zijn. Zoeken en automatisch aanvullen: tokenisatie voor CJK-talen die geen spaties kennen, afhandeling van diakritische tekens voor Spaans, Frans en Vietnamees.

Elk van deze punten is functioneel QA-werk dat boven op de gelokaliseerde gegevens plaatsvindt. Voor SaaS-teams die gelijktijdig in meerdere markten lanceren, voorkomt het toetsen hiervan aan een bredere SaaS-testchecklist dat deze problemen ondergesneeuwd raken in de grotere QA-scope.

Laag 7: prestaties, infrastructuur en analytics per regio

Een strakke Duitse UI op een trage server verliest alsnog de gebruiker. Lokalisatietesten voor websites die geen rekening houden met latentie vanuit de doelregio, CDN-routing en edge-cachegedrag, missen een hele klasse aan problemen, zelfs als er geen tekst bij betrokken is.

Drie controles horen hier thuis. CDN- en routinglatentie getest vanaf werkelijke IP-adressen uit de doelregio, niet vanaf uw kantoor. SMS- en e-mailbezorgbaarheid per land, aangezien sommige providers transactionele stromen van ongeregistreerde afzenders blokkeren. Notificaties die rekening houden met tijdzones, zodat een “goedemorgen”-push niet om 3 uur ‘s nachts lokale tijd wordt verstuurd.

De vierde controle is analytics. Tag elke gebeurtenis met de locale, niet alleen met de taal, zodat slecht presterende markten zichtbaar worden in uw dashboards. en-US en en-GB moeten te onderscheiden zijn, anders zal de retentiedaling in één van beide maandenlang verborgen blijven achter geaggregeerde cijfers.

Laag 8: regressie en continue lokalisatie-QA

Elke release bevat nieuwe teksten, nieuwe schermen en nieuwe randgevallen per locale. Teams die dit goed aanpakken, behandelen lokalisatie op dezelfde manier als beveiliging: een vast onderdeel in elke sprint, met een eigenaar en getagd in elk bugrapport.

De uitvoering is concreet. Screenshot-vergelijkingen per locale bij elke release vangen layout-regressies op voordat ze de productie bereiken. Locale smoke-tests in CI dekken de kritieke flows (inloggen, afrekenen, instellingen, foutmeldingen) in elke ondersteunde taal. Hygiëne van vertaalgeheugens markeert verouderde tekstfragmenten en biedt fuzzy matches aan voor review. Native-speaker spotchecks worden bij elke release uitgevoerd op risicovolle oppervlakken (registratie, betaling, foutmeldingen). Elk defect wordt getagd met locale:<code> zodat trends per markt zichtbaar worden in uw bugtracker.

Deze laag begeeft het als eerste wanneer teams schalen. Een product met twee locales kan handmatig worden getest op regressie. Een product met twaalf locales kan dat niet. Dat is waar een partner die regressietesten op schaal uitvoert, zijn waarde bewijst.

Uw lokalisatie-QA-snapshot vóór de lancering

Voordat u naar een nieuwe markt gaat, vertellen vijf gereedheidssignalen u of de locale echt klaar is. Als één ervan op rood staat, is de lancering niet klaar, ongeacht hoe goed de vertalingen zijn.

• Tekstfragmenten worden correct weergegeven in de context van registratie-, afreken-, instellingen- en foutmelding-flows.
• De UI behoudt zijn vorm bij tekstuitbreiding, RTL-omkering en font-fallback op echte doelapparaten.
• Locale-gegevensformaten (datum, getal, valuta, adres, telefoon) komen overeen met lokale conventies, zowel in weergave als invoer.
• Lokale betaalmethoden, belastinglogica en juridische disclaimers zijn live en end-to-end geverifieerd.
• De regressiesuite, getagd per locale, is groen in de CI.

Het doel van dit snapshot is om de gereedheidsbeslissing binair te maken. Of alle vijf zijn groen en u lanceert, of één is rood en u lost dit eerst op. Het rapport van McKinsey concludeerde dat 47% van de consumenten wereldwijd lokale merken nu belangrijk vindt bij hun aankoopbeslissing; hetzelfde instinct geldt voor digitale producten. Een gebruiker die aanvoelt dat uw product niet voor hem of haar is gemaakt, zal overstappen naar een lokale concurrent die er wel zo uitziet.

Elke release opent de checklist opnieuw

Lokalisatie is een terugkerend onderdeel van het werk dat telkens opnieuw opspeelt wanneer u een nieuwe functie uitrolt, een tekst aanpast of een nieuwe markt betreedt. De voorspellingen voor 2026 van Forrester waarschuwden dat een derde van de bedrijven het klantvertrouwen zal schaden door voortijdig genAI-ervaringen in te zetten in contexten waar deze waarschijnlijk niet zullen slagen; hetzelfde mechanisme speelt bij lokalisatie. Als u een locale uitrolt voordat deze is geverifieerd, betaalt de gebruiker de prijs voor uw gemiste testgevallen.

De 8 bovenstaande lagen vormen de scope. De lastigere vraag is wie deze beheert, bij elke release, in elke markt, zonder de roadmap te vertragen. Voor de meeste teams die verder zijn dan twee of drie locales, wijst de rekensom in de richting van een partner met native testers en een reeds geïntegreerde CI-regressietest. Als dat het gesprek is dat u overweegt, neem dan contact met ons op om te zien hoe dit voor uw product zou kunnen werken.