Apakah masuk akal untuk menginternasionalkan log?


8

Apa kasus penggunaan yang valid untuk menginternasionalkan log? Terutama, apakah ada kegunaan yang masuk akal untuk aplikasi web.

Saya sedang mengerjakan konversi log logging yang digunakan oleh aplikasi web dari log4jke slf4j, dan memperhatikan bahwa antarmuka yang digunakan untuk abstrak atas log4jimplementasi mendukung internasionalisasi; Saya juga melihat bahwa kedua log4jdan slf4jdukungan internasionalisasi, yang berarti harus berguna untuk seseorang.

Sekarang, internasionalisasi mungkin berguna ketika memprogram aplikasi desktop, di mana log dapat dilihat oleh pengguna akhir, tetapi fasad logging ini hanya digunakan di sisi server untuk beberapa aplikasi web, oleh pengembang yang diharuskan menggunakan bahasa Inggris secara umum. .


2
berikut ini adalah satu kasus penggunaan nyata: internasionalisasi (parsial) log diperlukan agar pesan ditampilkan di "Panel konsol lanjutan"
gnat

8
Log dalam bahasa selain bahasa Inggris membuat lebih sulit untuk menemukan bantuan online, karena itu mengurangi jumlah hasil yang cocok di Google.
Tulains Córdova

4
Saya menghabiskan berjam-jam dalam sehari menggunakan berbagai aturan penyaringan pada log. Jelas internasionalisasi entri membuat itu jauh lebih sulit
Gort the Robot

Saya bertanya-tanya apakah beberapa orang downvote ketika mereka benar-benar berarti "tidak, melakukan ini salah" ... Bukan itu yang downvoting adalah untuk: /
Andres F.

@AndresF. Jika komentar Anda terlampir pada jawaban, saya sangat tidak setuju dengan Anda. Meskipun pertanyaan ini memang bisa dijawab, pertanyaan itu juga ada di sisi hal-hal yang berdasarkan pendapat. Satu downvote tidak terlalu buruk.
jpaugh

Jawaban:


6

Jawaban yang diberikan di sini terlalu terikat pada sudut pandang pengembang. Namun, perangkat lunak dibuat untuk digunakan (dan dibaca) oleh manusia (pengguna) yang sebagian besar dari mereka tidak tahu tentang debugging, pola log, standar, dll ...

Katakanlah kita memiliki produk yang mencatat aktivitasnya pada level yang berbeda. Diperlukan produk untuk memiliki dasbor atau panel kontrol di mana pengguna dapat memantau aktivitas. Karena itu, jejak log harus dapat dibaca oleh pengguna, bukan pengembang atau teknisi .

Apalagi, pengguna bisa dari lokasi yang berbeda. Apa artinya, bahwa format tanggal log, simbol numerik dan mata uang, dll harus sesuai dengan lokasi pengguna.

Dalam situasi seperti itu, mengapa log tidak boleh dilokalisasi?

Meskipun benar bahwa log harus dapat dibaca mesin, tidak ada yang mencegah kita dari menerapkan proses pencatatan paralel yang sedikit lebih ramah pengguna.

Saya setuju dengan bahasa Inggris sebagai bahasa standar untuk log. Tetapi semua "standar" semacam ini adalah Standar De Facto . Jadi pada titik ini, kita harus fleksibel.

Yang sedang berkata, jika Anda menemukan alasan yang baik untuk menggunakan fitur pelokalan slog4j, silakan. Itu dibuat untuk alasan yang bagus.

Salah satu alasan ini mungkin karena aplikasi hari ini berjalan pada konteks dunia, dan tidak semua orang berbicara / membaca / menulis bahasa Anda (atau bahasa Inggris). Mungkin, bahkan helpdesk produk Anda tidak.


Anda membuat poin yang bagus. Menggunakan kerangka logging untuk mengirim pesan (diinternasionalkan) ke pengguna akhir masuk akal; mengapa menemukan kembali logging ketika sudah ada di sana?
jpaugh

1
Saya kira itu masalah penyesuaian. Kami membutuhkan / menginginkan fitur tambahan. Tetapi kita sering "menciptakan kembali roda" :-)
Laiv

2
Saya punya roda, yang saya buat sendiri. Itu adalah roda terbaik, lamanya! Itu lebih bersinar, lebih bulat dari yang lainnya. Tapi, itu tidak cocok dengan mobil yang ada. Saya perlu membuat mobil agar pas dengan roda saya ... ;-)
jpaugh

