Il formato SRX
Il formato SRX è stato sviluppato allo scopo di fornire una descrizione univoca e indipendente dallo strumento utilizzato della segmentazione dei documenti. La sua importanza è dovuta al fatto che la segmentazione del testo ha ripercussioni non indifferenti sull'individuazione di corrispondenze in TM, senza contare il fatto che committenti e agenzie di traduzione in molti casi applicano tariffe differenziate in base al numero di ripetizioni (che generano match interni) e di corrispondenze totali o parziali con le TM di progetto.
La segmentazione che può essere vista come una fase ‘a monte’ rispetto alla traduzione vera e propria — e infatti Melby la considera tale — viene realizzata nella maggior parte dei casi dallo stesso strumento CAT/TM contestualmente al caricamento dei testi di partenza (alcuni strumenti proprietari molto diffusi inglobano le regole di segmentazione all'interno delle TM).
Volendo ripristinare la segmentazione come una parte separata del workflow è possibile utilizzare Rainbow (cfr. 4.4.1) per il pretrattamento dei documenti e la creazione di ‘pacchetti di traduzione’ basati su XLIFF che potranno essere elaborati in un secondo momento con uno strumento CAT/TM.214
Per rispettare le specifiche del formato SRX sono necessari, al pari del TMX, due requisiti: la well-formedness XML e il rispetto della struttura rappresentata nello schema XML ufficiale messo a disposizione dalla LISA.
La radice di ogni documento è rappresentata da <srx>, il quale ha al suo interno i due elementi <header> e <body>. Il primo contiene una serie di specifiche sull'uso previsto del documento (ad es. se deve essere adottato il modello a cascata per l'applicazione degli schemi linguistici) e i comportamenti predefiniti (<formathandle>) relativi ai marcatori di formattazione di apertura e di chiusura interni al testo posti agli estremi superiore e inferiore dei segmenti.
Il secondo elemento, invece, rappresenta la parte fondamentale del documento, dal momento che contiene il set di regole di segmentazione che deve essere applicato a ogni schema linguistico e la mappatura delle lingue dove sono definiti gli schemi linguistici associati a ciascuna lingua mediante pattern matching della sigla identificativa. Tanto per la specifica delle varie regole, come si vedrà poco oltre, che per l'associazione delle lingue agli schemi linguistici e, di conseguenza, alle regole di ciascuno schema, viene utilizzata la corrispondenza di espressioni regolari.
Le regole sono contenute nell'elemento <languagerules> che raccoglie i vari schemi linguistici contrassegnati da un'etichetta (elemento <languagerule> con il relativo attributo languagerulename).
Ogni regola corrisponde a un elemento <rule> ed è costituita da tre componenti: l'attributo break (booleano), che specifica se si tratta di un'interruzione o di un'eccezione, il pattern eventualmente specificato nell'elemento <beforebreak> e quello in <afterbreak> che individuano la posizione del punto di applicazione (almeno una delle due parti della regola deve essere presente ma non necessariamente entrambe). La sequenza in cui le regole hanno effetto corrisponde all'ordine in cui sono specificate nella sezione <languagerule>.
La sezione <maprules> è invece relativa alla mappatura delle lingue e permette di associare il codice del locale (e quindi la lingua) dei documenti da processare a uno o più gruppi di regole fra quelli specificati in precedenza.
Come accennato nella sezione 4.4.4 è possibile infatti adottare due diverse politiche per l'assegnazione delle regole a un documento: il modello a cascata, secondo il quale a un documento vengono applicate le regole di tutti gli schemi linguistici con cui il codice del suo locale corrisponde oppure il modello standard in cui vengono processate solo le regole che corrispondono al primo schema linguistico fra quelli specificati con cui si registra un match.215
L'adozione di una o dell'altra politica deve essere specificata attraverso il valore dell'attributo cascade nell'intestazione in modo da risolvere i problemi di ambiguità rimasti aperti con la prima versione del documento (anche al prezzo, come in effetti è avvenuto, di perdere la retrocompatibilità).
La versione 1.0 dello standard non precisava infatti quale fosse la politica da adottare e questo ha lasciato aperta la via dell'interpretazione ai singoli produttori di strumenti CAT che davano così risultati di segmentazione diversi seppur a partire dallo stesso documento.
Applicare il modello ‘a cascata’ è più economico perché permette di specificare le regole una sola volta quando sono comuni a più schemi linguistici e di applicare via via quelle più specifiche solo al bisogno, senza replicare in tutti in più gruppi di lingue anche quelle generali.216
Le regole di base possono essere così incluse in uno schema predefinito associato al pattern ‘.*’ in modo che venga applicato a tutte le lingue, le regole per l'italiano possono essere associate a ‘IT.*’ ma quelle specifiche, ad esempio, per l'italiano svizzero sotto ‘IT-CH’. A un documento con locale ‘IT-CH’ sarebbero applicate le regole di tutti e tre i gruppi da quelle più generiche man mano a quelle più specifiche a seconda dei casi.
Adottando invece la politica predefinita le regole applicate sono solo quelle del primo schema linguistico il cui pattern corrisponde alla sigla della lingua, rendendo così necessaria la duplicazione delle regole in ogni gruppo anche quando queste sono effettivamente comuni a più di uno schema.
Questo approccio è meno economico ma rispetta le intenzioni degli ideatori dello standard ed è di fatto quello cui si sono attenuti molti strumenti anche proprietari (fra cui il vecchio ‘SDLX’).
L'SRX 2.0 permette entrambi i comportamenti ma non lascia spazio a interpretazioni, dal momento che la politica adottata è specificata univocamente nell'intestazione. Inoltre, nonostante le due versioni dello standard non siano compatibili, è sempre possibile convertire dall'1.0 al successivo con strumenti come Ratel. Per concludere, in figura 53 si riporta il corrispondente SRX di una regola già illustrata nella sezione 4.4.4 a proposito degli acronimi.
|
©inTRAlinea & Diego Beraldin (2013).
Una panoramica sugli strumenti di traduzione assistita
disponibili come software libero, inTRAlinea Monographs
This work can be freely reproduced under Creative Commons License.
Permalink: http://www.intralinea.org/monographs/beraldin/
