Il problema si vede quando il manuale è già tradotto
Stai facendo un controllo terminologico sulla versione inglese di un manuale.
Non stai cercando una frase più elegante. Non stai correggendo stile. Stai verificando che il testo tradotto continui a indicare le stesse parti della macchina con la stessa precisione della sorgente.
A un certo punto ti fermi. E non è il momento migliore per fermarsi: il controllo doveva essere una conferma finale, non l’inizio di un problema terminologico.
In punti diversi dello stesso documento trovi guard, cover e protective cover riferiti a quella che, dai rimandi del testo, sembra la stessa parte della macchina.
La figura è la stessa, il punto della procedura è lo stesso. Solo il nome cambia.
Presi singolarmente, quei termini non sono assurdi. In certi contesti possono anche essere corretti. Il problema nasce quando compaiono nello stesso manuale senza che il testo ti dia un criterio chiaro per distinguerli.
A quel punto non hai più un dubbio linguistico.
Hai un dubbio operativo. E sai già che, se lo lasci passare, potrebbe ritornare sulla tua scrivania.
Perché chi legge il manuale non sta facendo una revisione terminologica. Sta cercando di capire su cosa deve intervenire. Se trova cover, può pensare a una copertura da aprire. Se trova guard, può pensare a un riparo. Se trova protective cover, può immaginare un elemento che copre ma che ha anche una funzione di protezione.
La differenza può sembrare sottile.
Ma davanti a una macchina, le differenze sottili non sono sempre innocue.
Dentro la tua azienda magari tutti capiscono. Il progettista usa una parola, il service ne usa un’altra, il redattore ne eredita una terza da un manuale precedente. Il contesto aiuta. Le persone conoscono il prodotto. Sanno a cosa si stanno riferendo anche quando il nome cambia.
Il manuale, però, non vive dentro quel contesto.
Il manuale vive davanti a un utilizzatore, a un manutentore, a un tecnico sul campo. Vive spesso in un’altra lingua. Vive in un momento in cui la persona deve decidere se aprire, rimuovere, verificare, bloccare o lasciare dov’è una parte della macchina.
In un testo commerciale puoi anche variare un termine per non ripeterti. In un manuale tecnico, se il nome cambia, chi legge può legittimamente chiedersi se sia cambiato anche l’oggetto.
In un manuale tecnico, una parola è un collegamento fra testo e prodotto. Se quel collegamento è instabile, l’istruzione comincia a chiedere interpretazione proprio nel punto in cui dovrebbe ridurla.
Quando il problema compare nella versione inglese, la prima reazione è guardare la traduzione.
È normale.
Il dubbio si vede lì, quindi sembra nato lì. Magari il traduttore ha scelto tre termini diversi. Magari la memoria di traduzione era sporca. Magari il revisore non ha uniformato. Magari il controllo finale non ha intercettato la variante.
Tutto possibile.
Ma prima di concludere che il problema sia la traduzione, devi fare il passaggio più importante: tornare alla sorgente.
Torni alla sorgente e scopri che la decisione non era mai diventata regola
Apri il manuale italiano.
Vai a cercare i punti da cui sono nate quelle tre rese inglesi e trovi il vero problema.
In un punto c’era scritto “riparo”.
In un altro punto c’era scritto “carter”.
Nel capitolo sicurezza c’era scritto “protezione”.
A quel punto la versione inglese non sembra più l’origine del problema. Sembra quello che spesso è: il punto in cui il disallineamento diventa visibile.
La traduzione non inventa il caos. Lo trova nella sorgente e lo moltiplica.
Questo passaggio cambia tutto.
Finché guardi solo la lingua estera, puoi immaginare che il problema sia fuori dall’azienda: nel traduttore, nello strumento di traduzione assistita, nella memoria, nella revisione finale. Ma se nel testo italiano c’erano già tre nomi per la stessa area del prodotto, la traduzione non ha ricevuto una regola da rispettare. Ha ricevuto un’ambiguità da interpretare.
E qui bisogna essere precisi.
Riparo, protezione e carter non sono sempre sinonimi. Proprio per questo usarli come se lo fossero è pericoloso.
Un riparo può essere legato alla sicurezza dell’operatore. Un carter può essere percepito come una copertura, un involucro o un elemento di accesso. Una protezione può indicare una barriera, una funzione, un dispositivo o un concetto più generale.
La differenza non deve essere enorme per creare un problema. Basta che il testo non dica più con chiarezza se stai parlando dello stesso componente o di componenti diversi.
Magari, come redattore tecnico, ti riconosci subito in questa scena.
Perché spesso non hai creato tu questo disallineamento. Sei solo il primo che lo vede tutto insieme.
Lo trovi nei disegni, nei ticket del service, nei vecchi manuali, nelle correzioni dei tecnici, nei capitoli recuperati da una macchina precedente. A quel punto non stai scegliendo una parola da zero. Stai cercando di trasformare in una scelta unica parole che sono già entrate nel processo da strade diverse.
Chi progetta pensa alla funzione. Chi fa manutenzione pensa all’accesso. Chi scrive la sicurezza pensa al rischio. Chi parla con il cliente pensa al nome che usa il cliente. Ognuna di queste prospettive può avere una sua logica.
Il problema è che il manuale non può conservare tutte le abitudini dell’azienda come varianti libere.
Se in italiano hai “riparo”, “protezione” e “carter”, in inglese puoi ritrovarti con guard, cover, protective cover, casing, shield. Nelle altre lingue il ventaglio si apre ancora di più, perché ogni lingua costringe a scegliere fra parole che non si sovrappongono mai perfettamente.
Il risultato non è sempre una cattiva traduzione.
A volte è peggio: una buona traduzione di una sorgente terminologicamente debole.
Il testo scorre. La grammatica funziona. La frase sembra professionale. Solo che il collegamento fra parola e componente non è più stabile.
E quando questo succede, non basta dire: “Il traduttore doveva uniformare”.
Perché uniformare significa scegliere.
E scegliere come si chiama una parte della macchina non è una decisione solo linguistica. Non dovrebbe finire sulle spalle di chi traduce quando ormai il testo è già partito.
Il fornitore può aiutare. Non può governare a valle
Un traduttore tecnico scrupoloso, davanti a un problema del genere, si ferma.
Se nel testo sorgente trova “riparo”, “carter” e “protezione” usati in punti molto vicini, per indicare quella che sembra la stessa parte della macchina, segnala che qualcosa non torna e chiede se quelle tre parole indicano davvero tre concetti diversi, oppure tre varianti nate nel tempo e mai ripulite.
Questo può essere il valore aggiunto di un buon fornitore.
Ma c’è un limite che conviene non fingere di ignorare.
Il traduttore può applicare una decisione terminologica. Non può prenderla al posto dell’azienda.
Può vedere l’ambiguità, segnalarla, proporre un equivalente nella lingua di destinazione e mantenere coerenza, se riceve una regola da rispettare.
Ma non può sapere da solo se quella parte è un riparo di sicurezza, un carter di accesso, una protezione fissa o una copertura rimovibile.
Per saperlo non basta conoscere bene l’inglese, il tedesco o il francese. Serve conoscere il prodotto. Serve sapere se quella parte protegge l’operatore o la macchina, se può essere rimossa dall’utilizzatore o solo dal manutentore, se compare nell’analisi dei rischi, se ha un codice nei disegni, se nel catalogo ricambi viene chiamata in un altro modo.
Queste informazioni non stanno nel dizionario.
Stanno nel processo tecnico dell’azienda.
Per questo il modello “ci pensa l’agenzia” è comodo, ma fragile. È comodo perché sposta il problema a valle, quando il manuale sembra quasi finito e bisogna solo mandarlo in traduzione. È fragile perché l’agenzia arriva quando molte scelte sono già state fatte, oppure quando nessuno le ha fatte davvero e il testo si è riempito di abitudini.
Il problema non è il traduttore.
Il problema è chiedere al traduttore di compensare una decisione tecnica che l’azienda non ha preso.
E qui nasce l’equivoco successivo: “ma noi la terminologia la facciamo gestire all’agenzia”.
Il punto è che “gestire la terminologia” può voler dire due cose molto diverse.
1. Esiste una base terminologica approvata, condivisa, aggiornata nel tempo, collegata alle memorie di traduzione, usata nei progetti e restituita all’azienda come asset.
2. L’agenzia prende alcuni termini ricorrenti del manuale, li mette in una tabella, li abbina alla lingua target e cerca di mantenerli coerenti in quel lavoro.
Nel primo caso, la terminologia è già dentro un processo.
Nel secondo, stai solo cercando di mettere ordine per consegnare in tempo.
Una tabella di corrispondenze è meglio del nulla. Aiuta il traduttore a non cambiare termine ogni volta. Aiuta il revisore a controllare qualche ricorrenza. Aiuta il progetto a non disperdersi completamente.
Una tabella di corrispondenze può aiutare un progetto, ma non governa il prodotto.
Una tabella di progetto può dirti che, in quel manuale, “carter” è stato tradotto con cover.
Non ti dice se, nel prossimo manuale, la sorgente dovrà usare “carter”, “riparo” o “protezione”.
Può aiutarti dentro quella consegna. Non impedisce alla sorgente italiana di ripartire, fra tre mesi, con gli stessi componenti chiamati in modi diversi.
La terminologia di progetto nasce quando il testo è già scritto. Guarda quel manuale, quella lingua, quella consegna. Ti aiuta a non peggiorare quel lavoro, ma non cambia il punto in cui il problema è nato.
Il governo terminologico nasce prima.
Decide qual è il termine corretto nella sorgente. Definisce i sinonimi vietati. Collega il termine a una definizione, a un contesto e, quando serve, a un’immagine. Dice chi approva quella scelta. E soprattutto fa in modo che quella scelta rientri nel modo in cui scrivi, traduci, revisioni e pubblichi anche il manuale successivo.
La differenza la vedi nel manuale successivo.
Se il glossario nasce dopo che il manuale è già stato scritto, non ti impedisce di usare il termine sbagliato. Se resta nel perimetro dell’agenzia, non cambia il modo in cui scriverai la prossima procedura. Se viene aggiornato solo quando parte una nuova traduzione, arriva sempre quando il testo ha già preso la sua direzione.
Arriva tardi. E quando una soluzione arriva sempre tardi, sta inseguendo il problema, non lo sta governando.
Il fornitore serve, eccome. Ma deve portare nelle lingue una decisione già governata, non diventare il luogo in cui quella decisione nasce.
Perché il nome delle parti della macchina non è solo una questione di traduzione.
È una parte della memoria tecnica del prodotto.
E quella memoria, se vuoi governarla davvero, deve restare dentro il processo con cui il prodotto viene descritto, aggiornato e pubblicato.
Excel non è un sistema di controllo
Quando capisci che la terminologia non può essere decisa a valle, la reazione giusta è riportarla dentro l’azienda, e spesso il primo strumento è Excel.
Va benissimo.
Excel è semplice, economico, familiare. Puoi usarlo per iniziare a mettere ordine: termine corretto, sinonimi vietati, definizione, contesto, lingua sorgente, lingue di destinazione, note d’uso, magari un’immagine e un responsabile della decisione.
Se oggi non hai nulla, un Excel fatto bene è già un passo avanti enorme.
Il problema nasce quando lo scambi per il punto di arrivo.
Excel serve a prendere una decisione. Il processo serve a farla rispettare.
Il problema è che il file Excel sta in una cartella condivisa. Qualcuno lo ha mandato all’agenzia. Ogni tanto viene aggiornato. In riunione si può dire: “Il glossario ce l’abbiamo”.
Sulla carta è vero. Ma questo file entra davvero nel lavoro di tutti i giorni? Spesso no.
Il punto non è se il glossario esiste. Il punto è se ti evita di scoprire il problema quando ormai devi pubblicare.
Se stai scrivendo una procedura e usi “carter” dove il termine approvato è “riparo”, Excel te lo segnala?
Se il testo italiano parte in traduzione con un sinonimo vietato, Excel lo intercetta?
Se la traduzione rientra con una variante non approvata, Excel la blocca prima della pubblicazione?
Da solo, no.
Non perché Excel sia inutile. Ma perché Excel non è un sistema di controllo. È un contenitore di dati. Può raccogliere una decisione, ma non può garantirne l’applicazione in tutti i punti in cui il testo nasce, cambia, viene tradotto e rientra.
Questa cosa in produzione sarebbe evidente.
Se stabilisci che una vite deve essere serrata con una coppia precisa, non ti limiti a scrivere quel valore in un file che “tutti possono consultare”. Lo porti nella procedura, negli strumenti, nei controlli qualità, nei punti in cui quella decisione può essere applicata o violata.
Con la terminologia dovrebbe succedere la stessa cosa.
Se hai deciso che in quel contesto il termine corretto è “riparo”, e che “carter” non va usato, non devi scoprirlo quando il manuale è già tradotto in inglese.
Devi intercettarlo prima: quando il testo è ancora in sorgente, quando puoi correggerlo senza riaprire il progetto di traduzione e prima che l’ambiguità entri nelle lingue.
Il controllo vero comincia lì.
Non nel PDF finale, non nella revisione dell’ultimo giorno, non nella mail del traduttore che chiede se “carter”, “protezione” e “riparo” indicano la stessa cosa.
Comincia quando la terminologia approvata entra nel sistema di redazione e viene usata per verificare il testo sorgente.
Se un termine è corretto, il redattore lo vede. Se è vietato, il sistema lo segnala. Se una parola è ambigua, qualcuno la chiarisce prima che diventi una scelta obbligata in tre lingue diverse.
Poi quella stessa base terminologica deve seguire il testo nel passaggio successivo.
Quando il contenuto parte in traduzione, il traduttore non dovrebbe ricevere un file Excel separato da ricordarsi di aprire. Dovrebbe trovare la terminologia già collegata al progetto: termini corretti, sinonimi vietati, note di contesto.
Così non gli stai dicendo genericamente: “fai attenzione alla terminologia”.
Gli stai dando una regola da applicare.
E quando le lingue rientrano, il controllo non dovrebbe essere solo una lettura a campione o una ricerca manuale nel PDF. Dovrebbe verificare se i termini approvati sono stati rispettati e se sono entrati termini non approvati.
Non si tratta di passare da Excel a uno strumento più sofisticato per il gusto di usare uno strumento più sofisticato.
Si tratta di passare da un file che conserva la decisione a un processo che la fa intervenire nei punti in cui può rompersi.
Prima che il testo parta.
Mentre viene tradotto.
Quando le lingue rientrano.
Prima che il manuale venga pubblicato.
Se la terminologia resta fuori da questi passaggi, qualcuno deve sempre ricordarsi di applicarla a mano. E se il controllo dipende da qualcuno che deve ricordarsi cosa fare, non hai un processo: hai una buona abitudine che può saltare al primo cambio di urgenza, lingua o persona.
È qui che Excel mostra il suo limite: non perché sia sbagliato, ma perché un foglio, da solo, non controlla un processo.
Le decisioni prese su Excel devono uscire dal file e andare dove il testo viene scritto, tradotto, controllato e pubblicato.
Altrimenti hai solo spostato il problema.
Se automatizzi una terminologia debole, acceleri il rischio
Oggi il controllo terminologico non passa più solo dalle mani di un traduttore. Passa da memorie, CAT, controlli automatici, traduzione automatica neurale, modelli linguistici e funzioni basate sull’intelligenza artificiale.
Tutto questo può aiutare: può far risparmiare tempo, intercettare incoerenze, ridurre lavoro ripetitivo e rendere più veloce il controllo di grandi volumi di testo.
Ma solo se lavora su decisioni chiare.
Se la sorgente usa tre nomi per lo stesso componente, l’automazione non elimina l’ambiguità. La processa.
Ed è qui che si vede la differenza fra usare strumenti automatici e governare davvero la terminologia.
Se la terminologia resta fuori dal processo, ogni automatismo lavora su materiale che deve interpretare. Il CAT suggerisce. La memoria recupera. La NMT pretraduce. Un controllo automatico segnala qualche incoerenza. Un modello linguistico può perfino rendere la frase più fluida.
Ma se nessuno ha stabilito che, in quel contesto, il termine corretto è “riparo” e che “carter” non va usato, lo strumento non sta applicando una regola.
Sta scegliendo fra opzioni che il processo non ha chiarito.
E quando un sistema automatico sceglie fra possibilità che nessuno ha chiarito, il risultato può sembrare corretto proprio mentre ti sta portando fuori strada.
Non perché la tecnologia sia pericolosa in sé. La tecnologia è utile, a volte indispensabile. Ma funziona bene quando corre su binari già decisi: termini approvati, sinonimi vietati, sorgente controllata, traduzione assistita, verifica al rientro.
Se invece la usi per compensare una sorgente ambigua, non stai automatizzando un processo.
Stai accelerando una serie di interpretazioni.
E nei manuali tecnici le interpretazioni lasciate libere sono il punto in cui il controllo comincia a cedere.
La terminologia tecnica diventa controllo solo quando entra nel processo.
Non quando esiste in un file.
Non quando viene mandata all’agenzia.
Non quando qualcuno la corregge alla fine.
Non quando un controllo automatico prova a intercettare qualcosa a valle.
Diventa controllo quando accompagna il contenuto nei punti in cui può rompersi: mentre scrivi la sorgente, mentre prepari il pacchetto di traduzione, mentre il traduttore lavora, quando le lingue rientrano e prima che il manuale venga pubblicato.
A quel punto non stai più parlando di un glossario.
Stai parlando di informazioni di prodotto.
Stai parlando del modo in cui la tua azienda decide come si chiamano le parti della macchina, come quella decisione viene trasferita nelle istruzioni, come viene mantenuta nelle lingue e come resta disponibile quando il prodotto cambia.
Per te, technical writer, questo è il punto in cui il lavoro cambia davvero.
Non significa compilare una tabella in più. Significa smettere di essere l’ultima persona che scopre il problema quando il manuale è quasi chiuso, la traduzione è rientrata e tutti hanno fretta di pubblicare.
Significa portare in azienda un metodo di controllo sulla sorgente, sulla traduzione e sul rientro delle lingue.
Non un altro file da ricordarti di aprire.
Un controllo che intercetta il problema prima che diventi traduzione incoerente, revisione urgente o pubblicazione da rifare.
Scopri come si fa, in concreto
Ho caricato nel Club dei Technical Writers di because il video completo su come controllare la terminologia prima e dopo la traduzione. Vedi come partire da una terminologia decisa, controllarla nella sorgente, portarla in traduzione e verificarla al rientro delle lingue, senza aspettare che l’incoerenza esploda nel PDF finale.
È un contenuto riservato ai membri del Club, che puoi provare gratuitamente per 3 mesi. Appena entri, puoi guardare subito l’approfondimento.
Se sei già iscritto al Club dei Technical Writers di because, trovi questo video nella sezione “Webinar e Workshop” con il nome di “Terminologia: come controllarla PRIMA e DOPO la traduzione”.
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.
E se leggendo ti è venuto in mente qualcuno che, nella tua azienda o in quella di un cliente, si sente stretto tra il lavoro manuale che non regge più e l’IA fuori controllo che promette miracoli, inoltragli questo articolo.