Discussioni progetto:Trascrizioni/Archivio/1

L'Antologia delle prove

Prima proposta per inaugurare il bar e il Progetto Scan.

E' ipotizzabile che il nuovo arrivato sia intimidito dall'ambiente (io stesso, nonostante una discreta frequentazione di pedia e di Commons, sono stato un po' sorpreso dalla cura dei dettagli e dal numero di regole e convenzioni di it.wikisource, e ho ritenuto utile "emigrare" per un po' in en.source dove il clima è più user friendly). Penso che il principiante ci pensi parecchie volte prima di provare a mettere le mani su un vero lavoro in corso...

Una soluzione: quella di costruire un libro fittizio, l'Indice:Antologia delle prove, un collage di pagine di opere in corso di trascrizione, ognuna con un diverso di difficoltà e linkata al curatore del progetto da cui la pagina è tratta, invitando il nuovo arrivato a provare a trascriverne alcune, mettendosi in contatto con il curatore della trascrizione dell'opera "vera".

L'idea è molto grezza, per realizzarla ho bisogno che alcuni di voi mi segnalino alcune pagine di opere che stanno trascrivendo, specificandone il grado di difficoltà; io direi che Elementi è il sesto grado della difficoltà (testo antico + immagini), il quindo grado è Il cavallarizzo, mi mancano gli altri gradi.

Chi mi segnala i frammenti, si rende disponibile anche a fare da tutor...

Ovviamente, nulla sarà sprecato e dopo il tutoraggio e le correzioni il testo trascritto sarà utilizzato nell'opera vera e propria, e sostituito con altre pagine. Per far questo basterà ricaricare un nuovo djvu sul precedente, e con un po' di astuzia le modifiche alla pagina Indice:Antologia delle prove e relativo sommario dovrebbero risultare minime.

Cosa ne dite? Se vi va, si parte. --Alex brollo (disc.) 09:02, 17 ago 2008 (CEST)

Alternative "creative" alla procedura proofread classica

Il cuore della procedura proofread è quello di creare una pagina Indice, e una serie di pagine Pagina, ognuna di queste ultime collegate alla corrispondente immagine della pagina, da un'opera a stampa visualizzabile sul web; il tutto rielaborato e transcluso in una versione testuale dell'opera.

A sinistra, istanza di browser con wikisource in modifica di Pagina:Il_cavallarizzo.djvu/6; a destra, istanza di browser contenente la stessa pagina sul sito fonte

La procedura classica comporta che si lavori online, modificando il testo delle pagine Pagina: trascrivendo/correggendo la trascrizione delle pagine rappresentate sulla destra della finestra con un'immagine presente in wiki.

Esistono varie alternative alla procedura classica, alcune prevalentemente offline, altre "miste". La sostanza non cambia: si edita pagina per pagina un file testo, visualizzando contemporaneamente il file sorgente (indifferentemente se presente in wiki, se visualizzato online dal sito fonte, se visualizzato in locale dopo download). Solo la fantasia limita le possibili combinazioni, l'importante è che, alla fine, ogni pagina Pagina: corrisponda a una pagina del file fonte, visualizzabile sul web per le verifiche/correzioni.

Unico problema, il fatto che la modifica di una pagina Pagina: apre una particolare versione dell'editor, in cui la metà destra della schermata viene riservata all'immagine della pagina; questo avviene anche se non c'è alcuna immagine da visualizzare. Fortunatamente, se si attiva il tool wed di monobook.js, il normale editor viene sostituito da un editor diverso, che occupa l'intera larghezza della pagina e che quindi è molto adatto a lavorare senza intoppi grafici in un'istanza del browser, mentre una differente istanza tiene aperto il file fonte, nella pagina corrispondente. In poche parole: perchè ricaricare sul web due volte gli stessi dati-immagine, se la procedura proofread può essere attuata avendo di fronte direttamente il sorgente? Penso che ci siano vantaggi e svantaggi; mi pare che i vantaggi siano predominanti, e siano decisivi ogni qual volta vi sia il dubbio se il caricamento su wiki delle immagini disponibili online sia legittimo o meno. Vedi anche un primo abbozzo di discussione nel bar generale (qui). Caricherò qualche screenshot delle varie possibilità di lavoro online/offline, intanto ripubblico qui lo screenshot già visto al Bar. --Alex brollo (disc.) 15:34, 18 ago 2008 (CEST)

Segnalazione importante lavoro di Edo in corso!

Segnalo Wikisource:Convenzioni di trascrizione, importante "lavoro in corso" di Edo sulle convenzioni per la trascrizione delle opere antiche che abbiano testo a fronte. --Alex brollo (disc.) 14:01, 21 ago 2008 (CEST)

Progetto:Scan/Siti_autorevoli

Questa pagina ha senso solo se inseriamo i siti che contengono materiale scansionato che è possibile (cioè è compatibile dal punto di vista copyright) utilizzare per le trascrizioni. Propongo di togliere quindi l'elenco attualmente transcluso e iniziare a costruire un elenco di siti contenenti scansioni per trascrizione. Sarebbe bene che l'elenco fosse in una sezione apposita della pagina madre e fosse qui transcluso. Che ne dite? Ciao, --Accurimbono (disc) 08:52, 23 ago 2008 (CEST)

Sono d'accordo... e forse sarebbe anche il caso di modificare il nome della pagina: piuttosto che "Siti autorevoli" qualcosa come "Biblioteche virtuali utilizzabili come fonte", o qualcosa del genere. --Alex brollo (disc.) 19:45, 27 ott 2008 (CET)

Procedura proofread alternativa: qualche passo avanti

Un paio di post più sopra, ho accennato alla possibilità di sfruttare l'ambiente delle pagine Indice: e Pagina:, con tutti i loro tools, senza avere a disposizione su wiki le immagini delle pagine da trascrivere. L'esperimento che avevo fatto implicava però l'attivazione di monobook.js e del modulo wed, anzi: di un particolare bug del modulo wed, che penso prima o poi sarà corretto. Una strada sperimentale, ma poco promettente.

Oggi una seconda idea, che vorrei sottoporvi perchè mi sembra quasi perfetta (a meno che non ci siano problemi che non immagino).

Sono entrato in Pagina:Il cavalerizzo.djvu/2 e l'ho spostata in un altro namespace: ho provato a spostarla nella mia sandbox principale, quindi su Utente:Alex brollo/Sandbox/Il cavalerizzo.djvu/2. Il risultato è stato superiore alle aspettative.

• La pagina resta assolutamente identica, formattazione compresa, tranne che quando viene aperta in editing NON scatta il meccanismo di aggancio dell'immagine, e soprattutto la finestra di edir è quella usuale, a tutta larghezza di pagina.
• Nella pagina Indice: il link alla pagina funziona comunque, porta alla nuova collocazione della pagina, grazie a un redirect automatico.

Il fatto di avere una pagina Pagina: editabile con il normale editor facilita la predisposizione di quell'ambiente del desktop (a sinistra, la finestra web con wikisource in editing pagina; a destra, una seconda finestra web che visualizza la pagina attingendola direttamente dalla fonte) e rende la procedura "pseudo-proofread" accessibile a qualunque utente che sappia aprire sul desktop due istanze di un browser indipendenti, e ridimensionare le relative finestre. Non tutti... ma molti di più di quelli che sanno attivare monobook.js.

Vi prego di dirmi se mi sono spiegato... --Alex brollo (disc.) 14:04, 23 ago 2008 (CEST)

Scusa Alex, mi sorge un dubbio: Perché utilizzare per forza la Proofread extension? Mica ce l'ha imposto il dottore, come si dice. :)

Se la scansione con il testo non si può caricare su Commons ma è presente su internet, si può tranquillamente utilizzare il "vecchio metodo" come abbiamo sempre fatto finora, cioè un utente trascrive il testo a mano nel NS principale, si indica nell'infotesto la fonte web dove risiede la scansione, un altro utente rilegge. Finito.

Non capisco quale sia il vantaggio nell'utilizzare la Proofread extension in una maniera per cui non è stata pensata, e probabilmente è solo colpa mia perchè come avrai già capito da altri miei interventi sono "duro di comprendonio", però vorrei arrivarci da solo e capire se fare in maniera più complessa una cosa che può essere fatta in modo più semplice ha anche dei vantaggi, per cui il gioco vale la candela, oppure ci stiamo solo complicando la vita.

Ciao, --Accurimbono (disc) 15:24, 23 ago 2008 (CEST)

Sottoscrivo Accurimbono - εΔω 16:39, 23 ago 2008 (CEST)

Il "vecchio metodo" io semplicemente non lo conosco. Ma - visto che wikisource prevede che esista una fonte fisica stampata, poco importa se reale ed originale, fotocopia, scansione - vedo comunque con favore che la trascrizione sia fatta pagina per pagina. Mi sembra che sia questo il cuore della proofread... non il fatto di disporre dell'immagine all'interno di wiki. Vedo la tecnica proofread utile perfino se il correttore ha in mano una copia fisica del libro. Ma ripeto... ho una visione forse distorta da niubbo avventuroso. --Alex brollo (disc.) 17:45, 23 ago 2008 (CEST)

