Tek Dosya Girişi, Beş Format Çıktısı: WordPress Çevirilerinizi Geleceğe Nasıl Hazırlarsınız?

WordPress temanızı İspanyolcaya çevirmek için üç hafta harcadınız. .po dosyası mükemmel — her metin gözden geçirildi, her değişken sağlam, her çoğul formu doğru. Ardından müşteriniz klasik bir PHP temasından, ön yüzde React ile başsız bir kuruluma geçmeye karar veriyor.

Aniden .po dosyanız işe yaramaz hale geliyor. React uygulamasının .json dosyasına ihtiyacı var. Eski PHP widget'ları hala .mo dosyasına ihtiyaç duyuyor. Mobil uygulamayı yöneten serbest çalışan .xliff istiyor. Ve kimsenin 4.000 metni üç farklı biçime yeniden çevirmek için zamanı yok.

Bu uç bir durum değil. Temaların hem PHP hem de JavaScript bileşenleriyle birlikte gönderildiği, eklentilerin Gettext ve i18next'in bir karışımını kullandığı ve müşterilerin mimari konusundaki fikirlerini şifrelerini değiştirdiklerinden daha sık değiştirdiği modern WordPress geliştirmenin gerçeği bu.

Neden Çeviri Dosyası Formatları Her Zamankinden Daha Önemli

Beş yıl önce, WordPress çevirisi basitti. Bir .po dosyanız (insan tarafından okunabilir kaynak) ve bir .mo dosyanız (derlenmiş ikili dosya) vardı. Hepsi bu kadardı. Her tema, her eklenti, her çeviri aracı aynı dili konuşuyordu.

Bugün, WordPress ekosistemi üretimde en az beş çeviri dosyası formatı kullanıyor:

Bilmeniz Gereken Beş Format

.po (Portable Object - Taşınabilir Nesne) — GNU Gettext tarafından kullanılan insan tarafından okunabilir kaynak formatı. Orijinal metinleri (msgid) ve çevirilerini (msgstr) içerir. Çevirmenlerin düzenlediği şey budur.

msgid "Add to Cart"
msgstr "Anadir al carrito"

msgid "Your order has been shipped to %s"
msgstr "Su pedido ha sido enviado a %s"

.mo (Machine Object - Makine Nesnesi) — Bir .po dosyasının derlenmiş ikili sürümü. WordPress, çalışma zamanında load_textdomain() kullanarak .mo dosyalarını okur. Çalışma zamanında .po dosyasını ayrıştırmaktan daha hızlıdır, ancak insan tarafından düzenlenemez.

.json (JavaScript Object Notation - JavaScript Nesne Notasyonu) — Gutenberg bloklarında, React bileşenlerinde ve modern temalarda JavaScript tabanlı çeviriler için wp_set_script_translations() tarafından kullanılır. WordPress, locale_data anahtarlarıyla belirli bir JSON yapısı bekler.

{
  "locale_data": {
    "flavor-starter": {
      "Add to Cart": ["Anadir al carrito"],
      "Your order has been shipped to %s": ["Su pedido ha sido enviado a %s"]
    }
  }
}

.php (PHP Array - PHP Dizisi) — Laravel tarzı çeviri yüklemesini kullanan temalar ve eklentiler için giderek daha popüler bir format. Bazı modern WordPress temaları Gettext'i tamamen atlar ve performans için çevirileri PHP dizilerinden yükler.

<?php
return [
    'Add to Cart' => 'Anadir al carrito',
    'Your order has been shipped to %s' => 'Su pedido ha sido enviado a %s',
];

.xliff (XML Localization Interchange File Format - XML Yerelleştirme Değişim Dosyası Formatı) — Farklı araçlar ve platformlar arasında çeviri değişimi için endüstri standardı. memoQ, Trados ve Memsource gibi CAT (Bilgisayar Destekli Çeviri) araçları tarafından kullanılır. Profesyonel insan çevirmenlerle çalışırken önemlidir.

<trans-unit id="1">
  <source>Add to Cart</source>
  <target>Anadir al carrito</target>
</trans-unit>

Sorun: Format Bağımlılığı

Çoğu çeviri aracı tek bir çıktı formatı üretir. Poedit size .po ve .mo verir. WPML çevirileri veritabanında saklar (hiç dosyalarda değil). Weglot çevirileri kendi sunucularında özel bir formatta tutar. Crowdin ve Lokalise gibi TMS platformları bile her proje için dışa aktarma formatlarını manuel olarak yapılandırmanızı gerektirir.

