Gereksinim:
Sitemin
kimliği doğrulanmış bir kullanıcı olarak birden çok dilde
çalışabilmesi için, sitemin kod tabanında bulunan t () işleviyle yapılan tüm çeviri çağrılarını bir kerede çevirebilmem gerekiyor.
Bu gereksinim açıklaması, istediğiniz şeye yakın mı?
Tarayıcıları
Birinin dediği gibi - bir tarayıcı teorik olarak tüm t () çağrılarının kaydını zorlamak için tüm siteden geçebilir. Ancak 1) tarayıcı, hangi sayfaların taranacağını bilmiyor; 2) bu nedenle taranacak sayfaların listesini tutmak istemiyoruz; 3) tarayıcı kullanmak istemiyoruz, nokta. Iyy. Sadece eww. Sağ?
Sorun
- Tüm çeviri dizelerinin bir listesine sahip değiliz.
- Drupal / PHP, C'nin aksine derlenen dinamik bir dildir. Bu yüzden gidip örneğin diyemeyiz: bu kod tabanının tamamını derleyin, sonra bana bu işlevin tüm örneklerini bulun
t(), sonra bu örnekleri veritabanına kaydedin, sonra kayıtlı tüm bu örnekleri t()tek seferde çevirin. Bizim masamıza bir seçenek olduğunu sanmıyorum.
- Statik kod analiz aracı aynı nedenden dolayı tarayıcının çaresiz olacağını düşünürdü. Bunu
t()bu dosyada buldum . Harika! Hangi URL'de kullanılıyor? Bağlam nedir?
Sorunu mevcut araçlarla (Drupal ve bazı katkıda bulunan modüller) ve mevcut kısıtlamalarla (gerçek zamanlı tema çağrıları -> şablon dosyaları -> t()çağrılar) güvenmek, burada çıkışsız bir geçit gibi görünüyor. Biraz kutunun dışında düşünmemiz gerekebilir.
İhtiyacımız olan
- Hangi güncel çeviri dizelerine sahip olduğumuzu ve bağlamlarının ne olduğunu söyleyen bir veri kaynağına, modele ihtiyacımız var -
- Proaktif veri modeli. Mevcut veri modeli reaktiftir (bir çağrı olduğunda model güncellenir
t()). Proaktif bir veri modeline ihtiyacımız var - bu, uygulamanın t()müşteri tarafından gerçekten yürütülmeden önce örnekleri aramaya özen gösterdiği bir model .
- Bağlama ihtiyacımız var.
t()tek başına kesmez - çünkü - 'foo' tercüme ettiğimizi bilmiyoruz, ancak tercüme ettiğimiz hedef dil t()gerçekleştiği yerdeki URL'ye bağlıdır . Hedef dili t()aramaya, örneğin bir sarıcı araması kullanarak kodlayabilirsek bile, sizin amaçlarınız için işe yaramaz.
Onlara sahip olsaydık sorunumuza yardımcı olacak bazı araçlar belirledim. Bu araçlarla veri modeline gidip şunu söyleyebiliriz: henüz doldurulmamış tüm dizeleri verin t(). Şimdi bu çevirileri ekleyin. Teşekkür ederim.
Ve bir dahaki sefere müşteri geldiğinde, çeviriler oradadır.
Bu araçları nasıl inşa ederiz?
Kısıtlamalar
- Hedef dil, URL tarafından belirlenen şablonda olamaz. Dizenin herhangi bir dili desteklemesi gerektiğini varsayarsak.
- Çevrilen dize şablonda olamaz. Çeviri bir veritabanında bulunacaktır.
Artık sorunu daha fazla düşündüğüm ve bazı zorluklar ve kısıtlamalar belirlediğime göre, orada mevcut olan herhangi bir çözüme bakmayı veya özel çözümler üretmeyi düşünebilirim.
Çözüm beyin fırtınası
"Her şeyi" birbirine bağlayan bir şeye ihtiyacım var. Peki ya bir varlık?
- Bir işletmenin çevrilmesi gereken ürünü tutabilir.
- Varlıklar, çevrilmesi gereken ürün ile bağlam arasındaki ilişkiyi (tutkal) sağlayabilir.
- Varlık, bir alanda örneğin ürünün varsayılan URL konumunu belirtebilir.
- Jetonlar, ürünün görüneceği alternatif konumları (diller?) Belirtmek için kullanılabilir.
- İşletmeler bize ihtiyacımız olan proaktif veri modelini ve bağlamını sağlar. Bu da bizim gibi bir şey yapmamıza izin verir: veritabanına git, tüm ürün varlıklarını al ve X, Y ve Z alanları için bir çeviri dizesi yoksa, bu çeviri dizelerini oluşturun.
Daha sonra müşteri yakaladığında /pl/product/200, db'ye bir gezi yapın, 200 ürününe bakın ve mevcut plçeviriyi alın. Bu ürün için de bir başlık ve altyazı alanınız var mı? Çeviriler de orada olmalıdır.
Kullandığınız çeviri modülü açısından burada çok belirsiz ve genel olduğumu unutmayın. Sonunda kendi çeviri modülünüzü kullanabilirsiniz - büyük olasılıkla durum böyledir. Drupal'da şu ana kadar gördüğüm tüm çeviri modelleri (D7 itibariyle, henüz D8'e bakmamış) proaktif değil reaktif.
Kısaca
Teoride, ihtiyacınız olanı inşa etmek için araçlar vardır, varlıklar her şeyi birbirine bağlayacak anahtar bileşendir: - veri (çeviri dizesi), - hedef diller. Ürün dilleri için Varlığın kendisinde, tercihen bir sınıflandırma sözlüğünde olmak zorunda değilsiniz. veya belki de diğer varlıklar için jenerik bir sınıflandırma. - Bağlam. Varlığın göründüğü URL. URL bir jeton içerecek ve jeton da hedef dil sınıflandırmasına atıfta bulunacaktır.
Bu üç bileşenle şunları söyleyebilirsiniz: Tüm productvarlıkları alın , URL aliasalana gidin , sınıflandırma jetonunu alın, tüm olası terim kombinasyonları arasında geçiş yapın, tüm kombinasyonları çok büyük çirkin bir form veya AJAX kullanarak mevcut kullanıcıya sunun ve çok adımlı formlar (bunun gibi bir şey) ve şu anda oturum açmış olan kullanıcı, ürün 200 için çeşitli dilleri çevirdiğinden, bunları bir yere veritabanına kaydedin
Veritabanındaki bir yerde varlıktaki bir Alan API alanı, her bir varlığa ait ayarlar alanı (tam olarak Alan API'sı değil, yine de veri tutabilir) veya bunun için kullandığınız ayrı bir tablo olabilir. Varlık veri kaydetmek hem kod hem de veri daha düzenli ve kolay tutacağını düşünüyorum.
Bina: Olası çözümler
- D8MI (Drupal 8 Çok Dilli Girişim)
- Özel kod: Mevcut dizinleri ve ilgili tema kancası uygulamalarını programlı olarak sorgulayarak ve görüntüleyerek şablonlarda t () tarafından sağlanan "dizin" çevirileri.
pseudocode
Varlık foreach (x türünde),
Tüm dilleri bulun (ürünle ilişkili sınıflandırma veya temel dil),
varlığı oluşturun,
- t () çeviri dizelerini algılamak için
- ürün veri modelinin kendisi değil, ürün.
Sonuç:
- Her dilde varlık şablonu oluşturmak için ilk çağrı, her çağrı için varsayılan dil uygulamasını döndürür.
- Şablondaki t () parametreleri artık Drupal'da önbelleğe alındı ve çeviri için hazır (her dil örneği için değil, her ürün örneği için).
- “Tercüman” rolüne sahip kullanıcı artık çeviri arayüzüne gidebilir ve her dil için mevcut tüm t () parametrelerini çevirebilir.
- Site sahibinin, müşterilerinin her ürün sayfasını ziyaret etmesini veya her ürün sayfasını manuel olarak ziyaret etmesini beklemesi gerekmez, çünkü bu onun için programlı olarak yapılır.
Açık sorular:
- Bağlam nedir? Her bir “ürün” varlık paketi için programla bir theme () çağrısı yaparsam, çağrının yapıldığı yeri kaydediyor mu? Düğümün URL'sini kaydediyor mu? “Bağlam” değiştirilebilir mi? Bağlam nerede kaydedilir? "Dinamik" şablonlarınız olduğunda ne olur - yani ürün başına birden fazla şablonunuz olduğunda ve bu varyasyonları nasıl saptamaya devam ederseniz?
Her zaman olduğu gibi, teorileştirme ve sözde kod sadece beyin fırtınası için iyidir. Ancak geliştirmede prototip oluşturmaya başlayana kadar neye karşı olduğumuzu pek bilmiyoruz. Bu yüzden birkaç kısıtlama, olası çözüm ve olası sorun veya soruları hazırladıktan sonra, artık bir kavram veya çalışma prototipi kanıtı uygulamaya devam edebilirim. Yukarıdaki açık soruların bazıları sadece bu şekilde cevaplanabilir ve prototiplediğimiz en erken (başarı veya başarısızlık ne olursa olsun), bu soruların bazılarını yanıtlamaya başlayabilir veya yaklaşımı tamamen değiştirebiliriz. Bizi izlemeye devam edin ~
wgetya da her neyse kullanın . Hackish, ama buna izin verildiğini söyledin (: