Localizzazione software: 15 errori UX che una traduzione automatica non vede

Una traduzione automatica può produrre frasi plausibili senza rilevare che un pulsante viene tagliato, una variabile rompe l'accordo o un messaggio invita all'azione sbagliata. Per localizzare un software bisogna verificare il testo nel componente e nel percorso d'uso, non soltanto in una tabella. I quindici errori seguenti diventano una checklist per product manager, designer e responsabili della qualità.

Errori di contesto e significato operativo

Errore 1: tradurre un verbo senza vedere l'azione

Una parola come applica può riguardare un filtro, una modifica o una candidatura. Il traduttore deve conoscere l'effetto del comando. Una descrizione della chiave e uno screenshot aiutano a scegliere un'etichetta coerente con ciò che accade dopo il clic, evitando un verbo formalmente corretto ma funzionalmente sbagliato.

Errore 2: rendere identiche azioni diverse

Salvare una bozza, pubblicare e confermare un pagamento non devono diventare lo stesso generico conferma. La distinzione linguistica rende prevedibili le conseguenze. Nei flussi critici bisogna controllare insieme titolo della finestra, testo esplicativo, pulsante principale e alternativa disponibile all'utente.

Errore 3: confondere annullamento e cancellazione

Annullare un'operazione in corso non equivale a eliminare un oggetto già salvato. La verifica deve accertare se il sistema modifica dati, chiude una finestra o ripristina uno stato. Per le azioni irreversibili il testo deve descrivere la conseguenza reale, senza introdurre promesse di recupero inesistenti.

Errore 4: alternare termini per lo stesso oggetto

Se area di lavoro diventa alternativamente progetto, spazio e account, l'utente può pensare di incontrare entità diverse. Il glossario deve definire oggetti e relazioni, non soltanto traduzioni isolate. Le eccezioni vanno motivate dal contesto, invece di dipendere dalla preferenza del singolo revisore.

Errori legati alla struttura delle stringhe

Errore 5: concatenare frammenti come frasi complete

Un'interfaccia che unisce un verbo, un numero e un nome può funzionare nella lingua sorgente e fallire altrove. L'ordine delle parole e gli accordi cambiano. Gli sviluppatori dovrebbero rendere traducibili messaggi completi, lasciando alle regole di internazionalizzazione la gestione delle parti variabili.

Errore 6: gestire soltanto singolare e plurale inglesi

Le lingue non condividono necessariamente le stesse categorie di plurale. Anche zero può richiedere una formulazione specifica nel prodotto. Il team deve usare il sistema previsto dal framework e testare i casi pertinenti alla lingua, non duplicare meccanicamente due stringhe per ogni mercato.

Errore 7: perdere o alterare le variabili

Un segnaposto può rappresentare una persona, un file o una quantità: senza questa informazione è difficile costruire la frase corretta. I controlli automatici possono verificare la presenza dei segnaposto, ma non sempre la loro adeguatezza linguistica. Occorrono descrizioni e valori di esempio realistici.

Errore 8: ignorare genere e forma di cortesia

Un messaggio costruito intorno al nome di un utente può richiedere accordi non ricavabili dai dati disponibili. Meglio valutare formulazioni che non presumano informazioni mancanti. La scelta fra tu, voi e forme impersonali deve seguire una linea editoriale, compatibile con il tono del prodotto.

Errori che emergono soltanto nell'interfaccia

Errore 9: tagliare etichette e pulsanti

La lunghezza delle traduzioni cambia e il numero di caratteri non descrive sempre lo spazio occupato. Vanno testati larghezza, ritorni a capo e comportamento responsivo. Accorciare il testo non è l'unica soluzione: talvolta serve correggere il componente anziché impoverire l'etichetta.

Errore 10: lasciare testo incorporato nelle immagini

Un banner o un tutorial può contenere parole che non compaiono nell'esportazione delle stringhe. L'inventario deve includere immagini, animazioni e schermate dimostrative. Quando possibile, separare testo e grafica rende più semplice aggiornare le lingue e migliora la gestione delle alternative accessibili.

Errore 11: usare formati locali incoerenti

Date, orari, separatori decimali e valute devono seguire regole deliberate. Una data ambigua può causare un errore operativo anche se le parole sono corrette. Il test deve verificare inoltre la distinzione fra lingua dell'interfaccia, fuso orario e impostazioni scelte dall'utente.

