Oversæt Elementor- og Divi-skabeloner uden at ødelægge layouts

Du gjorde alt rigtigt. Du købte et premium-tema, fandt .po-filen, oversatte den omhyggeligt og uploadede .mo-filen til din sprogmappe. Strengene i temaets header opdateres korrekt. Footeren vises på spansk. Din WooCommerce-kasse er oversat. Men så åbner du hjemmesiden, og hver eneste overskrift, knap og tekstblok bygget med Elementor er stadig på engelsk.

Du tjekker .po-filen. Du kan se de engelske strenge i koden. Du oversætter igen. Intet ændrer sig. Du rydder caches. Intet ændrer sig. Du overbeviser dig selv om, at noget er i stykker, indtil nogen i et forum forsigtigt påpeger: Elementor (og Divi, og Beaver Builder, og Bricks) gemmer ikke indhold i .po-filer. Det har de aldrig gjort. Du har kæmpet med et problem, der ikke kan løses med den tilgang, du bruger.

Denne guide forklarer, hvorfor sidebygger-indhold er arkitektonisk anderledes end tema- og plugin-indhold, de to veje til at oversætte det, og hvordan du holder widget-markup intakt under oversættelse, så dine omhyggeligt designede layouts ikke falder fra hinanden.

Hvorfor Elementor og Divi ikke bruger .po-filer

.po-filer gemmer strenge, der lever i kode - __( 'Shop', 'mytheme' )-kald spredt ud over PHP-skabeloner. Byggeværktøjet WP-CLI kan udtrække disse strenge til en .pot-skabelon, oversættere arbejder på .po-filer, og kompilerede .mo-filer indlæses ved kørsel.

Sidebygger-indhold er anderledes. Når du skriver "Velkommen til vores butik" i en Elementor-overskrift-widget, er denne tekst ikke i nogen PHP-fil. Den gemmes som JSON (Elementor) eller en shortcode-blob (Divi) i wp_postmeta-tabellen, associeret med det indlæg, hvor du placerede den.

Hvor sidebygger-indhold faktisk bor

Elementor gemmer hver sides widget-træ i postmeta under nøglen _elementor_data. Åbn ethvert indlæg i databasen, og du vil finde et JSON-array, der beskriver hver sektion, kolonne og widget, med indstillinger og indhold inline:

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

Divi gemmer sit sideindhold som shortcodes indlejret i 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 og Oxygen følger det samme mønster med deres eget format. Intet af dette indhold berøres nogensinde af .po / .mo-filer.

Hvad der lever i .po-filer

Sidebygger-plugin'et selv har UI-strenge – knapetiketter i editoren, fejlmeddelelser, admin-meddelelser. Disse er i .po-filer og bliver oversat af dine .mo-filer i wp-content/languages/plugins/. Dette er normalt grunden til, at folk bliver forvirrede: de oversætter "Elementor"-strenge og ser editor-UI'en på spansk, men det faktiske indhold, de byggede med disse widgets, forbliver på engelsk.

Denne forskel er også den grundlæggende årsag til halvdelen af henvendelserne i vores fejlfindingsguide for oversættelser, der ikke vises – læseren forventer, at .mo-filer påvirker indhold, de ser på front-end, men indholdet er i databasen, ikke i kode.

Hvad .po-filer faktisk dækker på et sidebygger-site

Lad mig trække en klar skillelinje mellem de to, så du ved præcis, hvad hver filtype håndterer.

.po / .mo-filer oversætter

• Temaets skabelonstrenge: get_template_part, hardcoded tekst i header.php, footer.php, functions.php.
• Plugin UI-strenge: WooCommerce-kasse, Yoast-adminetiketter, Contact Form 7-feltetiketter.
• Sidebygger-plugin UI: Elementor-editor-knapper, Divi-gem-bekræftelsesmeddelelser.
• Dynamiske strenge, som plugins ekkoer til front-end: WooCommerce "Læg i kurv", "Udsolgt", kurvtotaaler.

.po / .mo-filer oversætter IKKE

