Wikisource:Domande tecniche/Archivio/2010

Idea js: tool per postelaborazione OCR

Ho cominciato a rovistare nel monobook.js completo come duro "esercizio di js", che ho deciso di cominciare a studiare. Trovo l'interessante funzione fixformat che fa proprio quello che servirebbe per una postelaborazione al volo dei testi provenienti da ORC, che sono straordinariamente migliorati da piccole, ma numerose, operazioni di cerca-e-sostituisci. C'è qualche anima buona che mia aiuta a sistemare i punti critici? L'elenco dei replace lo posso fornire io, ma ho (al momento) difficoltà nel collegare la chiamata alla funzione con un pulsante aggiuntivo. --Alex brollo (disc.) 12:25, 12 gen 2010 (CET)

Ho il piacere di dirvi che abbiamo a disposizione una funzione js postOCR che fa quasi tutto quello che faceva il mio script python:

1. aggiustamento spazi attorno alla maggior parte dei segni di interpunzione
2. riunione delle parole spezzate a fine riga
3. conversione degli apostrofi da dattilografici a tipografici e soppressione dello spazio dopo gli apostrofi
4. correzione di alcuni comuni errori di vocali accentate (E' -> È)
5. eliminazione degli acapo di fine riga con conservazione dei doppi a capo di fine paragrafo

Il bello è che è veramente facile creare nuove sostituzioni. Il tutto è permesso da uno script che trovate nel mio monobook.js, il cui motore è scitto da Pathoschild e documentato qui: http://meta.wikimedia.org/wiki/User:Pathoschild/Script:Regex_menu_framework. L'applicazione pratica invece l'imitata dal monobook di en:User:Billinghurst e ho adattato le routine per i tipici scannos che Internet Archive infila nei suoi testi. Un sentito ringraziamento al nostro migliore anonimo che mi ha permesso di devastare, in i miei test, il suo ottimo lavoro: Indice:Sotto il velame.djvu. :-) --Alex brollo (disc.) 19:50, 23 gen 2010 (CET)

PS: questo non significa affatto che ci capisca qualcosa di js, hai voglia (per rispondere all'appello di Edo nel post successivo). ma ho notato che il nostro Common.js è veramente pesante, come pure il monobook.js completo, fatto il confronto con altri. :-( --Alex brollo (disc.) 19:50, 23 gen 2010 (CET)

Problema Javascript

Carissimi,

ho provato a chiedere in un attimo di lucidità, come mai da noi non funziona l'estensione Categorytree (cf en:Special:Categorytree/Authors con Speciale:Categorytree/Autori). un salto nel canale IRC wikimedia-tech ha prodotto il seguente risultato:

[16:57] RoanKattouw:There's site JS on itwikisource that creates its own getElementsByClassName() function that's incompatible with the one in wikibits.js
 That function needs to be removed and its callers migrated to use the function from wikibits.js
[17:13] orbiliusmagister: No problem in going to common.js and removing those function...
[17:13] orbiliusmagister: but then? I didn't understand the second part
[17:13] RoanKattouw: Well there's other site JS using that function
[17:13] RoanKattouw: Well there's some other site JS of yours that uses that function, so that'd break. Someone needs to change those calls to use the wikibits.js version of the function, which works differently
[17:14] RoanKattouw: I suggest you grab your community's JS developer; someone must've written that code
[17:14] orbiliusmagister: Ok
[17:15] orbiliusmagister: I'll copy and paste your answer to our local village pump.

Capiamoci, per me è arabo, ma se qualche smanopolatore di Javascript volesse provare a tradurre in linguaggio umano potrei anche tentare di riparare il riparabile... - εΔω 17:26, 23 gen 2010 (CET)

Allora. La funzione getElementsByClassName() è un grosso argomento, e il creatore della versione su http://it.wikisource.org/skins-1.5/common/wikibits.js la documenta qui: http://robertnyman.com/2008/05/27/the-ultimate-getelementsbyclassname-anno-2008/.

Su common.js di en.source non c'è (verosimilmente caricano solo la versione "nuova" di wikibits). Quindi: bisogna eliminarla dal nostro common.js.

Il problema è che la chiamata alla versione nuova chiede tre parametri e non uno, e purtroppo quello che viene "chiamato" da noi (il nome della classe) è il terzo. Quindi, volendo assicurare la compatibilità delle nostre chiamate con la funzione, occorre ripescare ognuno degli script che la chiama e modificarli (dopo aver capito per bene cosa vuole, nel primo e secondo parametro).

A occhio, la cosa va fatta, perchè questo potrebbe essere in futuro la causa di molti grattacapi... si potrebbe cancellare brutalmente la nostra funzione, e vedere cosa si pianta. --Alex brollo (disc.) 18:00, 24 gen 2010 (CET)

L'unico script, da quello che ho rovistato, che chiama la "nostra" getElementsByClassName(), è lo script killTitle, presente sempre in common.js e scritto da PietroDn. Ma invece altri script "istituzionali" chiamano la funzione con la sintassi ufficiale, e probabilmente,anche se non ce ne siamo accorti, sono bloccati o malfunzionanti.

Siccome lo script killTitle mi pare ornamentale più che sostanziale, io suggerisco di rimuovere semplicemente la getElementsByClassName() dal nostro common.js e nel frattempo avvisare PietroDn perchè aggiusti la chiamata nel suo script, aggiungendo i due parametri ulteriori richiesti. In base alla mia esperienza, garantisco, per la procedura che suggerisco, una probabilità di successo di un buon 10%. :-) --Alex brollo (disc.) 18:16, 24 gen 2010 (CET)

A pensarci bene, forse basta entrare in common.js e rinominare sia la funzione che la chiamata di funzione in modo che diventi diversa; lasciando poi eventualmente a PietroDn il compito di aggiornare. Masi lasciano indietro cocci...--Alex brollo (disc.) 07:47, 25 gen 2010 (CET)

Update

Bene. È bastato sopprimere lo script killTitle per far funzionare di nuovo il categorytree. E questo è già molto buono. L'unco drawback finora è che le intestazioni di portali - progetti - indici dove le intestazioni nascondevano i titoli ora i titoli li mostrano. Poco male, si tratta di pura cosmesi, e probabilmente si rimedia con facilità. - εΔω 17:53, 25 gen 2010 (CET)

tl|Centrato + poem; post-OCR via js

1. Ho casualmente scoperto che tl|centrato e poem collaborano molto bene fra di loro per semplificare il codice necessario a rendere testi costituiti da righe centrate multiple, variamente formattate, evitando l'uso di <br />.

Infatti:

Questo è un tipico

titolo

di un'opera

scritto su più righe spaziate

2. Ho aggiunto qualcosa alla funzione postOCR che trovate nel mio Utente:Alex brollo/monobook.js e ho creato una nuova funzione "A capo". Quest'ultima elimina gli a acapo di fine riga nei pezzi di testo dove gli acapo danno fastidio (tipicamente lunghi paragrafi da rendere in corsivo, in cui eventuali acapo "spezzano" l'effetto di eventuali tag corsivo o, più raramente, grassetto). Ovvio: NON usate la funzione sulle opere in versi altrimenti succede un disastro! :-) --Alex brollo (disc.) 10:11, 8 apr 2010 (CEST)