Errore 12: tradurre gli errori senza offrire una via d'uscita

Un messaggio che dice soltanto operazione fallita non spiega che cosa fare. La revisione deve accertare quali azioni siano davvero possibili: riprovare, correggere un campo o contattare l'assistenza. Non va suggerita una soluzione che il sistema non supporta o che esponga informazioni riservate.

Errore 13: dimenticare accessibilità e lettura assistita

Etichette visibili, nomi accessibili e istruzioni devono restare coerenti. Un'icona può essere comprensibile a schermo ma priva di una descrizione utile per chi usa tecnologie assistive. La revisione linguistica deve includere questi testi, insieme ai test tecnici condotti dal team competente.

Errore 14: mescolare lingue lungo lo stesso percorso

Email di conferma, notifiche, help center e schermate possono usare criteri linguistici diversi. Un test della sola pagina iniziale non rileva il problema. Occorre seguire il percorso completo, compresi reindirizzamenti, recupero password e contenuti generati dai sistemi collegati.

Errore 15: scambiare una stringa mancante per una scelta corretta

Il fallback alla lingua sorgente può nascondere traduzioni non caricate o chiavi errate. Il team deve distinguere la politica di fallback dai difetti di rilascio. Una schermata apparentemente funzionante può comunque escludere utenti che non comprendono il testo rimasto nella lingua originale.

Esempio illustrativo: una conferma di eliminazione

In uno scenario ipotetico, un'app B2B mostra un pulsante tradotto come rimuovi. Nella tabella sembra corretto, ma il test rivela che l'azione elimina definitivamente un progetto e tutti i file associati. Il problema non riguarda soltanto la parola: manca una spiegazione della conseguenza.

Il team verifica il comportamento con gli sviluppatori e prepara un titolo esplicito, un testo che indica l'ambito dell'eliminazione e due pulsanti chiaramente distinguibili. La traduzione viene poi testata su mobile, dove il testo precedente occupava una sola riga ma quello nuovo richiede più spazio. Si controllano anche il nome accessibile del comando e la navigazione da tastiera.

La soluzione non consiste nel dichiarare sempre sbagliata la traduzione automatica. Consiste nel riconoscere ciò che il testo isolato non permette di sapere. Il servizio di localizzazione software deve quindi collegare lavoro linguistico, progettazione e verifica in ambiente.

Un workflow per trasformare i rilievi in correzioni

Ogni segnalazione dovrebbe contenere lingua, versione, ambiente, passaggi per riprodurre il problema, schermata e proposta. La gravità dipende dall'impatto sull'utente, non dal numero di parole coinvolte. Per coordinare rilasci continui è utile il confronto fra Crowdin, Phrase e Lokalise.

Nei prodotti con contenuti web collegati, la localizzazione del sito deve seguire le stesse definizioni fondamentali. La guida alla traduzione UX delle app italiane approfondisce il rapporto fra microtesti e comportamento dell'utente.

Domande frequenti

La revisione delle stringhe sostituisce il test in app?

No. Può intercettare problemi linguistici, ma non mostra necessariamente tagli, stati dinamici o conseguenze delle azioni. I due controlli sono complementari e devono condividere glossario e criteri di accettazione.

Servono screenshot per ogni stringa?

Non sempre, ma le stringhe brevi, ambigue o legate ad azioni critiche richiedono contesto sufficiente. Descrizioni, accesso a un ambiente di prova e percorsi documentati possono integrare le immagini.

Chi deve risolvere un errore di plurale?

Dipende dalla causa. Se manca il supporto alle categorie necessarie interviene lo sviluppo; se la struttura è corretta ma il testo no interviene il team linguistico. La diagnosi deve precedere l'assegnazione della correzione.

Quando va eseguito il controllo linguistico?

Prima del rilascio, su una versione rappresentativa e dopo le modifiche rilevanti. Nei cicli continui conviene controllare le nuove stringhe e riprovare i percorsi critici, mantenendo una verifica più ampia quando cambia l'interfaccia.

Vuoi capire quali errori linguistici ostacolano davvero l'uso della tua app? Condividi lingue, flussi prioritari e modalità di accesso al test per richiedere una verifica di localizzazione.