3.4 Post-editing e QA

3.4.1 Strumenti Gettext

Autore:	Bruno Haible
Licenza:	GNU GPLv2
Pagina web:	http://www.gnu.org/software/gettext/
Versione:	0.18.1 (maggio 2010)

Un primo e fondamentale controllo della validità dei file PO viene realizzato con l'utilità a riga di comando msgfmt. In realtà questo comando ha come scopo principale la compilazione ma se invocato, ad esempio, nella forma msgfmt --statistics -c -v -o /dev/null <file po> fornisce un risultato dettagliato, completo di statistiche ed eseguendo i controlli di validità sull'intestazione e sui placeholder (chiamate nella traduzione del programma ‘specifiche di formato’) secondo il formato delle variabili del linguaggio utilizzato. Il programma segnala il numero di errori e la loro natura, nonché la posizione del file dove sono stati generati.

Anche la presenza di messaggi duplicati, ovviamente, costituisce un grave errore di sintassi, che viene registrato da msgfmt e impedisce la compilazione. Per non dover risolvere questo problema ‘a mano’, cosa impossibile a meno che non si voglia intervenire pesantemente sulla sintassi PO, GNU gettext comprende l'utilità msguniq.

Quest'ultima è in grado di riconoscere i messaggi duplicati all'interno di un file PO o di una directory contenente file PO. In primo luogo, lo strumento permette di selezionare i messaggi: con l'opzione -repeated restituisce sullo standard output o su un file PO (specificato con -o) solo i messaggi duplicati e con l'opzione -unique solo quelli univoci.

In tutti gli altri casi, l'output del comando contiene solo messaggi univoci, in cui i duplicati sono stati completamente eliminati. I commenti, commenti estratti automaticamente sono sommati, salvo nel caso in cui si ricorra all'opzione -use-first (nel qual caso gli unici a essere conservati saranno quelli della prima occorrenza del messaggio). I riferimenti al sorgente, invece, sono in ogni caso accumulati.

Il programma presenta ulteriori funzionalità per la codifica e la leggibilità delle stringhe che meno hanno a che vedere con la QA in senso stretto e per cui si rimanda alla documentazione presente in [GNU Project, 2010a].

