Vertaalpijplijnen: van extractie tot continue deploy

Een vertaalpijplijn is de geautomatiseerde route die de tekst van je product aflegt: van de codebase naar professionele vertalers en weer terug naar productie, bij elke release, zonder spreadsheet of e-mailketen die het werk met de hand doorschuift. Het is de infrastructuurlaag van meertalige softwareontwikkeling: het onderdeel dat bepaalt of een nieuwe functie vanaf dag één in elke ondersteunde taal live gaat, of wekenlang op een handmatige vertaalronde wacht terwijl elke markt buiten je brontaal achterop raakt.

We bouwden deze pijplijnarchitectuur eerst vanaf de leverancierskant. Bij BeTranslated, het vertaalbedrijf waar Globaprom uit is voortgekomen, coördineerden we meer dan twintig jaar honderden professionele linguïsten over tientallen talenparen, onder vaste klantdeadlines. Wat volgt is die ervaring, stap voor stap: de extractie, de overdracht naar het TMS, de afweging tussen menselijke en automatische vertaling, de review in context, en de continue merge en deployment.

Elke nieuwe string bij elke release opvangen

Extractie is de eerste stap, en niemand hoeft eraan te denken om die te starten. Een script of build-plugin scant de codebase bij elke commit of release, vindt elke string die de gebruiker ziet en vergelijkt die met de laatst bekende set. Nieuwe strings worden als nieuw gemarkeerd. Gewijzigde strings worden als gewijzigd gemarkeerd, niet stilletjes opnieuw verstuurd alsof het nieuwe content is die niemand had vertaald. Verwijderde strings vallen buiten het bereik, zodat vertalers nooit tijd besteden aan tekst die niet meer wordt uitgeleverd.

De mechaniek verschilt per stack. React- en Vue-projecten extraheren doorgaans uit i18next- of FormatJS-resourcebestanden. Server-rendered apps putten uit gettext-.po-bestanden of Java-resourcebundles. Statische sites extraheren uit front matter en Markdown-content. Elke opzet steunt op dezelfde regel uit de onderliggende i18n-laag (in het Engels): strings leven in resourcebestanden onder stabiele sleutels, nooit samengesteld uit fragmenten binnen de applicatielogica. Een pijplijn kan alleen extraheren wat de architectuur al heeft geëxternaliseerd. Sla dat fundament over (zie i18n uitgelegd voor niet-technici) en er valt niets schoons te extraheren, alleen strings die verstopt zitten in code en die een script niet veilig kan aanraken.

De storing die deze stap voorkomt, is bekend voor iedereen die meertalige content op de oude manier heeft beheerd. Een ontwikkelaar levert een functie op, de Nederlandse string verschijnt, en elke andere taal drijft stilletjes weg tot iemand zich herinnert dat er een vertaalbatch moet worden aangevraagd. Automatische extractie schrapt dat "zich herinneren". Zodra een string in de brontaal bestaat, staat hij in de wachtrij voor alle andere.

Vertaalgeheugen en terminologielijsten bij de overdracht naar het TMS

Geëxtraheerde strings komen terecht in een translation management system (in het Engels) (TMS), het platform dat content naar vertalers stuurt, de status per taal bijhoudt en de twee mechanismen afdwingt die herhaalde vertaling zowel betaalbaar als consistent maken.

Een vertaalgeheugen is een database van elk eerder vertaald segment, zin voor zin vergeleken met nieuwe content. Een nieuwe string die exact overeenkomt met een opgeslagen vertaling, wordt hergebruikt tegen lage of geen kosten. Een string die dicht in de buurt komt maar niet identiek is (een "fuzzy match") wordt aan de vertaler voorgesteld met het verschilpercentage erbij, zodat hij corrigeert in plaats van vanaf een lege regel opnieuw te typen. Over jaren productcontent stapelt het vertaalgeheugen zich op: terugkerende interfacestrings, standaard juridische teksten en herhaalde productnamen kosten niets meer om opnieuw te vertalen.

Terminologielijsten lossen een ander probleem op: consistentie. Een Nederlandstalig product met tientallen bijdragers en honderden strings verzamelt anders drie verschillende Duitse woorden voor dezelfde knop, omdat drie vertalers elk op drie verschillende dagen een redelijke keuze maakten. Een terminologielijst legt de goedgekeurde term vast, de woordsoort, de context en de te vermijden termen, zodat elke vertaler, mens of machine, "winkelwagen" op elk scherm op dezelfde manier weergeeft. We onderhouden klantglossaria zoals we ze twee decennia lang voor vertaalklanten onderhielden: nagekeken door iemand die het product kent, niet één keer bij de kickoff gegenereerd en daarna vergeten.

Het uitwisselingsformaat onder de meeste TMS-platforms is XLIFF, het XML Localization Interchange File Format, geratificeerd als OASIS-standaard juist om vertaalbare content, de bijbehorende context en de status van tool naar tool te vervoeren zonder een van de drie te verliezen. Een TMS dat XLIFF niet schoon kan importeren en exporteren, vecht bij elke overdracht met je codebase, niet alleen bij de eerste.

Kies mens, machine of MTPE per contenttype

Niet elke string verdient dezelfde vertaalmethode. Ze allemaal gelijk behandelen verspilt geld of kwaliteit, en meestal allebei tegelijk.

Menselijke vertaling verdient haar kosten overal waar een fout duur uitpakt: contractvoorwaarden, prijspagina's, juridische kennisgevingen, onboardingtekst die een eerste indruk bepaalt, en elke string op een betaal- of toestemmingsscherm. Een ervaren linguïst vangt de dubbelzinnigheid op die een machine met stellige overtuiging fout weergeeft.

Post-editing van machinevertaling (MTPE) zit ertussenin. Een machinevertaalengine produceert een eerste versie, en een professionele vertaler leest die na en corrigeert tegen de brontekst in plaats van vanaf een lege pagina te beginnen. De norm ISO 18587:2017 legt de formele eisen aan dat proces vast, en aan de competenties van de post-editor. Dat telt, want "MTPE" wordt losjes gebruikt in verkooppraatjes; de norm definieert wat een volledige post-editing echt moet controleren voordat ze wordt opgeleverd. MTPE past bij volumes die een puur menselijk budget niet kan bijbenen: longtail-productbeschrijvingen, supportarchieven en catalogusdata met duizenden bijna identieke records.

Ruwe machinevertaling zonder review hoort thuis op de smalste snee content: interne tools die niemand buiten het bedrijf ziet, of tekst die uitdrukkelijk als machinaal gegenereerd is gemarkeerd zodat de lezer weet waar hij aan toe is. We raden het zelden aan voor iets dat klanten zien zonder minstens een lichte menselijke controle, want vloeiend en met overtuiging fout is voor een lezer moeilijker te betrappen dan een duidelijke typefout.

Deze beslissing werkt het best als een kaart per contenttype, één keer per project afgesproken in plaats van bij elke string opnieuw bevochten. We schrijven die kaart bij de opzet direct in de routeringsregels van het TMS, zodat nieuwe content automatisch op het juiste bureau belandt, zonder triageoverleg.

Waarom review in context opvangt wat spreadsheets missen

Een string die in isolatie correct is vertaald, kan op het scherm toch fout staan. Het Engelse "Order" betekent een aankoop in een webshop en een instructie in een technische tool, en het Nederlands splitst dat in bestelling en opdracht: twee losse woorden, voor één regel in een spreadsheet die er niets over prijsgeeft. "Post", "Bericht" en "Save" zetten dezelfde val, en een vertaler die alleen de bronkolom ziet, gooit een muntje op. Lengte is de tweede terugkerende faalfactor: een label dat in het Nederlands tot op de millimeter in zijn knop past, loopt over zodra het in het Duits wordt weergegeven, en het W3C becijfert de uitbreiding van korte interfacestrings tot 300% bij vertaling vanuit het Engels (W3C, Text size in translation).

Review in context dicht dat gat. Moderne TMS-platforms tonen een echte of gesimuleerde preview van het betreffende scherm, zodat vertalers de knop, de naastliggende labels en de beschikbare breedte zien terwijl ze werken, niet een regelnummer naast een string-ID. Sommige opzetten gaan verder en koppelen aan elke string die het nodig heeft screenshots die automatisch op een staging-build zijn gemaakt.

We behandelen deze stap als verplicht, niet als optioneel, want de kloof in defecten is groot genoeg om te tellen. Een vertaler zonder context gokt, en elke gok is een greep in het duister naar de werkelijke betekenis van je product. Een vertaler met context stelt minder verduidelijkingsvragen en levert minder correcties na de lancering, omdat hij het product vertaalt dat hij voor zich heeft in plaats van een lijst woorden ernaast.

Continue merge en deployment tegenover de oude "vertaalfase"

Het oude model behandelde vertaling als een fase: bouw het product in het Nederlands, bevries de strings, stuur een batch naar vertalers, wacht, en lever dan alle talen in één keer op, meestal weken na de Nederlandse release. Elke volgende update herhaalde dezelfde bevries-en-wacht-cyclus, zodat je Franstalige, Duitse of Spaanstalige gebruikers permanent achterliepen en een versie inhaalden die al was uitgebracht en alweer voorbij was.

