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 monolinguaal ontworpen en achteraf vertaald. De woorden van de oorspronkelijke taal zijn de zichtbare laag. Daaronder zitten hardgecodeerde teksten, lay-outs op maat van labels in één taal, datumlogica die uitgaat van één kalenderconventie, en een database die tekst opslaat zonder zich af te vragen welk schrift die bevat.

De commerciële kosten zijn meetbaar. 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. Ongeveer driekwart van de internetgebruikers heeft een moedertaal die niet het Engels is (Statista, 2024). Een product dat alleen in het Engels bestaat, vecht om een minderheid van zijn bereikbare markt.

Achteraf aanpassen is de dure weg. Talen toevoegen aan een monolinguale codebase betekent alle lagen tegelijk aanraken (interfaceteksten, validatie, e-mails, pdf's, databasevelden, zoekfunctie) terwijl het product blijft draaien. Teams melden twee tot vijf keer meer engineeringinspanning voor zo'n aanpassing achteraf dan voor dezelfde ondersteuning die vanaf het begin is ingebouwd (XTM, 2026). Teams die "vertaling" begroten en ontdekken dat ze "herbouw" hebben gekocht, ontdekken dat meestal halverwege het project.

De faalpatronen herhalen zich zo consistent dat we ze in kaart hebben gebracht: zie waarom software internationaal faalt voor de zeven fouten die we het vaakst tegenkomen, en wat elke fout kost om ongedaan te maken.

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

Een meertalige architectuur vanaf de conceptfase is een reeks concrete beslissingen, geen filosofie. Dit zijn de beslissingen die we bij de start van elk project nemen:

1. Overal Unicode. Unicode is de universele tekenstandaard die een code point toekent aan elk teken in elk schriftsysteem; UTF-8 is de dominante codering ervan. Elke databasekolom, API, bestandsexport en e-mailtemplate in onze builds is UTF-8 van begin tot eind. Eén verouderd component met een andere tekencodering volstaat om namen en adressen te corrumperen: de "mojibake"-onzintekst die we ontleden in Unicode in zakelijke applicaties.
2. Geëxternaliseerde teksten. Geen enkele voor de gebruiker zichtbare tekst leeft in de code. Elk label, elke foutmelding en elke e-mail staat in resourcebestanden met stabiele sleutels, klaar voor vertalers. Zinnen worden nooit uit fragmenten 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; de Poolse regels veranderen met het getal zelf. ICU handelt dit af; sjabloonteksten niet.
4. CLDR-localedata. De CLDR (Common Locale Data Repository, beheerd door het Unicode Consortium) levert de feiten van elke locale (een locale is een combinatie van taal en regio, zoals nl-BE). Datumpatronen, getalsscheidingstekens, valutasymbolen, sorteervolgorden: we gebruiken CLDR-data in plaats van handmatig onderhouden notatietabellen.
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 aan elke gebruiker te tonen. We genereren het programmatisch uit de locale-configuratie, nooit met de hand.
7. Pseudolokalisatie in CI. Pseudolokalisatie vervangt tekst door verlengde, van accenten voorziene dummyteksten ([!!! Àççôûñt Šéttîñgš !!!]) om hardgecodeerde tekst en brekende lay-outs bloot te leggen, nog voordat er één woord vertaald is.

Geen van deze punten is duur wanneer je het vanaf het begin kiest. Stuk voor stuk zijn ze duur om achteraf in te bouwen. Die asymmetrie is het hele argument voor meertalig vanaf de conceptfase. De rest van onze werkwijzen staat verzameld in applicaties bouwen voor een internationaal publiek (in het Engels).

Multivaluta, datums, getallen en notaties: de details die vertrouwen aantasten

Notatiefouten leiden zelden tot bugrapporten. Ze leiden tot stil wantrouwen: het gevoel dat een product voor ergens anders is gebouwd.

• Valuta. Multivalutaprijzen betekenen prijzen per markt met gecontroleerde afronding, geen wisselkoersberekening op het moment van weergeven. Het betekent ook de subeenheden respecteren: de Japanse yen heeft geen decimalen, en sommige valuta's gebruiken er drie. Opslag, afronding en weergaveregels komen aan bod in multivaluta-ondersteuning in software.
• Datums en tijden. 04-07-2026 is 4 juli in Amsterdam en Antwerpen, en 7 april in New York. We tonen datums per locale vanuit CLDR-patronen en slaan tijdstempels op in UTC met expliciete tijdzones, een gewoonte die ook de grensoverschrijdende rapportage zuiver houdt.
• Getallen. 1.500 is vijftienhonderd in Nederland en België, en anderhalf voor een Amerikaans systeem. Decimaal- en groeperingstekens moeten de locale volgen bij zowel weergave als invoer; een import die ze verkeerd leest, corrumpeert ongemerkt financiële data.
• Namen en adressen. Naamvolgorde, aanspreektitels, postcodenotaties en telefoonconventies verschillen per markt. Formulieren die een Amerikaanse structuur afdwingen, weigeren geldige klanten.

Elk detail is klein. Samen bepalen ze of een Belgische koper, een Saoedische dispatcher of een Japanse fabriekstechnicus de software als de hunne ervaart.

Hoe we standaard meertalig bouwen: het verleden als bewijs

Globaprom is voortgekomen uit BeTranslated, een internationaal vertaalbedrijf dat we hebben opgericht en nog steeds runnen (het verhaal achter Globaprom beschrijft het hele traject). Dat verleden is zichtbaar in het werk, op precieze en controleerbare manieren:

• We waren onze eigen eerste klant. Onze meertalige systemen voor facturatie, offertes en leveranciersportaal zijn gebouwd voor onze eigen vertaalactiviteiten: multivaluta, multi-locale, jarenlang in productie voordat we ook maar één build verkochten.
• Locales worden afgebakend, niet verondersteld. Elk project start met een localematrix: welke talen, schriften, valuta's en notaties, nu en waarschijnlijk later. De i18n-acceptatiecriteria gaan mee in de vaste scope.
• Snelheid door AI, kwaliteit door menselijke review. We bouwen met AI-ondersteunde ontwikkeling, en precies daarom wordt de i18n-checklist hierboven afgedwongen door revisie en door pseudolokalisatietests in CI: gegenereerde code valt standaard terug op Engelstalige aannames als de pijplijn dat niet verbiedt. Ons proces staat beschreven in hoe we scopen, bouwen en reviewen.
• Vertaling is niet jouw probleem om te organiseren. Via ons netwerk van professionele vertalers verbinden we je TMS, regelen we menselijke vertaling of MTPE, en leveren we een draaiende pijplijn op, geen map met teksten plus 'veel succes ermee'.

Geen enkel ander maatwerk-softwarebureau op deze markt kan deze reeks claims waarmaken. Daarom zetten we ze voorop.

Klantcase: meertalige oplevering in de praktijk

C21 Perdomo: meertalige website en trackingsysteem. Voor dit vastgoedkantoor bouwden we een nieuwe meertalige, AI-ondersteunde website met een geïntegreerd trackingsysteem, geïnternationaliseerd vanaf de eerste commit in plaats van achteraf aangepast. Deze build toont in productie de aanpak die hier beschreven staat: content afgestemd op de locale en een meertalige interface, opgeleverd als één samenhangend systeem.

Meer projectverslagen staan verzameld in onze klantcases.