11

Ketika pengembang berbicara tentang "log", mereka paling sering merujuk pada file teks biasa yang berisi informasi yang tidak berarti di luar konteks kode tertentu yang mencatatnya dan tidak memiliki tujuan selain memecahkan masalah kode itu ketika terjadi kesalahan.

Ketika pengembang berbicara tentang "internasionalisasi", mereka paling sering berarti "ketika pengguna adalah penutur bahasa X menggunakan string yang diterjemahkan ke bahasa X alih-alih string default".

Dengan definisi-definisi spesifik itu, log-log yang diinternasionalkan hampir selalu merupakan ide yang buruk , karena:

  1. Biasanya, rangkaian bahasa yang dapat digunakan oleh semua pengembang Anda dengan lancar jauh lebih kecil daripada serangkaian bahasa yang mungkin digunakan oleh pengguna mana pun yang menggunakan bahasa asli. Oleh karena itu, jika Anda menginternasionalkan log, kemungkinan besar pengembang Anda tidak akan tidak bisa memahaminya.

  2. Biasanya, sebagian besar pengguna Anda bukan pengelola perangkat lunak aktif yang mereka gunakan. Dengan demikian, pelanggan non-Inggris-spekaing Anda tidak akan dapat memahami log bahkan jika mereka diinternasionalkan, karena sebagian besar pesan log akan tentang potongan kode tertentu dan berbagai detail implementasi yang mereka tidak dan tidak seharusnya lakukan. pernah tahu tentang.

  3. Internasionalisasi pesan benar-benar mengalahkan kemampuan untuk melakukan pencarian teks untuk pesan itu, baik itu pengembang yang mencari kode mereka atau pengguna yang mencari di internet untuk mencari solusinya.

  4. Internasionalisasi memperkenalkan kemungkinan kesalahan terjemahan atau ambiguitas halus, yang sepenuhnya tidak dapat diterima dalam konteks pemecahan masalah perangkat lunak. Ini masalah yang sama dengan mencatat cap waktu tanpa zona waktu yang jelas; Anda terus-menerus harus membuang waktu untuk mencari tahu apa artinya sebenarnya.


Tentu saja, jika kita mengendurkan definisi dan asumsi yang saya mulai dengan, maka ada beberapa kasus penggunaan yang valid.

Secara umum, "internasionalisasi log" berpotensi berguna ketika ada subset mudah-diidentifikasi pesan log yang adalah berarti untuk rata-rata pengguna, dan ketika "internasionalisasi" sarana terpisah log dalam bahasa pengguna samping log bahasa default untuk para pengembang.

Dalam praktiknya, jika sesuatu yang bisa Anda sebut "log internasionalisasi" sebenarnya berguna, maka itu mungkin akan menjadi fitur aplikasi.

Beberapa jenis video game melakukan ini, terutama yang berperilaku seperti permainan papan:

masukkan deskripsi gambar di sini

Sumber: Blood Bowl, tangkapan layar diambil dari https://www.youtube.com/watch?v=UyQB4kDMZzE

Jika "log" dianggap sangat berguna atau fitur penting, mereka lebih cenderung berakhir di database yang tepat daripada hanya file teks. Perangkat lunak pelacakan penjualan adalah contoh khas dari ini:

masukkan deskripsi gambar di sini

Sumber: http://www.everlogic.com/i-want-to/see-screenshots/

Apakah Anda akan memanggil atau tidak "log" ini, teks yang Anda lihat dalam gambar-gambar ini jelas merupakan sesuatu yang ingin kami internasionalkan jika kami mempertahankan masalah ini.


Anda datang dari sudut pandang saya. Tapi, menggunakan kembali log logging yang ada untuk mengirim pesan status ke pengguna masuk akal, sekarang saya sudah memikirkannya. Lebih mudah untuk menambahkan internasionalisasi ke log daripada membuat logger khusus ad-hoc untuk UI.
jpaugh

Bayangkan Anda memiliki bug yang hanya terjadi pada versi yang dilokalkan ke Jepang. Dan devs Anda telah menambahkan logging yang akan membuatnya sangat mudah untuk menemukan dan memperbaiki bug. Kecuali logging Anda dalam bahasa Jepang, dan tidak ada devs Anda dapat memahaminya :-(
gnasher729

Tidak masalah, beri tahu saya kode kesalahan dan input data yang menyebabkan kesalahan. :-)
Laiv
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.