Tłumaczenie szablonów Elementor i Divi bez psucia układów

Zrobiłeś wszystko jak należy. Kupiłeś motyw premium, znalazłeś plik .po, starannie go przetłumaczyłeś i przesłałeś plik .mo do folderu języków. Napisy w nagłówku motywu aktualizują się poprawnie. Stopka wyświetla się po hiszpańsku. Twoja kasa WooCommerce jest zlokalizowana. Ale potem otwierasz stronę główną, a każdy nagłówek, przycisk i blok tekstowy zbudowany za pomocą Elementora nadal jest po angielsku.

Sprawdzasz plik .po. Widzisz angielskie ciągi znaków w kodzie. Przetłumaczasz ponownie. Nic się nie zmienia. Czyścisz pamięć podręczną. Nic się nie zmienia. Przekonujesz się, że coś jest zepsute, dopóki ktoś na forum delikatnie nie wskaże: Elementor (i Divi, i Beaver Builder, i Bricks) nie przechowują treści w plikach .po. Nigdy tego nie robiły. Walczyłeś z problemem, którego nie da się rozwiązać, stosując wybrane podejście.

Ten przewodnik wyjaśnia, dlaczego zawartość kreatorów stron różni się architektonicznie od treści motywów i wtyczek, przedstawia dwie ścieżki jej tłumaczenia oraz pokazuje, jak zachować nienaruszony kod znaczników widżetów podczas tłumaczenia, aby Twoje starannie zaprojektowane układy nie rozpadły się.

Dlaczego Elementor i Divi nie używają plików .po

Pliki .po przechowują ciągi znaków, które znajdują się w kodzie – wywołania __( 'Shop', 'mytheme' ) rozproszone po szablonach PHP. Narzędzie do kompilacji WP-CLI może wyodrębnić te ciągi do szablonu .pot, tłumacze pracują na plikach .po, a skompilowane pliki .mo są ładowane w czasie wykonywania.

Zawartość kreatorów stron jest inna. Kiedy wpisujesz „Welcome to our store” do widżetu nagłówka Elementora, ten tekst nie znajduje się w żadnym pliku PHP. Zostaje zapisany jako JSON (Elementor) lub blok shortcode'ów (Divi) w tabeli wp_postmeta, powiązany z wpisem, w którym go umieściłeś.

Gdzie faktycznie znajduje się zawartość kreatorów stron

Elementor przechowuje drzewo widżetów każdej strony w postmeta pod kluczem _elementor_data. Otwórz dowolny wpis w bazie danych, a znajdziesz tablicę JSON opisującą każdą sekcję, kolumnę i widżet, z ustawieniami i zawartością w wierszu:

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

Divi przechowuje zawartość swoich stron jako shortcode'y osadzone w 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 stosują ten sam wzorzec z własnym formatem. Żadna z tych treści nigdy nie jest modyfikowana przez pliki .po / .mo.

Co faktycznie znajduje się w plikach .po

Sama wtyczka kreatora stron ma ciągi znaków interfejsu użytkownika – etykiety przycisków w edytorze, komunikaty o błędach, powiadomienia administracyjne. Te znajdują się w plikach .po i są tłumaczone przez Twoje pliki .mo w wp-content/languages/plugins/. Zazwyczaj to właśnie z tego powodu ludzie się mylą: tłumaczą ciągi znaków „Elementor” i widzą interfejs edytora po hiszpańsku, ale rzeczywista treść, którą zbudowali za pomocą tych widżetów, pozostaje po angielsku.

To rozróżnienie jest również główną przyczyną połowy zgłoszeń w naszym przewodniku rozwiązywania problemów z nieznikającymi tłumaczeniami – czytelnik oczekuje, że pliki .mo wpłyną na treści widoczne na stronie, ale treści te znajdują się w bazie danych, a nie w kodzie.

Co faktycznie obejmują pliki .po na stronie zbudowanej kreatorem stron

Pozwól mi nakreślić wyraźną granicę między tymi dwoma, abyś dokładnie wiedział, co obsługuje każdy typ pliku.

Pliki .po / .mo tłumaczą

• Ciągi znaków szablonu motywu: get_template_part, na stałe zakodowany tekst w header.php, footer.php, functions.php.
• Ciągi znaków interfejsu wtyczek: kasa WooCommerce, etykiety administracyjne Yoast, etykiety pól Contact Form 7.
• Interfejs użytkownika wtyczki kreatora stron: przyciski edytora Elementor, komunikaty potwierdzające zapis Divi.
• Dynamiczne ciągi znaków, które wtyczki wyświetlają na stronie: WooCommerce „Dodaj do koszyka”, „Brak w magazynie”, sumy koszyka.

Pliki .po / .mo NIE tłumaczą

• Nagłówki, akapity, tekst przycisków wprowadzony do widżetów Elementora.
• Podpisy obrazów, efekty najechania myszą, tytuły akordeonów w modułach Divi.
• Treść w szablonach wielokrotnego użytku, sekcjach globalnych, zapisanych blokach.
• Niestandardowe etykiety CSS lub skrypty inline w widżetach kreatora.

