Melanjutkan diskusi tentang keuntungan Fluent daripada gettext yang biasa, saya mempublikasikan posisi resmi pencipta Fluent dalam terjemahan.
Gettext adalah sistem lokalisasi yang berakar dalam pada proyek GNU dan solusi arsitekturnya yang terkait.
Proyek Fluent melihat gettext sebagai contoh yang baik dari ekosistem pustaka tingkat rendah yang sepenuhnya independen platform-platform dan alat untuk mengelola siklus rilis produk lengkap dengan file lokalisasi dalam format yang dapat dibaca. Pada saat yang sama, paradigma Fluent membawa kita ke solusi arsitektur lain dalam aspek pelokalan penting, yang, pada gilirannya, mengarah pada API dan siklus hidup yang sangat berbeda.
Dengan kata lain, gettext adalah proyek yang hebat, tetapi kami tidak berbagi pandangannya tentang pendekatan lokalisasi.
Berikut adalah perbedaan utama antara gettext dan Fluent:
Pengaturan
Perbedaan paling penting antara gettext dan Fluent adalah pengidentifikasi pesan. Gettext memutuskan untuk menggunakan string sumber (biasanya dalam bahasa Inggris) sebagai pengenal. Pilihan ini tampaknya sederhana, tetapi kemudian memaksakan banyak pembatasan.
Pertama-tama, dengan pendekatan ini, setiap perubahan pada baris asli akan membatalkan semua terjemahan yang terkait dengannya. Ini secara serius meningkatkan beban pada pengembang, memaksa mereka untuk tidak pernah mengubah pesan asli, karena ini akan membutuhkan memperbarui semua terjemahan.
Kedua, mempersulit pengenalan beberapa pesan dengan teks yang sama dalam bahasa sumber, yang harus diterjemahkan dengan cara yang berbeda. Misalnya, teks untuk tombol "Open" dan untuk tanda "Open" dapat diterjemahkan dengan cara yang berbeda, karena teks pertama adalah perintah, dan yang kedua adalah deskripsi. Gettext memiliki baris konteks
msgctxt opsional untuk membedakan antara baris dengan segmen sumber yang sama. Pendekatan ini menempatkan tanggung jawab untuk mengenali situasi seperti itu pada pengembang, yang bertentangan dengan prinsip pemisahan kepentingan.
Fasih tidak merekomendasikan penggunaan kembali teks karena alasan ini. Memisahkan teks sumber dari terjemahan lain juga penting untuk kemampuan kita memasukkan pesan majemuk (yang berisi beberapa baris untuk satu unit terjemahan, dilampirkan ke satu widget antarmuka pengguna) dan untuk tautan berbasis pengenal ke pesan.
Lancar membuat "perjanjian" antara pengembang dan pelokalan. Pengembang memasukkan pengidentifikasi unik dan serangkaian variabel (jumlah pesan yang belum dibaca, nama pengguna, dll.), Dan pelokalkan, menggunakan sintaks Fluent, memutuskan bagaimana membuat teks pesan untuk pengidentifikasi ini.
Pengembang tidak perlu khawatir tentang implementasi terperinci terjemahan dari pesan-pesan tersebut. Semua yang dibutuhkan pengembang adalah untuk mendapatkan satu baris teks yang cocok untuk tempat tertentu di UI untuk meminta string oleh pengidentifikasi tertentu.
Opsi Pesan
Gettext mendukung sekumpulan fungsi kecil untuk internasionalisasi, khususnya untuk bentuk jamak. Tapi sintaks jamak seperti itu adalah kasus khusus, di samping sintaks gettext standar, dan sulit untuk skala untuk kasus-kasus lain yang membutuhkan variabilitas.
Lancar mendukung konsep dasar variasi string, yang dapat digunakan dengan penyeleksi. Biasanya aturan jamak akan menjadi pemilih seperti itu, tetapi tergantung pada fitur tata bahasa bahasa, mungkin ada yang lain, seperti jenis kelamin, kemunduran, atau bahkan lingkungan - misalnya, waktu hari atau sistem operasi. Sintaks Fluent memungkinkan pelacak untuk mempertimbangkan semua fitur ini dan membuat teks yang persis sesuai dengan situasi.
Argumen eksternal
Gettext tidak mendukung argumen eksternal. Dengan kata lain, Anda tidak dapat menentukan pemformatan parameter - angka, tanggal. Untuk memformat parameter dalam gettext, disarankan untuk mengembalikan string, yang akan diteruskan ke
printf atau menjalankan
String.prototype.replace pada string yang dihasilkan.
Dalam Fluent, dukungan untuk argumen eksternal adalah inti dari sintaksis. Argumen eksternal tidak hanya diinterpolasi, tetapi juga digunakan sebagai parameter untuk pemilih, dan juga dapat ditransfer ke fungsi bawaan. Ini memungkinkan pelokalan untuk membuat teks yang jauh lebih akurat untuk kasus-kasus tertentu. Selain itu, Fluent menempatkan penanda
FSI / PDI di sekitar objek untuk melindungi isolasi directivity dalam teks dua arah, dan melarang manipulasi string daun, mengurangi beban pada pengembang.
Isolasi Tanggung Jawab
Selain itu, cara gettext menangani aturan jamak mengharuskan perancang sistem untuk memilih apakah pesan tersebut akan menjadi pesan multivarian atau satu baris. Dari sudut pandang Fluent, pengembang tidak boleh berurusan dengan masalah seperti itu. Dalam banyak kasus, ketika satu opsi cukup dalam bahasa Inggris, dalam bahasa lain Anda perlu menambahkan varian dengan bentuk jamak.
Lancar mengasumsikan bahwa pengembang tidak boleh memiliki pengetahuan linguistik yang sama ketika mengembangkan perangkat lunak dengan banyak lokal, dan setiap bahasa harus memiliki kebebasan bertindak tertentu selama lokalisasi.
Akibatnya, Fluent menyimpan setiap terjemahan secara terpisah, tanpa "membocorkan" persyaratan satu bahasa ke bahasa lain, dan membuat semua terjemahan "buram" untuk pengembang yang tidak perlu khawatir tentang fungsi apa yang mungkin diperlukan oleh pelokalan untuk baris tertentu.
Pembatalan transfer
Dalam siklus pengembangan, ada tiga situasi di mana terjemahan "dibatalkan" (menjadi tidak valid) sehubungan dengan aslinya:
- Perubahan kecil: tidak memengaruhi terjemahan (tanda baca yang benar, salah ketik).
- Perubahan sedang: memengaruhi desain pesan, tetapi tidak membatalkan kebenaran terjemahan yang terkait (misalnya, Tampilkan Semua Bookmark -> Tampilkan Manajer Bookmark ).
- Perubahan signifikan: makna baru kalimat ( Klik untuk menyimpan -> Klik untuk membuka ).
Untuk alasan arsitektural, gettext menggabungkan ketiga level menjadi satu keadaan yang disebut
fuzzy . Setiap perubahan dalam baris sumber (setidaknya lengkap, setidaknya tidak signifikan) mengarah pada pembatalan terjemahan.
Dalam Fluent, penggunaan pengidentifikasi unik memungkinkan Anda untuk memisahkan dua level ini dari yang ketiga: ketika Anda membuat perubahan
kecil pada teks sumber dari sebuah baris dan ketika Anda menyimpan pengenal, terjemahan tetap valid. Di sisi lain, jika pengembang mengubah pengenal, maka semua terjemahan dibatalkan dan akan membutuhkan pembaruan.
Kami percaya bahwa solusi arsitektur seperti itu lebih bermanfaat untuk sebagian besar siklus rilis, meskipun kami mengakui bahwa untuk perubahan tingkat
menengah , pengembang harus memilih antara menyimpan atau mengubah pengidentifikasi (mis. Antara perubahan
minor dan perubahan
signifikan ).
Kami juga mempertimbangkan gagasan untuk membuat
versi pesan agar pengembang dapat menandai pesan sebagai yang
diperbarui tanpa sepenuhnya membatalkan kontennya. Keadaan ini akan memungkinkan Anda untuk menjaga terjemahan tetap valid berdasarkan pada titik bahwa versi terjemahan yang lama masih lebih baik daripada string yang tidak diterjemahkan, dan pada saat yang sama akan memungkinkan alat untuk memberi tahu pelokalan tentang perlunya memperbarui terjemahan.
Format data
Gettext menggunakan tiga format file - * .po, * .pot dan * .mo. Ini mempengaruhi implementasi gettext dalam siklus produksi dengan menambahkan langkah-langkah seperti mengekstraksi dan mengkompilasi pesan.
Lancar menggunakan format file * .ftl tunggal, yang menyederhanakan implementasi dan tidak memerlukan langkah-langkah tambahan yang dapat menyebabkan perbedaan data.
Dukungan Unicode
Gettext dapat dikodekan dalam UTF-8. Secara umum, ini adalah di mana dukungan Unicode berakhir. Ini menggunakan set data sendiri untuk bentuk jamak, tidak tahu cara memformat tanggal dan angka, tidak membantu dalam bekerja dengan teks dua arah.
Fluent menggunakan ekstensif perpustakaan standar dan algoritma CLDR, ICU, dan ECMA402, dengan rapi menggabungkan lokalisasi dan internasionalisasi.
Kesimpulan
Kami percaya bahwa API Lancar dan sintaksis menunjukkan peningkatan signifikan atas gettext, dan kami menyarankan Anda menggunakannya untuk perangkat lunak internasional.
Lebih Lanjut Tentang Fasih