Osservazioni sullo "spostamento di pagine"

Ci ho messo un bel po' per capire....

1. ogni pagina è univocamente identificata da un ID (non dal titolo).
2. nello "spostamento di pagina" quello che avviene è, in realtà:
   1. la pagina "spostata" mantiene il suo ID (e quindi la sua cronologia!);
   2. il titolo collegato a quell'ID viene modificato come richiesto; va bene qualsiasi titolo purchè non sia già presente o non sia "speciale";
   3. viene aperta una NUOVA pagina con il vecchio titolo, e le viene attribuito il contenuto REDIRECT alla vecchia pagina con il nuovo nome. Questo permette ai link alla vecchia pagina di non "puntare nel vuoto" (aimè, i link puntano al titolo e non all'ID!) e quindi possono essere rintracciati e corretti (uno a uno a mano, ma c'è una procedura via BOT che devo dissodare).

Per i più irresponsabili, esiste una procedura non accessibile all'utente comune che permette di "spostare la pagina senza lasciare tracce", ossia di rinominarla senza lasciarsi dietro pagine di redirect.... ma va usata con molta cautela. Io la sto usando nella conversione degli Indici che puntano su immagini singole jpg, ma con una certa apprensione.... :-( Bisogna essere ben sicuri di non lasciarsi dietro link "che puntano al nulla". --Alex brollo (disc.) 11:45, 25 apr 2010 (CEST)

