Aiuto:Strumenti per la rilettura/Sandbox

La finalità degli Strumenti per la rilettura

Per rilettura indendiamo, a oggi, la correzione di un testo per renderlo ragionevolmente simile alla fonte, sia come contenuto, che come formattazione. L'ambiente in cui facciamo questo lavoro è il nsPagina, organizzato in modo che il testo da correggere, come tutti sapete, viene modificato fianco a fianco dell'immagine di una pagina della fonte; spesso ci riferiamo a questa procedura di rilettura con originale a fronte con il termine di proofreading.

Dopo un po' di proofreading, ci si accorge che moltissime correzioni e applicazioni di formattazione sono ripetitive, e si scopre l'utilità dei pulsanti di formattazione e della toolbar, ma passato un altro po' di tempo, ci si accorge che manca sempre qualche pulsante particolare e specifico per il testo che si sta correggendo: è la fase in cui, magari con un piccolo aiuto da utenti esperti, si creano pulsanti personalizzati, e all'inizio sembra di aver raggiunto il massimo possibile dell'automazione.

Passa ancora il tempo, e ci si accorgere che anche premere ripetutamente gli stessi pulsanti è un'attività ripetitiva, e parecchio noiosa, soprattutto nel caso che si faccia un "proofreading sistematico", lavorando per parecchie pagine di seguito della stessa opera. Se stiamo lavorando in una raccolta di poesie, e non siamo particolarmente pazienti, è noioso applicare in ogni benedetta pagina il tag poem; le righe intestazione della pagina seguono sempre lo stesso schema a pagine alterne; l'OCR commette sempre gli stessi errori caratteristici di quell'opera, e leggermente diversi da quelli che sono frequenti in altre opere. Si presenta l'esigenza di disporre di strumenti di automazione fortemente personalizzabili, sia per quanto riguarda le preferenze individuali, che per quanto riguarda le particolarità dell'opera. La personalizzazione dev'essere agevole e rapida; non deve richiedere l'apertura e correzione di pagine diverse da quella che si sta rileggendo, nè deve richiedere competenze specifiche in linguaggi come javascript; se possibile, la memorizzazione deve scattare nel momento stesso in cui si inserisce la correzione come "effetto collaterale" della correzione stessa. In poche parole, il sistema di automazione deve apprendere e ricordare quello che ha appreso durante la normale attività di correzione del testo.

Tutto, inoltre, è reso molto più difficile da alcune scelte e compromessi "filosofici" del linguaggio di markup di wiki, finalizzati al rendere le cose più facili all'utente medio, ma disastrosi del punto di vista dell'automazione. Il markup wiki è un markup "mal conformato", al contrario dell'html e dei comunissimi codici usati nei forum, e ormai non c'è niente da fare: tocca accettare questa ulteriore, e inutile, difficoltà con pazienza e spremitura di meningi.

Rilettura in pratica

Vi sono motivi per ritenere che ognuno dei rilettori adotti uno specifico stile di lavoro personale, e abbia i suoi "trucchi del mestiere, le sue abitudini, i suoi metodi. L'obiettivo comunque è sempre lo stesso: produrre un testo identico, o quasi identico, alla fonte, dargli una formattazione gradevole e simile all'originale, e aggiungere qualcosa che costituisce lo "stile di it.wikisource". L'identità fra testo trascritto e testo originale dev'essere molto spinta, fino al rispetto rigoroso della punteggiatura originale dell'epoca (con qualche noioso problema di conversione di trattini, virgolette ecc.) e alle convenzioni ortografiche del tempo (es: nei testi molto antichi perché si scriveva perche; in quelli solo "vecchi" si scriveva perchè). La necessità di rispettare le convenzioni ortografiche originali diminuisce moltissimo l'utilità dei tool di correzione attivi anche in alcuni browser, che si basano sull'ortografia e sul dizionario dell'italiano attuale. Vi sono anche dei casi in cui un autore ha utilizzato di proposito convenzioni particolari, con fondatissimi motivi, tentando di "costruire regole di buon italiano" senza successo (ad esempio, nelle opere curate da Carducci non compaiono più e così, ma piú e cosí).

