Översätt Elementor & Divi-mallar utan att förstöra layouter

Du gjorde allt rätt. Du köpte ett premiumtema, hittade .po-filen, översatte den noggrant och laddade upp .mo-filen till din språkmapp. Strängar i temaheadern uppdateras korrekt. Sidfoten visas på spanska. Din WooCommerce-kassa är lokaliserad. Men sedan öppnar du hemsidan och varenda rubrik, knapp och textblock som byggts med Elementor är fortfarande på engelska.

Du kontrollerar .po-filen. Du kan se de engelska strängarna i koden. Du översätter igen. Inget ändras. Du tömmer cacheminnen. Inget ändras. Du övertygar dig själv om att något är trasigt tills någon på ett forum försiktigt påpekar: Elementor (och Divi, och Beaver Builder, och Bricks) lagrar inte innehåll i .po-filer. Det har de aldrig gjort. Du har kämpat med ett problem som inte kan lösas med den metod du använder.

Denna guide förklarar varför sidbyggarinnehåll är arkitektoniskt annorlunda från tema- och plugininnehåll, de två vägarna för att översätta det, och hur du håller widgetens markering intakt under översättning så att dina noggrant designade layouter inte faller isär.

Varför Elementor och Divi inte använder .po-filer

.po-filer lagrar strängar som finns i koden – __( 'Shop', 'mytheme' )-anrop spridda över PHP-mallar. Byggverktyget WP-CLI kan extrahera dessa strängar till en .pot-mall, översättare arbetar med .po-filer, och kompilerade .mo-filer laddas vid körning.

Sidbyggarinnehåll är annorlunda. När du skriver "Välkommen till vår butik" i en Elementor-rubrikwidget, finns den texten inte i någon PHP-fil. Den sparas som JSON (Elementor) eller en shortcode-blob (Divi) i wp_postmeta-tabellen, associerad med inlägget där du placerade den.

Var sidbyggarinnehåll faktiskt lagras

Elementor lagrar varje sidas widgetträd i postmeta under nyckeln _elementor_data. Öppna vilket inlägg som helst i databasen och du hittar en JSON-array som beskriver varje sektion, kolumn och widget, med inställningar och innehåll inbäddat:

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

Divi lagrar sitt sidinnehåll som shortcodes inbäddade 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 och Oxygen följer samma mönster med sina egna format. Inget av detta innehåll påverkas någonsin av .po / .mo-filer.

Vad som faktiskt finns i .po-filer

Sidbyggar-pluginet i sig har UI-strängar – knappetiketter i redigeraren, felmeddelanden, adminmeddelanden. Dessa finns i .po-filer och översätts av dina .mo-filer i wp-content/languages/plugins/. Detta är vanligtvis anledningen till att människor blir förvirrade: de översätter "Elementor"-strängar och ser redigerarens UI på spanska, men det faktiska innehållet de byggt med dessa widgets förblir på engelska.

Denna distinktion är också grundorsaken till hälften av ärendena i vår felsökningsguide för översättningar som inte visas – läsaren förväntar sig att .mo-filer ska påverka innehåll de ser på frontend, men innehållet finns i databasen, inte i koden.

Vad .po-filer faktiskt täcker på en sidbyggar-sajt

Låt mig dra en tydlig gräns mellan de två så att du vet exakt vad varje filtyp hanterar.

.po / .mo-filer översätter

• Temats mallsträngar: get_template_part, hårdkodad text i header.php, footer.php, functions.php.
• Plugin UI-strängar: WooCommerce kassa, Yoast adminetiketter, Contact Form 7 fältetiketter.
• Sidbyggar-pluginets UI: Elementor redigeringsknappar, Divi sparbekräftelsemeddelanden.
• Dynamiska strängar som plugins ekar till frontend: WooCommerce "Lägg i varukorg", "Slut i lager", varukorgens totalsummor.

.po / .mo-filer översätter INTE

• Rubrik-, stycke-, knapptext inskriven i Elementor-widgets.
• Bildtexter, hovringseffekter, dragspelstitlar inuti Divi-moduler.
• Innehåll i återanvändbara mallar, globala sektioner, sparade block.
• Anpassade CSS-etiketter eller inline-skript inuti byggar-widgets.

Detta är anledningen till att temaförfattares dokumentation om översättning är tekniskt korrekt men ofta värdelös för slutanvändare. Vår guide om hur man lokaliserar vilket WordPress-tema som helst täcker temasidan grundligt – detta inlägg tar vid där den slutar.

Två vägar för sidbyggar-lokalisering

Det finns exakt två sätt att översätta sidbyggarinnehåll, och båda har verkliga kompromisser.

Väg ett: Duplicera sidor per språk

Använd ett flerspråkigt plugin som WPML, Polylang eller TranslatePress. Det skapar en kopia av varje sida per språk. I Elementor duplicerar du hela layouten och byter texten på varje kopia. I Divi kopierar du shortcode-blobben och översätter texten mellan taggar.

Fördelar: Varje språk kan ha oberoende designade layouter (användbart när översatt text är längre och bryter din ursprungliga design). Full kompatibilitet med sidbyggarens visuella redigerare.

Nackdelar: Linjär skalning – 5 språk innebär 5 gånger mer layoutarbete. Alla designförändringar måste tillämpas 5 gånger. Databasen växer snabbt. Cachelagring blir svårare.

Väg två: Strängöversättningslager

Vissa plugins (Polylang Pro, WPML:s String Translation-modul, TranslatePress) kan exponera enskilda strängar inuti sidbyggar-widgets för översättning och sedan byta ut dem vid rendrering. Du behåller en layout och pluginet översätter strängar på plats.

Fördelar: Enkel källa till sanning för layout. Designändringar tillämpas överallt.

Nackdelar: Lägre flexibilitet när översatt text ändrar längd dramatiskt. Vissa widgets (komplexa med kapslat innehåll, dynamiska listor, formulär) exponerar inte strängar rent. Prestandakostnad per rendrering.

Vår jämförelse av Polylang, WPML och TranslatePress täcker kompromisserna för varje plugin mer i detalj.

Att hålla widgetens markering säker under översättning

Oavsett vilken väg du väljer måste översatt innehåll bevara byggarens strukturella markering. Om din översättare tar bort en Elementor-shortcode, ersätter ett dataattribut eller omorganiserar kapslade taggar, kommer widgeten att rendreras felaktigt.

Elementors riskzoner

Elementor-widgets bäddar in shortcodes och dynamiska taggar i textinställningar. En rubrikwidgets titelfält kan innehålla:

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

Den där [user_name] är en dynamisk tagg – Elementor ersätter den med den inloggade användarens namn vid rendrering. Om översättningen förstör den, får användare se den bokstavliga "[user_name]".

Ikoner inuti knappar använder klassattribut som inte får översättas. Bildens alt-text lagras separat från bildens URL. Kolumnlayouter använder brytpunktsspecifika inställningar (title_mobile, title_tablet) som behöver individuell hantering.

Divis kapslade Shortcodes

Divi shortcodes kapslas djupt: [et_pb_section][et_pb_row][et_pb_column][et_pb_text]. En översättare som behandlar blobben som ren text kommer att koda hakparenteser, översätta attributvärden eller förlora avslutande taggar. Något av detta korrumperar modulen och Divi vägrar att rendrera den.

Det säkra mönstret

För båda byggarna måste översättningen:

1. Parsa widgetformatet (JSON för Elementor, shortcode AST för Divi).
2. Gå igenom trädet och identifiera endast användarsynliga textfält.
3. Lås shortcodes, dynamiska taggar, HTML-attribut och inline CSS.
4. Skicka endast textytorna till översättaren med kontext.
5. Återinfoga översatt text i den ursprungliga strukturen.

Detta är samma princip som vår motor tillämpar på .po-filer. Guiden för att översätta .po-filer utan att bryta kodvariabler går igenom %s och platshållarmönster i detalj – sidbyggarens motsvarighet är shortcodes och dynamiska taggar.

Ett hybridarbetsflöde som faktiskt fungerar

För de flesta team är den praktiska lösningen att kombinera båda tillvägagångssätten.

Steg 1: Översätt tema- och plugin-UI via .po-filer

Exportera .pot-filer från ditt tema och viktiga plugins (WooCommerce, Yoast, sidbyggar-UI). Översätt dem en gång via en molnöversättare som respekterar .po-formatet. Släpp de kompilerade .mo-filerna i wp-content/languages/. Detta hanterar 80% av din webbplats gränssnittssträngar med nära noll löpande underhåll.

Steg 2: Välj ett flerspråkigt plugin för dynamiskt innehåll

Installera Polylang eller WPML för inläggs-, sid- och produktinnehåll. Konfigurera URL-struktur (/es/, /fr/) och hreflang-taggar. Detta ger dig infrastrukturen för databasinnehåll per språk.

Steg 3: Duplicera dina sidbyggarmallar selektivt

För landningssidor med hög trafik, startsidor och hörnstenar för marknadsföringsinnehåll, duplicera sidan på varje språk och översätt widgets manuellt. Du får full designkontroll där det är viktigt.

Steg 4: Använd strängöversättning för upprepade block

För globala sektioner, återanvändbara mallar och CTA:er i sidfoten som visas på varje sida, använd ditt flerspråkiga plugins strängöversättningsfunktion. Uppdatera på ett ställe, byt vid rendrering.

Steg 5: Utför kvalitetskontroller

Översatt sidbyggarinnehåll bör rendreras utan layoutförskjutningar. Längre språk (tyska, ryska) kan bryta knappbredder. Kortare språk (kinesiska, japanska) lämnar obekvämt tomrum. Testa varje mall per språk innan publicering.

Vanliga fallgropar och hur man undviker dem

Några fällor som dyker upp i varje lokaliseringsprojekt för sidbyggare.

Bildens alt-text översätts inte

Både Elementor och Divi lagrar alt-text per widgetinstans, inte i mediebiblioteket. Att översätta originalbilden översätter inte alt-texten i varje widget som använder den. Uppdatera alt-texten på varje duplicerad sida.

Formulär och anpassade fält

Kontaktformulär inbäddade i sidbyggar-widgets har sina egna strängar (etiketter, platshållare, valideringsmeddelanden). Se vår guide för att översätta Gravity Forms och Contact Form 7 för formulärsidan.

Globala widgets och mallar

Ändringar i en global mall sprids till varje sida som använder den, inklusive översatta kopior. Detta kan vara användbart eller katastrofalt beroende på om du vill ha delat eller separat innehåll. Bestäm explicit per mall.

Utgång av översättningscache

Sidbyggare cachelagrar rendrerad HTML aggressivt. Efter översättning, rensa alla cacheminnen inklusive Elementor CSS-cache (Elementor > Tools > Regenerate CSS) och Divi statiska CSS-cache.

Att sammanfatta

Att översätta en webbplats byggd med Elementor eller Divi är inte svårare än att översätta ett statiskt tema – det kräver bara rätt mental modell. Tema- och pluginsträngar finns i .po-filer och distribueras via .mo-filer. Sidbyggarinnehåll finns i databasen och distribueras via flerspråkiga plugins eller manuell duplicering. Att blanda ihop de två vägarna är den vanligaste källan till frustrationen "varför fungerar inte mina översättningar".

Arbetsflödet som vinner är tråkigt: statiska .mo-filer för allt som finns i koden, flerspråkigt plugin för sidinnehåll, och manuell kurering för värdefulla landningssidor. Inget enskilt verktyg hanterar alla tre, och den som lovar dig annat säljer dig något.

Redo att översätta dina tema- och plugin-.po-filer utan att bryta widgetens markering? Prova SimplePoTranslate gratis – inget kreditkort krävs. Ladda upp .po, ladda ner säkra översättningar, släpp in i wp-content/languages/.