Esempio recentissimo di vecchio metodo in azione: Su l'Assunzione della Vergine. Ho trovato il testo su GoogleBooks, l'ho copiato (creando contestualmente la pagina dell'autore), ho inserito il testo fornendolo de vari gadget di intestazione, categorie, SAL e infotesto. In pagina di discussione infilo le informazioni sulla fonte che indicano la fonte cartacea scansionata da cui ho preso la poesia. Un rilettore passando può rileggere e correggere la poesia da me inserita aprendo in una finestra la pagina di GoogleBook e in un'altra la modifica della mia trascrizione. Corregge e a quel punto il SAL invece che SAL 100% (livello ce non prevedeva la presenza di una fonte cartacea) è 101%, o edizioni WIkisource che dir si voglia. Anzi, se qualcuno ha voglia di rileggermi il sonetto si può considerare un testo validato in più! Notare che chi inserisce il testo non può validarlo direttamente (quello che oggi vale per il proofread è in realtà una consuetudine antica). Spero che questo esempio basti a far capire come ci si muoveva nell'era pre-proofread: nulla di tutto ciò è caduto in disuso. - εΔω 19:25, 23 ago 2008 (CEST)

Grazie Edo, chiarissimo. La mia soddisfazione esplorativa resta: anche scoprire l'acqua calda dà una certa soddisfazione, se non si conosce il fuoco. ;-).

Quindi, gli unici vantaggii della procedura proofread (esclusa la possibilità di avere l'immagine all'interno della finestra di editing) è quello di costringere a una trascrizione pagina per pagina, e (forse) di giovarsi di headers a footers noinclude automatici, e dei tastini in più per pagina precedente-pagina successiva-pagina indice e headers e footers.

Ora, mettiamo il caso di una fonte solo cartacea, o web scansionata ma in cui ci sia il dubbio o la certezza che non può essere riversata su Commons o su Wikisource per sottili questioni di copyright su cui, a quanto vedo, su Commons si stanno azzuffando perchè le cose sono meno chiare di quanto sembra. Avete in mano il libro, o avete sullo schermo del vostro pc l'immagine delle pagine, da copia locale ad uso personale o online. Voi usereste lo stesso la procedura proofread (ossia: la trascrizione pagina per pagina guidata una pagina indice, e successiva edizione di una versione testuale via transclusione) o pensate che il "vecchio metodo" sia comunque vantaggioso? Lo chiedo alle "vecchie volpi". Seconda domanda: a un niubbo, in queste condizioni, quale dei due metodi suggerireste? --Alex brollo (disc.) 19:47, 23 ago 2008 (CEST)

NOn sto capendo: mi sembra un falso problema. Ti cito tre casi personali:

1. Io sono andato in biblioteca e ho scansionato e caricato su commons dei libri (Messedaglia e Catullo/Rapisardi) pagina per pagina, e ho impostato l'indice come da procedura per proofread (se avessi saputo maneggiare il formato djvu avrei cercato di creare un unico file, ma sono ancora impedito in quel campo): insomma, da copia locale ho carcato su commons.
2. Gallica è un sito esterno a noi, ma che permette il riutilizzo dei suoi testi scansionati. Ne ho presi due (i due volumi di Pellico), li ho tradformati in altrettante immagini (per i motivi di cui sopra) e li ho caricati su commons.
3. GoogleBooks è un sito esterno che non permette il riuso dei suoi testi scansionati, dunque le immagini stanno "là fuori" e noi le trascriviamo "qui dentro". Visto che la trascrizione di immagini di testi PD non è un reato, ciò che non può stare su commons resta dov'è, ma noi lo trascriviamo lo stesso.

Insomma, la logica è la seguente: consideriamo commons come un magazzino di scansioni per noi, assai utile per non costringere il nostro progetto ad accollarsi la gestione delle immagini. Ciò che può stare là ce lo mettiamo. Il sistema proofread permette una gestione completa del processo "dallo scanner al testo trascritto", e la si usa se ci sono tutti i requisiti perché la si possa usare tramite commons (immagini libere da libri PD contenenti testi PD). Le alternative esistono quando non tutti i requisiti siano incontrati:

1. Immagini non libere di libri PD contenenti testi PD (GoogleBooks): trascrizione "indiretta";
2. Immagini di libri non liberi che però contengono testi PD (scansioni personali di testi antichi da edizioni moderne): te le tieni sul disco fisso, le trascrivi, pubblichi la trascrizione e ci si accorda per condividerne la rilettura;
3. Immagini di libri non liberi di testi non liberi (scansioni personali dell'ultimo libro della Saga di Harry Potter): vengono cestinate all'istante.

Insomma, dov'è il problema? In effetti il problema sarebbe convincere i detentori delle immagini non libere di testi PD a cedercele, ma per questo dobbiamo crescere ancora un bel po' per dimostrare la bontà del nostro operato. - εΔω 23:05, 23 ago 2008 (CEST)

Ci andiamo a parlare con quella responsabile a Torino? Dai che la convinciamo! All'Università ero praticamente imbattibile nelle richieste... Comunque, se ci dice male possiamo saccheggiare la biblioteca (un paio di lirbi in prestito a persona... Ci portiamo Aubrey appena torna da Oslo, con Ipork siamo 4... 8 forse 10 testi... non sarebbe male) :))) Xavier121|Talk 23:51, 23 ago 2008 (CEST)

@Edo: per fare i djvu ti consiglio il sito [1], un ottimo punto di partenza, soprattutto con i testi da Gallica o cmq i pdf. Ciao, --Accurimbono (disc) 08:29, 24 ago 2008 (CEST)

Fatto: riletto il testo: Su l'Assunzione della Vergine --Accurimbono (disc) 08:37, 24 ago 2008 (CEST)

Guida per le immagini

Data la meravigliosa notizia di OPAL libri antichi (ma anche senza quella è una cosa che ci serve), credo sia giunto il momento di scrivere una pagina di aiuto che raccolga per l'utente, vecchio o nuovo che sia, un insieme di buone pratiche e/o procedure per la scansione dei testi e la messa a punto del namespace Indice. Le domande che anche io mi pongo sono le seguenti:

• quale risoluzione è meglio utilizzare per le scansioni (tipo 220 dpi, se non ricordo male)
• quale migliore estensione?
• che cos'è un djvu?
• come funziona?
• come faccio a salvare la mi roba in quel formato?

... Mettetene a piacere. Ho un piccolo testo formato immagine che sto cercando di tagliuzzare, ma subito mi scontro con GIMP e con le estensioni in cui devo salvare l'immagine... Che dite, si cerca di fare una pagina del genere? --Aubrey McFato 20:12, 25 ago 2008 (CEST)

Nome

Ma scusate, perché non progetto:Scansioni (o scansione)? --Nemo 22:14, 2 set 2008 (CEST)

Infatti anche per me Progetto:Scansioni sarebbe meglio, meglio ancora Progetto:Trascrizioni visto che l'oggetto vero e proprio di tutto il lavoro sono le trascrizioni, ma ormai siam partiti così... cmq a cambiare si fa sempre in tempo, solo che ci vuole abbastanza lavoro da fare. --Accurimbono (disc) 22:41, 2 set 2008 (CEST)

In qualche modo il nome del progetto è stato cambiato, con qualche difficoltà e qualche conflitto di edizioni... finita la trascrizione del malefico Il cavallarizzo è venuto il momento delle verifiche e delle rifiniture, da farsi con calma dopo qualche discussione: un'ottima occasione per rimettere mano a questo progetto.--Alex brollo (disc.) 20:22, 27 ott 2008 (CET)

Le pagine Discussione nel namespace Pagina:

E' stato sollevato nel bar principale il tema del significato e del contenuto delle pagine Discussione: Infotesti_e_discussioni, e vorrei cogliere l'occasione per discutere con voi alcuni esperimenti svolti nel corso della trascrizione di Il cavallarizzo e del suo corrispondente Indice:Il cavallarizzo. L'opera è stata affrontata con audacia ai confini della temerarietà, come qualcuno dei "vecchi volponi" aveva giustamente osservato... prima di passare alle rifiniture, è bene discutere alcune delle "trovate" che sono state utilizzate, per classificarle in tre categorie:

1. quelle da eliminare perchè non accettabili per qualsiasi motivo;
2. quelle che possono essere conservate come tecniche accettabili, ma non raccomandate;
3. quelle eventuali che potrebbero, dopo una attenta revisione, diventare una procedura raccomandata.

Il tentativo era quello di ottemperare a due esigenze opposte:

1. rispettare il principio "Niente testi originali", ossia non introdurre alcunchè nelle pagine Pagina:, ad esclusione degli opportuni link, ferme restando le piccole modifiche del testo previste in Wikisource:Convenzioni di trascrizione; in particolare, occorreva evitare l'uso di note di trascrizione rese con il tag <ref>;
2. arricchire comunque il testo delle opportune annotazioni di trascrizione, aggiunte comunque tassativamente alla pagina Discussione delle singole pagine, e transcluse nella pagina Discussione della corrispondente sezione della versione testuale.

Il sistema che ho sperimentato, e che adesso, con l'aiuto del mio fido Alebot, vorrei automatizzare, prevede:

• l'uso di Template:? per linkare, nel testo, l'oggetto dell'annotazione alla pagina Discussione contenente l'annotazione;
• all'interno della pagina Discussione, l'uso delle sezioni per identificare le note da transcludere selettivamente nella pagina Discussione della versione testuale.

Per un esempio, vedi Discussioni_pagina:Il_cavallarizzo.djvu/5 e il corrispondente Il cavallarizzo/Proemio. Curioso il fatto che nella versione testuale la pagina discussione viene chiamata "fonte", evidente traccia dell'intento di riservarla esclusivamente all'infotesto. --Alex brollo (disc.) 20:22, 27 ott 2008 (CET)

Pagelist anche da noi!

Cari amici,

c'è un interrogativo a qui non riesco a dare risposta: Prendiamo Indice:Introduzione (Cremona).djvu e modifichiamolo. Notate tutti il simpatico "pagelist" che genera l'elenco delle pagine. Pensavo che da noi non fosse attiva un'estensione di questo genere, e da quando ho scoperto il giochino ho provato —inutilmente— ad applicarlo ad altri indici. cosa non sta funzionando? - εΔω 14:47, 11 nov 2008 (CET)

Per il momento ho scoperto parte del busillis: Funziona solo con gli indici che terminano con .djvu

Non ho ancora capito quali spazi di configurabilità abbia quel comando. ma evidentemente non è applicabile per le raccolte di immagini caricate su commons. È forse un invito non troppo larvato a preferire quel formato ad altri? - εΔω 18:36, 11 nov 2008 (CET)

Come "emigrante reimpatriato", avendo usato pagelist su en.source, ne sentivo molto la mancanza... ma non ho insistito per itrodurlo qui perchè immaginavo che fosse incompatibile con la grafica del SAL locale. Vedo invece dall'esempio che non è vero! Ottimo. Per quanto riguarda la configurazione, è interessante che si può numerare un certo numero di pagine iniziali con numerazione latina, e iniziare la numerazione delle pagine con cifre a partire da una certa pagina in poi; nella maggior parte dei casi (esclusi i testi in cui eventuali tavole "fuori testo" non rispettano la numerazione delle pagine) questo permette di allineare il nome della pagina con l'effettivo numero di pagina del testo.... MOLTO comodo. Rovisterò per l'help specifico, io ho applicato la cosa per "brutale imitazione". Vedi en:Index:Equitation.djvu, dove il comando <pagelist 1="1;roman" 23="1" /> fa il suo bel lavoro --Alex brollo (disc.) 09:35, 10 dic 2008 (CET)

Ho usato il tag pagelist "nudo e crudo" su due nuovi inserimenti: Indice:Fiaschi.djvu e Indice:Manzoni.djvu. La pesantissima pagina Indice delle opere "grosse" diventa leggerissima, a me piace molto. Rinuncio volentieri alla chicca dei colori di sfondo delle cellette... --Alex brollo (disc.) 18:17, 20 dic 2008 (CET)

Parliamo di Tesseract

Conoscete Tesseract[2]? E' un software OCR rilasciato Open Source da Google; vengono distribuiti anche i binari per Windows (prima o poi chiederò a qualche santo di aiutarmi a passare a Ubuntu... ma questo è un altro discorso; comunque, se c'è un volontario molto paziente, il sasso l'ho lanciato). Non è un programma facilissimo per chi è abituato alle interfacce grafiche... è un'applicazione a riga di comando, il che dà un elevato grado di libertà a prezzo di un certo esoterismo. Chi ce l'ha, può condividere qui qualche dritta? Magari incoraggiando altri a installarlo e a esplorarlo? Io annoterò qui quello che trovo e che sperimento. --Alex brollo (disc.) 09:18, 10 dic 2008 (CET)

Caro Alex hai tutta la mia attenzione... non mi spaventa un certo esoterismo, prima o poi qualcosa bisogna imparare (e io ho sempre una gran voglia...). Spero solo che il programma possa leggere anche la pagine più difficili in termini di immagine e tutti i formati possibili. Mi accontento anche di una versione off-line perfettmanete calibrata. Sto valutando l'ipotesi di fare qualche acquisto mirato (OCR in commercio) questo natale, vedremo... :)--Xavier121|Talk 10:42, 10 dic 2008 (CET)

Prima di affrontare Tesseract, bisogna considerare:

1. interpreta solo TIFF non compresse (XnView è un ottimo convertitore che può agire anche su gruppi di immagini);
2. non interpreta testi a struttura complessa (come i testi suddivisi in colonne)
3. ha vocabolari di varie lingue compreso l'italiano, ma la lingua va specificata nella riga di comando;
4. mi pare che generi un testo txt codificato utf-8 e quindi bisogna saper fare le opportune conversioni.

Questo a un primo sguardo... nel sito Google di tesseract c'è una lunga serie di commenti e di link a aiuti, forum ecc. da esplorare. Molto spesso si tratta di utenti Linux alle prese con la compilazione dei sorgenti, ma c'è anche qualche utente della versione EXE per Windows. --Alex brollo (disc.) 15:41, 10 dic 2008 (CET)

pyTesser

Lo immaginavo, se non l'avessero già fatto... esiste un modulo python, distribuito anche da Google, pyTesser, che interfaccia tesseract. Il bot di ThomasV deve averci qualcosa a che fare. Richiamare Tesseract da python semplifica, per certi versi, le cose. Altro da studiare! --Alex brollo (disc.) 14:37, 11 dic 2008 (CET)

PIL

Non c'entra nulla con il più noto, e fonte di ogni nequizia, Prodotto Interno Lordo.... il PIL di cui si tratta è la Python Imaging Library, su cui si appoggia Pytesser. Ogni informazione qui: http://www.pythonware.com/products/pil/. In pratica: una serie di routine Python, sempre utilizzabili in riga di comando python oppure all'interno di scripts, sempre in modo interpretato (ossia: senza compilazione), per elaborare immagini. Elaborare come? Elaborare parecchio: conversioni fra formati, ritaglio, alterazione dei colori.... :-) .... Un'immagine soltanto o mille...

Un esempio con il modulo ImageDraw: "The ImageDraw module provide simple 2D graphics for Image objects. You can use this module to create new images, annotate or retouch existing images, and to generate graphics on the fly for web use." Si apre un intero mondo di cosuccie interessanti... ora tra il dire e il fare, soprattutto con Il Cavallarizzo da portare al 101%, c'è di mezzo il mare... ma mica poi tanto, se il mio naso non mi tradisce. Pytesser e PIL insieme spiegano come si usa Tesseract: Tesseract è il motore che riceve un singolo file TIFF e lo trasforma in testo; ma chi lo "nutre" è PyTesser che fa da ponte fra PIL e Tesseract, e allora si possono ipotizzare comandi come "interpreta tutte le immagini che stanno nella cartella xxx qualsiasi sia il loro formato"... chissà se sono implementati anche i djvu...

Aubrey ci sei? ;-) --Alex brollo (disc.) 07:27, 12 dic 2008 (CET)

PIL installato, in quattro secondi... le routine funzionano perfettamente. Prendo ufficialmente possesso delle immagini... per farle girare basta un python ultraelementare.  :-) --Alex brollo (disc.) 21:18, 12 dic 2008 (CET)

Altra chicchetta: PDFDJ

Convertitore da PDF a Djvu: http://www.math.duke.edu/~jonhanke/PDF2DJ/

Dalla riga di comando questo l'esoterico script per trasformare un PDF in un Djvu:

pdf2dj file1.pdf 

Complicato vero...? :-) :-) --Alex brollo (disc.) 07:36, 12 dic 2008 (CET)

Python + Djvu

Ed ecco qualcuno che sta lavorando adesso all'accoppiata python + djvu: http://jwilk.nfshost.com/software/--Alex brollo (disc.) 07:43, 12 dic 2008 (CET)

Partito Indice:Fiaschi.djvu

L'officina dei morsai

Con la solita boldness che ormai conoscete mi sono buttato in un'altra avventura: Indice:Fiaschi.djvu. Complementare e coetaneo a Il cavallarizzo, si tratta di un altro dei più famosi trattati di equitazione rinascimentale, ma con la particolarità di essere un vero e proprio "atlante", ricchissimo di dettagliate immagini, e mi ha fatto lavorare un bel po' su Commons.

Se c'è qualche problema fermatemi... io intanto procedo. ;-) --Alex brollo (disc.) 07:49, 19 dic 2008 (CET)

Ho incontrato il primo problema: il testo è suddiviso in micro-capitoli (talora di poche righe). Mi consigliate di procedere comunque con lo schema un-capitolo-per-pagina nella versione testuale? Grazie!--Alex brollo (disc.) 22:58, 19 dic 2008 (CET)

Questo può bastare come risposta? - 85.32.110.188 12:08, 20 dic 2008 (CET)

Si. :-) --Alex brollo (disc.) 18:15, 20 dic 2008 (CET)

Esperimenti in corso: post-elaborazione dell'output OCR

A partire dalla pagina 220 circa di Indice:Manzoni.djvu sono in corso esperimenti di post-elaborazione via Alebot del testo fornito dall'OCR (che tenendo conto della cattiva qualità dell'immagine non è affatto malaccio). Annoto i passaggi nelle pagine di discussione di ogni pagina.

Innanzitutto, ho visto che basta creare una pagina con il puro template {{OCR}}; header e footer sono creati al primo edit umano. --Alex brollo (disc.) 19:21, 21 dic 2008 (CET)

Sono molto soddisfatto, il numero di "errori tipici" dell'OCR che sono corretti dalla post-elaborazione è inaspettatamente alto. Lancio una chiamata generale dell'OCR sulle pagine 3-100 di Manzoni e appena l'OCR ha fatto il suo, ripasso e rifinisco la routine. --Alex brollo (disc.) 00:02, 22 dic 2008 (CET)

Questo si che è interessante, mi sembra un'ottima idea. Alex, annotati da qualche parte tutte queste cose, io inizio a scordarmi tutte le idee che hai proposto: mi piace molto comunque questa riscoperta potenza dei bottoli per supplire alle mancanze di MediaWiki (dalla semantizzazione all'elaborazione di testi con statistiche e OCR). --Aubrey McFato 11:29, 22 dic 2008 (CET)

Diciamo che si tratta di una versione pre-beta...una sola serata di tentativi... sono convinto che studiandoci un po' sopra si può fare di meglio. La cosa curiosa è che la routine dovrebbe essere inattiva su una pagina "buona" (a meno di piccolissimi malintesi o eventi rari). E' una delle cose che devo verificare! Quanto a tenere ordine in quello che faccio... non chiedermi l'impossibile. ;-) --Alex brollo (disc.) 12:27, 22 dic 2008 (CET)

MuahahahaH! Bisognerebbe progettare un bot che analizzi il log dei tuoi millemila contributi e dia un output che li cataloghi per argomento. Siamo alla botfrutta :D - εΔω 15:17, 22 dic 2008 (CET)

Forse Edo potresti flaggarmi come bot, e non se ne parla più. Almeno, in certe giornate, la lista dei contributi non sarebbe floodata... x Aubrey: non farmi pesare la differenza di età; non sottolineare che tu appena adesso cominci a dimenticartene... io è da mo' che ho cominciato.

A parte gli scherzi, il mio stile di lavoro con il bot temo sia molto inusuale; spesso non lavoro nemmeno con degli script, ma solo con comandi interattivi, e purtroppo anche gli script non sono veri programmi, ma routine che richiamo dall'ambiente interattivo. Le mie speranze di fare qualcosa di più di esplorare e di dimostrare "cose fattibili" (ossia: di produrre routine solide e ben documentate, che possano essere usate come gli script correnti, ossia lanciate e tanti saluti) si affievoliscono... a meno che non trovi qualcuno che lavora nello stesso modo temerario. Questa cosa della post-elaborazione però è veramente promettente, anche perchè non modifica nessuna procedura e nessuno schema dati e si inserisce perfettamente in un'attività corrente. --Alex brollo (disc.) 16:01, 22 dic 2008 (CET)

Ho molta ammirazione, anche se non ci capisco nulla. Nella seconda metà di gennaio ho un appuntamento con la dr. Beretta che dirige il progetto Digitami della Biblioteca Sormani di Milano. Spero che abbiano molto materiale in archivio ancora non messo in rete. Se nasce qualche idea di possibili collaborazioni ve lo comunico.--213.140.6.122 16:47, 22 dic 2008 (CET) Mizar sloggato

Cosa fa la routine

Annoto qui cosa fa la routine, senza codice. Il problema non è il codice, ma spiegare a parole i passi. Al momento la routine fa queste cose:

1. elimina gli spazi incongrui prima, o dopo, i segni di punteggiatura;
2. riga per riga:
   1. elimina gli spazi vuoti in testa e in coda;
   2. elimina i caratteri "·"
   3. elimina lettere singole seguite da spazi in testa alla riga, o lettere singole precedute da spazi in fondo alla riga (fantasia frequente del software OCR), a meno di poche eccezioni; da rifinire per evitare eliminazioni incongrue;
   4. riunisce le parole spezzate da un trattino a fine riga;
   5. conserva invece i caratteri di acapo a fine riga nelle altre situazioni per agevolare l'edit manuale.

Aggiunte:

1. 1. Elimina la prima riga della pagina, contenente titolo del libro e numero pagina
   2. riconosce il punto a fine riga e lo trasforma in un fine paragrafo (doppio a capo)

Sono in caccia di altre cose che si possono fare... se avete idee, proponetemele. --Alex brollo (disc.) 00:43, 23 dic 2008 (CET) Dubbi:

1. normalizzare gli apostrofi resi casualmente con "'" e con "’"?
2. trasformare di default tutti gli 0 (zero) in o?
3. trasformare tutti i " 48" in " 18" (ricorrente errore: 4807 per 1807)?

Ipotesi:

1. spezzare la routine in segmenti autonomi da richiamare in sequenza o da soli
2. riconoscimento e eliminazione di "assurdità": brevi sequenze di lettere (2-3) senza senso, caratteri esotici, segni di interpunzione consecutivi --Alex brollo (disc.) 09:31, 23 dic 2008 (CET)

La versione corrente della routine è pubblicata in Utente:Alebot/Scripts per i pythomani. Che sia il caso di parlarne con ThomasV? --Alex brollo (disc.) 09:30, 24 dic 2008 (CET)

Un testo, post-elaborato con una specifica routine dall'OCR pubblicato su Internet Archive (di ottima qualità, ma comunque da ritoccare) è: Indice:Olanda.djvu. --Alex brollo (disc.) 11:42, 8 gen 2009 (CET)

Semantizzare ancora

Dopo mesi e mesi di lavoro su un singolo testo ho introdotto un paio di testi da zero, e mi sono accorto che c'è qualcosa che si deve trascrivere identica più e più volte, cosa che non solo è noiosa, ma viola il "principio della coerenza": il titolo dei capitoli. Quindi, sto pensando di "semantizzarli" mediante transclusione selettiva. Indice:Manzoni.djvu farà da cavia. --Alex brollo (disc.) 09:54, 24 dic 2008 (CET)

Spiega meglio a noi poveri analfabeti... fai riferimento alla intestazione dei capitoli come a suo tempo facesti con il Cavallarizzo? - εΔω 10:17, 24 dic 2008 (CET)

Se identifichiamo il titolo del capitolo I di Indice:Manzoni.djvu all'interno di una pagina "buona" (ad esempio, nel sommario della pagina indice) con una section, che contiene il nome, e che si chiama section=Capitolo 1, allora dovunque serva, su wikisource, otterremo il nome del capitolo transcludendo quella section. Abbiamo in pratica creato una "variabile" con un "contenuto". Il vantaggio è il solito: niente ridondanza, ossia: niente possibilità di errori da trascrizioni multiple, e soprattutto: in caso di errore, correzione automatica di tutte le ripetizioni.

Esempio. Ho aggiunto un tag section=Capitolo 2 nella pagina 300 (l'indice) di Manzoni, attorno al nome del capitolo; ne segue che il codice '''{{#lst:Pagina:Manzoni.djvu/300|Capitolo 2}}''' fornisce: '. Se si corregge un eventuaale errore nella sezione, la correzione comparirà in tutti i richiami sparsi qua e là. --Alex brollo (disc.) 13:43, 24 dic 2008 (CET)

Rapporto pagine - versioni testuali: gestione duplicati

Cari Trascrittori,

ho una questione non essenziale, ma dai risvolti filosofici interessanti: il titolo la descrive.

La categorizzazione dei testi per autore include al momento sia le pagine indice che le versioni testuali: ad esempio Categoria:Testi di Angelo Messedaglia. Questa è a mio parere un'anomalia da sistemare, dato che gli indici e le versioni testuali sono due visualizzazioni di una medesima opera. Io toglierei la categorizzazione per autore dalle pagine indice. ma a questo punto... se una trascrizione non ha ancora una versione testuale, e non è un caso così strano: vedasi ad esempio Indice:La statistica e i suoi metodi, se togliamo la categorizzazione dei testi per autore alle pagine indice sarà come se tale opera ancora non esistesse: lo vogliamo? Per me non ci sarebbero particolari problemi perché tale opera compare nella Categoria:Sommari donde andrà pubblicizzata maggiormente di quanto accade ora.

Capite le implicazioni di tale questione: se gli indici e la procedura proofread siano "propedeutica alla versione testuale" che costituirebbe il vero e proprio testo oppure se tali pagine e indici debbano avere il medesimo status delle versioni testuali.

Dato che aprendo in modifica una versione testuale ciò che essa contiene è una somma di template e di trasclusioni senza un reale contenuto autonomo ci sarebbe da abbraccaire la seconda ipotesi, ma a ben guardare c'è un aspetto cruciale delle versioni testuali che richiede attenzione:

• Categorie (che andrebbero poste lì e non nelle pagine o negli indici)
• Interlink
• Altre Versioni

Questi aspetti non competono le pagine proofread e collegano effettivamente i testi all'interno della Wikiteca e tra Wikiteche diverse. Dunque le versioni testuali sarebbero i "veri e propri testi" a cui far convergere ricerche e collegamenti mentre le pagine proofread sarebbero una specie di "officina aperta" in cui far convergere i lavori.

Un punto debole della questione rimane il SAL, sistema che, nato e cresciuto con le versioni testuali oggi non collega pagine proofread e versioni testuali. L'unica soluzione che vedo sarebbe la possibilità di rendere dinamicamente collegata l'icona del sal delle pagine a quella "fantoccio" che compare a lato dei collegamenti alle pagine nelle versioni testuali, ma occorre lavorarci a fondo e occorre un informatico competente qual io non sono... ma da sempre io sono specializzato nell'"armiamoci e partite" :D Se si riuscisse in tal collegamento si potrebbe dire che il SAL di una versione testuale sarebbe il SAL delle sue singole pagine, e non sarebbe più necessario identificarlo se non nella pagina indice della versione testuale.

Ottime argomentazioni. Tuttavia ricordo - da "convenzioni di trascrizione" - che proprio l'esistenza del testo a fronte giustifica determinate scelte leggermente elastiche di trascrizione... io mi orienterei a considerare le due opere come differenti versioni della stessa opera. Eventualmente, raggiunto il SAL 101%, si potrebbe "recidere il cordone ombelicale" fra madre e figlia con una subst: di massa. Da quel momento, sarebbero veramente opere distinte. --Alex brollo (disc.) 13:47, 24 dic 2008 (CET)

NO! Recidere il cordone ombelicale equivale a privarsi di una risorsa insostituibile: io non mi sentirei mai di ritenere un testo perfettissimamente terminato. Se seguissimo le regole basterebbero due utenti a convalidare un testo, ma per esperienza questo non è il massimo. Lo dimostra l'esperienza di Pedia per cui la revisione sul contenuto si avvantaggia nell'apporto di sempre più persone: allo stesso modo anche se un testo "validato", cioè SAL 100% è stato rivisto da almeno due utenti, questo è il significato letterale di tale sigla: almeno due utenti' non perfezione garantita. Ecco perché non solo nei testi SAL 100% bloccherei la versione testuale ma non quella proofread, ma manterrei per i motivi sopraesposti sia il legame con le versioni proofread sia la possibilità di modificare anche pagine proofread già validate. - εΔω

Presentazione delle versioni testuali

Una seconda questione, parzialmente legata alla prima è: se una trascrizione è ancora allo stato iniziale, se presenta cioè il puro e semplice risultato dell'OCR che per quanto raffinato ed emendato da Alebot non è utilizzabile umanamente dal mondo esterno, va riversato in una versione testuale? Io vedo due strade:

• O usiamo la versione testuale come pubblicità per la procedura proofread, e allora non ci importa di come si presenti il testo e però mettiamo i collegamenti alle pagine attivi di default e un bell'avviso in alto che inciti all'intervento
• oppure aspettiamo che almeno una parte rilevante (un capitolo, un canto, una poesia di una raccolta) sia stata trascritta prima di pubblicare la versione testuale, e creiamo in pagina principale e nei luoghi comunitari più gettonati (ultime modifiche, bar, Bibliotecario, progetti tematici) poniamo un template pubblicitario che inviti alla pagina Wikisource:Aiuta Wikisource attualmente sottovalutatissima.

Parliamone: io per il mio perfezionismo propenderei per la seconda ipotesi, ma riconosco che lo spirito open e collaborativo del progetto giustifica la presenza di testi come cantieri aperti; ambo le ipotesi spingono a una decisione che prevede un grosso lavoro successivo. Lasciamo tutto com'è? Sto guardandomi l'ombelico? Intanto auguro a tutti buon Natale: tra breve mi assenterò per qualche giorno, dunque non potrò rispondere battuta su battuta, ma almeno mi sono tolto il sassolino dalla scarpa di suscitare la discussione. - εΔω 11:13, 24 dic 2008 (CET)

Pensavo la stessa cosa stamattina. Includerò i link alle pagine in un tag commento; poi il tag di apertura può essere fatto scorrere per evidenziare, man mano, la parte "buona". Comunque, lavorare in parallelo sulla versione a fronte e su quella testuale non è una cattiva idea; a me il povero Manzoni sta servendo come "animale da esperimento". --Alex brollo (disc.) 13:50, 24 dic 2008 (CET)

Provo a riflettere a tastiera sbrigliata... Da una parte non vedo motivo di affrettarsi a pubblicare l'improponibile in versione testuale, mentre avere almeno una sezioncina a SAL 50% (cioè sgrossata e/o già formattata) permetterebbe quantomeno di iniziare tale pubblicazione, certamente mi rimane la percezione che dobbiamo spingere affinché i navigatori possano arrivare rapidamente alle pagine proofread, dove anche il più scalcinato dei passanti casuali può correggere uno spazio mancante o una lettera sbagliata, e il tutto senza passare dalla versione testuale, che se aperta in modifica è totalmente esoterica. Metti caso che un Wikipediano di passaggio passi da Alessandro Manzoni - studio biografico/Proemio e veda tutti gli strafalcioni da OCR: il primo impulso sarà cliccare su modificaper scoprire un mondo a lui estraneo - provare per credere: quanto di quello che compare in tale pagina è preesistente in Wikipedia? Forse gli interlink e le categorie, ma il resto è tutto automatismo a base di template proprietari di source - dunque, con l'aiuto di Aubrey e di chi maneggia template, css e javascript, proporrei

• che le indicazioni di pagina siano visibili per default
• che le versioni testuali di testi proofread contengano nelle pagine indice un messaggio che rimandi espressamente all'indice della versione proofread
• Che arrivato a SAL 100% sia protetta la versione testuale ma non le pagine proofread, dato che non si sa mai ce qualche errore scappi ancora e dato che il livello di vandalismo sulle pagine proofread non lo richiede ancora.

Infine ora mi metto di voglia e prima di partire per il giro dei parenti modifico le indicazioni del SAL delle pagine con un invito a correggere eventuali errori.

A proposito, le pagine di aiuto per il proofread esistono? Credetemi: non lo so. - εΔω 15:08, 24 dic 2008 (CET)

P.S. Alex, non prendertela a male, ma uno dei motivi per cui desidero inserire questo saggio è perché invece dell'OCR a questo testo si può applicare la trascrizione già compiuta presso il Progetto Gutenberg e si tratterebbe dunque di un altro caso di "Testo Frankenstein" stile Frascherie. Io gli esperimenti li condurrei su un testo realmente bisognoso di trascrizione (sempre per citare un esempio non del tutto a caso... www.archive.org questo che sto trascrivendo un pizzico alla volta.

Come ho detto, il povero Manzoni mi è servito semplicemente come cavia; non sono capace di ragionare in termini del tutto teorici, ho bisogno di materiale su cui sperimentare.... e parecchio, e soprattutto vero, una sandbox non mi basta mai. Non appena qualcuno si prenderà cura del povero Manzoni ne sarò felicissimo e lo abbandonerò senza rimpianti: quello che potevo imparare, l'ho imparato. Non sono affezionato al testo... sono molto affezionato agli stimoli che l'elaborazione di quel testo mi ha dato. Quindi, non posso prendermela a male! :-)

Sono assolutamente d'accordo con il fatto di far comparire i link pagina di default; io vedrei vene anche un commento HTML in testa alle pagine, che appaia in bella evidenza se uno entra in modifica nella pagina e che spieghi come fare per modificare il testo. Ma lo deve scrivere uno che sa scrivere bene e semplice... io sono escluso. :-( --Alex brollo (disc.) 23:25, 26 dic 2008 (CET)

Template Opera

Come esistono i template Autore, creati via bot (es. Template:Alessandro Manzoni), comincio a pensare e a sperimentare dei template Opera (esiste la pagina Template:Manzoni.djvu/Schema), dove si potrebbero accumulare, via bot, "elementi semantici" tratti dai templates intestazione ecc. Ma oltre a questo, in sottopagine del template potrebbero essere scritti templates di servizio specifici dell'opera, che potrebbero ridurre moltissimo gli input per la costruzione di strutture pagina standard. Ad esempio, u ipotetico template per richiamare il nome di un capitolo potrebbe ridursi a {{Manzoni.djvu/Capitolo|2}} che è molto ma molto più semplice del codice che ho riportato qualche post più sopra, {{#lst:Pagina:Manzoni.djvu/300|Capitolo 2}}. --Alex brollo (disc.) 15:19, 24 dic 2008 (CET)

Ancora sugli esperimenti in corso: tentativo di mettere ordine

Accolgo il suggerimento di Aubrey, e cerco di fare un po' d'ordine negli esperimenti che sto facendo su Indice:Manzoni.djvu e sul correlato Alessandro_Manzoni_-_studio_biografico, che è la sua versione testuale. Gli esperimenti sono parecchi; riguardano sia la post-elaborazione dell'OCR, che la "riduzione al minimo" della struttura delle sottopagine Capitolo, con qualche approfondimento sui templates e soprattutto sull'integrazione fra templates e transclusione selettiva.

Essendo impossibile continuare a seminare pezzetti di spiegazioni qui e là, raccolgo le note su quello che sto facendo in una pagina, anche per ricordarmene io... questa: Note su Alessandro Manzoni. Chi si diverte con questo tipo di argomenti gli dia un'occhiata...è, e resterà a lungo, una pagina "incompleta", consideratela uno spazio per annotazioni personali ad accesso pubblico. Usate pure la sua pagina discussioni per qualsiasi osservazione o commento. --Alex brollo (disc.) 19:35, 25 dic 2008 (CET)

Problemucci su Indice:Fiaschi.djvu

Ho un po' di problemi con l'opera Indice:Fiaschi.djvu; il posto giusto forse sarebbe "L'angolo del medioevalista" ma penso che non sia molto frequentato, magari poi spostiamo là la discussione.

1. pagine con sole immagini. C'è una lunga serie di immagini a piena pagina. Complemento straordinario a Il cavallarizzo, dove l'autore si rammarica di non aver aggiunto proprio quelle immagini... ma: come rendere questa lunga serie di pagine sulla versione testuale? Come galleria di thumbs in un unico, fittizio capitolo? A fine testo? Come "capitoli" autonomi di grandezza decente, uno per immagine?
2. grossi errori di composizione. Temo che l'edizione sia grossolanamente fallata ab origine: alcui capitoli (dal XXX al XXXV) del Secondo trattato mancano del tutto... eppure la numerazione delle "cartelle" è corretta! Alcune pagine prima, il problema inverso: c'è un "salto di numeri" nelle cartelle, ma il testo è corretto! Cos'ha combinato l'antico editore?
3. il testo è zeppo di tituli, ma ormai conosco i polli. Verranno tutti espansi senza tante storie.

--Alex brollo (disc.) 10:02, 29 dic 2008 (CET)

Quiz di fine anno :-)

Nelle trascrizioni, molto è transclusione.

Quiz (risolvetelo logicamente prima di provare su una sandbox). Guardate con attenzione questo codice:

123<includeonly><noinclude></includeonly> 456 <includeonly></noinclude></includeonly>789

1. Cosa succede a transcludere questo codice in una pagina?
2. E cosa succede se poi transcludiamo la pagina dove abbiamo transcluso la pagina precedente? ;-)

Vi spiego cosa c'entra con il progetto transclusioni: c'entra perchè chi ha provato a transcludere tutte insieme delle pagine testuali derivate da un'opera proofread (ossia: con contenuto derivante da transclusione), è stato senz'altro disturbato dalle intestazioni (avrebbe voluto ottenere un testo bello liscio e continuo); il problema si risolve inserendo il template Intestazione in un tag noinclude. Ma se come ho fatto per prova su Alessandro Manzoni - studio biografico/Capitolo V tutta la pagina di un capitolo viene generata da un template, c'è un fastidioso problema... --Alex brollo (disc.) 00:57, 31 dic 2008 (CET)

Prima della fine dell'anno... il risultato!

In questo preciso momento, Alebot sta creando tutte le pagine Capitolo di Trattato dell'imbrigliare, atteggiare e ferrare cavalli. In totale automatismo. :-) --Alex brollo (disc.) 22:22, 31 dic 2008 (CET)

.... e ce l'ha fatta senza il minimo problema! :-) --Alex brollo (disc.) 13:23, 1 gen 2009 (CET)

Ulteriori meditazioni sulle section come variabili definite dall'utente

Mi rivolgo a chi di voi ha qualche elemento di programmazione in un linguaggio qualsiasi.

Dopo mesi di vaghe intuizioni, mi sono accorto improvvisamente di una cosa assai banale: il meccanismo della transclusione selettiva altro non è che un sistema di definire, e richiamare, variabili definite dall'utente. Come sapete, una variabile è un metodo di indicazione simbolica di un contenuto; per creare una variabile, occorre definirne un nome e assegnargli un contenuto; successivamente quel contenuto potrà essere richiamato dovunque, nel "campo di esistenza della variabile", con il solo nome della variabile. Una ulteriore finezza: la variabile può essere passata a una procedura per riferimento o per valore.

Vediamo dunque come queste particolari "variabili" sono create, assegnate, richiamate per riferimento o per valore e qual'è il loro campo di esistenza.

Creazione e assegnazione di un valore

Per creare una variabile e assegnarle un valore, basta usare il codice di identificazione di una section all'interno di una pagina qualsiasi (chiamiamola "NomePagina"):

<section begin="NomeSection" />Contenuto<section end="NomeSection" />

Non appena la pagina Nomepagina viene salvata, viene creata una variabile chiamata Nomepagina+NomeSection che indica simbolicamente il contenuto Contenuto.

Campo di esistenza

La variabile Nomepagina+NomeSection ha come campo di esistenza il progetto wiki dov'è stata creata; al momento infatti non è possibile transcludere contenuti da un progetto wiki ad un altro.

Richiamo della variabile "per riferimento"

Il contenuto della variabile è richiamato dal codice di transclusione selettiva:

{{#section:NomePagina|NomeSection}}

Variazioni di Contenuto si riflettono sull'output del codice, con una vaga analogia alla "chiamata per riferimento".

Richiamo della variabile "per valore"

Il contenuto della variabile può essere richiamato dal codice di transclusione selettiva con subst:

{{subst:#section:NomePagina|NomeSection}}

In questo caso il codice scompare e viene rimpiazzato materialmente da Contenuto; eventuali successivi aggiornamenti di Contenuto non si rifletteranno nella pagina dove ha operato il codice di tranclusione. Esiste una vaga analogia con la "chiamata per valore".

Cosa farne?

A questo punto, esistono variabili e metodi per elaborarle (i Templates). Le possibili applicazioni della coppia variabile + metodo di elaborazione di variabili hanno come unico limite la fantasia e la creatività dell'utente. --Alex brollo (disc.) 10:32, 7 gen 2009 (CET)

Piccole correzioni alla pagina Progetto:Trascrizioni

Ho sistemato un po' la pagina Progetto:Trascrizioni; ho aggiunto una sezione "Lavori in corso" che comprende la sottosezione "Pagine di aiuto da preparare" ma anche una nuova sottosezione "Progetti in fase sperimentale", a fianco dei quali ho messo (in bianco) uno spazio per elencare gli utenti interessati (avrei messo Edo e me per il primo; Edo, Aubrey, Snark e me per il secondo, ma è meglio che lo faccia ciascuno per sè.)--Alex brollo (disc.) 12:22, 8 gen 2009 (CET)

Piccolo rilievo

Cari trascrittori,

scrivo qui per non ripetere lo stesso messaggio a più utenti: Sebbene il titolo di una pagina non sia obbligatorio che coincida con quello dell'intestazione, non trovo ragioni tecniche per chiamare una pagina Lettere autografe Colombo invece di Lettere autografe edite e inedite di Cristoforo Colombo come si trova scritto sulla copertina del libro da cui il testo deriva.

Siccome questo non è un caso isolato (ho notato indice:Manzoni.djvu e Delle Frascherie) ribadisco un concetto non scritto esplicitamente ma finora rispettato:

• Una delle differenze che saltano all'occhio per i Pediani è proprio la lunghezza e la "indigitabilità" dei titolidi pagina: noi di fatto ci affidiamo a template, indici e categorie per navigare tra le pagine, e facendo lavoro sporco questo lo si nota particolarmente.
• La fedeltà del titolo della pagina indice rispetto a quello che effettivamente appare sul libro (maiuscole, virgole preposizioni e articoli strani ecc.) non è un vezzo, ma permette di avere la massima disambiguazione in caso di omografie (vedasi Batracomiomachia) e nello stesso tempo dà ai motori di ricerca segnali chiari soprattutto in caso di opere a molte sottopagine come sono i testi proofread.

Insomma, sarà meno pratico, meno indolente, meno informatico, ma grazie al copiaincolla, grazie ai bot, grazie alle diavolerie di questo nostro modo di byte e tastiere ritengo che denominare il file djvu e la versione testuale con il loro vero titolo sia un favore al progetto da non negare. Ciò scritto torno da Elisa e rimango ammirato dall'idea di inserire le lettere autografe edite e inedite di Cristoforo Colombo. - εΔω 21:19, 11 gen 2009 (CET)

Ricevuto! ;-)

A dire il vero non so come e dove avevo equivocato. Forse è un vecchio retaggio da Pedia. Negli ultimi giorni ho maneggiato belle quantità di dati e codici, e francamente ogni trucco per aumentare la semplicità dei titoli era estremamente gradito. Un sono punto non mi convince: i nomi dei file djvu. Penso che - essendo ospitati da Commons - sono le regole di Commons che andrebbero rispettate, e questo comporta - mi pare - la politica della massima semplificazione possibile nel nome del file. Anche perchè più si semplifica e meno si sbaglia... ogni tanto basta scrivere una e al posto di un ed e un titolo non si aggancia. :-) --Alex brollo (disc.) 21:06, 12 gen 2009 (CET)

Hack pagine indice e djvu

Ho fatto un piccolo hack, non so se lo conoscevate, ma a me sembra una bella scorciatoia... Il problema delle pagine Indice è spesso la costruzione del sommario, piena di sintassi strana e lungo e complicato.

Con Alex e i suoi cari djvu ci siamo accorti che, se il nome dell'opera è lo stesso dell'opera djvu caricata su commons, basta scrivere

<pagelist />

e il sommario viene magicamente creato.

Ora, il file su Commons dev'essere caricato come djvu, e avere opere su Source con nomi strani utilizzati dai caricaotri dei file è spesso brutto e non conforme con le regole e abitudini che abbiamo, in cui i titoli (come ricordato da Edo) sono importanti per uomini e macchine. Ma ricaricare un'intera opera con un nome nuovo su Commons spesso è più faticoso che altro.

Una soluzione che può aiutarci, salvando capra è cavoli, è creare un semplice redirect, su Commons, che dal nome utilizzato come titolo su Source punti al nome del file djvu caricato. Si scrive pagelist come prima e il gioco è fatto.

Es. Il file su commons si chiama File:Alfieri-Saul.djvu. Creo un redirect File:Saul che punta a lui, e scrivo la mia pagine Indice:Saul. Fine. Sembra funzionare tutto, se riscontrate problemi ditemelo. --Aubrey McFato 01:10, 16 gen 2009 (CET)

Ottima proposta. C'è un remoto rischio che qualcuno modifichi il redirect (cosa molto più facile che modificare il nome di una pagina su Commons) ma se funziona è un'ottima cosa.

La paternità della scoperta che il tag <pagelist /> può essere usato su it.source ed è compatibile con il nostro SAL è di Edo. Una piccola correzione: quello che viene creato automaticamente non è il sommario, ma la tabella delle pagine. L'unica cosa che si perde è la possibilità di colorare diversamente le caselline della tabella delle pagine, ma mi sembra che possiamo rinunciarci; possiamo comunque colorare le righe del Sommario (quello vero, sulla destra). Inoltre è importante che prima del pagelist sia richiamato {{Indice pagine|1}} (vedi Indice:Olanda.djvu altrimenti "la pagina si scompagina".

Onde evitare delusioni, da notare anche che i link pagina NON si aggiornano immediatamente; vengono aggiornati con ritardo per salvare tempo server. Per aggiornarli immediatamente (e controllare ad esempio il SAL di un gruppo di pagine appena riempite) bisogna "rinfrescare la pagina indice", ossia entrare in modifica e salvare la pagina senza modificarla.

Nel caso che il caricatore del file djvu sia lo stesso utente che poi lavorerà su Source, io suggerisco che si passi al "nome unico", ossia che si decida innanzitutto un buon titolo per la versione testuale su source, secondo criteri che andranno una volta per tutte scritti in una pagina Wikisource:Convenzioni per i titoli delle opere; identico titolo, con la sola aggiunta di un .djvu, dovrebbe essere sia quello della pagina Indice che quello del file .djvu su Commons. Chi usa la procedura Auto, dovrebbe usare lo stesso titolo anche nel Template:NomeOpera.

Quindi: nel caso de Delle Frascherie di Antonio Abati fasci tre i nomi delle pagine dovrebbero essere:

1. versione testuale: Delle Frascherie di Antonio Abati fasci tre
2. Pagina indice: Indice:Delle Frascherie di Antonio Abati fasci tre.djvu
3. pagina su Commons: File:Delle Frascherie di Antonio Abati fasci tre.djvu
4. template di servizio: Template:Delle Frascherie di Antonio Abati fasci tre

Se si seguono questi criteri, molti errori si evitano e molti dubbi si chiariscono d'incanto. --Alex brollo (disc.) 11:45, 16 gen 2009 (CET)

OCR ThomasV e OCR da IA postelaborato

Tanto per documentazione, a sinistra il testo di Indice:Lettere autografe Colombo.djvu come restituito da {{OCR}}, che attiva il bot di ThomasV, e a destra il testo come prodotto dallo script che legge il djvu.xml di Internet Archive e gli dà un'aggiustatina (restano comunque parecchi errori da aggiustare a mano).

Notate la riunione delle parole spezzate a fine riga, gli apostrofi "tipografici", le spaziature pressochè giuste.

<noinclude>{{PageQuality|1|}}<div class="pagetext"> </noinclude>20 catsgrosroao t | perchè in Italia matur arono gli elementi del pensiero e della forza, percui fu grande Colombo. Chi appena guardi le condizioni d’Italia nel XV secolo, sent.e che essa avea diritto di cducareil vin- ci tore della antichità , l’ uoxnoche disserrando nuovi spazii e nuovi tempi, dissipasse affatto il sonnambo- lismodel medio evo e ravviasse il pensiero europeo alla poesia ed alla spcrienza della natura esteriore. ll A XV secolo, cosi poco noto , è quello appunto in cui si svolsero e si bilanciarono tutte le forze intellettuali dell’Italia; lotta confusa, vorticosa e pur troppo mor- ta le. Allora Vitaliano, in mezzo alle inutili sventure M ed alle inutili vittorie di tutte le fazioni , iimparo a far conto, più che d’ogni altra cosa, della propria ener- gia personale: germe funesto d’ egoismo, ma scuola altresi di volonta indomabili e di nature eroiche. E mentre altrove gli uomini erano o sorretti o stritolati dalle gerarchie feudali, solo l’Italiano di que’ tempi vedeva uscire dalla plebe ipontefici, dalla ollicina i magistrati; ed mercanti e soldat i di ventura conqui- starsi ‘coll’ oro e colla spada le corone. Tutti i fatti, tutte le idee S’ agitano allora in Italia vive, possenti, istigatrici d` ogni rea, come d’ogni nobile ambizione; il fervore religioso si alleava col poetico entusiasmo per la classica antichità, e nella stessa generazione si srontrava e mescevasi Vespericnza dei politici, dei mercanti, dei viaggiatori colle memorie e, diremo anc he, colle fantasie delI’ erudizione. Di che nasceva quella fclice e robusta gioventù degli ingegni, iquali creavano, credendo pur tuttavia d’ imitare e fabbri- ravanoi artlitissime ipotesi, interpretando con inconscia l ihcr tà il m ondo e ta st oria. Ed è singolarea dirsi come i due uomini,che fecero la più protbnda rivo- taz saaa aa t t`e idee, mut ando Vaspettodellaterra e del cielo, Colzombo e C orpcn ic o, i quali ora, quasi divinità t <noinclude> <references/></div></noinclude>

<noinclude>{{PageQuality|1|Alebot}}<div class="pagetext"> </noinclude>perdio in Italia maturarono gli olcmenli del pensiero e della forza, per cui fu grande Colombo. Chi appena guardi le condizioni d’Italia nel XV secolo, sente che essa avea dii’ ilto di educare il vincitore della antichità, 1’uomo che disserrando nuovi spazi! e nuovi tempi, dissipasse alTafto il sonnamholismo del medio evo e ravviasse il pensiero europeo alla poesia ed alla sperienza della natura esteriore. Il XV secolo, così poco noto, è quello appunto in cui si svolsero e si bilanciarono tutte le forze intellettuali dell’Italia; lotta confusa, vorticosa e pur troppo mortale. Allora r italiano, in mezzo alle inutili sventure ed alle inutili vittorie di tutte le fazioni, imparò a far conto, più che d’ogni altra cosa, della propria energia personale: germe funesto d’egoismo, ma scuola altresì di volontà indomabili e di nature eroiche. E mentre altrove gli uomini erano o sorretti o stritolati dalle gerarchie feudali, solo l’Italiano di quo’ tempi vedeva uscire dalla plebe i pontefici, dalla oflicina i magistrati; e mercanti e soldati di ventura conquistarsi coir oro e colla spada le corone. Tutti i fatti, tutte le idee s’agitano allora in Italia vive, possenti, istigatricì d’ogni rea, come d’ogni nobile ambizione; il fervore religioso si alleava col poetico entusiasmo per la classica antichità, e nella stessa generazione si scontrava e niescevasi l’esperienza dei politici, dei mercanti, dei viaggiatori colle memorie e, diremo anche, colle fantasie dell’erudizione. Di che nasceva quella felice e robusta gioventù degli ingegni, i quali creavano, credendo pur tuttavia d’imitare e fabbricavano arditissime ipotesi, interpretando con inconscia libertà il mondo e la storia. Ed è singolare a dirsi come i due uomini, che fecero la più profonda rivoluzione delle idee, mutando l’aspetto della terra e del cielo, Colombo e Corpenico, i quali ora, quasi divinità<noinclude> <references/></div></noinclude>

--Alex brollo (disc.) 09:03, 19 gen 2009 (CET)

Cambio di nome

Ho cambiato nome al nostro bar per i nuovi arrivati. L'ho chiamato "Saletta del Benvenuto". Spero che sia una buona idea; la filosofia dovrebbe essere invariata, ma dovrebbe essere più palese il rappporto fra messaggio di benvenuto e accoglienza in un ambiente amichevole e non esoterico, dove si dà qualche suggerimento (es: si elencano "lavori in corso" adatti a prendere un po' di mano) e soprattutto si incoraggiano i neofiti a conoscersi e a aiutarsi l'un l'altro in santa pace e senza alcun timore di porre quesiti "banali". --Alex brollo (disc.) 00:13, 21 feb 2009 (CET)

Dubbio:pubblicare solo libri completi?

Da parecchio aspettavo di trovare qualcosa di Senofonte, e l'ho trovato; si tratta però di un testo settecentesco che raccolglie tutte le opere di Senofonte, e a me interessano solo due (indovinate di che soggetto). Vi chiedo: è ammissibile che io affronti, in proofread, solo le due opere che mi interessano, tralasciando del tutto la trascrizione delle altre opere, comprese nello stesso libro? IO allestirei un "estratto djvu" comprendente solamente il frontespizio, e le due opere (separatamente). --Alex brollo (disc.) 19:05, 23 mar 2009 (CET)

Capiti proprio subito dopo che il Vermondo ha estratto una canzione da un libro che le raccoglie. Io ho seri dubbi sulla filosofia sottesa all'operazione. Provo a spigarmi meglio.

Noi raccogliamo testi prima che libri. Questo legittima anche se non ineccepibilmente l'inserimento di testi singoli di raccolte o antologizzazioni. Non mi piace ma non è vietato.

Ciononostante l'aspirazione di questo progetto è la raccolta di opere per quanto possibile complete. Se non lo sono sarebbe bene mettere nelle condizioni di completarle.

L'avvento del proofread ha introdotto però la possibilità di trascrivere interi libri, e questo ha rimescolato le carte in tavola.

Così come non sono entusiasta delle antologizzazioni preventive rispetto a un'opera ma lo accetto fintantoché sia disponibile la fonte con cui completare la trascrizione, allo stesso motivo non sono particolarmente esaltato dalla creazione di uno spin-off in djvu di un libro concepito con scansione differente. Proporrei la seguente strategia:

• O si rimane con il vecchio metodo con cui si tiene la scansione su Google Books e la sua trascrizione da noi invitando alla rilettura su due finestre affiancate
• O si importa l'intero libro in djvu, si prepara l'indice dell'intero libro, si trascrive e si pubblica quanto interessa e si lascia il rimanente ai posteri.
• Tertiumne datur? Sententias vestras libenter accipiam - εΔω 20:26, 23 mar 2009 (CET)

Sull'unghia, io direi che puoi farlo. Le critiche di Edo sono sensate, d'altra parte mi viene in mente che

• il testo è ciò che ci interessa maggiormente (e non il libro)
• la granularità che ci possiamo permettere ci distingue dal mondo reale (ed è una direzione in cui tutte le biblioteche digitali andranno: si passa dalle antologie alle singole opere ai singoli capitoli alle singole pagine), e può essere un'enorme forza
• questo complica non poco la questione metadata/catalogazione, ma noi non siamo la Biblioteca Nazionale e possiamo tranquillamente permettercelo.

Il fatto di inserire testi (e non libri), è anche per comodità: il buon Kai40 da tempo immemorabile si sta trascrivendo le omelie di San Bernardino, e io ho preferito (anche per quieto vivere mio, s'intende) di lasciarlo fare e pensare ad una predica alla volta. Così almeno abbiamo i singoli testi e chi vuole si va a guardare i libri su GB¹. Io penso che, nell'ottica del servizio che offriamo, la proposta di Alex sia la migliore, perchè offre il miglior servizio. Lui è uno dei pochi che sa usare la procedura proofread (che rimane decisamente poco usabile, in termini di niubbi (ma purtroppo così è, non c'è niente da fare)), e piuttosto che un megalibro in ns:Pagina mai completato e una mezza via solo testuale, fargli inserire le pagine che vuole mi pare la scelta migliore. Capisco il voler essere rigorosi, ma il libro in sè, come tecnologia, non va idolatrato (so Edo che non lo stai facendo ;-)), in quanto anche lui è frutto di scelte, spesso di comodo. Spero di essermi spiegato decentemente. Aubrey McFato 21:04, 23 mar 2009 (CET)

Non mi sognerei di proporre qui la pubblicazione di parte di un'opera, e infatti Ippico (o Sull'equitazione) e Ipparchio sono due distinte opere complete di Senofonte; come tali sono elencate distintamente anche da Pedia. Il fatto che siano pubblicate insieme in un libro è per così dire accidentale, ma pone problemi. Avevo già incontrato un caso analogo con Dom Duarte, per il quale esiste una trascrizione di due diverse opere, Bem cavalgar e Leal Consilheiro, in un solo testo, ma in quel caso ho lavorato (si fa per dire) su pt.s e ho scelto di "provarci" senza tante discussioni (e ho diviso il testo in due distinte transclusioni). Intanto faccio alcune operazioni preliminari, poi vedremo. --Alex brollo (disc.) 21:41, 23 mar 2009 (CET)

OK il dato è tratto: in nsPaGINA il libro intero e integro, che resterà a un SAL basso per tempo indeterminato; su ns0 le opere suddivise individualmente, ciascuna con il SAL che eredita dalle sue sole pagine nsPagina. UN piccolo problema: c'è un sistema di link automatico verso la "versione testuale", fatto per una versione unica...... ci penseremo in quel momento; oppure, la versione testuale unica sarà una banale pagina indice, da cui si accede alle varie opere. --Alex brollo (disc.) 07:04, 24 mar 2009 (CET)

Note

1. a proposito, dovremo fare qualcosa che migliorare la visibilità del testo scansionato, quando c'è (o magari decidere di importare tutti i libri da GB qui...)

Piccola grande intuizione: template R dove serve

Carissimi, ho avuto anch'io un raro caso di uso creativo del template:pt: provate a vedere Per li giocatori di pallone in Firenze l'estate dell'anno 1619, e notate cosa ha in più rispetto alla trascrizione proofread (es: Pagina:Chiabrera2.jpg): i numeri di verso! Apriete quest'ultima pagina in modifica, li ho posti nella versione proofread, nascondendoli nella pagina e rendendoli visibili nel namespace principale con il template pt. Così potremo numerare le poesie trascritte da namespace pagina... - εΔω 19:29, 24 mar 2009 (CET)

Avevo notato, Edo, un colpo di genio ;-) --Aubrey McFato 14:36, 27 mar 2009 (CET)

Bene! Di poesie ho scarsa esperienza e non avrei mai immaginato questa applicazione. Vedo un piccolissimo problema: se il tl|R cade sul primo verso dopo una riga bianca, si pone sulla riga bianca e non sul verso. Why? Vado a vedere per fare un po' di ricreazione da Fiaschi... --Alex brollo (disc.) 19:59, 27 mar 2009 (CET)

Ho guardato meglio: il 5 sta sul 6° verso, il 10 sull'11°... ho combattuto e perso, recentemente, con il float:right del tag div, riconosco i tristi segni. Il tl|pt è innocente. Unica soluzione che propongo: mettere il tl|R alla fine del verso precedente, non all'inizio del vero giusto; e tutto s'aggiusta. --Alex brollo (disc.) 20:22, 27 mar 2009 (CET)

Generazione di tabella di thumb

Trovo comodo avere, per mio uso personale, una "tabella dei thumb delle pagine". Per farlo, mi preparo con Excel una tabella di questo tipo:

|[[File:Senofonte.djvu|200px|page=1]]
|[[File:Senofonte.djvu|200px|page=2]]
|[[File:Senofonte.djvu|200px|page=3]]
|[[File:Senofonte.djvu|200px|page=4]]
|[[File:Senofonte.djvu|200px|page=5]]

....
|}

poi ci aggiungo con un text processor qualsiasi (anche word) i fine riga |- (in word sostituisco 0]]^p con 0]]^p|-^p, e idem con 5]]^p), aggiungo il codice di initio e fine tabella, metto il tabellone in sandbox e chiedo un'anteprima. NON salvo: invece eseguo un "salva con nome, pagina web completa" dal browser dell'anteprima e abbandono sandbox. Ho stressato un po' il server ma non ho inquinato i databare, e mi ritrovo sul mio pc la collezione dei thumbs, ognuno con il suo bel nome in cui c'è anche il numero pagina del file djvu, utilissimo per costruire il sommario. --Alex brollo (disc.) 09:52, 27 mar 2009 (CET)

Problema Fiaschi

Vedo la fine della trascrizione del Trattato di Fiaschi, e sono incappato in un problema. La stampa 1603 è grossolanamente fallata. La pagina 135 (numerazione originale) finisce a metà del Capitolo XXX... la pagina 136 inizia con l'inizio del Capitolo XXXV. Ci sono quattro capitoli mancanti (potrebbero essere due o tre pagine). L'indice li menziona... nella stampa non ce n'è traccia. Un bel caso in cui si confrontano "edizione critica", focalizzata sul testo "ideale", e "fedeltà alla fonte", che invece si preoccupa di riprodurre meglio possibile un "libro".

1. come mettere una buona nota che spieghi il "buco"?
2. ho una piccola speranza di procurarmi un paio di fotocopie o fotografie delle pagine mancanti, che però saranno di un'altra edizione. Potrò utilizzarle? --Alex brollo (disc.) 00:05, 29 mar 2009 (CET)

Risolto - quasi - il problema del carattere Athenian

Copiaincollando un testo Word contenente lettere greche in source, è molto probabile che i caratteri greci risultino illeggibili (a seconda del browser e della configurazione del PC, sono resi come rettangolini bianchi o contenenti quattro piccole lettere o come punti interrogativi). E' quello che è avvenuto, ad esempio, ne Zibaldone.

Il problema nasce dal fatto che frequentemente il greco antico, in Windows, è reso con il carattere/la codifica Athenian, mentre il server wiki è predisposto per ragionare in Unicode. Tralascio le parti esoteriche di questa cosa, in cui incoccia chiunque muova un bot; il problema si riduce a convertire le lettere scritte in Athenian, in lettere scritte in Unicode.

Ho il piacere di dirvi che la tabella di decodifica è quasi completata, tranne alcuni particolari, e che quindi Alebot è in grado di eseguire la conversione Athenian->Unicode in maniera decente; sfuggono pochi caratteri e sfuggono le maiuscole accentate (o meglio "spiritose") ma i raffinamenti potranno essere introdotti o a mano, o con una seconda passata. Quindi: se avete opere con molto greco antico dentro, caricatele pure che vediamo cosa si può fare! --Alex brollo (disc.) 08:36, 1 apr 2009 (CEST)

Ottima ottima notizia. Vi sono alcune opere di Francesco Redi che contengono molto greco (alcune inserite alter no): io ricordo che Osservazioni intorno alle vipere aveva l'athenian che non veniva visualizzato. Allora io ho installato il font nel mio pc ed al riavvio miracolosamente c'era anche su Source! Non so se queste due cose abbiano nesso causale: potresti vedere se tu leggi i caratteri greci? Sono visualizzati diversi dal solito e sono tutti attaccati (quindi necessitano formattazione).

Per il resto, a bot ottimizzato, potresti inserire lo script nella pagina di Alebot, che rimane uno spazio per richieste comodissimo. --Aubrey McFato 11:28, 1 apr 2009 (CEST)

Aimè no, sotto IE e senza Athenian installato vedo solo delle belle sequenze di punti interrogativi. Invece, nello stesso ambiente, vedo bene i caratteri Unicode (quelli che compaiono nel set "Greco antico" del box modifica). Mi annoto Redi, chi ha altre opere con problemi analoghi me lo dica che metto Alebot alla prova! Dovunque sia, l'Athenian va eradicato da source.--Alex brollo (disc.) 11:55, 1 apr 2009 (CEST)

Immaginavo-> bhè, allora hai un'altra opera ;-) Può darsi che aggiunga qualche altra opera di Redi, magari ti faccio un cenno, lui ha il greco piuttosto facile. ;-) --Aubrey McFato 12:10, 1 apr 2009 (CEST)

E' stata una battaglia un pochino dura ma ce l'ho fatta discretamente. Purtroppo rilevo che non c'è uniformità nell'uso dell'Athenian nellemo all'interno dello stesso LiberLiber. Segnalatemi pure altre opere con caratteri greci da sottoporre a Alebot.

--Alex brollo (disc.) 08:28, 6 apr 2009 (CEST)

Estensione del tl|Navbar

Per chi mi ha seguito nel "progetto Auto" una piccola novità riguardo al tl|Navbar.

Il tl adesso accetta uno o due parametri numerici.

1. un parametro: Navbar considera il parametro come "numero d'ordine del capitolo corrente" e quindi punta automaticamente al numero d'ordine precedente e a quello successivo.
2. due parametri: Navbar considera i due parametri come numero d'ordine a cui puntare come capitolo precedente e sucecssivo. Questo consente dei "pentimenti", ossia consente di modificare l'ordine in cui i capitoli compaiono (eliminazioni, aggiunte).

Il tl è stato usato con la seconda opzione in Trattato dell'imbrigliare, atteggiare e ferrare cavalli, vedi, ad esempio, Cannone, elemento 100 dell'indice, dove si era presentata la necessità di insierire numerose sezioni (dalla 100 alla 134) fra gli elementi 47 e 48. Il tl|Navbar dell'elemento 100 ha quindi il seguente codice: {{Fiaschi.djvu/Navbar|47|101}}. Anche gli elementi 47,48 e 134 sono stati modificati in modo di "spezzare la sequenza". --Alex brollo (disc.) 08:28, 6 apr 2009 (CEST)

Il Trattato offre anche la possibilità di applicare numerosi link interni (dal testo alle pagine/immagine) e probabilmente di sperimentare una o più immagini mappate. C'è qualcuno di voi che ha già usato immagini mappate? --Alex brollo (disc.) 08:28, 6 apr 2009 (CEST)

Non credo. Forse ce le avevi presentate tu una volta, ma poi data l'esotericità nessuno le ha mai sperimentate. --Aubrey McFato 11:16, 6 apr 2009 (CEST)

No, no io, erano una novità anche per me. Copmunque, visto che l'estensione che le gestisce è già presente qui su source: perchè lasciarla inoperosa? Ho in mente un regalino per l'atelier del medioevalista.... un'immagine di una pagina difficile con "mappate" le varie difficoltà: tildi, punteggiature aliene, ecc; ma l'applicazione equestre sarà la pagina "Infermità" di Fiaschi. --Alex brollo (disc.) 15:38, 6 apr 2009 (CEST)

Uau, sarebbe bellissimo (e finalmente un'applicazione creativa ed utile delle immagini mappate). Tu fai delle prove che in effetti mi vengono delle ideuzze in merito... ;-) --Aubrey McFato 15:52, 6 apr 2009 (CEST)

Nulla, ma nulla di esoterico. http://toolserver.org/~dapete/ImageMapEdit/ImageMapEdit.html?en fa tutto lui. :-) Vedi in Wikisource:Pagina delle prove. --Alex brollo (disc.) 16:47, 6 apr 2009 (CEST)

Ho visitato rapidamente il "Laboratorio grafico" di Pedia; li contatterò, perchè noi (da quando abbiamo la proofread extension) abbiamo molto bisogno di impratichirci con la grafica, ma con programmi diversi dai loro. Come dicevo, dobbiamo destreggiarci in programmi che elaborano pagine di testo, possibilmente programmabili, a cui chiedere qualcosa come "estrai da questo file PDF tutte le immagini delle pagine in file jpg/tiff, dividi ciascuna pagina in due tagliandola verticalmente, croppale (=elimina il margine bianco),", ecc. Per far questo bisogna impratichirsi in: ImageMagick; Ghostscript; XnView; DjvuSolo. Tutti ad alto tasso di esoterismo (soprattutto i primi due, direi). Siccome nessuno può sapere tutto, intravedo l'utilità dell'apertura di un Laboratorio grafico anche qui da noi. --Alex brollo (disc.) 16:58, 6 apr 2009 (CEST)

Noinclude, includeonly,onlyinclude

Usiamo abitualmente i tre tag noinclude, includeonly, onlyinclude (nettamente più i primi due). Ho trovato un'applicazione per onlyinclude recentemente, in una astrusa questione di categorizazzione che stiamo studiando con Aubrey; una seconda mi è stata suggerita da un quesito della nuova utente Utente:Lagrande (mi chiedeva: dov'è la pagina discussione delle pagine del ns0? Bella domanda, visto che è ben nascosta dalla dizione "fonte" sulla linguella del folder...non molto "user-friendly"...  ;-)).

Onlyinclude individua zone di pagina che in caso di transclusione devono essere transcluse in via esclusiva; ossia: tutto il resto della pagina dev'essere ignorato. Equivale a marcare tutto il resto della pagina con noinclude. E' quindi utile nella transclusione del solo infotesto dalla pagina di discussione delle pagine Indice:, Pagina: e ns0, se si vuole ottenere una transclusione esclusiva dell'infotesto senza portarsi dietro anche le eventuali note, ed evitando di confondere gli utenti obbligandoli a scrivere le loro note solo in un'area noinclude della pagina di discussione.

Molto complesso, logicamente, cosa succede annidando uno dentro l'altri i tag.

<onlyinclude><includeonly>testo</includeonly></onlyinlude>	testo non sarà visualizzato nella pagina ma solo nella transclusione, e sarà transcluso in via esclusiva (il resto della pagina sarà ignorato)
<onlyinclude><noinclude>testo</noinclude></onlyinlude>	nella transclusione non comparirà nulla, nè testo (escluso dal noinclude) nè il resto della pagina (esclusa dall'onlyinclude)

Cercasi sperimentatori per verificare e testare altre combinazioni (e ragionare sulle loro possbili applicazioni). :-) --Alex brollo (disc.) 11:09, 7 apr 2009 (CEST)

Approfondimento grafica

Metto qui un paio di note per non dimenticare...

1. XnView è un programma piuttosto complesso per la manipolazione di immagini singole o a gruppi: conversione da un formato all'altro, "croppatura" (ritaglio dei margini), e moltissimi effetti grafici tutti da esplorare.
2. XnView NON gestisce i file PDF nè i file Djvu, e gestisce i Tiff multipagina solo una pagina alla volta.
3. Esiste però, collegato a XnView, il programma a linea di comando Nconvert, un pochino alieno per chi ama lavorare con interfacce grafiche perchè non ne ha. Nconvert può effettivamente estrarre da un file Tiff multifile le immagini singole (Gallica fornisce sia PDF che Tiff multipagina. Per ora ho testato la conversione Tiff multipagina->Jpeg singole ->cropping con XnView ->montaggio in Djvu. In teoria, essendo a riga di comando, Nconvert può essere "pilotato" da uno script python o altro.
4. Sono iscritto come alexb nel forum di appoggio di XnView e Nconvert: http://newsgroup.xnview.com/ ma devo trovare qualche sito che parli di Nconvert e della sua sintassi in modo umano. --Alex brollo (disc.) 23:35, 7 apr 2009 (CEST)

trascrizione-inversa

Ormai è una moda e sono contento di averla lanciata: In questi anni abbiamo trascritto opere da scansioni esterne, e ora che abbiamo un progetto e una prassi abbastanza collaudata (a quando le pagine di aiuto?) stiamo tornando sui nostri passi a caricare su commons quelle scansioni per metterle a fronte delle nostre trascrizioni. L'unico problema è la cronica scarsità di mani in grado di pubblicare tali opere... allora farei questo: a futura memoria, a partire da un paio di ricerche, elenco qui (ma a mio parere servirebbe una pagina apposita), i libri che ad oggi potrebbero essere importati e pubblicati in quanto già trascritti completamente qui:

Testo di source	scansioni
Africa orrenda	fonte
Confessioni d'un scettico	fonte
Specchio di vera penitenza	[in corso]
Memorie per servire alla vita di Dante Alighieri	[in corso]
Meditazioni storiche	fonte
Vita di Dante, Petrarca e Boccaccio	fonte
Memorie storiche civili, ed ecclesiastiche della città, e diocesi di Larino	fonte
... altre... --> VEDERE QUI

- εΔω 11:33, 11 apr 2009 (CEST)

Scopro con frustrazione che non tutti i pdf si lasciano elaborare da nconvert e da ghostscript; ho perso l'intera giornata per capire perchè nconvert si bloccava su Confessioni.

Sono in pieno fermento esplorativo, spero di non perdermi. Forse è il caso di fare il punto della situazione, riguardo le fonti di libri online che possono essere usati come fonte proofread dopo trasformazione in djvu.

1. Internet Archive: offre i djvu pronti, basta caricarli direttamente su Commons. Il djvu di IA non può essere però modificato con DjvuSolo. I PDF di IA non sono elaborabili (perlomeno da me). Dovendo eseguire il cropping delle pagine, possono essere usati i file TIFF singoli, che IA offre.
2. Google: offre solo PDF; possono essere convertiti in djvu con il servizio online Any2djvu. Il file djvu restituito può essere modificato con DjvuSolo.
3. Gallica: offre PDF o TIFF multipagina. Il PDF può essere convertito in djvu da Any2Djvu. Il TIFF multipagina può essere elaborato da nconvert (ottenendo le immagini singole).
4. OPAL: offre PDF a pagina doppia, è il caso più difficile, quello su cui sto lavorando. I PDF possono essere elaborati con gli strumenti di cui dispongo per trasformarli prima in immagini jgp, che poi possono essere divise in due pagine distinte. Un serio problema per l'elaborazione automatica è il disallineamento di alcune pagine.
5. ......

--Alex brollo (disc.) 01:02, 12 apr 2009 (CEST)

Non so se può esserti utile, ma ti passo la pagina wiki dove tempo fa avevo cominciato ad inserire i siti da cui si può scaricare materiale per il progetto Gutenberg. Non so quanto sia valido ancora, e quanto sia aggiornato, ma qualcosa di buono dovrebbe esserci. Puoi vedere se c'è qualcosa con cui fare esperimenti. Lagrande (disc.) 10:43, 12 apr 2009 (CEST)

Spaventosa quantità di materiale... penso che le fonti "grosse" le conoscessimo tutte, lascio rovistare gli appassionati (te compresa: qualsiasi opera ti interessi, segnalamela che la sottoponiamo al "trattamento proofread"; io mi occuperò ancora delle parti relative alle immagini vere e proprie, penso che tu sia in grado di provare tutto il resto).--Alex brollo (disc.) 22:46, 12 apr 2009 (CEST)

Proposta operativa per la trascrizione inversa

Occorre una furbata per fare la minor fatica possibile per riversare le pagine datta versione testuale al nsPagina... con Xavier ho fatto un esperimento su un file txt esterno continuo, ma sarebbe bene ideare un metodo che funzioni (via bot) direttamente da source. Si tratta di inserire nel testo qualcosa che funga da "marcatore di inizio pagina", ma francamente non ho idea se la fatica di inserirlo valga la candela. Vogliamo fare un esperimento? Un buon marcatore potrebbe essere un commento html contenente il numero della pagina (il numero della pagina del file djvu, non del libro): qualcosa tipo <!--1-->,<!--2-->,<!--3-->.... il resto potrebbe farlo Alebot, sempre che (ovviamente) esista una pagina Indice: e i marcatori siano stati messi con cura. Il vantaggio di usare commenti html è che sono totalmente invisibili e neutri e che consentono di rimandare sine die l'inizio dei lavori, in quanto non causerebbero alcun danno al testo com'è visualizzato. A lavoro completato, Alebot potrebbe tagliare il testo dalla pagina testuale, copiarlo nella pagina Pagina: e insierire direttamente nella pagina testuale il codice di transclusione, in modo che la cosa sia del tutto trasparente... si tratta solo di valutare attentamente se ne vale la pena. Il solo inserimento dei marcatori di inizio pagina sarebbe un vero lavoraccio, in un'opera un po' grossa. --Alex brollo (disc.) 22:41, 12 apr 2009 (CEST)

OPAL trasformazione in jpg ->ritaglio via PIL, test

Sto caricando (bizze del server permettendo) File:Gl'ingannati.djvu, semplicemente la prima opera OPAL che ho trovato nella lista delle opere teatrali. Uno script python ha eseguito la conversione pdf->jpg (via creazione di un file bat intermedio), un secondo script python, usando le routine del PIL (Python Imaging Library) ha letto uno alla volta gli jpg prodotto nel primo passo, li ha tagliati in due (con una certa sovrapposizione fra le immagini per rimediare alle pagine sghembe), e ha salvato le immagini correttamente rinumerate in un'altra cartella. Le immagini delle pagine singole sono state montate in un djvu con DjvuSolo 3.1 (risoluzione 100 dpi, qualità foto). Il file djvu è risultato di 17 Mby per 167 pagine (un po' troppo grande, bisogna limare). --Alex brollo (disc.) 23:59, 12 apr 2009 (CEST)

La fusione dei due script python e il richiamo via python del file bat intermedio è facile; da studiare le routine batch per costruire, via comandi di sistema (e quindi via python), il file djvu, per realizzare l'automazione integrale di tutto il processo. --Alex brollo (disc.) 00:05, 13 apr 2009 (CEST)

Un suggerimento per dirigere le scelte... - εΔω 08:39, 13 apr 2009 (CEST)

Suggerimento seguito, le prime 5 opere elencate là dove il suggerimento mi ha portato sono elaborate e caricate. Adesso mi sono piantato su Georgiche, il server Commons non ne vuole sapere. Ma il problema sembra generale. Probabilmente dipende dai massivi caricamenti di immagini in corso. --Alex brollo (disc.) 11:50, 21 apr 2009 (CEST)

Nuovo amministratore

Alex brollo

Vorrei candidare Alex amministratore del progetto trascrizioni, --Xavier121 16:32, 14 apr 2009 (CEST)

Grazie... come detto altrove, sono veramente onorato, ma preferisco rifiutare! :-) --Alex brollo (disc.) 00:11, 16 apr 2009 (CEST)

---

Caricamenti per trascrizione inversa

Dopo alcuni test su opere brevi trascritte da Snark, ho verificato gli script su opere un po' più grosse (i testi di Aristofane) e in questo momento sto caricando le Georgiche, che è ancora più grossetta. Finora tutto bene. Segnalo l'eccellente Commonist, tool indispensabile per difendersi dalle cadute di collegamento (ritenta da sè!). --Alex brollo (disc.) 00:11, 16 apr 2009 (CEST)

Inizio scrittura pagina di aiuto

Ho cominciato, con difficoltà, a scrivere Aiuto:Come pubblicare un testo con la versione cartacea a fronte. Ci ho messo il tag WIP, ma non badateci... chiunque voglia/possa modificare/integrare è grandemente benvenuto. Per ora c'è poco più di una bozza. Soprattutto, vi chiedo (a chi può farlo) di elencarsi come utente disponibile a dare una mano... penso che questo sarà il punto più importante e cliccato della pagina. ;-) --Alex brollo (disc.) 11:34, 21 apr 2009 (CEST)

OCR: approfondimento

Inizio la discussione nella pagina dedicata, su invito di Alex. L'OCR è fondamentale per il nostro lavoro (acqua calda!), ultimamente ho preso una versione potentissima, trascrive da qualsiasi formato (si può lavorare direttamente su opal ecc.), pochissimo margine di errore, e mi restituisce, incredibile a dirsi, il testo FORMATTATO (corsivi, maiuscole, cambio di carattere ecc.). Lavoro sugli indici di Leopardi e solo il tempo (lavoro), m'impedisce di completare l'intro di Ziba e concentrarmi sul teatro. Se anche voi disponeste di una versione simile, credo che il lavoro di trascrizione scivolerebbe via agevolmente. Questo prezioso aiuo tecnico non condiziona l'altro, succoso, aspetto del nostro lavoro, la rilettura, che con un testo già ben formattato diventa piacevole ecc. Sarebbe il caso di fare il punto della situazione sui rispettivi OCR e scambiarci i programmi se occorre :) --Xavier121 10:17, 24 apr 2009 (CEST)

Interessantissimo. Alcune domande:

1. legge direttamente da file PDF? SI
2. quanto è sensibile alla qualità? POCO (nel senso che ricostruisce in termini più che lodevoli, pagine malconce)
3. ovviamente legge testo in colonne e in box? SI (distingue anche le immagini nel testo)
4. ha la possibilità di essere pilotato da riga di comando? Non lo so (interfaccia Windows, comunque)
5. ha la capacità di "apprendimento" di nuovi caratteri? SI
6. é possibile gestire il vocabolario? SI

--Alex brollo (disc.) 10:38, 24 apr 2009 (CEST) --Xavier121 10:46, 24 apr 2009 (CEST)

Allora lo voglio. :-) --Alex brollo (disc.) 11:37, 24 apr 2009 (CEST)

Penso sia venuto il momento di aprire in LaBARatorio informatico :-) --Alex brollo (disc.) 11:57, 24 apr 2009 (CEST)

Lo voglio anche io! Link per favore!!!! Lagrande (disc.) 13:32, 24 apr 2009 (CEST)

Qui sono i software consigliati dai Distributed Proofreaders. Lagrande (disc.) 13:38, 24 apr 2009 (CEST)

Mi piace come idea, sarei curioso di provarlo (sempre se riesco a farlo correre su Ubuntu). Parallelamente, Alex, sarebbe bello continuare con l'idea di un "bottolo" OCRrante e post-OCRrante, a cui l'utente niubbo può chiedere il grosso del lavoro. Così possiamo dsare sia strumenti all'utente esperto che a quello dilettante. D'altronde, il pulsantino OCR serve a questo, a distribuire un po' di lavoro. Che ne pensi/ate? Aubrey McFato 13:44, 24 apr 2009 (CEST)

:-( :-( Non ditemi che ho lavorato alcune centinaia di ore per trascrivere manualmente due libri del XVI secolo quando un buon OCR avrebbe potuto fare gran parte del lavoro.... @ Aubrey: prima di lavorare sulla postelaborazione, occorre che mi chiarisca le idee sulle possibilità dell'elaborazione.... l'OCR "nostro" è (quasi) certamente Tesseract, che però lavora in modo "cieco", non interattivo, e senza apprendimento; nulla a che vedere con le cose che Xavier e Lagrande ci hanno indicato. A mia discolpa, il fatto che avevo interrogato alcune mail list wiki e queste possibilità erano state escluse, e a dimostrazione dell'impossibilità di ottenere un buon risultato con testi "difficili" mi era stato menzionato il progetto ReCaptCha. --Alex brollo (disc.) 14:29, 24 apr 2009 (CEST)

Comunicazione di servizio per OCR

Stimati colleghi, spedite alla mia e-mail delle preferenze un recapito fisico dove consegnare il materiale. Allestirò un CD/DVD con tutto quello che serve. :) --Xavier121 14:24, 24 apr 2009 (CEST)

P.S. con quello che serve mi riferisco all'elenco di testi su cui lavorare e quelli già preparati... niente di oscuro... :) --Xavier121 17:17, 24 apr 2009 (CEST)

Io però un tentativo ulteriore di controllo di Tesseract lo devo fare.... OK, userò i tuoi testi. Elenco lungo, immagino, se occupano un dvd. Bisognerà darci sotto. --Alex brollo (disc.) 19:45, 24 apr 2009 (CEST)

Ho cominciato a approfondire Tesseract. L'opposto di quello che si definisce "user friendly" ma le potenzialità ci sono; ad esempio, una serie di programmi di "apprendimento" consentirebbe non solo di introdurre un dizionario qualsiasi, ma anche un qualsiasi set di caratteri sconosciuti, con le uniche limitazioni che la scritura vada da sinistra a destra e che i caratteri non siano "legati" come nell'arabo. Se non fosse che tempus inesorabile fugit, mi piacerebbe fare un po' "l'addestratore di tesseract"... Attendo lo svilupparsi degli eventi per comparare le possibilità di questo programma con quelle di programmi evoluti, come quello a cui accennava Xavier. --Alex brollo (disc.) 13:46, 29 apr 2009 (CEST)

Suggerirei a chi usa un OCR evoluto (Xavier, Lagrande, altri?) di testare a fondo la possibilità di addestrare il software ai caratteri e ai font inconsueti; se avessimo un OCR addestrato a riconoscere caratteri, font e vocabolari antichi.... :-) --Alex brollo (disc.) 10:03, 12 mag 2009 (CEST)

Il sofware a disposizione può essere istruito, attraverso un vocabolario mirato, costruito scansione dopo scansione, a riconoscere non il segno gafico ma la parola nel suo complesso e suggerire quella con cui siamo soliti sostituirla. --Xavier121 10:59, 12 mag 2009 (CEST)

Ha sorpreso anche me, ma da un link di Lagrande: http://www.pgdp.net/wiki/Training_ocr_for_old_texts , sembrerebbe che alcuni OCR possano essere addestrati anche a riconoscere old texts con caratteri inusuali/sconosciuti. La cosa mi interessa ovviamnete parecchio. Su tesseract si può fare, ma la procedura è di una complessità spaventosa. Vorrei schivare per una volta la lectio difficilior --Alex brollo (disc.) 11:21, 12 mag 2009 (CEST)

Voilà..

... le Georgiche sono diventate Proofread : Indice:Georgiche.djvu. Ho messo il SAL direttamente al 75% com'era la versione testuale "travasata". Una spintarella, e diventano un bel testo Edizioni Wikisource. :-) --Alex brollo (disc.) 15:43, 25 apr 2009 (CEST)

Proofread e lite con il tag poem

Sto conducendo una furiosa lite con il tag poem, nel corso della "trascrizione inversa" di Georgiche.

1. ho scoperto che all'interno di un testo delimitato da poem le section non funzionano, per motivi misteriosi.
2. non riesco ad evitare che il tag poem inserito sulle pagine Pagina: mi crei una riga vuota fra le pagine transcluse, devastando l'impaginazione originale.
3. Per fortuna mi è stato spiegato (grazie Edo) il "trucco" di lasciare uno spazio fra tag poem di apertura e a capo, per evitare che il primo capoverso si indenti.

Chi mi sa dire dove c'è un aiuto MOLTO approfondito su questo insidioso tag? Che le cose non siano semplici, lo dimostra che c'è un'estensione dedicata... --Alex brollo (disc.) 13:07, 29 apr 2009 (CEST)

Anche io avevo avuto il problema 2), ci avevo sbattuto la testa per un po' ma senza trovare soluzioni concrete (siiigh!) Torredibabele (disc.) 23:08, 5 mag 2009 (CEST)

Spero che Edo consideri il vecchio proverbio ad impossibilia nemo tenetur. Io ho gettato la spugna; se qualcuno risolve l'arcano meglio, altrimenti chi sa farlo dovrebbe aprire un bug (io ho gettato la spugna anche su questo compito :-(). --Alex brollo (disc.) 10:01, 12 mag 2009 (CEST)

Ho lo stesso problema, anche io. Magari in certi casi bisognerebbe usare il tag br, o altri. --Aubrey McFato 14:16, 12 mag 2009 (CEST)

A questo punto, il problema sembra che ce l'abbiamo tutti. Aubrey, ti assicuro che mi son messo d'impegno... le ho provate tutte... non escludo che ci sia un trucco che non ho scovato, ma.... :-( --Alex brollo (disc.) 14:36, 12 mag 2009 (CEST)

Ad impossibilia nemo tenetur. Se anche sul canale irc di oldwikisource gli inventori dell'estensione hanno ammesso di non venirne a capo accettiamo il bug e speriamo che qualcuno dal metaempireo dei developer lo sistemi. - εΔω 16:50, 12 mag 2009 (CEST)

Il bug non ha impedito a Georgiche di ricevere il secondo premio... :-) Ancora complimenti a tutti i premiati! --Alex brollo (disc.) 12:50, 28 mag 2009 (CEST)

Cassetti nei sommari delle pagine Indice

Superate un paio di difficoltà, ho "montato dei cassetti" funzionanti nel Sommario di una pagina Indice: Indice:Edipo Coloneo.djvu. Il trucco è di scrivere il tl senza andare a capo sui parametri, come titolo si può anche usare un tl|Indice sommario. Qui il codice di un cassetto:

* {{Cassetto| Titolo = * {{Indice sommario|4|Edipo Coloneo.djvu/103|Atto quarto|103}}| Testo =* {{Indice sommario|4|Edipo Coloneo.djvu/103|Atto quarto, scena I|103}}
* {{Indice sommario|4|Edipo Coloneo.djvu/104|Atto quarto, scena II|104}}
* {{Indice sommario|4|Edipo Coloneo.djvu/113|Atto quarto, scena III|113}}
* {{Indice sommario|4|Edipo Coloneo.djvu/116|Atto quarto, scena IV|116}}
* {{Indice sommario|4|Edipo Coloneo.djvu/130|Atto quarto, scena V|130}}
* {{Indice sommario|4|Edipo Coloneo.djvu/133|Atto quarto, scena VI|133}}
}}