Nella rilettura vi sono due situazioni di partenza:

il testo che si comincia a correggere proviene direttamente da un'interpretazione OCR del testo rappresentato in immagine; in questo caso, sono frequenti gli errori di interpretazione, ma sono assenti gli "errori sistematici" tipo variazioni delle maiuscole, variazioni della punteggiatura, delle tipo di virgolette, dell'uso di corsivo e di grassetto ecc.;
il testo è tratto da una trascrizione e correzione già pubblicata sul web, talora derivante da una diversa edizione dello stesso testo, e allora le differenze sono sistematiche e difficili da trovare. Paradossalmente, è più faticoso correggere questo tipo di opere che testi OCR puri; in questi testi le differenze non emergono "a colpo d'occhio".

In un caso e nell'altro, lo "stile it.wikisource" impone:

di verificare e correggere le spaziature attorno alle parole e ai segni di interpunzione;
di trasformare nei caratteri corretti gli apostrofi "dattilografici" prodotti dalla tastiera italiana in "vere virgolette";
di eliminare i caratteri di acapo semplici ("riunire le righe dello stesso paragrafo") e di separare i paragrafi con una riga vuota.
di inserire anche le intestazioni di pagina nel box header (solo nelle pagine che la contengono) utilizzando il template RigaIntestazione e l'eventuale piè di pagina nel box footer, utilizzando il template PieDiPagina;
di applicare la numerazione ai versi (anche se manca nell'originale);
per le opere in versi, lo standard attuale impone di utilizzare il tag <poem>. In questo caso diventano importanti, e vanno conservati, sia eventuali spazi a inizio riga, che (ovviamente) gli acapo semplici a fine verso.

I tool di base e la corretta sequenza del loro uso

elimina riga 1

Nel caso dei testi provenienti da OCR, la prima riga contiene generalmente l'intestazione della pagina (di solito, il numero pagina e il titolo del libro o del capitolo). Di regola, l'OCR dell'interstazione è di pessima qualità con un numero di errori particolarmente alto; piuttosto che riutilizzarlo, è opportuno eliminarlo e scriverlo daccapo. Il tool elimina riga 1 elimina la riga 1 ;-) con un singolo click; molto più veloce che selezionare con il mouse e premere il tasto Cancella. E' la prima cosa da fare su una pagina "grezza".

aggiusta paragrafi

Aggiustare i paragrafi, ossia digitare un secondo acapo in fondo a ogni riga che conclude un paragrafo, è abbastanza noioso. Per automatizzare questa operazione, si può utilizzare il tool aggiusta paragrafi, che "ragiona" secondo questo principio: Se una riga finisce con un acapo o altri segni di interpunzione che generalmente chiudono un paragrafo, come .?! e simili, allora è molto probabile che lì finisca un paragrafo e agisce di conseguenza aggiungendo a fine riga un ulteriore acapo.

ATTENZIONE: Prima di utilizzare il tool è necessario identificare le zone in versi, in cui la regola non vale e in cui NON devono essere aggiunti acapo nemmeno se un verso termina con un segno di interpunzione tipo .?!. Cominciando a lavorare su una pagina che contiene versi, la PRIMA cosa da fare, quindi, è identificare le zone dei versi con il tag poem.

postOCR

Il primo passo per l'automazione delle correzioni è stato il tool postOCR, sviluppato sulla base di analogo tool della wikisource inglese, e adattato all'italiano. Il tool è "abbastanza intelligente", in quanto esegue una serie di piccole correzioni standard evitando di danneggiare il codice di template, link, ecc, e variando il proprio comportamento a seconda che il testo sia poesia o prosa. Ad esempio, postOCR riunisce le righe separate da un acapo semplice, e riunisce le parole spezzate a fine riga; ma non riunisce le righe all'interno dei testi poetici perchè "riconosce" il tag poem.

postOCR esegue parecchie correzioni:

corregge la maggior parte delle errate spaziature attorno alla punteggiatura;
unisce le parole spezzate a fine riga e unisce le righe che terminano con un acapo semplice, "saltando" gli acapo multipli che identificano i fine paragrafo o che sono introdotti per spaziare le righe, e "saltando" anche le zone marcate con il tag poem;
trasforma gli apostrofi dattilografici in apostrofi tipografici, salvando però gli apostrofi che costituiscono codice wiki per i caratteri corsivi e per il grassetto.

ATTENZIONE: Prima di cliccare postOCR su una pagina proveniente da un OCR, occorre identificare i fine paragrafo con una riga vuota (ossia con un doppio acapo) e le zone di testo in versi (applicando il tag poem), altrimenti il risultato è errato e fastidioso da correggere. Una volta che nel testo sono stati identificati i paragrafi e sono stati applicati i tag poem, l'uso di postOCR è sicuro e può essere utilizzato anche su pagine completamente formattate, ad es. per trasformare in tipografico un singolo apostrofo dattilografico aggiunto da tastiera. Chi conosce il tool lo usa ripetutamente, nel corso dell'edit, nella stessa pagina.

La corretta sequenza su una pagina OCR grezza

Da quanto abbiamo detto finora, risulta che l'ordine dei tool (elimina riga 1 - aggiusta paragrafi - postOCR) NON è casuale, anzi: è esattamente la sequenza che si dovrebbe utilizzare su un OCR grezzo di un testo in prosa. Nel caso di un testo in versi, invece, la prima cosa da fare è aggiungere il tag poem attorno alle zone in versi. A meno che.... l'aggiunta del tag versi non sia stata automatizzata con una personalizzazione dei tool; e a questo punto è necessario parlare della variabile datiPagine.

Adesso viene il bello

Fin qui, non c'era alcuna vera automazione: i tre tool sono solo delle serie di trova-sostituisci, abbastanza complicati ma senza "memoria" e senza alcuna possibilità di adattamento all'opera specifica. A questo punto, era necessario affrontare il problema delle intestazioni delle pagine, estremamente barbose da inserire perchè è evidente che lo schema delle pagine pari e dispari è ripetitivo (dopo la pagina 3 viene la pagina 4, vero? E il codice, magari formattato a fatica con maiuscoletti e corsivi, si ripete ogni due pagine, vero? E riscrivere, ogni pagine, le stesse cose, è frustrante o no? E non dà un gran fastidio che i pulsanti NON FUNZIONINO nell'header?)

E' stata ideato a questo punto l’oggetto datiPagine, un "contenitore di dati" specifico per ogni opera, dove sono rappresentati, una volta per tutte, gli schemi delle intestazioni per le pagine pari e dispari e il "delta", ossia la differenza numerica fra numero della pagina djvu e il numero della pagina cartacea. Tutti gli oggetti datiPagine (uno per ciascuna opera su cui sono in corso lavori) sono raccolti in MediaWiki:Variabili.js, purtroppo modificabile solo dagli operatori di sistema (gli "amministratori"); ma possono essere anche ficcati nella pagina vector.js personale, per uso privato dei singoli utenti, e quindi ogni utente può cimentarsi in un copia-incolla di un datiPagine pronto, e suo adattamento all'opera su cui sta lavorando.

Il tool RigaIntestazione cerca, fra gli oggetti datiPagine disponibili, quello relativo alla pagina su cui viene chiamato; se c'è, inserisce lo schema del template RigaIntestazione sostituendo il "marcatore" #pag con il numero di pagina cartaceo giusto (calcolato come numero di pagina djvu corrente - delta). Per ovviare al fastidio di non poter usare, nell'header, i pulsanti e la toolbar per eventuali adattamenti, il tool aggiunge il template all'inizio del testo e non nell'header; un secondo click sullo stesso tool, sposta il template nell'header; un altro click lo sposta di nuovo nell'area testo, e così via, per comodità di edit. Se l'oggetto datiPagine non c'è, il tool aggiunge uno schema vuoto di rigaIntestazione, meglio di niente.

Questo è stato il primo vero passo di automazione personalizzata sull'opera; e per molti mesi, sembrava un risultato più che soddisfacente. Ma l'appetito vien mangiando.

Perchè non collegare il tool rigaIntestazione a postOCR? Infatti; fatto. Se la pagina è ancora priva di rigaIntestazione, postOCR chiama automaticamente il tool.

Ma un'analisi "da pigri" degli aggiustamenti ripetitivi alle pagine ha evidenziato altre possibili automatizzazioni personalizzate.

la forma delle virgolette. La tastiera consente (senza impazzire con combinazioni di tasti) di produrre un solo tipo di virgolette: il carattere ". Ma ogni opera ha la sua convenzione; talora le virgolette sono rappresentate con i "caporali", « »; talora altrimenti: ‘’ oppure “” oppure “„ oppure „“. Sostituire a mano una per una le doppie virgolette, nelle opere ricche di dialoghi, per i più pigri di noi è intollerabile. Quindi, a datiPagine è stato aggiunto un dato, "virgolette", contenente la coppia di caratteri giusti; ed è stato creato il tool virgolette, che sostituisce in un lampo tutte le virgolette "sbagliate" (di qualsiasi tipo) con quelle "giuste". Tenete conto che c'era un problema logico: la prima virgoletta della pagina in genere è aperta, ma in rari casi è chiusa: succede quando una battuta del dialogo inizia in una pagina e termina nella successiva. Il tool virgolette risolve il problema: un secondo click inverte la sequenza di tutte le virgolette presenti.

il tipo dell'opera. Ci sono opere in prosa, e opere in poesia; in queste ultime, la prima cosa da fare (come abbiamo detto) è aggiungere una coppia di tag poem per evitare disastri combinati da aggiusta paragrafi e da postOCR. Perchè non automatizzare la cosa, aggiungendo un dato "tipo" a datiPagine? Fatto: se in datiPagine c'è il dato "tipo":"poesia", postOCR controlla che nella pagina non ci siano già dei tag poem, e se non ci sono, li aggiunge dall'inizio alla fine della pagina prima di fare danni. Dopodichè continua nel suo lavoro, facendo ciò che è giusto fare nelle opere in poesia (niente fusione di righe, niente eliminazione di spazi, ecc).

gli errori OCR o non OCR ricorrenti specifici dell'opera. Certo, gli errori ricorrenti si possono correggere a mano, o con qualche sistema di trova-sostituisci; ma dopo aver corretto per dieci volte di fila air in all’ ci si comincia a stufare. Quindi, a datiPagine è stato aggiunto un ulteriore campo, regex, che contiene con un trucco piuttosto fragile una serie lunga a piacere di coppie cerca/sostituisci specifiche dell'opera. Ancora una volta, è postOCR che "legge" queste sostituzioni personalizzate e le esegue.

Questa è stata la prima fase dell'avventura dell'automazione; ed eravamo solo all'inizio, perchè a questo punto Candalua ha creato il gruppo di tool per l'aggiunta automatica dei versi, dimostrando la potenza della memorizzazione immediata e automatica di dati "trascinati" in avanti, da pagina a pagina, adattandosi perfettamente alle abitudini del "rilettore esperto", che di solito non agisce su una pagina sola, ma su una sequenza consecutiva di pagine. Una meraviglia, ma anche una sfida: è stato il primo passo per la seconda fase dell'automazione, iniziata alla fine del 2011.

I due inconvenienti di datiPagine e la loro risoluzione

Il sistema di automazione basato su datiPagine aveva due inconvenienti:

scrivere il codice datiPagine, e pubblicarlo sul proprio vector.js, non è facilissimo. Immagino che qualche utente si sia scoraggiato e abbia rinunciato.
datiPagine è rigido. Se il delta salta (magari perchè ci sono illustrazioni fuori testo, o perchè manca una pagina), oppure cambia qualche elemento (es. il titolo del capitolo), tocca interrompersi, trovare dove sta datiPagine, modificarlo, fare un "purge" approfondito, e poi ripartire. Intollerabilmente fastidioso. Idem per l'aggiornamento del campo regex: ogni volta che ci si accorge di un nuovo "errore sistematico", tocca fare la stessa trafila: cercare datiPagine, modificarlo, eseguire il purge approfondito.

Come fare a modificare comodamente, dalla stessa pagina di edit dove si sta lavorando, datiPagine, in modo che la modifica venga ricordata e risulti immediatamente attiva anche nelle pagine successive? Con un biscottino, un cookie, associato a un tool che consenta l'agevole modifica dei dati correnti di datiPagine per l'opera specifica.

La gestione del cookie è invisibile e automatica; il tool per modificare datiPagine è modifica dati Pagina. Il delta improvvisamente salta? No problem: lo si modifica con il tool. L'intestazione cambia perchè inizia un nuovo capitolo? Idem. Non solo: nel caso che datiPagine non esista, ossia: non esista nè in MediaWiki:Variabili.js, nè nel proprio vector.js, è possibile, con il tool, crearlo dal nulla, e il cookie lo memorizzerà e lo renderà disponibile in tutte le pagine della stessa opera, quasi come se fosse scritto in modo stabile in MediaWiki:Variabili.js o nel vector.js personale.

Due inconvenienti:

i cookie sono un affare personale fra utente, specifico browser che gira in uno specifico PC e server. Ossia: usando un browser diverso, sullo stesso pc; o peggio, cambiando pc; o ancora, lasciando scadere il cookie (impostato su 7 giorni) i dati sono irragiungibili, o spariscono.
inoltre i dati non sono utilizzabili da altri utenti, non sono wiki: li usa solo chi ha creato il cookie. Cosa ssolutamente inaccettabile.

Per risolvere entrambi i problemi, occorre memorizzare stabilmente l'oggetto datiPagine in MediaWiki:Variabili.js (per condividerlo con tutti) o nel vector.js personale (per condividerlo con chi è astuto e usa il copia-incolla dalle pagine vector.js altrui). Per facilitare la memorizzazione, in testa al form evocato da modifica dati Pagina viene visualizzato il codice pronto e funzionante del datiPagine memorizzato nel cookie, pronto a essere copiaincollato. Il sistema è così comodo che chi lo prova un paio di volte non scrive più il codice sulle pagine; invece, costruisce datiPagine con modifica dati Pagina, lo prova su qualche pagina, e poi lo memorizza con copiaincolla in MediaWiki:Variabili.js o nel proprio vector.js.

Finita? No, siamo a metà strada. Rientra in scena Candalua (già: è una specie di campionato di ping-pong....) :-).

Il tool trova & sostituisci e la sua integrazione in datiPagine

Da poche settimane, si è aggiunto alla serie un nuovo tool: trova & sostituisci, costruito da Candalua. Comodissimo per modifiche rapide, apparentemente semplice da usare (meglio: può essere usato sia in modalità semplice, che in modalità estremamente complessa e potentissima: tutto dipende dalle capacità dell'utente e dalla sua familiarità con l'argomento regex). Trovate le regex ostiche, al limite dell'incomprensibilità totale? Benissimo: siete persone normali.

Il tool merita una specifica pagina di aiuto e comunque i tempi non sono maturi perchè è ancora in evoluzione. Tuttavia vi è una relazione con datiPagine e "i tool che imparano". Chiunque abbia fatto dei trova & sostituisci su una pagina, andando sulla successiva/sulle successive si è trovato a ripetere esattamente lo stesso trova & sostituisci. E allora: perchè non aggiungere, opzionalmente, i trova & sostituisci già collaudati a datiPagine, in modo che siano "imparati" e applicati automaticamente nelle pagine successive?

Infatti, si può fare: basta selezionare l'opzione "ricorda questa sostituzione" e la sostituzione (sia essa "semplice" o regex parametrizzata) viene accodata a un campo di datiPagine, denominato regexl, e quindi memorizzata nel cookie e, volendo, esportata stabilmente in MediaWiki:variabili.js.

Ad oggi (inizio gennaio 2012), sia il tool trova & sostituisci che la sua integrazione in datiPagine sono in fase di test; l'assestamento potrebbe richiedere qualche settimana di tempo. Nel frattempo, è opportuno che tutti gli utenti interessati, di qualsiasi livello di competenza software, li sperimentino e annotino malfunzionamenti/difficoltà.

Il tool per la numerazione versi

(continua)