• Overskrift-, afsnits- og knaptekst indtastet i Elementor-widgets.
• Billedtekster, hover-effekter, harmonika-titler inde i Divi-moduler.
• Indhold i genanvendelige skabeloner, globale sektioner, gemte blokke.
• Brugerdefinerede CSS-etiketter eller inline-scripts inde i bygger-widgets.

Dette er grunden til, at temaforfatteres dokumentation om oversættelse er teknisk korrekt, men ofte ubrugelig for slutbrugere. Vores guide om hvordan man lokaliserer ethvert WordPress-tema dækker temasiden grundigt – dette indlæg tager over, hvor den slutter.

To veje til sidebygger-lokalisering

Der er præcis to måder at oversætte sidebygger-indhold på, og begge har reelle kompromiser.

Vej Én: Dupliker sider pr. sprog

Brug et flersproget plugin som WPML, Polylang eller TranslatePress. Det opretter en kopi af hver side pr. sprog. I Elementor duplikerer du hele layoutet og udskifter teksten på hver kopi. I Divi kopierer du shortcode-blob'en og oversætter teksten mellem tags.

Fordele: Hvert sprog kan have uafhængigt designede layouts (nyttigt, når oversat tekst er længere og ødelægger dit originale design). Fuld kompatibilitet med sidebyggerens visuelle editor.

Ulemper: Lineær skalering – 5 sprog betyder 5x layoutarbejdet. Enhver designændring skal anvendes 5 gange. Databasen vokser hurtigt. Caching bliver sværere.

Vej To: Strengoversættelseslag

