Beberapa pertimbangan:
1. Terjemahan
Siapa yang akan menerjemahkan? Orang-orang yang juga terhubung ke situs? Agen penerjemahan? Saat menggunakan Gettext, Anda akan bekerja dengan file 'pot' (.po). File-file ini berisi ID pesan dan string pesan (terjemahan). Contoh:
msgid "A string to be translated would go here"
msgstr ""Sekarang, ini terlihat baik-baik saja dan dapat dimengerti oleh siapa saja yang perlu menerjemahkan ini. Tetapi apa yang terjadi ketika Anda menggunakan kata kunci, seperti yang disarankan Mike, alih-alih kalimat lengkap? Jika seseorang perlu menerjemahkan msgstr yang disebut "address_home", dia tidak tahu apakah ini harus berupa header "Home address" atau kalimat lengkap. Dalam hal ini, pastikan untuk menambahkan komentar ke file tepat sebelum Anda memanggil fungsi gettext, seperti:
/// This is a comment that will be included in the pot file for the translators
gettext("ready_for_lost_episode");
Menggunakan xgettext --add-comments=/// saat membuat file .po akan menambahkan komentar ini. Namun, saya tidak berpikir Gettext digunakan dengan cara ini. Juga, jika Anda perlu menambahkan komentar dengan setiap teks yang ingin Anda tampilkan Anda akan a) mungkin membuat kesalahan di beberapa titik, b) seluruh skrip Anda akan diisi dengan teks, hanya dalam bentuk komentar, c) komentar harus ditempatkan langsung di atas Gettext fungsi, yang tidak selalu sesuai, tergantung pada posisi fungsi dalam kode Anda.
2. Pemeliharaan
Setelah situs Anda berkembang (lebih jauh lagi) dan file bahasa Anda bersamanya, mungkin akan cukup sulit untuk mempertahankan semua terjemahan yang berbeda dengan cara ini. Setiap kali Anda menambahkan teks, Anda perlu membuat file baru, mengirim file ke penerjemah, menerima file kembali, memastikan strukturnya masih utuh (penerjemah yang bersemangat selalu senang menerjemahkan sintaks juga, membuat seluruh file tidak dapat digunakan :)), dan selesaikan dengan mengimpor terjemahan baru. Itu bisa dilakukan, tentu saja, tetapi waspadalah dengan kemungkinan masalah di akhir ini dengan situs besar dan banyak bahasa berbeda.
Opsi lain:gabungkan alternatif ke-2 dan ke-3 Anda:
Secara pribadi, saya merasa lebih berguna untuk mengelola terjemahan menggunakan CMS (sederhana), menyimpan variabel dan terjemahan dalam database dan mengekspor teks yang relevan ke file bahasa sendiri:
- menambahkan variabel ke database (mis.:id, halaman, variabel);
- tambahkan terjemahan ke variabel ini (mis.:id, varId, language, translation);
- pilih variabel dan terjemahan yang relevan, tulis ke file;
- sertakan file bahasa yang relevan di situs Anda;
- buat fungsi Anda sendiri untuk menampilkan teks variabel:
text('var'); atau mungkin sesuatu seperti __('faq','register','lost_password_text');
Poin 3 dapat sesederhana memilih semua variabel yang relevan dan terjemahan dari database, menempatkannya dalam array dan menulis array serlialisasi ke file.
Keuntungan:
-
Pemeliharaan. Mempertahankan teks bisa jauh lebih mudah untuk proyek besar. Anda dapat mengelompokkan variabel berdasarkan halaman, bagian, atau bagian lain dalam situs Anda, cukup dengan menambahkan kolom ke database Anda yang menentukan bagian situs mana yang dimiliki variabel ini. Dengan begitu Anda dapat dengan cepat menarik daftar semua variabel yang digunakan dalam mis. halaman FAQ.
-
Menerjemahkan. Anda dapat menampilkan variabel dengan semua terjemahan dari semua bahasa yang berbeda pada satu halaman. Ini mungkin berguna bagi orang yang dapat menerjemahkan teks ke dalam beberapa bahasa secara bersamaan. Dan mungkin berguna untuk melihat terjemahan lain untuk memahami konteksnya sehingga terjemahannya sebaik mungkin. Anda juga dapat menanyakan database untuk mengetahui apa yang telah diterjemahkan dan apa yang belum. Mungkin menambahkan stempel waktu untuk melacak kemungkinan terjemahan yang kedaluwarsa.
-
Mengakses. Hal ini tergantung pada siapa yang akan menerjemahkan. Anda dapat membungkus CMS dengan login sederhana untuk memberikan akses kepada orang-orang dari agen terjemahan jika perlu, dan hanya mengizinkan mereka untuk mengubah bahasa tertentu atau bahkan bagian tertentu dari situs. Jika ini bukan opsi, Anda masih dapat menampilkan data ke file yang dapat diterjemahkan secara manual dan mengimpornya nanti (walaupun ini mungkin datang dengan masalah yang sama seperti yang disebutkan sebelumnya.). Anda dapat menambahkan salah satu terjemahan yang sudah ada (bahasa Inggris atau bahasa utama lainnya) sebagai konteks untuk penerjemah.
Secara keseluruhan saya pikir Anda akan menemukan bahwa Anda akan memiliki lebih banyak kontrol atas terjemahan dengan cara ini, terutama dalam jangka panjang. Saya tidak dapat memberi tahu Anda apa pun tentang kecepatan atau efisiensi pendekatan ini dibandingkan dengan fungsi gettext asli. Tetapi, tergantung pada ukuran file bahasa, saya tidak berpikir itu akan menjadi perbedaan besar. Jika Anda mengelompokkan variabel menurut halaman atau bagian, Anda selalu dapat menyertakan hanya bagian yang diperlukan.
