Eén bestand erin, vijf formaten eruit: Zo maak je je WordPress-vertalingen toekomstbestendig

Je hebt drie weken besteed aan het vertalen van je WordPress-thema naar het Spaans. Het .po-bestand is perfect — elke string gecontroleerd, elke variabele intact, elke meervoudsvorm correct. Dan besluit je klant over te stappen van een klassiek PHP-thema naar een headless setup met React aan de frontend.

Plotseling is je .po-bestand nutteloos. De React-app heeft .json nodig. De legacy PHP-widgets hebben nog steeds .mo nodig. De freelancer die de mobiele app beheert, wil .xliff. En niemand heeft tijd om 4.000 strings opnieuw te vertalen naar drie verschillende formaten.

Dit is geen uitzonderlijk geval. Het is de realiteit van moderne WordPress-ontwikkeling, waarbij thema's worden geleverd met zowel PHP- als JavaScript-componenten, plugins een mix van Gettext en i18next gebruiken en klanten vaker van gedachten veranderen over de architectuur dan ze hun wachtwoorden veranderen.

Waarom vertaalbestandsformaten belangrijker zijn dan ooit

Vijf jaar geleden was WordPress-vertaling eenvoudig. Je had een .po-bestand (menselijk leesbare bron) en een .mo-bestand (gecompileerde binaire code). Dat was het. Elk thema, elke plugin, elke vertaaltool sprak dezelfde taal.

Tegenwoordig gebruikt het WordPress-ecosysteem minstens vijf vertaalbestandsformaten in productie:

De vijf formaten die je moet kennen

.po (Portable Object) — Het door mensen leesbare bronformaat dat wordt gebruikt door GNU Gettext. Bevat originele strings (msgid) en hun vertalingen (msgstr). Dit is wat vertalers bewerken.

msgid "Add to Cart"
msgstr "Anadir al carrito"

msgid "Your order has been shipped to %s"
msgstr "Su pedido ha sido enviado a %s"

.mo (Machine Object) — De gecompileerde binaire versie van een .po-bestand. WordPress leest .mo-bestanden tijdens runtime met behulp van load_textdomain(). Sneller dan het parsen van .po tijdens runtime, maar niet door mensen te bewerken.

.json (JavaScript Object Notation) — Gebruikt door wp_set_script_translations() voor JavaScript-gebaseerde vertalingen in Gutenberg-blokken, React-componenten en moderne thema's. WordPress verwacht een specifieke JSON-structuur met locale_data-keys.

{
  "locale_data": {
    "flavor-starter": {
      "Add to Cart": ["Anadir al carrito"],
      "Your order has been shipped to %s": ["Su pedido ha sido enviado a %s"]
    }
  }
}

.php (PHP Array) — Een steeds populairder wordend formaat voor thema's en plugins die vertalingen laden in Laravel-stijl. Sommige moderne WordPress-thema's omzeilen Gettext volledig en laden vertalingen uit PHP-arrays voor betere prestaties.

<?php
return [
    'Add to Cart' => 'Anadir al carrito',
    'Your order has been shipped to %s' => 'Su pedido ha sido enviado a %s',
];

.xliff (XML Localization Interchange File Format) — De industriestandaard voor vertaaluitwisseling tussen verschillende tools en platforms. Gebruikt door CAT-tools (Computer-Assisted Translation) zoals memoQ, Trados en Memsource. Essentieel bij het werken met professionele menselijke vertalers.

<trans-unit id="1">
  <source>Add to Cart</source>
  <target>Anadir al carrito</target>
</trans-unit>

Het probleem: Formaat Lock-In

De meeste vertaaltools produceren één uitvoerformaat. Poedit geeft je .po en .mo. WPML slaat vertalingen op in de database (helemaal niet in bestanden). Weglot bewaart vertalingen op hun servers in een eigen formaat. Zelfs TMS-platforms zoals Crowdin en Lokalise vereisen dat je handmatig exportformaten configureert voor elk project.

Dit creëert formaat lock-in — je vertalingen zitten vast in het formaat dat je huidige tool produceert. Wanneer je eisen veranderen, heb je twee opties:

1. Alles opnieuw vertalen in het nieuwe formaat (duur, tijdrovend en je verliest alle handmatige correcties).
2. Aangepaste conversiescripts schrijven (foutgevoelig, vooral voor complexe meervoudsvormen en variabelen).

Geen van beide opties is goed. Beide verspillen tijd en geld. Beide introduceren risico's.

Echte scenario's waarin formaat lock-in pijn doet

Scenario 1: Thema modernisering. Het thema van je klant wordt herbouwd met Gutenberg-blokken. De oude PHP-templates gebruikten .mo-bestanden. De nieuwe blokken hebben .json nodig voor wp_set_script_translations(). Je 3.000 vertaalde strings moeten tijdens de overgang in beide formaten bestaan.

Scenario 2: Agency workflow. Je beheert 20 klantensites. Sommige gebruiken klassieke thema's (.mo). Sommige gebruiken headless setups (.json). Eén gebruikt een aangepast framework dat PHP-arrays leest. Je hebt dezelfde vertalingen in verschillende formaten nodig voor verschillende klanten.

Scenario 3: Professionele revisie. Je AI-vertalingen zijn 95% nauwkeurig, maar je wilt dat een native speaker de overige 5% beoordeelt. Professionele vertalers gebruiken CAT-tools die .xliff importeren. Je moet je vertalingen exporteren naar .xliff, ze ter beoordeling verzenden en de correcties terug samenvoegen.

Scenario 4: Platform migratie. Je klant stapt over van WordPress naar een aangepaste Node.js-applicatie. De nieuwe app gebruikt i18next en heeft .json-bestanden nodig. Je 5.000 vertaalde strings in .po-formaat moeten worden geconverteerd — zonder een enkele variabele of meervoudsvorm te verliezen.

De oplossing: Eén keer vertalen, elk formaat krijgen

SimplePoTranslate hanteert een andere aanpak. Wanneer je een .po, .pot, .json of .xliff bestand uploadt en een vertaling uitvoert, krijg je een ZIP terug met alle vijf formaten:

translations-es_ES.zip
├── flavor-starter-es_ES.po
├── flavor-starter-es_ES.mo
├── flavor-starter-es_ES.json
├── flavor-starter-es_ES.php
└── flavor-starter-es_ES.xliff

Dit is geen "premium functie" die is vergrendeld achter een enterprise tier. Elk betaald plan — Pro ($19/maand) en Lifetime ($399 eenmalig) — bevat alle vijf uitvoerformaten in elke vertaalopdracht.

Waarom dit belangrijk is voor toekomstbestendigheid

Wanneer je vanaf het begin alle vijf formaten hebt, hoef je nooit meer opnieuw te vertalen. Je vertalingen zijn een asset die zich aanpast aan elke technische vereiste:

• Klant migreert van klassiek naar Gutenberg? Implementeer het .json-bestand.
• Nieuwe ontwikkelaar geeft de voorkeur aan PHP-arrays? Geef ze het .php-bestand.
• Professionele vertaler wil beoordelen? Stuur het .xliff-bestand.
• Overstappen naar een ander CMS? De .json- en .xliff-bestanden zijn platformonafhankelijk.

Je vertaalt één keer. De formaten zijn klaar wanneer je ze nodig hebt.

Hoe elk formaat werkt in WordPress

Weten welk bestand waar naartoe gaat, is essentieel voor een schone implementatie.

.mo-bestanden implementeren (klassieke PHP-thema's en plugins)

wp-content/languages/plugins/woocommerce-es_ES.mo
wp-content/languages/themes/flavor-starter-es_ES.mo

WordPress laadt deze automatisch wanneer de sitetaal overeenkomt. Geen plugin vereist. Geen database overhead. Dit is de aanpak die de beste prestaties levert.

.json-bestanden implementeren (Gutenberg-blokken en JS-componenten)

wp-content/languages/plugins/woocommerce-es_ES-{handle}-{md5}.json

De bestandsnaam bevat de script-handle en een MD5-hash. WordPress komt hiermee overeen wanneer je wp_set_script_translations() aanroept in je plugin of thema. Als je Gutenberg-blokken bouwt, is dit het bestand dat ervoor zorgt dat je vertaalde bloklabels en -beschrijvingen correct worden weergegeven.

.xliff-bestanden gebruiken (professionele revisieworkflow)

.xliff-bestanden worden niet geïmplementeerd in WordPress. Ze worden gebruikt als een uitwisselingsformaat wanneer je vertalingen naar een professionele reviewer moet sturen of ze in een CAT-tool moet importeren. De workflow ziet er als volgt uit:

1. Upload .po naar SimplePoTranslate en krijg .xliff in de ZIP
2. Stuur .xliff naar je vertaler of reviewer
3. Ontvang gecorrigeerde .xliff terug
4. Upload gecorrigeerde .xliff naar SimplePoTranslate en krijg bijgewerkte .mo en .json

Deze round-trip workflow behoudt elke variabele en meervoudsvorm omdat SimplePoTranslate's Syntax Locking ze in elke fase beschermt.

De Vendor Lock-In test

Hier is een eenvoudige test om te bepalen of je huidige vertaalworkflow een lock-in probleem heeft:

1. Kun je je vertalingen nu exporteren als standaard .po-bestanden?
2. Als je vandaag je abonnement op je vertaaltool opzegt, behoud je dan elke vertaalde string?
3. Kun je je vertalingen importeren in een compleet andere tool of platform zonder opnieuw te vertalen?

Als het antwoord op een van deze vragen "nee" is, zit je vast. Services zoals Weglot en GTranslate slagen niet voor alle drie de vragen — annuleer het abonnement en je vertalingen verdwijnen. WPML slaat vertalingen op in de database, waardoor exporteren mogelijk maar pijnlijk is. Zelfs desktoptools zoals Poedit slagen in theorie voor de test, maar beperken je tot alleen .po en .mo.

Met SimplePoTranslate is het antwoord op alle drie de vragen "ja". Je downloadt standaardbestanden in vijf formaten. Ze zijn van jou. Verwijder morgen je account en elke vertaling die je ooit hebt gemaakt, werkt nog steeds.

Een formaatonafhankelijke vertaalbibliotheek bouwen

Voor agencies en ontwikkelaars die meerdere projecten beheren, is de slimste aanpak om een vertaalbibliotheek te bouwen — een Git repository of gedeelde map waar je vertaalde bestanden voor elk klantproject opslaat.

translations/
├── client-acme/
│   ├── es_ES/
│   │   ├── flavor-starter-es_ES.po
│   │   ├── flavor-starter-es_ES.mo
│   │   ├── flavor-starter-es_ES.json
│   │   ├── flavor-starter-es_ES.php
│   │   └── flavor-starter-es_ES.xliff
│   └── de_DE/
│       └── ...
├── client-globex/
│   └── ...

Wanneer een klant een nieuw formaat nodig heeft, heb je het al. Wanneer een klant van platform verandert, migreren je vertalingen zonder enige moeite. Wanneer een nieuwe ontwikkelaar zich bij het team voegt, kunnen ze precies zien wat er is vertaald en in welke formaten.

Dit is wat "toekomstbestendig" eigenlijk betekent — niet voorspellen welke technologie je klanten volgend jaar zullen gebruiken, maar ervoor zorgen dat je vertalingen werken met wat ze ook kiezen.

Klaar om je geen zorgen meer te maken over bestandsformaten? Probeer SimplePoTranslate gratis — upload één bestand, krijg vijf formaten terug. Geen conversiescripts, geen hervertaling, geen lock-in.