10 veelvoorkomende i18n-fouten en hoe je ze vermijdt
Leer de meest voorkomende i18n-fouten die ontwikkelaars maken, en hoe je ze oplost. Verbeter de kwaliteit van de lokalisatie van jouw app met deze best practices.
Internationalisatie (i18n) lijkt eenvoudig — totdat je ontdekt dat je Duitse gebruikers knoppen zien die afgesneden zijn, je Japanse gebruikers verminkte zinsdelen krijgen en je Arabisch sprekende gebruikers volledig kapotte lay-outs voor zich hebben. Dit zijn geen randgevallen. Het zijn de voorspelbare gevolgen van veelgemaakte fouten die de meeste ontwikkelingsteams tegenkomen wanneer ze voor het eerst lokaliseren aanpakken. In deze gids nemen we de 10 meest voorkomende i18n-fouten door, leggen we precies uit waarom ze gebeuren en laten we stap voor stap zien hoe je elk afzonderlijk probleem oplost. Of je nu een nieuwe app bouwt of een bestaande upgradeert — het vermijden van deze valkuilen bespaart je weken debugging en levert een gepolijste ervaring op voor wereldwijde gebruikers.
Fout #1: hardgecodeerde strings
Het hardcoderen van strings is de meest fundamente i18n-fout. Het gebeurt omdat ontwikkelaars zich eerst richten op het laten werken van functies en plannen voor 'opruimen later'. Maar later komt nooit, en plotseling heb je duizenden strings verspreid over honderden bestanden.
['Stel je i18n-framework in voordat je de eerste UI-regel schrijft', 'Gebruik een Linter-plug-in om hardgecodeerde strings in sjablonen en componenten te herkennen', 'Houd vertaal-sleutels beschreven en georganiseerd per feature of pagina']
Stel je i18n-framework in voordat je de eerste regel UI-code schrijft.
Gebruik een linter-plugin om hardgecodeerde strings in sjablonen en componenten te herkennen.
Houd vertaal-sleutels beschrijvend en georganiseerd naar functionaliteit of pagina.
Een typisch scenario
Een ontwikkelaar schrijft een knoplabel rechtstreeks in JSX: <button>Submit Order</button>.
De app wordt geleverd in het Engels en werkt naar behoren. Zes maanden later breidt het bedrijf uit naar Duitsland.
Het lokalisatieteam ontdekt 2.000+ hardgecodeerde strings. De upgrade duurt 3 weken en veroorzaakt 47 bugs.
Waarom is dit een probleem
In een volwassen codebase kunnen hardgecodeerde strings in de duizenden lopen. Het achteraf extraheren vereist dat je elk bestand aanraakt, elke component opnieuw test en overal regressies riskeert.
Hardgecodeerde strings zijn direct in de broncode, sjablonen of componenten ingebed. Ze kunnen niet worden geëxtraheerd, vertaald of tijdens runtime vervangen zonder de code zelf aan te passen.
Gebruikers in niet-Engelse locales zien onvertaalde UI-elementen gemengd met vertaald inhoud — een chaotische en onprofessionele indruk.
Zo los je het op
Zet alle voor de gebruiker zichtbare strings vanaf het begin in bronnenbestanden.
Stel een vertaalframework in (bijv. next-intl, react-i18next, vue-i18n) voordat je je eerste component schrijft.
Maak een resource-bestandsstructuur (bijv. messages/de.json) en verwijs alle strings via vertaal-sleutels zoals t('checkout.submitButton').
Voeg een lint-regel of pre-commit-hook toe die ruwe string-literal in UI-componenten markeert.
Fout #10: Alles letterlijk vertalen.
Niet alle inhoud moet vertaald worden. Merknamen, namen van juridische entiteiten, technische termen en bepaalde productnamen moeten in hun oorspronkelijke taal blijven. Overmatige vertaling kan juridische problemen, merk-inconsistentie en verwarring bij gebruikers veroorzaken.
["Onderhoud een 'Niet vertalen'-glossarium en deel deze met alle vertalers", "Gebruik afgesloten segmenten of aparte namespaces voor merknamen en juridische termen", "Geef altijd contextnotities voor dubbelzinnige strings om verkeerde vertalingen te voorkomen"]
Onderhoud een 'Niet vertalen'-glossarium en deel dit met alle vertalers.
Gebruik afgesloten segmenten of aparte namespaces voor merknamen en juridische termen.
Voorzie altijd contextnotities voor ambigu strings om verkeerde vertalingen te voorkomen.
Een typisch scenario
Een vertaaldocument bevat de bedrijfsnaam 'CloudForge Inc.' en de technische term 'OAuth 2.0 Token' als reguliere vertaalbare strings.
De Spaanse vertaler vertaalt 'CloudForge' naar 'ForjaNube' en 'OAuth 2.0 Token' naar 'OAuth 2.0-token'.
Resultaat: Gebruikers kunnen het bedrijf niet vinden onder zijn echte naam, en ontwikkelaars die de Spaanse documentatie lezen, raken in de war door onbekende vaktermen.
Waarom is dit een probleem
Een enkele fout vertaald merknamen in een juridisch document kan contracten ongeldig maken. Het corrigeren van over-vertaling vereist de controle van elke string in elke taal — weken werk.
Wanneer alle strings zonder context naar vertaling worden verzonden, kunnen vertalers mogelijk merknamen ('Apple' → 'Apfel'), juridische termen ('GmbH' → 'LLC') of technische termen die in het Engels moeten blijven vertalen.
Gebruikers vinden producten niet onder hun bekende merknaam, juridische documenten verwijzen naar het verkeerde bedrijf, en technische documentatie wordt onduidelijk als termen zoals 'API Endpoint' vertaald worden.
Zo los je het op
Marker duidelijke onvertaalbare inhoud en geef contextnotities aan vertalers.
Maak een 'Niet vertalen'-glossarium dat alle merknamen, productnamen, juridische entiteiten en vaktermen bevat die onveranderd moeten blijven.
Gebruik een aparte namespace of speciale sleutels voor niet-vertaalbare inhoud. Veel i18n-tools ondersteunen 'vergrendelde' segmenten die vertalers niet kunnen bewerken.
Voeg vertalercommentaar/beschrijvingen toe aan je vertaalbestanden die de context verklaren: 'Dit is een merknamen — niet vertalen' of 'Vakterm — Engels laten'.
Fout #2: Strings samenvoegen
Zinnen samenvoegen uit fragmenten lijkt logisch in het Engels, maar werkt niet in andere talen. Woordvolgorde, grammatica en zinsstructuur variëren sterk tussen talen, waardoor samengestelde strings niet vertaald kunnen worden.
['Maak nooit zinnen door vertaalde fragmenten samen te voegen', 'Gebruik benoemde placeholders ('{name}') in plaats van positionele ({0}) voor duidelijkheid', 'Voorzie contextuele opmerkingen voor vertalers die uitleggen wat elke placeholder bevat']
Bouw nooit zinnen door vertaalde fragmenten aan elkaar te plakken.
Gebruik benoemde placeholders ('{name}') in plaats van positionele ({0}) voor duidelijkheid
Voorzie contextuele notities voor vertalers die uitleggen wat elke placeholder bevat.
Een typisch scenario
Ontwikkelaar schrijft: 'You have ' + count + ' items in your ' + cartType + ' cart' — werkt perfect in het Engels.
De Duitse vertaler krijgt drie aparte fragmenten en kan geen grammaticaal correcte zin vormen, omdat de woordvolgorde moet veranderen.
Resultaat: Duitse gebruikers zien 'Sie haben 5 Artikel in Ihrem Warenkorb Standard' — klinkt haperig en onprofessioneel.
Waarom is dit een probleem
Elke gekoppelde string is een tikkende tijdbom. Bij 20 talen en 50 gekoppelde strings heb je 1.000 potentiële grammaticale fouten die handmatig moeten worden opgelost.
Strings samenvoegen zoals 'Willkommen ' + userName + ', je hebt ' + count + ' neue Nachrichten' vereist een specifieke woordvolgorde. Vertalers krijgen contextloze fragmenten die ze niet kunnen herordenen.
Gebruikers zien grammaticaal onjuiste zinnen. In het Duits staat het werkwoord vaak aan het eind. In het Arabisch is de hele structuur omgekeerd. Het resultaat leest als onzin.
Zo los je het op.
Gebruik geparameteriseerde berichten met benoemde placeholders, zodat vertalers de hele zin kunnen herschikken.
Vervang concatenatie door een enkele bericht-sleutel met placeholders: 'cart.summary': 'Je hebt {count} artikelen in je '{cartType}'-winkelwagen'.
Geef variabelen als parameters door aan je vertaalfunctie: t('cart.summary', { count: 5, cartType: 'Premium' }).
Vertalers kunnen nu vrij herschikken: 'In je '{cartType}'-winkelwagen bevinden zich {count} artikelen' — grammaticaal correct Duits.
Fout #3: Meervoud negeren
Engels heeft twee meervoudsvormen: enkelvoud en meervoud. Ontwikkelaars gaan er vaak vanuit dat alle talen op dezelfde manier werken. Dat klopt niet. Pools heeft 4 vormen, Arabisch heeft 6, en zelfs talen zoals Frans behandelen nul anders dan Engels.
['Gebruik altijd ICU MessageFormat of een equivalente bibliotheek voor telbare inhoud', 'Schrijf nooit je eigen meervoud-logica — vertrouw op de CLDR-regels', 'Test meervoud met waarden zoals 0, 1, 2, 5, 21 en 100 om alle categorieën te dekken']
Gebruik altijd ICU MessageFormat of een vergelijkbare bibliotheek voor telbare inhoud.
Schrijf nooit eigen meervoudige logica — vertrouw op de CLDR-regels.
Test meervoud met waarden zoals 0, 1, 2, 5, 21 en 100 om alle categorieën te dekken.
Een typisch scenario
Ontwikkelaar schrijft: count + (count === 1 ? 'Datei' : 'Dateien') — behandelt Duits correct.
De Poolse vertaler heeft 4 vormen nodig: 1 plik, 2–4 pliki, 5–21 plików, 22–24 pliki. De eenvoudige ternary kan dit niet uitdrukken.
Resultaat: Poolse gebruikers zien '5 pliki' (verkeerde vorm) in plaats van '5 plików' (juiste vorm), en de app lijkt kapot.
Waarom is dat een probleem
Elk telbaar zelfstandig naamwoord in je app vereist meervoudsbehandeling. Bij 50 dergelijke strings en 20 talen zijn dat 1.000 meervoudregels — onmogelijk handmatig te beheren.
Eenvoudige if/else-controles (count === 1 ? 'Datei' : 'Dateien') behandelen slechts Duits/Engels. De CLDR definieert tot 6 meervoudscategorieën: zero, one, two, few, many en other. Elke taal gebruikt een andere subset.
Gebruikers zien grammaticaal onjuiste teksten zoals '1 Nachrichten' of volledig verkeerde meervoudsvormen. In formele contexten schaadt dit de geloofwaardigheid.
Zo los je het op.
Gebruik ICU MessageFormat, dat alle CLDR-meervoudregels meteen ondersteunt.
Definieer berichten met ICU-syntaxis: 'fileCount': '{count, plural, one {# Datei} other {# Dateien}}'.
Vertaler leveren alle benodigde meervoudsvormen voor hun taal. Pools: '{count, plural, one {# plik} few {# pliki} many {# plików} other {# pliku}}'.
Je i18n-bibliotheek kiest tijdens runtime automatisch de juiste vorm op basis van de CLDR-regels van de actieve locale.
Fout #4: Vaste breedtes van UI-elementen
Ontwerpers maken pixelprecieze lay-outs in het Engels, en ontwikkelaars voeren ze uit met vaste breedtes. Maar vertaald tekst kan dramatisch langer of korter zijn. Duitse tekst is ongeveer 30% langer dan Engels, terwijl Chinese tekst 50% korter kan zijn.
['Gebruik nooit vaste pixelbreedtes bij elementen met vertaalbare tekst', 'Plan voor 40% tekstuitbreiding als baseline — sommige talen groeien nog meer', 'Gebruik CSS Flexbox of Grid voor lay-outs die zich aanpassen aan variabele inhoudslengtes']
Vermijd nooit vaste pixelbreedtes bij elementen met vertaalbare tekst.
Houd 40% tekstuitbreiding als baseline — sommige talen breiden zich nog meer uit.
Gebruik CSS Flexbox of Grid voor lay-outs die zich aanpassen aan variabele inhoudslengten.
Een typisch scenario
Ontwerper maakt een navigatiebalk met 5 knoppen, elk precies 100px breed — ziet er geweldig uit in het Engels.
Duitse vertaling: 'Settings' wordt 'Einstellungen' (13 vs 8 tekens), 'Submit' wordt 'Absenden' (8 vs 6). De navbar loopt over.
Resultaat: op mobiele apparaten stapelen de knoppen zich op elkaar of wordt de tekst afgekapt, waardoor de navigatie voor Duitse gebruikers onbruikbaar wordt.
Waarom is dit een probleem
Elk element met een vaste breedte is een potentieel breekpunt. Een typische app heeft honderden knoppen, labels en kaarten die allemaal tekstuitbreiding aankunnen.
Een container met een vaste breedte (width: 120px) en knoppen met vaste afmetingen knippen af of lopen buiten beeld wanneer de tekst zich uitrekt. CSS overflow: hidden verbergt inhoud stilletjes, terwijl overflow: visible de lay-out verstoort.
Gebruikers zien afgesneden labels zoals 'Einstellu...' in plaats van 'Instellingen', of knoppen die aangrenzende elementen overlappen. Kritische acties worden onleesbaar of niet klikbaar.
Zo los je het op
Ontwerp en implementeer flexibele lay-outs die zich aanpassen aan de tekstlengte van alle locales.
Vervang vaste breedtes door min-width, max-width en Flex-layouts. Gebruik CSS Grid of Flexbox om de ruimte dynamisch te verdelen.
Zet de tekstcontainer op afbreken: gebruik overflow-wrap: break-word en vermijd white-space: nowrap bij vertaalde inhoud.
Test je UI met pseudo-lokalisatie die alle strings met 40% verlengd om de worst-case te simuleren — nog voordat je strings naar vertalers stuurt.
Fout #5: Datum- en getalnotatie
Gegevens en cijfers lijken universeel te zijn. Maar 01/02/2025 betekent 2 januari in de VS en 1 februari in Europa. Komma's en punten veranderen betekenis in getallen: 1,000.50 (VS) vs 1.000,50 (Duitsland). Dit fout doen leidt tot verwarring, gegevensfouten en verlies van vertrouwen.
['Formatteer nooit data of getallen handmatig met string-templates — gebruik altijd Intl-API's', 'Sla alle gegevens intern op in ISO 8601-formaat (YYYY-MM-DD) en valuta in de kleinste eenheid (cent) intern', 'Test met locales die verschillende decimatie-scheidingstekens, datumvolgorde en kalendersystemen gebruiken']
Formatteer nooit data of getallen handmatig met string-templates — gebruik altijd Intl-API's.
Sla alle data intern op in ISO 8601 en valuta in de kleinste eenheid (cent).
Test Locales die verschillende decimale scheidingstekens, datumvolgorde en kalendersystemen gebruiken.
Een typisch scenario
Ontwikkelaar formatteert een datum als MM/DD/YYYY en een prijs als $1,234.50 — correct voor Amerikaanse gebruikers.
Een Duitse gebruiker ziet de datum 03/04/2025 en leest deze als 3 april (DD/MM/JJJJ-conventie). De prijs $1,234.50 lijkt te moeten zijn 1.234,50.
Resultaat: De gebruiker boekt een vlucht voor de verkeerde datum en vraagt zich af wat het prijsformaat is. Supporttickets in de Duitse markt stijgen met 15%.
Waarom is dit een probleem
Datum- en getalopmaak raakt elke weergave van gegevens in je app: tabellen, diagrammen, formulieren, facturen, rapporten. Een globale oplossing dekt honderden instanties.
Hardgecodeerde opmaakstrings zoals toLocaleDateString('en-US') of handmatige opmaak met template literals negeren de daadwerkelijke locale van de gebruiker. Zelfs de juiste locale maar het verkeerde kalendersysteem (Gregorianisch vs. Hijri) veroorzaakt problemen.
Gebruikers lezen gegevens verkeerd en voeren gegevens in in het verkeerde formaat. Een Europese gebruiker die 03/04/2025 ziet, interpreteert het mogelijk als 3 april in plaats van 4 maart — gemiste afspraken of verkeerde boekingen.
Zo los je het op
Gebruik de ingebouwde Intl-API of een locale-gevoelige formatteringsbibliotheek voor alle data, tijden, getallen en valuta.
Vervang handmatige opmaak door Intl.DateTimeFormat(locale) voor data en Intl.NumberFormat(locale, { style: 'currency', currency }) voor prijzen.
Sla gegevens intern op in ISO 8601-formaat (YYYY-MM-DD) en formatteer ze alleen voor weergave met de locale van de gebruiker.
Test met locales die verschillende decimatiescheidingstekens, datumvolgorde en kalendersystemen gebruiken.
Fout #6: RTL-talen vergeten
Richt-naar-links (RTL) talen zoals Arabisch, Hebreeuws en Perzisch worden door meer dan 500 miljoen mensen gebruikt. Toch worden de meeste apps uitsluitend ontworpen voor links-naar-rechts (LTR) lay-out. RTL-ondersteuning betekent niet alleen tekst omdraaien — het hele UI moet worden gespiegeld.
['Gebruik vanaf dag één uitsluitend logische CSS-eigenschappen (inline-start/end, block-start/end)', 'Test je app met dir='rtl' op het HTML-element bij elke sprintreview', 'Maak een RTL-test-checklist voor navigatie, pictogrammen, formulieren en voortgangsindicatoren']
Gebruik vanaf dag één uitsluitend logische CSS-eigenschappen (inline-start/end, block-start/end).
Test je app met dir='rtl' op het HTML-element bij elke sprint-review.
Maak een RTL-testchecklist voor navigatie, pictogrammen, formulieren en voortgangsindicatoren.
Een typisch scenario
Ontwikkelaars gebruiken margin-left: 16px en text-align: left door de hele app — standaard-LTR-praktijk.
De app begon in Saoedi-Arabië. Terug-knoppen wijst naar voren, zijbalken verschijnen aan de verkeerde kant, en numerieke gegevens zijn niet goed uitgelijnd.
Resultaat: Arabische gebruikers verlaten de app na 30 seconden. Het team heeft 4 weken nood-CSS-refactoring nodig om het probleem op te lossen.
Waarom is dit een probleem
RTL-ondersteuning raakt elke afzonderlijke component in je app. RTL achteraf invoeren vereist meestal het herschrijven van 30-50% van alle CSS-regels en het controleren van ieder pictogram en elke lay-out.
CSS-eigenschappen zoals margin-left, padding-right, text-align: left en float: left hard-coderen de richting. Icons met richtingaanduiding (pijlen, voortgangsindicatoren) wijzen in de verkeerde richting. Zelfs border-radius-waarden moeten gespiegeld worden.
Arabische gebruikers zien navigatie in de verkeerde hoek, voortgangsbalken lopen achteruit, en tekst die in botsing komt met UI-elementen. De app voelt vreemd aan en is onbruikbaar.
Zo los je het op
Gebruik logische CSS-eigenschappen en test vanaf het begin met een RTL-layout.
Vervang alle fysieke CSS-eigenschappen door logische tegenhangers: margin-left → margin-inline-start, padding-right → padding-inline-end, text-align: left → text-align: start.
Stel het dir-attribuut in op het HTML-root-element op basis van de actieve locale. Gebruik de CSS-pseudoklasse :dir(rtl) voor RTL-specifieke overrides.
Controleer alle pictogrammen op richting. Vervang richtinggebonden pictogrammen door gespiegelde versies of gebruik CSS transform: scaleX(-1) voor RTL-contexten.
Fout #7: Afbeeldingen met tekst
Tekst in afbeeldingen verwerken — of het nu in hero-banners, knoppen, infographics of screenshots is — is een localisationele nachtmerrie. Elk beeld met tekst moet voor elke taal opnieuw gemaakt worden, wat de ontwerpkosten en releases vertraagt.
['Biedt vertaalbare tekst nooit rechtstreeks aan in rasterafbeeldingen (PNG, JPG)', 'Gebruik CSS-tekstoverlay op achtergrondafbeeldingen voor hero-banners en CTA’s', 'Automatiseer de screenshot-generatie voor App Store-lijsten en marketingpagina’s']
Plaats vertaalbare tekst nooit rechtstreeks in rasterafbeeldingen (PNG, JPG).
Gebruik CSS-tekstoverlays op achtergrondafbeeldingen voor hero-banners en CTA's.
Automatiseer de screenshot-generatie voor App Store-listings en marketingpagina's.
Een typisch scenario
Een ontwerper maakt een promotiebanner met de tekst 'Start Your Free Trial' rechtstreeks in de afbeelding ingebed.
Het lokalisatieteam vertaalt alle UI-strings, maar het banner toont op de Duitse pagina nog steeds Engelse tekst.
Resultaat: De Duitse landingspagina heeft een irritante Engelse banner. Het lokaliseren van banners voor 15 talen duurt 3 dagen ontwerparbeid en vertraagt de lancering.
Waarom is dit een probleem
Een typisch marketinggedeelte heeft 5-10 afbeeldingen met tekst. Bij 15 talen zijn dat 75-150 afbeeldingsvarianten die gemaakt, onderhouden en bij elke ontwerpwijziging moeten worden bijgewerkt.
Tekst die in afbeeldingen is ingebed (PNG, JPG, SVG met ingebed tekst) kan niet door vertaaltools worden geëxtraheerd. Elke gelokaliseerde versie vereist dat een ontwerper het brondbestand handmatig aanpast, exporteert en uploadt.
Gebruikers zien afbeeldingen met tekst in een vreemde taal, of nog erger, een combinatie van vertaald UI en onvertaalde afbeeldingen. Dit komt inconsistent over en ondermijnt het merkvertrouwen.
Zo los je het op
Houd tekst gescheiden van de afbeeldingen via CSS-overlay, SVG's met vertaalbare tekstelementen of dynamische afbeeldingsgeneratie.
Gebruik CSS om vertaalbare tekst boven achtergrondafbeeldingen te plaatsen: positioneer de tekstlaag met absolute positioning boven de afbeeldingencontainer.
Voor infographics of diagrammen gebruik SVG's met <text>-elementen die verwijzen naar vertaalbare sleutels, in plaats van ruwe strings in te bedden.
Voor apps-schermbeelden in marketingmateriaal, automatiseer de screenshot-generatie met tools zoals Fastlane (Mobile) of Playwright (Web), die schermafbeeldingen in elke locale opnemen.
Fout #8: Ontbrekende vertalingen worden niet afgehandeld
Vertalingen zijn tijdens de ontwikkeling altijd onvolledig. Nieuwe functies voegen strings sneller toe dan vertalers ze kunnen vertalen. Zonder goede fallback-handling veroorzaken ontbrekende vertalingen crashes, lege UI-elementen of ruwe vertaal-sleutels die aan gebruikers worden getoond.
['Stel altijd minstens één fallback-taal in je i18n-setup in', 'Log ontbrekende vertaal-sleutels naar je monitoringsysteem voor traceerbaarheid', 'Stel een minimale vertaaldekkingsgraad in voordat een locale live kan gaan']
Configureer altijd minstens één fallback-taal in je i18n-setup.
Log ontbrekende vertaal-sleutels naar je monitoringsysteem ter opvolging.
Stel een minimale vertaaldekking voordat een locale live mag gaan.
Een typisch scenario
Ontwikkelaar voegt een nieuw 'Premium Features'-gedeelte toe met 15 nieuwe vertaal-sleutels. De Engelse versie wordt onmiddellijk uitgebracht.
De Franse vertalingen zijn nog niet af. De Franse pagina toont ruwe sleutels: 'premium.feature1.title', 'premium.feature1.description'.
Het resultaat: Franse gebruikers zien een kapotte pagina vol ontwikkelaarssleutel-namen. Het ondersteuningsteam ontvangt tientallen foutmeldingen.
Waarom is dit een probleem
Hoe groter je app wordt, hoe groter de kloof tussen Engelse strings en vertalingen in andere talen. Een app met 100 talen en 2.000 strings kan op elk moment 10.000+ ontbrekende vertalingen hebben.
Zonder fallback-logica geeft een ontbrekende vertaal-sleutel undefined, null of de ruwe sleutel-string terug (bijv. 'checkout.confirmButton'). Sjablonen kunnen fouten geven, de pagina kan crashen of niets renderen.
Gebruikers zien een kapotte UI: lege knoppen, ontbrekende labels of cryptische strings zoals 'nav.settings.title' in plaats van echte tekst. Dit is verwarrend en onprofessioneel.
Zo los je het op
Configureer een robuuste fallback-keten en houd de vertaaldekking bij in alle locales.
Stel in jouw i18n-configuratie een fallback-taalketen in: ontbrekende Franse keys vallen automatisch terug op Engels (en).
Voeg een Missing-Key-handler toe die onvertaalde sleutels logt naar je monitoringsysteem (bijv. Sentry, Datadog) zonder de gebruikerservaring te verstoren.
Maak een vertaaldekkings-dashboard aan die de afrondingsgraad per taal bijhoudt en releases blokkeert wanneer de dekking onder een drempelwaarde zakt (bijv. 95%).
Fout #9: tekenkoderingproblemen
Tekencodeerproblemen zijn de stille killer van lokalisatie. Alles lijkt goed te werken in Engels en Europese talen, maar zodra je Chinees, Japans, Koreaans, Arabisch of emoji toevoegt, verschijnen vervormde tekens. Deze bugs staan erom bekend moeilijk op te sporen.
['Gebruik overal UTF-8-codering — bronbestanden, database, API-antwoorden en HTML-meta-tags', 'Gebruik utf8mb4 in MySQL (niet utf8) om het volledige Unicode-bereik inclusief emoji te ondersteunen', 'Test met echte inhoud in CJK, Arabisch en emoji om coderingproblemen vroeg te detecteren']
Gebruik overal UTF-8-codering — brondocumenten, database, API-antwoorden en HTML-meta-tags.
Gebruik utf8mb4 in MySQL (niet utf8) om het volledige Unicode-bereik inclusief Emoji te ondersteunen.
Test met echte content in CJK, Arabisch en Emoji om coderingsproblemen vroeg te signaleren.
Een typisch scenario
Ontwikkelaars richten een MySQL-database in met latin1-collation (de oude standaard). De applicatiecode gebruikt UTF-8.
Japanse gebruikers registreren zich met hun echte naam. De database slaat '田中太郎' op als beschadigde bytes.
Resultaat: Het gebruikersprofiel toont verknoeide tekst. Nog erger: Zoeken en sorteren falen voor alle CJK-namen, wat duizenden gebruikers treft.
Waarom is dit een probleem
Tekencodeerproblemen verspreiden zich door de hele stack. Een foutief geconfigureerde database-collatie kan miljoenen records beschadigen — het herstellen vereist dure gegevensmigraties.
Inconsistente codering door de hele stack heen — UTF-8 in de bronbestanden, Latin-1 in de database en Windows-1252 in de API-respons — beschadigt multibyte-tekens. Een enkele fout geconfigureerde laag verandert '日本語' in '????' of '日本èª'.
Gebruikers zien verminkte teksten, vraagtekens of lege vakjes waar hun taal zouden moeten staan. In het ergste geval kunnen formulierinvoer permanent beschadigd raken in de database.
Zo los je dit op
Dwing UTF-8-codering consequent af in elke laag van je applicatiestack.
Stel alle brontebestanden in op UTF-8 (stel je editor en .editorconfig in). Voeg <meta charset='UTF-8'> toe aan je HTML en 'Content-Type: application/json; charset=utf-8' aan API-antwoorden.
Stel je database in op utf8mb4 (niet alleen utf8, wat in MySQL een 3-byte-subset is). Stel de connectie-collation in op utf8mb4_unicode_ci.
Kies lettertypen die jouw doelschriftsystemen dekken: Latijns, Cyrillisch, CJK, Arabisch, Devanagari. Gebruik system-font-stacks of Google Fonts met taalsubsets voor optimale laadtijden.
Test je i18n-implementatie.
Lengte-uitbreidingstest
Verleng alle vertaalde strings met 30-40% om de lengtevergroting te simuleren die optreedt in talen met lange woorden zoals Duits, Fins of Grieks. Dit dekt containers met vaste breedte, afgeknotte labels en knoppen die uitrekken voordat je begint te vertalen. Veel pseudo-lokalisatietools bieden dit als ingebouwde functie.
"Verzenden" → "Ṡééééñðéñ_éxpáñðéð" (40% langer)
Pseudo-lokalisatie.
Pseudolokalisatie vervangt elk teken door een accentueel equivalent (bijv. 'a' → 'á') en omhult strings met markeringen zoals [!! en !!]. Hierdoor is meteen zichtbaar welke strings hardcoded zijn en welke uit het vertalingssysteem komen. Voer pseudolokalisatie uit als onderdeel van je CI-pijplijn om regressies automatisch te vangen.
Elk tekst op het scherm die NIET tussen [!! !!]-markeringen staat, is hardgecodeerd en moet worden uitgesplitst. Deze test vangt ongeveer 95% van de overgeslagen strings op in minder dan een minuut.
"Bericht verzenden" → "[!! Ñáçḥŕíçḥṫ ṡéñðéñ !!]"
RTL-layouttest
Zelfs zonder Arabische of Hebreeuwse vertalingen kun je RTL-layout testen door dir='rtl' toe te voegen aan het HTML-root-element. Dit detecteert direct directionele CSS-fouten: verkeerd uitgelijnde pictogrammen, margins aan de verkeerde kant, kapotte navigatie en foutgesorteerde flex-items. Maak dit tot een standaardcontrole in elke sprintreview — het kost 10 seconden om te wisselen en vangt problemen die anders weken kosten om op productie op te lossen.
De i18n-checklist
['Alle door de gebruiker zichtbare strings in resource-bestanden verplaatst', 'Geen string-concatenatie gebruikt om zinnen te vormen', 'Meervoudregels geïmplementeerd met ICU MessageFormat of equivalent', 'Datum-, tijd- en getalnotatie gebruikt locale-gevoelige API\'s', 'RTL-layout met Arabische of Hebreeuwse inhoud getest', 'Flexibele UI zonder vaste breedte voor tekstintensieve elementen', 'Fallback-taal geconfigureerd en getest bij ontbrekende sleutels', 'UTF-8-encoding consistent over alle bestanden en databases', 'App Store- en Play Store-metadata voor elk market gelokaliseerd', 'Screenshots en marketing-assets voor elke taal bijgewerkt']