Questo l'output:

Se seminato in una pagina Indice, all'interno del campo Sommario, compare anche l'icona SAL della pagina linkata; qui no. Evidentemente c'è qualcosa nel template mascherato Mediawiki che lo genera. --Alex brollo (disc.) 09:57, 28 mag 2009 (CEST)

Ottima chicca estetica, utile per i testi teatrali ed altri. Diventiamo sempre più bellini ;-) --Aubrey McFato 11:35, 28 mag 2009 (CEST)

Avviso a chi legge: i numerosi "Errore script" dipendono dal fatto che l'esempio è superato (il tl|Indice sommario non funziona più in quel modo, in tre anni sono cambiate parecchie cosette). --Alex brollo (disc.) 00:15, 27 lug 2013 (CEST)

Commento gli "errori script" per evitare che questa pagina venga riportata in Categoria:Pagine con errori di script. Candalùa (disc.) 10:23, 29 lug 2013 (CEST)

testi prelevati da altri siti internet

personalmente non mi interessa la completezza di wikisource... mi interessa invece trovare su internet trascrizioni affidabili di testi... Ho notato un problema. Ci sono anche altri siti, come ad esempio liber liber, che si aspettano dagli utenti la segnalazione di eventuali errori nelle trascrizioni dei testi. Wikisource permette di correggere facilmente un errore, ma... che cosa succede quando, come spesso avviene sulla versione italiana di Wikisource, i testi inseriti provengono da liber liber? chi inserisce un testo di liber liber in Wikisource, lo controlla o no? si limita a formattarlo senza ricontrollare la trascrizione? e se individua degli errori, li segnala anche a liber liber o no? e che cosa succede dopo?

inizialmente liber liber e wikisource avranno lo stesso testo con errori (ogni trascrizione presenta errori), poi gli utenti di ciascuna comunità indicheranno alcuni errori da correggere solo alla propria comunità, senza indicarli alla comunità "avversaria"...

a che cosa serve tutto questo? il mio consiglio è: ogni volta che si prende un testo da un sito internet per metterlo su Wikisource, o si ricontrolla la trascrizione con la versione cartacea e si segnalano gli errori anche al sito di provenienza, oppure è solo una perdita di tempo...

Ciao Needmoral, innanzitutto benvenuto.

Innanzitutto ti confermo che la rilettura e la correzione avviene eccome. Penso che tu non abbia tenuto distinti due elementi: la "fonte", mettiamo, Liberliber o Internet Archive, e "l'edizione", ossia la copia stampata: è alla seconda che facciamo riferimento, anche se, per comodità, possiamo usare come canovaccio il lavoro di trascrizione pubblicato da altri, quando sia consentito dalle norme sul copyright. Altrettanto può fare chiunque con le nostre riletture.

Ci stiamo comunque orientando sempre più a lavorare sui testi con a fronte l'immagine digitalizzata delle pagine cartacee originali, e questo rende ancora più trasparente e condiviso il rapporto diretto che c'è fra trascrizione su wikisource e l'edizione originale stampata.

Quanto al sincronizzare le varie trascrizioni fra progetto e progetto... niente impedisce che possa essere fatto, ma è un lavoro improbo. Penso che ciascuno dei siti da cui attingiamo conosca bene wikisource e sappia che, se e quando lo volesse, può attingervi a sua volta a piene mani. --Alex brollo (disc.) 15:47, 28 mag 2009 (CEST)

Aggiungo solo qualche link per integrare la già esauriente risposta di Alex. Noi abbiamo un sistema di avanzamento qualità, che prevede ultimamente la rilettura da fonte cartacea. Questo purtroppo avviene solo per pochi libri, ma è la fine ideale di ogni testo inserito. Inoltre, come già detto, ci stiamo spostando sui testi con immagine a fronte (guarda in questa categoria, per dare un'occhiata): piano piano sarebbe bello focalizzarci solo su questi testi, e recuperare la fonte formato immagine di tanti testi di LiberLiber (che linka spesso la versione immagine presa da Gallica). Come immagini, il lavoro è decisamente tanto e siamo una comunità di volontari: volendo, potresti contribuire rileggendo da fonte cartacea ;-). Scherzi a parte, lavoro da fare ce n'è, se hai voglia chiedi pure informazioni, siamo tutti disponibili ;-). Aubrey McFato 16:13, 28 mag 2009 (CEST)

caro Needmoral, la penso come te: alla quantità preferisco la qualità, anche se converrai con me che arrivare in cima ai motori di ricerca non è un traguardo disprezzabile, e questo purtroppo richiede la quantità oltre che la qualità. Comunque, finché noi daremo la possibilità di risalire alla fonte cartacea del testo pubblicato il lavoro è duplice: noi non non promettiamo l'impossibile, ci sforziamo di raggiungerlo e come per Wikipedia, il tempo è a nostro favore, mentre il lettore ha un criterio rapido di affidabilità di ogni testo e nel contempo ha alcun impedimento a correggere ogni eventuale errore che sia riscontrato. Si noti infine che nessuno è preventivamente bandito da questo progetto, dunque più occhi ci aiutano a leggere e correggere, meglio è. P.S. qui nessuno è "avversario" di nessuno. la libera trasmissione della cultura ci interessa sommamente e se collaboro qui e non a LiberLiber o Internet Archive non è certo per qualche sorta di malanimo che possa nutrire verso tali progetti, ma semplicemente perché qui mi trovo bene, infatti

• ho trovato una comunità vivace, alacre e disponibile a collaborare, e infine
• questo ambiente wiki, dove puoi agire e tutto è modificabile correggibile e migliorabile mi affascina un sacco e non l'ho trovato in altre biblioteche online. - εΔω 19:24, 28 mag 2009 (CEST)

A cavallo fra il 28 e il 29 maggio: una galoppata insieme a Alebot

Da bravo ippomaniaco, sono riuscito a infilare due metafore equestri in un solo titolo. :-)

Ieri sera, insieme a Xavier, abbiamo lanciato per la prima volta da source il template {{Alebot|Roadmap opera}} e seguito le sue operazioni. Il bot ha costruito integralmente l'ossatura dell'opera Versi del conte Giacomo Leopardi, con un livello di automazione che fa svanire fra le vecchie idee che hanno fatto il loro tempo il precedente "Progetto Auto". La manutenzione degli script non finisce mai, questa è una versione iniziale che va ritoccata e migliorata... ma è stato un bel collaudo. Chi pesca errori od omissioni in Versi, in qualsiasi pagina o sottopagina testuale o proofread o relative pagine di discussione, me lo segnali: siamo nella fase "caccia all'errore". Grazie! --Alex brollo (disc.) 09:19, 29 mag 2009 (CEST)

PS: "costruire l'ossatura" significa aver creato i contenitori, per ora privi di contenuto. Tuttavia i contenuti in questo caso sono facilissimi da aggiungere: le opere di Leopardi, contenute nel libro, mi sembra siano tutte o quasi già presenti su Source e non c'è che fare un copia-incolla dalle pagine testuali alle pagine Pagina: dell'opera, come primo passo che sarà seguito dalla formattazione e rilettura.--Alex brollo (disc.) 09:24, 29 mag 2009 (CEST)

PSPS: per chi può leggerli, gli script python usati sono pubblicati sotto Utente:Alebot/Scripts interattivi. Un vero guazzabuglio, ma chi volesse cimentarsi tenga conto che la routine di partenza è def leggi, che chiama def leggi_richieste_bot (che legge il contenuto di Categoria:Richieste bot), che a sua volta chiama def crea_opera se si trova un tl|Alebot|Roadmap opera. Da lì cominciano i balli. --Alex brollo (disc.) 09:36, 29 mag 2009 (CEST)

Aggiornamento

Vi segnalo una nuova richiesta accodabile al tl Alebot: la richieste Trascrizione inversa. Questo codice:

{{Alebot|Trascrizione inversa}}

va seminato direttamente nella pagina testuale principale dell'opera di cui di desidera avviare la trascrizione inversa. Se tutto va bene, al primo lancio di Alebot comparirà automaticamente, in Wikisource:Opificio, lo schema (inattivato, da verificare e correggere) del tl Alebot|Roadmap opera, un "mostro" che dà a Alebot tutti i parametri per creare dal nulla la pagina Indice e non solo, non appena viene attivato. --Alex brollo (disc.) 11:24, 6 giu 2009 (CEST)

Nuovo amministratore

Xavier121

Vorrei candidare Xavier amministratore del progetto trascrizioni. L'entusiasmo con cui segue questa nuova attività, la boldness nel porre "domande apparentemente impossibili" alcune delle quali si rivelano ottimi suggerimenti, la cura per i dettagli grafici e - non ultimo - il recente premio Wikimedia 2009 mi sembrano tutti elementi che giocano a favore, e personalmente sarei ben lieto di esercitare la tattica sotto la sua direzione strategica. --Alex brollo (disc.) 01:19, 6 giu 2009 (CEST)

Lusingato e ... commosso! --Xavier121 11:56, 9 giu 2009 (CEST)

Approvo la candidatura (tanto più che pensavo che Xavier fosse già amministratore). :) Snark (disc.) 08:46, 12 giu 2009 (CEST)

Idea bizzarra su Intestazione e Infotesto: nuova collocazione

La posizione del template Intestazione e del template Infotesto sono fissat da una lunga tradizione e da abitudini consolidate nei "vecchi utenti", tuttavia alcune divagazioni (il mio vecchio Progetto Auto, passato recentemente a miglior vita (amen), e qualche approfondimento recente sui concetti Don't Repeat Yourself, il DRY, ed altro) mi incoraggiano a proporvi una piccola "rivoluzione". L'ho implementata sperimentalmente su Medea, dove potete vederne in pratica il funzionamento.

Intestazione

Una buona collocazione per il tl Intestazione, secondo me, potrebbe essere una sottopagina Intestazione della pagina principale testuale (vedi Medea/Intestazione), trasformata in un semplicissimo template con un unico parametro opzionale (l'eventuale nome del capitolo). Questo permette di utilizzare in tutte le pagine e sottopagine della versione testuale lo stesso codice base, con un unico parametro che corrisponde al nome dell'eventuale capitolo:

Nella pagina principale:

{{:Medea/Intestazione}}

Nelle pagine capitolo:

{{:Medea/Intestazione|Titolo del capitolo}}

I due punti in testa sono necessari per indicare che va transclusa una pagina del ns0; se non ci fossero il software cercherebbe per default un inesistente template Template:Medea/Intestazione.

Il vantaggio di questo approccio è un'implementazione DRY: i contenuto di Intestazione non vengono ripetuti, e un'eventuale correzione si riverbera in tutte le pagine e sottopagina dove l'intestazione viene transclusa.

Infotesto

A questo punto ho pensato che se Medea/Intestazione è una buona collocazione per il tl Intestazione di Medea, la logica suggerisce che una buona collocazione di Infotesto sarebbe - intuitivamente - Medea/Infotesto. Collocazione estremamente intuitiva per un neofita a cui sia stato spiegato il passo precedente, assolutamente "strana" per un utente esperto. Ponendo l'infotesto in Medea/Infotesto, si osserva che:

1. in tutte, ma proprio tutte, le pagine (ns0, nsIndice, nsPagina) si può usare lo stesso identico codice di transclusione:

{{:Medea/Infotesto}}

1. tutte le pagine di discussione assumono le stesse caratteristiche ed in particolare non occorre preoccuparsi dell'eventuale tranclusione automatica e involontaria di eventuale note e discussioni che vengono poste nelle pagine di discussione.
2. si passa automaticamente all'"infotesto unico" fra pagine Indice/Pagina e pagine testuali: attualmente spesso su Indice e ns0 ci sono due copie indipendenti di Infotesto, cosa che viola il principio DRY ed espone a disallineamenti e a "corruzione dei dati".

Un punto importante è che la soluzione è totalmente e completamente compativile con il codice attualmente esistente nelle opere, perchè comunque il vecchio codice di tranclusione (che punta su Discussione:Pagina testuale o su Discussioni indice:Nome pagina indice funzionerebbe perfettamente, sia che nelle pagine trovi un tl Infotesto, sia che trovi solo un codice di transclusione. Questa modifica potrebbe quindi essere applicata solo nelle opere nuove, senza alcuna modifica dei codici preesistenti, e potrebbe essere considerata opzionale. --Alex brollo (disc.) 11:44, 9 giu 2009 (CEST)

PS: La colonna dei link a sinistra è particolarmente affollata su it.source, ma se, aprendo la pagina di un'opera, comparissero due link alle sottopagine Intestazione e Infotesto dell'opera aperta, sarebbe un'ottima cosa :-) --Alex brollo (disc.) 11:50, 9 giu 2009 (CEST)

Ti seguo. Mi sembra una soluzione vincente! :) --Xavier121 11:59, 9 giu 2009 (CEST)

Grazie Xavier... ovviamente una cosa del genere può essere montata su alcune opere per prova, ma prima di diventare un "suggerimento o una raccomandazione ufficiale, bisognerà discuterla con parecchi utenti, pensarci e ripensarci! --Alex brollo (disc.) 23:50, 10 giu 2009 (CEST)

La Roadmap opera completa

Una decina di minuti fa è partito il primo test della "Roadmap opera perfetta": Alebot ha scritto Indice:Dieci lettere di Publio Virgilio Marone.djvu, poi è passato a creare le pagine Pagina complete di testo, poi creerà la versione testuale completa dei codici di transclusione... Questo è fattibile se c'è, ancora prima di iniziare, un testo trascritto (almeno in bozza) completo; in questo caso era un testo rielaborato dal file txt di LiberLiber.  :-) --Alex brollo (disc.) 23:41, 12 giu 2009 (CEST)

Fantastico! Davvero: ora che Alebot è diventato un mostro del genre possiamo dargli in pasto un sacco di testi tutti insieme ;-).

Ho trovato un solo errore, nele template instestazione della versione testuale: nel paramentro Pagina principale è rimasto impigliato un #nomepaginaprincipale#, che dava sì il titolo giusto ma lo rendeva linkabile. Per il resto, sono eccitato dalle prospettive. (e se riuscissimo, in qualche modo, ad avere da LiberLiber una lista dei testi che loro hanno trascritto ma di cui sono presenti le immagini su Gallica? Dite che riuscirebbero a saperlo, loro? Dite che il CD potrebbe essere utile? Magari lo chiedo a Marco Calvo) --Aubrey McFato 01:39, 13 giu 2009 (CEST)

Già: ma se Alebot ha toppato, Alebot ha rimediato. Me ne sono accorto immediatamente, ma dopo un primo tentativo di debugging al volo, ho deciso di rimediare con una seconda passata "a mano" di Alebot. Purtroppo sono stato preso dall'entusiasmo e avevo modificato la routine Roadmap in due punti: la parte dove vengono create le pagine Pagina: (che ha funzionato bene) e la gestione del tl Intestazione (che ha toppato). Ho chiaro il problema e so dove mettere le mani: il problema è quello di gestire quialsiasi intestazione, di qualsiasi progetto. Il fatto che ci siano più di dieci varianti dei tl Intestazione rende la cosa una bella sfida... ;-)

Sono orgoglioso del tuo apprezzamento, Xavier, ma.... per ora la routine è lontana dall'essere affidabile: quando la lancio controllo Alebot con il fucile spianato pronto a accopparlo, dall'inizio alla fine del lavoro. Non escludo che raffinando raffinando si possa arrivare a lasciarlo fare, ma ci siamo ancora lontanucci. :-( --Alex brollo (disc.) 09:51, 13 giu 2009 (CEST)

Template:R

Problemi col tl R se inserito in una riga che deve rientrare verso destra. Il numeretto scende al verso successivo.(es. 5 al verso 6). --Xavier121 15:24, 13 giu 2009 (CEST)

Avevo sbattuto il naso sullo stesso problema ma non trovo più dove l'avevo discusso. In che opera stai rilevando il problema? faccio un po' di test in Wikisource:Pagina delle prove--Alex brollo (disc.) 15:41, 13 giu 2009 (CEST)

Il fattaccio si verifica se si rientra con spazi ma non se si rientra con i caratteri :, vedi test in pagina delle prove (meglio scriverlo da qualche parte se c'è un aiuto sull'uso di poem)--Alex brollo (disc.) 15:54, 13 giu 2009 (CEST)

Devo ottenere questo risultato: si può fare solo in questo modo? (modifica per vedere il trucco) --Xavier121 16:54, 13 giu 2009 (CEST)

Ho visto: mi sembra tutto a posto... non so se c'è un altro modo, ma questo mi basterà se mi capita. O c'è un problema che non vedo? --Alex brollo (disc.) 17:18, 13 giu 2009 (CEST)

In alternativa, quando si rientra con degli spazi, il tl|R può essere messo alla fine del verso predente e tutto si sistema: vedi Pagina:La bellezza dell'universo.djvu/2 di cui ho appena completato la trascrizione inversa (che fastidio gli spazi fra poem e poem nella versione testuale transclusa....... :-( )--Alex brollo (disc.) 00:44, 14 giu 2009 (CEST)

Problema: immagine della pagina in Modifica

Dopo un secolo ho aperto una pagina proofread per fare un po' di editing, e con disappu nto vedo che l'immagine è visualizzata solo parzialmente: la parte finale è "fuori campo", e per vederla dovrei attivare l'opzione di visualizzazione che mi è meno simpatica, quella "sopra-sotto" piuttosto che quella laterale. Succede anche a voi? C'è un edit del software in corso? --Alex brollo (disc.) 15:17, 16 giu 2009 (CEST)

Più che un problema, a me sembra un miglioramento. Mentre prima la pagina da trascrivere era statica, adesso è dinamica; il che significa che se non ci sta tutta basta cliccarci sopra e trascinarla dove si vuole (ma si può anche aumentare o diminuire di dimensione a piacimento, usando la rotellina centrale del mouse), il che è una bella comodità. :) Ma forse sono io che non ho capito il problema... Ciao! Snark (disc.) 15:30, 16 giu 2009 (CEST)

Te lo spiego: il problema è che sono un allocco. ;-) Tutto avevo provato, meno che trascinare l'immagine. Cercavo disperatamente un cursore o qualcosa del genere... la rotellina poi non l'avrei mai usata. --Alex brollo (disc.) 00:07, 17 giu 2009 (CEST)

