Persyaratan Anda:
Agar situs saya berfungsi dalam berbagai bahasa
sebagai pengguna yang diautentikasi,
saya harus dapat menerjemahkan sekaligus semua dan semua panggilan terjemahan yang ditemukan dalam basis kode situs saya yang dilakukan dengan fungsi t ().
Apakah deskripsi persyaratan itu mendekati apa yang Anda minta?
Perayap
Seperti kata seseorang - perayap secara teoritis dapat menelusuri seluruh situs untuk memaksa pendaftaran semua panggilan t (). Tapi 1) crawler tidak tahu halaman mana yang harus dijelajahi; 2) kami tidak mencari untuk mempertahankan daftar halaman yang akan dirayapi, oleh karena itu; 3) kami tidak ingin menggunakan crawler, titik. Eww. Baru saja. Baik?
Masalah
- Kami tidak memiliki daftar semua string terjemahan.
- Drupal / PHP adalah bahasa yang dinamis tidak seperti C yang dikompilasi. Jadi kita tidak bisa pergi dan mengatakan misalnya: kompilasi seluruh basis kode ini, lalu temukan semua instance dari fungsi ini
t(), kemudian daftarkan instance-instance itu dalam database, kemudian terjemahkan semua instance terdaftar itu t()dalam sekali jalan. Saya tidak berpikir adalah pilihan yang kami miliki di meja kami.
- Alat analisis kode statis akan tidak berdaya karena alasan yang sama crawler tidak berdaya. Saya menemukan ini
t()di file ini. Bagus! Di mana URL itu digunakan? Apa konteksnya?
Menyerang masalah dengan alat saat ini (Drupal, dan beberapa modul contrib), dan dengan kendala saat ini (bergantung pada panggilan tema waktu nyata -> file templat -> t()panggilan), tampak seperti lorong keluar di sini. Kita mungkin perlu berpikir sedikit di luar kebiasaan.
Apa yang kita butuhkan
- Kami membutuhkan sumber data, model, yang memberi tahu saya string terjemahan mana yang kami miliki saat ini, dan apa konteksnya -
- Model data proaktif. Model data saat ini adalah reaktif (model akan diperbarui setiap kali terjadi panggilan
t()). Kami membutuhkan model data proaktif - model di mana aplikasi berhati-hati dalam mencari t()contoh sebelum mereka benar-benar dieksekusi oleh pelanggan.
- Kami membutuhkan konteks.
t()sendiri tidak memotongnya - karena - kita tidak tahu kita menerjemahkan 'foo', tetapi bahasa target yang kita terjemahkan tergantung pada URL tempat t()terjadinya. Bahkan jika kami dapat mengubah kode bahasa target ke t()panggilan, katakanlah, menggunakan panggilan wrapper, itu tidak akan berfungsi untuk tujuan Anda.
Saya telah mengidentifikasi beberapa alat yang - jika kita memilikinya - akan membantu masalah kita. Dengan alat-alat ini kita bisa masuk ke dalam model data dan berkata: beri saya semua string t()yang belum diisi. Sekarang masukkan terjemahan ini. Terima kasih.
Dan pada saat pelanggan datang, terjemahan ada di sana.
Bagaimana kita ... membangun alat-alat ini?
Kendala
- Bahasa target tidak boleh ada di templat, yang ditentukan oleh URL. Dengan asumsi string harus mendukung bahasa apa pun.
- String yang diterjemahkan tidak boleh ada di templat. Terjemahan akan berada di database.
Sekarang saya telah memikirkan masalah lebih lanjut, dan mengidentifikasi beberapa tantangan dan kendala, saya dapat berpikir tentang melihat solusi apa pun yang tersedia di luar sana, atau membuat solusi kustom apa pun.
Brainstorm solusi
Saya membutuhkan sesuatu yang mengikat "segalanya" bersama. Bagaimana dengan ... entitas?
- Suatu entitas dapat menampung produk yang perlu diterjemahkan.
- Entitas dapat memberikan hubungan - perekat - antara produk yang perlu diterjemahkan, dan konteksnya.
- Entitas dapat menentukan katakanlah, di bidang, lokasi URL default produk.
- Token dapat digunakan untuk menentukan lokasi alternatif (bahasa?) Tempat produk akan muncul.
- Entitas memberi kita model data proaktif yang kita butuhkan, dan konteksnya. Yang pada gilirannya memungkinkan kita untuk melakukan hal seperti: masuk ke database, ambil semua entitas produk, dan jika tidak memiliki string terjemahan untuk bidang X, Y, dan Z, buat string terjemahan itu.
Ketika pelanggan kemudian mengambil /pl/product/200, Anda melakukan perjalanan ke db, mencari produk 200, dan ambil terjemahan yang sudah ada pl. Anda memiliki bidang judul dan teks untuk produk itu juga? Terjemahan juga harus ada di sana.
Perhatikan bahwa saya menjadi sangat kabur dan generik di sini dalam hal modul terjemahan apa yang Anda gunakan. Anda bisa saja menggunakan modul terjemahan Anda sendiri - kemungkinan besar inilah masalahnya. Semua model terjemahan yang saya lihat di Drupal sejauh ini (pada D7, belum melihat D8) adalah reaktif, bukan proaktif.
Pendeknya
Secara teori, alat untuk membangun apa yang Anda butuhkan ada di sana, entitas menjadi komponen kunci yang akan menyatukan semuanya: - data (string terjemahan), - bahasa target. Tidak harus berada di Entitas itu sendiri, lebih disukai kosakata taksonomi, katakanlah untuk bahasa produk. atau mungkin taksonomi generik untuk entitas lain juga. - Konteks. URL tempat entitas muncul. URL akan berisi token, dan token pada gilirannya akan merujuk taksonomi bahasa target.
Dengan tiga bahan yang bisa Anda katakan: Raih semua productentitas, pergi ke URL aliaslapangan, dapatkan token taksonomi, siklus melalui semua kombinasi istilah yang mungkin, sajikan semua kombinasi kepada pengguna saat ini menggunakan bentuk jelek yang sangat besar - atau, AJAX - dan formulir multi-langkah (sesuatu seperti itu), dan ketika pengguna yang saat ini masuk menerjemahkan berbagai bahasa untuk produk 200, simpan yang ada di suatu tempat ke dalam basis data
Di suatu tempat di dalam basis data bisa menjadi bidang API Bidang dalam entitas, bidang pengaturan milik masing-masing entitas (tidak persis API Bidang, tetapi masih dapat menyimpan data), atau tabel terpisah yang Anda gunakan untuk ini. Saya pikir menyimpan data ke Entitas akan membuat kode dan data lebih rapi dan lebih mudah.
Membangunnya: Kemungkinan solusi
- D8MI (Drupal 8 Multilingual Initiative)
- Kode khusus: terjemahan "indeks" dibuat tersedia dalam templat oleh t () dengan secara terprogram meminta dan merender bundel yang tersedia dan implementasi kait tema yang terkait.
Kodesemu
Entitas entitas depan (tipe x),
Temukan semua bahasa (taksonomi atau bahasa inti yang terkait dengan produk),
Render entitas,
- untuk mendeteksi t () string terjemahan
- render panggilan tema (), yang menangani lapisan presentasi multibahasa dari produk, bukan model data produk itu sendiri.
Hasil:
- Panggilan pertama untuk merender templat entitas di setiap bahasa mengembalikan implementasi bahasa default untuk setiap panggilan.
- Parameter t () pada template sekarang di-cache dalam Drupal dan siap untuk terjemahan (untuk setiap instance bahasa, tidak setiap instance produk).
- Pengguna dengan peran "penerjemah" sekarang dapat pergi ke antarmuka terjemahan dan menerjemahkan semua parameter t () yang tersedia, untuk setiap bahasa.
- Pemilik situs tidak perlu menunggu pelanggan untuk mengunjungi setiap halaman produk, atau mengunjungi setiap halaman produk secara manual, karena ini dilakukan secara terprogram untuknya.
Pertanyaan terbuka:
- Apa konteksnya? Jika saya melakukan panggilan programatik ke tema () untuk setiap bundel entitas "produk", apakah ia merekam lokasi dari mana panggilan itu dibuat? Apakah ini merekam URL node? Bisakah "konteks" diubah? Di mana konteksnya dicatat? Apa yang terjadi ketika Anda memiliki template "dinamis" - yaitu, ketika Anda memiliki lebih dari satu template per produk dan bagaimana Anda mendeteksi variasi-variasi itu?
Seperti biasa, berteori dan kodesemu hanya baik untuk brainstorming. Tetapi dalam pengembangan kita tidak akan tahu apa yang sebenarnya kita hadapi sampai kita mulai membuat prototipe. Jadi, setelah membuat beberapa kendala, solusi yang mungkin, dan kemungkinan masalah atau pertanyaan - sekarang saya dapat melanjutkan untuk menerapkan bukti konsep atau prototipe kerja. Beberapa pertanyaan terbuka di atas hanya dapat dijawab dengan cara ini, dan prototipe kami yang paling awal (terlepas dari keberhasilan atau kegagalan), kami dapat mulai menjawab beberapa pertanyaan itu - atau mengubah pendekatan secara bersamaan. Tetap disini ~
wgetatau apa pun. Meretas, tetapi Anda memang mengatakan bahwa itu diizinkan (: