Traduceți șabloanele Elementor & Divi fără a strica structura

Ați făcut totul corect. Ați cumpărat o temă premium, ați găsit fișierul .po, l-ați tradus cu atenție și ați încărcat fișierul .mo în folderul dumneavoastră de limbi. String-urile din antetul temei se actualizează corect. Subsolul este afișat în spaniolă. Pagina de finalizare a comenzii WooCommerce este localizată. Dar apoi deschideți pagina principală și fiecare titlu, buton și bloc de text construit cu Elementor este încă în engleză.

Verificați fișierul .po. Puteți vedea string-urile în engleză în cod. Retraduceți. Nimic nu se schimbă. Goliți cache-urile. Nimic nu se schimbă. Vă convingeți că ceva este stricat până când cineva de pe un forum vă atrage cu blândețe atenția: Elementor (și Divi, și Beaver Builder, și Bricks) nu stochează conținutul în fișiere .po. Nu au făcut-o niciodată. V-ați luptat cu o problemă care nu poate fi rezolvată cu abordarea pe care o utilizați.

Acest ghid explică de ce conținutul unui page builder este diferit din punct de vedere arhitectural de conținutul temelor și plugin-urilor, cele două căi pentru a-l traduce și cum să păstrați structura widget-urilor intactă în timpul traducerii, astfel încât designurile dumneavoastră proiectate cu atenție să nu se destrame.

De ce Elementor și Divi nu folosesc fișiere .po

Fișierele .po stochează string-uri care se află în cod - apeluri precum __( 'Shop', 'mytheme' ) răspândite în șabloanele PHP. Instrumentul de construire WP-CLI poate extrage aceste string-uri într-un șablon .pot, traducătorii lucrează pe fișiere .po, iar fișierele .mo compilate sunt încărcate la rulare.

Conținutul page builder-ului este diferit. Când tastați „Welcome to our store” într-un widget de titlu Elementor, acel text nu se află în niciun fișier PHP. Acesta este salvat ca JSON (Elementor) sau ca un blob de shortcode (Divi) în tabelul wp_postmeta, asociat cu postarea unde l-ați plasat.

Unde se află de fapt conținutul Page Builder-ului

Elementor stochează arborele de widget-uri al fiecărei pagini în postmeta sub cheia _elementor_data. Deschideți orice postare din baza de date și veți găsi un array JSON care descrie fiecare secțiune, coloană și widget, cu setări și conținut inline:

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

Divi stochează conținutul paginii ca shortcode-uri încorporate în 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 și Oxygen urmează același model cu propriul lor format. Niciunul dintre acest conținut nu este vreodată afectat de fișierele .po / .mo.

Ce se află de fapt în fișierele .po

Plugin-ul page builder în sine are string-uri de interfață - etichete de butoane în editor, mesaje de eroare, notificări de administrare. Acestea se află în fișiere .po și sunt traduse de fișierele dumneavoastră .mo din wp-content/languages/plugins/. Acesta este de obicei motivul pentru care oamenii devin confuzi: ei traduc string-uri „Elementor” și văd interfața editorului în spaniolă, dar conținutul real pe care l-au construit cu acele widget-uri rămâne în engleză.

Această distincție este, de asemenea, cauza principală a jumătate din solicitările din ghidul nostru de depanare pentru traducerile care nu apar – cititorul se așteaptă ca fișierele .mo să afecteze conținutul pe care îl vede pe front-end, dar conținutul este în baza de date, nu în cod.

Ce acoperă de fapt fișierele .po pe un site cu Page Builder

Permiteți-mi să trasez o linie clară între cele două, astfel încât să știți exact ce gestionează fiecare tip de fișier.

Fișierele .po / .mo traduc

• String-urile șabloanelor temei: get_template_part, text codat direct în header.php, footer.php, functions.php.
• String-urile de interfață ale plugin-urilor: pagina de finalizare a comenzii WooCommerce, etichetele de administrare Yoast, etichetele câmpurilor Contact Form 7.
• Interfața plugin-ului page builder: butoanele editorului Elementor, mesajele de confirmare de salvare Divi.
• String-uri dinamice pe care plugin-urile le afișează în front-end: WooCommerce „Adaugă în coș”, „Stoc epuizat”, totaluri coș.

Fișierele .po / .mo NU traduc

• Textul de titlu, paragraf, buton introdus în widget-urile Elementor.
• Legendele imaginilor, efectele de hover, titlurile de acordeon din modulele Divi.
• Conținutul din șabloanele reutilizabile, secțiunile globale, blocurile salvate.
• Etichetele CSS personalizate sau scripturile inline din widget-urile builder-ului.

Acesta este motivul pentru care documentația autorilor de teme despre traducere este tehnic corectă, dar adesea inutilă pentru utilizatorii finali. Ghidul nostru despre cum să localizați orice temă WordPress acoperă în detaliu partea temei – această postare continuă de unde se termină acel ghid.

Două căi pentru localizarea conținutului Page Builder-ului

Există exact două moduri de a traduce conținutul unui page builder, și ambele vin cu compromisuri reale.

Calea Unu: Duplicarea Paginilor pentru Fiecare Limbă

Utilizați un plugin multilingv precum WPML, Polylang sau TranslatePress. Acesta creează o copie a fiecărei pagini pentru fiecare limbă. În Elementor, duplicați întregul layout și schimbați textul pe fiecare copie. În Divi, copiați blob-ul de shortcode și traduceți textul dintre tag-uri.

Avantaje: Fiecare limbă poate avea layout-uri proiectate independent (util când textul tradus este mai lung și strică designul original). Compatibilitate deplină cu editorul vizual al page builder-ului.

Dezavantaje: Scalare liniară – 5 limbi înseamnă de 5 ori mai multă muncă de design. Orice modificare de design trebuie aplicată de 5 ori. Baza de date crește rapid. Caching-ul devine mai dificil.

Calea Doi: Strat de Traducere a String-urilor

Unele plugin-uri (Polylang Pro, modulul String Translation de la WPML, TranslatePress) pot expune string-uri individuale din interiorul widget-urilor page builder-ului pentru traducere, apoi le pot înlocui la momentul randării. Mențineți un singur layout, iar plugin-ul traduce string-urile pe loc.

Avantaje: O singură sursă de adevăr pentru layout. Modificările de design se aplică peste tot.

Dezavantaje: Flexibilitate mai scăzută atunci când textul tradus își schimbă drastic lungimea. Unele widget-uri (complexe, cu conținut imbricat, liste dinamice, formulare) nu expun string-urile curat. Cost de performanță la fiecare randare.

Comparația noastră Polylang vs WPML vs TranslatePress acoperă în detaliu compromisurile fiecărui plugin.

Păstrarea Structurii Widget-urilor în Siguranță în Timpul Traducerii

Indiferent de calea pe care o alegeți, conținutul tradus trebuie să păstreze structura constructorului. Dacă traducătorul dumneavoastră elimină un shortcode Elementor, înlocuiește un atribut de date sau reorganizează tag-urile imbricate, widget-ul se va randa greșit.

Zonele de Pericol Elementor

Widget-urile Elementor încorporează shortcode-uri și tag-uri dinamice în setările de text. Câmpul de titlu al unui widget de titlu poate conține:

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

Acel [user_name] este un tag dinamic – Elementor îl înlocuiește cu numele utilizatorului autentificat la randare. Dacă traducerea îl alterează, utilizatorii vor vedea literal „[user_name]”.

Iconițele din interiorul butoanelor folosesc atribute de clasă care nu trebuie traduse. Textul alternativ al imaginii este stocat separat de URL-ul imaginii. Layout-urile pe coloane utilizează setări specifice punctelor de întrerupere (title_mobile, title_tablet) care necesită o gestionare individuală.

Imbricarea Shortcode-urilor Divi

Shortcode-urile Divi se imbrică profund: [et_pb_section][et_pb_row][et_pb_column][et_pb_text]. Un traducător care tratează blob-ul ca text simplu va codifica parantezele pătrate, va traduce valorile atributelor sau va pierde tag-urile de închidere. Oricare dintre acestea corupe modulul și Divi refuză să-l randeze.

Modelul Sigur

Pentru oricare builder, traducerea trebuie să:

1. Analizeze formatul widget-ului (JSON pentru Elementor, AST shortcode pentru Divi).
2. Parcurgă arborele, identificând doar câmpurile de text vizibile pentru utilizator.
3. Blocheze shortcode-urile, tag-urile dinamice, atributele HTML și CSS-ul inline.
4. Trimită traducătorului doar suprafețele de text cu context.
5. Reintroducă textul tradus în structura originală.

Acesta este același principiu pe care motorul nostru îl aplică fișierelor .po. Ghidul de traducere a fișierelor .po fără a strica variabilele de cod detaliază modelele %s și placeholder – echivalentul pentru page builder sunt shortcode-urile și tag-urile dinamice.

