Va bene lasciare un log avanzato non tradotto?

Quello che devi fare è configurare la registrazione per soddisfare sia le tue esigenze sia quelle del tuo capo. Il fatto è che non sei realmente obbligato a fare ciò che il tuo capo chiede ("Limita l'uso del messaggio") nel codice e privarti completamente di un'opzione per fare il logging nel modo desiderato.

Qualsiasi struttura di registrazione semipreziosa consente al programmatore di inviare messaggi di log in posizioni diverse (se il tuo attuale framework non può, hai problemi molto più grandi della traduzione).

Configura la tua registrazione in modo che ciò che si suppone sia desiderabile dalle uscite del tuo capo in una posizione (file) e ciò che consideri necessario, passi a un'altra.

Dopo di ciò, mostra un esempio di output apparentemente conforme al "boss" e verifica se questo soddisfa le loro esigenze.

Indirizzali anche sull'esempio di output "internamente necessario" e spiega che può essere completamente disattivato modificando la configurazione (il tuo framework di registrazione dovrebbe permetterlo, e se non lo fa, vedi sopra) e spiega che girandolo off renderebbe molto più difficile e costoso analizzare i problemi che potrebbero verificarsi durante l'utilizzo dell'applicazione.

La configurazione della registrazione è il modo per mantenere aperte le opzioni: indipendentemente da ciò che viene deciso inizialmente, cambiandolo in un secondo momento si otterrebbe solo la configurazione della registrazione, lasciando intatta l'applicazione.

1. Non dare per scontato che gli utenti esperti conoscano l'inglese. Vengo dalla Francia e ho trascorso un anno lavorando in un'azienda di sviluppo software dove:

   • Molti programmatori non erano in grado di leggere o scrivere in inglese,

   • La maggior parte dei programmatori odiava leggere o scrivere in inglese.

   Dato che qualsiasi programmatore dovrebbe conoscere l'inglese, puoi facilmente immaginare come i non programmatori possano conoscere l'inglese potrebbero diventare problematici (puoi, d'altra parte, aspettarti che se la tua app è indirizzata, per esempio, agli scienziati).

2. Il carattere tecnico dei messaggi può essere importante. Difficilmente vedo persone di cui ho parlato in precedenza che non erano in grado di leggere in inglese per immergersi in /var/log/ quando un server proxy o bind9 non si comportano come previsto. Molto probabilmente, non troveranno nemmeno la posizione di tali log, e anche se quei messaggi fossero localizzati, sono troppo tecnici per loro.

   D'altra parte, mi aspetto che software come Microsoft Word abbia messaggi dettagliati e localizzati quando l'app fallisce, ma è solo in grado di mostrarmi una finestra di messaggi che è allo stesso tempo chiara, dettagliata e estremamente utile: "Impossibile avviare Microsoft Word perché ha rilevato un errore imprevisto."

3. Non dare per scontato i requisiti dell'app. Non è il tuo lavoro. Non è il lavoro del tuo capo. Sono i tuoi clienti / utenti finali a cui chiedere se sono abbastanza fluenti in inglese o se i messaggi di log devono essere tradotti.

   Le funzionalità di spedizione che ti aspetti che gli utenti utilizzino senza che decidano è uno dei motivi per cui i progetti sono in ritardo e superiori al costo originariamente previsto, perché stai spendendo tempo e denaro per funzionalità che forse nessuno ha bisogno.

   • Gli utenti dicono i loro problemi: "Sono un utente esperto ma non conosco molto bene l'inglese."
   • Le persone della tua azienda che lavorano con gli utenti finali raccolgono / prevedono le statistiche. "Su 12 000 utenti, ci sono 1 500 dei nostri utenti che potrebbero essere interessati a messaggi di log tradotti e 400 utenti che sono totalmente interessati."
   • Gli sviluppatori valutano lo sforzo necessario. "Abbiamo oltre milleduecento messaggi di errore e ci vorranno due giorni per renderli dipendenti dalla lingua, ci vorranno altre due ore per integrare il lavoro dei traduttori e impiegheranno trenta minuti ogni volta che dobbiamo aggiungere o modificare un messaggio. "
   • I traduttori valutano lo sforzo necessario. "Ci vorranno tre settimane per tradurre quei messaggi in dieci lingue. "
   • I project manager valutano il costo e il programma. "Non abbiamo alcuna possibilità di spedire il supporto per Oracle per il 1 settembre ^st se abbiamo bisogno di localizzare i messaggi di registro nel frattempo."
   • Le imprese decidono. "È accettabile passare qualche mese alla traduzione, poiché in tal modo saremo in grado di affermare che il nostro prodotto è tradotto al 100% in dieci lingue e può anche aumentare le vendite internazionali offrendo un strong vantaggio rispetto alle nostre principali concorrente. "

4. Registri separati che devono essere letti dagli utenti dai log che devono essere letti dagli sviluppatori durante il debug. Gnat l'ha già descritto.

   Questo ti aiuterà a evitare di limitare le voci del registro. Avere registri dettagliati quando l'app viene eseguita in modalità dettagliata è fondamentale per mitigare il costo del debug.

   Sarai anche in grado di scrivere quei messaggi in modo diverso. Ad esempio, i messaggi di registro destinati all'utente finale potrebbero contenere informazioni quali i percorsi dei file, qualcosa che potresti ritenere troppo sensibile per includere nei registri orientati agli sviluppatori. D'altra parte, non dovresti includere lo stack trace nei messaggi di log degli utenti finali, dato che è troppo tecnico.

5. Tieni in considerazione che la traduzione di messaggi effettivi è solo una parte dello sforzo. Ciò che è più importante è che dovrai tradurre ogni nuovo messaggio e ogni modifica al messaggio esistente. Dato il fattore di dieci lingue, ciò implica molto di impegno e organizzazione, e potrebbe rapidamente diventare schiacciante per una piccola squadra.

   Potresti finire a utilizzare sempre più il log orientato allo sviluppatore (poiché impiega pochi minuti per creare un messaggio) e modificare i messaggi di log per il log degli utenti finali solo quando non hai una scelta (dato che potrebbe facilmente prendere settimane).