Drupal .po Dosyaları Yapay Zeka ile Nasıl Çevrilir
Çoğu kişi .po dosyalarını WordPress ile ilişkilendirir, ancak gettext formatı WordPress'ten onlarca yıl önceye dayanır ve tüm açık kaynak dünyasında arayüz çevirisine güç verir. Drupal, en büyük kullanıcılarından biridir. Çok dilli bir Drupal sitesi işletiyorsanız, her menü etiketi, alan açıklaması, hata mesajı ve modül dizgisi, WordPress'te olduğu gibi .po dosyaları aracılığıyla akar, sadece farklı bir yer tutucu lehçesi ve farklı bir içe aktarma iş akışı ile. Ve tıpkı WordPress'te olduğu gibi, siteniz birkaç dizgiyi aştığı anda, bu dosyaları elle çevirmek darboğaz haline gelir.
Bu rehber, Drupal'ı Drupal yapan şeyleri bozmadan Drupal .po dosyalarını yapay zeka ile nasıl çevireceğiniz hakkındadır. Drupal'ın çeviri sistemini, dizgelerin aslında nereden geldiğini, WordPress'ten farklı olan ve kesinlikle korunması gereken yer tutucu sözdizimini ve bunu tekrarlanabilir kılan drush komutları da dahil olmak üzere tam dışa aktarma, çevirme ve yeniden içe aktarma döngüsünü ele alacağız.
Drupal'ın Çeviri Sistemi Nasıl Çalışır
Drupal, çekirdek locale modülü (modern Drupal'da bazen "Arayüz Çevirisi" olarak adlandırılır) aracılığıyla arayüz çevirisini yönetir. Etkinleştirildikten sonra, kaynak dizgileri ve dillerine göre çevirilerini içeren bir veritabanı tablosunu yönetir ve bu çevirileri standart gettext .po dosyaları olarak içe ve dışa aktarabilir.
Yönetim arayüzü /admin/config/regional/translate adresinde bulunur. Buradan çevrilmemiş dizgileri arayabilir, satır içi düzenleyebilir ve en önemlisi, toplu çeviri yüklemek için bir .po dosyasını içe aktarabilir veya çevrimdışı düzenleme için mevcut durumu bir .po dosyasına dışa aktarabilirsiniz. İşte bu dışa aktarma/düzenleme/içe aktarma döngüsü, optimize ettiğimiz iş akışıdır.
Her eklenti ve temanın kendi .po ve .mo dosyalarını languages/ dizininde gönderdiği WordPress'in aksine, Drupal arayüz dizgilerini veritabanında merkezileştirir ve .po'yu değişim formatı olarak kabul eder. Dosyayı dışa aktarır, üzerinde çalışır ve geri içe aktarırsınız. WordPress'in gerektirdiği derlenmiş .mo adımı dahili olarak ele alınır.
Dizgiler Nereden Gelir
Drupal dizgeleri üç yerden gelir ve eksiksiz bir çeviri bunların hepsini kapsamalıdır:
- Çekirdek yönetim arayüzü, formlar ve sistem mesajları için binlerce çevrilebilir dizgi gönderir.
- Katkıda bulunan modüller (Views, Webform, Commerce ve diğerleri) her biri kendi dizgilerini
t()fonksiyonu aracılığıyla kaydeder. - Temalar şablon dizgileri, bölge etiketleri ve tema ayarı açıklamaları katkısında bulunur.
/admin/config/regional/translate adresinden dışa aktardığınızda, dışa aktarımı çevrilmiş, çevrilmemiş veya tüm dizgilere göre kapsamlandırabilirsiniz. Yeni bir çeviri geçişi için, yalnızca çevrilmemiş dizgileri dışa aktarmak, kalan işi tam olarak içeren odaklanmış bir .po dosyası sağlar.
Bu üç kaynaklı yapının pratik bir sonucu: çeviri işiniz asla tam olarak "bitmez." Her katkı modülü eklediğinizde, yeni bir özellik etkinleştirdiğinizde veya Drupal çekirdeğini güncellediğinizde, yerel tabloya yeni bir grup çevrilmemiş msgid girdisi eklenir. Bu yüzden Drupal ekipleri çeviriyi tek seferlik bir başlangıç görevi olarak değil, tekrarlayan bir süreç olarak ele alır. Modüllere dokunan her dağıtımda aynı dışa aktarma, çevirme, yeniden içe aktarma döngüsü çalışır ve bu döngü ne kadar hızlı olursa, sürümler arasında o kadar az çeviri borcu birikir.
Drupal'ın çekirdek ve popüler katkı modülleri için topluluk katkılı çevirileri localize.drupal.org adresinden otomatik olarak çekebildiğini de belirtmekte fayda var. Bunlar genel dizgileri kapsar, ancak özel modüllerinizi, temanızı veya sitenizin gerçekten kullandığı projeye özgü ifadeyi nadiren kapsarlar. Topluluk çevirisi ile tam olarak yerelleştirilmiş bir site arasındaki fark, yapay zeka geçişinin hızla kapattığı iştir.
Drupal Yer Tutucuları WordPress Yer Tutucuları Değildir
Herhangi bir Drupal .po dosyasını bir yapay zeka çevirmenine göndermeden önce anlaşılması gereken en önemli şey şudur: Drupal, WordPress'te yaygın olan printf-stili %s ve %1$s yer tutucularını kullanmaz. Drupal'ın t() fonksiyonu, her biri farklı kaçış davranışına sahip üç farklı yer tutucu öneki kullanır:
@variable— değer HTML'den kaçırılır, kullanıcı tarafından sağlanan metinler için güvenli varsayılan.%variable— değer kaçırılır ve<em>vurgu biçimlendirmesi ile sarılır.:placeholder— URL nitelikleri için kullanılır, URL temizlemesinden geçirilir.
Tipik bir Drupal kaynak dizgisi, dışa aktarılan .po dosyasında şöyle görünür:
#: core/modules/node/node.module
msgid "@count comments"
msgid_plural "@count comments"
msgstr[0] ""
msgstr[1] ""
#: core/modules/user/user.module
msgid "Welcome @name, you last logged in on %date."
msgstr ""
Bir çevirmen @count'u @cuenta olarak değiştirirse, @name'i "isim" kelimesinin çevrilmiş haliyle değiştirirse, veya @count'ı @ count haline getiren bir boşluk eklerse, yer tutucu, t() çağrısının ilettiğiyle eşleşmez. Drupal o zaman gerçek sayı yerine literal belirteç @count'ı sayfaya yazdırır. Çeviri bitmiş gibi görünür ancak site gözle görülür şekilde bozulmuştur.
Bu, WordPress %s dizgilerini etkileyen aynı hata sınıfıdır ve genel prensibi kod değişkenlerini bozmadan PO dosyaları nasıl çevrilir makalesinde derinlemesine ele alıyoruz. Drupal'daki fark, tek bir yer tutucu stili yerine üç tane olması ve bir çeviri aracının bunların hepsini tanıması gerektiğidir.
Neden Genel Çevirmenler Burada Başarısız Olur
Bu node.module dizgisini bir tüketici makine çevirisi kutusuna yapıştırdığınızda, ve sıklıkla @count'ın bozulduğunu, <em>-ile bağlı %date'in farklı bir belirtece yerelleştirildiğini, veya çoğul formların tek bir taneye indirgendiğini görürsünüz. Bu araçların hiçbiri gettext semantiği göz önünde bulundurularak geliştirilmemiştir. Metin çevirirler; @count'ın uygulama koduyla bir sözleşme olduğunu anlamazlar.
Sözdizimi Kilitleme özelliğine sahip gettext uyumlu bir çeviri hattı, @variable, %variable ve :placeholder'ı değişmez belirteçler olarak ele alır. Çeviri öncesinde kilitlenirler ve sonrasında geri yüklenirler, böylece yer tutucular dokunulmadan geçerken çevreleyen cümle çevrilir. Aynı kilit WordPress %s ve %1$s, i18next {{name}} ve satır içi HTML'yi kapsar; bu nedenle tek bir araç bir Drupal, Symfony veya Laravel projesine bir WordPress projesi kadar kolay hizmet verebilir. msgid_plural aracılığıyla Drupal çoğul formları düzleştirilmek yerine çoğul formlar olarak korunur; bu önemlidir çünkü Drupal dilleri birden altıya kadar çoğul varyanta sahip olabilir.
yrıca, bahsetmeye değer daha ince bir hata modu da var. Drupal dizgeleri sıklıkla çevrilebilir metnin içine satır içi biçimlendirme ve bağlantılar gömer, örneğin :url'nin bir yer tutucu olduğu ve <a> etiketlerinin korunması gereken Read the <a href=":url">documentation</a> gibi. Yapıyı anlamayan bir çevirmen href niteliğini çevirebilir, kapanış etiketini düşürebilir veya yer tutucu adını yerelleştirebilir. Tüm dizgiyi bir birim olarak okuyan, belirteç kilitleme ile birleştirilmiş Bağlama Duyarlı Yapay Zeka, hem biçimlendirmeyi hem de :url sözleşmesini sağlam tutarken, yalnızca insan tarafından okunabilir "documentation" metnini çevirir.
Dışa Aktarma, Çevirme, Yeniden İçe Aktarma Döngüsü
Tekrarlanabilir iş akışının üç aşaması vardır, ve drush dışa ve içe aktarmayı betiklenebilir hale getirir, böylece her seferinde yönetim arayüzünde tıklamanız gerekmez.
Adım 1: PO Dosyasını Dışa Aktarma
/admin/config/regional/translate adresindeki kullanıcı arayüzünden bir dil ve dışa aktarma kapsamı seçerek dışa aktarabilir veya komut satırından yapabilirsiniz. Locale modülü, Drupal'ın çeviri hizmetleri aracılığıyla dışa aktarmayı sunar ve çoğu ekip bunu betikler. Bir çeviri içe aktarmayı tetiklemek için tipik bir drush çağrısı (üçüncü adımda kullanacağımız tersi) şöyle görünür:
# Re-import a translated PO file for Spanish, overwriting customized strings
drush locale:import es /var/www/translations/es-untranslated.po \
--type=customized --override=all
# Rebuild caches so the new strings render immediately
drush cache:rebuild
Dışa aktarma tarafı için, yönetici dışa aktarma formu .po dosyasını üretir; birçok ekip, tam otomasyon için yerel dışa aktarma hizmetini küçük bir özel Drush komutuna sarar. Her iki durumda da, çevrilmemiş msgid girdilerinizi içeren standart bir gettext .po dosyası elde edersiniz.
Adım 2: Dosyayı Çevirme
Bu, yapay zekanın saatler süren manuel düzenlemelerin yerini aldığı aşamadır. Dışa aktarılan .po dosyasını bir bulut çevirmenine yükleyin, hedef dilinizi seçin ve işlemesine izin verin. Büyük bir site için Drupal .po dosyaları, çekirdek, katkı ve temalar birleştirildiğinde rutin olarak 10MB'ı geçtiği için, burada Akıllı Gruplama önemlidir: dosya, sizin elle bölmenize veya boyut sınırlarına takılmanıza gerek kalmadan parçalanır, çevrilir ve yeniden birleştirilir. Çıktı, her msgstr'nin doldurulduğu ve her @count, %date ve :url yer tutucunun tam olarak başladığı yerde olduğu eksiksiz bir .po dosyasıdır.
Adım 3: Drupal'a Yeniden İçe Aktarma
Çevrilmiş dosyayı /admin/config/regional/translate aracılığıyla veya yukarıda gösterilen drush locale:import komutuyla geri içe aktarın, ardından önbelleği yeniden oluşturun. Drupal, çevirileri yerel tablolarına birleştirir ve dizgeler sitede hemen görünür. Yeni çevrilmemiş dizgeler getirdiği için her modül eklediğinizde veya çekirdeği güncellediğinizde döngüyü tekrar çalıştırın.
Doğru yapılması gereken bir içe aktarma detayı: --override bayrağı, gelen çevirilerin mevcut olanları değiştirip değiştirmediğini kontrol eder. Yapay zeka ile çevrilmiş dosyanın yetkili olmasını istediğinizde --override=all kullanın, veya Drupal kullanıcı arayüzünde elle ayarladığınız ve üzerine yazılmasını istemediğiniz belirli dizgiler varsa daha muhafazakar bir ayar kullanın. Çoğu otomatikleştirilmiş süreç için, .po dosyasını doğruluk kaynağı olarak kabul etmek ve her şeyi üzerine yazmak sistemi öngörülebilir kılar: sürüm kontrolündeki dosya, sitenin gösterdiğidir, nokta.
Birkaç hedef dile sahip çok dilli siteler için döngü, dil başına bir kez çalışır. Çevrilmemiş kümeyi dışa aktarın, Almanca'ya çevirin, içe aktarın; tekrar dışa aktarın, İspanyolca'ya çevirin, içe aktarın; ve bu böyle devam eder. Her dil bağımsız bir .po dosyası olduğu için bunları paralel çalıştırabilirsiniz ve bulut çeviricinin bunları eşzamanlı olarak işlemesi, eskiden bir hafta süren bir yüklenici işini bir öğleden sonraya dönüştürür.
Drupal PO Birkaç Format Arasından Biridir
gettext .po'nun Drupal'ın çeviriyi ele aldığı tek yol olmadığını belirtmekte fayda var. Yapılandırma ve içerik varlıkları da profesyonel çeviri tedarikçi iş akışları için Çeviri Yönetimi Aracı (TMGMT) modülünün dayandığı standart olan XLIFF olarak alışveriş edilebilir. Drupal yerelleştirmeniz arayüz .po dosyaları yerine XLIFF üzerinden çalışıyorsa, yer tutucu koruma prensipleri aynıdır ancak dosya yapısı farklılık gösterir, ve bu yolu Drupal, Symfony ve Angular için XLIFF dosyalarını çevirme makalesinde ele alıyoruz.
Ancak arayüz çeviri katmanı için .po, işgücünü sürdüren ana araç olmaya devam ediyor. Dışa aktarma, yapay zeka ile çevirme, yeniden içe aktarma döngüsü, çok günlü manuel bir görevi birkaç dakikalık işleme dönüştürür, ve kullandığınız araç gettext yer tutucularını gerçekten anladığı sürece, @variable sözleşmeleriniz sağlam kalır ve Drupal siteniz gönderdiğiniz her dilde bozulmadan kalır.
Drupal .po dosyalarınızı tek bir
@variablebile bozmadan çevirmeye hazır mısınız? SimplePoTranslate'i ücretsiz deneyin — kredi kartı gerekmez. Ücretsiz katman, tam Sözdizimi Kilitleme ile standart gettext .po ve .pot dosyalarını işler, böylece Drupal yer tutucularınız kodun beklediği gibi tam olarak geçer.