Risposta.

La prima onda di automazione dei test non ha praticamente toccato il controllo della localizzazione (i18n), poiché i principali mercati erano orientati verso interfacce in lingua inglese. Tuttavia, con la globalizzazione delle applicazioni, le richieste di qualità della localizzazione sono aumentate: l'interfaccia deve essere visualizzata correttamente in tutte le lingue supportate e le risorse testuali e le stringhe formattate devono essere caricate correttamente a seconda della locale selezionata.

Il problema principale è che il controllo manuale è molto oneroso e i test automatici sono complessi a causa della variabilità del formato, del contesto, delle specifiche delle lingue (ad esempio, da destra a sinistra o peculiarità grammaticali). Può mancare la traduzione di un frammento, ci possono essere errori di formattazione, violazioni del layout.

Le soluzioni includono l'elaborazione di dati di test per ogni locale, l'uso di test snapshot, il confronto degli elementi UI con gli standard, l'introduzione di utility di controllo secondo il principio "chiave-valore" per i file delle risorse, l'estrazione automatizzata e il confronto delle stringhe tramite API e l'esecuzione regolare di linters sui file delle risorse.

Caratteristiche chiave:

Verifica della presenza e visualizzazione corretta di tutte le lingue supportate.
Confronto delle traduzioni di riferimento con la visualizzazione attuale nell'interfaccia.
Validator per lunghezza e formattazione dei testi per evitare violazioni del layout.

Domande trabocchetto.

È possibile creare un test universale che valida qualsiasi locale con uno script?

In parte sì, ma le peculiarità delle lingue (casi, genere, direzione dell'input) richiedono spesso modifiche manuali o condizioni aggiuntive in tali test. La 100% di universalità non è possibile.

Se il file di traduzione è presente e caricato con successo, ciò significa che il test i18n è passato?

No. Il file potrebbe essere collegato erroneamente dal lato dell'applicazione, ci potrebbe essere un errore nella chiave, il contesto di utilizzo della traduzione potrebbe essere compromesso, potrebbero esserci caratteri speciali non considerati, ecc.

Ha senso automatizzare i test di localizzazione per lingue con < 1% di utenti?

Sì, se la criticità aziendale anche di un solo utente è alta, ad esempio nel rispetto degli obblighi contrattuali o per mercati con requisiti specifici. L'automazione riduce notevolmente le risorse rispetto ai controlli manuali.

Errori tipici e anti-pattern

Controllo solo della presenza del file e non della reale visualizzazione nell'UI.
Confronto rigido delle stringhe senza considerare le peculiarità grammaticali e i formati delle lingue.
Copia cieca dei test da una locale all'altra senza adattamento.

Esempio della vita reale

Caso negativo

Il team ha implementato test automatici per confrontare le chiavi nel file .po con il testo originale in inglese, ritenendo che fosse sufficiente. Non sono stati scritti test UI - nella release della versione araba si è scoperto che tutto il testo era uscito dai pulsanti e alcune stringhe non venivano tradotte affatto a causa di chiavi errate.

Vantaggi:

Rapida implementazione dell'automazione per i18n.

Svantaggi:

Basso livello di copertura dei reali scenari utente.
Errori UX significativi sono rimasti non notati.

Caso positivo

È stata realizzata una combinazione di linting delle risorse e test automatici che rotazionavano l'interfaccia tra tutte le lingue, scattavano schermate e confrontavano con il layout standard. Rilevando la mescolanza di elementi RTL/LTR, il team ha identificato e risolto la causa principale prima della release.