È facile notare, in ogni caso, che msgfmt non è uno strumento completo per la QA nemmeno restringendo il campo di applicazione ai soli PO. Uno dei controlli basilari che non viene effettuato, ad esempio, è se la traduzione sia stata davvero portata a termine, ovvero, che non esistano messaggi fuzzy o non tradotti. Per questo motivo, gli strumenti che si affidano a msgfmt per la validazione del PO devono integrare ulteriori verifiche interne (come l'uscita dalla sessione con verifica dei messaggi non pronti in GNU Emacs).

Dal punto di vista ‘tecnico’ non si tratta di una vera e propria mancanza, dal momento che un messaggio non tradotto non vanifica gli sforzi del localizzatore e non pregiudica il funzionamento del programma: molto semplicemente, non trovando la funzione gettext corrispondenze nel catalogo dei messaggi la stringa rimarrà agli occhi dell'utente finale in lingua originale. Tuttavia, come ogni traduttore sa, l'alternanza di stringhe tradotte a stringhe non tradotte va a scapito della qualità generale del lavoro ed è bene che esistano dei meccanismi di verifica e avvertimento in tal senso.

3.4.2 Pofilter

Autori:	D. Bailey, F. Wolff, W. Leibbrandt et al.
Licenza:	GNU GPLv2
Pagina web:	http://translate.sourceforge.net
Versione:	1.8.1 (novembre 2010)

Si tratta di uno strumento a riga di comando146 che permette di effettuare una serie di verifiche sul contenuto di file bilingui, in formato PO, XLIFF o TMX. Anche in questo caso, come in molti altri del TTK, l'utilità si propone non come un'alternativa ma come una soluzione complementare all'infrastruttura GNU Gettext e, come in molti altri casi, è modellata su uno strumento di quest'ultima (msgfilter).

I controlli di validità di pofilter intendono colmare le lacune messe in evidenza per msgfmt, come il controllo delle maiuscole, delle variabili, degli acceleratori e delle traduzioni incomplete. I messaggi ‘problematici’ che non superano uno o più controlli verranno estrapolati dai PO di partenza e inviati sullo standard output, che può essere rediretto in un nuovo file PO.

Il risultato contiene i messaggi che potrebbero richiedere l'intervento dell'umano, corredati da commenti del traduttore con il prefisso (pofilter) in cui si spiega la natura dell'errore, cioè quale o quali test non sono stati superati, in modo da facilitarne la correzione, che deve essere effettuata ancora una volta a mano da parte del traduttore. Una volta ultimati gli interventi correttivi è possibile utilizzare lo strumento pomerge (cui si è accennato nella sez. 2.4.3) per reintegrare le nuove stringhe nei PO iniziali.

Come la maggior parte delle utilità a riga di comando del TTK, anche pofilter accetta in input file singoli o, eventualmente, intere directory contenenti i file da processare (eventuali esclusioni sono da specificare con l'opzione -x seguita dal una sequenza che corrisponde ai nomi dei file da ignorare).

Dal momento che i file in ingresso sono, indipendente dal formato TU o cataloghi, è possibile selezionare quali messaggi devono essere analizzati, ad esempio, -review e -fuzzy includono nel controllo i messaggi marcati per la revisione o fuzzy, mentre le corrispondenti opzioni -noreview e -nofuzzy hanno il comportamento opposto.

Oltre alla rilevazione degli errori l'intervento del programma può essere configurato con -nonotes, che evita l'inserimento dei commenti esplicativi sulla natura dell'errore, mentre risulta particolarmente interessante l'opzione -autocorrect che ove possibile invece di inserire le note tenta di correggere in modo automatico il problema riscontrato.

Lo script pofilter ha a sua disposizione 46 filtri che possono essere eseguiti singolarmente oppure in gruppo a seconda dello scopo cui è destinato il PO. Esistono infatti dei gruppi ‘standard’ di filtri, o test, associati ai più comuni campi di applicazione dei PO all'interno del SL: OpenOffice, Mozilla, GNOME, KDE, Drupal o wxWidgets. È possibile selezionare un gruppo di test con le omonime opzioni (es. -openoffice, -mozilla, eccetera). Esistono inoltre due opzioni che permettono all'utente di specificare in modo esplicito quali test debbano essere eseguiti -test=<filtro> oppure no -excludefilter=<filtro> su un determinato input.

Si presenta a continuazione una classificazione e una descrizione dei test di pofilter, accompagnati da una breve descrizione del tipo di errori rilevabili con ciascuno di essi.

Classificazione dei test

In ordine di importanza, e quindi di gravità ai fini della qualità del lavoro, i test possono essere raggruppati in quattro categorie, a seconda del tipo di errore rilevato:

1. critici (compromettono il funzionamento del programma)
   • accelerators: controlla che gli acceleratori siano utilizzati in modo coerente nella stringa di partenza e in quella tradotta e secondo le convenzioni del gruppo di appartenenza del PO;
   • escapes: verifica che le sequenze di escape utilizzate nelle due stringhe coincidano;
   • newlines: rileva eventuali variazioni nel numero di caratteri di fine riga (\n) nelle due stringhe;
   • nplurals: controlla che il numero di plurali presenti (l'indice [0], [1], ecc.) nelle stringhe tradotte coincida con quello specificato nell'intestazione del PO;
   • printf: segnala variazioni nella natura dei placeholder ma gestisce correttamente le variazioni dell'ordine degli stessi in gruppi dove esiste una sintassi particolare a tale scopo (es. -gnome);
   • tabs: verifica che non ci siano variazioni nel numero di tabulazioni (\t) fra le due stringhe;
   • variables: controlla che le variabili (dipendenti dal formato) utilizzate nelle due stringhe non siano state alterate;
   • xmltags: rileva le modifiche o la soppressione di tag di formattazione in stile (X)HTML, ignorando le espressioni racchiuse fra parentesi angolari che comprendono l'intera stringa e permette la traduzione degli attributi, ove necessario;
2. funzionali (sono fonte di confusione per l'utente finale)
   • acronyms: controlla che gli acronimi siano rimasti invariati;
   • blank: fallisce se un msgstr contiene solo spazi, nonostante risulterebbe tradotto;
   • emails: rileva la presenza di indirizzi email all'infuori dei campi di credits e controlla che quando compaiono nella stringa sorgente non siano stati alterati in quella tradotta;
   • filepaths: verifica che i percorsi dei file non siano stati alterati nella stringa tradotta;
   • functions: controlla che i nomi delle funzioni non siano stati tradotti;
   • gconf: verifica che non siano state apportate modifiche ai nomi delle impostazioni gconf;
   • kdecomments: rileva le eventuali traduzioni delle stringhe "_: testo" che da un punto di vista storico corrispondono ai contesti di disambiguazione in stile KDE (prima dell'introduzione del campo msgctxt nel PO) e non devono essere tradotte;
   • long: fallisce se la traduzione è molto più lunga della stringa originale;
   • musttranslatewords: controlla che tutti i termini presenti nel file specificato con l'opzione -musttranslatefile siano stati tradotti, cioè non compaiano nella stringa della traduzione;
   • notranslatewords: controlla che tutti i termini elencati nel file specificato con l'opzione -notranslatefile siano rimasti invariati nella stringa tradotta;
   • numbers: rileva eventuali variazioni (anche nell'ordine) fra le cifre presenti nelle due stringhe;
   • options: controlla che le opzioni dei comandi non siano state alterate nella traduzione (molto utile traducendo la documentazione di software);
   • purepunc: verifica che i messaggi costituiti da soli segni di punteggiatura non siano stati alterati in fase di traduzione;
   • sentencecount: fallisce se il numero di frasi è variato nella stringa tradotta rispetto a quella di partenza (genera falsi positivi in caso di riformulazione);
   • short: si attiva se la traduzione è molto più corta dell'originale;
   • spellcheck: esegue il controllo ortografico sulle stringhe tradotte, a condizione che sia installato pyEnchant147 e i dizionari Hunspell o aspell effettuando un primo controllo sull'inglese per aggiungere a una lista di esclusione le espressioni che non lo superano, in seguito controlla le stringhe tradotte tenendo conto di questa lista suggerendo le possibili correzioni ortografiche nella nota esplicativa;
   • urls: controlla che gli URL non siano stati alterati nella traduzione;
   • unchanged: fallisce se rileva che la traduzione è identica all'originale;
3. cosmetici: penalizzano la leggibilità del testo
   • brackets controlla che il numero di parentesi coincida nelle due stringhe
   • doublequoting: controlla che il numero di apici doppi (eccetto i delimitatori) all'interno delle due stringhe coincida, tenendo conto delle convenzioni linguistiche specificate con l'opzione -language;
   • doublespacing: rileva la presenza di spazi ripetuti nella stringa tradotta quando non sono presenti in quella sorgente e viceversa;
   • doublewords: controlla la presenza di parole ripetute nella traduzione;
   • endpunc: verifica che la punteggiatura corrisponda nelle due stringhe (può generare falsi positivi anche se il filtro è sensibile alle convenzioni linguistiche delle principali lingue europee e asiatiche);
   • endwhitespace: controlla che la presenza di spazi alla fine delle due stringhe coincida;
   • puncspacing: rileva l'eliminazione dello spazio dopo i segni di punteggiatura che lo richiedono;
   • simplecaps: fallisce se l'uso delle maiuscole è molto diverso fra le due stringhe;
   • simpleplurals: estrae i messaggi in cui la stringa inglese contiene una parola che finisce con i caratteri (s) in modo da controllare che l'ambivalenza singolare/plurale sia mantenuta in lingua d'arrivo;
   • startcaps: controllare che le maiuscole/minuscole a inizio stringa siano mantenute nella traduzione;
   • singlequoting: controlla che il numero di apici singoli all'interno delle due stringhe coincida;
   • startpunc: verifica che la punteggiatura all'inizio del messaggio coincida nelle due stringhe;
   • startwhitespace: controlla che la presenza di spazi all'inizio delle due stringhe coincida;
   • validchars: rileva la presenza di caratteri non validi nella traduzione, richiede che sia passato un file codificato Unicode (UTF-8) attraverso l'opzione -validcharsfile contenente i caratteri validi nella lingua d'arrivo;
4. di estrazione: il filtro estrae determinate categorie di segmenti
   • compendiumconflicts rileva la presenza della stringa #-#-#-#-# inserita creando un compendium con msgcat qualora fossero rilevate delle incoerenze nella traduzione di uno stesso messaggio, che potrebbe essere passata dal compendium al PO in traduzione preprocessandolo con msgmerge;
   • credits: rileva il corretto completamento dei campi dove devono essere inseriti i nomi dei traduttori;
   • hassuggestion: è sensibile alla presenza di suggerimenti nella traduzione (es. traduzioni alternative nei file XLIFF);
   • isfuzzy: estrae tutti i messaggi contrassegnati come fuzzy;
   • isreview: riconosce ed estrae i messaggi marcati per la revisione;
   • untranslated: estrae i messaggi non tradotti (campo msgstr vuoto), utile per salvarli temporaneamente in un file separato e riunire poi il lavoro in un secondo momento.

Concludendo, pofilter mette a disposizione del localizzatore tutto il necessario per svolgere un lavoro di qualità: i test sopraelencati coprono infatti una vasta gamma di errori molto comuni di formattazione che spesso possono sfuggire anche revisione umana. Com'è possibile osservare, l'operato di msgfmt qui viene svolto dal filtro prinft, e questo consente di utilizzare virtualmente il solo pofilter come strumento esclusivo di QA per un progetto basato su PO.

Il meccanismo di rilevazione degli errori che correda ciascun risultato ‘positivo’ di una nota esplicativa ed eventualmente delle possibile correzioni, assieme alla possibilità di estrarre i messaggi da correggere in un nuovo file che può in seguito essere riunito con il PO principale rende molto più semplice il compito del traduttore o del coordinatore del progetto di localizzazione.

Uno degli svantaggi di questo strumento è dato dai falsi positivi che vengono restituiti anche se non era presente alcun errore. Tuttavia, da questo punto di vista, è meglio operare qualche controllo in più, rispetto a un lavoro frettoloso. Inoltre, è molto probabile che con il passare del tempo e il supporto a nuove lingue le caratteristiche di pofilter maturino producendo così risultati anche migliori.

Le pagine dedicate a pofilter nel sito del progetto sono curate e complete di esempi di applicazione pratici. È da sottolineare che le pagine del wiki di TTK & Pootle, che sono state cruciali per la comprensione dell'argomento nonché fonte inesauribile di spunti per questa e molte altre sezioni del presente lavoro, sono disponibili anche in versione italiana.148

3.4.3 Considerazioni finali

Le utilità di QA presentate in questa sezione corrispondono agli strumenti utilizzati nei progetti di localizzazione di SL in grado di controllare la validità dei file PO. A questo proposito una soluzione, forse la più tradizionale, fa parte dell'infrastruttura GNU Gettext e permette di rilevare gli errori di sintassi e/o le omissioni del traduttore umano in fase di compilazione.

Una seconda soluzione, invece, è stata messa a punto dagli sviluppatori del TTK come ‘complemento’ a GNU Gettext ed è molto adatta ad essere implementata non solo in locale, ma anche e soprattutto negli ambienti di traduzione online (come Pootle), in cui il traduttore non ha necessariamente accesso ai file di lavoro né ha a disposizione i mezzi o le competenze per compilare il PO e rilevare gli errori.

In particolare pofilter rappresenta un'ottima integrazione per tutti gli editor di PO, anche molto avanzati, che non dispongono (ancora) di strumenti di QA interni, come Virtaal e Lokalize. Inoltre, dal momento che il programma accetta in ingresso anche file XLIFF e TMX, è possibile impiegarlo anche al di fuori del contesto dell'internazionalizzazione del SL.

Una parte dei filtri però perde di significato quando si tratta di documenti estranei alla localizzazione, in particolare tutti quelli classificati come ‘critici’ e una piccola parte di quelli ‘funzionali’, in quanto non ha più senso senso al di fuori delle interfacce grafiche controllare la presenza di acceleratori, placeholder o sequenze di escape, e così via.

Appare quindi evidente che né le utilità di Gettext né pofilter sono applicabili immediatamente alle esigenze ‘tradizionali’ del traduttore in generale. Una soluzione molto simile e più completa, a questo riguardo, è rappresentata da CheckMate (cfr. sez. 4.4.3) che ha il vantaggio di essere compatibile con l'ampia gamma di formati supportata dall'infrastruttura Okapi. I criteri di qualità presi in esame in questo contesto, anche se classificati in modo leggermente diverso, sono in realtà molto simili a quelli esposti nella sezione appena conclusa, dal che emerge ancora una volta come il workflow PO possa essere preso a modello di quel che avviene in generale.

Infine, a proposito delle verifiche di QA per il traduttore che intenda affidarsi al SL, si è già visto che esistono anche utilità integrate all'interno di strumenti CAT general purpose come la convalida di tag e l'estensione LanguageTool in OmegaT (cfr. sez. 3.3.1).