Similitudine fra stringhe

Ho ideato un algoritmo che permette di confrontare due stringhe e ottenere una "percentuale di appartenenza" della prima nella seconda. Il meccanismo è semplice e sfrutta solo due cose che python fa velocemente e bene: l'estrazione di pezzetti di stringa e la ricerca di stringhe.

L'algoritmo logico è il seguente, date stringa1 e stringa2:

1. azzera contatore match
2. azzera contatore cicli
3. per tutta la stringa stringa1:
   1. estrai la sottostringa cicli:cicli+3 (dal carattere 0 al carattere 3, poi da 1 a 4, poi da 2 a 5....
   2. se la sottostringa è contenuta in stringa2:
      1. incrementa di 1 il contatore match
   3. incrementa di 1 il contatore cicli
4. calcola match*100/cicli (percentuale di match sul totale dei tentativi)

Il risultato va da 0 (nessuna sottostringa di stringa1 appartiene a stringa2) a 100 (tutte le sottostringhe di stringa1 appartengono a stringa2, il che non significa che siano uguali). Ci sono possibili varianti (trasformando le stringhe da confrontare, es. convertendo tutti i caratteri in minuscolo o eliminando la punteggiatura e gli spazi, o ripetendo il procedimento scambiando le stringhe fra di loro) tutte da esplorare. Per chi ci trova divertimento... io lo trovo. :-) . Questo algoritmo python lo esegue in qualche millisecondo. :-) --Alex brollo (disc.) 12:16, 8 lug 2010 (CEST)

It.source match and split

Vin (abbiamo in friulano, lo uso oper una volta....) il nostro Match and Split, totalmente originale. La chiave per farlo funzionare è "l'algoritmo di similitudine" sopra descritto, che si è dimostrato fenomenale (donde l'entusiasmo che traspariva..). Per i curiosi spiego come per adesso il match and split funziona nelle mie mani. Mi piacerebbe renderlo accessibile ad altri, ma al momento, aimè, non lo è se non per i "pythonisti anormali" come me.

Prerequisiti

1. disponibilità di un file djvu con layer di testo da OCR di discreta qualità (tipo la quasi totalità dei file di Internet Archive)
2. presenza di una versione testuale in ns0

Procedura operativa

1. caricare il djvu su Commons e preparare un file Indice:.
2. scaricare il file djvu.xml contenente il testo da OCR
3. con la funzione estrai() python trasformare il testo in una lista di pagine
4. con la funzione caricaTesti() python scaricare (leggendo la pagina principale dell'opera in ns0) tutti i testi dei capitoli/sezioni in un unico grosso file txt (chiamiamolo TESTO); le varie sezioni/capitoli sono identificate da opportuni header-footer

1. lanciare la funzione match() che esegue le seguenti operazioni (per ora funziona su testi in versi, che hanno il vantaggio di essere organizzati in righe distinte, i versi):
   1. per ogni pagina della lista:
      1. cerca il match grossolano del contenuto della pagina in TESTO con algoritmo "statistico";
      2. appoggiandosi sui delimitatori header-footer estrae l'intero testo della sezione/capitolo;
      3. passa il testo della sezione/capitolo e il testo della pagina a un secondo script di match fine;
      4. questo secondo script esamina riga per riga il testo ed esegue il match "perfetto" (identifica nella sezione/capitolo le righe che sono contenute nella pagina con l'"algoritmo di similitudine");
      5. se il match ha successo vengono aggiunti due tag poem in testa e in coda alle righe appropriate e viene creata la pagina Pagina, in cui il testo delle righe "che battono" viene scritto tal quale com'è in ns0.

Esempio: A Satana è un'opera compresa in Indice:Poesie (Carducci).djvu. Non so dove, so che da qualche parte c'è. Ho sul pc la lista python delle pagine di File:Poesie (Carducci).djvu. Carico il testo di A Satana in un file con caricaTesto() e lancio match(). Lo script esamina una per una tutte le pagine (oltre 1000!) della lista con sovrumana velocità (suppongo, 10 o più pagine al secondo: scrollano velocissime). Trovato il match, fa quello che deve fare e produce le pagine Pagina: nel posto giusto. Poi carico un "mostro" come l'intero contenuto di Juvenilia. Rilancio match() e la cosa va avanti da sola, qualsiasi sia il numero di pagine che match() trova; siano una o siano 200, senza badare all'ordine in cui compaiono e ignorando bellamente tutti i codici di formattazione, i template, le differenze in spazi e punteggiatura presenti nella versione testuale, che non creano il minimo intoppo alla ricerca del match.

Passo 2

Restano "buchi", perchè sicuramente vi sono parti del file djvu che non sono presenti in ns0:

• prefazioni, pagine indice, note dell'editore;
• opere incomplete;
• opere mancanti;
• pagine vuote.

Lancio un secondo script, che "riempie tutti i buchi" di Indice: caricando il testo come sta nella lista python delle pagine.

Passo 3

Alcune delle pagine create sono vuote.

Lancio un terzo script che le identifica e le marca con pagequality=0.

Il risultato finale

Le opere sperimentali caricate sono:

• Indice:Poesie (Carducci).djvu
• Indice:Myricae.djvu

L'analisi in corso di rilettura mostrerà quanto spesso il meccanismo ha fallito; un'analisi campionaria mi ha permesso di trovare un solo errore su Myricae. Essendo un meccanismo di "match statistico", è assolutamente certo che qualche errore sarà stato fatto; per favore, segnalatemelo! --Alex brollo (disc.) 09:11, 9 lug 2010 (CEST)

I problemi

Il sistema lavora molto bene sulle opere in versi, ma:

1. non è testato sulle opere in prosa;
2. è "sensibile ai versi brevi", e salta alcuni versi brevi in testa e in coda a una pagina;
3. viene confuso anche da molti "versi brevi" nel contesto della pagina.
4. c'è il problema delle pagine spezzate, che appartengono a diverse sezioni/capitoli
5. infine, c'è in terribile problema nelle note, ossia di "pezzi di testo" indipendenti che sono situati in posizione totalmente diversa nel contesto.

I problemi 2 e 3 problemi sono ben espressi dai mancati match nel caso di Adelchi all'interno di Indice:Opere varie (Manzoni).djvu, ma il problema 2 si è affacciato per Myricae.

Tutti e tre i problemi derivano dal fatto che si appoggia eccessivamente agli acapo; occorre quindi risolvere il punto 1 (fare un match "indipendente dagli acapo") e verosimilmente si risolveranno anche i problemi 2 e 3. E' ora di portare a spasso il cane :-) e di riflettere su un "match fine" basato su un algoritmo del tutto diverso. --Alex brollo (disc.) 05:51, 10 lug 2010 (CEST)

Proposta per template testo

Ho trovato per caso un template francese che mostra un'iconcina carina per mandare al testo djvu quando presente. Il codice è qui sotto:

<includeonly><span class=openbook>[[Livre:{{{2|{{{1}}}}}}|     ]]</span> {{#if:{{{1|}}}|[[{{{1}}}|{{{3|{{{1}}}}}}]]|}}</includeonly><noinclude>

sarebbe integrabile e traducibile nel nostro template {{testo}}? Altrimenti traduciamo il template e lo usiamo solo con i libri djvu. Aubrey McFato 16:00, 10 lug 2010 (CEST)

Ultimi arrivi

Altra cosetta. Dato che ancora dobbiamo fare a mano, chi mi fa il favore di risolvere il piccolo bug che mi butta la scritta aggiorna sotto il box? io non ricordo come si fa. Grazie. Aubrey McFato 17:43, 10 lug 2010 (CEST)

Fatto così. - εΔω 19:01, 10 lug 2010 (CEST)

Bug strano

OK, questo è strano davvero. Non capisco come mai

Vedi anche Wikisource:Niente testi originali.

viene visualizzato in corsivo e con un font diverso. Forse dibende dal css, io e ipork anni fa facemmo qualcosa per avere un font diverso per le poere di letteratura. Ma questo è un template ed è l'unico a venir visualizzato così. La cosa strana è che se togliete alcune lettere, CAMBIA!

Vedi anche Wikisource:Niente.

Vedi anche Wikisource:Niente testi.

Vedi anche Wikisource:Niente test.

Vedi anche Wikisource:Niente testi.

Vedi anche Wikisource:Niente testi bla bla bla.

Qualcuno mi sa dire? Priorità bassa, proprio se non avete nulla da fare. Aubrey McFato 21:01, 12 lug 2010 (CEST)

c'è nel template un class="hiddenStructure" che non capisco proprio che senso abbia... nel css non c'è nessuna classe che cominci per "hiddenStructure". In più col parametro 1, se tu passi al template la stringa "testi", lui va a prendere la classe "testi" del css! provo a togliere quella roba. Candalùa (disc.) 21:37, 12 lug 2010 (CEST)

ok, ho capito come funzionava: si trattava di un "magheggio" della peggiore specie che mostrava o nascondeva le varie scritte a seconda dei parametri che erano presenti. ora il template dovrebbe funzionare uguale ma senza più questi fastidiosi effetti collaterali. Candalùa (disc.) 21:54, 12 lug 2010 (CEST)

Grazie Candalua, era una piccola cosa ma ora finalmente è stata risolta. Appena ne trovo altre te le passo tutte ;-). Più che altro, tu che sei pratico, sapresti indicarmi una guida/aiuto per imparare a postare bug su bugzilla? Sono un totale niubbo a riguardo, ma ci sono alcune cosette che vorrei chiedere ai developer. Aubrey McFato 22:39, 12 lug 2010 (CEST)

Ns0 (caso semplice...) ispiegato in due screenshoot

Vedete? una volta deposto un Ns0 in una pagina, sono disponibili 4 dati, due dai parametri e due dal nome della pagina: "base" del nome della pagina e dell'Indice; numero della pagina; nome della sottopagina testale (parametro 1) e titolo della pagina testuale (parametro 2).

Se in giro ci sono section, sono disponibili altri due dati: il nome dell'eventuale section che si chiude immediatamente prima del Ns0, e il nome dell'eventuale section che si apre immediatamente prima di Ns0.

Se si tiene a mente tutti questi dati della sequenza dei Ns0, si possono ricavare anche i parametri to=, fromsection=, tosection= :-) oltre che i parametri prec= e succ= :-) :-)

... ed ecco i quattro dati "ridistribuiti" a creare parte della pagina testuale!
. Analogamente, se ci sono "in giro" tag section, ricostruisco i parametri fromsection e tosection; e i parametri prec= e succ= di IncludiIntestazione li ricavo dal Ns0 precedente e successivo a quello corrente... facile no? ;-) --Alex brollo (disc.) 16:56, 13 lug 2010 (CEST)

