Ontwikkeling van meertalige software

Waarom de meeste software internationaal faalt (de valkuil van achteraf aanpassen)

De meeste software faalt buiten de eigen markt om één reden: ze is voor één taal ontworpen en achteraf vertaald. De woorden zijn alleen de zichtbare laag. Daaronder zitten hardgecodeerde teksten, lay-outs op maat van korte labels, datumlogica die uitgaat van één kalenderconventie, en een database die tekst opslaat zonder te weten welk schrift erin staat.

Dat kost je omzet. De studie "Can't Read, Won't Buy" van CSA Research, onder 8.709 consumenten in 29 landen, stelde vast dat 76% liever producten koopt met informatie in de eigen taal, en dat 40% nooit koopt op sites in een andere taal. Minder dan 20% van de wereldbevolking spreekt Engels, terwijl bijna de helft van alle websites in het Engels is geschreven (Statista, 2026). Een product in één taal vecht om een minderheid van zijn markt.

Achteraf aanpassen is de dure weg. Talen toevoegen aan een eentalige codebase betekent alle lagen tegelijk openbreken (interfaceteksten, validatie, e-mails, pdf's, databasevelden, zoekfunctie) terwijl het product gewoon doordraait. Teams melden twee tot vijf keer meer engineeringwerk voor zo'n aanpassing achteraf dan voor dezelfde ondersteuning die vanaf het begin is ingebouwd (XTM, 2026). De meesten ontdekken halverwege dat ze vertaling begrootten en herbouw kochten.

We zien dezelfde fouten zo vaak dat we ze in kaart hebben gebracht: waarom software internationaal faalt zet de zeven fouten op een rij die we het vaakst tegenkomen, en wat het kost om elk ervan recht te zetten.

i18n-architectuur: wat je vanaf dag één inbouwt

Een meertalige architectuur vanaf het begin komt neer op een korte lijst concrete beslissingen. Vooraf genomen kost elke beslissing weinig. Achteraf ingebouwd kost elke beslissing veel. Dit zit in elk project dat we opleveren:

1. Overal Unicode. Unicode kent een code point toe aan elk teken in elk schriftsysteem, en UTF-8 is de dominante codering ervan. Elke databasekolom, API, bestandsexport en e-mailtemplate die we bouwen, is UTF-8 van begin tot eind, want één verouderd onderdeel met een andere codering volstaat om namen en adressen te verminken. Die onzintekst heeft een naam, "mojibake", en we ontleden hem in Unicode in zakelijke applicaties.
2. Geëxternaliseerde teksten. Geen enkele tekst die de gebruiker ziet, staat in de code. Elk label, elke foutmelding en elke e-mail staat in resourcebestanden met vaste sleutels, klaar voor vertalers. Zinnen worden nooit uit losse stukjes aan elkaar geplakt, omdat de woordvolgorde per taal verschilt.
3. ICU-berichtformattering. ICU (International Components for Unicode) is de opensourcebibliotheek die meervouden, geslacht, lijsten en geformatteerde waarden per taal afhandelt. Het Engels heeft twee meervoudsvormen, het Arabisch zes, en in het Pools veranderen de regels met het getal zelf. Sjabloonteksten kunnen dat niet aan. ICU wel.
4. CLDR-localedata. De CLDR (Common Locale Data Repository, beheerd door het Unicode Consortium) levert de gegevens van elke locale, een combinatie van taal en regio zoals nl-BE: datumpatronen, scheidingstekens voor getallen, valutasymbolen, sorteervolgorden. We gebruiken die data in plaats van notatietabellen die iemand met de hand bijhoudt.
5. Een vertaalbaar datamodel. Interfaceteksten zijn maar de helft van het probleem. Productnamen, categorieën, documenttemplates en meldingen leven in de database, dus het schema slaat ze vanaf dag één per taal op, meestal achter een meertalig CMS of gelokaliseerde contentvelden.
6. hreflang en locale-routering. hreflang is de HTML-annotatie die zoekmachines vertelt welke taalversie van een pagina ze aan welke gebruiker tonen. We genereren die uit de locale-configuratie, nooit met de hand.
7. Pseudolokalisatie in CI. Pseudolokalisatie vervangt tekst door verlengde dummyteksten vol accenten, zoals "[!!! Àççôûñt Šéttîñgš !!!]", om hardgecodeerde tekst en brekende lay-outs zichtbaar te maken voordat er één woord vertaald is.

De rest van onze werkwijzen staat in best practices voor internationale apps. In jouw project staan de i18n-acceptatiecriteria die ze afdwingen in de vaste scope.

Taaltags zijn waar veel meertalige opzetten misgaan. Onze hreflang-gids behandelt de syntaxis en de regels, en onze audit van 78 grote websites toont de fouten die grote merken nog steeds maken.

RTL, CJK en de schriften die naïeve interfaces breken

Twee schriftfamilies leggen zwakke internationalisatie sneller bloot dan wat ook. Vang je de problemen in de tests, dan zien je gebruikers ze nooit.

Schriften van rechts naar links (RTL), Arabisch en Hebreeuws, draaien de leesrichting van de hele interface om. Echte RTL-ondersteuning betekent gespiegelde lay-outs (navigatie, iconen, voortgangsstappen), logische CSS-eigenschappen in plaats van links/rechts-waarden, en correcte bidirectionele tekst, waarbij een Arabische zin een Latijnse productcode of een telefoonnummer bevat dat de andere kant op leest. Een naïeve interface maakt van RTL-tekst een visuele warboel, en gebruikers merken dat binnen seconden.

CJK-schriften (Chinees, Japans, Koreaans) breken andere aannames. Er staan geen spaties tussen woorden, dus de regelafbreking moet het schrift kennen. De tekens zijn dichter, dus lettergroottes en regelhoogtes die op Latijnse tekst zijn afgestemd, worden onleesbaar. Zoeken, sorteren en invoermethoden werken ook anders.

Dan is er nog tekstexpansie. Duitse labels zijn ongeveer 30% langer dan de Engelse, en zelfs alledaagse woorden passen niet meer in knoppen met een vaste breedte. Lay-outs moeten getest worden met echte schriften, dus elke meertalige build die we opleveren gaat door pseudolokalisatie plus minstens één RTL- en één CJK-locale.

Vertaalpijplijnen: je applicatie verbinden met professionele vertaalworkflows

Vertaalpijplijnen zijn ons thuisterrein. Een vertaalpijplijn is de geautomatiseerde route die je content aflegt van de codebase naar vertalers en terug. Zo blijft meertalige software actueel, release na release, in plaats van één keer vertaald en daarna verouderd.

Een productiepijplijn kent vijf fasen:

1. Extractie. Nieuwe en gewijzigde teksten worden bij elke release automatisch opgespoord. Niemand mailt nog spreadsheets.
2. Overdracht naar het TMS. Een translation management system (TMS) verdeelt de content over vertalers en volgt de voortgang. Het past vertaalgeheugen toe (eerder goedgekeurde vertalingen, hergebruikt in plaats van twee keer betaald) en terminologielijsten, zodat je productvocabulaire consistent blijft over releases en talen heen.
3. Vertaling. Menselijke vertalers, machinevertaling, of post-editing van machinevertaling (MTPE: machinevertaling nagekeken en gecorrigeerd door een professional), naar keuze per contenttype. Juridische teksten en interfaceteksten verdienen menselijke zorg. Catalogusbeschrijvingen in bulk rechtvaardigen vaak MTPE.
4. Revisie in context. Vertalers zien teksten waar ze verschijnen. De meeste vertaalfouten zijn contextfouten.
5. Samenvoegen en uitrollen. Goedgekeurde vertalingen gaan door dezelfde reviewstappen als de code. Met continue lokalisatie draait de lus bij elke release, zodat geen enkele taal ooit op een "vertaalfase" wacht.

We hebben zulke workflows meer dan 20 jaar laten draaien over tientallen talenparen, als vertaalleverancier, met honderden professionele vertalers onder strakke deadlines. Toolkeuze en de volledige architectuur staan in onze gids over vertaalpijplijnen.