Un Flux de Lucru Hibrid care Funcționează Real

Pentru majoritatea echipelor, răspunsul practic este combinarea ambelor abordări.

Pasul 1: Traduceți Interfața Temei și a Plugin-urilor prin Fișiere .po

Exportați fișierele .pot din tema și plugin-urile cheie (WooCommerce, Yoast, interfața page builder-ului). Traduceți-le o singură dată printr-un traducător cloud care respectă formatul .po. Plasați fișierele .mo compilate în wp-content/languages/. Aceasta gestionează 80% din string-urile interfeței site-ului dumneavoastră cu costuri de întreținere aproape zero.

Pasul 2: Alegeți un Plugin Multilingv pentru Conținut Dinamic

Instalați Polylang sau WPML pentru conținutul de postări, pagini și produse. Configurați structura URL (/es/, /fr/) și tag-urile hreflang. Aceasta vă oferă infrastructura pentru conținutul bazei de date pe limbă.

Pasul 3: Duplicați Selectiv Șabloanele Page Builder-ului

Pentru paginile de destinație cu trafic ridicat, paginile principale și conținutul de marketing esențial, duplicați pagina în fiecare limbă și traduceți widget-urile manual. Obțineți control deplin asupra designului acolo unde contează.

Pasul 4: Utilizați Traducerea String-urilor pentru Blocuri Repetate

Pentru secțiunile globale, șabloanele reutilizabile și CTA-urile din subsol care apar pe fiecare pagină, utilizați funcția de traducere a string-urilor a plugin-ului dumneavoastră multilingv. Actualizați într-un singur loc, înlocuiți la randare.

Pasul 5: Efectuați Verificări de Calitate

Conținutul page builder-ului tradus ar trebui să se randeze fără modificări de layout. Limbile mai lungi (germană, rusă) pot modifica lățimea butoanelor. Limbile mai scurte (chineză, japoneză) pot lăsa spații albe inestetice. Testați fiecare șablon pentru fiecare limbă înainte de lansare.

Capcane Comune și Cum să le Evitați

Câteva capcane care apar în fiecare proiect de localizare a unui page builder.

Textul Alt al Imaginii Nu se Traduce

Atât Elementor, cât și Divi stochează textul alt per instanță de widget, nu în Biblioteca Media. Traducerea imaginii originale nu traduce textul alt în fiecare widget care o utilizează. Actualizați textul alt în fiecare pagină duplicată.

Formulare și Câmpuri Personalizate

Formularele de contact încorporate în widget-urile page builder-ului au propriile lor string-uri (etichete, placeholder-uri, mesaje de validare). Consultați ghidul nostru despre traducerea Gravity Forms și Contact Form 7 pentru partea de formulare.

Widget-uri și Șabloane Globale

Modificările aduse unui șablon global se propagă la fiecare pagină care îl utilizează, inclusiv la copiile traduse. Acest lucru poate fi util sau catastrofal, în funcție de dacă doriți conținut partajat sau separat. Decideți explicit pentru fiecare șablon.

Expirarea Cache-ului de Traducere

Page builder-ele cache-uiesc agresiv HTML-ul randat. După traducere, goliți toate cache-urile, inclusiv cache-ul CSS Elementor (Elementor > Tools > Regenerate CSS) și cache-ul CSS static Divi.

Punând Totul Cap la Cap

Traducerea unui site construit cu Elementor sau Divi nu este mai dificilă decât traducerea unei teme statice – necesită doar modelul mental corect. String-urile temelor și plugin-urilor se află în fișiere .po și circulă prin fișiere .mo. Conținutul page builder-ului se află în baza de date și circulă prin plugin-uri multilingve sau duplicare manuală. Amestecarea celor două căi este cea mai comună sursă de frustrare „de ce nu funcționează traducerile mele”.

Fluxul de lucru care funcționează este plictisitor: fișiere .mo statice pentru tot ce se află în cod, plugin multilingv pentru conținutul paginilor și curatare manuală pentru paginile de destinație de mare valoare. Niciun instrument unic nu le gestionează pe toate trei, iar oricine vă promite altceva vă vinde ceva.

Sunteți gata să traduceți fișierele .po ale temei și plugin-urilor dumneavoastră fără a strica structura widget-urilor? Încercați SimplePoTranslate gratuit – nu este necesar un card de credit. Încărcați .po, descărcați traducerile sigure, plasați-le în wp-content/languages/.