Progettare un’interfaccia multilingue con un compito concreto
Un esempio di portale mostra come prevedere testi lunghi, formati locali, traduzioni mancanti e cambio di lingua durante un’attività.

Partire da un record che non cambia
Progetti un’interfaccia multilingue su un’attività completa: aprire, esaminare e approvare una richiesta. I testi devono restare comprensibili e i dati aziendali conservare il proprio significato. Un elenco di pulsanti tradotti non mostra ancora questi rapporti.
Un portale fittizio per progetti dovrà supportare dieci lingue. La richiesta R-18 contiene l’importo numerico 1234.5, la valuta EUR e la data di calendario 2026-11-12. In questa attività la lingua dell’interfaccia non cambia valuta, importo, data o stato di approvazione. Un’interfaccia inglese non trasforma l’importo in dollari.
Definire esplicitamente i formati
Il team sceglie per il confronto queste tre impostazioni locali, cioè varianti di lingua e area geografica. L’importo appare come valuta con due decimali; la data con giorno e mese a due cifre e anno completo. Il confronto delle date usa esplicitamente il fuso orario UTC.
Impostazione locale | Importo visualizzato | Data visualizzata |
|---|---|---|
| 1.234,50 € | 12.11.2026 |
| €1,234.50 | 12/11/2026 |
| €1.234,50 | 12.11.2026 |
Intl.NumberFormat e Intl.DateTimeFormat consentono queste visualizzazioni dipendenti dalla lingua. Impostazione locale e opzioni vengono scelte esplicitamente; il valore predefinito del computer non deve modificare il confronto senza che sia notato. Una data che indica solo un giorno di calendario non deve slittare a un altro giorno cambiando lingua. Se si inseriscono importi, servono inoltre regole adeguate di immissione e verifica: un testo formattato in uscita non definisce da solo un parser sicuro degli input.
Prevedere testi lunghi e stati mancanti
Verifichi le etichette reali in viste strette e ampie. Nell’esempio, il pulsante «Approva la richiesta di progetto dopo la verifica» deve conservare il significato anche quando una traduzione richiede più spazio. Un ritorno a capo previsto o una disposizione diversa è più utile di un’abbreviazione oscura. Una percentuale fissa di ingrandimento non garantisce spazio sufficiente per ogni testo.
La copertura linguistica include anche elenchi vuoti, caricamento ed errori. Se manca la traduzione di approval.confirm, il portale dell’esempio blocca l’approvazione e mostra una spiegazione comprensibile nella lingua scelta. Per questo passaggio critico non accetta tacitamente una lingua di ripiego mescolata all’interfaccia. È una regola di prodotto scelta, non una proprietà automatica di una libreria di traduzione.
Verificare il cambio di lingua durante l’attività
Apra la stessa richiesta in ogni lingua prevista e cambi lingua durante la modifica. Nell’esempio i dati inseriti devono restare; il cambio non deve avviare l’approvazione. Verifichi poi che importo, giorno di calendario e stato ancora aperto siano conservati.
Testi di prova allungati artificialmente possono mostrare presto problemi di impaginazione. Deve comunque leggere le traduzioni finali nel contesto e verificarle nell’attività completa. Annoti per ogni lingua se l’approvazione è comprensibile e possibile senza perdita di dati, oppure quale stato preciso manca ancora.
Fonti
Continuate a leggere
Tutti gli articoli







Design & UX con ASES
Esperienza utente, interfacce e immagine del marchio