Een productiepijplijn vervangt de fase door een lus. Goedgekeurde vertalingen komen uit het TMS terug via dezelfde review- en buildpoorten als de code: een pull request, geautomatiseerde controles, een merge. Met continue lokalisatie draait die lus bij elke release in plaats van op een vertaalkalender, zodat een Vlaamse of Japanse gebruiker een nieuwe functie in hetzelfde uitrolvenster ziet als een Nederlandse gebruiker, niet een kwartaal later.

Dit is de omslag die meertalige software die actueel blijft, scheidt van een product dat één keer is vertaald en daarna aan zijn lot is overgelaten. We hebben beide modellen vanaf de leverancierskant meegemaakt: de oude batchoverdracht, waarbij het engineeringteam van een klant op ons leverschema wachtte, en de continue lus, waarbij vertaalde content naast de code mee-merget omdat de pijplijn het als een build-artefact behandelt, niet als een aparte workstream op zijn eigen klok. Het tweede model schrapt een hele categorie "welke taal loopt achter"-statusoverleggen. Het antwoord is altijd hetzelfde: geen enkele.

Wat twintig jaar aan de leverancierskant ons leerde

We zaten vroeger aan het verre eind van deze pijplijn, niet in het bedrijf dat hem bouwt. Meer dan twee decennia lang ontving BeTranslated geëxtraheerde strings, mobiliseerde honderden freelance linguïsten over tientallen talenparen, en stuurde de afgeronde vertalingen terug tegen de deadline van een klant, niet die van onszelf.

Dat perspectief leerde ons waar pijplijnen echt breken. Terminologielijsten drijven weg zodra niemand er na de kickoff eigenaar van is. Het vertaalgeheugen rot weg wanneer een TMS-migratie de database kwijtraakt, en dan wordt elke string opnieuw als nieuw gefactureerd. Deadlines schuiven het hardst op de overdrachtspunten, niet tijdens het vertalen zelf, want een linguïst kan pas beginnen op het moment dat de content hem daadwerkelijk in een bruikbaar formaat bereikt.

Dat we de pijplijn nu zelf bouwen in plaats van bestanden aan het uiteinde ervan te ontvangen, verklaart waarom we de overdracht als eerste ontwerpen: welk TMS, welke eigenaar van de terminologielijst, welke reviewpoort, voordat één regel applicatiecode aanneemt dat er een tweede taal bestaat.

Veelgestelde vragen over vertaalpijplijnen

Wat is een vertaalpijplijn?

Een vertaalpijplijn is het geautomatiseerde systeem dat nieuwe content uit je codebase haalt, via een translation management system naar vertalers stuurt, laat vertalen door mensen of met MTPE, in context laat reviewen en bij elke release terug-merget. Geen handmatige overdracht nodig.

Hoe verschilt een vertaalpijplijn van een vertaalfase?

Een vertaalfase bundelt vertaling aan het eind van een build of herhaalt ze in sporadische inhaalrondes, waardoor gebruikers weken op nieuwe talen wachten. Een pijplijn draait continu: elke release komt in alle ondersteunde talen tegelijk uit, want vertaling is een buildstap, geen aparte kalender.

Waar staat TMS voor?

TMS staat voor translation management system: het platform dat content naar vertalers stuurt, vertaalgeheugen en terminologielijsten toepast en de status per taal bijhoudt. In de logistiek betekenen dezelfde drie letters transportation management system, een tool zonder verband.

Hoe verschilt een vertaalpijplijn van lokalisatie?

De pijplijn is het mechanisme; lokalisatie is de bredere aanpassing die hij levert, inclusief formats, valuta en beeld. De pijplijn verplaatst de woorden en hun status; lokalisatie beslist over al het overige dat een bepaalde markt daarbovenop nodig heeft.

Vertalen jullie de content zelf, of bouwen jullie alleen de pijplijn?

We organiseren de vertaling in plaats van ze uit te voeren zoals je eigen team dat zou doen. Via de pijplijn die we bouwen en ons netwerk van professionele linguïsten, met tientallen talenparen en honderden vertalers, heb je bij elke release menselijke vertaling of MTPE binnen handbereik.

Richt de pijplijn één keer in, lever daarna elke taal

Vertel ons welke talen je product nodig heeft en hoe nieuwe strings vandaag worden afgehandeld, als dat al gebeurt. We bakenen de extractie, het TMS, de terminologielijst en de reviewpoort af als één build met vaste prijs, geen abonnement dat na de lancering op je codebase is geschroefd.

Vraag een offerte met vaste prijs aan →