Vertaal Elementor & Divi Templates Zonder Layouts te Breken

Je hebt alles goed gedaan. Je kocht een premium thema, vond het .po-bestand, vertaalde het zorgvuldig en uploadde het .mo-bestand naar je talenmap. Strings in de themaheader worden correct bijgewerkt. De footer leest in het Spaans. Je WooCommerce-afrekenpagina is gelokaliseerd. Maar dan open je de homepage en blijkt elke afzonderlijke kop, knop en tekstblok, gebouwd met Elementor, nog steeds in het Engels te zijn.

Je controleert het .po-bestand. Je ziet de Engelse strings in de code. Je vertaalt opnieuw. Niets verandert. Je leegt caches. Niets verandert. Je overtuigt jezelf ervan dat er iets kapot is, totdat iemand op een forum voorzichtig opmerkt: Elementor (en Divi, en Beaver Builder, en Bricks) slaan inhoud niet op in .po-bestanden. Dat hebben ze nooit gedaan. Je hebt gestreden tegen een probleem dat niet oplosbaar is met de aanpak die je gebruikt.

Deze gids legt uit waarom page builder-inhoud architectonisch verschilt van thema- en plugin-inhoud, de twee manieren om deze te vertalen, en hoe je de widget-markup intact houdt tijdens het vertalen, zodat je zorgvuldig ontworpen layouts niet uit elkaar vallen.

Waarom Elementor en Divi geen .po-bestanden gebruiken

.po-bestanden slaan strings op die in de code leven – __( 'Shop', 'mytheme' )-aanroepen verspreid over PHP-templates. De buildtool WP-CLI kan deze strings extraheren naar een .pot-template, vertalers werken aan .po-bestanden en gecompileerde .mo-bestanden worden tijdens runtime geladen.

Inhoud van page builders is anders. Wanneer je 'Welkom in onze winkel' typt in een Elementor-kopwidget, staat die tekst niet in een PHP-bestand. Het wordt opgeslagen als JSON (Elementor) of een shortcode-blob (Divi) in de wp_postmeta-tabel, gekoppeld aan het bericht waar je het hebt geplaatst.

Waar Page Builder-inhoud daadwerkelijk leeft

Elementor slaat de widgetstructuur van elke pagina op in postmeta onder de sleutel _elementor_data. Open een willekeurig bericht in de database en je vindt een JSON-array die elke sectie, kolom en widget beschrijft, met instellingen en inhoud inline:

{
  "id": "a1b2c3",
  "elType": "widget",
  "widgetType": "heading",
  "settings": {
    "title": "Welcome to our store",
    "size": "xl",
    "header_size": "h1"
  }
}

Divi slaat de pagina-inhoud op als shortcodes ingebed in post_content:

[et_pb_section][et_pb_row][et_pb_column type="4_4"]
  [et_pb_text]Welcome to our store[/et_pb_text]
[/et_pb_column][/et_pb_row][/et_pb_section]

Bricks, Beaver Builder en Oxygen volgen hetzelfde patroon met hun eigen formaat. Geen van deze inhoud wordt ooit aangeraakt door .po / .mo-bestanden.

Wat er wél in .po-bestanden leeft

De page builder-plugin zelf heeft UI-strings – knoplabels in de editor, foutmeldingen, admin-berichten. Die staan in .po-bestanden en worden wel vertaald door je .mo-bestanden in wp-content/languages/plugins/. Dit is meestal waarom mensen verward raken: ze vertalen 'Elementor'-strings en zien de editor-UI in het Spaans, maar de daadwerkelijke inhoud die ze met die widgets hebben gebouwd, blijft in het Engels.

Dit onderscheid is ook de hoofdoorzaak van de helft van de tickets in onze gids voor probleemoplossing als vertalingen niet worden weergegeven – de lezer verwacht dat .mo-bestanden invloed hebben op inhoud die ze aan de voorkant zien, maar de inhoud bevindt zich in de database, niet in de code.

Wat .po-bestanden daadwerkelijk dekken op een Page Builder-site

Laat me een duidelijke scheidslijn trekken tussen de twee, zodat je precies weet wat elk bestandstype afhandelt.

.po / .mo-bestanden vertalen

• De template-strings van het thema: get_template_part, hardgecodeerde tekst in header.php, footer.php, functions.php.
• Plugin UI-strings: WooCommerce afrekenpagina, Yoast admin-labels, Contact Form 7 veldlabels.
• Page builder plugin UI: Elementor editor-knoppen, Divi opslagbevestigingsberichten.
• Dynamische strings die plugins naar de voorkant sturen: WooCommerce 'Toevoegen aan winkelwagen', 'Niet op voorraad', winkelwagentotaal.

.po / .mo-bestanden vertalen NIET

• Kop-, paragraaf- en knoptekst getypt in Elementor-widgets.
• Afbeeldingsteksten, hover-effecten, accordeontitels binnen Divi-modules.
• Inhoud in herbruikbare templates, globale secties, opgeslagen blokken.
• Aangepaste CSS-labels of inline scripts binnen builder-widgets.

Dit is waarom de documentatie van thema-auteurs over vertaling technisch correct is, maar vaak nutteloos voor eindgebruikers. Onze gids over hoe je elk WordPress-thema lokaliseert behandelt de thema-kant grondig – dit bericht pikt de draad op waar die eindigt.

Twee manieren voor Page Builder-lokalisatie

Er zijn precies twee manieren om page builder-inhoud te vertalen, en beide hebben reële afwegingen.

Manier Eén: Pagina's dupliceren per taal

Gebruik een meertalige plugin zoals WPML, Polylang of TranslatePress. Deze creëert een kopie van elke pagina per taal. In Elementor dupliceer je de hele layout en vervang je de tekst op elke kopie. In Divi kopieer je de shortcode-blob en vertaal je de tekst tussen de tags.

Voordelen: Elke taal kan onafhankelijk ontworpen layouts hebben (handig wanneer vertaalde tekst langer is en je oorspronkelijke ontwerp breekt). Volledige compatibiliteit met de visuele editor van de page builder.

Nadelen: Lineaire schaling – 5 talen betekent 5x het layoutwerk. Elke ontwerpaanpassing moet 5 keer worden toegepast. Database groeit snel. Caching wordt moeilijker.

Manier Twee: Stringvertaallaag

Sommige plugins (Polylang Pro, WPML's String Translation-module, TranslatePress) kunnen individuele strings binnen page builder-widgets blootleggen voor vertaling, en deze vervolgens tijdens het renderen omwisselen. Je onderhoudt één layout en de plugin vertaalt strings ter plekke.

Voordelen: Eén enkele bron van waarheid voor de layout. Ontwerpaanpassingen worden overal toegepast.

Nadelen: Minder flexibiliteit wanneer vertaalde tekst dramatisch van lengte verandert. Sommige widgets (complexe met geneste inhoud, dynamische lijsten, formulieren) leggen strings niet netjes bloot. Prestatiekosten per weergave.

Onze vergelijking van Polylang vs WPML vs TranslatePress behandelt de afwegingen van elke plugin in meer detail.

Widget-markup veilig houden tijdens vertaling

Welke manier je ook kiest, vertaalde inhoud moet de structurele markup van de builder behouden. Als je vertaler een Elementor-shortcode verwijdert, een data-attribuut vervangt of geneste tags herordent, zal de widget kapot worden weergegeven.

Elementor Gevarenzones

Elementor-widgets bevatten shortcodes en dynamische tags in tekstinstellingen. Het titelveld van een kopwidget kan het volgende bevatten:

Welcome to <strong>our</strong> [user_name] store

Die [user_name] is een dynamische tag – Elementor vervangt deze door de naam van de ingelogde gebruiker tijdens het renderen. Als de vertaling deze verminkt, krijgen gebruikers letterlijk '[user_name]' te zien.

Pictogrammen in knoppen gebruiken klasse-attributen die niet vertaald mogen worden. Alternatieve tekst voor afbeeldingen wordt apart opgeslagen van de afbeeldings-URL. Kolomlayouts gebruiken breakpoint-specifieke instellingen (title_mobile, title_tablet) die individuele behandeling vereisen.

Divi Shortcode Nesting

Divi-shortcodes nesten diep: [et_pb_section][et_pb_row][et_pb_column][et_pb_text]. Een vertaler die de blob als platte tekst behandelt, zal haakjes coderen, attribuutwaarden vertalen of sluitende tags verliezen. Elk van deze acties beschadigt de module en Divi weigert deze te renderen.

Het veilige patroon

Voor beide builders moet vertaling het volgende doen:

1. Parseer het widgetformaat (JSON voor Elementor, shortcode AST voor Divi).
2. Loop door de boomstructuur en identificeer alleen de voor gebruikers zichtbare tekstvelden.
3. Vergrendel shortcodes, dynamische tags, HTML-attributen en inline CSS.
4. Stuur alleen de tekstoppervlakken met context naar de vertaler.
5. Plaats de vertaalde tekst terug in de oorspronkelijke structuur.

Dit is hetzelfde principe dat onze engine toepast op .po-bestanden. De handleiding voor het vertalen van .po-bestanden zonder codevariabelen te breken behandelt de %s en placeholder-patronen in detail – het page builder-equivalent zijn shortcodes en dynamische tags.

Een hybride workflow die echt werkt

Voor de meeste teams is het praktische antwoord het combineren van beide benaderingen.

Stap 1: Vertaal thema- en plugin-UI via .po-bestanden

Exporteer .pot-bestanden van je thema en belangrijke plugins (WooCommerce, Yoast, page builder UI). Vertaal ze één keer via een cloudvertaler die het .po-formaat respecteert. Plaats gecompileerde .mo-bestanden in wp-content/languages/. Dit behandelt 80% van de interface-strings van je site met bijna nul doorlopend onderhoud.

Stap 2: Kies een meertalige plugin voor dynamische inhoud

Installeer Polylang of WPML voor bericht-, pagina- en productinhoud. Configureer de URL-structuur (/es/, /fr/) en hreflang-tags. Dit geeft je de infrastructuur voor database-inhoud per taal.

Stap 3: Dupliceer je Page Builder Templates selectief

Voor veelbezochte landingspagina's, homepages en belangrijke marketinginhoud dupliceer je de pagina in elke taal en vertaal je de widgets handmatig. Je krijgt volledige ontwerpcontrole waar het erom gaat.

Stap 4: Gebruik String Translation voor herhaalde blokken

Voor globale secties, herbruikbare templates en footer-CTA's die op elke pagina verschijnen, gebruik je de stringvertaalfunctie van je meertalige plugin. Update op één plek, wissel tijdens het renderen.

Stap 5: Voer kwaliteitscontroles uit

Vertaalde page builder-inhoud moet worden weergegeven zonder lay-outverschuivingen. Langere talen (Duits, Russisch) breken knopbreedtes. Kortere talen (Chinees, Japans) laten onhandige witruimte achter. Test elke template per taal voordat je live gaat.

Veelvoorkomende valkuilen en hoe je ze vermijdt

Enkele valkuilen die in elk page builder-lokalisatieproject verschijnen.

Alternatieve tekst voor afbeeldingen wordt niet vertaald

Zowel Elementor als Divi slaan alt-tekst per widget-instantie op, niet in de Mediabibliotheek. Het vertalen van de originele afbeelding vertaalt de alt-tekst niet in elke widget die deze gebruikt. Werk de alt-tekst bij op elke gedupliceerde pagina.

Formulieren en aangepaste velden

Contactformulieren ingebed in page builder-widgets hebben hun eigen strings (labels, placeholders, validatieberichten). Zie onze gids over het vertalen van Gravity Forms en Contact Form 7 voor de formulierenkant.

Globale widgets en templates

Wijzigingen in een globale template worden doorgevoerd naar elke pagina die deze gebruikt, inclusief vertaalde kopieën. Dit kan nuttig of catastrofaal zijn, afhankelijk van of je gedeelde of afzonderlijke inhoud wilt. Beslis dit expliciet per template.

Expiratie van vertaalcache

Page builders cachen gerenderde HTML agressief. Na het vertalen, leeg alle caches, inclusief de Elementor CSS-cache (Elementor > Tools > CSS opnieuw genereren) en de Divi statische CSS-cache.

Alles samenvatten

Een site gebouwd met Elementor of Divi vertalen is niet moeilijker dan een statisch thema vertalen – het vereist alleen het juiste mentale model. Thema- en plugin-strings leven in .po-bestanden en reizen via .mo-bestanden. Page builder-inhoud leeft in de database en reist via meertalige plugins of handmatige duplicatie. Het door elkaar halen van de twee manieren is de meest voorkomende bron van frustratie over 'waarom werken mijn vertalingen niet'.

De workflow die werkt is saai: statische .mo-bestanden voor alles wat in de code leeft, een meertalige plugin voor pagina-inhoud en handmatige curatie voor waardevolle landingspagina's. Geen enkele tool behandelt alle drie, en iedereen die je iets anders belooft, verkoopt je iets.

Klaar om je thema- en plugin .po-bestanden te vertalen zonder widget-markup te breken? Probeer SimplePoTranslate gratis – geen creditcard nodig. Upload .po, download veilige vertalingen, plaats ze in wp-content/languages/.