Mengapa sumber daya string umumnya disimpan di luar kode dan tidak di dalam kode?

18

Secara umum, pada banyak platform, saya menulis sumber daya string saya ke file .resx atau .xml, dan kemudian saya membuatnya menggunakan beberapa pendekatan yang bergantung pada platform.

Yaitu, di iOS, saya mendapatkannya melalui NSBundle.MainBundle, dan dengan menggunakan Context.Resourcesdi Android.

Apa kelebihan dari pendekatan ini, dan mengapa tidak dapat diakses langsung dalam kode, jadi, misalnya:

Dalam proyek lintas-platform, platform apa pun dapat mengaksesnya secara langsung, tanpa integrasi.
Tidak ada kekhawatiran selama membangun tentang apakah sumber daya dibangun dengan baik atau tidak.
Coder dapat menggunakan fungsi seperti penanganan multi bahasa

Singkat cerita: apa alasan mengapa sumber daya string terstruktur seperti itu?

[Sunting]

Katakanlah file saya adalah bagian dari proyek "inti" yang dibagikan di antara proyek lain. (Pikirkan tentang struktur file proyek lintas platform PCL.)

Dan misalkan file saya benar-benar mirip dengan file .resx / .xml, terlihat seperti ini (saya bukan pro dalam xml, maaf!): Parameters Paramètres

Jadi, ini pada dasarnya adalah xml khusus, di mana Anda menunjuk ke kunci / bahasa untuk mendapatkan string yang tepat.

File akan menjadi bagian dari aplikasi sama seperti Anda menambahkan file yang dapat diakses di dalam aplikasi, dan sistem untuk mengakses sumber daya string, yang dikodekan menggunakan PCL. Apakah ini menambah overhead ke aplikasi?

cross-platform resources internationalization

— Léon Pelletier
sumber

kemungkinan duplikat Internasionalisasi: Hal-hal apa yang dipikirkan?

— nyamuk

6

Tidak, kekhawatiran saya bukan tentang Internasionalisasi, dan lebih pada arsitektur dan lintas-platform, maaf.

— Léon Pelletier

1

Pertanyaan ini dapat digeneralisasi ke sumber daya apa pun, sungguh, bahkan dengan mudah lokalisasi / internasionalisasi samping. Apa keuntungan memisahkan sumber daya dari kode? Mengapa file gambar atau audio biasanya tidak dikodekan dalam sumber sebagai string biner? (Data URI memang ada, tentu saja, tetapi umumnya tidak praktis untuk file besar). Yang lain telah memberikan beberapa jawaban yang cukup bagus, tetapi saya hanya ingin menunjukkan bahwa string yang dapat dibaca pengguna bukan satu-satunya jenis sumber daya yang mendapatkan manfaat dari dieksternalisasi.

— JAB

38

Lokalisasi dan internasionalisasi,

Menjaga string eksternal memungkinkan mereka untuk mengubah (baca: diterjemahkan) tanpa perlu mengkompilasi ulang (hanya relink paling banyak, dan hanya memasukkan folder baru di terbaik).

— ratchet freak
sumber

Relink vs recompile ini adalah alasan yang bagus, terima kasih.

— Léon Pelletier

2

Masih satu-satunya orang yang mengerti pertanyaan itu.

— Léon Pelletier

3

@ scratchetfreak itu bentuk buruk untuk menerima terlalu cepat (dalam hitungan jam pasti dihitung.) Tidak memberikan waktu untuk jawaban lain muncul. Ini sederhana, dan to the point dan akurat ... tetapi seseorang mungkin membawa jawaban yang lebih lengkap, lebih rinci besok (atau bulan depan dalam hal ini).

— WernerCD

3

Ekstra: Mungkin baik bagi penerjemah untuk mengedit file XML, tetapi jangan pernah membiarkan mereka mengutak-atik kode yang sebenarnya ...

— Darkhogg

Sekarang pertanyaannya adalah: "Apakah jawaban ini masih berlaku untuk bahasa yang ditafsirkan?". Saya bertanya karena tidak akan ada pemasangan kembali atau kompilasi ulang.

— Thomas Eding

10

Jika Anda memiliki file yang hanya berisi sumber daya string maka Anda dapat memberikan file sumber daya ke agensi terjemahan atau sesuatu seperti itu dan mendapatkan terjemahan. Saya kira Anda dapat membayangkan betapa sulitnya itu jika Anda harus memberikan banyak file kode kepada orang awam untuk melakukan beberapa terjemahan (selain itu mungkin tidak ingin memberikan kode Anda kepada siapa pun).

— Flo
sumber

2

Ya, tidak ada perbedaan antara file yang disertakan dalam proyek dan file sumber daya. Masalahnya tidak ada.

— Léon Pelletier

Saya berbicara tentang memasukkan sumber daya secara langsung dalam kode dan kemudian menangani semua yang ada di dalam program, sehingga lebih ramah PCL / Cross-platform.

— Léon Pelletier

2

jika Anda memiliki file "kode" dengan semua sumber daya string Anda (kamus definisi atau sesuatu seperti itu) dan tidak ada yang lain di dalamnya .. baik daripada itu pada dasarnya adalah file sumber daya (tetapi satu untuk platform tunggal, seperti misalnya. android tidak akan ambil kode objektif-c). Jika ada kode lain di dalamnya atau jika dibagi beberapa file daripada mendapatkan terjemahan eksternal lebih sulit. Dalam tampilan lintas platform, format teks seperti xml memiliki keuntungan yang bisa Anda baca dan gunakan pada bahasa / platform apa pun (tetapi Anda mungkin harus membuatnya lebih baik)

— Flo

7

Selain internasionalisasi / pelokalan, memisahkan string teks seperti ini juga memungkinkan korektor proofreader untuk mengirimkan koreksi ke pengejaan / tata bahasa / tanda baca yang diisolasi messages.${LOCALE}, tanpa harus menyentuh file kode sumber yang benar. Anda mungkin mengalami pemadaman perubahan kode tetapi menerima koreksi teks tersebut. Jika Anda menerima perubahan bersamaan untuk kedua kode dan pesan, memisahkannya membuatnya lebih mudah untuk menggabungkan tambalan, asalkan perubahan kode tidak mendefinisikan kembali pesan yang ada saat proofreader memeriksa messages.en_US.

Juga, tergantung pada bagaimana penerapannya, bahkan mungkin tidak perlu untuk menautkan kembali aplikasi. Kode dapat dengan mudah mengambil baris 138 dari messages.${LOCALE}untuk pesan tertentu, dengan nomor baris ditentukan pada saat run time.

— Monty Harder
sumber

0

Ini hanya cara bahasa / platform Anda memutuskan untuk menerapkan pelokalan string. Semua pendekatan untuk pelokalan memerlukan beberapa jenis file sumber daya eksternal untuk mendapatkan terjemahan. Titik sakit utama adalah bagaimana Anda mempertahankan sumber daya ini.

Sepertinya Anda perlu mengelola file sumber daya ini secara manual , yang dapat menjadi beban. Ini juga mempersulit pembagian string yang berulang. Dan harus melakukan ini ketika Anda saat ini hanya mengirim satu bahasa, bahkan lebih membebani.

Alternatif umum adalah pendekatan GNU Gettext yang hanya menandai string yang dapat diterjemahkan dalam kode sumber dan secara otomatis mengekstraksi string ini ke file PO standar yang berfungsi dengan baik lintas platform dan lintas bahasa. Dari perspektif pengembang, ini mengalahkan pemeliharaan manual file sumber daya XML setiap hari.

— Rene Saarsoo
sumber