Internationalisatie (i18n), uitgelegd

Internationalisatie (i18n) is het technische werk dat software zo ontwerpt dat ze veel talen, schriften en regionale formaten kan ondersteunen met zo weinig mogelijk codewijzigingen; de benodigde inspanning verschilt per product en taalcombinatie. De afkorting telt de 18 letters tussen de eerste i en de laatste n van het Engelse woord "internationalization".

Die definitie telt vooral voor de mensen die de code nooit aanraken: de kopers. Als de software die je laat bouwen ooit een tweede markt moet bedienen, bepaalt internationalisatie (ook wel software-internationalisatie) of het toevoegen van een taal een paar dagen kost of meerdere kwartalen. Wij bouwen het in elk project in als onderdeel van meertalige softwareontwikkeling. Wat volgt is de technische laag van die aanpak: wat i18n concreet in de code omvat, waarin het verschilt van lokalisatie, waarom het achteraf toevoegen duur uitpakt, en wat je een leverancier moet vragen voordat je iets tekent.

Wat dekt i18n concreet in de code?

"Ondersteunt meerdere talen" is een bewering. i18n is de precieze set technische beslissingen die haar waarmaken. Zes daarvan doen het meeste werk.

1. Geëxternaliseerde strings. Elke tekst die een gebruiker ziet (labels, knoppen, foutmeldingen, e-mails) leeft in resourcebestanden buiten de code, elke string onder een stabiele sleutel als checkout.confirm_button. Vertalers werken op die bestanden. Ontwikkelaars raken de applicatielogica nooit aan om een taal toe te voegen. Eén regel telt hier zwaarder dan welke toolkeuze dan ook: je stelt een zin nooit samen uit fragmenten, want de woordvolgorde verschilt per taal. "Verwijder" vóór "bestand" plakken levert grammaticale onzin op in het Duits, en erger in het Japans.

2. Unicode en UTF-8. Unicode kent elk teken in elk schriftsysteem een nummer toe; UTF-8 is de codering die die nummers opslaat. UTF-8 wordt gebruikt door 99,0% van de websites waarvan de karaktercodering bekend is; W3Techs actualiseert deze meting dagelijks. Geïnternationaliseerde software is UTF-8 van begin tot eind: invoerveld, API, databasekolom, PDF-export. Eén verouderd component op een andere codering verandert "José" in "José", de beschadiging die we ontleden in Unicode in zakelijke applicaties.

3. Het ICU-berichtformaat. ICU (International Components for Unicode) is de opensourcebibliotheek die grammatica afhandelt die per taal verandert. Meervouden zijn het klassieke geval: het Engels kent twee meervoudscategorieën, het Arabisch zes. CLDR onderscheidt daarvoor onder meer de categorieën zero, one, two, few, many en other, zodat software natuurlijke gelokaliseerde formuleringen kan kiezen in plaats van constructies als "1 hour(s)". Een bericht geschreven als {count, plural, one {# factuur} other {# facturen}} laat elke taal zijn eigen vormen bepalen, en hetzelfde mechanisme dekt geslachtsovereenkomst en geformatteerde waarden. Handgemaakte stringsjablonen kunnen dit niet, hoe zorgvuldig ze ook zijn geschreven.

4. Locale-afhankelijke opmaak. Een locale is een taal-regiocombinatie zoals nl-BE of fr-BE. Een land kan meerdere taal- en regiovarianten omvatten, zoals in België (Nederlands, Frans en Duits als officiële talen, met Brussel als tweetalig gebied), dus één land kan meerdere locales tellen. De locale bepaalt hoe datums, getallen en valuta worden weergegeven. 04-07-2026 is juli in Brussel en april in New York. 1.500 is vijftienhonderd voor een Nederlandse of Belgische lezer en anderhalf voor een Amerikaans systeem. Geïnternationaliseerde code formatteert deze waarden per locale op basis van standaard localegegevens in plaats van hardgecodeerde patronen, en leest gebruikersinvoer volgens dezelfde regels, wat voorkomt dat een geïmporteerde prijslijst stilletjes corrupt raakt.

5. Een RTL-klare lay-out. Het Arabisch en het Hebreeuws lezen van rechts naar links, wat de hele interface spiegelt, niet alleen de tekst. Lay-outs gebouwd met logische CSS-eigenschappen (start en einde in plaats van links en rechts, zoals het W3C aanbeveelt voor interfaces met verschillende schrijfrichtingen) klappen correct om; lay-outs gebouwd op pixelposities niet. De tekstlengte is de bijbehorende valkuil: vertaalde tekst kan, vooral bij korte strings, aanzienlijk langer worden. Het W3C documenteert dat korte vertaalde strings in sommige gevallen tot 200–300% kunnen uitzetten, maar het percentage verschilt per taalpaar en context; flexibele lay-outs en voldoende ruimte zijn daarom essentieel (W3C, Text size in translation). Knoppen hebben ruimte nodig om te groeien. Het volledige beeld staat in ons artikel over RTL-ondersteuning.

6. Locale-onderhandeling. De software moet bepalen welke taal elke gebruiker krijgt: vanuit de URL of de Accept-Language-header van de browser, met een accountinstelling die boven beide gaat, en een verstandige terugvalketen wanneer een vertaling ontbreekt. Doe je dit verkeerd, dan zien gebruikers twee talen door elkaar op één scherm, wat overkomt als een kapot product, ook al werkt al het andere.

Merk op dat geen van deze taken ook maar één woord vertaalt. Dat is precies de bedoeling. i18n maakt vertaling mogelijk en herhaalbaar; ze voert de vertaling nooit uit.

i18n vs l10n: de één bouwt de mogelijkheid, de ander gebruikt haar

De architectuur voor internationalisatie wordt meestal vroeg door ingenieurs ontworpen en bedient in principe elke toekomstige taal, al blijven onderhoud, testen en discipline nodig naarmate het product groeit. Lokalisatie (l10n, tien letters tussen de l en de n van het Engelse "localization") gebeurt markt per markt: de content vertalen en de formaten, beeldtaal, betaalmethoden en toon aanpassen aan één specifiek publiek. Softwarelokalisatie zonder voorafgaande i18n, daar lopen projecten vast.

Een metafoor met stopcontacten houdt goed stand. i18n plaatst de stopcontacten; l10n steekt in elk daarvan iets in. De bedrading betaal je één keer. Lokalisatie betaal je opnieuw voor elke markt die je betreedt, en vertaling is daarbinnen een terugkerende contentkost. De kosten en optimale volgorde hangen af van de stack, het product en de markten, maar meestal werkt het goed om eerst te internationaliseren en daarna markt per markt te lokaliseren. Teams die dit omdraaien, betalen vaak taal per taal voor problemen die eerder opgelost hadden kunnen zijn.

De distinctie heeft echte gevolgen voor het budget, en offertes die haar vertroebelen verstoppen her-engineering onder de post vertaling. Die kant lichten we toe in lokalisatie versus vertaling. Voor een snelle referentiedefinitie is er het i18n-woordenlijstitem.

Waarom i18n achteraf toevoegen duurder kan uitpakken (de valkuil van achteraf inbouwen)

i18n overslaan neemt de kosten niet weg. Het stelt ze uit, met rente.

Een eentalige codebase verbergt in elke laag de aanname dat iedereen in jouw taal leest: strings hardgecodeerd op duizend plekken, lay-outs afgestemd op korte Nederlandse labels, datums die in één format worden gelezen, een schema met een enkele product_name-kolom. Een tweede taal toevoegen betekent dit allemaal tegelijk vinden en corrigeren, in een live product, terwijl er functies blijven uitkomen. Het achteraf toevoegen van i18n kan aanzienlijk meer engineeringinspanning vragen dan ondersteuning die vanaf het begin is voorzien; de omvang verschilt sterk per codebase en moet met een projectanalyse worden vastgesteld. Het achteraf inbouwen draagt ook een risico dat de nieuwbouw nooit kent: elke gecorrigeerde string kan een scherm breken dat betalende klanten al gebruiken, dus elke nieuwe taal dwingt een volledige regressietest af.

We zien het patroon het vaakst bij maatwerk e-commerceontwikkeling. Een webshop lanceert alleen in Nederland, wint terrein in Vlaanderen en daarna in Duitsland, en het verzoek "we vertalen het gewoon even" komt terug als een her-engineeringofferte die niemand had begroot. De zichtbare strings waren het makkelijke deel. Het catalogusschema, de checkout en de transactionele e-mails waren dat niet.

Vanaf de eerste dag ingebouwd kost dezelfde mogelijkheid doorgaans veel minder dan achteraf. Resourcebestanden kosten weinig extra ten opzichte van inline strings. UTF-8 is de standaard in elke moderne stack. Locale-afhankelijke opmaak is meestal een bibliotheekaanroep. Die asymmetrie, relatief goedkoop nu tegenover potentieel duur later, vat het argument samen om het eerst te doen.

Wat je een leverancier moet vragen voordat je tekent

Je hoeft geen code te lezen om i18n te verifiëren. Zeven vragen leggen haar bloot, en elke vraag heeft een goed antwoord.

1. "Zijn alle voor gebruikers zichtbare strings geëxternaliseerd, e-mails en PDF's inbegrepen?" Ja, in resourcebestanden met stabiele sleutels. "Grotendeels" betekent nee.
2. "Is de stack UTF-8 van begin tot eind, database en exports inbegrepen?" Elk "dat zouden we moeten nakijken" is een waarschuwingssignaal.
3. "Hoe gaan jullie om met meervouden en geslacht?" Het antwoord moet het ICU-berichtformaat noemen of een equivalent, niet "we plakken er een s achter".
4. "Waar komen jullie opmaakgegevens vandaan?" Van standaard localegegevens (CLDR), nooit van met de hand onderhouden opmaaktabellen.
5. "Overleeft de lay-out RTL-schriften en aanzienlijke tekstuitbreiding?" Vraag om één scherm in het Arabisch of in pseudo-gelokaliseerde tekst te zien.
6. "Hoe komt vertaalde content erin en eruit?" Er moet een vast circuit naar vertalers zijn, geen spreadsheet als bijlage bij een e-mail.
7. "Wat gebeurt er als een vertaling ontbreekt?" Een gelogde terugvalketen. Nooit een lege knop.

Een leverancier die dit allemaal in gewone taal beantwoordt, heeft het werk al eerder gedaan. Een leverancier die internationalisatie "iets voor fase twee" noemt, offreert je het achteraf-traject.

Veelgestelde vragen over i18n

Waar staat i18n voor?

i18n is de afkorting van het Engelse "internationalization": het cijfer telt de 18 letters tussen de eerste i en de laatste n. Dezelfde afspraak levert l10n voor lokalisatie ("localization") en a11y voor toegankelijkheid ("accessibility"). Ingenieurs bedachten de afkorting omdat de volledige woorden lang zijn en makkelijk verkeerd te typen.

Heb ik i18n nodig als ik vandaag alleen in het Nederlands werk?

Als een tweede taal ooit denkbaar is, is i18n vaak de moeite waard om vroeg in te bouwen. i18n inbouwen voegt weinig toe aan een nieuwbouw; het achteraf toevoegen kan aanzienlijk meer engineeringinspanning vragen, al verschilt de omvang sterk per codebase. Je krijgt ook meteen een correcte verwerking van namen met accenten, buitenlandse adressen en tijdzones.

Is internationalisatie een eenmalige taak?

Grotendeels. De architectuur (geëxternaliseerde strings, UTF-8, locale-afhankelijke opmaak) wordt één keer gebouwd. Daarna vraagt ze discipline in plaats van budget: elke nieuwe functie houdt haar tekst in resourcebestanden, en pseudo-lokalisatietests in CI vangen overtredingen automatisch op.

Hoe weet ik of mijn bestaande software geïnternationaliseerd is?

Draai een pseudo-lokalisatieronde: vervang elke string door verlengde, geaccentueerde dummytekst en klik door het product. Een pseudo-lokalisatieronde met langere en geaccentueerde dummytekst is een praktische manier om afgebroken lay-outs en hardgecodeerde strings snel zichtbaar te maken; de W3C-waarschuwingen over tekstexpansie ondersteunen die teststrategie. Hardgecodeerde strings en brekende lay-outs verschijnen binnen enkele minuten. Wij voeren deze audit uit tijdens de scoping; vraag een offerte tegen vaste prijs aan en hij zit erbij.

Wie doet het i18n-werk: ontwikkelaars of vertalers?

Ontwikkelaars. i18n is pure engineering, en geen enkele vertaler raakt haar aan. Vertalers komen in beeld tijdens de lokalisatie, zodra de software hun werk kan opnemen. Als een voorstel wel vertaling vermeldt maar geen post voor engineering, vraag dan of de i18n al bestaat of gewoon in de raming ontbreekt.