Template {{nota}}

Segnalo, per i più appassionati di "strane cose alexbrollesche", il nuovo {{nota}}, che crea un meccanismo alternativo a ref per le note. Lo vedete in azione in Il corsaro/Note e nelle pagine Pagina sorgente. Che ve ne pare? --Alex brollo (disc.) 06:59, 23 ago 2010 (CEST)

Buono. --Demart81 (Comunicazioni, insulti ecc.) 15:47, 25 ago 2010 (CEST)

Soluzioni a un problemuccio di transclusione

Immaginate di avere, in una pagina, un pezzo di testo che NON volete che sia transcluso insieme al resto del testo, ma che volete trascludere da un'altra parte.

Certo potete marcarlo con una section, marcare il resto del testo con un'altra section, e trascludere selettivamente. Ma... questo rende fastidiosissimo l'uso di pages index; perchè se la pagina in cui avviene il "fenomeno" è a metà di una sequenza, pages si rifiuta di trascludere solo una section di quella pagina. Nè funziona il trucco: "metto due tag noinclude attorno al testo e all'interno metto una section, e poi trascludo la sola section". Provate! Niente da fare: una volta che un testo è marcato con noinclude, NON verrà transcluso. Non esiste più, per il software... nemmeno la section interna, esiste più.

Tocca spezzare il tag pages, e farlo finire, e reiniziare, ogni volta che si incappa nella cosa. Ma bisogna farlo a mano, e ricordarsene.

Però.... osservate questo codice: da mettere in nsPagina:

<includeonly><div style="display:none; "></includeonly>

<span style="font-size:2.2em">LORD G. BYRON</span>


<includeonly></div></includeonly>

usato come test in Pagina:Poemi (Byron).djvu/3. Il testo "da far sparire" è racchiuso in una div style="display:none", e i tag della div sono a loro volta racchiusi dentro includeonly. Cosa accade? in pagina Pagina, i tag div sono "accoppati" da includeonly e non agiscono affatto; ma nel testo trascluso, ci sono eccome, e mascherano benissimo il testo che racchiudono. E' come se non fosse stato transcluso.... a meno che uno rovisti nell'html della pagina, dove il testo in realtà c'è; e c'è anche se uno tenta un copiaincolla dall'HTML; ma in visualizzazione, no, non ce n'è alcuna traccia. --Alex brollo (disc.) 07:30, 25 ago 2010 (CEST)

