Documentare un pannello operatore in più lingue non è mai una cosa lineare.
In particolare, quando devi esportare all’estero il macchinario o il dispositivo che lo contiene.
Per gestire le traduzioni, mandi una nota al traduttore: “i nomi dei tasti devono restare identici a quelli che si vedono negli screenshot dell’HMI”.
Ricevi tutto, impagini, pubblichi il manuale e lo spedisci al cliente.
Risultato:
- Nello screenshot il tasto si chiama Start.
- Nella tabella in cui descrivi i comandi, compare “Cycle Start”.
- Nella procedura compare “start the cycle”.
- E nel pannello reale installato presso il cliente la scritta è diventata “Start Cycle”.
È grave? Forse sì, forse no, dipende da tanti aspetti. Ma è chiaro che qualcosa non va.
La domanda giusta che devi farti è un’altra:
Da dove deriva questa falla? E perché rischia di tornare ogni volta che lavori con screenshot in lingua?
Per arrivare a rispondere, dobbiamo tornare al punto in cui è nato il modo di documentare i pannelli HMI.
Dal primo screenshot al metodo consolidato
La prima volta in cui qualcuno nella tua azienda ha documentato un’interfaccia HMI, ha fatto l’equivalente digitale di una fotografia al pannello.
Uno screenshot per ogni schermata.
Sotto ha aggiunto una tabella con la funzione dei tasti principali. Più avanti, nella procedura, ha richiamato gli stessi comandi nel punto in cui servivano.
In questo modo, il manuale mostrava all’utilizzatore esattamente quello che avrebbe visto sulla macchina.
Il pannello aveva poche schermate, poche funzioni, poche scritte. Le lingue erano limitate, il prodotto non cambiava spesso. Chi progettava l’HMI, chi scriveva le istruzioni e chi conosceva davvero la macchina erano ancora abbastanza vicini da permettere un controllo quasi artigianale.
Se una scritta non tornava, qualcuno se ne accorgeva. Se la tabella con la descrizione dei campi usava un nome diverso, bastava una revisione. Se il manuale usciva in una seconda lingua, il controllo era ancora possibile con attenzione, memoria e buon mestiere.
Era la scelta più ovvia e naturale del mondo.
Poi il pannello ha cominciato a portarsi dietro più varianti, lingue e versioni di quante il metodo basato sugli screenshot potesse tenere insieme.
Perché il pannello cresce. Non tutto insieme, non in modo spettacolare. Cresce una funzione alla volta, una lingua alla volta, una variante alla volta. Una schermata diventa un gruppo di schermate. I tasti diventano menu, campi, messaggi, allarmi. Il prodotto entra in nuovi mercati. Una versione software modifica due scritte. Una configurazione cliente introduce una differenza. Il manuale deve uscire in una lingua mentre l’HMI reale resta in un’altra.
Nessuno di questi passaggi, da solo, sembra sufficiente per mettere in crisi il metodo.
Allora continui a utilizzare il sistema che hai ereditato e che ha sempre funzionato: acquisisci lo screenshot, aggiorni la tabella, sistemi la procedura, mandi in traduzione, controlli al ritorno.
Solo che ogni nuova lingua non aggiunge più soltanto una traduzione. Aggiunge un nuovo punto in cui quello che il pannello mostra e quello che il manuale dice possono smettere di coincidere.
Con 30 schermate e 10 lingue stai già ragionando su 300 screenshot potenziali. Con 100 schermate e 12 lingue arrivi a 1.200.
Il numero serve solo a far vedere il salto di scala. Ma il punto è che dentro il modello “screenshot nel manuale, tabella, procedura, traduzione, controllo finale” ogni nuova lingua moltiplica i confronti, non solo i file.
Da fuori sembra lavoro redazionale. In realtà è tempo tecnico speso per capire se il manuale sta ancora descrivendo la versione giusta del prodotto.
A un certo punto non stai più documentando una schermata. Stai controllando, pezzo per pezzo, che punti diversi del manuale e del pannello stiano ancora dicendo la stessa cosa.
La soluzione impossibile: tenere tutto insieme a mano
Se vuoi restare dentro questo metodo senza rinunciare a niente, ti rimane una strada sola: controllare tutto.
Apri il manuale nella lingua sorgente, gli screenshot del pannello, le tabelle descrittive e le procedure operative. Verifichi che ogni scritta richiamata nel testo corrisponda a quello che l’operatore vede sull’HMI. Poi ripeti lo stesso lavoro quando il manuale torna tradotto, quando gli screenshot vengono sostituiti o localizzati, quando una procedura cambia, quando una tabella viene aggiornata, quando una lingua in più entra nel giro.
All’inizio sembra un controllo di routine. Poi, poco alla volta, diventa resistenza alla ripetizione.
Hai il PDF tradotto aperto, una cartella di screenshot localizzati, il manuale sorgente da una parte, una mail del traduttore dall’altra, e magari davanti agli occhi una lingua che capisci troppo poco per poterti fidare solo del tuo controllo. Sul francese o sul tedesco puoi farti aiutare. Sul russo, sul greco, sul vietnamita, il controllo smette di essere diretto e diventa una catena di richieste, commenti, conferme, screenshot rimandati indietro, note nel PDF e risposte da qualcuno che ha visto il pannello acceso sulla macchina.
E tu, in mezzo, devi tenere insieme tutto.
Devi sapere se il nome del tasto nello screenshot è lo stesso che compare nella tabella. Devi capire se la procedura, per spiegarsi meglio, ha introdotto una variante. Devi distinguere una scritta che andava tradotta da una che doveva restare identica al pannello. Devi accorgerti se una correzione è stata fatta in un punto e dimenticata in un altro.
Questo non è lavoro superficiale. È il massimo della diligenza dentro un metodo che ti ha lasciato addosso il compito più fragile: ricostruire alla fine quello che il processo non ha conservato durante il percorso.
Il problema è proprio questo: stai facendo bene un lavoro che non dovrebbe dipendere così tanto dalla tua attenzione e da passaggi manuali.
Da un certo punto in poi, la qualità non dipende più solo da quanto sei bravo. Dipende da quante volte riesci a ripetere lo stesso confronto senza perdere lucidità.
E anche quando arrivi in fondo, rimane una domanda scomoda.
Sei sicuro che il pannello che hai appena controllato sia ancora quello che il manuale dovrà documentare quando la macchina verrà usata davvero?
Teniamo sospesa questa domanda. Prima bisogna guardare che cosa succede quando quel controllo diventa troppo pesante per restare una pratica quotidiana.
A quel punto, di solito, cerchi un compromesso che ti permetta di consegnare.
1. Togli le scritte. E lo screenshot perde la sua parte più utile
La prima via di sopravvivenza è togliere le scritte dagli screenshot.
Sfocare, cancellare, coprire, pallinare, sostituire le scritte con numeri o richiami esterni. Se lavori con molte lingue, questa scelta può sembrare quasi inevitabile. Una cosa è gestire qualche screenshot in italiano e inglese. Un’altra è produrre, inserire, aggiornare e verificare screenshot in dieci, venti o trenta lingue. A quel punto ogni parola visibile dentro lo screenshot diventa un moltiplicatore di file, controlli, dubbi ed errori possibili.
Togliere le scritte dagli screenshot del pannello riduce la parte visibile del problema.
Ma non è una rinuncia a costo zero.
Lo screenshot non mostra più quello che vede davvero l’operatore. Mostra la struttura del pannello, la posizione dei tasti, magari la logica generale della schermata, ma non mostra più le parole che l’operatore userà per riconoscere il comando. La legenda deve ricostruire fuori dallo screenshot ciò che il pannello avrebbe già mostrato da solo.
Quelle parole possono anche ricomparire nella legenda o nella procedura. Ma non sono più nello screenshot, cioè nel punto in cui l’operatore dovrebbe riconoscere il pannello senza passare da un altro livello di interpretazione.
2. Lasci solo l’inglese. Ma devi sapere se è davvero il pannello reale
La seconda strada è lasciare gli screenshot sempre e solo in inglese.
In molte aziende l’inglese è la lingua più stabile dell’HMI: quella con cui nasce il software, quella che conoscono i tecnici, quella che usa l’assistenza, quella che spesso il cliente internazionale accetta senza stupirsi troppo. Se produci molti modelli o molte varianti, usare screenshot inglesi anche nei manuali in altre lingue può sembrare un modo ragionevole per ridurre il lavoro.
E a volte lo è.
Se il pannello reale consegnato al cliente è davvero in inglese, il manuale deve documentare quel pannello. Fingere che sia in francese, italiano o tedesco sarebbe molto peggio.
Il problema nasce quando l’inglese smette di essere una caratteristica del pannello e diventa una scorciatoia del manuale. Il manuale deve uscire in francese, ma lo screenshot resta in inglese.
Nel testo sorgente descrivi i tasti e le procedure che li richiamano. Per dare un riferimento all’utilizzatore, lasci fra parentesi il nome inglese che compare sul pannello e chiedi che non venga tradotto.
Per esempio, scrivi una frase come: “Premere il tasto Avvio (Start)”.
Poi chiedi al traduttore di mantenere Start invariato fra parentesi, in modo da ottenere una frase come: “Appuyez sur la touche Démarrer (Start)”.
Così l’operatore francese capisce che il tasto Start sul pannello corrisponde al comando Démarrer nel manuale.
Sembra logico e lineare, ma presuppone due condizioni che devono reggere sempre.
- La prima è tua: devi usare sempre lo stesso schema. Non puoi scrivere una volta “Avvio (Start)”, una volta solo “Start”, una volta “Avvio / Start”, e poi pretendere che il sistema resti chiaro.
- La seconda è del processo di traduzione: il traduttore non può trattare allo stesso modo il nome del comando nella lingua del manuale e il nome che resta visibile sul pannello. Se traduce tutto, perdi il riferimento allo screenshot. Se dimentica l’inglese fra parentesi, l’utilizzatore perde il ponte con il pannello.
Il problema è che nessun automatismo garantisce davvero queste due condizioni, né nel tuo ambiente di lavoro né in quello del traduttore.
Non sono processi progettati per gestire due lingue contemporaneamente nella stessa frase.
Se questa scorciatoia ti sembra troppo fragile, la tentazione successiva è quasi obbligata: dare più contesto possibile a chi traduce e chiedergli di proteggere l’allineamento.
3. Dai il contesto al traduttore. Ma il processo resta fuori
La terza strada sembra la più ordinata: prepari gli screenshot nelle lingue disponibili, li inserisci nel manuale, mandi tutto al fornitore linguistico e gli spieghi che i nomi dei tasti, dei menu e dei campi devono restare coerenti con ciò che si vede sul pannello.
In teoria è una richiesta sensata. Gli dai il contesto, gli mostri le schermate, gli segnali che non tutte le parole del manuale si comportano allo stesso modo. Quando nel testo compare il nome di un tasto, quel nome non può essere tradotto liberamente se sul pannello resta diverso.
Il problema è che stai chiedendo al processo di traduzione di conservare un legame che il processo documentale ha già reso fragile.
Tu immagini il traduttore davanti alla pagina del manuale: screenshot sopra, tabella sotto, procedura accanto, contesto visibile e relazioni evidenti fra gli oggetti.
Ma il traduttore professionale, nella maggior parte dei casi, lavora in un CAT, uno strumento che separa il testo dalla grafica e dall’impaginazione. È normale che sia così. È il modo in cui si gestiscono grandi volumi di testo, segmento dopo segmento.
E così, nel suo ambiente di lavoro, quella pagina così ben impaginata non esiste più.
Il traduttore si trova davanti una sequenza di segmenti, una frase dopo l’altra, separata dallo screenshot e dal punto esatto della procedura. Per allineare davvero il nome del tasto con quello che compare nel pannello, deve uscire dal segmento, consultare il PDF o il file di riferimento, trovare la pagina, guardare lo screenshot, capire a quale comando si riferisce quella frase, tornare nel CAT e fare la scelta giusta.
E deve farlo ogni volta in cui quel comando ricompare.
Se succede una volta, è un controllo. Se succede in decine di schermate, in più lingue, in procedure diverse e magari in manuali collegati, non è più un dettaglio di traduzione. È controllo del pannello scaricato su un processo nato per tradurre testo.
Il traduttore può aiutare, segnalare dubbi, salvarti in molte lingue che non puoi verificare direttamente. Ma non può essere il sistema su cui fondi la corrispondenza fra screenshot, procedura e pannello reale.
Il punto non è che il traduttore non possa controllare. È che il controllo non può dipendere ogni volta dal fatto che esca dal suo ambiente di lavoro per ricostruire il contesto a mano.
Quando nasce una lingua parallela
Queste tre strade nascono da vincoli diversi: troppe lingue, inglese predominante, fiducia nel fornitore, poco tempo, poche risorse, necessità di consegnare.
Ma possono portare tutte nello stesso punto: il manuale comincia a sviluppare nomi, scorciatoie e spiegazioni che non coincidono più del tutto con quelle del pannello. Una lingua leggermente diversa.
Non una nuova lingua straniera. Una lingua parallela.
Succede quando una stessa funzione viene chiamata in modi diversi a seconda del punto in cui compare. Nel pannello resta il nome breve, magari imposto dallo spazio disponibile nel campo. Nello screenshot vedi quella scritta. Nella tabella la spieghi meglio. Nella procedura la rendi ancora più descrittiva. Poi il manuale va in traduzione e quella differenza viene assorbita, interpretata, adattata o peggiorata.
A quel punto non hai più solo tre varianti della stessa scritta. Hai tre logiche diverse: la scritta reale del pannello, la traduzione descrittiva della tabella, la frase naturale della procedura.
Nello screenshot il tasto si chiama Start. Nella tabella del manuale francese diventa Démarrer. Nella procedura lo stesso comando viene richiamato come lancer le cycle.
Dentro il file, tutto può sembrare difendibile. “Démarrer” è la traduzione corretta. “lancer le cycle” è più naturale dentro una procedura. “Start” è quello che si vede sul pannello.
Ma l’operatore non sta facendo revisione terminologica. Sta cercando sul pannello il tasto che il manuale gli ha detto di premere.
Se non lo trova, deve interpretare.
E l’interpretazione non dovrebbe essere una fase della procedura.
Il problema non è l’eleganza linguistica. È la corrispondenza operativa.
Quando il testo usa un nome e il pannello ne mostra un altro, il manuale non accompagna più davvero l’utilizzatore. Gli chiede di fare da ponte fra il nome scritto nel manuale e il nome che trova sulla macchina.
Fin qui potresti ancora pensare che basti aumentare il controllo: più attenzione prima della pubblicazione, più revisione, più verifiche sugli screenshot, più disciplina nei nomi dei tasti.
In molti casi aiuta.
Ma tutto questo presuppone una cosa: che il pannello resti quello che hai controllato.
E non sempre succede.
Il manuale era corretto. Poi il pannello è stato modificato.
Una linea confezionatrice parte per un cliente in Germania. Il manuale è già stato pubblicato. Il PDF è stato consegnato. La macchina è installata, la matricola è assegnata, il pannello operatore è configurato, il collaudo è chiuso. Per quanto riguarda la documentazione, la commessa sembra arrivata in fondo.
Hai controllato gli screenshot disponibili, verificato le procedure principali, chiesto conferme sulle scritte più delicate e sistemato quello che non tornava prima della consegna.
Sulla carta era tutto a posto.
Dopo qualche settimana, gli operatori del cliente iniziano a usare davvero la macchina. Non in ufficio tecnico, non durante una revisione ordinata, non davanti a una tabella di controllo. La usano in reparto, con i tempi della produzione e con le parole che loro usano ogni giorno per riconoscere funzioni, stati, allarmi e comandi.
La segnalazione non arriva come “problema documentale”. Arriva come problema sul pannello: due scritte sono formalmente corrette, ma in reparto nessuno le associa davvero a quella funzione. Magari erano traduzioni difendibili, uscite da un file corretto e approvate da qualcuno. Semplicemente, per chi usa quella macchina in quel contesto, non sono le parole giuste.
Il tecnico interviene. Il software HMI viene aggiornato. Le scritte sul pannello vengono corrette.
Non sempre questa correzione entra subito come “revisione del manuale”. Spesso passa come intervento di avviamento, sistemazione software, nota di commessa, scambio fra tecnico e cliente.
Per chi è sul campo, il problema sembra risolto quando il pannello mostra la scritta giusta.
Risultato: il prodotto reale cambia. Ma le istruzioni consegnate al cliente no.
Da fuori, magari, sembra solo una piccola correzione di campo. Per il manuale, invece, è un cambio di realtà.
E nel processo documentale non si accende nessuna spia che dica: attenzione, questa scritta ora non è più quella che hai pubblicato.
Qui il problema smette di essere una questione di singole scelte redazionali. Il pannello ha continuato a vivere, mentre il manuale non aveva un modo naturale per accorgersene.
A quel punto non devi soltanto rifare uno screenshot. Devi capire dove quella scritta compariva: nello screenshot, nella tabella, nella procedura, in una nota, in un altro capitolo, in un manuale collegato. Devi capire se la modifica riguarda solo il tedesco o se tocca anche l’inglese, l’italiano o la lingua sorgente da cui partono le altre. Devi capire se vale solo per quella macchina, per quella commessa, per quel mercato, oppure se anticipa una modifica che entrerà nella prossima versione standard dell’HMI.
E soprattutto devi sperare che qualcuno te lo dica.
Perché può succedere anche internamente. Una scritta cambia in ufficio software durante una revisione dell’HMI, magari per ragioni legittime: era troppo lunga, non stava nel campo, creava confusione in collaudo, un tecnico ha chiesto di renderla più chiara. La lingua sorgente viene aggiornata, il pannello viene ricompilato, la macchina successiva esce con la scritta nuova.
Ma nelle istruzioni resta la scritta precedente, perché il sistema non ti ha messo nella condizione di vedere il cambiamento nel punto in cui ti serviva.
Il problema non è solo rifare gli screenshot. È sapere se il manuale sta ancora documentando il pannello reale installato su quella macchina.
Questa è la soglia oltre la quale il metodo smette di essere semplicemente faticoso e diventa strutturalmente fragile. Se l’unico modo per accorgertene è confrontare di nuovo screenshot, procedure, tabelle e lingue, non hai un processo sotto controllo.
Hai un sistema che funziona finché qualcuno continua a inseguirlo.
La domanda, a questo punto, non è più quanti screenshot devi rifare. È più scomoda: da dove sta prendendo il manuale le parole del pannello?
Il problema non sono le lingue: sono le scritte fotografate
Le lingue rendono il problema visibile. Gli screenshot lo rendono faticoso. Le revisioni lo rendono pericoloso.
Ma non sono ancora il punto. Il problema degli HMI multilingua ha poco a che fare con le lingue.
Il problema si verifica quando una scritta del pannello smette di essere un’informazione del prodotto e diventa testo fotografato.
Quando trasformi una stringa in uno screenshot da rincorrere.
Se fotografi un carter, il carter non contiene già parole. Le parole che lo descrivono stanno nel manuale.
Il pannello operatore no. È una parte del prodotto che parla. Mostra comandi, stati, messaggi, allarmi, campi da compilare, nomi di funzioni. E quelle scritte non nascono nel manuale. Nascono prima, nel software HMI.
Nel pannello quelle scritte sono stringhe: informazioni collegate a una funzione, a una lingua, a una versione, a una configurazione. Puoi trattarle come informazioni del prodotto.
Poi fai lo screenshot.
E per il manuale quella scritta non è più una stringa del pannello. È testo fotografato: visibile, ma scollegato.
Si vede ancora, ed è proprio per questo che sembra rassicurante. Guardi la schermata e hai l’impressione di avere portato nel manuale il pannello così com’è. Ma hai catturato il risultato visivo, non la logica che lo rendeva governabile.
Lo screenshot conserva l’aspetto della stringa, ma perde quasi tutto ciò che serve per governarla.
Non porta più con sé il punto da cui nasce, la lingua, la versione, il contesto. E perde la possibilità di dire, in modo semplice: questa è la stessa scritta che stai usando nella tabella, nella procedura, nel manuale tradotto, nella variante destinata a quel cliente.
Da una parte l’HMI continua a vivere nella sua filiera: software, lingue, revisioni, configurazioni. Dall’altra il manuale segue la propria: screenshot, tabelle, procedure, traduzioni, PDF pubblicati. Per un po’ sembrano camminare insieme. Poi basta poco perché prendano strade diverse.
Lo screenshot sembra il punto in cui queste due filiere si incontrano.
Molto spesso, invece, è il punto in cui perdono il collegamento.
Da quel momento puoi solo inseguire: guardare, copiare, mandare in traduzione, confrontare, sostituire, sperare.
Il lavoro che prima poteva appartenere al processo torna sulle tue spalle.
Ecco perché i rimedi di sopravvivenza non risolvono il problema alla radice. Possono ridurre il carico, spostarlo, renderlo più gestibile per un periodo. Ma restano rimedi applicati dopo che il collegamento è stato spezzato.
A quel punto la soluzione non è controllare meglio lo screenshot. È smettere di chiedergli una cosa che non può fare: essere la fonte delle parole del pannello.
Le parole del pannello non vanno inventate. Vanno richiamate.
Se il problema è questo, la via d’uscita non può essere un altro giro di copia e incolla. Non può essere solo “controlliamo meglio”, “aggiungiamo una nota al traduttore”, “facciamo più attenzione alle parentesi”.
Sono accorgimenti utili, in certi casi. Ma arrivano tutti dopo il punto in cui il collegamento si è già spezzato.
Non serve inventare nulla.
Le parole del pannello esistono già.
Se sono sbagliate, vanno corrette nel punto giusto. Se cambiano, il manuale deve saperlo. Se servono in una procedura, non dovrebbero essere riscritte come testo libero.
Le parole del pannello non vanno inventate. Vanno richiamate.
Non è una questione creativa. È una questione di automazione tradizionale: regole, richiami controllati, informazioni che nel prodotto esistono già.
La stessa logica che usano i softwaristi della tua azienda per progettare il pannello deve entrare anche nelle istruzioni che lo spiegano.
Così lo screenshot torna a essere una rappresentazione visiva utile, non il posto in cui informazioni vive diventano materiale da inseguire.
Scopri come smettere di inseguire gli screenshot
Nel Club dei Technical Writers trovi il video completo in cui mostro questa logica applicata agli HMI multilingua: come partire dalle scritte reali del pannello e portarle nelle istruzioni, senza trasformare ogni stringa in uno screenshot da inseguire.
È un approfondimento operativo per chi lavora sul processo documentale e vuole portare in azienda un ragionamento più forte: non “serve qualcuno che sistemi gli screenshot”, ma “serve un metodo per non perdere le scritte del pannello quando entrano nelle istruzioni”.
Il video è riservato ai membri del Club, che puoi provare gratuitamente per 3 mesi. Appena entri, puoi guardarlo subito.
Se sei già iscritto al Club dei Technical Writers di because, lo trovi nella sezione “Webinar e Workshop”, con il titolo “Istruzioni per pannelli HMI: Come allineare automaticamente testi e schermate in tutte le lingue”.
PS: Se vuoi capire, nei prossimi articoli, come tenere insieme redazione, traduzione e pubblicazione senza caos, senza dipendere dai fornitori e senza mettere a rischio sicurezza e conformità, iscriviti a questa newsletter.