Waarom software internationaal faalt: zeven terugkerende fouten

Software faalt internationaal omdat ze is gebouwd voor één taal en één markt en vervolgens andere markten moet bedienen zonder dat de manier van bouwen verandert. De vertaling gaat er prima in. Daaronder gaat de code nog steeds uit van de woordvolgorde van de oorspronkelijke taal, één datumformaat, uitsluitend Latijnse tekst en één enkele valuta, waardoor het product breekt op een manier die geen enkele vertaler ooit kan repareren.

Op hoofdlijnen beschrijven we dit patroon in ontwikkeling van meertalige software: de meeste mislukkingen zijn terug te voeren op een retrofit, techniek die voor één markt is gebouwd en achteraf voor andere is aangepast. Even concreet. Dit zijn de zeven fouten die we het vaakst tegenkomen bij het auditen van een bestaande codebase, hoe elke fout er in productie uitziet, en wat ze echt voorkomt.

1. Hardcoded strings in de code

Hoe het eruitziet. Een knop toont "Submit" omdat iemand <button>Submit</button> rechtstreeks in een template heeft getypt. Een bevestigingsmail bevat "Your order #" + orderId + " has shipped" diep in een Node-functie. Nergens bestaat er een lijst van alle teksten in de applicatie. Om het Duits toe te voegen, moet iemand elk bestand openen, elke string opzoeken en hopen dat hij ze allemaal heeft gevonden.

Je vindt ze nooit allemaal. Audits leggen steevast resterend Engels bloot in error-toasts, beheerdersmails, PDF-voetteksten en pushmeldingen, de hoeken waar niemand aan dacht omdat ze niet op het hoofdscherm staan. Elk zo'n fragment gaat in productie als een kleine, gênante bug in een verder vertaald product.

Wat het voorkomt. Elke voor de gebruiker zichtbare string leeft in een resourcebestand onder een vaste sleutel (checkout.confirm_button, niet de tekst zelf), vanaf de eerste commit. Ontwikkelaars verwijzen naar de sleutel; vertalers werken in het resourcebestand. Pseudolokalisatie in CI (vervang elke string door verlengde, van accenten voorziene dummytekst en klik de build door) vangt alles wat nog hardcoded is vóór een release live gaat, niet nadat een klant het meldt.

2. Lay-outs op maat van Engelse teksten

Hoe het eruitziet. Een knop past "Save" met ruimte over. Het Duitse label is "Speichern", zes letters langer, en het valt op een tweede regel of wordt met een beletselteken afgekapt. Een instellingenpaneel ontworpen rond korte Engelse labels verandert in een muur van afgekapte tekst zodra alle labels vertaald zijn. Het Fins maakt hetzelfde probleem erger: samengestelde woorden lopen routineus voorbij de 20 tekens waar het Engels twee korte woorden gebruikt, zodat een label gebouwd voor "Shipping Address" kan botsen met "Toimitusosoite" in hetzelfde veld met vaste breedte.

De omvang van het probleem is geen afrondingsfout. Duitse interfacetekst is gemiddeld ongeveer 30 tot 35% langer dan Engelse, en korte strings van minder dan 10 tekens kunnen 200 tot 300% uitdijen (W3C). Een knop op de maat van het Engels heeft daar geen marge meer voor.

Wat het voorkomt. Lay-outs gebruiken flexibele containers in plaats van vaste breedtes, en knoppen, labels en navigatie worden getest tegen pseudo-gelokaliseerde of echt vertaalde tekst vóór de lancering, niet op het oog in het Engels beoordeeld in de aanname dat het wel past. We behandelen de bredere architectuur hierachter in i18n uitgelegd voor niet-technici.

3. Zinnen samengesteld uit fragmenten

Hoe het eruitziet. Een ontwikkelaar schrijft "Delete " + itemType + "?" om een vertaalstring uit te sparen, wat "Delete file?" oplevert in het Engels. Dezelfde code produceert grammaticale onzin in het Duits, waar de woordvolgorde en het geslacht van het zelfstandig naamwoord veranderen afhankelijk van de waarde van itemType, en ronduit onleesbare uitvoer in het Japans, waar de zinsstructuur zich helemaal niet op een Engels sjabloon laat plakken.

Deze fout is onzichtbaar in de brontaal en overduidelijk in alle andere. Ze overleeft langer dan de meeste bugs, omdat niemand ze ooit ziet bij het testen in het Engels.

Wat het voorkomt. Volledige zinnen, geen fragmenten, gaan in het resourcebestand, met plaatshouders voor het variabele deel: "Delete {itemType}?" als één vertaalbare eenheid. Vertalers zien en vertalen de hele zin, in de woordvolgorde die hun taal echt gebruikt. ICU-berichtformattering breidt dit uit naar meervouden en geslacht, waar de eenvoudige regels van het Engels een complexiteit maskeren die andere talen niet delen.

4. Aannames over datum- en getalnotatie

Hoe het eruitziet. Een verzendbevestiging toont "04/07/2026". In de VS is dat 7 april. In de meeste rest van de wereld, ook in het land waar de klant woont, is dat 4 juli. Niemand ziet een foutmelding. De klant komt gewoon een seizoen te vroeg opdagen, of een rapport wordt stilletjes op de verkeerde datum vastgelegd.

Getallen dragen dezelfde valstrik in de andere richting. "1.500" leest als anderhalf in de VS en als vijftienhonderd in Duitsland en Nederland, waar de punt een duizendtalscheiding is en geen decimaalteken. Een importroutine die buitenlandse getallen met Amerikaanse regels leest, crasht niet. Ze corrumpeert financiële gegevens en blijft gewoon draaien.

Wat het voorkomt. Datums en getallen worden weergegeven op basis van localegegevens (het Common Locale Data Repository, geen zelfgemaakte formattabel), en dezelfde localeregels gelden voor het inlezen van gebruikersinvoer, niet alleen voor de weergave. Een datumveld dat getypte invoer accepteert, moet "04/07/2026" weigeren of herformatteren op een manier die overeenkomt met hoe het is weergegeven, in beide richtingen.

5. Fouten met valuta en afronding

Hoe het eruitziet. Een checkout rekent prijzen om tegen de dagkoers en toont het resultaat met twee decimalen, voor elke valuta, overal. Dat gaat op twee specifieke manieren mis. Ten eerste driften prijzen mee met de wisselkoers in plaats van de vaste lokale prijs aan te houden die een markt verwacht: een product dat gisteren 49,99 EUR kostte, kost vandaag 51,23 EUR zonder zichtbare reden voor de klant. Ten tweede is de aanname van twee decimalen op zichzelf al fout: de Japanse yen heeft nul decimalen, terwijl de Bahreinse dinar, de Koeweitse dinar en de Omaanse rial er drie gebruiken. Een winkelwagen gebouwd voor twee decimalen verliest precisie die hij nodig heeft, of verzint precisie die niet bestaat.

Wat het voorkomt. Meervaluta-prijzen worden per markt vastgesteld met gecontroleerde afronding, niet live berekend uit een wisselkoersfeed op het moment van betalen. Valutaformattering en de omgang met subeenheden komen uit dezelfde localegegevens als datums en getallen, zodat JPY als heel getal verschijnt en KWD met drie decimalen, omdat de code de gegevens heeft geraadpleegd in plaats van iets aan te nemen.

6. RTL-schriften die als verhaspelde tekst verschijnen

Hoe het eruitziet. Arabische of Hebreeuwse tekst verschijnt in een interface die nooit voor rechts-naar-links lezen is gebouwd. In plaats van een gespiegelde lay-out blijft de interface links uitgelijnd terwijl het schrift zelf van rechts naar links loopt, zodat navigatie, iconen en voortgangsindicatoren de verkeerde kant op wijzen ten opzichte van de leesrichting. Erger nog: een zin die een Arabische uitdrukking mengt met een Latijnse productcode of een telefoonnummer kan met de segmenten in de verkeerde volgorde verschijnen, een visuele verhaspeling die de tekst echt moeilijk leesbaar maakt, niet alleen ongewoon.

Gebruikers merken dit binnen enkele seconden, en het komt over als kapotte software in plaats van een onafgemaakte vertaling. Het is een van de snelste manieren om geloofwaardigheid bij een hele markt te verliezen.

Wat het voorkomt. Lay-outs gebruiken logische CSS-eigenschappen (start en end, niet left en right) zodat het spiegelen automatisch gebeurt, en de omgang met bidirectionele tekst wordt getest met een echte RTL-locale, niet verondersteld te werken omdat er niets aan is geraakt. Het onderwerp is groot genoeg dat Globaprom het elders in zijn praktijk van meertalige software apart en uitgebreid behandelt.

7. Databasekolommen die geen niet-Latijnse schriften kunnen opslaan

Hoe het eruitziet. Een klant met de naam "José" wordt opgeslagen, en later getoond, als "José". Een Japanse bedrijfsnaam die in een database wordt bewaard, komt terug als een rij vraagtekens of blokjes. Dit gebeurt wanneer een databasekolom, een verouderde API of een bestandsexport een tekencodering gebruikt die alleen Latijnse tekens dekt: alles daarbuiten raakt corrupt op het moment van schrijven, niet van weergeven. De schade ontstaat in de opslaglaag, dus ze blijft onzichtbaar tot iemand de ruwe gegevens bekijkt, of tot een klant klaagt dat zijn eigen naam verkeerd is gespeld op zijn eigen factuur.

Wat het voorkomt. Unicode, de tekenstandaard die aan elk teken in elk schriftsysteem een code point toekent, moet de codering zijn van elke laag: databasekolom, API-payload, bestandsexport, e-mailsjabloon. UTF-8, de dominante Unicode-codering, moet van begin tot eind draaien, want één verouderd component op een andere codering volstaat om namen en adressen in het hele systeem te corrumperen.

Het patroon achter alle zeven

Elk van deze fouten lijkt op zichzelf klein: een afgekapte knop, een verkeerde datum, een verhaspelde naam. Geen enkele duikt op in tests die volledig in de oorspronkelijke taal van het product worden gedaan, want dat is precies de enige taal die geen ervan raakt. Juist daarom overleven ze tot in productie en worden ze ontdekt door betalende klanten in andere landen in plaats van door QA.

De commerciële inzet is reëel. De enquête van CSA Research onder 8.709 consumenten in 29 landen toonde aan dat 76% liever producten koopt met informatie in hun eigen taal, en dat 40% nooit iets koopt op websites in andere talen (CSA Research). Een product dat over zijn eigen vertaling struikelt, verliest dat vertrouwen even snel als een product dat nooit is vertaald.

Deze zeven fouten na de lancering herstellen kost veel meer dan ze vooraf vermijden. Teams melden twee tot vijf keer meer engineeringinspanning om internationalisatie in een draaiend product in te bouwen dan om het vanaf dag één mee te nemen (XTM, 2026), omdat elke laag (strings, lay-out, formattering, opslag) in één keer moet worden opgespoord en gecorrigeerd terwijl het product blijft leveren. We zien dezelfde zeven punten het hardst opduiken in maatwerk e-commerce ontwikkeling, waar checkout, prijzen en productgegevens elke fout op deze lijst tegelijk raken, en in maatwerk logistieke software, waar douanedocumenten, meertalige chauffeursapps en grensoverschrijdende datum- en valutanotaties geen ruimte laten voor giswerk.

Veelgestelde vragen over internationalisatiefouten

Wat is de meest voorkomende reden dat software internationaal faalt?

Ze is gebouwd met de aanname van één taal en één regio, en daarna vertaald in plaats van vanaf het begin ontworpen om er meerdere te bedienen. De vertaling dekt de zichtbare tekst; de hardcoded strings, de vaste lay-outs en de format-aannames daaronder blijven kapot.

Kunnen deze fouten worden hersteld zonder het product opnieuw te bouwen?

Ja, maar niet goedkoop. Elke fout moet worden opgespoord en gecorrigeerd in de laag waar ze leeft (code, lay-out of database) terwijl het product blijft draaien: daarom kost een retrofit twee tot vijf keer meer dan het vanaf het begin meenemen (XTM, 2026).

Treffen deze problemen alleen rechts-naar-links-talen zoals het Arabisch?

Nee. Tekstuitdijing, datumverwarring en valuta-afronding treffen elke niet-Engelse markt, ook de markten die van links naar rechts lezen. RTL-schriften leggen de fouten het snelst en het zichtbaarst bloot, maar ze zijn niet de enige talen waar deze zeven mislukkingen opduiken.

Hoe controleer ik of mijn software deze problemen heeft?

Draai een pseudolokalisatie-pass: vervang elke string door verlengde, van accenten voorziene dummytekst en loop het product door op zoek naar afgekapte knoppen, tekst die in de brontaal is blijven staan en kapotte lay-outs. Dat brengt de meeste van deze zeven fouten in één middag naar boven.

Betekent internationalisatie herstellen dat ik alles zelf moet vertalen?

Nee. Internationalisatie is engineeringwerk dat vertaling mogelijk maakt; het vraagt niet dat je zelf iets vertaalt. Zodra de code is gecorrigeerd, loopt de vertaling via een aparte pijplijn voor i18n (in het Engels), los van de budgetvraag lokalisatie vs vertaling.

Bouw software die niet over zijn eigen vertaling struikelt

Vertel ons welke markten je software moet bereiken. We auditen welke van deze zeven fouten je al hebt, en offreren tegen vaste prijs de correctie plus een vertaalpijplijn die voorkomt dat nieuwe talen ze herhalen.

Vraag een offerte met vaste prijs aan →