Konten dinamis adalah tempat penerjemahan WordPress menjadi sulit

Mengapa penerjemahan pos biasa berhenti di batas editor

Bagian termudah dari penerjemahan WordPress adalah teks yang berada di dalam konten pos, karena ia memiliki objek sumber yang jelas, penetapan bahasa yang stabil, dan tempat yang dapat diprediksi di editor. Alat penerjemahan biasanya dapat membaca konten itu, membuat versi khusus bahasa, dan menjaga hubungan antarversi tetap utuh.

Konten dinamis mematahkan model itu. Jika teks dirakit belakangan oleh widget, shortcode, callback render blok, template plugin, atau permintaan AJAX, teks itu mungkin tidak pernah ada sebagai satu bidang yang dapat diedit di dalam pos itu sendiri. Artinya, lapisan penerjemahan tidak dapat mengandalkan aturan penyimpanan dan pemetaan yang sama seperti yang dipakainya untuk konten biasa.

Konsekuensi praktisnya adalah perilaku multibahasa bergantung pada apakah permukaan dinamis mengekspos input yang dapat diterjemahkan, menyimpan data yang sadar bahasa, atau dapat dirender secara berbeda per bahasa pada saat permintaan. Jika tidak, halaman yang diterjemahkan masih dapat berisi fragmen yang belum diterjemahkan meskipun pos utamanya sudah dilokalkan dengan benar.

Permukaan WordPress mana yang biasanya memerlukan penanganan kompatibilitas eksplisit

Widget dan sidebar sering berisi teks yang dikonfigurasi di luar editor pos utama, sehingga penerjemahan harus menjangkau pengaturan tema atau plugin, bukan hanya konten pos.

Shortcode bisa sangat sulit karena keluaran yang terlihat dihasilkan dari atribut, opsi tersimpan, atau data plugin yang mungkin tidak direpresentasikan sebagai teks halaman yang dapat diedit.

Blok bisa bersifat statis atau dinamis. Blok statis menyimpan kontennya di dalam pos, tetapi blok dinamis dapat dirender dari logika sisi server, yang berarti teks yang terlihat dihasilkan saat runtime dan mungkin memerlukan dukungan penerjemahan terpisah.

Keluaran yang dihasilkan plugin, pemberitahuan, area akun, dan fragmen yang dimuat lewat AJAX juga merupakan titik kegagalan yang umum karena semuanya dirakit dari data milik plugin atau status spesifik permintaan, bukan hanya dari isi halaman.

Permukaan-permukaan ini tidak otomatis tidak diterjemahkan di setiap pengaturan, tetapi sering berada di luar jalur penerjemahan biasa dan karena itu memerlukan penanganan kompatibilitas eksplisit agar berperilaku benar di berbagai bahasa.

Masalah rekayasa inti: penerjemahan membutuhkan data yang stabil, bukan hanya teks yang terlihat

Sistem multibahasa hanya dapat menerjemahkan apa yang dapat diidentifikasi dan dikaitkan dengan bahasa. Itu biasanya berarti data sumber yang stabil, hubungan objek yang dapat diprediksi, dan cara untuk mereproduksi keluaran yang sama dalam bahasa lain tanpa merusak halaman.

Konten dinamis sering bergantung pada meta pos, bidang kustom, catatan milik plugin, atau kondisi runtime. Jika input-input itu tidak dipetakan ke padanan bahasa, halaman yang diterjemahkan dapat merender teks yang salah, objek tertaut yang salah, atau campuran bahasa.

Inilah sebabnya hubungan konten penting. Halaman yang diterjemahkan bukan hanya masalah penggantian teks; itu juga masalah perutean dan asosiasi. Sistem harus tahu pos, istilah, template, atau objek terkait mana yang harus digunakan ketika pengunjung berada di versi lokal situs.

Ketika pemetaan itu tidak lengkap, mode kegagalannya biasanya penerjemahan parsial, bukan kegagalan total: halaman dimuat, tetapi beberapa fragmen tetap dalam bahasa sumber, mengarah ke varian bahasa yang salah, atau menampilkan label dan tautan yang tidak konsisten.

Rendering saat runtime mengubah alur kerja penerjemahan

Rendering dinamis berarti HTML akhir belum sepenuhnya ditentukan ketika pos disimpan. Sebaliknya, halaman mungkin dirakit belakangan dari template, logika render blok, pengaturan plugin, atau konteks permintaan.

Itu mengubah alur kerja penerjemahan dalam dua cara. Pertama, sistem penerjemahan mungkin perlu menerjemahkan sumber data yang mendasarinya, bukan keluaran yang sudah dirender. Kedua, sistem mungkin perlu mengevaluasi ulang keluaran pada setiap permintaan agar versi bahasa yang benar dirakit saat runtime.

Ini berguna ketika template yang sama harus melayani banyak bahasa, tetapi juga menciptakan risiko ketergantungan. Jika komponen dinamis membaca dari opsi bersama, pengaturan global, atau catatan yang netral bahasa, setiap bahasa dapat mewarisi teks yang sama kecuali komponen itu secara eksplisit dibuat sadar bahasa.

Bagi pemilik WordPress, pertanyaan operasionalnya bukan hanya apakah halaman dapat diterjemahkan, tetapi apakah komponen yang menghasilkan halaman tahu cara memilih data khusus bahasa yang tepat pada saat render.

Mode kegagalan umum di situs WordPress multibahasa

Salah satu mode kegagalan umum adalah fragmen yang tidak diterjemahkan di dalam halaman yang sudah dilokalkan. Ini terjadi ketika pos utama sudah diterjemahkan tetapi widget, shortcode, atau keluaran plugin masih membaca dari pengaturan bahasa sumber.

Yang lain adalah hubungan yang rusak. Halaman yang diterjemahkan dapat menaut ke pos terkait, produk, istilah, atau tampilan akun yang salah jika pemetaan objek yang mendasarinya tidak sadar bahasa.

Perutean juga dapat gagal di tepi konten dinamis. Jika sebuah komponen menghasilkan tautan, sinyal kanonik, atau jalur khusus bahasa tanpa memperhatikan lokal saat ini, pengunjung dapat diarahkan ke versi situs yang salah atau mesin pencari dapat menerima sinyal yang tidak konsisten.

Konten AJAX menambah lapisan risiko lain karena halaman awal dan fragmen yang dimuat kemudian mungkin tidak berbagi konteks bahasa yang sama kecuali permintaan itu ditangani secara eksplisit seperti itu.

Area akun dan pemberitahuan sangat sensitif karena sering bergantung pada status pengguna, status sesi, atau data milik plugin. Permukaan-permukaan itu mungkin memerlukan logika penerjemahan yang terpisah dari konten halaman yang terlihat publik.

Apa saja yang biasanya harus dicakup oleh penanganan kompatibilitas

Penanganan kompatibilitas umumnya harus menjawab tiga pertanyaan: di mana teks berada, bagaimana teks itu dikaitkan dengan bahasa, dan bagaimana teks itu dirender dalam konteks yang benar.

Jika teks berada di meta pos, bidang kustom, atau pengaturan plugin, lapisan penerjemahan perlu cara untuk menyimpan atau mereferensikan nilai khusus bahasa.

Jika teks dihasilkan oleh blok, shortcode, atau callback template, logika rendering perlu tahu versi bahasa mana yang harus dikeluarkan dan objek terkait mana yang harus dimuat.

Jika keluaran menyertakan tautan atau target navigasi, target-target itu perlu diselesaikan ke objek yang diterjemahkan, bukan objek sumber asli.

Jika keluaran dimuat secara asinkron, permintaan itu sendiri perlu membawa konteks bahasa yang cukup agar fragmen cocok dengan halaman yang sedang dilihat pengunjung.