Come progettare per l'espansione del testo

L’espansione del testo diventa un problema di layout quando l’interfaccia dipende dal fatto che le parole originali occupino una quantità esatta di spazio. Una breve etichetta inglese entra nel pulsante, una traduzione più lunga viene tagliata. Una fila di tab ordinati si affolla, oppure la scheda cresce e la sua azione resta ancorata alla vecchia posizione.

Non devi aspettare tutte le traduzioni per esaminare questa rigidità. Puoi mettere sotto pressione una bozza con testo deliberatamente più lungo e poi ripetere la revisione con traduzioni vere. Il primo passo trova debolezze strutturali; il secondo verifica se l’interfaccia funziona con lingua e significato reali.

Perché una sola percentuale non basta

Non esiste una percentuale che prepari l’interfaccia a ogni lingua. Etichette brevi, frasi lunghe, parole composte e scritture diverse producono pressioni differenti. Il conteggio dei caratteri non dice neppure esattamente quanto spazio renderizzato occorrerà.

La spiegazione W3C sulle dimensioni del testo tradotto illustra perché stringhe compatte possano espandersi molto e perché contino larghezza dei caratteri, struttura delle parole e interlinea. Gli esempi sono avvertimenti utili, non un calcolatore per la tua interfaccia. Esamina contenuto e font effettivi prima di considerare pronto un componente.

Immagina un dashboard eventi fittizio con «Visualizza dettagli». Una formulazione più lunga può richiedere larghezza o una seconda riga; il titolo dell’evento può passare da due a tre righe. Sono cambiamenti diversi con conseguenze diverse. Riservare la stessa percentuale di spazio extra ovunque non decide come debbano comportarsi.

Identifica prima ciò che le parole devono comunicare. Se un’etichetta distingue la visualizzazione di una prenotazione dalla sua modifica, questa distinzione deve restare chiara. Se un avviso spiega che un’azione non può essere annullata, non puoi eliminarne il significato per conservare l’altezza originale della scheda. Il layout serve a trasmettere il messaggio.

Un piccolo inventario dei componenti vulnerabili

Comincia dove lo spazio è controllato: navigazione, tab, pulsanti, badge, etichette dei moduli, intestazioni delle tabelle e piccole schede sono spesso più rivelatori di una colonna generosa. Cerca testi accanto a icone, prezzi, stati o altre azioni.

Per ogni componente, annota quattro comportamenti:

1. A capo: l’etichetta può usare un’altra riga?
2. Crescita: il contenitore aumenta altezza o larghezza?
3. Vicini: icona e azione adiacente si spostano in sicurezza?
4. Limiti: se le righe sono limitate, dove si legge il testo completo?

Una domanda senza risposta è una decisione ancora da prendere; la breve etichetta inglese potrebbe averla semplicemente nascosta.

Annota poi il costo del fallimento. Un tag decorativo che diventa più alto è diverso da un importo coperto. Dai priorità a componenti che portano decisioni, requisiti o azioni: la revisione non deve spendere la prima ora su variazioni innocue mentre un controllo chiave resta illeggibile.

Cosa Shopify ha imparato prima delle traduzioni

Nel racconto dell’internazionalizzazione di Shopify, il team descrive un problema facile da perdere in un’anteprima inglese: le stringhe estratte sembravano identiche a quelle hardcoded. Introdusse pseudotraduzione che sostituiva caratteri riconoscibili e raddoppiava vocali. Il testo alterato mostrava quali stringhe passassero dalla traduzione e permetteva di esaminare l’interfaccia con parole più lunghe.

La pseudotraduzione scopre presto stringhe fuori dal sistema, controlli dipendenti dalle parole brevi e contenitori che non crescono. Non dice se un’istruzione francese sia naturale o se un layout arabo abbia l’ordine corretto.

Guarda ciò che resta riconoscibile nello screenshot. Chi testa comprende ancora la schermata pur vedendo caratteri insoliti. Può completare un compito normale e notare le rotture lungo il percorso. Stringhe casuali riempirebbero i riquadri ma toglierebbero la capacità di valutare se azione e spiegazione restino sensate insieme.

Usa l’approccio per separare quattro verifiche:

• Copertura: il testo pseudo marcato rivela le stringhe mai trasformate.
• Capacità: le parole espanse provano la crescita di controlli e contenitori.
• Rendering: scrittura prevista e font di fallback espongono glifi mancanti e righe tagliate.
• Lingua: traduzioni approvate permettono a chi conosce la lingua di giudicare senso e formulazione.

Un insieme pratico di stress test

Prendi una pagina con titolo, tab, badge, due azioni e un errore. Conserva valori e destinazioni, modificando soltanto il testo esaminato.

Collega il difetto alla stringa e allo stato che lo producono. «L’azione secondaria francese copre la primaria a 390px dopo la validazione» dà un punto di partenza. «Il francese vuole più spazio» non distingue pulsante fisso, gruppo rigido ed errore fuori posto.

Dopo una riparazione prova di nuovo anche il testo breve. Un pulsante a piena larghezza può risolvere l’etichetta lunga ma sembrare scollegato sul grande. Una scheda alta e fissa può accogliere una traduzione rendendo difficili da scorrere i record ordinari. Preferisci crescita dal contenuto e impilamento definito; riserva capacità fissa a veri vincoli, come una superficie host incorporata.

Prima della revisione linguistica, fornisci al traduttore la destinazione dell’azione e la frase che la circonda. «Open» può indicare uno stato oppure un comando. Questa ambiguità non si risolve allargando il pulsante. Le verifiche visive e linguistiche devono aiutarsi a vicenda, senza chiedere a uno dei revisori di certificare aspetti che non è in grado di valutare.

Mantieni controllato il test

Usa un titolo evento più lungo, un luogo più lungo e un’etichetta d’azione più descrittiva. Mantieni fissi date e conteggi dei partecipanti nel primo confronto, perché la variabile studiata sia la lunghezza del testo. Quando il layout funziona, aggiungi formati data locali in un passaggio separato.

L’inglese espanso trova pressione di spazio; le traduzioni vere servono a verificare naturalezza, significato e rendering specifico della scrittura.

Una risposta per ogni componente

La stessa stringa lunga non dovrebbe attivare ovunque la stessa riparazione. Un pulsante può crescere, la navigazione cambiare layout, una scheda richiedere un’altra riga. Parti dalla relazione che deve sopravvivere.

Pulsanti: crescere, andare a capo o impilarsi

I pulsanti hanno bisogno di una regola per le etichette più lunghe. Una larghezza fissa può essere utile per un gruppo volutamente allineato, ma diventa fragile se quella larghezza conta più del testo. Esamina l’azione nel layout circostante prima di decidere se il pulsante debba allargarsi, andare a capo o spostarsi.

Per due azioni sotto un modulo, impilarle sullo stretto può essere più chiaro che comprimerle su una riga. Se una è primaria, conservane il risalto dopo la modifica. Il visitatore non dovrebbe dedurne l’importanza da una disposizione desktop ormai assente.

Andare a capo non è automaticamente sbagliato. Funziona con altezza, padding e legame col contenuto adeguati. Però tante piccole azioni su due righe rallentano la scansione. Se più comandi richiedono lunghe spiegazioni, valuta se appartengano tutti allo stesso gruppo compatto.

Non sostituire parole significative con icone inspiegate per risparmiare. Un’icona può servire un’azione familiare nel contesto giusto, ma introduce un problema di riconoscimento. È un compromesso da valutare, non una sparizione neutra della traduzione.

Per una verifica concreta delle dimensioni, ho misurato tre etichette inglesi in Albert Sans a 32px, con 20px di padding orizzontale per lato. «View details» richiede una larghezza totale di 212px; «Review booking details» ne richiede 368px e «Review your booking details» 440px. Un pulsante con larghezza fissa di 220px lascia soltanto 180px al testo: la prima etichetta entra, mentre le altre richiedono un adattamento del layout. Queste etichette inglesi di prova isolano la pressione sulla larghezza e non sono traduzioni. La parte più scura di ogni barra rappresenta il testo misurato; quella più chiara rappresenta il padding. Su una pagina stretta, confronta la larghezza risultante con lo spazio disponibile nel gruppo di azioni prima di scegliere se allargare i pulsanti, consentire il ritorno a capo o impilarli.

Navigazione: cambia prima della collisione

La navigazione è spesso uno dei primi punti in cui emerge l’espansione del testo, perché molte etichette competono per un’unica riga orizzontale. Un header che contiene a malapena il testo originale lascia poco margine a parole più lunghe. In un’altra lingua potrebbe dover cambiare presentazione prima, oppure adottare un layout che si adatti allo spazio disponibile.

Controlla l’header completo: marchio, selettore lingua, azione account ed eventuali link promozionali. Guardare soltanto le etichette di navigazione può far perdere la collisione reale. Un’etichetta account appena più lunga potrebbe essere ciò che stringe tutto il resto.

Non accorciare le etichette separatamente soltanto per mantenerle della stessa larghezza. Un traduttore può scegliere parole diverse per preservare il significato, e le etichette risultanti possono non essere visivamente simmetriche. È ragionevole che una voce occupi più spazio, se il gruppo resta comprensibile e utilizzabile.

Per i tab, valuta se andare a capo crei ambiguità. Due righe possono rendere meno chiaro quale contenuto appartenga alla scelta. Un altro controllo o uno scorrimento deliberato possono adattarsi meglio al compito. Esamina insieme stato selezionato e contenuto di destinazione, non soltanto la visibilità delle parole.

Schede: conserva identità e azione

Le schede ripetute creano la pressione di mantenere ogni elemento esattamente della stessa altezza. Questo può facilitare la scansione, ma il metodo conta. Tagliare testo significativo per preservare la griglia può rendere le schede più facili da allineare e più difficili da scegliere.

Nel dashboard degli eventi, supponi che il nome di un evento occupi tre righe e quello di un altro una sola. L’azione può comunque restare in una posizione prevedibile se il layout della scheda distribuisce lo spazio con cura. L’area del titolo dovrebbe poter crescere e il legame fra titolo, data e azione deve restare chiaro.

Decidi quale testo si può abbreviare e come raggiungerne la versione completa. L’anteprima di una descrizione lunga è diversa da un titolo che identifica l’evento. Se due eventi diventano indistinguibili dopo il troncamento, il componente ha perso informazioni necessarie alla scelta. I puntini di sospensione non spiegano quale sia la differenza mancante.

Controlla separatamente badge e stati. Uno stato più lungo non dovrebbe coprire il nome evento o spingere la data fuori dalla scheda. Una riga dedicata al badge può essere migliore di caratteri più piccoli. Poi guarda anche una scheda con etichetta breve, per non creare troppo vuoto in tutte le altre.

Moduli: etichette, suggerimenti ed errori insieme

I moduli sono particolarmente sensibili perché più tipi di contenuto circondano lo stesso controllo. Un’etichetta identifica il campo, un suggerimento spiega l’input atteso e un errore descrive la correzione. Tutti possono allungarsi in un’altra lingua.

Verifica ogni stato con gli altri presenti. Un campo corretto con la sola etichetta può diventare confuso con un aiuto tradotto e un errore sotto. Il lettore deve ancora capire quale informazione appartenga a quale campo e dove continuare dopo la correzione.

Etichette e controlli affiancati possono dover impilarsi quando l’etichetta cresce. È una scelta strutturale, non una cattiva traduzione. Se mantieni l’orizzontale, entrambi devono avere spazio per lavorare. Un’etichetta generosa accanto a un input inutilizzabilmente stretto non è un miglioramento.

Conserva le distinzioni nei messaggi di errore. «Obbligatorio», «Troppo lungo» e «Impossibile salvare» descrivono problemi diversi. Una revisione di localizzazione non dovrebbe ridurli tutti a una frase generica soltanto perché l’area di errore ha un’altezza fissa. Lascia che quell’area comunichi il problema specifico e cresca con il messaggio.

Numeri, unità e nomi nel contesto

L’espansione del testo non riguarda soltanto le frasi. Date, valute, nomi e unità possono cambiare lo spazio e l’ordine richiesti da un componente. Considerali esempi di contenuto da verificare per la lingua e l’area geografica pertinenti, non valori che il designer dovrebbe improvvisare a memoria.

Una riga di prezzo può combinare un importo, un periodo di fatturazione e una precisazione. Se la precisazione va a capo, verifica che sia ancora chiaramente associata a quel prezzo. Nell’esempio dell’evento, un intervallo di date può richiedere più spazio di una singola data. Tenere insieme etichetta e valore può essere più importante che risparmiare una riga nell’intera scheda.

Usa nomi rappresentativi forniti dagli utenti, anziché supporre un numero fisso di parole brevi. Funzionare solo con «Alex Lee» non dimostra che nomi più lunghi si leggano. Valuta dove il nome completo debba restare visibile e dove una forma compatta sia adatta al compito.

Evita di concatenare frammenti nella specifica visiva come se l’ordine della lingua originale fosse universale. Una frase composta da un numero, un sostantivo e un breve suffisso può richiedere una costruzione diversa nella traduzione. Trasmetti il significato previsto e il contesto, così il lavoro linguistico può produrre un messaggio coerente anziché riordinare pezzi scollegati senza indicazioni.

I consigli rapidi W3C includono dichiarazioni linguistiche, separazione fra contenuto e presentazione e cautela con le stringhe assemblate.

Spazio verticale oltre che orizzontale

Un rimedio comune è aumentare la larghezza lasciando tutte le altezze fisse. Aiuta un’etichetta, ma può tagliarne un’altra al cambio di righe. Controlla il flusso verticale dell’intera sezione: un titolo lungo può spingere sottotitolo, gruppo azioni e sezione seguente.

Lascia che la pagina assorba questa crescita dove il compito lo consente. Una scheda che diventa più alta è spesso meno dannosa di una frase essenziale che scompare. Se l’altezza deve restare vincolata, definisci esplicitamente il comportamento alternativo: per esempio, spostare i dettagli secondari in una vista separata mantenendo visibili le informazioni identificative.

Guarda sopra e sotto i caratteri effettivamente renderizzati. Un riquadro può sembrare sufficiente e tagliare un accento o parte di un glifo. Cambiare font, scrittura o peso può rivelarlo. Uno screenshot col font di partenza non è prova sufficiente per un’altra scrittura.

Non imporre a ogni lingua lo stesso numero di righe. Il design conserva gerarchia, relazioni e usabilità. Altezza e ritorni diversi sono conseguenze ragionevoli dello stesso senso in testi diversi.

Localizzazione e larghezza insieme

Una traduzione che funziona sul desktop può comunque creare problemi su un telefono. Verifica i componenti vulnerabili in una vista stretta, una intermedia e una ampia, poi esamina le larghezze in cui il layout cambia. Mantieni selezionata la stessa lingua mentre completi un intero compito, così potrai notare relazioni che una serie di screenshot isolati non mostrerebbe.

Distingui le osservazioni linguistiche dai problemi di layout. Se una frase suona innaturale, richiede una revisione linguistica. Se un’etichetta ben formulata collide con un controllo vicino, serve una correzione del layout. A volte sono presenti entrambi i problemi, ma classificarli evita che designer e traduttore continuino a rimandarseli a vicenda.

Per i giudizi finali su formulazione e senso serve chi conosce la lingua. Chi non la parla trova tagli, sovrapposizioni e caratteri assenti, ma non conferma affidabilmente che un’abbreviazione comunichi l’azione corretta. Segnala il limite nella revisione anziché scambiare la capienza visiva per approvazione linguistica.

I layout da destra a sinistra richiedono anche una verifica distinta della direzionalità. Allungare un testo da sinistra a destra non dimostra che funzionino l’ordine, i contenuti con direzioni miste o i controlli direzionali. Mantieni esplicito questo lavoro, invece di assorbirlo in una generica dichiarazione secondo cui tutte le lingue hanno superato la verifica.

Usa OpenDesign per verificare e correggere

OpenDesign può sostenere il lavoro tramite anteprima HTML, viste desktop, tablet e mobile e revisioni mirate. Fornisci testo approvato come contesto, ispeziona e descrivi collisioni con commenti o chat. Le modifiche manuali supportate di testo e stile aiutano a provare aggiustamenti locali.

Per esempio, specifica che il titolo dell’evento può andare a capo su più righe, che la data deve restare interamente visibile e che l’azione principale deve rimanere associata alla sua scheda. Mantieni invariato il testo mentre provi la correzione del layout. Questo rende il risultato più facile da valutare rispetto a una riprogettazione generale richiesta ogni volta che compare una stringa lunga.

Usa traduzioni approvate nel giudizio finale, perché cambiare parole non nasconda una collisione ancora da risolvere.

Dopo una correzione locale, confronta di nuovo il contenuto originale con quello espanso. Una regola che risolve il caso più lungo può rendere inutilmente goffe le etichette brevi. Un layout flessibile deve funzionare con testi di lunghezze diverse: il testo ordinario mantiene una composizione curata, quello più lungo resta utilizzabile e il motivo di ogni trattamento eccezionale è chiaro.

Definisci «pronto per la traduzione»

Una consegna utile registra il comportamento dei componenti vulnerabili, gli stress test provati e le lingue reali esaminate. Includi restrizioni irrisolte, come un widget esterno con larghezza fissa dell’etichetta o un’immagine contenente testo ancora da localizzare.

Dai contesto alle stringhe ambigue: destinazione del pulsante, spiegazione vicina e differenze fra azioni simili. Se un limite di caratteri è inevitabile, spiega perché e chi può cambiarlo. Non trasformare silenziosamente ogni larghezza corrente in un vincolo linguistico.