Elementor ve Divi Şablonlarını Düzenleri Bozmadan Çevirin

Her şeyi doğru yaptınız. Premium bir tema satın aldınız, .po dosyasını buldunuz, dikkatlice çevirdiniz ve .mo dosyasını diller klasörünüze yüklediniz. Tema başlığındaki dizeler doğru bir şekilde güncelleniyor. Alt bilgi İspanyolca okunuyor. WooCommerce ödeme sayfanız yerelleştirildi. Ancak daha sonra ana sayfayı açtığınızda, Elementor ile oluşturulmuş her bir başlık, düğme ve metin bloğu hala İngilizce.

.po dosyasını kontrol edersiniz. Kodda İngilizce dizeleri görebilirsiniz. Yeniden çevirirsiniz. Hiçbir şey değişmez. Önbellekleri temizlersiniz. Hiçbir şey değişmez. Birisi bir forumda nazikçe şunu belirtene kadar bir şeylerin bozuk olduğuna kendinizi inandırırsınız: Elementor (ve Divi, Beaver Builder ve Bricks) içeriği .po dosyalarında depolamaz. Hiçbir zaman depolamadılar. Kullandığınız yaklaşımla çözülemeyecek bir sorunla savaşıyorsunuz.

Bu kılavuz, sayfa oluşturucu içeriğinin tema ve eklenti içeriğinden mimari olarak neden farklı olduğunu, bunu çevirmek için iki yolu ve dikkatlice tasarlanmış düzenlerinizin bozulmaması için çeviri sırasında widget işaretlemesini nasıl sağlam tutacağınızı açıklıyor.

Elementor ve Divi Neden .po Dosyaları Kullanmaz?

.po dosyaları, kodda bulunan dizeleri depolar – PHP şablonlarına dağılmış __( 'Shop', 'mytheme' ) çağrıları gibi. WP-CLI oluşturma aracı bu dizeleri bir .pot şablonuna çıkarabilir, çevirmenler .po dosyaları üzerinde çalışır ve derlenmiş .mo dosyaları çalışma zamanında yüklenir.

Sayfa oluşturucu içeriği farklıdır. Elementor başlık widget'ına "Mağazamıza Hoş Geldiniz" yazdığınızda, bu metin herhangi bir PHP dosyasında değildir. JSON (Elementor) veya bir kısa kod blobu (Divi) olarak wp_postmeta tablosuna, yerleştirdiğiniz gönderiyle ilişkilendirilerek kaydedilir.

Sayfa Oluşturucu İçeriği Gerçekte Nerede Yaşar?

Elementor, her sayfanın widget ağacını postmeta'da _elementor_data anahtarı altında saklar. Veritabanında herhangi bir gönderiyi açtığınızda, ayarlar ve içerik dahil olmak üzere her bölümü, sütunu ve widget'ı açıklayan bir JSON dizisi bulacaksınız:

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

Divi, sayfa içeriğini post_content içine gömülü kısa kodlar olarak saklar:

[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 ve Oxygen kendi formatlarıyla aynı modeli takip eder. Bu içeriğin hiçbiri .po / .mo dosyaları tarafından asla etkilenmez.

.po Dosyalarında Neler Yaşar?

Sayfa oluşturucu eklentisinin kendisi kullanıcı arayüzü dizelerine sahiptir - düzenleyicideki düğme etiketleri, hata mesajları, yönetici bildirimleri. Bunlar .po dosyalarındadır ve wp-content/languages/plugins/ konumundaki .mo dosyalarınız tarafından çevrilir. İnsanların kafasının karışmasının nedeni genellikle budur: "Elementor" dizelerini çevirirler ve düzenleyici arayüzünü İspanyolca görürler, ancak bu widget'larla oluşturdukları gerçek içerik İngilizce kalır.

Bu ayrım, çevirilerin WordPress'te görünmemesi sorun giderme kılavuzumuzdaki biletlerin yarısının da temel nedenidir – okuyucu, .mo dosyalarının ön uçta gördükleri içeriği etkilemesini bekler, ancak içerik kodda değil, veritabanındadır.

Bir Sayfa Oluşturucu Sitesinde .po Dosyaları Gerçekte Neleri Kapsar?

Her dosya türünün neyi işlediğini tam olarak bilmeniz için ikisi arasında net bir çizgi çekmeme izin verin.

.po / .mo dosyaları şunları çevirir:

• Temanın şablon dizeleri: get_template_part, header.php, footer.php, functions.php içindeki sabit kodlanmış metinler.
• Eklenti kullanıcı arayüzü dizeleri: WooCommerce ödeme, Yoast yönetici etiketleri, Contact Form 7 alan etiketleri.
• Sayfa oluşturucu eklenti kullanıcı arayüzü: Elementor düzenleyici düğmeleri, Divi kaydetme onay mesajları.
• Eklentilerin ön uca yansıttığı dinamik dizeler: WooCommerce "Sepete ekle," "Stokta yok," sepet toplamları.

.po / .mo dosyaları şunları ÇEVİRMEZ:

• Elementor widget'larına yazılan başlık, paragraf, düğme metinleri.
• Divi modüllerinin içindeki görsel başlıkları, üzerine gelme efektleri, akordeon başlıkları.
• Yeniden kullanılabilir şablonlar, küresel bölümler, kaydedilmiş bloklardaki içerik.
• Oluşturucu widget'larının içindeki özel CSS etiketleri veya satır içi komut dosyaları.

Tema yazarlarının çeviri hakkındaki belgeleri teknik olarak doğru ancak son kullanıcılar için çoğu zaman işe yaramazdır. Herhangi bir WordPress temasını nasıl yerelleştireceğinizle ilgili kılavuzumuz tema tarafını eksiksiz bir şekilde kapsar – bu gönderi, diğerinin bittiği yerden devam eder.

Sayfa Oluşturucu Yerelleştirmesi için İki Yol

Sayfa oluşturucu içeriğini çevirmenin tam olarak iki yolu vardır ve her ikisinin de gerçek avantajları ve dezavantajları bulunur.

Birinci Yol: Dil Başına Sayfaları Çoğaltma

WPML, Polylang veya TranslatePress gibi çok dilli bir eklenti kullanın. Bu, her sayfanın dil başına bir kopyasını oluşturur. Elementor'da, tüm düzeni çoğaltır ve her kopyadaki metni değiştirirsiniz. Divi'de, kısa kod bloğunu kopyalar ve etiketler arasındaki metni çevirirsiniz.

Artıları: Her dilin bağımsız olarak tasarlanmış düzenleri olabilir (çevrilen metin daha uzun olduğunda ve orijinal tasarımınızı bozduğunda faydalıdır). Sayfa oluşturucunun görsel düzenleyicisiyle tam uyumluluk.

Eksileri: Doğrusal ölçekleme – 5 dil, 5 kat daha fazla düzen çalışması anlamına gelir. Herhangi bir tasarım değişikliğinin 5 kez uygulanması gerekir. Veritabanı hızlı büyür. Önbelleğe alma zorlaşır.

İkinci Yol: Dize Çeviri Katmanı

Bazı eklentiler (Polylang Pro, WPML'in String Translation modülü, TranslatePress) sayfa oluşturucu widget'larının içindeki bireysel dizeleri çeviri için açığa çıkarabilir, ardından bunları oluşturma anında değiştirebilir. Tek bir düzeni korursunuz ve eklenti dizeleri yerinde çevirir.

Artıları: Düzen için tek doğruluk kaynağı. Tasarım değişiklikleri her yere uygulanır.

Eksileri: Çevrilen metnin uzunluğu önemli ölçüde değiştiğinde daha düşük esneklik. Bazı widget'lar (iç içe içerik, dinamik listeler, formlar gibi karmaşık olanlar) dizeleri temiz bir şekilde açığa çıkarmaz. Oluşturma başına performans maliyeti.

Polylang, WPML ve TranslatePress karşılaştırmamız her eklentinin avantajlarını ve dezavantajlarını daha ayrıntılı olarak kapsar.

Çeviri Sırasında Widget İşaretlemesini Güvende Tutmak

Hangi yolu seçerseniz seçin, çevrilmiş içerik oluşturucunun yapısal işaretlemesini korumalıdır. Çevirmeniniz bir Elementor kısa kodunu çıkarırsa, bir veri niteliğini değiştirirse veya iç içe etiketleri yeniden sıralarsa, widget bozuk bir şekilde oluşturulur.

Elementor Tehlike Bölgeleri

Elementor widget'ları, metin ayarlarının içine kısa kodları ve dinamik etiketleri gömer. Bir başlık widget'ının başlık alanı şunları içerebilir:

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

Bu [user_name] dinamik bir etikettir – Elementor bunu oluşturma sırasında oturum açmış kullanıcının adıyla değiştirir. Çeviri onu bozarsa, kullanıcılara tam olarak "[user_name]" görüntülenir.

Düğmelerin içindeki simgeler, çevrilmemesi gereken sınıf nitelikleri kullanır. Görsel alt metni, görsel URL'sinden ayrı olarak saklanır. Sütun düzenleri, bireysel işlem gerektiren kırılma noktasına özel ayarlar (title_mobile, title_tablet) kullanır.

Divi Kısa Kod Yuvalaması

Divi kısa kodları derinlemesine iç içe geçer: [et_pb_section][et_pb_row][et_pb_column][et_pb_text]. Blobu düz metin olarak ele alan bir çevirmen, köşeli parantezleri kodlayacak, nitelik değerlerini çevirecek veya kapanış etiketlerini kaybedecektir. Bunlardan herhangi biri modülü bozar ve Divi onu oluşturmayı reddeder.

Güvenli Desen

Her iki oluşturucu için de çeviri şunları yapmalıdır:

1. Widget formatını ayrıştırın (Elementor için JSON, Divi için kısa kod AST).
2. Yalnızca kullanıcı tarafından görülebilen metin alanlarını tanımlayan ağacı dolaşın.
3. Kısa kodları, dinamik etiketleri, HTML niteliklerini ve satır içi CSS'i kilitleyin.
4. Yalnızca metin yüzeylerini bağlamla birlikte çevirmene gönderin.
5. Çevrilen metni orijinal yapıya yeniden ekleyin.

Bu, motorumuzun .po dosyalarına uyguladığı aynı prensiptir. Kod değişkenlerini bozmadan .po dosyalarını çevirme kılavuzu, %s ve yer tutucu desenlerini ayrıntılı olarak ele alır – sayfa oluşturucu eşdeğeri kısa kodlar ve dinamik etiketlerdir.

Gerçekten Çalışan Hibrit Bir İş Akışı

Çoğu ekip için pratik çözüm, her iki yaklaşımı da birleştirmektir.

Adım 1: Tema ve Eklenti Kullanıcı Arayüzünü .po Dosyaları aracılığıyla Çevirme

Temanızdan ve temel eklentilerden (WooCommerce, Yoast, sayfa oluşturucu UI) .pot dosyalarını dışa aktarın. Bunları .po formatına saygı duyan bir bulut çevirmeni aracılığıyla bir kez çevirin. Derlenmiş .mo dosyalarını wp-content/languages/ içine bırakın. Bu, sitenizin arayüz dizelerinin %80'ini sıfıra yakın sürekli bakımla halleder.

Adım 2: Dinamik İçerik için Çok Dilli Bir Eklenti Seçin

Gönderi, sayfa ve ürün içeriği için Polylang veya WPML'yi kurun. URL yapısını (/es/, /fr/) ve hreflang etiketlerini yapılandırın. Bu size dil başına veritabanı içeriği için altyapıyı sağlar.

Adım 3: Sayfa Oluşturucu Şablonlarınızı Seçici Olarak Çoğaltın

Yüksek trafikli açılış sayfaları, ana sayfalar ve temel pazarlama içeriği için, sayfayı her dilde çoğaltın ve widget'ları manuel olarak çevirin. Önemli yerlerde tam tasarım kontrolü elde edersiniz.

Adım 4: Tekrarlayan Bloklar için Dize Çevirisi Kullanın

Küresel bölümler, yeniden kullanılabilir şablonlar ve her sayfada görünen alt bilgi CTA'ları için çok dilli eklentinizin dize çevirisi özelliğini kullanın. Tek bir yerde güncelleyin, oluşturma anında değiştirin.

Adım 5: Kalite Kontrollerini Çalıştırın

Çevrilen sayfa oluşturucu içeriği, düzen kaymaları olmadan oluşturulmalıdır. Daha uzun diller (Almanca, Rusça) düğme genişliklerini bozar. Daha kısa diller (Çince, Japonca) tuhaf boşluklar bırakır. Göndermeden önce her şablonu dil başına test edin.

Sık Görülen Tuzaklar ve Bunlardan Nasıl Kaçınılır

Her sayfa oluşturucu yerelleştirme projesinde ortaya çıkan birkaç tuzak.

Görsel Alt Metninin Çevrilmemesi

Hem Elementor hem de Divi, alt metnini Medya Kütüphanesinde değil, widget örneği başına saklar. Orijinal görseli çevirmek, onu kullanan her widget'taki alt metnini çevirmez. Her çoğaltılan sayfada alt metni güncelleyin.

Formlar ve Özel Alanlar

Sayfa oluşturucu widget'larına gömülü iletişim formlarının kendi dizeleri vardır (etiketler, yer tutucular, doğrulama mesajları). Form tarafı için Gravity Forms ve Contact Form 7 çevirme kılavuzumuza bakın.

Küresel Widget'lar ve Şablonlar

Küresel bir şablonda yapılan değişiklikler, çevrilmiş kopyalar dahil olmak üzere onu kullanan her sayfaya yayılır. Bu, paylaşılan veya ayrı içerik isteyip istemediğinize bağlı olarak faydalı veya felaket olabilir. Her şablon için açıkça karar verin.

Çeviri Önbellek Süresinin Dolması

Sayfa oluşturucular oluşturulan HTML'yi agresif bir şekilde önbelleğe alır. Çeviri yaptıktan sonra, Elementor CSS önbelleği (Elementor > Araçlar > CSS'i Yeniden Oluştur) ve Divi statik CSS önbelleği dahil tüm önbellekleri temizleyin.

Her Şeyi Bir Araya Getirme

Elementor veya Divi ile oluşturulmuş bir siteyi çevirmek, statik bir temayı çevirmekten daha zor değildir – sadece doğru zihinsel modeli gerektirir. Tema ve eklenti dizeleri .po dosyalarında yaşar ve .mo dosyaları aracılığıyla taşınır. Sayfa oluşturucu içeriği veritabanında yaşar ve çok dilli eklentiler veya manuel çoğaltma aracılığıyla taşınır. Bu iki yolu karıştırmak, "çevirilerim neden çalışmıyor" hayal kırıklığının en yaygın tek kaynağıdır.

Kazanan iş akışı sıkıcıdır: kodda yaşayan her şey için statik .mo dosyaları, sayfa içeriği için çok dilli eklenti ve yüksek değerli açılış sayfaları için manuel düzenleme. Tek bir araç üçünü de halletmez ve size aksini vaat eden herkes size bir şey satmaya çalışıyordur.

Tema ve eklenti .po dosyalarınızı widget işaretlemesini bozmadan çevirmeye hazır mısınız? SimplePoTranslate'i ücretsiz deneyin - kredi kartı gerekmez. .po dosyasını yükleyin, güvenli çevirileri indirin, wp-content/languages/ içine bırakın.