Ha senso internazionalizzare i log?

Le risposte date qui sono troppo legate al punto di vista dello sviluppatore. Tuttavia, il software è fatto per essere usato (e letto) dagli umani (utenti), la maggior parte di loro non ha idea di debugging, log pattern, standard, ecc ...

Diciamo che abbiamo un prodotto che registra la sua attività a diversi livelli. È richiesto che il prodotto abbia un dashboard o un pannello di controllo in cui gli utenti possano monitorare l'attività. Di conseguenza, le tracce del registro sono obbligatorie per essere leggibili dagli utenti anziché dagli sviluppatori o dai tecnici .

Inoltre, gli utenti potrebbero provenire da località diverse. Che cosa significa, che registra i formati delle date, i simboli numerici e di valuta, ecc. Dovrebbe andare di conseguenza con la posizione dell'utente.

In tale situazione, perché i registri non dovrebbero essere localizzati?

Anche se è vero che i registri dovrebbero essere leggibili dalla macchina, nulla impedisce di implementare un processo di registrazione parallela un po 'più user-friendly.

Sono d'accordo che l'inglese sia la lingua standard per i log. Ma tutti questi "standard" sono De Facto Standard . Quindi, a questo punto, dobbiamo essere flessibili.

Detto questo, se trovi una buona ragione per usare la funzione di localizzazione di slog4j, vai avanti. È stato creato per una buona ragione.

Uno di questi motivi potrebbe essere che le applicazioni di oggi funzionano in un contesto mondiale e non tutti parlano / leggono / scrivono la tua lingua (o inglese). Forse, nemmeno l'helpdesk del tuo prodotto fa.

Quando gli sviluppatori parlano di "log", si riferiscono più spesso a file di testo semplice contenenti informazioni che non hanno senso al di fuori del contesto del codice specifico che li ha registrati e non hanno uno scopo diverso dalla risoluzione di quel codice quando qualcosa va storto .

Quando gli sviluppatori parlano di "internazionalizzazione", spesso significano "quando l'utente è un oratore del linguaggio X usa la stringa tradotta nella lingua X invece della stringa predefinita".

Date queste definizioni specifiche, i log internazionalizzati sono quasi sempre una cattiva idea , perché:

1. Di solito, il set di lingue che tutti dei tuoi sviluppatori possono parlare fluentemente è molto più piccolo del set di lingue che qualsiasi dei tuoi utenti potrebbe essere madrelingua. Pertanto, se internizzi i log, è più probabile che i tuoi sviluppatori non riescano a capirli.

2. Solitamente, la maggior parte dei tuoi utenti non sono gestori attivi del software che stanno utilizzando. Pertanto, i tuoi clienti non inglesi non sarebbero in grado di comprendere i log anche se fossero internazionalizzati, perché la maggior parte dei messaggi di log riguarderanno specifici pezzi di codice e vari dettagli di implementazione che semplicemente non sono e non dovrebbero mai saputo.

3. L'internazionalizzazione di un messaggio vanifica completamente la possibilità di effettuare ricerche di testo per quel messaggio, sia che gli sviluppatori eseguano ricerche nel loro codice che utenti che cercano in Internet soluzioni alternative.

4. L'internazionalizzazione introduce la possibilità di errori di traduzione o sottili ambiguità, che sono completamente inaccettabili nel contesto della risoluzione dei problemi del software. È lo stesso problema della registrazione di timestamp senza un timezone esplicito; devi costantemente perdere tempo a capire cosa significa in realtà.

Naturalmente, se rilassiamo le definizioni e le ipotesi con cui ho iniziato, ci sono alcuni casi d'uso validi.

In generale, i "log internazionalizzati" sono potenzialmente utili quando c'è un sottoinsieme facilmente identificabile di messaggi di registro che sono significativi per l'utente medio, e quando "internazionalizzazione" significa un separato accedi alla lingua dell'utente insieme al registro della lingua predefinito per gli sviluppatori.

In pratica, se qualcosa che potresti chiamare un "registro internazionalizzato" è in realtà utile, allora probabilmente sarà comunque una funzione dell'applicazione.

Alcuni tipi di videogiochi fanno questo, in particolare quelli che si comportano come i giochi da tavolo:

_{Fonte:BloodBowl,screenshottrattoda link}

Se i "registri" sono considerati estremamente utili o una funzionalità critica, è più probabile che finiscano in un database corretto piuttosto che in semplici file di testo. Il software di monitoraggio delle vendite è un tipico esempio di questo:

_{Fonte: link}

Indipendentemente dal fatto che chiami questi "log", il testo che vedi in queste immagini è chiaramente qualcosa che vorremmo internazionalizzare se mantenessimo questi problemi.