Traduzione software per HMI e macchine: testi a schermo identici al manuale
La traduzione software per le macchine riguarda schermate HMI, testi di allarme e messaggi PLC, stringhe firmware e software di service: ogni termine sul pannello deve coincidere con il manuale d’uso, rispettare i limiti di caratteri del display e lasciare intatti i segnaposto. DEMA Solutions traduce stringhe e documentazione con un unico glossario e un’unica memoria di traduzione, release dopo release.
A chi si rivolge questa guida
Questa guida è scritta per chi è responsabile delle parole di una macchina: responsabili della documentazione tecnica, automazionisti e programmatori PLC, sviluppatori software e product manager di costruttori di linee di confezionamento, impianti di processo, sollevamento, macchine utensili, unità HVAC e sistemi di automazione. Di solito il manuale è in mano all’ufficio tecnico documentazione, mentre i testi HMI vengono esportati da un tecnico pochi giorni prima del collaudo, inviati in un foglio Excel e reimportati con pochissimo tempo per controllarli.
Le domande sono concrete. Perché gli operatori all’estero chiamano l’assistenza per un allarme che il manuale spiega benissimo? Quale file va mandato al traduttore? Come si evita che un testo tedesco esca dal pulsante, e come si tiene ogni lingua allineata al manuale da una release all’altra?
Che cosa si intende per software di macchina
Una macchina moderna parla ai suoi utilizzatori in molti più punti del manuale. Il pannello operatore, o interfaccia uomo macchina, mostra menu, pulsanti, nomi dei parametri, messaggi di stato e help in linea. Dietro, il progetto PLC contiene testi di allarme e messaggi, spesso centinaia o migliaia, ciascuno con un numero, un testo breve e talvolta una causa e un rimedio più estesi. Un sistema di supervisione o SCADA per l’intera linea aggiunge le proprie schermate, trend e registri eventi.
Poi c’è il software che vede il tecnico di assistenza: stringhe firmware su azionamenti e controllori, strumenti di diagnostica e messa in servizio, software di configurazione e, sempre più spesso, un’app o un portale web per lo stato della macchina e la manutenzione. Ogni componente nasce spesso in un team diverso, in un formato diverso. Quando app e portali crescono fino a diventare veri prodotti software, conviene impostare un processo di traduzione e localizzazione del software con rilasci regolari.
Per la traduzione hanno tre caratteristiche in comune. I testi sono brevi e spesso compaiono senza una frase intorno. Vivono in file che il software legge, quindi un carattere danneggiato o una variabile mancante possono bloccare una build. E descrivono esattamente gli stessi componenti, funzioni e pericoli del manuale d’uso, ed è lì che nasce la maggior parte dei problemi.
Perché schermo e manuale devono usare termini identici
Un operatore davanti a una macchina ferma legge l’allarme sul pannello, poi lo cerca nel manuale. Se il pannello dice “Porta di protezione aperta” e il manuale chiama lo stesso componente “carter di protezione”, l’operatore deve indovinare se si tratta della stessa cosa. Nell’originale italiano i due testi possono essere perfettamente allineati; dopo una traduzione fatta da persone diverse in momenti diversi, spesso non lo sono più.
Sicurezza. Avvisi e allarmi servono a far compiere rapidamente l’azione giusta. Una differenza tra la formulazione sullo schermo e quella delle istruzioni di sicurezza rallenta quell’azione proprio nel momento sbagliato e indebolisce la riduzione del rischio che la documentazione dovrebbe garantire.
Chiamate all’assistenza e fermi macchina. Quando l’operatore non riesce ad associare un allarme a un rimedio, il passo successivo è una telefonata al vostro service o al distributore locale. Molte di queste chiamate non nascono da un guasto, ma da un problema di terminologia, e ognuna costa tempo al vostro team e produzione al vostro cliente.
La soluzione non è una rilettura più accurata alla fine. È trattare la traduzione dell’interfaccia utente e quella della documentazione come un unico corpo di contenuti, con un unico vocabolario approvato.
Il Regolamento macchine porta l'interfaccia nel perimetro
Dal 20 gennaio 2027 il Regolamento (UE) 2023/1230 sostituisce la Direttiva macchine. L’articolo 10, paragrafo 7, richiede che la macchina sia accompagnata da istruzioni per l’uso e informazioni di sicurezza in una lingua facilmente comprensibile per gli utilizzatori, stabilita da ciascuno Stato membro. L’allegato III, punto 1.7.1, estende la regola linguistica alle informazioni e alle avvertenze scritte o verbali sulla macchina stessa, privilegiando dove possibile simboli o pittogrammi facilmente comprensibili.
Il punto 1.7.1.1 va oltre per l’interfaccia: i videoterminali e gli altri mezzi di comunicazione interattiva tra operatore e macchina devono essere facilmente comprensibili. In pratica, schermate HMI, testi di allarme e help in linea rientrano nello stesso quadro di conformità del manuale. Il Regolamento consente inoltre di fornire le istruzioni per l’uso in formato digitale, anche integrate nel software della macchina, purché gli utilizzatori possano stamparle, scaricarle e salvarle.
Questo alza la posta. Una macchina con il manuale in polacco e il pannello disponibile solo in inglese e italiano è più difficile da difendere, e un manuale digitale mostrato sull’HMI segue le stesse regole linguistiche di quello stampato. Il nostro articolo su che cosa chiede il nuovo Regolamento macchine per le istruzioni tradotte copre l’intero set documentale, mentre la guida alla traduzione dei manuali spiega le regole generali sulle istruzioni nella normativa UE di prodotto.
Perché la traduzione software è un lavoro diverso dalla traduzione di un manuale
Chi traduce un manuale ha paragrafi e illustrazioni per capire il senso. Chi traduce stringhe HMI spesso ha un elenco: una chiave, due o tre parole di testo sorgente e una colonna da riempire. “Start”, “Reset”, “Arresto”, “Scarico” o “Alimentazione” possono essere comando o stato, o indicare cose diverse a seconda della schermata, e la traduzione corretta in tedesco, spagnolo o polacco dipende da questo.
È questa la differenza di fondo tra localizzazione dell’interfaccia e traduzione di documenti. La stessa parola italiana può richiedere due traduzioni diverse su due schermate diverse, e due parole sorgente diverse possono richiedere la stessa traduzione perché indicano la stessa funzione. Senza contesto, anche un ottimo traduttore deve indovinare, e qualche ipotesi sarà sbagliata.
Le stringhe portano anche vincoli che un manuale non ha: lunghezze di campo fisse, variabili inserite a runtime, abbreviazioni obbligate e formati di file che devono tornare esattamente nella struttura attesa dal software.
Limiti di caratteri, espansione del testo e font
La maggior parte dei campi HMI ha una larghezza fissa. Un pulsante può contenere una dozzina di caratteri, una riga di allarme forse quaranta, il nome di un parametro anche meno. Le traduzioni dall’italiano o dall’inglese verso tedesco, francese, spagnolo o polacco sono spesso sensibilmente più lunghe, e un composto tedesco può superare da solo l’intero campo.
Quando un testo non ci sta, il pannello lo tronca, lo manda a capo a metà parola o spinge fuori vista altri elementi. Un’avvertenza troncata non è un problema estetico: può cambiarne completamente il significato. L’unico metodo affidabile è comunicare al traduttore il limite di ogni stringa, in caratteri o in pixel se il display usa font proporzionali, e verificare il risultato rispetto a quel limite prima dell’importazione.
A volte il testo semplicemente non entra. Le alternative sono allora un’abbreviazione approvata e registrata nel glossario, un testo sorgente più breve o un campo più largo nella versione software successiva. Concordare le abbreviazioni una volta per lingua evita che ogni traduttore inventi le proprie.
Font e set di caratteri meritano la stessa attenzione anticipata. Un pannello che visualizza perfettamente l’italiano può non avere i caratteri del polacco, del ceco, del greco o del cirillico, e i controllori più vecchi possono non gestire affatto Unicode. Conviene verificarlo prima di iniziare a tradurre, non al collaudo con il cliente presente.
Segnaposto, variabili, unità di misura e numeri di allarme
Le stringhe di interfaccia sono piene di elementi da non tradurre. Segnaposto come %d, {0} o %s vengono sostituiti a runtime da un valore, un’unità o un numero di stazione, e il loro ordine può contare. Alcuni formati consentono al traduttore di riordinarli, altri no. Tag di markup, ritorni a capo e caratteri di escape devono restare esattamente come sono.
Un segnaposto mancante o alterato può produrre un messaggio senza senso, un errore software o un valore nel punto sbagliato: “Temperatura olio 85 °C troppo alta” può perdere il numero o l’unità. Per questo la traduzione software richiede controlli automatici che confrontino segnaposto, tag e lunghezza in ogni segmento, accanto alla revisione umana del significato.
Anche unità, formati numerici e codici di allarme richiedono regole esplicite. Il separatore decimale lo imposta il software oppure la traduzione, mai entrambi, e numeri di allarme e codici parametro restano invariati, perché il manuale e il tecnico al telefono fanno riferimento proprio a quelli.
Export delle stringhe: Excel, CSV, XLIFF, resx e altri formati
Il modo in cui i testi escono dall’ambiente di sviluppo determina buona parte della qualità che torna indietro. I costruttori di macchine lavorano di solito con una combinazione di questi formati:
- Export Excel o CSV dal software di progettazione PLC o HMI, una riga per testo e una colonna per lingua, spesso con numeri di allarme e commenti
- File XLIFF, il formato di scambio pensato per la traduzione, che contiene sorgente, traduzione, note e limiti di lunghezza in un’unica struttura
- File resx, XML, JSON o properties di strumenti di service, software di configurazione e app
- Tabelle di testo del firmware, di solito esportate in un foglio di calcolo dallo sviluppatore
I fogli di calcolo sono i più diffusi e i più fragili: le colonne si spostano, righe nascoste viaggiano con il file e il testo sorgente può essere sovrascritto per errore. Qualunque sia il formato, mantenete una chiave univoca stabile per ogni stringa, esportate solo le stringhe nuove e modificate quando possibile e inviate limite di caratteri e commenti dello sviluppatore in campi dedicati. Il file deve tornare con la stessa struttura e la stessa codifica, pronto per l’importazione senza correzioni manuali.
Contesto e screenshot
L’investimento più utile nella traduzione HMI è il contesto. Screenshot delle schermate principali, una breve descrizione di cosa fa ogni schermata, l’elenco allarmi con causa e rimedio e l’accesso al manuale attuale permettono al traduttore di capire se “Scarico” è il comando per svuotare la tramoggia o lo stato che indica che la tramoggia è già vuota.
Subito dopo vengono i commenti dello sviluppatore. Una nota come “pulsante, verbo, max 12 caratteri” elimina in pochi secondi gran parte delle ambiguità. Mantenete le stringhe raggruppate per schermata o funzione; un elenco in ordine alfabetico separa testi che vanno insieme. Le domande rimaste vanno rivolte a chi conosce la macchina: un breve foglio di quesiti a cui risponde l’automazionista costa molto meno di un ciclo di correzioni dopo il rilascio.
Pseudo-localizzazione e revisione in contesto
La pseudo-localizzazione è un test che potete fare prima di tradurre una sola parola. Il software sostituisce ogni stringa sorgente con una versione artificialmente più lunga, con caratteri accentati e speciali, e il team scorre le schermate. Testi troncati, stringhe scritte direttamente nel codice e mai esportate, caratteri che il font non sa visualizzare: tutto diventa subito visibile. Correggerli in questa fase costa una frazione rispetto a correggerli più tardi in quindici lingue.
Dopo la traduzione, il controllo più prezioso si fa sullo schermo reale o su un simulatore. Un revisore che conosce la macchina, per esempio un tecnico locale o il distributore, scorre il pannello e conferma che i testi entrano, si leggono in modo naturale e corrispondono al manuale. Le sue correzioni vanno nella memoria di traduzione e nel glossario, non in un’email, così la stessa correzione non serve mai due volte.
Un glossario e una memoria di traduzione per interfaccia e documentazione
La decisione più efficace che un costruttore può prendere è smettere di trattare HMI e manuale come due progetti di traduzione separati. Un unico glossario multilingue, approvato dai vostri tecnici, definisce in ogni lingua i nomi di componenti, funzioni, modalità operative e pericoli. Lo usano sia chi traduce le stringhe sia chi traduce il manuale, ed entrambi vengono verificati rispetto a esso. Un servizio di gestione terminologica lo rende praticabile su più lingue e linee di prodotto.
Il glossario ha bisogno di voci specifiche per l’interfaccia: l’abbreviazione approvata per ogni termine lungo, la forma usata sui pulsanti e i termini da non tradurre mai. Il nostro articolo su come mantenere coerente la terminologia tecnica tra traduttori e fornitori spiega come costruirlo e mantenerlo vivo.
Una memoria di traduzione condivisa completa il quadro. Quando il testo di allarme “Arresto di emergenza attivato” ha una traduzione approvata, la stessa formulazione deve comparire nel capitolo sulla risoluzione dei guasti, nel manuale di service e nell’app. Se i testi HMI e i manuali esistenti sono stati tradotti separatamente in passato, l’allineamento delle memorie di traduzione trasforma quei file bilingui in una memoria utilizzabile, e le incoerenze che emergono diventano le prime decisioni di glossario. La memoria deve essere vostra, in un formato portabile, ed è il tema del nostro articolo su chi possiede la memoria di traduzione.
Release dopo release: schermate e manuale sempre allineati
Il software di una macchina non è mai finito. Ogni nuova versione, opzione cliente o aggiornamento firmware aggiunge e modifica stringhe, e il manuale cambia con esso. Se ogni release viene tradotta da zero o da una persona diversa, la terminologia deriva e il costo di ogni aggiornamento resta alto.
Un processo per release funziona diversamente. Il tecnico esporta solo le stringhe nuove e modificate, con chiavi e limiti. La memoria di traduzione fornisce tutto ciò che è già approvato e il traduttore lavora solo sul nuovo, con il glossario condiviso. Prima dell’importazione, controlli automatici verificano segnaposto, tag e lunghezza. L’aggiornamento del manuale per la stessa release passa dalla stessa memoria e dallo stesso glossario, così una funzione rinominata cambia contemporaneamente sullo schermo e nella documentazione. Un report di leverage mostra quanta parte di ogni release deriva dal riutilizzo, e questo rende prevedibile il costo di ogni aggiornamento.
Conservate ogni file di stringhe tradotto con lo stesso numero di release del software a cui appartiene, e l’edizione del manuale allineata, così pannello e manuale descrivono sempre la stessa macchina.
Un processo pratico di traduzione HMI, passo per passo
Partite da un inventario di tutti i punti in cui la macchina parla agli utilizzatori: pannello, allarmi, firmware, strumento di service, app, etichette sulla macchina e manuali, con formato, responsabile, limiti di caratteri e lingue richieste per ciascuno. Molti costruttori scoprono a questo punto che più reparti acquistano traduzioni in modo indipendente.
Poi preparate la terminologia. Risolvete prima nella lingua sorgente le differenze tra pannello e manuale, quindi fate approvare ai vostri tecnici i termini di destinazione, le abbreviazioni e l’elenco dei testi che restano non tradotti, come i codici di allarme.
Quindi preparate i file: un formato di export per ogni componente software, con chiavi stabili, limiti e commenti, testato con la pseudo-localizzazione e inviato insieme agli screenshot e al manuale attuale.
Segue la traduzione, affidata a traduttori che conoscono le macchine, con la revisione di un secondo linguista e controlli automatici su segnaposto, tag, numeri e lunghezza. Verificate le stringhe importate in una build di test o su un simulatore, riportate ogni correzione in memoria e glossario e rilasciate software e documentazione insieme, con numeri di versione corrispondenti.
Cosa chiedere a un fornitore per la traduzione HMI
Non tutti i fornitori di traduzioni sono attrezzati per i file di stringhe. Prima di inviare il vostro primo export, queste domande distinguono chi lo ha già fatto da chi imparerà sul vostro progetto:
- Tradurrete le nostre stringhe HMI e i nostri manuali con lo stesso glossario e la stessa memoria di traduzione, e chi approva i nuovi termini?
- Come controllate segnaposto, tag e limiti di caratteri prima di restituire il file?
- Potete restituire il file esattamente con la stessa struttura e codifica, pronto per l’importazione?
- Memoria e glossario resteranno di nostra proprietà, in un formato portabile che possiamo portare altrove?
- Come gestite quesiti, screenshot e revisione in contesto con i nostri tecnici?
La nostra guida su come scegliere un fornitore di traduzioni tecniche aggiunge le domande più generali su qualità, processo e costi.
Come DEMA Solutions gestisce la traduzione software per i costruttori di macchine
I nostri servizi di traduzione tecnica coprono l’intero set documentale di una macchina, compresi pannelli HMI e software, manuali d’uso e manutenzione, procedure di sicurezza e dichiarazioni di conformità. Per stringhe di interfaccia, app e software di service, la nostra offerta di localizzazione software per il settore tecnologico elabora file di risorse come JSON e XML nella loro struttura originale, con controlli automatici che intercettano variabili danneggiate, stringhe troncate ed errori di formattazione prima che arrivino in una build di release.
I vostri tecnici possono approvare il glossario che costruiamo con voi, e le loro decisioni guidano poi ogni traduzione, sullo schermo e nel manuale. Testi HMI e manuali esistenti possono essere allineati in una memoria di traduzione invece di essere scartati. Il processo è certificato ISO 17100, con un secondo linguista qualificato che rivede ogni traduzione, e nei progetti sensibili le traduzioni riutilizzate dalla memoria vengono ricontrollate. Il nostro team interno di desktop publishing multilingue impagina poi i manuali nei formati originali, e memorie e glossari restano vostri, consegnati in formati portabili. Lavoriamo con team in Italia, Serbia e Spagna, e le nostre soluzioni linguistiche per il settore manifatturiero trattano software e documentazione come un unico progetto.
Dove si inserisce TUBE
Per le macchine il cui software e la cui documentazione cambiano a ogni release, TUBE è la nostra soluzione per mantenere quel linguaggio sotto il vostro controllo. Il vostro glossario e la vostra memoria di traduzione guidano la traduzione automatica, ogni traduzione approvata confluisce in una memoria di vostra proprietà ed esportabile, e il report di leverage mostra quanta parte di ogni aggiornamento HMI o revisione del manuale deriva da testi già approvati.
Domande frequenti
È la traduzione dei testi visualizzati sul pannello operatore di una macchina e nel software collegato: menu, pulsanti, nomi dei parametri, messaggi di stato e di allarme, help in linea e schermate di service. Si differenzia dalla traduzione di documenti perché i testi sono brevi, spesso privi di contesto, devono rispettare lunghezze di campo fisse e contengono segnaposto che il software compila a runtime.
Il Regolamento (UE) 2023/1230 richiede che le informazioni e le avvertenze scritte sulla macchina siano in una lingua facilmente comprensibile per gli utilizzatori, stabilita da ciascuno Stato membro, e che videoterminali e altri mezzi di comunicazione interattiva siano facilmente comprensibili. I simboli sono preferiti quando funzionano, ma ogni testo che resta sul pannello rientra nella regola linguistica.
Comunicate al traduttore il limite in caratteri o in pixel di ogni stringa, concordate abbreviazioni approvate nel glossario, eseguite la pseudo-localizzazione prima della traduzione per trovare i campi troppo corti e controllate ogni stringa tradotta rispetto al suo limite prima dell'importazione. Poi verificate il risultato sul pannello reale o su un simulatore.
Quello che il vostro software di progettazione può esportare e reimportare senza correzioni manuali. XLIFF è pensato per la traduzione e contiene note e limiti; Excel e CSV funzionano bene se la struttura è fissa, con chiavi stabili e colonne separate per limiti e commenti.
Può aiutare su grandi insiemi di stringhe ripetitive, soprattutto se è guidata dal vostro glossario e dalla vostra memoria approvati. I testi brevi e senza contesto sono però proprio quelli in cui la traduzione automatica sceglie più facilmente il significato sbagliato, quindi un traduttore specializzato deve rivedere ogni stringa, con particolare attenzione ad allarmi e avvertenze di sicurezza.
Perché gli operatori leggono entrambi. Se l'allarme e il capitolo sulla risoluzione dei guasti usano parole diverse per lo stesso componente, l'utilizzatore esita e chiama l'assistenza. Un glossario e una memoria unici portano ovunque la stessa formulazione approvata.
La traduzione dell'interfaccia utente riguarda di solito i testi stessi. La localizzazione comprende anche tutto ciò che li circonda: formati di data, numeri e unità, set di caratteri e font, lunghezza dei testi, layout e test in contesto, perché l'interfaccia funzioni come se fosse nata nella lingua dell'utilizzatore.
Fate parlare la stessa lingua a schermate e manuale
Se la vostra prossima release di macchina richiede testi HMI, allarmi, software di service e manuali in più lingue, inviateci un export di esempio e il manuale attuale. Analizzeremo formati, limiti e terminologia e vi proporremo un processo che mantiene ogni lingua allineata al vostro software.
Come possiamo aiutarvi?
Abbiamo le risposte giuste alle vostre domande.