Il punto sulle opere elencate per la Trascrizione inversa

Ho lavorato un po' sulle opere di cui è stata proposta la trascrizione inversa; ho preparato e caricato su Commons tutti i file djvu che mancavano, tranne quelli di Zibaldone. La colonna dei file djvu è quindi "bluificata", nei prossimi giorni vorrei "bluificare" anche gli Indici ancora rossi; dopodichè mi prenderò una lunga wikipausa selettiva, nel senso che vorrei dedicarmi esclusivamente a Zibaldone.

La bluificazione degli indici sarà fatta mediante Alebot|Roadmap opera, mettendo il template in Wikisource:Opificio per lavorarci un po' insieme, prima dell'effettivo lancio. La parte di lavoro manuale da fare è rilevare e riportare, capitolo per capitolo, la pagina di inizio e di fine dei capitoli. --Alex brollo (disc.) 11:02, 18 giu 2009 (CEST)

Immagini nei libri: dove/come pubblicarle

Sono un po' incerto su come e dove pubblicare le immagini tratte da libri. Vedo varie possibilità, dopo che sono state ritagliate, ritoccate e trasformate in file jpg:

1. montarle come pagine aggiuntive in coda alle immagini delle pagine del file djvu, come pagine accessorie (quindi, ovviamente, metterle su Commons in blocco con il libro);
2. montarle in un file djvu separato (in questo caso potrebbero stare sia su Commons che su it.wikisource);
3. pubblicarle come jpg singole (anche in questo caso, potrebbero stare sia su Commons che su it.wikisource).

Pubblicarle come jpg singole offre qualche problema in più come categorizzazione, ma ha il grande vantaggio che sono più maneggevoli, e non interferiscono con l'eventuale conversione in "libro pdf".

La soluzione che ho adottato per tre immagini tratte da Indice:Lettera sopra il canto de' pesci.djvu è di pubblicarle su it.wikisource come jpg singole, con il tl PD ma senza categorizzarle; in attesa di sentire il vostro parere (io vedrei bene un'unica categoria globale Categoria:Immagini tratte da libri o qualcosa del genere).

Che ne dite? --Alex brollo (disc.) 23:13, 18 giu 2009 (CEST)

Per la verità qui su 'source avremmo già una Categoria:Illustrazioni (con tanto di sottocategorie per i libri con molte immagini)... che ne dici? :) Ciao! Snark (disc.) 23:20, 18 giu 2009 (CEST)

No. Io sono dell'idea che le immagini siano da caricare esclusivamente su Commons e considerate singolarmente, per poterle usare su tutti i progetti con la massima libertà. Sto procedendo in questo modo per il Bettinelli. :) --Xavier121 19:13, 19 giu 2009 (CEST)

A dire il vero, quello che mi angoscia è che la categorizzazione di queste immagini - per renderle veramente disponibili a tutti i progetti da Commons - dovrebbe prendere in considerazione anche il contenuto dell'immagine.... solo così diventa "svincolata" dal libro e reperibile per chi eventualmente la cerca. In fondo, una copia dell'immagine - disponibile per tutti - su Commons c'è: è quella contenuta nel djvu. Non lo dico per insistere, ma solo per giustificare l'incertezza; in genere non ho dubbi, tutte le immagini originali le metto su Commons senza alcuna esitazione. --Alex brollo (disc.) 21:41, 22 giu 2009 (CEST)

Temo di rattristare Alex, ma la storia va nella direzione descritta da Xavier121: le immagini sono PD-Old, all'inizio le tenevamo localmente per poterle categorizzare come ci pareva, ma nel tempo abbiamo capito che per l'esiguità degli utenti attivi it.source non può accollarsi la gestione di immagini in locale. peraltro è possibilissimo aggiungere categorie nostre qui a una immagine caricata su commons: vedi File:P_culture.svg. Diversamente da Xavier io comunque sarei per la categorizzazione anche per libro contenitore come facevamo qui. Insomma, si categorizzano le immagini per contenitore e per contenuto. La seconda parte è macchinosa e rognosa, ma possiamo provare a chiedere la collaborazione dei commonisti. Al limite la categorizzazione per libro è pur sempre garanzia di reperibilità anche se non è certo la soluzione migliore. - εΔω 07:32, 23 giu 2009 (CEST)

Si, sono molto triste. Anche perchè il settore che a suo tempo seguivo su Commons (Histopathology) e che avevo ben sistemato ricomincia ad essere un guazzabuglio.. e una mia proposta è stata presa un po' sottogamba. --Alex brollo (disc.) 10:53, 23 giu 2009 (CEST)

Alex, non rattristarti. La tua proposta per le catwords non è stata capita, e se anche lo fosse stata sarebbe stata veramente complicata da applicare. La categorizzazione nei progetti wiki rimane ad uno stato brado, quando una marea di bibliotecari e classificatori si accorgerà dei progetti wiki avremo una nuova era del Web, ma èer ora siamo lontani :-). Aubrey McFato 12:54, 23 giu 2009 (CEST)

Già... adesso che non posso avviare la categorizzazione sperimentale su Commons, come riempirò le mie serate? ;-) --Alex brollo (disc.) 13:34, 23 giu 2009 (CEST)

Probabilmente non sono stato molto chiaro su quel punto ma categorizzare le immagini per gruppi contenitori libro-autore-genere(illustrazione,incisione, stampa ecc.) lo davo per scontato. :) --Xavier121 14:41, 23 giu 2009 (CEST)

A questo punto, Xavier, ti chiedo un "esempio esemplare" per evitare un orribile do it yourself. Hai sottomano un libro illustrato in cui grafica di vario tipo (fregi, capilettera, ex libris, illustrazioni) sia stata ottimamente categorizzata? Lo esplorerò molto volentieri e saccheggerò le buone idee (e non sarebbe male preparare una paginetta di aiuto, a mio parere). --Alex brollo (disc.) 18:50, 23 giu 2009 (CEST)

Se mi dai qualche giorno trovo il tempo di sistemare tutte le immagini ricavate dal Bettinelli. Credo sia un buon esempio. --Xavier121 20:29, 23 giu 2009 (CEST)

Libri: due buone notizie

Sono riuscito a far produrre una versione pdf decente di Georgiche al tool Libri. E' stata una cosa un pochetto laboriosa in tre tappe:

1. creazione via Alebot di Georgiche/Testo completo, pagina che contiene l'intero libro, ripulito degli orpelli e con testo delle varie pagine ricucito per bene; ricordo che la versione attuale di Georgiche è un proofread, e che quindi la versione testuale è, in sostanza, una lista di tl Pagina;
2. conversione di tutti i tl R nella loro "esplosione" in semplici tag html, perchè il tool Libri non li espande;
3. spostamento dei tag html rislutanti dall'esplosione del tl R a fine verso, invece che a inizio verso.

L'unico piccolo neo è che i numeri di verso non sono allineati a destra, ma semplicemente equispaziati dalla vine del verso; ma io sono piuttosto soddisfatto lo stesso. :-)

La seconda buona notizia è che il tool libri sembraguasto, ma in realtà è inceppato solamente il meccanismo di aggiornamento dinamico dell'avanzamento del lavoro; ignorate l'errore, ripetete ogni tanto il ricaricamento della pagina, e alla fine comparirà il messaggio "Conversione terminata" ed il link funzionante al file pdf.--Alex brollo (disc.) 21:31, 22 giu 2009 (CEST)

.... resta solo Memorie...

Ho rovistato nella cronologia della pagina Lavori da finire e ho scoperto l'amabile utente che ha aggiunto due opere particolarmente spinose: Aubrey. ;-)

Una è Memorie..., un "mezzo Zibaldone" di 795 pagine di cui mi sto accingendo a scrivere l'indice nel tl Roadmap; l'altra, che sembrava innocente ma che nasconde un trabocchetto indisioso, è Vita di Dante, Petrarca e Boccaccio, che ha una struttura di libro bilingue latino/italiano con traduzione a fronte. Come si rende un libro bilingue con traduzione a fronte? C'è qualche esempio a cui ispirarsi? Il problema non è tanto nella costruzione dell'indice, quanto nella resa testuale della struttura "testo a fronte". O la parte latina va su la:wikisource e saluti? --Alex brollo (disc.) 22:48, 24 giu 2009 (CEST)

Vedo due possibilità:

1. Lobotomizzare il libro, strappando via ciò che di latino è a fronte
2. Tenere integro il libro e trascrivere solo la parte italiana.

Io sono per la seconda ipotesi. Dato che la scansione finisce su commons non vedo particolari problemi a "dividere il lavoro tra diverse source", vale a dire che noi trascriviamo e riportiamo inversione testuale solo la parte italiana; su la.source avviene lo speculare lavoro su quella latina mentre chi si voglia scorrere il file pagina per pagina prenderà atto delle pagine latine non trascritte in cui —al massimo— mettiamo un rimando a la.source. Una ingegnosa costruzione dell'indice (a mano, non via pagelist) permetterebbe di presentare anche nell'indice i link solo alle pagine in italiano. Parliamone - εΔω 23:24, 24 giu 2009 (CEST)

Aggiungo una possibilità: rendere le pagine a fronte con capitoli a fronte: due colonne affiancate, rese con due celle di una tabella di una riga e due colonne. Spezzare il libro in due (latino su la.source, italiano su it.source) solo perchè il testo è a fronte, ed è completo, comporterebbe una serie di problemi: come rendere poi note, osservazioni, commenti del traduttore, che si riferiscono, suppongo, all'opera com'è? E una modifica così radicale di una fonte non sarebbe qualcosa di molto, ma molto più radicale di una edizione critica? E inoltre: che differenza di sostanza c'è fra un testo di questo tipo, e altri testi in cui all'interno del testo italiano vi sono intercalati frammenti talora brevi, talora lunghi in altre lingue?

Aggiungo un'ulteriore possibilità: spostare il testo nella source multilingue... e una quinta un tantinello audace: riunire tutte le source, dalla prima all'ultima, in un'unica source multilingue (cosa che avevo già buttato là in un'altra discussione)... vi pare troppo audace? ;-) --Alex brollo (disc.) 00:44, 25 giu 2009 (CEST)

A parte l'ultima proposta scherzosa (ma visto che sono considerato un po' matto, meglio precisarlo), un'ulteriore possibilità che mi piace abbastanza: riorganizzare le pagine all'interno del file djvu, mettendo in testa, e in sequenza, tutte le pagine in italiano, oltre alle pagine accessorie, e in coda tutte le pagine in latino. Il principio di conservazione del testo sarebbe salvo, e la manipolazione dei contenuti (sia per quanto riguarda gli automatismi tipo pagelist, che per quanto riguarda le future decisioni su cosa farne, del testo latino) sarebbe senz'altro agevolata, IMO. Intanto produco una seconda versione riordinata del djvu, poi aspetto il vostro parere. --Alex brollo (disc.) 06:39, 25 giu 2009 (CEST)

Waiting for reply

Aspetto una risposta.... chi mi dà l'OK/NIET per l'ultima proposta che ho fatto? --Alex brollo (disc.) 09:16, 29 giu 2009 (CEST)

Perché non si crea una pagina sul ns0 (smanettando un po' col codice) l'edizione con testo a fronte, ovvero una pagina un po' più larga del normale che possa contenere due pagine affiancate (a colonna speciale), sufficientemente comode in cui inserire testo italiano e testo latino. Sul nspagina si lavora come facciamo suol Vocabolario della crusca o sull'indice dello Zibaldne: a colonne semplici. --Xavier121 11:31, 29 giu 2009 (CEST)

Era una delle possibilità che avevo proposto nella discussione. Le facciate comunque sono singole sul djvu, quindi il quesito che ri-pongo è limitato all'ordinamento delle pagine sul djvu: quello originale, o un riordinamento con testo latino reso su pagine consecutive? Io propenderei per la seconda possibilità... poi giocando di trasclusione sul ns0 possiamo sbizzarrirci (perfino, volendo, con due versioni diverse, una a fronte, l'altra tradizionale). --Alex brollo (disc.) 11:48, 29 giu 2009 (CEST)

Mah, da una parte riconosco che al fine della presentazione del testo riordinare le pagine nel djvu facilita la navigazione sequenziale nel nsPagina, dall'altra pongo un paio di obiezioni:

• Se una nota a pie' di pagina si stende sia sulla pagina latina che su quella della traduzione creeremmo un bel macello, verifichiamo che questo non accada.
• Poi a me l'idea in sé della manipolazione della fonte proofread (come già è successo molte volte per rendere proofread i poemi trascritti da Snark) non è mai andata giù del tutto. Proprio per questo desidero che si giunga a una discussione ben articolata: la mia idea è quella di creare indici e trascrizioni del medesimo libro sia su la. che su it.source, con trascrizioni nelle lingue di pertinenza e rimandi (softredirects, template, quel che volete, insomma) incrociati alle rispettive source per le lingue non di pertinenza. - εΔω 17:56, 29 giu 2009 (CEST)

La discussione era comunque - da parte mia - dettata puramente dalla curiosità. Per un bel po' sarò impegnato a tempo pieno su Zibaldone. tenete solo conto che se la vorrete, c'è una versione djvu con le pagine riordinate e suddivise in latino e in italiano. --Alex brollo (disc.) 21:29, 29 giu 2009 (CEST)

Link pagine->versione testuale

Al momento, esiste il link versione testuale ->pagina sorgente (attraverso il tl|Pagina) ma non esiste un link pagina sorgente-versione testuale.

Ho implementato sperimentalmente in Pagina:Narcissa.djvu/3 tale link con queste operazioni:

1. creazione di un'ancora con il tl § sulla pagina (nel caso, essendo un poemetto, ancorandolo al primo verso, con il codice: {{§|numero pagina|verso}})
2. aggiunta di un tl|AltraVersione nell'intestazione non transclusa (nel caso, ho aggiunto {{AltraVersione|http://it.wikisource.org/wiki/Narcissa#3|Versione testuale}} subito dopo al tag <div class="pagetext"> dell'intestazione).

Nei casi "semplici", come Narcissa, in cui la versione testuale è costituita da una pagina singola, questo completa la procedura. Nei casi, invece, in cui la versione testuale è divisa in capitoli, il link all'interno del tl AltraVersione deve puntare sul capitolo specifico; questo è fattibile via bot scorrendo il codice della versione testuale e estraendo i tl|Pagina compresi dal capitolo, ricavandone l'elenco delle pagine Pagina: a cui aggiungere il link corretto.

Prima di procedere alla preparazione di un ulteriore script interattivo di Alebot, che potrebbe svolgere completamente l'intera procedura in tutti i casi, chiedo la vostra opinione sullo sporco trucco. --Alex brollo (disc.) 11:59, 6 lug 2009 (CEST)