Messaggi di errore e numeri di errore multilingue

Nelle applicazioni che ho fatto che dovevano essere multi-lingue usiamo un approccio di tipo tabella per contenere ogni set di stringhe di lingue. L'accesso alla tabella avviene tramite un'enumerazione. Questo più i codici di errore che sono universali consentirebbe all'utente di vedere il tuo messaggio di errore mantenendo un valore di codice per aiutare il team di sviluppo. Come altri hanno già detto, l'utente finale preferirebbe visualizzare gli errori nella propria lingua nativa piuttosto che nella propria.

Se hai le traduzioni nel tuo database, allora hai la possibilità di tradurle in inglese. Dopo un po 'sarai fluente nei messaggi di errore globalizzati:)

My suggestion is to not worry about that and focus on being user friendly.

Tieni presente che gli oratori non inglesi apprezzeranno molto gli errori nella loro lingua.

Assicurati di avere le traduzioni corrette, questa sarebbe la mia preoccupazione.

Sarebbe possibile che il programma generi un file di log degli errori che l'utente può inviarti? Meglio ancora se esiste uno strumento separato di segnalazione degli arresti anomali (che ovviamente dovrebbe essere tradotto in altre lingue, ma è probabilmente più facile che tradurre tutti i messaggi stessi) che invierà tutti i dati di errore a una casella postale speciale dalla tua parte. In questo modo, anche se non capiscono il messaggio molto bene, possono inviarti il registro degli errori e puoi analizzarlo in dettaglio. So che il numero di errore non è il tuo metodo preferito, ma questo o il file di errore sembra funzionino.

Poiché I18N non è stato preso in considerazione all'inizio, subirai più problemi, quindi gestirai semplicemente i codici di errore.

Il layout degli elementi dell'interfaccia utente per quanto riguarda la struttura delle frasi e la crescita che può verificarsi quando viene introdotta una nuova lingua è uno dei più comuni. Inoltre, formare dinamicamente frasi o altre rappresentazioni testuali al volo e quindi legare quel risultato all'interno di vari elementi dell'interfaccia utente è un altro avvertimento.

Il mio punto è che la presentazione di messaggi di errore sarebbe in definitiva la parte più facile da indirizzare poiché sono generalmente isolati in una finestra di dialogo; mentre altra rappresentazione testuale all'interno della tua applicazione non è.

L'approccio che raccomanderei è quello di utilizzare pacchetti di lingue e quindi implementare una struttura di imballaggio per la rappresentazione testuale del prodotto. Ciò consentirebbe di avere un. Zip o altra struttura che potrebbe essere caricata e utilizzata in fase di esecuzione.

Quando si desidera cambiare lingua, è possibile rilasciare il pacchetto lingua desiderato e riavviare l'applicazione. Il pacchetto lingua sarà costituito da tutti i dati testuali necessari in tutta l'applicazione. Come un errore emerge dal back-end viene usato un codice che è specifico del prodotto tra il client e il server e non è progettato per essere visualizzato dall'utente. Questo codice viene quindi mappato su un determinato errore lato client che è anche statico e non cambia. Il valore che quell'errore contiene sul lato client sarà la parte dinamica che è stata estratta dal pacchetto lingua all'avvio. È quindi possibile creare un proxy tra i dati estratti dal pacchetto lingua e i valori di riferimento all'interno del codice; consente di utilizzare la tipizzazione strong in tutto il prodotto, ma offre la capacità dinamica che cerchi in termini di lingue diverse.