Applicazione pratica del trucco di cui sopra

La creazione di una div style="display:none" consente una via alternativa (forse che è la volta buona?) alla "semantizzazione" dei template fondamentali. Infatti, l'anno di pubblicazione di Poesie (Carducci) è 1906; l'autore è Giosuè Carducci; e dispone di versione immagine come potete vedere dando un'occhiata al codice del messaggio, il valore 1906 viene prodotto da questo codice, abbastanza intuitivo:

{{#section:Poesie (Carducci)|Anno di pubblicazione}}

. Che ve ne pare? Tenete conto che la "zona dati invisibile" della pagina Poesie (Carducci) viene generata da un algoritmo "generalizzato" che funziona non solo con il particolare template Intestazione, ma con qualsiasi template (tranne trabocchetti); in ogni caso, viene generata una "batteria di section" ognuna delle quali di chiama esattamente ciascuno dei parametri del template, oppure si chiama 1,2,3... nel caso che i parametri siano "senza nome". L'algoritmo (finora) si è dimostrato "robusto", non lo bloccano piccole differenze tipo acapi, spazi ecc. --Alex brollo (disc.) 23:26, 24 set 2010 (CEST)

Semantizzazione: il punto della situazione

Alcune discussioni in wikitech-I mi hanno convinto che Semantic MediaWiki è una bellissima cosa... "bella e impossibile": non c'è aria che la implementino dei progetti wiki. Io quindi adrei avanti con l'idea accennata nel paragrafo sopra: semantizzare per conto nostro, con #lst. Il principio è molto interessante: come sa chi mi ha seguito in test meno maturi, semantizzare significa: "disporre via template di qualsiasi dato collegato a un autore o a un'opera". Esempio di questi giorni: "Visualizzare col solo template Testo di un'opera, senza parametri, il suo autore, la data di pubblicazione e il suo tipo (testo "naked" o testo "proofread").

Io comincio con prove pratiche! --Alex brollo (disc.) 09:04, 9 ott 2010 (CEST)

Semantizzazione: si comincia

Ci siamo, sta per partire la Alebot SemanticSource. ;-) E' pronto uno script che aggiunge alle pagine principali Ns0 una "area dati", invisibile tranne che in edit; in edit compare inclusa in messaggi html minatori, spero efficaci. Potete vedere la cosa in azione in Il giaurro.

Dal momento in cui esiste tale area dati, ognuno dei parametri del template Intestazione può essere recuperato via tranclusione selettiva definita dall'utente, oppure da una transclusione selettiva "mascherata" dentro un template. Ovviamente, ad ogni modifica dell'utente Alebot controllerà, ed eventualmente sincronizzerà, i corrispondenti dati.

La stessa identica cosa verrà implementata per Autori, eliminando senza pietà la precedente versione che aveva delle limitazioni nel numero, tipo, lunghezza dei dati. Questa implementazione non ne ha.

Ognuno dei dati si "chiama" esattamente come il nome del parametro.

Quindi, i codici:

• {{Dato|Il giaurro|Nome e cognome dell'autore}} produce George Gordon Byron
• {Dato|Il giaurro|Anno di pubblicazione}} produce 1813
• {{Dato|Il giaurro|Progetto}} ({{Dato|Il giaurro|Argomento}}) produce Letteratura (Poemi)

eccetera, eccetera. :-) --Alex brollo (disc.) 14:55, 9 ott 2010 (CEST)

Qual'è la data di nascita dell'autore di I promessi sposi? Facile: è ! :-)

La battaglia di Centrato

Dura! Sanguinosa! Ma forse... Avrete notato un ostinato, e bizzarro, comportamento di {{Centrato}}, che infilava quando voleva delle indentature nel testo centrato, ma solo qualche volta... non sempre nei vari namespace, e non in ogni riga. Eppure il codice css di Commons.css era identico a quello di fr.source... e non funzionava; se lo si metteva nel proprio css utente, funzionava... Sono mesi che ci sto dietro; la battaglia è stata simile a quella contro poem... ebbene, forse ho trovato l'astruso busillo; il codice css era esatto, ma messo nell'ordine sbagliato.... era messo prima del codice della classe pagetext la cui definizione lo "rullava". :-( è bastato "tirare su" il codice della classe .pagetext (quella che determina lo stile delle pagine Pagina) e il problema, nel nsPagina,si è dissolto. Almeno spero.

---

Questo è centrato sulla pagina... :-)

