Düğüm çevirisi - Varlık (alan) çevirisi

Çok dilli bir site için ne önerdiğinizi bilmek isterim. Örneğin, aşağıdaki durumu göz önünde bulundurun: Bir sayfa ve içeriği 3 dilde (örneğin, Almanca, İngilizce ve İspanyolca) mevcut olmalıdır; site bir profil türü, çeşitli içerik türleri ve görünümleri, taksonomi, taksonomi referansları, düğüm referansları, kullanıcı ve saha referansları, saha koleksiyonları, menüler vb. kullanır. Bu bilgilerin tümü çevrilebilir olmalıdır.

Bildiğim kadarıyla, bunu elde etmenin iki yolu var: Entity Translation ve "düğüm tabanlı" yöntem veya Internationalization modülleri ve l10n ile olağan olanı .

Hangi yolu seçmeliyim? Bu durumda neden diğeri yerine bir yöntem düşünmeliyim?

Randy Fay kısa bir süre önce Gabor Hojtsy'nin tartılacak bazı hususlar hakkında yorum yaptığı Entity Translations ile elde edilen olasılıkları tartışan bir gönderi oluşturdu :

[İyi eski] düğüm çevirisi tarafından sunulan bazı iyi şeyler, ayrı düğüm yorumlaması için destek içerir (örneğin, Almanca ve İngilizce yorumlarınız karıştırılmayacaktır); dil revizyonları için destek; yayın iş akışları (örneğin, Alman düğümü, İngilizce zaten yayınlanırken yayın öncesi bir revizyon iş akışında olabilir, koordine eylemler, hepsi iş akışında belirli bir adıma ulaştığında, birden fazla dil sürümünü yayınlayabilir); Drupal'ın aşırı düğüm erişim sistemi vb. sayesinde farklı izin işlemleri (örneğin, bazı insanlar yalnızca İngilizce orijinalleri değil sadece Almanca çevirileri düzenleyebilir) vb. Menüleri düşünün. Çoğu site, çevrilen tüm sürümler için 1-1 menü yapısını planlamamaktadır.

Content / Entity / field level Translation için gördüğüm en büyük uyarı şu anda o eski Drupalism özel vakasına düşüyor: düğüm başlığı ... Gerçekten bir alan değil, başka bir modül olmadan çevrilemez ve potansiyel olarak Bazı yama çalışması. Şu an itibariyle, alan çevirisinin hala "deneysel" bir temel olduğunu düşünüyorum, ancak yeni bölgelere ilerlemeniz için size daha fazla güç verildiğini düşünüyorum.

Suzanne Kennedy ve Florian Loretan'ın DrupalCon Denver'daki sunumu bu soruyu ele aldı. Varlık çevirisi geleceğin yoludur ve en azından kısmen çekirdeğe entegrasyon için planlanmıştır.

Önerileri, revizyon için desteğe ihtiyaç duymazsanız varlık çevirisini kullanmaktı.

Düğüm çevirisini kullandım ama şimdi Entity Translation'ı denedikten sonra kesinlikle favorim!

Bence asıl sorun, Varlık Çevirisi ile yapılan içe aktarma işlevi, çünkü Drupal topluluğunda uzun bir tartışma var. Aksi halde yeni bir modül okudum, ancak henüz denemedim. Fakat daha sonra size geri bildirimimi vereceğim!

Varlık Çevirisini Başlık modülüyle birleştirirseniz , her şeyi çevirebilirsiniz. Ayrıca " Localization update " modülünü de tercih ediyorum .

Bu katkıda bulunan modülleri kurmanız ve etkinleştirmeniz gerekir:

• Varlık Çevirisi .
• Başlık .
• Yerelleştirme güncellemesi .

Ve bu çekirdek modülleri etkinleştirmeniz gerekir:

• Yerel.
• İçerik Çevirisi.

İyi şanslar!

Burada ölüleri yetiştirdiğimi biliyorum ama:

Söyleyebileceğim kadarıyla, 6 tarzı düğüm çeviri yöntemi (her çeviri yeni bir düğümdür) hala herkesin alıştığı ve işlevsel olarak tamamladığı gibi faydaları olan, içeriği çevirmenin tek kullanışlı yoludur. (Düğüm başlıkları 7'de alan değildir ve bu nedenle diğer aptalca eksikliklerin yanı sıra alana çevrilemez.)

Her zaman i18n / locale kullanacaksınız, tek seçenek (gerçekten bir seçim değil) sadece seviye çevirinin faydalı olabileceği düğüm seviyesi veya alan düzeyinde çeviri.

Düzenleme: Bu yazıldığı için, Entity Translation + Title modülü alan düzeyinde çeviriyi çok etkili kılmıştır. Onları kullanabilirsen, yapmalısın.

Varlık çevirisi çoğu durumda düğüm çeviriden daha anlamlı olur; Ancak ne yazık ki, pek çok modül hala desteklemediği için D7 için gerçekten uygun bir seçenek değil. Sunumlar yapan ve ne kadar harika olduğunu gösteren insanlar sadece çok basit işler yapıyorlar. Örneğin, saha koleksiyonları kadar yaygın / popüler olan bir şey ET tarafından hala desteklenmiyor.

Çok dilli yeni bir siteye başladığımızda, ET ile başlıyoruz çünkü harika bir fikir. Uyumlu olmayan şeylerle ilgili çok fazla sorun bulana kadar buna bağlıyız .. ve sonra eski D6 yöntemine geri dönüyoruz.