Terug naar blog

Workflow · 1 apr 2026

Updates vertalen zonder alles opnieuw te vertalen

De meeste meertalige releases zijn bewerkingen, geen volledig nieuwe pagina's. Zo houd je updates klein, veilig en snel.

Updates vertalen zonder alles opnieuw te vertalen

De meeste adviezen over lokalisatie gaan er stilzwijgend van uit dat teams gloednieuwe content vanaf nul vertalen. Zo zien de meeste releaseweken er niet uit. De meeste weken bestaan uit bewerkingen: een prijswijziging, een aangescherpte kop, een tweak in de product-UI, een bijgewerkte CTA, een nieuwe alinea op een bestaande landingspagina.

Als elke kleine wijziging een volledige vertaalcyclus triggert, wordt de workflow elke maand zwaarder.

De fout: elke update behandelen als een nieuw project

Teams weten vaak precies wat er in het Engels is veranderd, maar hun lokalisatieworkflow bewaart die precisie niet. Het resultaat is herkenbaar: een kleine update wordt doorgezet als een verzoek voor paginabrede vertaling, reviewers moeten te veel materiaal scannen, en het team besteedt meer tijd aan bewijzen dat oude copy nog steeds klopt dan aan het verbeteren van de nieuwe copy.

Daar begint het vertrouwen in releases af te brokkelen.

Het betere model: vertaal de delta

Een volwassen workflow behandelt updates als delta's, niet als resets.

Dat betekent vragen:

  • welke velden daadwerkelijk zijn gewijzigd
  • welke secties al waren goedgekeurd en vergrendeld kunnen blijven
  • welke pagina's genoeg risico dragen om gerichte review te rechtvaardigen
  • welke locales de update onmiddellijk nodig hebben

Dit klinkt eenvoudig, maar het verandert de werklast drastisch. Zodra het team de delta verkleint, voelt vertalen niet langer als een terugkerend backlog-evenement en begint het te voelen als normaal contentonderhoud.

Waarom beperkte updates sneller gaan

Er zijn drie praktische redenen waarom kleinere updates makkelijker te publiceren zijn.

1. Review blijft proportioneel

Wanneer slechts één CTA en één subkop zijn veranderd, zou de reviewer niet de hele pagina opnieuw moeten lezen alsof het launch day is. Een beperkte wijzigingsset creëert een beperkte reviewset.

2. Eerdere beslissingen blijven bruikbaar

Als glossary-keuzes, goedgekeurde formuleringen en merkgevoelige bewoording al stabiel zijn, moet het systeem op die beslissingen voortbouwen in plaats van ze elke week opnieuw te openen.

3. Risico is makkelijker te zien

Grote hervertaalrondes verbergen de belangrijke wijzigingen in een stapel ongewijzigde content. Kleinere updates maken het risico zichtbaar. Het team kan snel de regels zien die ertoe doen en de delen negeren die geen aandacht nodig hebben.

Hoe je updatevertaling structureert

Voor Contentful-teams is een bruikbaar patroon:

  1. identificeer alleen de entries of velden die zijn gewijzigd
  2. houd eerder goedgekeurde copy waar mogelijk vergrendeld
  3. voer vertaling alleen uit voor de update-scope
  4. review de gewijzigde copy in context
  5. publiceer nadat is bevestigd dat de entry in de doellocale overeenkomt met de beoogde update

Dit is niet alleen sneller. Het is ook schoner. De workflow leert stabiele content te respecteren in plaats van bij elke run alles te verstoren.

De verborgen winst: minder reviewermoeheid

Reviewermoeheid is een echte lokalisatiekost. Wanneer mensen worden gevraagd om te veel ongewijzigde copy te inspecteren, zien ze niet meer wat aandacht verdient. De workflow voelt verantwoord, maar de reviewkwaliteit daalt alsnog omdat de signaal-ruisverhouding slecht is.

Kleinere update-runs lossen dat op. Ze laten reviewers hun energie besteden aan de copy die daadwerkelijk is veranderd, en daar telt hun oordeel.

Wanneer je de scope niet beperkt moet houden

Er zijn nog steeds momenten om de batch te verbreden:

  • een producthernoeming raakt meerdere oppervlakken
  • een campagneboodschap is wereldwijd veranderd
  • een glossary-beslissing moet op oudere pagina's worden toegepast
  • een compliance- of juridische herziening raakt veel entries tegelijk

De sleutel is om de scope bewust te verbreden, niet standaard.

De kern

Lokalisatie wordt duur wanneer elke update zich gedraagt als een volledige herlancering. Het wordt veel makkelijker wanneer de workflow het verschil respecteert tussen een herschrijving en een revisie.

De meeste teams hebben geen snellere manier nodig om alles opnieuw te vertalen. Ze hebben een veiligere manier nodig om minder aan te raken.