Di mana saya harus melakukan pelokalan (sisi server atau sisi klien)?


17

Saat ini saya sedang mengembangkan aplikasi web baru berdasarkan klien JavaScript kaya yang berkomunikasi dengan beberapa layanan web REST di server saya. Aplikasi itu dimaksudkan untuk digunakan di setidaknya dua negara dengan bahasa yang berbeda, jadi kita perlu melokalkannya.

Pertanyaan saya adalah di mana saya harus mengelola pelokalan: haruskah layanan REST menerima permintaan dan mengirim jawaban dengan data yang dilokalkan, atau haruskah klien menerima dan mengirim data umum dan kemudian bertanggung jawab untuk melakukan pelokalan?

Jawaban:


19

API REST Anda akan lebih mudah digunakan oleh orang lain jika Anda memberikan ID string daripada string yang diterjemahkan. Menggunakan API yang mengembalikan "E_NOT_AUTHORIZED"lebih mudah daripada jika mengembalikan beberapa bahasa manusia, dan bahkan string yang dilokalkan.

Juga, Anda mungkin ingin mengubah string terlokalisasi di versi mendatang, yang akan menjadi perubahan API melanggar. Dengan pendekatan ID string, Anda masih kembali "E_NOT_AUTHORIZED", menjaga API Anda tetap kompatibel.

Jika Anda menggunakan kerangka kerja seperti Angular.js , mudah untuk menerapkan hot-switching bahasa jika Anda menggunakan pendekatan ID string. Anda cukup memuat tabel string lain, dan semua string secara otomatis mengubah bahasa mereka karena Anda hanya menggunakan beberapa logika filter dalam template Anda, seperti {{errorStringID | loc}}.

Pertimbangan lain: Untuk mengurangi beban server Anda, jaga agar back-end Anda sesederhana mungkin. Anda akan dapat melayani lebih banyak klien dengan jumlah server yang sama. Kirimkan stringtable Anda melalui CDN, dan lakukan pelokalan di front-end.


5

Mintalah klien mengirim Accept-Languagetajuk standar dalam permintaan, lalu lokalkan di server dan sertakan Content-Languagetajuk sebagai tanggapan. Lihat RFC 7231 Bagian 5.3.5 untuk detailnya.

Pelokalan di sisi server menghasilkan round trip dan konsumsi bandwidth yang lebih sedikit daripada mengirimkan metadata pelokalan klien. Tetapi server tidak dapat mengasumsikan bahasa apa yang diinginkan klien, karena bagaimana jika klien itu adalah proxy yang melayani orang lain? Bagaimana jika ada lapisan caching antara klien dan server? Bagaimana server seharusnya "mencari tahu" bahasa apa yang harus digunakan untuk beberapa permintaan sewenang-wenang?

Mencoba menjawab pertanyaan-pertanyaan itu rumit, jadi alih-alih minta agar permintaan itu bersifat deskriptif sendiri dan gunakan tajuk standar agar klien dapat menegosiasikan bahasa apa yang mereka inginkan. Itu disebut negosiasi konten. The Accept-Languageheader bentuk proaktif negosiasi konten mana klien memberitahu server apa preferensi itu adalah, maka server memutuskan apa yang harus merespon dengan berdasarkan preferensi mereka. Negosiasi konten reaktif adalah di mana klien mengirim permintaan bertanya kepada server jenis konten apa yang ada, biasanya menerima respons yang berisi daftar tautan, dan kemudian memilih yang mana yang diinginkan dengan memilih tautan yang akan diikuti.


3

Saya akan mengatakan sebanyak mungkin di sisi server jika Anda akan mendukung beberapa perangkat.

Setiap perangkat tentu saja akan menggunakan beberapa terjemahan sendiri tetapi dibagikan sebagai pesan kesalahan dari api dll akan sama terlepas dari perangkat.


2
Saya tidak yakin mengerti mengapa. Untuk hal-hal yang dibagikan, bahkan jika klien melakukan pelokalan, saya pikir saya akan menggunakan "kamus" yang berasal dari server, dan bahwa saya dapat membagikan kamus itu di antara perangkat saya. Atau maksud Anda sesuatu yang lain? (Dalam kasus saya, saya hanya akan menggunakan satu perangkat, tetapi komentar yang menarik)
gvo

1

Ini adalah masalah selera pribadi, tetapi jika Anda melakukan hal-hal di sisi klien, Anda akan menghemat beban server (dengan asumsi kamus statis atau cache), dan dapat menggunakan alat agnostik bahasa untuk menguji layanan.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.