---

---

Questo è centrato in uno spazio di 50em... :-)

---

---

Questo è centrato in uno spazio di 25em... :-)

---

--Alex brollo (disc.) 07:33, 22 ott 2010 (CEST)

News da toolserver

Sono dentro toolserver! :-)

Adesso si tratta di studiare e pensare; pensare e studiare; poi provare, pensare e studiare in tutte le combinazioni.

Ecco alcune cose che ho a disposizione:

1. uno spazio web pubblico per pagine statiche e dinamiche;
2. accesso ai database wiki (i loro "cloni");
3. possibilità di lanciare bot python.

Per ora mi concentrerò sui punti 1 e 2; poi ci sarà una base intermedia in cui suppongo di costruire tabelle parallele a quelle originali di wiki, con i famosi "dati semantizzati", e costruzione di una specie di interfaccia per interrogare il tutto via pagina web esterna a wiki; altra fase, possibilità di interrogare tali dati da wiki via bot; ultima fase, lancio di programmi in grado di modificare pagine wiki (fase molto delicata).

Appena possibile, in via transitoria attendendo soluzioni migliori, potresti aggiornare con gli script di Pietrodn alcune pagine sospettosamente quiescenti come Template:Conteggio testi SAL? εΔω 22:54, 1 nov 2010 (CET)

Seeee... domani :-D. Se sapessi che problemucci devo affrontare prima... piuttosto, guiderò per prova gli script di BimBot da Alebot (non da toolserver) per vedere cosa combinano. Quasi quasi comincio a capirli. --Alex brollo (disc.) 16:49, 2 nov 2010 (CET)

Help needed: toolserver, l'avventura comincia davvero

Spezzate varie barriere (so come lanciare Alebot da toolserver) adesso il gioco si fa duro, e la difficoltà è quella di darsi una strategia e di cominciare.

Ho un gran bisogno di aiuto da:

1. chiunque sappia programmare per bene in python;
2. chiunque abbia familiarità con l'interfaccia testo di Unix.
   1. Che text editor usare: va bene Nano?
   2. Chi mi aiuta con bash?
   3. Qualcuno ha esperienza pratica di cron?
   4. Qualcuno ha esperienza pratica del matrimonio php-python?
   5. Qualcuno ha maneggiato php-mySQL, oppure php-python-mySQL?
3. in generale, per non fare un immane casino:
   1. è opportuno lavorare direttamente in toolserver nell'editing/test degli script python?
   2. è opportuno lavorare invece in locale, e poi esportare gli scirpt rodati in toolserver via pftp?

Queste sono solo le prime domande. :-) --Alex brollo (disc.) 15:43, 15 nov 2010 (CET)

Nano secondo me è meglio di vi, che è assurdamente unfriendly. Per il resto, non saprei dirti... all'inizio comunque forse è meglio provare in locale, se hai paura di far troppi danni.. --Aubrey McFato 09:22, 16 nov 2010 (CET)

Infatti, ho avuto la netta impressione che il nome di vi derivi dall'esclamazione, che io ho rivolto ai suoi creatori, "Vi possino....". Risolto, grazie. --Alex brollo (disc.) 11:57, 17 nov 2010 (CET)

Opere in pubblico dominio pubblicate dopo il 1923

Non riesco a trovare una indicazione se un libro del 1930, di un autore morto nel 1911 (Salgari) può essere scannerizzato e utilizzato per la trascrizione, oppure è necessario trovare un libro pubblicato prima del 1923? Nel caso non sia scannerizzabile è utilizzabile almeno come fonte cartacea, cioè lo trascrivo a casa? --Luigi62 (disc.) 11:26, 17 nov 2010 (CET)

In questo bar non ci viene nessuno: è "tecnico" in senso di "informatico" :-). Meglio mettere la domanda in bar generale, se non ti viene risposto subito (al momento la tua domanda mi lascia confuso; mille volte ne parliamo, mille volte me ne dimentico qualche dettaglio...) --Alex brollo (disc.) 11:55, 17 nov 2010 (CET)

