Internationalisatie (i18n), uitgelegd

Internationalisatie (i18n) is het technische werk waarmee software in elke taal, elk schrift of elk regionaal format kan werken zonder dat de code verandert. 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, en draagt vandaag 99% van alle websites waarvan de codering bekend is (W3Techs, 2026). 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-meervoudsregels). 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. België alleen al is officieel drietalig (Nederlands, Frans en Duits), 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) klappen correct om; lay-outs gebouwd op pixelposities niet. De tekstlengte is de bijbehorende valkuil. Het Duits is gemiddeld ongeveer 30% langer dan het Engels, en het W3C becijfert de uitbreiding van korte strings tot wel 300% (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

Internationalisatie gebeurt één keer, door ingenieurs, en bedient elke toekomstige taal. 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 volgorde ligt ook vast: eerst internationaliseren, daarna markt per markt lokaliseren. Teams die dit omdraaien, betalen uiteindelijk taal per taal voor problemen die één keer opgelost hadden moeten zijn.

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

Waarom i18n later toevoegen een veelvoud kost (de valkuil van achteraf inbouwen)

i18n overslaan neemt de kost niet weg. Het stelt de kost 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 op maat gesneden van 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. Teams rapporteren 2 tot 5 keer meer engineeringinspanning voor een achteraf-traject dan voor dezelfde ondersteuning die vanaf het begin is ingebouwd (XTM, 2026). 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 is dezelfde mogelijkheid vrijwel gratis. Resourcebestanden kosten niets extra ten opzichte van inline strings. UTF-8 is de standaard in elke moderne stack. Locale-afhankelijke opmaak is een bibliotheekaanroep. Die asymmetrie, goedkoop nu tegenover peperduur later, vat het hele 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 30% 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, ja. i18n inbouwen voegt weinig toe aan een nieuwbouw; het achteraf toevoegen kost 2 tot 5 keer de engineeringinspanning (XTM, 2026). 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. 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 engineeringregel, vraag dan of de i18n al bestaat of gewoon in de raming ontbreekt.