Automatische vertaling van Drupal-pagina’s met AI

Een meertalige backlog heeft een bijzondere geur. Je publiceert maandag in het Engels, je belooft Duits “deze week”, en tegen vrijdag staar je naar 47 bijgewerkte pagina’s zonder een nette manier om te antwoorden: “Dus… wat is de echte status?”

Ik heb teams dit zien proberen op te lossen door er meer proces tegenaan te gooien: spreadsheets, vertaal-tickets, wekelijkse syncs. Dat werkt totdat iemand de hero-paragraaf op 200 pagina’s aanpast. Dan ben je weer aan het gokken.

Wat voor ons uiteindelijk werkte, was vertaling behandelen als een productiesysteem: TMGMT om te volgen en te sturen, een kleine custom module om jobs automatisch via cron te triggeren, en een AI-vertaler die op de achtergrond draait en grote velden aankan door ze in chunks op te delen.

Dit artikel is het managerperspectief: resultaten, risico’s en wat je je team moet vragen zodat je niet eindigt met een stille puinhoop.

Eerst: wat “automatische vertaling” echt betekent (in Drupal-termen)

Als je een magische knop voor je ziet die direct een hele site naar vijf talen omzet, vergeet het. De betrouwbare versie is trager en saaier:

• Nieuwe of bijgewerkte content wordt gedetecteerd.
• Er wordt een vertaaljob aangemaakt en gevolgd.
• Het werk draait op de achtergrond volgens een planning.
• Resultaten komen in een reviewstap terecht (of worden automatisch geaccepteerd als je dat risico neemt).
• De vertaalde content wordt gepubliceerd wanneer die aan jouw regels voldoet.

Dat “job”-concept is waarom TMGMT een sterke ruggengraat is. Het is gebouwd om vertaling te beheren als werk met statussen, tracking, bronnen en vertaler-plugins.

Je koopt dus geen “AI-vertaling”. Je koopt een workflow die je kunt meten.

Waarom cron en queues geen implementatiedetail zijn

Managers horen meestal “cron” en denken “geplande taak, prima”. Maar Drupals geautomatiseerde cron draait op een schema dat bij weinig verkeer kan gaan schuiven, en in standaardopstellingen kan het extra belasting op gebruikersverzoeken leggen.

Vertaaljobs zijn zwaar. Ze omvatten externe API-calls, retries en soms lange tekst. Het betrouwbare patroon is dus: zet het werk in de queue en laat cron het vervolgens in gecontroleerde stukjes verwerken.

De managementvertaling daarvan:

• Je editors wachten niet op vertaling.
• Je site krijgt geen latencypiek omdat iemand een lange pagina heeft gepubliceerd.
• Je kunt de throughput tunen door meer of minder achtergrondtijd toe te wijzen.
• Fouten worden geïsoleerd tot kleine werkunits in plaats van de hele run omver te trekken.

Als je team hier niet op gepland heeft, krijg je geen automatisering. Je krijgt een nieuwe faalmodus.

Het AI-deel: wat je wél krijgt, en wat niet

Voor de AI-vertaler gebruiken we een TMGMT-compatibele aanpak, zodat vertaling nog steeds via jobs en workflow wordt beheerd, niet via losse one-off scripts.

Vanuit projectperspectief is de keuze van de provider belangrijker dan mensen verwachten. Het geeft je later opties:

• Je kunt van model wisselen wanneer de kosten veranderen.
• Je kunt gevoelige content anders routeren als beleid dat vereist.
• Je kunt de promptstijl per taal aanpassen om toon-drift te verminderen.
• Je kunt vertaalinstellingen behandelen als configuratie in plaats van hardcoded logica.

Maar verkoop het intern niet te hard. AI-vertaling is snel en kan verrassend goed zijn, maar heeft nog steeds governance nodig. Review-workflows bestaan niet voor niets.

Het grote operationele risico: lange Body-velden

Dit is het deel waar PM’s meestal pas over horen na het eerste incident.

Grote Body-velden (documentatie, policy-pagina’s, pagina’s met veel embedded markup) zijn waar naïeve AI-vertaling stukloopt. Soms luid. Vaker stil: gedeeltelijke output, inconsistent formatting of kapotte HTML die door glipt totdat iemand het op de live site ziet.

Onze fix is niet “betere prompting”. Het is engineering:

• Vertalen op de achtergrond, niet in het pad van de gebruikersrequest.
• Grote Body-waarden opsplitsen in chunks die binnen praktische limieten blijven.
• In de oorspronkelijke volgorde weer samenvoegen.
• Op chunk-niveau retryen, zodat één failure niet de hele pagina blokkeert.

Chunking introduceert wel een trade-off: terminologie kan tussen chunks gaan driften. Dat kun je mitigeren met een lichte glossary of stijregels per taal.

Wat de custom module doet (en waarom je ’m wilt)

TMGMT is de workflow-engine, maar iets moet nog steeds bepalen wanneer er een vertaaljob wordt aangemaakt. Dat is wat de custom module doet:

• Contentwijzigingen detecteren.
• Bepalen welke talen vereist zijn voor dat contenttype.
• Vertaaljobs automatisch aanmaken of bijwerken.
• Werk in een queue duwen zodat cron het later verwerkt.

Dit geeft je een voorspelbaar operationeel ritme. Het maakt vertaling ook onderdeel van publicatie-hygiëne in plaats van een aparte projectstroom.

In grotere programma’s wil je expliciete regels: welke contenttypes automatisch worden vertaald, welke review vereisen, en wat er gebeurt bij kleine edits versus grote rewrites. Zonder regels wordt automatisering verrassingsgedrag.

Wat je moet meten (zodat je kunt zien of het werkt)

Als je succes niet definieert, definieert het team het voor je — en je vindt die definitie misschien niet leuk. Dit zijn metrics die echt op uitkomsten aansluiten:

• Vertaal-latency: mediane tijd van publiceren/updaten van content tot de vertaling beschikbaar is voor review.
• Backloggrootte: aantal items dat in “needs translation” of “needs review” staat.
• Rework rate: hoe vaak vertalingen door mensen worden aangepast na AI-output.
• Failure rate: retries, vastgelopen jobs of formatting issues die interventie vereisen.

Gebruik job-tracking als reporting-oppervlak in plaats van een parallel dashboard te verzinnen.

Governance: waar projecten slagen of je stilletjes in verlegenheid brengen

De snelste manier om vertrouwen in automatische vertaling te verliezen, is iets publiceren dat juridisch risicovol is of je merk schaadt. Automatisering vergroot de blast radius.

Je hebt beleidsbeslissingen nodig, niet alleen modules:

• Welke contenttypes mogen AI-vertalingen automatisch publiceren?
• Welke moeten door review?
• Wie is eigenaar van glossary-termen voor productnamen, juridische formuleringen, gereguleerde taal?
• Wat is je rollbackplan als een model-update de toon verandert?

Een hybride model is vaak het verstandige compromis: AI doet het volume, mensen doen het risico.

Een uitrolplan dat je redactieteam niet opblaast

Als je dit in één keer doet, zullen editors het gevoel hebben dat de grond onder hen verschuift. Er is een beter pad.

Begin met één contenttype met een duidelijke structuur en lager risico. Nieuwsberichten, eventpagina’s, FAQ’s. Krijg de pipeline stabiel. Breid daarna uit naar het rommelige spul: long-form pagina’s, documentatie, marketingpagina’s met zware opmaak.

Beslis ook vroeg hoe je cron draait. Betrouwbaarheid en throughput beïnvloeden leverdata op een manier die teams onderschatten. Dit is geen technische voetnoot.

De vraag die ik zou stellen voordat ik dit groen licht geef

Als het systeem werkt, wordt vertaling achtergrondruis. Dat is het doel.

Maar hier is de ongemakkelijke vraag: optimaliseer je voor snelheid, of voor vertrouwen? Want het antwoord bepaalt of je auto-publiceert, hoe strikt review is, welke talen je eerst uitrolt en hoeveel je investeert in terminologiecontrole.

Als je me vertelt wat voor site je runt (marketing-zwaar, documentatie-zwaar of gemengd) en hoeveel talen in scope zijn, kan ik een uitrolaanpak voorstellen die bij het risicoprofiel past in plaats van te doen alsof één workflow voor iedereen werkt.

Op zoek naar het beste Drupal-developmentbedrijf op de markt? Je hebt het zojuist gevonden.

Wij zijn het grootste Drupal-gefocuste digitale bureau, gebouwd om snelle, veilige en schaalbare platformen te leveren—zonder compromissen. Van nieuwbouw en redesigns tot migraties en langetermijnsupport: onze Drupal-experts leveren enterprise-grade resultaten met boutique-level aandacht.

Plan vandaag nog een call en laten we je Drupal-roadmap omzetten in een high-performing realiteit.