"Blocchi" di testo spezzati fra due pagine: la soluzione generale!

Per capire bene quello che dirò occorre qualche nozione di html; in particolare, occorre avere un'idea di cos'è un "elemento blocco" in html.

Sono "elementi blocco" quegli elementi che racchiudono il contenuto in un rettangolo virtuale di spazio pagina. I più comuni sono l'elemento div e l'elemento p. Ma noi usiamo moltissimo anche gli elementi lista e anche le tabelle.

Tutti gli elementi blocco hanno caratteristiche comuni, che derivano dal fatto di essere uno spazio rettangolare dotati di un margine (margin), di un bordo (border), di uno spazio fra bordo e contenuto (padding), di uno sfondo (background). Tutti hanno la caratteristica che non possono essere aperti e chiusi all'interno di un paragrafo: il tentativo di farlo, inevitabilmente, "spezza" il testo e crea almeno un ritorno a capo.

Il markup wiki ha parecchi automatismi per rendere l'utente del tutto ignaro della presenza, posizione e funzionamento di questi elementi:

1. l'elemento div è generalmente mascherato dentro il codice di template;
2. l'elemento p è generato automaticamente da un doppio a capo;
3. gli elementi lista sono mascherati dai codici a inizio riga: * # : ;

Un "trucco" per visualizzare gli elementi blocco è quello di inserire esplicitamente il codice html e assegnare un bordo visibile.

Esempio: questo è un paragrafo in cui i tag p sono stati scritti esplicitamente e al p di apertura è stato assegnato un bordo rosso punteggiato da 1 pixel.

Questo invece è un elemento-lista (tag dd contenuto in un tag dl)che simula l'uso del codice : a inizio riga (notate il rientro del blocco a sinistra:lo riconoscete?), a cui è stato assegnato un bordo punteggiato verde.

Questo infine è un elemento div della larghezza di 200 pixel, con un bordo punteggiato blu, e centrato nella pagina.

Il normale pediano non ha alcun bisogno concreto di sapere queste cose. Quindi nessuno le spiega; sono argomenti per iniziati.

Il normale sourciano, che usa il nsPagina e poi transclude, invece ci si intoppa, e le cose sono messe in modo che disintopparsi richiede ignobili trucchi.... o la comprensione a fondo di cosa succede. Infatti, c'è un punto in cui "casca l'asino": la fine di una pagina Pagina, e l'inizio della successiva, nel caso in cui un paragrafo sia metà sulla pagina precedente, metà sulla successiva. Quando il paragrafo è "normale", non succede nulla, quando il paragrafo "non è normale", o invece del paragrafo, ci sia un altro tipo di blocco (es. un blocco lista: cosa comunissima nei testi teatrali) il codice wiki si imbizzarrisce, e produce anomalie-rompicapo; la più comune, il paragrafo viene spezzato in due in transclusione, perchè è stato aggiunto un acapo che resiste a ogni ragionevole tentativo di eliminazione. La causa di queste bizzarrie è che il software wiki chiude automaticamente, alla fine della pagina, tutti i blocchi aperti; e soprattutto, se chiude un blocco di qualsiasi tipo, chiude anche il paragrafo di testo che il blocco contiene. Blocco paragrafo chiuso = a capo inevitabile fra la parte delparagrafoche sta nella pagina, e la parte che sta nella successiva.

La soluzione? c'è, ed è unica e comune a tutti gli elementi blocco. :-)

Essa consiste in questa semplice regola: per evitare che il software chiuda automaticamente elementi blocco lasciati aperti, apriteli voi stessi con i tag html espliciti (non con il markup!) e chiudeteli con i normali tag di chiusura, sistemati però nella zona footer della pagina. Nella pagina successiva, riaprite un nuovo elemento blocco, ma con codice sistemato nell'header. Effetto: il software wiki è soddisfatto di veder chiusi tutti i blocchi aperti e non fa niente. In tranclusione, trasporterà dalla pagina precedente solo i tag di apertura, e dalla successiva solo i tag di chiusura; creerà, cioè, un blocco unico, a cui verranno per forza applicati tutti gli attributi previsti nel tag di apertura! fate qualche esperimento, tutti quelli che ho fatto io funzionano a colpo sicuro. Tranne poem, che NON è un tag html! --Alex brollo (disc.) 20:38, 29 dic 2010 (CET)