Bu, format bağımlılığı yaratır — çevirileriniz mevcut aracınızın ürettiği formatta hapsolur. Gereksinimleriniz değiştiğinde, iki seçenekle karşılaşırsınız:

1. Yeni formatta her şeyi yeniden çevirin (pahalı, zaman alıcı ve manuel düzeltmeleri kaybedersiniz)
2. Özel dönüştürme komut dosyaları yazın (hataya açık, özellikle karmaşık çoğul formları ve değişkenler için)

İki seçenek de iyi değil. Her ikisi de zaman ve para kaybıdır. Her ikisi de risk oluşturur.

Format Bağımlılığının Zarar Verdiği Gerçek Senaryolar

Senaryo 1: Tema modernizasyonu. Müşterinizin teması Gutenberg bloklarıyla yeniden inşa ediliyor. Eski PHP şablonları .mo dosyalarını kullandı. Yeni blokların wp_set_script_translations() için .json dosyasına ihtiyacı var. 3.000 çevrilmiş metninizin geçiş sırasında her iki formatta da bulunması gerekiyor.

Senaryo 2: Ajans iş akışı. 20 müşteri sitesini yönetiyorsunuz. Bazıları klasik temalar (.mo) kullanıyor. Bazıları başsız kurulumlar (.json) kullanıyor. Bir tanesi PHP dizilerini okuyan özel bir çerçeve kullanıyor. Farklı müşteriler için aynı çevirilere farklı formatlarda ihtiyacınız var.

Senaryo 3: Profesyonel inceleme. AI çevirileriniz %95 doğru, ancak kalan %5'i bir ana dil konuşmacısının incelemesini istiyorsunuz. Profesyonel çevirmenler .xliff içe aktaran CAT araçları kullanır. Çevirilerinizi .xliff olarak dışa aktarmanız, inceleme için göndermeniz ve düzeltmeleri geri birleştirmeniz gerekiyor.

Senaryo 4: Platform geçişi. Müşteriniz WordPress'ten özel bir Node.js uygulamasına geçiyor. Yeni uygulama i18next kullanıyor ve .json dosyalarına ihtiyaç duyuyor. .po formatındaki 5.000 çevrilmiş metninizin tek bir değişkeni veya çoğul formunu kaybetmeden dönüştürülmesi gerekiyor.

Çözüm: Bir Kez Çevirin, Her Formatı Alın

SimplePoTranslate farklı bir yaklaşım benimser. Bir .po, .pot, .json veya .xliff dosyası yükleyip bir çeviri çalıştırdığınızda, beş formatın tamamını içeren bir ZIP dosyası alırsınız:

translations-es_ES.zip
├── flavor-starter-es_ES.po
├── flavor-starter-es_ES.mo
├── flavor-starter-es_ES.json
├── flavor-starter-es_ES.php
└── flavor-starter-es_ES.xliff

Bu, bir kurumsal katmanın arkasına kilitlenmiş bir "premium özellik" değildir. Her ücretli plan — Pro (19$/ay) ve Ömür Boyu (399$ tek seferlik) — her çeviri işinde beş çıktı formatının tamamını içerir.

Bu, Geleceğe Hazırlık İçin Neden Önemli?

Başlangıçtan itibaren beş formatın tamamına sahip olduğunuzda, asla yeniden çeviri yapmanız gerekmez. Çevirileriniz, herhangi bir teknik gereksinime uyum sağlayan bir varlıktır:

• Müşteri klasikten Gutenberg'e mi geçiyor? .json dosyasını dağıtın.
• Yeni geliştirici PHP dizilerini mi tercih ediyor? Onlara .php dosyasını verin.
• Profesyonel bir çevirmen incelemek mi istiyor? .xliff dosyasını gönderin.
• Farklı bir CMS'ye mi geçiyorsunuz? .json ve .xliff dosyaları platformdan bağımsızdır.

Bir kez çeviri yaparsınız. Formatlar ihtiyacınız olduğunda hazırdır.

Her Format WordPress'te Nasıl Çalışır

Hangi dosyanın nereye gittiğini bilmek, temiz bir dağıtım için çok önemlidir.

.mo Dosyalarını Dağıtma (Klasik PHP Temaları ve Eklentileri)

wp-content/languages/plugins/woocommerce-es_ES.mo
wp-content/languages/themes/flavor-starter-es_ES.mo

