Internationalisatieconsultatie: los op wat er misgaat, plan wat er komt
Je weet al dat i18n lastig is. Ik heb de symptomen gezien: RTL-lay-outs die instorten, Duitse tekst die over knoppen heen loopt, API-responses in de verkeerde taal, en vertalingen die binnen een paar weken na de lancering uit de pas lopen. Ik verkoop geen wondermiddelen. Ik help je de specifieke puinhoop van je team ontwarren — en systemen bouwen die niet twee keer op dezelfde manier kapotgaan.
„We hadden dit eerder moeten plannen"
De architectuurbelasting die je nu betaalt
Je lanceerde in het Engels. Het werkte. Toen voegde je Frans toe, „alleen voor de landingspagina." En nu zit je hier omdat:
Je codebase heeft lang=-controles verspreid over 47 bestanden
Productmanagers vragen 'Kunnen we tekst A/B-testen?' en engineering zegt 'niet zonder een volledige herschrijving'
Je hebt drie verschillende vertaalworkflows en geen ervan werkt betrouwbaar
Wat ik heb zien misgaan:
- Teams die meer dan zes maanden besteden aan het achteraf inbouwen van i18n in een Next.js-app, omdat strings hardcoded in componenten zaten
- Vertaalbestanden raken uit de pas omdat ontwikkelaars niet weten welk bestand ze moeten bijwerken
- 'Localization freeze'-periodes voor releases omdat niemand het vertaalproces vertrouwt
- Weerstand tegen het aanpassen van vertaalde content omdat de workflow zo moeizaam is
Waar ik mee help:
- Refactoringstrategieën waarmee je i18n geleidelijk kunt invoeren (ik eis niet dat je 'alles stopzet en herschrijft')
- Procesontwerp om vertalingen synchroon te houden zonder de ontwikkeling te blokkeren
- Architectuurreviews om te achterhalen waar je huidige aanpak vastloopt bij meer dan 10 talen
i18n is architectuur, geen functionaliteit. Het achteraf toevoegen is alsof je besluit dat je huis een kelder nodig heeft nadat je het al hebt gebouwd.
Ik help je die kelder te graven — of te beslissen of je er eigenlijk wel een nodig hebt.
RTL Breekt Alles
Je UI is niet ontworpen voor Arabisch, Hebreeuws of Urdu
Je schakelde dir=„rtl" in en zag je lay-out ontploffen:
Wat ik heb gezien:
- Ontwerpsystemen met meer dan 200 componenten waarvan er maar 12 RTL goed ondersteunen
- Teams die float: left gebruiken in plaats van logische eigenschappen, waardoor er bij elke nieuwe functie RTL-bugs ontstaan
- Popovers en modals die per component aangepaste RTL-overschrijvingen nodig hebben
- Frameworks die beweren RTL te ondersteunen, maar alleen de lay-outrichting omdraaien en de plaatsingslogica om zeep helpen
Waar ik mee help:
- Migratie naar CSS logical properties (margin-inline-start in plaats van margin-left)
- Ontwerpsysteemaudits om RTL-landmijnen op te sporen voordat ze uitrollen
- Frameworkspecifieke richtlijnen (Tailwind, shadcn, MUI) voor RTL-first styling
Handmatig RTL-bugs oplossen in elk component is niet vol te houden. Ik maak RTL-ondersteuning systematisch, in plaats van constant brandjes blussen.
„De Duitse tekst heeft onze knop verpest"
UI die niet gemaakt is voor vertaling
Engels past. Duits niet. Je ontwerp ging ervan uit:
Toen vertaalde je naar het Duits, Fins of Thais en ontdekte je:
Knoppen die halverwege een woord afgesneden worden
Tabellen met horizontale scrollbalk op elke rij
Tekst die omloopt tot onleesbare blokken
Niet-Latijnse tekst wordt afgekapt doordat containers een vaste breedte hebben
Waar ik mee help:
- Elastische UI-patronen die zich aanpassen aan de lengte van de inhoud
- Planning van karakterbudget (wetende dat Duits 30 % uitbreidt, Thai geen spaties gebruikt)
- Typografiesystemen die CJK, Arabisch en Devanagari aankunnen zonder problemen
Ik help je een UI bouwen die vertaling overleeft — voordat je hebt betaald voor 10,000 woorden die niet passen.
Je hebt geen college nodig over waarom i18n belangrijk is. Je hebt iemand nodig die RTL-popovers heeft gedebugd om 2 uur 's nachts, met de productafdeling heeft gesteggeld over tekenlimieten, en vertaalpipelines heeft ontworpen die daadwerkelijk werken.
De valkuilen waar niemand je voor waarschuwt
Verhalen uit de loopgraven van teams die het hebben meegemaakt
Dit is geen theorie. Dit zijn dingen die fout gingen in productie:
Meervoudshel
Engels: '1 item' vs '2 items'
Pools: '1 przedmiot' / '2 przedmioty' / '5 przedmiotów' (3 meervoudsvormen)
Arabisch: 6 meervoudsvormen
Je count === 1 ? 'item' : 'items'-logica werkt niet meer.
Datum- en tijdchaos
Je formateerde datums met toLocaleDateString(). Vervolgens zagen gebruikers in Japan „2025年2月9日" in je CSV-exports, en Excel kon daar niet goed mee overweg.
API-taalafwijking
Je frontend vraagt Frans aan. Je API stuurt Engels terug omdat het auth-token geen locale meedraagt. Het resultaat: een UI met gemengde talen, en gebruikers die denken dat het een bug is.
Pseudo-localetesten
Je hebt niet getest met [Ţĥîś îś ţéśţ ţéẋţ ţĥàţ éẋþàñðś 30 %] voordat je live ging. Nu is je Poolse site onbruikbaar.
De onzichtbare aanname
Je dacht dat alleen teksten vertaald moesten worden. Tot je stuitte op datums, getallen, valuta's, sortering, zoeken — alles heeft lokaalspecifiek gedrag.
Waar ik mee help:
- ICU MessageFormat-implementatie (verwerkt meervouden, geslacht, context)
- API-i18n-patronen (taalonderhandeling, fallbackstrategieën)
- QA-processen die deze problemen opvangen voordat vertaalbureaus ze vinden
De workflow is het moeilijke gedeelte
Hoe houd je 8 talen gesynchroniseerd als je dagelijks uitrolt?
Je snapt de technologie. Nu loop je vast op het proces:
Ontwikkelaars mergen code met nieuwe Engelse teksten. Vertalingen lopen 2 weken achter. Gebruikers zien een half vertaalde UI.
Je weet niet welke strings veilig verwijderd kunnen worden (worden ze gebruikt? vertaald? zitten ze nog bij een vertaalbureau?)
Product wil de tekst aanpassen. Niemand weet of het wijzigen van „Verzenden" naar „Sturen" 12 talen kapot maakt.
Vertaalbestanden lopen wekenlang uit de pas met productie
Vragen die teams mij stellen:
Wat ik heb zien misgaan:
- Vertaalbestanden in Git die afwijken van de productiestrings
- „Blijf van het Spaanse bestand af"-waarschuwingen omdat niemand weet wat veilig is om te wijzigen
- Functies gelanceerd in het Engels, daarna pas 6 maanden later vertaald (als het überhaupt gebeurt)
Waar ik mee help:
- Ontwerp van de vertaalpipeline (wanneer i18n-bibliotheken gebruiken, wanneer TMS gebruiken, wanneer AI gebruiken)
- Git-workflows om bronstrings en vertalingen synchroon te houden
- Automatisering die PR's blokkeert wanneer nieuwe strings niet zijn gemarkeerd voor vertaling
De techniek is oplosbaar. De workflow is het obstakel. Ik ontwerp workflows die geen heldendaden vereisen om te onderhouden.
Teams waarmee ik heb gewerkt
Wereldwijde producten, regionale expertise
LINE (Japan, Taiwan, Thailand)
Berichtenplatform actief in 3 belangrijke Oost-Aziatische markten. Gewerkt aan uitdagingen rond CJK-tekenverwerking, integratie met platformecosystemen en uiteenlopende verwachtingen op het gebied van gebruikerservaring in Japan, Taiwan en Thailand.
KakaoTalk (Zuid-Korea)
Het dominante berichtenplatform van Korea. Marktspecifieke productvereisten voor Korea aangepakt, waaronder verwachtingen rondom taalformaliteit in de UI en behoeften op het gebied van platformintegratie.
Change.org (196 landen, 20+ prioriteitstalen)
Wereldwijd petitieplatform waar snelheid en kwaliteit van de inhoud beide essentieel zijn. Hielp bij het vormgeven van de vertaalworkflow voor door gebruikers gegenereerde politieke en sociale inhoud in verschillende markten.
Airbnb (220+ landen, 60+ talen)
Wereldwijde marktplaats met complexe i18n-vereisten. Geadviseerd over uitdagingen rondom vertrouwen en veiligheid in meerdere talen, en culturele aanpassing van platformconcepten voor verschillende markten.
Intercom (30+ talen, global B2B SaaS)
Klantcommunicatieplatform voor internationale zakelijke klanten. Gewerkt aan productinternationalisatie voor realtime supporttools en lokalisatie van de kennisbank.
Lilith Games (China, Japan, Korea, VS, EU)
Mobiele game-uitgever met wereldwijd gedistribueerde titels. Werkte aan marktspecifieke uitdagingen op het gebied van contentlokalisatie en regionale platformvereisten.
Markten waarin ik heb gelanceerd:
Oost-Azië (Japan, Korea, China):
CJK-typografie, integratie met het platformecosysteem, verticale tekstondersteuning
Zuidoost-Azië (Thailand, Vietnam, Indonesië):
Multiscriptondersteuning, mobile-first gebruikersverwachtingen
MENA (Arabischtalige regio's):
RTL-lay-outvereisten, verwachtingen rondom formeel versus informeel taalgebruik, culturele inhoudsaanpassing
Europa:
24 officiële talen, productlanceringen in meerdere landen
Noord- en Zuid-Amerika:
Regionale taalvarianten (Latijns-Amerikaans Spaans vs. Spaans uit Spanje, Braziliaans Portugees), tweetalige markten
Ik heb gezien wat werkt en wat mislukt in deze markten — niet vanuit theorie, maar door producten te leveren waar echte gebruikers op vertrouwen.
Laten we oplossen wat er misgaat
Je hebt geen college nodig over waarom i18n belangrijk is. Je hebt iemand nodig die RTL-popovers heeft gedebugd om 2 uur 's nachts, met de productafdeling heeft gesteggeld over tekenlimieten, en vertaalpipelines heeft ontworpen die daadwerkelijk werken.
Architectuur- en strategiebeoordeling (1–2 weken):
Ik vertel je wat er kapotgaat als je de volgende 3 talen toevoegt, en wat het kost om dat te repareren
Ondersteuning bij marktlancering (4–8 weken):
Je lanceert in Japan/MENA/EU en hebt experts nodig die het al eerder hebben gedaan
Doorlopend partnerschap:
Ingebedde consultancy terwijl je opschaalt van 2 naar 20 talen
Ik doe niet aan theorie. Ik doe triage, roadmaps en opleveringen.