Come rendere testabili le localizzazioni delle stringhe dei messaggi di errore

7

Sto lavorando su un'applicazione attualmente localizzata in sei lingue. Gli ingegneri di localizzazione occasionalmente verificano che tutte le loro stringhe siano appropriate al contesto e appaiano correttamente nell'applicazione.

Qualcosa che sta richiedendo sempre più tempo è la loro verifica dei messaggi di errore che è improbabile che si incontrino con un uso regolare o seguendo istruzioni specifiche. Originariamente, uno sviluppatore creava le condizioni di errore, faceva apparire l'errore in ogni lingua, prendeva screenshot e inviava quelli alla localizzazione per verificarne la correttezza.

Qualcuno ha notato che ci voleva molto tempo e ha quindi creato un'applicazione di supporto in un ramo di sviluppo. Questa applicazione di supporto, una volta avviata, mostra una finestra accanto alla finestra principale dell'applicazione con un elenco di messaggi di errore che possono essere visualizzati. Quando il tester fa clic su una voce in tale elenco, la riflessione viene utilizzata per scavare nella logica del programma e fare confusione con i campi privati e tale da creare la condizione di errore e causare la visualizzazione del messaggio di errore. Questo fa risparmiare tempo, ma non tanto, perché è difficile da mantenere ed estendere.

Mi piacerebbe trovare una soluzione migliore. Attualmente sto prendendo in considerazione il refactoring della generazione di tutti questi messaggi di errore in una classe statica e l'aggiunta della finestra "mostra i messaggi di errore" menzionata sopra al tronco dell'applicazione, per apparire solo se viene definito un determinato simbolo del preprocessore. Quindi, è possibile generare messaggi di errore in risposta a condizioni di errore effettive o semplicemente in risposta al clic di un pulsante nella finestra "mostra messaggi di errore", con lo stesso codice che genera il messaggio di errore in entrambi i casi. L'unica cosa significativa che mi preoccupa è che non saremmo in grado di essere totalmente sicuri che lo stesso messaggio di errore appaia in entrambi gli scenari di errore reale e falso, anche se questo è certamente vero anche per la soluzione di riflessione.

In che modo gli altri hanno affrontato situazioni simili?

Questa è un'applicazione C # con un'interfaccia utente WPF.

    
posta Aurast 04.08.2016 - 17:50
fonte

1 risposta

1

Prova e crea messaggi di errore generici:

"Siamo spiacenti, è successo qualcosa di brutto."

Mantenere il numero di messaggi di errore al minimo. I dettagli del messaggio di errore possono essere nella lingua del team di sviluppo e possono essere acquisiti in un file di registro.

Anche con i messaggi di convalida, non essere specifici. Usa:

"Il campo è obbligatorio."

Quindi evidenzia il campo nel modulo con convalida non riuscita.

Utilizza al posto di messaggi specifici come "Nome richiesto". o simili. Utilizzare indicatori visivi o simboli anziché testo. In pratica, limita l'uso del testo sui messaggi di errore.

Per quanto riguarda i test, non esiste un modo semplice per testare. Potresti scrivere test unitari e impostare la cultura locale corrente per testare ogni lingua:

CultureInfo cultureInof = new CultureInfo("fr-FR");
Thread.CurrentThread.CurrentCulture = ci;
Thread.CurrentThread.CurrentUICulture = ci;

Quindi potresti aggiungere una serie di asserzioni per tutte le stringhe localizzate per assicurarti che la cultura sia impostata su un certo valore e che venga restituita la stringa corretta. Questo dovrebbe essere automatizzato. Ma, in realtà, hai bisogno di un umano che guardi lo schermo. Non solo il testo deve essere corretto, ma deve adattarsi correttamente all'interfaccia utente, non essere troncato, posizionato correttamente, ecc.

    
risposta data 04.08.2016 - 22:28
fonte

Leggi altre domande sui tag