Nogle plugins (Polylang Pro, WPML's String Translation-modul, TranslatePress) kan eksponere individuelle strenge inde i sidebygger-widgets til oversættelse og derefter udskifte dem ved renderingstidspunktet. Du vedligeholder ét layout, og plugin'et oversætter strenge på stedet.

Fordele: Én enkelt kilde til sandhed for layout. Designændringer gælder overalt.

Ulemper: Mindre fleksibilitet, når oversat tekst ændrer længde dramatisk. Nogle widgets (komplekse med indlejret indhold, dynamiske lister, formularer) eksponerer ikke strenge rent. Ydeevneomkostninger pr. rendering.

Vores Polylang vs WPML vs TranslatePress-sammenligning dækker de enkelte plugins' kompromiser mere detaljeret.

Sådan holder du widget-markup sikker under oversættelse

Uanset hvilken vej du vælger, skal oversat indhold bevare byggerens strukturelle markup. Hvis din oversætter fjerner en Elementor shortcode, erstatter en data-attribut eller omarrangerer indlejrede tags, vil widget'en blive vist ødelagt.

Elementor farezoner

Elementor-widgets indlejrer shortcodes og dynamiske tags inde i tekstindstillinger. En overskrifts-widgets titelfelt kan indeholde:

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

Den [user_name] er et dynamisk tag – Elementor erstatter det med den loggede brugers navn ved rendering. Hvis oversættelsen forvansker det, får du bogstaveligt "[user_name]" vist til brugerne.

Ikoner inde i knapper bruger klasseattributter, der ikke må oversættes. Billedets alt-tekst gemmes separat fra billedets URL. Kolonnelayouts bruger breakpoint-specifikke indstillinger (title_mobile, title_tablet), der kræver individuel håndtering.

Divi Shortcode-indlejring

Divi shortcodes indlejres dybt: [et_pb_section][et_pb_row][et_pb_column][et_pb_text]. En oversætter, der behandler blob'en som almindelig tekst, vil kode firkantede parenteser, oversætte attributværdier eller miste afsluttende tags. Enhver af disse korrumperer modulet, og Divi nægter at vise det.

Det sikre mønster

For begge byggere skal oversættelsen:

1. Parse widget-formatet (JSON for Elementor, shortcode AST for Divi).
2. Gå gennem træet og identificer kun bruger-synlige tekstfelter.
3. Lås shortcodes, dynamiske tags, HTML-attributter og inline CSS.
4. Send kun tekstfladerne til oversætteren med kontekst.
5. Genindsæt oversat tekst i den originale struktur.

Dette er det samme princip, som vores motor anvender på .po-filer. Guiden til oversættelse af .po-filer uden at ødelægge kodevariabler gennemgår %s- og placeholder-mønstrene i detaljer – sidebyggerens ækvivalent er shortcodes og dynamiske tags.

En hybrid arbejdsgang, der faktisk virker

For de fleste teams er det praktiske svar at kombinere begge tilgange.

Trin 1: Oversæt tema- og plugin-UI via .po-filer

Eksporter .pot-filer fra dit tema og nøgleplugins (WooCommerce, Yoast, sidebygger-UI). Oversæt dem én gang via en cloud-oversætter, der respekterer .po-formatet. Drop kompilerede .mo-filer ind i wp-content/languages/. Dette håndterer 80% af dit sites interface-strenge med næsten nul løbende vedligeholdelse.

Trin 2: Vælg et flersproget plugin til dynamisk indhold

Installer Polylang eller WPML til indlægs-, side- og produktindhold. Konfigurer URL-struktur (/es/, /fr/) og hreflang-tags. Dette giver dig infrastrukturen til databaseret indhold pr. sprog.

Trin 3: Dupliker dine sidebygger-skabeloner selektivt

For landingssider med høj trafik, hjemmesider og hjørnestensmarkedsføringsindhold skal du duplikere siden på hvert sprog og oversætte widgets manuelt. Du får fuld designkontrol, hvor det er vigtigt.

Trin 4: Brug strengoversættelse til gentagne blokke

For globale sektioner, genanvendelige skabeloner og footer-CTA'er, der vises på hver side, skal du bruge dit flersprogede plugins strengoversættelsesfunktion. Opdater ét sted, udskift ved rendering.

Trin 5: Kør kvalitetskontrol

Oversat sidebygger-indhold skal gengives uden layoutændringer. Længere sprog (tysk, russisk) bryder knapbredder. Kortere sprog (kinesisk, japansk) efterlader akavet mellemrum. Test hver skabelon pr. sprog før udgivelse.

Almindelige faldgruber og hvordan man undgår dem

Et par faldgruber, der dukker op i ethvert sidebygger-lokaliseringsprojekt.

Billedets alt-tekst oversættes ikke

Både Elementor og Divi gemmer alt-tekst pr. widget-instans, ikke i mediebiblioteket. Oversættelse af det originale billede oversætter ikke alt-tekst i hver widget, der bruger det. Opdater alt-tekst på hver duplikerede side.

Formularer og brugerdefinerede felter

Kontaktformularer indlejret i sidebygger-widgets har deres egne strenge (etiketter, pladsholdere, valideringsmeddelelser). Se vores guide til oversættelse af Gravity Forms og Contact Form 7 for formular-siden.

Globale widgets og skabeloner

Ændringer i en global skabelon overføres til hver side, der bruger den, inklusive oversatte kopier. Dette kan være nyttigt eller katastrofalt, afhængigt af om du ønsker delt eller separat indhold. Beslut eksplicit pr. skabelon.

Udløb af oversættelsescache

Sidebyggere cache'er gengivet HTML aggressivt. Efter oversættelse skal du tømme alle caches, inklusive Elementor CSS-cache (Elementor > Værktøjer > Regenerer CSS) og Divi statisk CSS-cache.

Opsummering

At oversætte et site bygget med Elementor eller Divi er ikke sværere end at oversætte et statisk tema – det kræver blot den rette mentale model. Tema- og plugin-strenge lever i .po-filer og transporteres via .mo-filer. Sidebygger-indhold lever i databasen og transporteres via flersprogede plugins eller manuel duplikering. At forveksle de to veje er den mest almindelige kilde til frustration over "hvorfor virker mine oversættelser ikke".

Den arbejdsgang, der virker bedst, er kedelig: statiske .mo-filer til alt, der lever i kode, flersproget plugin til sideindhold og manuel kuratering til landingssider af høj værdi. Intet enkelt værktøj håndterer alle tre, og enhver, der lover dig andet, sælger dig noget.

Klar til at oversætte dine tema- og plugin .po-filer uden at ødelægge widget-markup? Prøv SimplePoTranslate gratis – intet kreditkort påkrævet. Upload .po, download sikre oversættelser, læg dem i wp-content/languages/.