WordPress bunları site diliyle eşleştiğinde otomatik olarak yükler. Eklenti gerekmez. Sıfır veritabanı yükü. Bu, en iyi performansı sağlayan yaklaşımdır.

.json Dosyalarını Dağıtma (Gutenberg Blokları ve JS Bileşenleri)

wp-content/languages/plugins/woocommerce-es_ES-{handle}-{md5}.json

Dosya adı, komut dosyası tanıtıcısını ve bir MD5 karmasını içerir. WordPress, eklentinizde veya temanızda wp_set_script_translations() çağırdığınızda bunları eşleştirir. Gutenberg blokları oluşturuyorsanız, bu, çevrilmiş blok etiketlerinizin ve açıklamalarınızın doğru görünmesini sağlayan dosyadır.

.xliff Dosyalarını Kullanma (Profesyonel İnceleme İş Akışı)

.xliff dosyaları WordPress'e dağıtılmaz. Çevirileri profesyonel bir incelemeciye göndermeniz veya bir CAT aracına aktarmanız gerektiğinde bir değişim formatı olarak kullanılırlar. İş akışı şöyle görünür:

1. SimplePoTranslate'e .po yükleyin ve ZIP içinde .xliff alın
2. .xliff dosyasını çevirmenize veya incelemecinize gönderin
3. Düzeltilmiş .xliff dosyasını geri alın
4. Düzeltilmiş .xliff dosyasını SimplePoTranslate'e yükleyin ve güncellenmiş .mo ve .json alın

Bu gidiş-dönüş iş akışı, SimplePoTranslate'in Sözdizimi Kilitlemesi her aşamada bunları koruduğu için her değişkeni ve çoğul formunu korur.

Satıcı Bağımlılığı Testi

Mevcut çeviri iş akışınızda bir bağımlılık sorunu olup olmadığını belirlemek için basit bir test şöyledir:

1. Çevirilerinizi şu anda standart .po dosyaları olarak dışa aktarabilir misiniz?
2. Çeviri aracı aboneliğinizi bugün iptal ederseniz, çevrilmiş her metni saklar mısınız?
3. Çevirilerinizi yeniden çevirmeden tamamen farklı bir araca veya platforma aktarabilir misiniz?

Bunlardan herhangi birine cevabınız "hayır" ise, bağımlısınız demektir. Weglot ve GTranslate gibi hizmetler üç sorunun tamamında başarısız olur — aboneliği iptal edin ve çevirileriniz kaybolur. WPML çevirileri veritabanında saklar, bu da dışa aktarmayı mümkün ama zahmetli hale getirir. Poedit gibi masaüstü araçları bile kağıt üzerinde testi geçer ancak sizi yalnızca .po ve .mo ile sınırlar.

SimplePoTranslate ile üç sorunun tamamına cevap "evet"tir. Beş formatta standart dosyalar indirirsiniz. Onlar sizindir. Yarın hesabınızı silin ve yaptığınız her çeviri hala çalışır.

Format Agnostik Bir Çeviri Kitaplığı Oluşturma

Birden çok projeyi yöneten ajanslar ve geliştiriciler için en akıllıca yaklaşım, bir çeviri kitaplığı oluşturmaktır — her müşteri projesi için çevrilmiş dosyaları sakladığınız bir Git deposu veya paylaşılan klasör.

translations/
├── client-acme/
│   ├── es_ES/
│   │   ├── flavor-starter-es_ES.po
│   │   ├── flavor-starter-es_ES.mo
│   │   ├── flavor-starter-es_ES.json
│   │   ├── flavor-starter-es_ES.php
│   │   └── flavor-starter-es_ES.xliff
│   └── de_DE/
│       └── ...
├── client-globex/
│   └── ...

Müşteri yeni bir formata ihtiyaç duyduğunda, zaten sahipsiniz. Müşteri platform değiştirdiğinde, çevirileriniz sıfır çabayla taşınır. Yeni bir geliştirici ekibe katıldığında, tam olarak neyin ve hangi formatlarda çevrildiğini görebilirler.

"Geleceğe hazırlık" aslında budur — müşterilerinizin gelecek yıl hangi teknolojiyi kullanacağını tahmin etmek değil, çevirilerinizin ne seçerlerse seçsinler çalıştığından emin olmak.

Dosya formatları hakkında endişelenmeyi bırakmaya hazır mısınız? SimplePoTranslate'i ücretsiz deneyin — bir dosya yükleyin, beş format geri alın. Dönüştürme komut dosyaları, yeniden çeviri, bağımlılık yok.