Devo localizzare i messaggi di eccezione?

Credo che i registri e le eccezioni siano per gli sviluppatori, quindi dovrebbero essere nella lingua migliore per adattarsi al team di sviluppo. Questa potrebbe essere la loro lingua madre, tuttavia potrebbe essere (e a giudicare dai commenti è spesso) l'inglese. Ciò consente agli sviluppatori di lavorare in una lingua a loro familiare e di non dover tradurre da francese, spagnolo o cinese per risolvere un problema.

Tuttavia, i tuoi utenti potrebbero non essere tutti anglofoni.

Per offrire la migliore esperienza utente, potresti voler localizzare qualsiasi messaggio di errore che ritieni necessario visualizzare all'utente.

Potresti farlo in diversi modi:

public class LocalisedException : Exception
{
   public string LocalErrorMessage {get; protected set;}
   public LocalisedException(string localErrorMessage, string englishMessage)
     :base(englishMessage)
   {
      this.LocalErrorMessage = localErrorMessage
   }       
}

Or (e probabilmente il modo in cui lo farei io):

try
{
  DoSomethingExceptional();
}
catch(Exception ex)
{
  _log.Error("There was an error", ex);
  this.DisplayErrorMessage(LanguageResourceFile.ThereWasAnError);
}

Il mio sospetto è che l'autore dell'articolo che hai linkato presuma che tu stia visualizzando Ex.ErrorMessage direttamente agli utenti finali. Non lo farei, ad esempio il messaggio di errore contiene spesso dettagli tecnici (e talvolta anche sensibili) e pertanto non dovrebbe essere mostrato. Ti fa anche pensare a ciò che stai presentando all'utente. Catturare, loggare e scusarsi ti fanno prendere quell'abitudine.

In sintesi. Mi assicurerei che le eccezioni e i log fossero il più possibile semplici e accessibili per gli sviluppatori. Assicurati però che il tuo sito web (e i messaggi di errore visualizzati) siano i più chiari possibile per gli utenti.

Secondo me il messaggio di eccezione non dovrebbe essere tradotto.

• se lo sviluppatore è in grado di riprodurre la situazione eccezionale nel proprio ambiente di sviluppo, il messaggio non è affatto necessario, possono semplicemente collegare un debugger e configurarlo per interrompere l'eccezione. I messaggi di eccezione hanno più senso per i guasti non riproducibili che si verificano solo nell'ambiente di produzione

• nella maggior parte dei casi, mostrarli all'utente non ha senso. Sono troppo tecnici per questo. Dovrebbero piuttosto essere registrati e gli utenti dovrebbero ottenere una descrizione specifica dell'applicazione di ciò che ha fallito.

• per l'ambiente internazionale, i messaggi localizzati da librerie di terze parti sono molto più difficili da investigare. Anche quando ho il testo del messaggio, la traduzione automatica fornisce solo informazioni approssimative. Inoltre, ad alcune persone piace inviare uno screenshot al posto del testo, che è quasi inutile per alcuni testi in giapponese o arabo.

No, dovresti localizzare i messaggi di errore. I tuoi utenti non dovrebbero mai vedere un messaggio di eccezione. Questo è solo per i tuoi registri.

Le eccezioni non dovrebbero mai accadere se l'app funziona. Ad esempio, se si desidera aprire un file, verificare che esista e quindi aprirlo. Non provare ad aprire e lanciare un'eccezione se fallisce.

Ovviamente questo non significa che non puoi dire all'utente che il file non esiste! Significa solo che ricevono un messaggio di errore localizzato e di facile utilizzo, non un messaggio di eccezione

In questo modo tutte le eccezioni possono essere considerate come un arresto anomalo e un semplice "È successo qualcosa di brutto!" il messaggio può essere presentato all'utente, mentre il team delle operazioni riceve il messaggio di eccezione con i dettagli su cosa è andato storto.

* Ovviamente se stai creando classi di eccezioni personalizzate in una libreria multinazionale, loro avranno bisogno di messaggi localizzati per il consumo da parte degli sviluppatori di prodotti che usano la libreria.