Dlatego dokumentacja autorów motywów dotycząca tłumaczenia jest technicznie poprawna, ale często bezużyteczna dla użytkowników końcowych. Nasz przewodnik jak zlokalizować dowolny motyw WordPress, nawet jeśli nie jesteś programistą szczegółowo omawia stronę motywu – ten wpis kontynuuje tam, gdzie tamten się kończy.

Dwie ścieżki lokalizacji kreatorów stron

Istnieją dokładnie dwa sposoby tłumaczenia treści kreatorów stron, a oba wiążą się z rzeczywistymi kompromisami.

Ścieżka pierwsza: Duplikowanie stron dla każdego języka

Użyj wtyczki wielojęzycznej, takiej jak WPML, Polylang lub TranslatePress. Tworzy ona kopię każdej strony dla każdego języka. W Elementorze duplikujesz cały układ i zamieniasz tekst na każdej kopii. W Divi kopiujesz blok shortcode'ów i tłumaczysz tekst między tagami.

Plusy: Każdy język może mieć niezależnie zaprojektowane układy (przydatne, gdy przetłumaczony tekst jest dłuższy i narusza oryginalny projekt). Pełna kompatybilność z wizualnym edytorem kreatora stron.

Minusy: Skalowanie liniowe – 5 języków oznacza 5-krotnie więcej pracy nad układem. Każda zmiana projektu musi być zastosowana 5 razy. Baza danych szybko rośnie. Buforowanie staje się trudniejsze.

Ścieżka druga: Warstwa tłumaczenia ciągów znaków

Niektóre wtyczki (Polylang Pro, moduł tłumaczenia ciągów znaków WPML, TranslatePress) mogą ujawniać pojedyncze ciągi znaków w widżetach kreatorów stron do tłumaczenia, a następnie zamieniać je w czasie renderowania. Utrzymujesz jeden układ, a wtyczka tłumaczy ciągi znaków na miejscu.

Plusy: Jedno źródło prawdy dla układu. Zmiany w projekcie stosują się wszędzie.

Minusy: Mniejsza elastyczność, gdy przetłumaczony tekst drastycznie zmienia długość. Niektóre widżety (złożone, z zagnieżdżoną zawartością, dynamicznymi listami, formularzami) nie ujawniają ciągów znaków w sposób czysty. Koszt wydajności na każde renderowanie.

Nasze porównanie Polylang vs WPML vs TranslatePress szczegółowo omawia kompromisy każdej wtyczki.

Zachowanie bezpieczeństwa znaczników widżetów podczas tłumaczenia

Niezależnie od wybranej ścieżki, przetłumaczona zawartość musi zachować strukturalne znaczniki kreatora. Jeśli tłumacz usunie shortcode Elementora, zastąpi atrybut danych lub zmieni kolejność zagnieżdżonych tagów, widżet zostanie wyświetlony w sposób uszkodzony.

Strefy zagrożenia Elementora

Widżety Elementora osadzają shortcode'y i dynamiczne tagi w ustawieniach tekstowych. Pole tytułu widżetu nagłówka może zawierać:

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

To [user_name] to dynamiczny tag – Elementor zastępuje go nazwą zalogowanego użytkownika podczas renderowania. Jeśli tłumaczenie go zniekształci, użytkownikom zostanie wyświetlone dosłowne „[user_name]”.

Ikony w przyciskach używają atrybutów klas, które nie mogą być tłumaczone. Tekst alternatywny obrazu jest przechowywany oddzielnie od adresu URL obrazu. Układy kolumn używają ustawień specyficznych dla punktów przerwania (title_mobile, title_tablet), które wymagają indywidualnej obsługi.

Zagnieżdżanie shortcode'ów Divi

Shortcode'y Divi są głęboko zagnieżdżone: [et_pb_section][et_pb_row][et_pb_column][et_pb_text]. Tłumacz, który potraktuje ten blok jako zwykły tekst, zakoduje nawiasy kwadratowe, przetłumaczy wartości atrybutów lub zgubi tagi zamykające. Każda z tych czynności uszkodzi moduł i Divi odmówi jego renderowania.

Bezpieczny wzorzec

W przypadku każdego kreatora tłumaczenie musi:

1. Parsować format widżetu (JSON dla Elementora, AST shortcode'ów dla Divi).
2. Przejść przez drzewo, identyfikując tylko pola tekstowe widoczne dla użytkownika.
3. Zablokować shortcode'y, dynamiczne tagi, atrybuty HTML i wbudowany CSS.
4. Wysłać do tłumacza tylko powierzchnie tekstowe z kontekstem.
5. Ponownie wstawić przetłumaczony tekst do oryginalnej struktury.

Jest to ta sama zasada, którą nasz silnik stosuje do plików .po. Przewodnik tłumaczenia plików .po bez uszkadzania zmiennych kodu szczegółowo omawia wzorce %s i placeholderów – odpowiednikiem dla kreatorów stron są shortcode'y i dynamiczne tagi.

Hybrydowy przepływ pracy, który faktycznie działa

Dla większości zespołów praktycznym rozwiązaniem jest połączenie obu podejść.

Krok 1: Tłumaczenie interfejsu motywu i wtyczek za pomocą plików .po

Wyeksportuj pliki .pot z motywu i kluczowych wtyczek (WooCommerce, Yoast, interfejs kreatora stron). Przetłumacz je raz za pomocą tłumacza chmurowego, który respektuje format .po. Umieść skompilowane pliki .mo w wp-content/languages/. To obsłuży 80% ciągów znaków interfejsu Twojej strony z niemal zerowymi bieżącymi kosztami utrzymania.

Krok 2: Wybór wtyczki wielojęzycznej dla dynamicznej zawartości

Zainstaluj Polylang lub WPML dla treści wpisów, stron i produktów. Skonfiguruj strukturę URL (/es/, /fr/) i tagi hreflang. Zapewnia to infrastrukturę dla treści bazy danych dla każdego języka.

Krok 3: Selektywne duplikowanie szablonów kreatora stron

W przypadku landing page'ów o dużym ruchu, stron głównych i kluczowych treści marketingowych, zduplikuj stronę w każdym języku i ręcznie przetłumacz widżety. Otrzymujesz pełną kontrolę nad projektem tam, gdzie ma to znaczenie.

Krok 4: Użycie tłumaczenia ciągów znaków dla powtarzających się bloków

W przypadku sekcji globalnych, szablonów wielokrotnego użytku i CTA w stopce, które pojawiają się na każdej stronie, użyj funkcji tłumaczenia ciągów znaków swojej wtyczki wielojęzycznej. Zaktualizuj w jednym miejscu, zamień podczas renderowania.

Krok 5: Przeprowadź kontrolę jakości

Przetłumaczona zawartość kreatora stron powinna renderować się bez zmian układu. Dłuższe języki (niemiecki, rosyjski) mogą zmieniać szerokość przycisków. Krótsze języki (chiński, japoński) pozostawiają nieporęczne białe miejsca. Przed wdrożeniem przetestuj każdy szablon dla każdego języka.

Typowe pułapki i jak ich unikać

Kilka pułapek, które pojawiają się w każdym projekcie lokalizacji kreatora stron.

Brak tłumaczenia tekstu alternatywnego obrazu

Zarówno Elementor, jak i Divi przechowują tekst alternatywny dla każdej instancji widżetu, a nie w Bibliotece Mediów. Tłumaczenie oryginalnego obrazu nie tłumaczy tekstu alternatywnego w każdym widżecie, który go używa. Zaktualizuj tekst alternatywny na każdej zduplikowanej stronie.

Formularze i pola niestandardowe

Formularze kontaktowe osadzone w widżetach kreatora stron mają swoje własne ciągi znaków (etykiety, pola wypełnienia, komunikaty walidacyjne). Zobacz nasz przewodnik dotyczący tłumaczenia Gravity Forms i Contact Form 7 dla strony formularzy.

Widżety i szablony globalne

Zmiany w szablonie globalnym propagują się na każdą stronę, która go używa, włączając w to przetłumaczone kopie. Może to być przydatne lub katastrofalne, w zależności od tego, czy chcesz współdzielonej, czy oddzielnej zawartości. Decyduj o tym wyraźnie dla każdego szablonu.

Wygaśnięcie pamięci podręcznej tłumaczenia

Kreatory stron agresywnie buforują renderowany HTML. Po przetłumaczeniu wyczyść wszystkie pamięci podręczne, w tym pamięć podręczną CSS Elementora (Elementor > Narzędzia > Regeneruj CSS) i statyczną pamięć podręczną CSS Divi.

Podsumowanie

Tłumaczenie strony zbudowanej za pomocą Elementora lub Divi nie jest trudniejsze niż tłumaczenie statycznego motywu – wymaga jedynie odpowiedniego modelu myślowego. Ciągi znaków motywów i wtyczek znajdują się w plikach .po i są przesyłane za pośrednictwem plików .mo. Zawartość kreatorów stron znajduje się w bazie danych i jest przesyłana za pośrednictwem wtyczek wielojęzycznych lub ręcznego duplikowania. Mieszanie tych dwóch ścieżek jest najczęstszym źródłem frustracji „dlaczego moje tłumaczenia nie działają”.

Skuteczny przepływ pracy jest nudny: statyczne pliki .mo dla wszystkiego, co znajduje się w kodzie, wtyczka wielojęzyczna dla zawartości stron i ręczne zarządzanie dla wartościowych landing page'ów. Żadne pojedyncze narzędzie nie obsługuje wszystkich trzech, a każdy, kto obiecuje coś innego, próbuje Ci coś sprzedać.

Gotów przetłumaczyć pliki .po swojego motywu i wtyczek bez uszkadzania znaczników widżetów? Wypróbuj SimplePoTranslate za darmo – karta kredytowa nie jest wymagana. Prześlij .po, pobierz bezpieczne tłumaczenia, umieść w wp-content/languages/.