Wikisource:Domande tecniche

Da Wikisource.
Domande tecniche
il punto d'incontro e discussione tra geek e niubbi!
archivio
Filing cabinet icon.svg
2015
2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021

Nuvola filesystems folder blue open.png Categoria: Domande tecniche Bar  Nuvola apps noatun.png Domande tecniche 

Pagina dedicata a domande sul software, sulla struttura organizzativa del progetto, sulla visualizzazione e i bug dei browser. Le comunicazioni Tech News verranno ricevute su Wikisource:Domande tecniche/Tech News.



Indice

Tech News: 2014-01[modifica]

09:47, 30 dic 2013 (CET)

Tech News: 2014-02[modifica]

09:34, 6 gen 2014 (CET)

Ipotesi shortcut.js[modifica]

Sto provando Utente:Alex brollo/shortcut.js, funzione che consente di attivare shortcuts di tastiera con risultati abbastanza simili a Chrome Shortcut Manager - ma con il vantaggio che non è un software legato a Chrome.

Lo script è questo: http://www.openjs.com/scripts/events/keyboard_shortcuts/index.php

Attivato lo script, attivare una shortcut è semplice; il primo parametro è il tasto o combinazione, il secondo è la funzione che viene attivata dal tasto o dalla combinazione. Un terzo parametro, opzionale, consente di specificare opzioni varie.

Esempio: shortcut.add("Alt+9", function () {alert("E' stata premuta la combinazione ALT+9")});

La mia vittima designata, per i test, sarà Stefano Mariucci alle prese con Tartaglia :-) ma penso che Barbaforcuta si associerà all'impresa. --Alex brollo (disc.) 15:38, 6 gen 2014 (CET)

Funziona. Preso atto che le combinazioni di tasti Alt+0....Alt+9 sono tutte libere, faccio un esperimento: collego a queste combinazioni, nell'ordine della tastiera, da Alt+5 a Alt+0, gli "strumenti per la rilettura" che suggerisco di lanciare, nell'ordine, su una pagina da OCR standard. Man mano aggiungerò al nome della funzione la combinazione attiva. shortcut() sta in MediaWiki:Gadget-common.js, quindi se uno vede gli --Strumenti per la rilettura "vede" anche la funzione. --Alex brollo (disc.) 19:57, 8 gen 2014 (CET)
Abilitata la funzione shortcut per alcuni strumenti per la rilettura. Si tratta dei tool che nella maggior parte dei casi possono essere lanciati su una pagina con un buon OCR (tipo quello da IA) per "dare una ripulita": eliminare la prima riga che contiene pattume di intestazione pagina; aggiustare i paragrafi; ripulire da piccoli errori tipici dell'OCR; riunire il testo delle righe; aggiungere RigaIntestazione. Tutte queste funzioni (che sono tool vecchi, Aubrey!) adesso si possono chiamare anche con una combinazione di tasti Alt+5.... Alt+9, oltre che con il click del mouse. Due piccole modifiche: RigaIntestazione adesso funziona in un solo modo (quello chiamato anche dal bottone autoRi); anche postOCR richiama la stessa funzione. Prossimo passo, la revisione di AutoreCitato e l'eliminazione delle varianti. --Alex brollo (disc.) 22:22, 9 gen 2014 (CET)

Giocando con inherit[modifica]

Essendomi stato vietato di produrre nuovi tool, ho giocato un po' con il css (per alleggerire il codice delle tabelle).

Ho quindi inserito in MediaWiki:Common.css la seguente riga:

/* permette di registrare in un tag tr bordi e allineamento del testo che poi si propagano alle celle 
della riga */
.donor td, .donor th {border:inherit;text-align:inherit;}

che "propaga" eventuali proprietà di stile (NON attributi del tag html!) assegnati a una riga a tutte le celle figlie, se alla riga viene assegnata la classe "donor". Per ora le proprietà "donate" sono solo border e text-align, ma se ne possono aggiungere altre; questo semplifica il codice delle tabelle quando occorrerebbe assegnare a tutte, o a molte celle uno stile diverso da quello di default. Un esempio di applicazione nella tabella, suggerita da Barbaforcuta, qui (in questa versione della pagina il codice è stato usato solo nella seconda sotto-tabella, nelle successive sarà esteso alla terza e quarta) --Alex brollo (disc.) 08:26, 9 gen 2014 (CET)

(te l'ho vietato solo nel l'ambito della ricognizione della pagine di Aiuto, ma mi piace moolto questa cosa che mi hai preso sul serio: mettere a posto i tool precedenti è sicuramente utile per tutti, come fare pulizia di quello che non serve). Aubrey (disc.) 23:11, 9 gen 2014 (CET)
Chiaro.... spero solo di fare pulizia in fretta e bene prima che le pagine di aiuto nominino i tool/i gadget. --Alex brollo (disc.) 00:32, 10 gen 2014 (CET)

Semplificazioni[modifica]

Dalla cronologia di MediaWiki:Variabili.js osservo che da molti mesi sono io l'autore delle modifiche. Ciò significa che quella prcedura è, in sostanza, inutilizzata e può essere archiviata. Ugualmente, ritengo che sia archiviabile tutta la gestione dei "datiPagine" e della gestione dei cookie per la loro memorizzazione; tutti le procedure correlate possono essere sostutuite da altre, e alcune sono già atste sostituite (es. l'automazione di RigaIntestazione). L'intero insieme di funzioni correlate ai cookie può essere rimosso.

Fatta pulizia, eventualmente si possono ricostituire funzioni eventualmente utilizzate con altri metodi: Wikidata, blocchi di dati Lua o JSON, localStorage. A pulizia finita, attenderò i "lamenti" degli utenti che eventualmente usano (silenziosamente....) uno di questi trucchi e ne sentono l'improvvisa mancanza. --Alex brollo (disc.) 09:16, 10 gen 2014 (CET)

Mi pare una buona idea. Mentre fai pulizia, però, segna, in una tua pagina utente o in una pagina di aiuto, ciò che hai messo via, è importante. Magari in un secondo momento riscopriamo quello che hai fatto. Sai bene che non tutti (io no) ti stanno dietro, per cui capita che un tool molto interessanti sia semplicemente "non visto". un posto unico in cui ci sono i tuoi strumenti (non tutti, quelli più grossi) sarebbe utile. --Aubrey (disc.) 10:09, 10 gen 2014 (CET)
Grazie del suggerimento, per ora accumulo almeno gli script che elimino. Prossimo passo, pulizia dei due diversi tool per AutoreCitato e sostituzione con il nuovo tool che (nei test che ho fatto) fa che è una meraviglia e, come dicevo, "lavora" per similitudine e non per uguaglianza e gestisce le omonimie/similitudini presentando un elenco da cui scegliere con un click. --Alex brollo (disc.) 08:19, 11 gen 2014 (CET)
Inserito in MediaWiki:Gadget-common.js richiamo a Utente:Alex brollo/autoreCitato.js]] preliminare alla eliminazione dei vecchi tool. Fa comparire in bottoniera un pulsante selAut (Selezione Autore) --Alex brollo (disc.) 09:28, 11 gen 2014 (CET)
È merito delle tue semplificazioni che postOCR cambia RigaIntestazione anche se già esiste? Anche "virgolette" sembra non funzionare più. --Luigi62 (disc.) 20:51, 11 gen 2014 (CET)
Sì; questo è sempre stato il comportamento di "autoRi". In effetti può essere un problema (anche se nel mio "stile di lavoro" non mi ha mai infastidito). La semplificazione comporta che appena correggerò la funzione, cosa che tento di fare immediatamente, la correzione sarà "generalizzata".
Virgolette non l'ho toccato; verifico. --Alex brollo (disc.) 17:53, 12 gen 2014 (CET)
Sistemati entrambi; la semplificazione comporta anche.... che mettere le mani sugli script è un pochino più semplice :-) Alex brollo (disc.) 18:09, 12 gen 2014 (CET)
autoRi proprio non funziona più. Virgolette ora funziona, ma come si fa a cambiare il tipo di virgolette da utilizzare come standard? --Luigi62 (disc.) 00:32, 14 gen 2014 (CET)
Ehi, manco un paio di giorni e vedo fibrillazioni. :-) Una pulizia credo sia necessaria. L'idea di accorpare gadget-common e regex è ottima; sul datiPagine mi ricordo fosse utile, ma non lo uso da un po' (se può essere egregiamente sostituito da altro ben venga). Sarebbe utile avere un accorpamento di alcuni gadget (vedi i 5 che aggiungono la numerazione dei versi, forse superati da qualche marchingegno in Lua).--Barbaforcuta (disc.) 12:02, 14 gen 2014 (CET)
Ah io accorperei anche gadget-tools ai due precedenti, così d'avere tutte le funzioni utili in un'unica pagina.--Barbaforcuta (disc.) 12:18, 14 gen 2014 (CET)
Grazie Luigi62, in effetti avevo infilato un banale errore logico per correggere il comportamento che mi avevi segnalato.... purtroppo sto trascrivendo un testo che non usa rigaIntestazione e non ho avuto occasione di accorgermene. Per le virgolette: non ho ancora trovato un giusto compromesso fra semplicità e elasticità.... datiPagine era troppo complicato. Che virgolette ti servirebbero? --Alex brollo (disc.) 20:04, 14 gen 2014 (CET)

Tech News: 2014-03[modifica]

10:33, 13 gen 2014 (CET)

Maledetti apostrofi[modifica]

Da una nota di Accurimbono, ho ripreso in mano la questione Virgolette() e ho di nuovo maledetto gli apostrofi. I caratteri «...» “...” 〈...〉“...„ „...“ vanno tutti bene ma.... ‘...’ pianta lo script. Il motivo è presto detto: per il carattere di chiusura dell'ultima combinazione si usa lo stesso carattere Unicode 8217 che si usa per l'apostrofo tipografico; il che significa, conflitto fra script virgolette e script di tipografizzazione degli apostrofi. Non riesco quindi a estendere lo script Virgolette() a quest'ultimo caso :-(.

Se invece volete farvi un bottone che use altre coppie di virgolette, lo schema della funzione funzionante è questo (sostituite ai caratteri virgolette «» quelli che vi servono)

newButton("«»", Virgolette("«","»")","es","Virgolette");

--Alex brollo (disc.) 08:44, 16 gen 2014 (CET)

@Alex brollo: qual è il problema? --Ricordisamoa 21:36, 17 gen 2014 (CET)
Il problema è che non è possibile riconoscere, se non con una analisi del contesto che temo impossibile da automatizzare, quali sono apostrofi e quali sono invece virgolette di chiusura; e se non lo capisco, non posso correttamente appaiare le coppie virgoletta aperta-virgoletta chiusa. Pazienza; vuol dire che i pochi casi in cui si usano le virgolette semplici si faranno "a mano". --Alex brollo (disc.) 21:46, 17 gen 2014 (CET)

Tech News: 2014-04[modifica]

11:21, 20 gen 2014 (CET)

Wikidata: API e Lua[modifica]

Ho trovato delle funzioni Lua per ricevere dati da wikidata; ho provato un po' l'API di wikidata ma con scarso successo. Infine ho trovato menzione di una funzione parser #property senza riuscire a trovare uno straccio di doc. Dove cerco? --Alex brollo (disc.) 18:48, 22 gen 2014 (CET)

Da qui: http://www.mediawiki.org/wiki/Extension:Wikibase_Client/Lua ho importato il codice per il modulo Lua Modulo:Wikibase dopodichè ho testato un esempio:
* ID: {{#invoke:Wikibase|id}}
con il seguente risultato:
  • ID: (no item connected)
La cosa non mi soddisfa. Dove sbaglio, cosa manca? Vado a vedere come sono su wikipedia. --Alex brollo (disc.) 09:55, 23 gen 2014 (CET)
Alex, da quello che diceva Ricordisamoa qui, mi pare di capire che il modulo Wikibase non funzionerà fino a che non attivano la Fase 2 (Lydia diceva qualche giorno fa che ci sarà da aspettare almeno 1 mese). Candalùa (disc.) 11:28, 23 gen 2014 (CET)
@Ricordisamoa:Come temevo. Ricordisamoa, mi metteresti qui un paio di query API funzionanti su wikidata, che diano un risultato utile per noi? Vorrei provarle di là, e poi vedere se riesco a trasformarle in chiamate Ajax via JSONP. Ho provato qualche query API su wikidata ma non ho avuto i risultati sperati. Chiedo a ricordisamoa perchè è stato citato, ma ovviamente chiedo a tutti color che sanno.... :-) --Alex brollo (disc.) 11:59, 23 gen 2014 (CET)
Alex, non so se può esserti di aiuto, ma considera che su it.wiki la fase due è già attiva, per cui se sei impaziente puoi sperimentare si it.wiki! ;) --Accurimbono (disc) 12:16, 23 gen 2014 (CET)
Grazie.....sì, ho già provato là il loro w:modulo:Wikidata, e ho già verificato che là funziona e qui no. Aspetto.... ma nel frattempo vorrei dedicarmi alla APIcultura e non avrò pace finchè non romperò il ghiaccio. Curioserò nel codice di pywikibot, qualche richiesta API dovrei trovarla... --Alex brollo (disc.) 13:53, 23 gen 2014 (CET)
Trovato! action=wbgetentities in mediawiki :-) --Alex brollo (disc.) 14:53, 23 gen 2014 (CET)
Qui il primo script js che da qua legge là. Lo farò partire all'apertura di una pagina Autore sbattendo i dati in localStorage; poi se si vuole si usano. --Alex brollo (disc.) 15:28, 23 gen 2014 (CET)
Come al solito.... ho scoperto la ruota :-)
Avendo montato e attivato MediaWiki:WikidataLink.js, quello che fa comparire il link "Wikidata" in sidebar, in $("body").data("wikidata") c'è un sacco di roba; in pratica un ottimo estratto di tutti i dati della "entity". Non solo: i dati sono caricati sia in view, che in edit, quindi sono accessibili a javascript intanto che si edita. Chissà, forse sono anche presenti al momento della creazione di una nuova pagina Autore... adesso verifico. --Alex brollo (disc.) 22:03, 23 gen 2014 (CET)
Confermo: sono tutti già presenti al momento della creazione di una nuova pagina Autore. In pratica, il form Autore, nei casi in cui viene agganciata un'entità wikidata, potrebbe autocompilarsi. I dati son, ma chi pon mano ad essi? Questo fa il paio con la possibilità - conosciuta da pochi - di leggere qualsiasi dato e lanciare qualsiasi API su qualsiasi progetto da qualsiasi altro progetto wiki.... segreti ben costoditi nelle mani di pochi. :-( --Alex brollo (disc.) 09:21, 24 gen 2014 (CET)

@Alex brollo: converrà usare Lua invece delle funzioni parser (che non supportano bene asserzioni multiple e fonti); vorrò vederti all'opera nello sviluppo di Modulo:Autore! ;-P --Ricordisamoa 22:51, 5 feb 2014 (CET)

@Ricordisamoa: ho rovistato qui] e mi sono studiato un po' l'orrido oggetto restituito da wikidata. Sono un pochino impressionato dalla quantità di letture a wikidata per tradurre le entità restituite per solo ID all'interno dell'oggetto.... toccherà ridurle un poco con un dizionario locale, almeno per le più comuni; altrimenti si fa notte. In effetti, il tempo che wikidata sta per aprire la pagina di una entity dà l'idea dell'enorme lavoro server che ci sta dietro. Speriamo bene.... ecologicamente parlando questa enorme circolazione di dati mi spaventa un pochetto come "impatto energetico".--Alex brollo (disc.) 00:42, 6 feb 2014 (CET)
@Alex brollo: al momento solo l'item corrispondente alla pagina che richiama il modulo è accessibile interamente; da' anche un'occhiata a WP:DWAP. --Ricordisamoa 14:49, 6 feb 2014 (CET)
@Ricordisamoa: DWAP? Adesso mi preoccupo il doppio: oltre alle risorse energetiche e informatica da performance/da banda/da tempo server, mi rendo conto che a ciò devo pure aggiungere la preoccupazione sulle risorse umane e finanziarie per pagare gente che risolve i problemi che io creo.... quanto a item corrispondente alla pagina che richiama il modulo aimè trovo il concetto oscuro peggio di una closure :-( --Alex brollo (disc.) 16:14, 6 feb 2014 (CET)

Esercizio wikidata[modifica]

Mi sono costruito il primo gadget personale su wikidata (giusto per studiare un po' il progetto). In sidebar su wikidata, mi compare uno strumento "Esporta su source" (da usare sugli autori che su wikidata ci stanno, ma su source non ci stanno ancora). Funziona così: dalla pagina wikidata della persona si clicca. Tutto qua.

Dopo cliccato, wikidata si chiude da sè e al suoposto si apre la pagina di creazione del nuovo autore (o di edit, se l'autore c'è) su source. Tutte le proprietà sono "trascinate dietro" nell'URL, pronte a essere infilate, una a una, nel form Autore di Candalua, o usate per la verifica dei dati esistenti. Qui mi sono fermato, perchè da questo punto in poi le cose sono molto più facili; mi domando se val la pena andare avanti e se magari possiamo approfittarne per caricare qualche dato aggiuntivo (tipo i codici del "controllo di autorità" VIAF ecc). --Alex brollo (disc.) 01:02, 25 gen 2014 (CET)

Comincio a capire qualcosa di wikidata. In particolare, comincio a capire perchè le pagine delle entità (apparentemente con "quattro dati") sono pesantissime, e ci mettono vari secondi per essere caricate. Per capirlo, basta studiare l'oggetto $("body").data("wikidata") che invece viene caricato in un attimo - i dati ci sono, ma ognuno dei dati (perlomeno la maggior parte) è solo un ID che punta a un'entità; ci vuole per ognuno un'altra lettura al server, per "agganciare" il valore, come visto dalla lingua corrente; perchè in realtà ad ogni entità sono associati numerosissimi "nomi", uno per lingua.
Questo spiega anche perchè mi sono deciso ad abbandonare l'analisi di $("body").data("wikidata") e dirottare l'attenzione sulla pagina wikidata dell'entità: in quella pagina, tutti i dati sono già stati collegati al loro valore, nella lingua desiderata, e sono pronti per essere utilizzati.
Un esempio per i "mezzi geek", i geek veri lo sanno già. Sotto Chrome, vado su Autore:Alessandro Verri e apro la console javascript. Scrivo $("body").data("wikidata") per "vederlo", e ci navigo dentro. Trovato l'ingresso all'oggetto, Q780989, apro i claims e trovo che P21 ha come valore un item wikidata Q6581097. Un dato bello, pulito e verificato, ma.... del tutto incomprensibile. Diventa comprensibile se leggo due volte wikidata e scopro che P21 è la "proprietà" sesso, e Q6581097 è il suo valore in questo caso, ossia maschio. Questo è quel che ci serve.... possiamo caricare il valore, o leggerlo ogni volta su wikidata; penso che la prima soluzione sia più rapida, per ora.
Prossimo passo: ficcare in localStorage un dizionario delle entità wikidata più comuni (a partire dalle "proprietà", come P21), in modo di averlo sottomano e di dover leggere solo quelle sconosciute. --Alex brollo (disc.) 15:19, 25 gen 2014 (CET)
✔ Fatto Caricato un dizionario di tutte le proprietà generiche e di quelle specifiche per persone e opere (letteratura). Ci aggiungerò le entità collegate, scegliendo quelle con un numero ragionevole di valori (sesso, professione, forse stato di nascita); il numero di letture da fare per completare la decodifica penso si sia ridotto parecchio (la decodifica non serve per parecchi tipi di valori). --Alex brollo (disc.) 16:38, 25 gen 2014 (CET)
Alex, non ti fermerò certo dallo studiare Wikidata, ma ricordati che fra un mese o poco più ci sarà l'integrazione direttamente con i singoli statements. Questo vorrà dire che potremmo sempre avere un template {{Autore}} (in Lua, idealmente) sulle nostre pagine autore, e quel template sarà fatto in modo da richiamare, da Wikidata, i dati che vogliamo. Ora, questo vorrà dire che, in quelche modo, noi dovremmo prima mettere su Wikidata i dati da wikisource, e questo si fa sempre via bot. Cioè, dovremo importare tutti i dati biografici che possediamo e metterli direttamente là sopra. Se vuoi studiare questa cosa, sarà secondo me enormemente utile. Puoi chiedere lumi anche a @Ricordisamoa: e @Candalua:, sono gli unici utenti italiani che conosco che hanno il bot là sopra. Aubrey (disc.) 16:52, 25 gen 2014 (CET)
Ho dato un'occhiata sia al tag magico {{#property}} che alle funzioni Lua per accedere ai dati; so bene che questa "esplorazione" è solo conoscitiva... ma sono qui, sostanzialmente, per divertirmi e questa esplorazione mi diverte :-) --Alex brollo (disc.) 18:00, 25 gen 2014 (CET)
@Alex brollo: non vale la pena di prodigarsi nell'uso dei dati adesso, dovremo piuttosto migrarli tra un mesetto, a favore di quelli già presenti su Wikidata, di certo più completi e aggiornati Gnome3-wink.svg --Ricordisamoa 22:21, 5 feb 2014 (CET)

Soppressione di dehyphen()[modifica]

Non so chi ha inserito dehyphen() in Common.js, ma alla prima pagina in versi che ho creato mi sono precipitato a sopprimerla sostituendola con il codice dentro cleanup(), che unisce solo le righe hyphenate (che per definizione non esistono nelle opere in versi tranne eccezioni di cui non ricordo nemmeno un caso). Meglio sarebbe non replicare il codice di cleanup(), ma fare in modo che sia il pulsante/il link che la chiamata automatica attivino lo stesso script per rispettare il sacro principio If you are repeating yourself, you are going wrong. Un principio che fa un po' ridere in MediaWiki dove le cose vengono ripetute millantadue volte ciascuna.... ma tant'è. :-)

In generale, suggerirei di rimandare quanto più possibile l'unione delle linee anche nelle prose, perchè ostacola il confronto con il testo a fronte e non comporta il minimissimo vantaggio nella resa html --Alex brollo (disc.) 16:38, 26 gen 2014 (CET)

Tech News: 2014-05[modifica]

10:46, 27 gen 2014 (CET)

Lua + lst[modifica]

Mi domando: che accade passando a Lua come parametro il risultato di un una chiamata #lst? Proverò; ma visti vecchi esperimenti ritengo - per questioni di priorità - che gli venga passato il risultato di #lst; e se tale risultato fosse un oggetto tipo JSON, allora... si aprirebbe un nuovo capitolo della nostra source altamente semantizzata.  :-) --Alex brollo (disc.) 07:27, 29 gen 2014 (CET)

Tech News: 2014-06[modifica]

09:30, 3 feb 2014 (CET)

Domande su Labs[modifica]

@Candalua: @Ricordisamoa: ... e ad altri eventuali frequentatori di Labs:

  1. che strumenti sono disponibili sul server per l'elaborazione di immagini? C'è ancora ImageMagick? Altri?
  2. esiste nconvert (che è quello che uso io nel mio povero pc vintage)?
  3. dovendo estrarre le immagini da un file xxx.pdf trasformandole in jpg oppure tiff dentro una cartella chiamata out, sapreste darmi una ricetta indicativa o dirmi dove c'è la doc per studiare l'applicazione di elaborazione grafica?
  4. tale applicazione, che voi sappiate, potrebbe eseguire anche uno split dell'immagine estratta dal pdf? --Alex brollo (disc.) 00:06, 5 feb 2014 (CET)
Giusto per notificarvi i lavori in corso: ho ripreso in mano nconvert e python, e vecchi tool abbandonati; il risultato è che ho un file python che acchiappa un file pdf OPAL (scansioni a doppia facciata) e restituisce il zip delle immagini jpg estratte dal pdf autocroppate e splittate pronte a essere caricate su Internet Archive (potrei farlo con immagini tiff, ma l'archivio risultante è quasi 10 volte più grande e vedo che le immagini jpg non danno un risultato schifido). La routine usa solo python (+PIL) e nconvert (l'applicazione batch di XnView). Bello sarebbe che questa cosa fosse trasformata in un tool su Labs, che magari, alla fine, si occupasse anche del caricamento su IA. --Alex brollo (disc.) 08:39, 5 feb 2014 (CET)
Mi pare una grandissima idea, dovresti magari parlarne con Tpt, che su labs ha ovviamente i suoi script. Ti nomino lui con reticenza perchè ha mille cose da fare, ma sarei il primo a godere di una suite di tool "Wikisource" su Labs, e mi piacerebbe avere le cose coordinate e nello stesso posto. --Aubrey (disc.) 09:45, 5 feb 2014 (CET)
Ho mandato in lista Labs una richiesta un pochino più generica, nel corso dell'eventuale discussione posso aggiungere "dove vorrei andare a parare". --Alex brollo (disc.) 10:44, 5 feb 2014 (CET)
@Alex brollo: su Tool Labs sono ancora un novellino, fai bene a chiedere ad altri ;-) --Ricordisamoa 03:26, 13 feb 2014 (CET)

Tech News: 2014-07[modifica]

10:30, 10 feb 2014 (CET)

Problema css[modifica]

In Drammaturgia di Lione Allacci/Tavola degli autori/A ho il problema di eliminare l'indentatura dei paragrafi che costituiscono le righe dell'indice. Il text-indent dovrebbe essere determinato dalla div class "eredita", ed in effetti il css è ricevuto dall'elemento, ma è "rullato" dal text-indent determinato da div class="testi". Perchè? Non capisco! L'unica idea che mi viene è che il css text-indent venga impropriamente caricato "dopo" in termini temporali per questioni di resource loader ... ma forse è una delle solite banalità che sfuggono a chi ci è dentro ma sono evidenti al primo che passa. Quindi, per favore... passate. :-(

PS: qualsiasi altro attributo css passato dalla classe "eredita" arriva regolarmente ai paragrafi.... text-indent invece viene rullato. --Alex brollo (disc.) 11:08, 12 feb 2014 (CET)

Per caso scopro che il tag p "stenta" a ereditare gli attributi della div class="eredita", ma un altro tag block come dd (generato dai due punti) li eredita benissimo, compreso il text-indent. La resa mi sembra buona... esploro questa strada, mi pare promettente (e abbastanza semplice semplice). --Alex brollo (disc.) 22:19, 12 feb 2014 (CET)

@Alex brollo:

/* direttiva !important, selettori più specifici */
div.eredita p,
div.eredita>p,
div.eredita.testi p,
div.testi div.eredita p,
div.eredita div.testi p
{text-indent:0!important}

Vai per tentativi. --Ricordisamoa 03:38, 13 feb 2014 (CET)

Aaaaahhh, adesso so chi stressare per poroblemi di css.... grazie, li proverò uno a uno; tuttavia il fatto che il mio settaggio funzioni con dd ma non funzioni con p mi rende un po' pessimista. Se veramente esiste un'interferenza "temporale" di caricamento dei file css via Resource Loader, con la conseguenza di rendere instabile/aleatorio il risultato, il problema sarebbe generale e grosso; ma sarebbe anche nettamente superiore alle mie capacità di descriverlo adeguatamente in Bugzilla.... in caso farò un fischio virtuale. --Alex brollo (disc.) 10:27, 13 feb 2014 (CET)

Dati nelle pagine autore[modifica]

All'inizio di ogni pagina nel namespace Autore trovo dei tag section (usati da LST). Non sono ridondanti ai dati presenti nel template {{Autore}}? --Ricordisamoa 06:18, 16 feb 2014 (CET)

No, perchè permettono di usare tali dati in qualsiasi pagina: "semantizzano" i dati. E' il nostro "wikidata fai da te"; sarà superato nel momento in cui da qualsiasi pagina si potrà ottenere qualsiasi dato relativo a qualsiasi autore (il che è diverso da visualizzare qualsiasi dato nella pagina Autore). Qualcuno mi ha fatto biezioni riguardanti la performance (LST non è ottimizzato come dovrebbe/potrebbe); ma adesso seguo il principio DWAP e non me ne curo ;-) --Alex brollo (disc.) 16:56, 16 feb 2014 (CET)
Il template Autore non potrebbe includere anche i tag "section" già compilati? --Ricordisamoa 23:38, 16 feb 2014 (CET)
No, non si può inserire il tag section in un template. Magari.... --Alex brollo (disc.) 00:23, 17 feb 2014 (CET)

Errore di categorizzazione alfabetica[modifica]

Ci sono obiezioni? --Ricordisamoa 06:27, 16 feb 2014 (CET)

Tech News: 2014-08[modifica]

09:38, 17 feb 2014 (CET)

Il magico mondo dei pixel[modifica]

Sto imbarcandomi in una nuova avventura: l'immersione nel "modo dei pixel", a basso livello (quello che serve per PIL e per l'uso avanzato di canvas). Il problema che finalmente m,i sento pronto ad affrontare è: data l'immagine di una pagina pdf OPAL (a doppia facciata, talora un po' "sbieca", che non copre l'inteera immagine perchè è stato fotografato anche un po' di "fondo") raddrizzarla in base alla linea della rilegatura e centrarla in base alla stessa linea in modo che un taglio verticale a metà immagine risulti perfetto. Non è facile; anche FineReader, che pure ha un sistema di riconoscimento delle doppie pagine ed è capace di dividerle automaticamente quando le riconosce, spesso con i libri antichi fallisce. Questo per ora mi ha costretto a ripassare anche statistica e trigonometria... e un pochino di neurofisiologia della retina. o_O

Ve lo dico per due motivi:

  1. c'è qualcuno esperto nella manipolazione delle immagini a basso livello, filtri, PIL ecc?
  2. esiste qualche programnma ad alto livello a cui affidare il compito di ruotare-centrare-splittare in batch, meglio di come lo sappia fare FineReader? --Alex brollo (disc.) 23:39, 17 feb 2014 (CET)
Per i pythonomani: sto sperimentando la class Eye (la "classe occhio") :-) --Alex brollo (disc.) 09:30, 18 feb 2014 (CET)
Conosci imagemagick? Lo usavano qui in ufficio per ruotare-croppare-splittare in batch. --Aubrey (disc.) 12:58, 18 feb 2014 (CET)
Si, grazie, Aubrey; non lo maneggio ma dovrò studiarlo; la stessa cosa posso fare, al momento, con nconvert o con PIL di python. Il problema è però: come calcolare automaticamente i parametri da passare al batch per eseguire la rotazione e il ritaglio?

Ecco due immagini da un testo Opal che ho appena caricato in IA:

Pag bianca.jpg Pag marcata.jpg

Il problema è tracciare automaticamente la riga rossa come nella seconda immagine (per farlo occorre una primordiale analisi di immagine, cosa del tutto diversa da un'elaborazione batch di immagine). In questa immagine che avevo sottomano la riga rossa è quasi verticale e quasi al centro, ma in altri casi non è affatto nè verticale, nè al centro. Sto lavorando a un "occhio virtuale" che scorre l'immagine e trova ciò che è caratteristico della linea che separa le due immagini, ma non è semplice. Si tratta di implementare qualcosa come "Circa a metà dell'immagine, trova una linea verticale o obliqua più scura dell'immediato contesto e restituiscine posizione e gradi di inclinazione rispetto alla verticale, oppure coefficienti a e b della retta". Il resto è trigonometria.... --Alex brollo (disc.) 08:31, 19 feb 2014 (CET)
Progetto sospeso; gran parte dei file Opal non richiedono questa manipolazione.... la accantono, c'è ben altro da fare. --Alex brollo (disc.) 12:46, 25 feb 2014 (CET)

Tech News: 2014-09[modifica]

11:18, 24 feb 2014 (CET)

Script opalLib.py[modifica]

Non potevo farlo prima perchè nel codice c'erano in chiaro le mie chiavi di accesso personali a Internet Archive; sistemati i punti critici dello script, mi sono potuto dedicare alle prime rifiniture, e li ho fatti sparire dal codice.

Metto in Progetto:Trascrizioni/Opal/opalLib.py il codice attuale che gira su tools-dev. Chi conosce la programmazione, abbia pietà. --Alex brollo (disc.) 23:12, 27 feb 2014 (CET)

Segnalazione[modifica]

Segnalo questa discussione--Piaz1606 (disc.) 00:49, 1 mar 2014 (CET)

Tech News: 2014-10[modifica]

10:30, 3 mar 2014 (CET)

API di internet archive per i metadati[modifica]

Guardate questo libro di IA: https://archive.org/details/image156TeatroOpal

Notate l'id: image156TeatroOpal. Questo vi permette di risalire immediatamente all'URL diretto del pdf su Opal; il pdf su Opal si chiama proprio image156.pdf e sta dentro la raccolta Teatro.

L'URL della raccolta Teatro ha sempre, come base,

  • http://www.opal.unito.it/psixsite/Teatro italiano del XVI e XVII secolo/Elenco opere/

Aggiungiamo in fondo il nome del pdf:

  • http://www.opal.unito.it/psixsite/Teatro italiano del XVI e XVII secolo/Elenco opere/image156.pdf

ed ecco il link funzionante:

Non è finita! Provate l'effetto di questi due link:

Il primo restituisce l'intero set di metadati IA (anche quelli interni di servizio); il secondo i medatadi inseriti da chi ha caricato, quelli bibliografici; il terzo restituisce, all'interno dei secondi, il solo metadato "title" (il titolo). A qualcuno di voi può sembrare astruso, poco chiaro e "povero"; ci giurerei che Candalua, Ricordisamoa, e altri geek o semigeek si fregheranno le mani :-) @Ricordisamoa:: questi dati sono particolarissimi anche dal punto di vista Wikidata, perchè hanno la fonte implicita (l'originale del libro), la migliore immaginabile. Un pensierino lo farei: IA->wikidata->commons book e -> it.wikisource Indice: ; tutti perfettamente allineati) --Alex brollo (disc.) 10:58, 4 mar 2014 (CET)

Acchiappo dei metadati da IA tipo Ajax[modifica]

Per coloro che maneggiano javascript, in cima al mio common.js due funzioni IA() e IAload() (mi scuso se sono lunghe e complesse :-D ) attivate le quali un'istruzione js tipo:

IAload("image10TeatroOpal")

acchiappa tutti (ma proprio tutti!) i metadati contenuti nella pagina details dell'item e li ficca in $("body").data("IA") dove restano tranquilli finchè la pagina non viene abbandonata. Questo in qualsiasi progetto mediawiki, anzi: in qualsiasi sito dove sia attivo jQuery. --Alex brollo (disc.) 19:09, 7 mar 2014 (CET)

Ajax API interprogetto: sapevatelo?[modifica]

Vi posto il modo più semplice che ho scovato per lanciare una Ajax API interprogetto (qualsiasi API, qualsiasi progetto):

risultato=""
$.getJSON("https://en.wikisource.org/w/api.php?action=query&prop=contributors&titles=Main_Page&format=json&callback=?", function (data) {risultato=data})

oppure più semplicemente in un solo colpo

$.getJSON("https://en.wikisource.org/w/api.php?action=query&prop=contributors&titles=Main_Page&format=json&callback=?", function (data) {
    $("body").data("ApiResult",data)
})

Il truccaccio sta, oltre che a usare $.getJSON, di ricordarsi di aggiungere alla fine della API &format=json&callback=? Alex brollo (disc.) 08:50, 10 mar 2014 (CET)

Tech News: 2014-11[modifica]

10:10, 10 mar 2014 (CET)

Tech News: 2014-12[modifica]

08:14, 17 mar 2014 (CET)

Editor per djvu text layer[modifica]

Sappiamo molte cose sullo strato testo djvu; quello che manca è uno strumento semplice, intuitivo, infallibile per editare lo strato testo modificando solo ed esclusivamente il testo senza toccare un sacco di altra roba (struttura, coordinate degli elementi), che può essere trasformata in una struttura html (tipo hOCR oppure analoghi, in html5 dovrebbe essere molto più agevole). L'importante è che l'editor permetta solo di editare il testo e non tocchi i tag html.

Scopro e resto a bocca aperta tinyeditor, uno script js che permette di trasformare qualsiasi textarea in un "editor hrml WISIWYG"; leggo il codice, brevissimo (11 kby!) e piombo nella disperazione perchè è scritto in aramaico. Non ci capisco nulla :-( . La sfida è: qualcuno è in grado di capirlo? Se sì, e se qualcuno è in grado di modificarlo, questo breve script potrebbe essere la chiave per la soluzione del problema. Il resto è facile. --Alex brollo (disc.) 10:02, 17 mar 2014 (CET)

Perché non CKEditor? --Ricordisamoa 16:48, 17 mar 2014 (CET)
CKEditor è "grosso", e non è immediatamente evidente la possibilità di applicarlo a una qualsiasi textarea in qualsiasi pagina web in cui si possa in filare un pochino di js aggiuntivo (la possibilità che non sia evidente non la esclude!). Tinyeditor potrebbe essere infilato direttamente nella pagina di edit di wikisource (in teoria), anche se prima vorrei ideare un tool "autonomo".
Inoltre, per quello che serve a me, almeno l'80% del codice di tinyeditor (che pesa 11 k: poche decine di righe, una specie di miracolo dell'astrazione...) non mi serve affatto; devo solo capire come isolare, nel codice, la parte "fondamentale" e eliminare tutto il resto. Per quello cerco un interprete: perchè nonostante sia javascript puro, è per me, al momento, totalmente e assolutamente incomprensibile.
Se sei disponibile a approfondire, potrei elencarti qui le caratteristiche dell'"editor perfetto" che cerco: una banalità assoluta, da cui dipende, facendo le cose bene, l'impossibilità di sbagliare (o quasi)--Alex brollo (disc.) 09:19, 18 mar 2014 (CET)
Non hai pensato a un plugin specifico per VisualEditor? --Ricordisamoa 15:25, 18 mar 2014 (CET)
Certo; e in effetti ho già verificato che per certi versi VE sarebbe ideale ed in effetti funziona; ma la sua complessità è tale da scoraggiare ogni approccio. Quando ho chiesto come si monta sopra un gadget js qualsiasi mi è stato risposto che... stavano progettando la cosa da mesi, e non era finita. Io uso preferenzialmente quello che capisco; VE non lo capisco. Stavo comunque pensando di esporre i dettagli del problema a qualche sviluppatore. Si tratterebbe solo di disattivare quasi tutto. --Alex brollo (disc.) 18:27, 18 mar 2014 (CET)
Volendo possiamo anche discuterne operativamente qui: https://meta.wikimedia.org/wiki/Grants:IdeaLab/Djvu_text_layer_editor --Alex brollo (disc.) 11:16, 21 mar 2014 (CET)

Ipotesi per l'inserimento delle immagini nelle pagine[modifica]

E' possibile scaricare da Internet archive le singole immagini delle pagine in formato originario (tiff) oppure nella migliore "derivazione" possibile di un pdf (jp2, jpg). E' quindi possibile, avendo le cordinare di un'immagine sulla pagina, cosa che sta dentro il template Ritaglio, istruire un bot per scaricare le immagini originali (e non quelle manomesse dal sistema di compressione dei file djvu), ritagliarle, sottoporle a eventuale elaborazione (es. conversione in BN o in scala di grigi) e caricarle su Commons; dopodichè è possibile sostituire il tl Ritaglio con una normale chiamata a un'immagine.

Non è una cosa da poco.... ma ho verificato tutti i passaggi, si può fare. Chi ci sta a aiutarmi, o a prendersi in carico questo progettino? --Alex brollo (disc.) 05:31, 20 mar 2014 (CET)

Immagini ad alta risoluzione da IA[modifica]

Grazie a Nemo ho scoperto che è possibile utilizzare le immagini delle singole pagine alla massima risoluzione possibile, scaricandole direttamente da IA, come file jpg.

Questo significa che in caso di pagina troppo compressa e dubbia all'interno del djvu, è teoricamente possibile, con un click, sostituirla con un'immagine ad alta risoluzione aggirando tutto il sistema di visualizzazione dell'estensione proofreading; una volta caricata, l'immagine "regge" anche alla variazione di layout verticale/orizzontale.

L'indirizzo dell'immagine è ricavabile avendo solo l'ID del libro su IA, e il numero della pagina.

Esempio

L'ID di File:Ritratto delle più nobili et famose città d'Italia.djvu è imageMA95NarrativaOpal. Da qui si ricava:

  • il nome della pagina principale del libro su IA è //archive.org/details/imageMA95NarrativaOpal
  • per accedere all'indice del file zip che contiene le immagini jp2/jpg l'indirizzo è //archive.org/download/imageMA95NarrativaOpal/imageMA95NarrativaOpal_jp2.zip/
  • per accedere direttamente all'immagine della pagina 5 l'indirizzo è://archive.org/download/imageMA95NarrativaOpal/imageMA95NarrativaOpal_jp2.zip/imageMA95NarrativaOpal_jp2%2FimageMA95NarrativaOpal_0004.jpg

--Alex brollo (disc.) 08:34, 24 mar 2014 (CET)

@Ricordisamoa:: come da bar generalista, esiste uno script prototipo che carica da IA l'immagine ad alta risoluzione della pagina sostituendola a quella compressa proveniente dal djvu di Commons. Il problema è recuperare l'ID IA del libro da cui è stato estratto il djvu. Chiedo a chi lo sa fare di aprire un item Wikidata del libro Indice:Ritratto delle più nobili et famose città d'Italia.djvu (Internet Archive) e di infilare fra i metadati il codice IA, in modo che in questo caso-test (e poi nin tutti gli altri) l'ID IA si possa recuperare al volo da wikidata; tale ID è tutto ciò che serve per ricavare l'url esatto dell'immagine della pagina su Internet Archive. Mi sembra di essermi spiegato chiaramente ;-) --Alex brollo (disc.) 08:21, 25 mar 2014 (CET)
@Alex brollo: tramite le nuove API ho creato d:Q15978367 aggiungendo anche la dichiarazione in una singola modifica! --Ricordisamoa 11:14, 25 mar 2014 (CET)
Grazie! Dai un'occhiata a come ho "manomesso" l'item e vedi anche discussione che ho aperto in pagina discussione di Book task force. --Alex brollo (disc.) 16:46, 26 mar 2014 (CET)

Tech News: 2014-13[modifica]

19:56, 24 mar 2014 (CET)

Tech News: 2014-14[modifica]

11:20, 31 mar 2014 (CEST)

File xml di Internet Archive[modifica]

Ogni libro di Internet Archive contiene due xml molto interessanti per la gestione del testo:

  • il file _djvu.xml;
  • il file _abbyy.xml (mascherato dentro un file gz)

Il primo ha i seguenti contenuti e caratteristiche:

  • contiene tutti i dati/metadati generali del file djvu;
  • contiene il testo mappato (coordinate) delle pagine, nelle regioni page-column-region-paragraph-line-word;
  • è strutturato in modo da poter essere riversato nel file djvu senza parametri (ne sostituisce completamente lo strato metadati e testo)

Il secondo ha i seguenti caratteri:

  • contiene tutto il testo mappato fino a livello di singolo carattere:
  • per ogni elemento carattere contiene dati di vario tipo riguardanti la formattazione e il grado di certezza del riconoscimento;
  • non può essere riversato nel file djvu senza profonda rielaborazione.

Test preliminari dimostrano che è possibile aggiungere agli elementi word del primo markup wiki o markup html, che saranno poi normalmente recuperati come puro testo in edit della pagina su source. Le coordinate testo dei due file xml corrispondono; è quindi possibile "travasare" qualcuno dei (ridondanti) dati del secondo nel primo; ad esempio, è possibile estrarre il dato "certezza del riconoscimento OCR" delle singole parole e aggiungerlo allo strato testo di djvu.xml in modo che le parole incerte siano identificabili nel testo come compare sia in view che in edit.

Un'altra cosa che si potrebbe fare + produrre un dizionario completo degli elementi parola del file djvu, con le proprie coordinate, e editarlo in massa prima di ricaricarlo; ogni parola, essendo associata alle proprie coordinate, può essere anche estratta dal file immagine "ritagliandola" esattamente per visualizzarla singolarmente. --Alex brollo (disc.) 08:41, 3 apr 2014 (CEST)

Mi sta pungendo vaghezza di usare le coordinate delle parole per estrarre massivamente le immagini delle parole, normalizzarle per altezza, convertirle in B/N e provare a studiare algoritmi di confronto (innanzitutto per rapporto altezza/larghezza, poi in qualche modo per "sovrapponibilità"). L'idea è pazzesca o_O : quindi ci provo :D --Alex brollo (disc.) 11:55, 23 apr 2014 (CEST)

Tech News: 2014-15[modifica]

10:00, 7 apr 2014 (CEST)

Tech News: 2014-16[modifica]

09:18, 14 apr 2014 (CEST)

Tech News: 2014-17[modifica]

10:34, 21 apr 2014 (CEST)

Categoria:Template che usano dati di Wikidata[modifica]

Nuova, utile, sull'esempio di pedia. --Ricordisamoa 16:11, 25 apr 2014 (CEST)

Estrattore immagini in python[modifica]

In Utente:Alex brollo/estrattoreImmagini.py trovate i primi vagiti di uno script che estrae una copia fisica in formato png delle immagini visualizzate con Ritaglio. Per attivarlo basta il nome base del file djvu. Per ora lavora solo in locale e in modalità interattiva.

  • La prima versione estrae le immagini dal file djvu di Commons (formato png).
  • La seconda (utilizzabile se l'opera proviene da IA) estrae le immagini ad alta risoluzione dal file _jp2.zip di Internet Archive (formato jpg).

--Alex brollo (disc.) 17:21, 25 apr 2014 (CEST)

Una serie di prova in commons:Category:Illustrations from Avventure di Robinson Crusoe con il nome standard File:Avventure di Robinson Crusoe [pagina] [numero].jpg (pagina: numero pagina djvu; numero: numero dell'immagine della illustrazione nella pagina, default 0). --Alex brollo (disc.) 15:45, 26 apr 2014 (CEST)

Siccome il nome è standard, dovrebbe essere possibile trasformare le immagini da provvisorie a definitive via bot. --Alex brollo (disc.) 15:45, 26 apr 2014 (CEST)

Cosa aggiungono queste immagini ritagliate alle pagine già presenti su Commons? --Ricordisamoa 18:46, 26 apr 2014 (CEST)
Le immagini incorporate nelle pagine con Ritaglio non sono esportabili in ePub, aimè. Non ho provato con il generatore di pdf, ma l'epub non va. Vanno considerate provvisorie e vanno sostituite quanto prima con immagini "definitive", autonome. Adesso provo il generatore di pdf.... --Alex brollo (disc.) 16:49, 28 apr 2014 (CEST)
Niente da fare. :-( --Alex brollo (disc.) 16:54, 28 apr 2014 (CEST)

Tech News: 2014-18[modifica]

09:22, 28 apr 2014 (CEST)

Tech News: 2014-19[modifica]

09:29, 5 mag 2014 (CEST)

Jq, pdftk, e virtualenv[modifica]

Tre domandine facili per i "geek maggiori" (@Candalua:, @Ricordisamoa:) con familiarità con l'ambiente del SO di Tool Labs.

  1. jq è un interessante script per il parsing di strutture json - viene descritto come "il grep per json". Lo conoscete? Vi servirebbe nel progetto itsource? Gira già qualcosa di analogo (si può fare in python, ma jq è più pratico)?
  2. pdftk è uno script per smontare-rimontare file pdf multipagina; su Tool Labs gira l'interessante pdfunite, che ricuce pdf separati, ma mi manca uno strumento per splittarli. Come sopra.
  3. virtualenv è una cosa che riguarda solo python o dà dei "privilegi locali di root" generali? --Alex brollo (disc.) 08:49, 7 mag 2014 (CEST)
Se non sbaglio, jq e pdftk sono stati installati d'ufficio a seguito di un messaggio in lista Labs. Proviamoli! :-)
Sono quasi certo che un'accoppiata fra curl (+ mediawiki API) e jq potrebbe dare grandi e velocissimi risultati prima ancora di attivare python. Pdftk invece è per chi si occupa di pdf, ovviamente --Alex brollo (disc.) 13:30, 9 mag 2014 (CEST)

Tech News: 2014-20[modifica]

08:00, 12 mag 2014 (CEST)

Geek maggiori, date un occhio a jq[modifica]

Qui: http://stedolan.github.io/jq/manual/ il manuale di jq, parser per strutture json di qualsivoglia complessità. Ci sono belle prospettive da sfruttare (tenendo conto della complessità e della ridondanza di blocchi dati json prodotti da mediawiki API, soprattutto da wikidata). Io me lo studierò, ho idea che possa semplificare moltissimo i lavori bot, e anche estrazioni manuali (funzia bene anche in ambiente windows). Se esistesse qualcosa di simile per l'ambiente javascript sarebbe il massimo. --Alex brollo (disc.) 09:55, 16 mag 2014 (CEST)

Ho cominciato i test.... non è facile, è molto astratto. Se fra voi c'è qualche astrattista.... :-P
Una bella cosa è che in windows è un file unico exe senza dipendenze; lo si schiaffa in una qualsiasi directory elencata nel PATH di sistema, e fine. --Alex brollo (disc.) 18:23, 18 mag 2014 (CEST)

Tech News: 2014-21[modifica]

09:18, 19 mag 2014 (CEST)

Ipotesi per l'accesso all'OCR di testi IA[modifica]

Quando un'opera è caricata su IA e viene caricato in Commons il djvu di IA, l'intero contenuto testuale mappato djvu.xml può essere letto da IA, caricato localmente (in memoria o nello spazio local storage) e utilizzato via jQuery. Ci proviamo? --Alex brollo (disc.) 10:32, 19 mag 2014 (CEST)

Aggiornamento jQuery[modifica]

Invito specialmente gli amministratori a prendere coscienza di mailarchive:wikitech-l/2014-May/076340.html: come riassunto più sopra, alcuni script potrebbero non funzionare correttamente (uno a caso: MediaWiki:Common.js usa $.browser). --Ricordisamoa 05:35, 24 mag 2014 (CEST)

L'ho letta ma speravo che non usassimo le funzioni moriture. Mi arrangio in jQuery ma non abbastanza per mettere le mani su Common.js senza fare danni: esperienze precedenti mi hanno scoraggiato. Passo palla. --Alex (disc.) 17:10, 9 giu 2014 (CEST)
In questo caso, $.browser è usato ai fini esclusivi del supporto per IE7 (usato dallo 0,2 % degli utenti). Per il resto, Douglas Crockford avrebbe un infarto dopo il primo sguardo a MediaWiki:Common.js... --Ricordisamoa 10:07, 10 giu 2014 (CEST)

Tech News: 2014-22[modifica]

10:29, 26 mag 2014 (CEST)

Tech News: 2014-23[modifica]

10:07, 2 giu 2014 (CEST)

Tech News: 2014-24[modifica]

09:39, 9 giu 2014 (CEST)

djvu text layer editor[modifica]

Da molto tempo giro attorno al problema di costruire un semplice editor per lo strato testo dei file djvu. La soluzione che immagino è quella di un editor che consenta unicamente la correzione del testo suddiviso in parole, senza toccare le strutture di livello superiore. Dopo averne pensate tante, ho provato a costruire un editor html "parola per parola", ci lavorerò sopra; il testo campione è in Utente:Alex brollo/djvuEditor e lo script che attiva l'editor è in Utente:Alex brollo/djvuEditor.js. Non aspettatevi, per ora, nulla di più di un trucchetto che permette di editare i testi di una serie di span. Il trucco sta proprio lì: l'impossibilità di editare qualsiasi cosa al di fuori del contenuto degli span permette di "allineare implicitamente" le parole editate con la lista delle parole nella pagina djvu. Poi c'è "qualcosina" da fare lato server per caricare il file djvu, estrarre i testi, spedirli alla pagina, ricevere la lista delle parole editate, reinfilarle nel file djvu. Una cosetta da poco, ma dopo penose riflessioni ho concluso che la parte critica è proprio l'editor delle parole, e quindi ho iniziato da lì.

Se ogni tanto date un'occhiata e mi lasciate un commento, mi incoraggiate a andare avanti (ovviamente l'immagine a destra è un puro "segnaposto", dovrà comparire l'immagine della pagina). --Alex (disc.) 23:38, 9 giu 2014 (CEST)

Ipotesi per i backlinks[modifica]

Attualmente, il "cuore" del trucco backlinks è una funzione bl() scatenata dal click su un'ancora-backlink:

function bl(elemento) {
          window.location.href = window.location.origin + window.location.pathname+'#' + $(elemento).attr('id');
          var linkBersaglio=$(elemento).data('link');
          if (linkBersaglio.indexOf("/wiki/")==-1) linkBersaglio=window.location.origin+'/wiki/'+linkBersaglio;
         
          window.location.href=linkBersaglio;
         } 


Immaginiamo di sostituirla con questa:

function bl(link) {
   var backlink=location.origin+location.pathname+"#"+$(link).attr("id"); 
   localStorage.setItem("backlink",backlink); 
   targetLink=$(link).data('link');
   if (targetLink.indexOf("/wiki/")==-1) {
        targetLink="/wiki/"+targetLink;
   } 
   window.open(targetLink,"_self");
}

A questo punto, l'indirizzo all'ancora di partenza è stabilmente memorizzato, e potrà essere attivato in una varietà di modi, e non solo cliccando l'ancora di arrivo; verrà mantenuto anche se da questa si prosegue la navigazione seguendo altri link, perfino se si uscirà da wikisource o si spegnerà il pc; non appena rientrati in wikisource, sarà possibile tornare al punto esatto del testo da cui si è partiti. Basta organizzare qualcosa che se esiste un backlink memorizzato, visualizzi un link per raggiungerlo (e una volta che lo ha raggiunto, lo cancelli da localStorage). --Alex (disc.) 00:43, 13 giu 2014 (CEST)

localStorage: brainstorming[modifica]

Ho la sensazione che si possano fare grandi cose sfruttando i 5-10 Mby dello spazio localStorage, ho fatto qualche grossolano esperimento ma sono sovraccarico di idee fino alla paralisi :-(

In linea generale, preso atto che localStorage è uno spazio di memorizzazione stabile collegato a un determinato sito, e quindi accessibile fin tanto, e tutte le velte, che si apre una pagina qualsiasi di quel sito, vedo due possibili, diverse classi di utilizzi:

  1. in view, potrebbero essere pre-caricati dati utili alla navigazione; tenuto conto che la lettura wikisourciana spesso procede "a libri", scorrendo le pagine o i capitoli di una stessa opera, potrebbero per esempio essere caricati i wikidata collegati alla pagina-base di quell'opera per essere immediatamente disponibili da qualsiasi pagina secondaria;
  2. in edit, potrebbero essere precaricati una grande serie di dati utili a automazioni/a supporto dell'edit; la prima applicazione da implementare potrebbe essere la memorizzazione delle sostituzioni ricorrenti opera-specifiche impostate con la opzione "Ricorda" del tool find&replace di Candalua, Strumenti per la rilettura.

Altro? Alex (disc.) 10:59, 13 giu 2014 (CEST)

Tech News: 2014-25[modifica]

09:13, 16 giu 2014 (CEST)

Tech News: 2014-26[modifica]

09:20, 23 giu 2014 (CEST)

Tech News: 2014-27[modifica]

08:53, 30 giu 2014 (CEST)

Tech News: 2014-28[modifica]

09:07, 7 lug 2014 (CEST)

Idea testata su fr.source: currentIndexData[modifica]

@Candalua:, @Ricordisamoa: Per ovviare ad alcune carenze su fr.source (non trovo backlink nè nulla di simile all'amato tl|Pg) ho testato una possibilità: come si apre una pagina ns0 oppure nsPagina, viene ritrovato e aggiornato in memoria (in una variabile localStorage, quindi persistente) il nome della pagina Indice correlata alla pagina corrente (in localStorage["currentIndex"]. Se tale nome è diverso da quello memorizzato (ossia: se si è aperta una pagina che punta a un Indice diverso da quello memorizzato) scatta uno script che legge l'html del nuovo indice, ne esegue il parsing e carica i dati su una seconda variabile localStorage["currentIndexData"]]. Per ora i dati sono quelli prodotti da pagelist, in pratica un dizionario con chiave pagina libro che restituisce numero pagina djvu. Prossimo passo, il parsing dell'html del campo Sommario per identificare e memorizzare la relazione nome/titolo sottopagina ns0 - numero di pagina djvu iniziale qualsiasi sia lo script/template/transclusione che lo genera.

Gli usi potenziali di tali dati, sempre disponibili in editing, sono molteplici, sto appena esplorandoli con entusiasmo. Che dite, geek maggiori: monto il meccanismo anche qui? Gli script stanno in fr:user:Alex brollo/GetIndexData.js--Alex (disc.) 08:29, 8 lug 2014 (CEST)

Ho aggiunto una classe tableItem agli elementi creati da Indice sommario, e anche agli elementi creati da fr:Modèle:Table di fr.source, usato allo stesso scopo. Questo facilita enormemente il recupero dei due link (verso la pafina ns0 e verso la pagina Pagina: da cui la transclusione inizia); in pochi giorni sia su fr.source, sia su it.source questi dati saranno utilizzati in pratica. Fr.source mi piace molto... incoraggiano fortemente la sperimentazione, anche i template più "astrusi" sono sprotetti. --Alex (disc.) 12:44, 10 lug 2014 (CEST)
Fatto e semplificando parecchio! Adesso su fr.source come entro in una pagina Pagina o in una pagina Ns0 collegata a una pagina Indice tutti i dati (sia quelli provenienti da pagelist, che quelli compresi da un buon campo Sommario) sono silenziosamente acchiappati. Questo significa che da ognuna di queste pagine si ha a immediata disposizione l'intera struttura dell'opera, pronta a essere "interrogata" come si vuole. Sono molto, molto soddisfatto. --Alex (disc.) 16:42, 10 lug 2014 (CEST)

Pagina Indice, fonte della pagina ns0 corrente[modifica]

L'url della pagina Indice correlata alla pagina ns0 corrente sta nella variabile proofreadpage_source_href e il titolo (decodificato) della pagina Indice si può ricavare con:

currentIndex=find_stringa(decodeURIComponent(proofreadpage_source_href).replace(/_/g," "),"/wiki/",'"',0);

Sapevatelo? Io no. :-( --Alex (disc.) 08:35, 10 lug 2014 (CEST)

Importazione di fr:User:Alex brollo bis/GetIndexData.js[modifica]

Metto provvisoriamente in Utente:Alex brollo/GetIndexData.js una copia della pagina che corre su fr.source. Non ha alcuna dipendenza, è tutto javascript e jQuery base e usa variabili mediawiki di default. Potete quindi provare a farlo correre semplicemente con importScript(). --Alex (disc.) 18:11, 12 lug 2014 (CEST)

@Candalua:: Ho adattato lo script a it.source; adesso funziona anche come (velocissimo) autoNs0, ovviamente per provarlo bisogna evitare conflitti con precarica.js che ho disattivato dalle mie preferenze. Ha vari vantaggi su autoNs0; non richiede obbligatoriamente Indice sommario in pagina Indice, basta che ci siano degli elementi class="tableItem" ognuno dei quali contenga un link vs. ns0 e un link vs, nsPagina, anche caricati per transclusione; non richiede che vi sia l'elenco dei capitoli nella pagina ns0 base. La lascio un po' attiva come sta per provarla prima di proporti di trasformarla in un gadget; sono un po' esausto, è stata una faticaccia, sento un po' di nausea da javascript. --Alex (disc.) 22:08, 12 lug 2014 (CEST)

Interfaccia per Imagemap interattivo[modifica]

Con lo stesso "motore" di Ritaglio immagini si potrebbe realizzare un tool per le immagini mappate (per le aree rettangolo ee pure per le aree cerchio). Che ne dite, ne vale la pena? Avete mai sentito la voglia di costruirne qualcuna, nelle immagini con didascalie che puntano a parti dell'immagine? A me è successo. e succederà ancora per esempio qui: fr:Page:Saunier_-_La_Parfaite_Connaissance_des_chevaux.djvu/317 --Alex (disc.) 16:39, 15 lug 2014 (CEST)

Test qui: Pagina:Trattato di archeologia (Gentile).djvu/382. Il motore è grossolano, ma funzia, ed è molto più semplice di Ritaglio. --Alex (disc.) 08:28, 16 lug 2014 (CEST)

Tech News: 2014-29[modifica]

09:48, 14 lug 2014 (CEST)

Self templates[modifica]

@Candalua:: E' possibile trasformare una pagina (che non abbia una sezione dati) in un "self-template", capace di restituire dati relativi alla pagina. Chiamata come template con un parametro, restituisce il valore di quel parametro. Esempio: io sono guidatore del bot {{Utente:Alex brollo|bot}} e faccio parte del gruppo utenti {{Utente:Alex brollo|gruppo}}.

Purtroppo il sistema "confligge" con un'eventuale area dati; dovrebbe essere sostituirla. Il risultato è analogo a quello prodotto con area dati, ma sfrutta il meccanismo della gestione dei templates, e non quello delle section, che è molto meno efficiente e maggiormente server-expensive. --Alex (disc.) 08:16, 17 lug 2014 (CEST)

Immaginiamo di avere in una pagina Autore il seguente codice, appiccicato (sempre uguale!!!) al momento del salvataggio della pagina al posto dell'area dati:
<onlyinclude>{{#switch:{{{1}}}
|genere={{subst:#property:P21}}
|VIAF={{subst:#property:P214}}
....
}}</onlyinclude>
Al salvataggio della pagina, avvengono le sostituzioni e si caricano i valori delle proprietà aggiornate da wikidata. Appena la pagina è salvata (senza modifiche se i wikidati non sono cambiati!) la pagina Autore diventa un self-template e le singole proprietà sono estraibili da qualsiasi pagina di wikisource; es. il VIAF di Autore:Cesare Fiaschi sarebbe ottenibile con {{Autore:Cesare Fiaschi|VIAF}}. --Alex (disc.) 11:24, 17 lug 2014 (CEST)

Tech News: 2014-30[modifica]

09:41, 21 lug 2014 (CEST)

Tech News: 2014-31[modifica]

10:08, 28 lug 2014 (CEST)

Tech News: 2014-32[modifica]

09:37, 4 ago 2014 (CEST)

Categoria:Link a Wikipedia presenti in Autore[modifica]

Perche la pagina Pagina:Storia della rivoluzione piemontese del 1821 (Santarosa).djvu/48 non è visualizzata in Categoria:Link a Wikipedia presenti in Autore? --Accurimbono (disc) 13:00, 6 ago 2014 (CEST)

Adesso che l'ho modificata appare, ma prima non appariva... Come non appaiono numerose altre pagine transluse in NS0 che sono elencate nella caegoria: è un problema in quanto per indivisuare la pagina problematica bisogna spulciare tra le centinaia di pasine transcluse... C'è una soluzione? --Accurimbono (disc) 14:15, 6 ago 2014 (CEST)

Mi chiedo....[modifica]

.... che succede se io chiedo il parsing di una pagina A contenente un tag #property, via AJAX, lanciando la richiesta da una pagina B, ad esempio: da qui, chiedendo l'html di Opera:Tommaso Moro? Proviamoci....

html=$.ajax({url:"http://it.wikisource.org/w/index.php?action=render&title=Opera:Tommaso_Moro",async:false}).responseText;

Ma tu guarda un po'! Mi restituisce tutti i valori generati dai vari #property e pure quelli generati da Modulo:Wikidata, proprio come se stessi visualizzando quella pagina. Quindi è possibile leggere i valori generati da #property (non ottenuti con subst: i valori dinamici) nella pagina A, pur stando nella pagina B. Ma chi l'avrebbe detto.... ;-) --Alex (disc.) 22:30, 6 ago 2014 (CEST)

Ottimo! Qual è l'alternativa meno server expensive? La transclusione o AJAX?--Erasmo Barresi (disc.) 15:26, 13 ago 2014 (CEST)

Tech News: 2014-33[modifica]

09:43, 11 ago 2014 (CEST)

Tech News: 2014-34[modifica]

09:16, 18 ago 2014 (CEST)

Tech News: 2014-35[modifica]

11:21, 25 ago 2014 (CEST)

Tech News: 2014-36[modifica]

09:48, 1 set 2014 (CEST)

Nuovo Modulo:JSON[modifica]

Hop caricato un nuovo Modulo:JSON che codifica in una stringa JSON oggetti Lua, e inverso. Utile, anche perchè permette di scambiare dati fra javascript e Lua e per importare in Lua qualsiasi "roba" trasmessa in JSON. --Alex (disc.) 15:18, 1 set 2014 (CEST)

Funzione editPage()[modifica]

@Candalua: Tempo fa ho scritto/copiato (chissiricorda!) ciò che sta scritto in Utente:Alex brollo/ajaxEdit.js. La funzione interessante è editPage(callback,pagename); callback è il nome di una funzione che accetta come parametro il testo wiki di una pagina e lo restituisce modificato; pagename è il nome dalla pagina da modificare. La funzione legge il wikitesto di pagename, lo passa a callback, e poi scrive ciò che riceve da callback in pagename; la modifica, in cronologia, è registrata con il nome utente che ha lanciato la funzione (che usa l'edit token dell'user che sta manovrando la cosa). Se la pagina pagename non esiste, la crea.

Detta così, la cosa è un po' astratta; traducendola in modo operativo, rende possibile una modifica "standard" della pagina visualizzata, di un'altra pagina, di una serie di pagine con un click, se esiste una funzione predisposta per tale modifica "standard". Le possibili applicazioni sono parecchie e tutte evitano la noia di aprire una pagina in modifica - modificarla - salvarla quando la modifica è evidente. Consente anche il active touch delle pagine tipo Opera: in cui la reintroduzione di un codice standard allinea il contenuto con wikidata, rendendolo disponibile nel progetto; e vista la sua semplicità o_O sarà la prima applicazione che proverò a implementare, seguita dall'applicazione del SAL 00% sulle pagine vuote da un elenco di numeri pagina.

Domanda: qualcuno dei geek maggiori già usa la funzione o una funzione omologa? --Alex (disc.) 17:09, 1 set 2014 (CEST)

Io userei qualcosa come:
new mw.Api().postWithToken( 'edit', {
	action: 'edit',
	title: pagename,
	summary: 'summary',
	text: content
} )
.done(...)

--Ricordisamoa 14:18, 2 set 2014 (CEST)

@Ricordisamoa: Grazie! Intanto io sto costruendo dei callback; uno, per aggiornare Opera, è già pronto ed è "activeTouch" già accennato; l'altro, fresco fresco, è autoSAL100 e consente di passare a SAL 100% le pagine SAL 75% senza aprirle in modifica. Mi studierò bene il tuo codice, che di primo acchito non capisco: mi sa che devo studiarmi mw.Api e i sui metodi, e in generale stento moltissimo a ragionare con gli oggetti per vecchio, incancrenito, e difficilmente superabile, approccio "procedurale DIY". :-(
Per il momento e per semplicità, il link di "lancio" di queste procedure lo faccio apparire in sidebar, sotto Strumenti. --Alex (disc.) 14:31, 2 set 2014 (CEST)
@Alex brollo: la documentazione è sempre d'aiuto! --Ricordisamoa 16:13, 2 set 2014 (CEST)
Un detlodell'equtazione recita: "I libri insegnano solo a chi sa"; nel software: "La documentazione insegna solo a chi capisce" :-( :::: Mi sforzerò.... ma sarà dura. Lo prendo anche come invito a documentare un minimo quello che scrivo io. --Alex (disc.) 18:26, 2 set 2014 (CEST)

Pasticciando con le variabili globali[modifica]

@Candalua: & @Ricordisamoa: Come programmatore grossolano incappo spesso in problemi di namespace delle variabili javascript, e aimè nella mia produzione di gadget si sono stratificati in una maniera estremamente confusa vari sporchi trucchi per gestire variabili e funzioni.

Giusto in questi giorni ho scoperto che un buon modo di registrare variabili globali, per renderle accessibili a qualsiasi funzione anche come "parametri impliciti", è quello di aggiungerle come attributi al poderoso oggetto mw. E' una cosa corretta? Sarebbe corretto/utile aggiungere a mw anche le funzioni, come metodi? --Alex brollo (disc.) 08:40, 10 set 2014 (CEST)

Ho trovato alcune risposte nelle pagine di aiuto sullo stile di programmazione js.... e sono sul punto di capire le iffy! --Alex brollo (disc.) 13:14, 12 set 2014 (CEST)
Sto cautamente rivedendo i miei script sulla base di queste convenzioni:
  1. ficcare tutte le variabili dentro un oggetto mw.p
  2. ficcare tutte le funzioni dentro un oggetto mw.m
  3. usare solo il costrutto IIFE (Immediately-invoked function expression).
Sembra meno assurdo di quanto pensavo.... fermatemi se sto imboccando una strada rischiosa a mia insaputa. In ogni caso, per ora: solo negli script personali. --Alex brollo (disc.) 10:22, 15 set 2014 (CEST)

JsBot....[modifica]

Ho lanciato dalla console una roba così:

for (i=100; i<290; i+=2) {editPage(savePage0, "Pagina:Album Paulista.pdf/"+i); console.log(i); }

È partita una "raffica di ajax" che, al ritmo di una pagina al secondo, ha creato un centinaio di pagine vuote in Album Paulista.pdf. Almeno tre o quattro volte la velocità di un bot py, lanciato alla velocità massima. Finchè non mi bloccano, userò e svilupperò ancora questa cosa.... il famoso "bot javascript". --Alex brollo (disc.) 15:53, 17 set 2014 (CEST)

Fico! E anche leggermente inquietante :D Candalùa (disc.) 16:29, 17 set 2014 (CEST)
Già. La prossima volta lo faccio come Alebot, o mi travesto da bot, almeno non intaso Ultime modifiche. Chissà se qualcuno, ai "piani alti", se ne sarà accorto.... Devo trovare un modo di rallentare il processo, emulando una "throttle": suggerimenti? --Alex brollo (disc.) 23:25, 17 set 2014 (CEST)
jQuery non mi aiuta.... mi tocca studiare quella cosa orenda di setInterval che avevo sempre schivato come inutile orpello. Altro? --Alex brollo (disc.) 23:33, 17 set 2014 (CEST)
ecco qua: una cosa similare
n=0;
x=setInterval(function() {console.log("test "+n);n+=1;if (n===10) clearInterval(x);},10000)
esegue qualcosa una volta ogni 10 secondi poi si ferma da sè quando n raggiunge 10. Ci siamo :-) Alex brollo (disc.) 00:06, 18 set 2014 (CEST)

Ritorno e domanda[modifica]

Ciao a tutti!
Dopo una serie di peripezie nella vita ho di nuovo un poì di tempo libero da impiegare su WikiSource! Quando me ne sono andato, ormai anni fa, stavo lavorando alla trascrizione di tabelle come in questa pagina.
All'epoca ero niubbo assai, ora di mestiere faccio applicazioni web per cui ho acquisito una certa padronanza con HTML, CSS e soprattutto JavaScript.
La prima cosa che mi fa rabbrividire vedendo le vecchie tabelle è quanto codice scrivevo all'interno del tag style, metodologia allegramente errata. Da preferirsi di gran lunga è il sistema delle classi.

Ora la domanda vera e propria: siccome suppongo che ogni testo abbia la sua formattazione particolare, è possibile applicare fogli di stile personalizzati specifici per testo? Per fare un esempio sarebbe bello che in ogni pagina del libro Progetto di una strada a guide di ferro da Venezia a Milano fosse all'inizio incluso un file del tipo Progetto_di_una_strada_a_guide_di_ferro_da_Venezia_a_Milano.css che contenesse le regole di stile specifiche di quel testo, come ad esempio i bordi esterni spessi delle tabelle.

Possibilità o fantascienza? Grazie mille! --L0ll0 (disc.) 11:39, 20 set 2014 (CEST)

Perchè no? Immaginiamo che ci sia un'istruzione (per prova, in un js personale):
document.ready(function() {importStylesheet(wgTitle+".css");});
con qualche accorgimento per estrarre il nome della pagina principale se si sta su sottopagine; dovrebbe funzionare, facendo un bel nulla se la pagina .css non esiste. Se esiste, l'unico problema che vedo sono gli eventuali conflitti e anche il ResourceLoader che funziona in asincrono, certi css "grossi" potrebbero essere caricati dopo. Si tratta di provare. Alex brollo (disc.) 23:16, 21 set 2014 (CEST)
Bisognerebbe verificare... Perché i conflitti vanno evitati utilizzando i CSS correttamente in cascata (la regola che arriva dopo vince, la regola più annidata vince), i dati asincroni dovrebbero dare problemi solo su vecchie versioni di IE (credo la 7 e la 8, ma potrei sbagliarmi...), i CSS grossi si evitano perché i casi in cui necessita un vero e proprio stile personalizzato dovrebbero essere pochi, dato che non è il fine primario di Source. Ora faccio qualche prova col mio utente. Grazie delle dritte! --L0ll0 (disc.) 23:07, 22 set 2014 (CEST)
@L0ll0: Ripensandoci, però, attenzione: ogni modifica js - come ben sai - causa una variazione dell'aspetto della pagina a livello di browser; nessuna di queste modifiche avrà effetto su eventuali esportazioni che originino dal server. Ibn particolare: non appariranno su ePub. Quindi, se vuoi un abbellimento per te e per gli utentio che leggono le pagine qui, è un conto; ma se vuoi che l'adattamento css sia esportato.... le cose diventano complicate. IL solo css aggiuntivo che viene esportato negli ePub è quello che sta su una pagina specifica, ma generale (che in queso momento non trovo...); sarebbe lì, in teoria, che si dovrebbe caricare il css aggiuntivo, con qualche sistema che lo attivi in modo opera-specifico; ma è una soluzione che regge solo per pochi casi. Alex brollo (disc.) 13:47, 26 set 2014 (CEST)

MediaWiki:Gadget-Diacritici.js[modifica]

Non è ancora collegato, ma è funzionante. Potrebbe essere l'ovo di colombo per evitare di scorrere disperatamente alla ricerca di lettere con diacritici strani (in Indice:Storia di Santa Genoveffa.djvu ce ne sono parecchi per pagina).

Il tool Diacritici funziona in questa maniera. Creato un bottone con il segno del diacritico, es. aggiungendo nella propria pagina PersonalButtons.js:

newButton("˘", "applicaDiac('˘')", "es","Applica ˘");

si crea un pulsantino con il diacritico. Ora, posizionando il cursore dopo la lettera a cui si vuole applicare il diacritico, anche se già accentata o con diacritico diverso "inventato" dall'OCR, e premendo il pulsantino, la lettera che precede il cursore si strasformerà istantaneamente nella lettera con il diacritico giusto; qui, ad esempio, mi posiziono il cursore dopo la o di prova e premo il pulsante con ¯: diventa prōva. Il cursore resta lì. Se il diacritico, per quella lettera, non esiste, il browser lancia un alert lamentoso ma altro non succede. Che ve ne pare? Se volete provare:

  1. bottoniera attivata;
  2. scopiazzare i bottoni da Utente:Alex brollo/PersonalButtons.js;
  3. mettere nel proprio common.js l'istruzione importscript("MediaWiki:Gadget-Diacritici.js");.

--Alex brollo (disc.) 23:30, 21 set 2014 (CEST)

Attivato. Nelle prove che sto facendo (ogni scarafone ecc...) il risultato è molto buono; cercare e correggere i diacritici più stravaganti è divertente.
La logica è: alla pressione del bottone che rappresenta un diacritico:
  1. memorizzare il carattere precedente il cursore e una sua copia normalizzata (ossia, carattere base senza diacritico);
  2. trovare l'eventuale carattere unicode corrispondente al carattere normalizzato + diacritico pigiato;
  3. sostituire il carattere precedente il cursore e riposizionare il cursore dov'era.
Potrebbe essere esteso ai diacritici greci ma c'è la complicazione delle combinazioni di più diacritici (sovrascritti e sottoscritti) che complica un po' le cose. --Alex brollo (disc.) 22:51, 23 set 2014 (CEST)
Esteso oggi alla gestione dei diacritici sui caratteri maiuscoli (comodissimo perfino nel caso banale del carattere È). Prossimo passo, la trasformazione di caratteri da latini a greci (per ora senza diacritici) in modo che anche i caratteri greci possano essere comodamente scritti con la normale tastiera + click. Utile qualche astuto suggerimento per le necessarie convenzioni per ottenere, da tastiera italiana, i caratteri non corrispondenti (tipo ω; φ; ψ) Alex brollo (disc.) 09:24, 24 set 2014 (CEST)
@OrbiliusMagister: Che ne diresti di scrivere u per ω, th per φ, ps per ψ? Si creerebbero conflitti per parole ambigue? Il caso σ - ς penso si possa automatizzare; in finale è sempre ς e in altra posizione è sempre σ, mi confermi? Quali altri caratteri ambigui si possono incontrare, e come risolvere? --Alex brollo (disc.) 09:44, 26 set 2014 (CEST)
@OrbiliusMagister: Mi sono incastrato sul caso ε - η; non so a quali caratteri della tastiera italiana associarli, in modo che l'associazione sia immediatamente intuitiva :-( Alex brollo (disc.) 07:39, 2 ott 2014 (CEST)
Intanto cerco di rispondermi da me :-)
Lo standard di translitterazione è il seguente:
Per il greco moderno sono previste le corrispondenze esposte nella tabella seguente secondo l'ISO 843 1997 TL. http://transliteration.eki.ee/pdf/Greek.pdf
Α, α Β, β Γ, γ Δ, δ Ε, ε Ζ, ζ Η, η Θ, θ Ι, ι K, κ Λ, λ Μ, μ Ν, ν Ξ, ξ Ο, ο Π, π Ρ, ρ Σ, σ (ς) Τ, τ Υ, υ Φ, φ Χ, χ Ψ, ψ Ω, ω
a v g d e z ī th i k l m n x o p r s t y f ch ps ō
Devo verificare se funziona; ai nostri fini vedo il problema che i caratteri ī e ō non si possono ottenere dalla tastiera, e chiederei il piccolo sforzo - in deroga allo standard - di inserirli come ì e ò che invece sulla tastiera ci sono; inoltre accetterei il b per β. Che ne dite? Il tool che ho in mente dovrebbe funzionare così: si scrive in caratteri latini o anche mescolando caratteri latini e greci che è lo stesso, si seleziona e si clikka. Ai diacritici ci si pensa poi. --Alex brollo (disc.) 08:19, 2 ott 2014 (CEST)

<torno a capo> ti propongo le corrispondenze che ricorrono nei font pre unicode e con cui eravamo abituatia digitare: il betaCode è questo: tutto come hai scritto

Α, α Β, β Γ, γ Δ, δ Ε, ε Ζ, ζ Η, η Θ, θ Ι, ι K, κ Λ, λ Μ, μ Ν, ν Ξ, ξ Ο, ο Π, π Ρ, ρ Σ, σ (ς) Τ, τ Υ, υ Φ, φ Χ, χ Ψ, ψ Ω, ω
a b g d e z h q i k l m n c o p r s t u f x y w

La sigma finale è aggiustabile come hai detto, il carattere h non è parte dell'alfabeto greco e serve perfettamente per la eta senza bisogno di altro. dall'immagina che ti ho linkato puoi notare gli artifici con cui i diacritici venivano "imitati" (gli spirit con le parentesi, gli accenti con gli slash e l'"uguale", il "pipe" | per la iota sottoscritta ecc.). Spero di averti dato una mano. - εΔω 16:42, 2 ott 2014 (CEST)

Magnifico: esattamente quello di cui avevo bisogno. :-) --Alex brollo (disc.) 08:54, 6 ott 2014 (CEST)

Le mie prime iffy: please review[modifica]

@Candalua: Caduto pietosamente in un conflitto fra funzioni e variabili fra imagemap e ritaglio, mi sono deciso a trasformare MediaWiki:Gadget-imagemap.js e MediaWiki:Gadget-cornersAlpha.js in due strutture iffy e in effetti il conflitto sembrerebbe risolto. L'idea e di "incarcerare" tutte le funxioni e variabili interne dentro una struttura (function (mw) { codice }) (mediaWiki), esponendo all'esterno solo te funzioni che sono richiamate all'esterno (in sostanza, quelle dentro bottoni o link di chiamata). Ce la fai a darmi un'occhiata al codice? Ho commesso degli errori grossolani? --Alex brollo (disc.) 07:13, 29 set 2014 (CEST)

@Candalua: Fatta la trasformazione (parziale) in iffy anche di MediaWiki:Gadget-EditInView.js. Ho lasciato però, in testa, alcune funzioni pubbliche. Sembra funzionare. --Alex brollo (disc.) 18:58, 29 set 2014 (CEST)

Oggetto mw.eiv[modifica]

Sto testando delle cose su fr.source, e mi sono deciso a sistemare un po' il codice che, in modalità view:

  • inizializza un oggetto mw.eiv
  • legge il codice della pagina Pagina corrente
  • lo carica in un oggetto mw.eiv.contenuto i cui campi sono:
    • code: codice completo,
    • header: contenuto dell'header come appare in modifica
    • body: contenuto del corpo pagina
    • footer: contenuto del footer come appare in modifica
    • level: quality level
    • user: utente contenuto nell'header
  • carica in mw.eiv alcune funzioni:
    • mw.eiv.pageRead, legge il wikicode
    • mw.eiv.pageParse, trasforma il wikicode in un oggetto editabile
    • mw.eiv.pageBuild, ritrasforma l'oggetto in wikicode
    • mw.eiv.pageSave, salva il wikicode

Il tutto in una iffy priva di dipendenze. Trovate il codice "in lavoro" su Utente:Alex brollo/pagina.js. Raffinerò e generalizzerò (per adesso tutto è focalizzato sulla pagina Pagina corrente) in seguito... forse. --Alex brollo (disc.) 21:54, 5 ott 2014 (CEST)

In termini pratici: stando in view su una pagina, per salvare il codice modificato è sufficiente modificare i valori dei campi dell'oggetto mw.eiv.contenuto, già precaricato, e chiamare la funzione di salvataggio. Un paio di righe di codice di estrema semplicità. --Alex brollo (disc.) 08:48, 6 ott 2014 (CEST)
Esempio. Volendo portare a SAL 100 la pagina Pagina:Annali d'Italia, Vol. 1.djvu/64, stando lì scrivo in console:
mw.eiv.contenuto.user="Alex brollo";
mw.eiv.contenuto.level="4";
mw.eiv.pageSave("Test nuova funzione mw.eiv.savePage()");
e succede ciò che è documentato nella cronologia della pagina. --Alex brollo (disc.) 09:58, 6 ott 2014 (CEST)
Provato su fr.source: funzia. Oltre che privo di dipendenze, lo script sembra essere multiprogetto, tranne, forse, la gestione del footer di default. --Alex brollo (disc.) 15:08, 6 ott 2014 (CEST)

Primo passo verso la generalizzazione[modifica]

@Candalua:, @Ricordisamoa:Adesso mw.eiv.savePage() accetta un unico parametro data, opzionalmente stringa (summary) o oggetto. Se data è oggetto è possibile salvare in pagine diverse dalla pagina corrente, senza ricaricare la pagina corrente (lo script si comporta quindi come un jsbot e può essere lanciato ripeturtamente dalla stessa pagina) Alex brollo (disc.) 08:38, 7 ott 2014 (CEST)

Preview affiancata a immagine della pagina[modifica]

Questo codice clona l'immagine della pagina (a largezza fissa) e la affianca al testo in preview. Provatelo se siete curiosi. Ogni successivo "Visualzza anteprima" modificherà il testo in preview senza "rompere" lo schema della pagina.

$(document).ready(function() {
        if (wgCanonicalNamespace==="Page" && (wgAction==="edit" || wgAction==="submit")) {
                var tabella=$("<table>").attr("width","100%").attr("border","1");
                tabella.append($("<td valign='top' id='tdPreview'>"));
                tabella.append($("<td valign='bottom' id='tdImmagine'>"));
                tabella.insertBefore($("#wikiPreview"));
                $("#tdPreview").append($("#wikiPreview"));
                imgPreview=$(".prp-page-image img").clone();
                imgPreview.css("width","480px").css("height","auto");
                $("#tdImmagine").append(imgPreview);
        }
 
});

--Alex brollo (disc.) 00:09, 11 ott 2014 (CEST)

Pseudotransclusione inversa[modifica]

Avendo nominato l'orrido neologismo in un messaggio a Candalua, vi spiego l'esperimento che ho fatto su wikisource, su indice vuoto.

Con un po' di python associato a DjvuLibre, ho estratto lo strato testo di un'intero libro pagina per pagina, passandolo a Python che ha sistemato un pochino il testo (un minimo di postOCR) e ha aggiunto, in testa a ogni pagina, il codice split (quello che normalmente viene prodotto da Match, altro non è che un banale link alla pagina circondato da due segni = per parte: ==[[Nome della pagina]]==). Lo script poi ha fuso tutte le pagine accodandole e il testo è stato caricato su una sandbox; da qui, con la funzione Split, è stato riversato nelle pagine Pagina. Tutto qua. --Alex brollo (disc.) 09:52, 16 ott 2014 (CEST)

Pulizia Common.js[modifica]

Stavo dando un occhio di nuovo a common.js e ho notato che ci sono numerose chiamate a $(document).ready, vengono caricati script in punti diversi e due variabili globali che forse possono essere rese locali "areaDati" e "datiPagina". Che ne dite se catalogo tutte le funzioni presenti in common e dopo averle raggruppate per funzione proviamo a vedere se ci sono cose che possono essere scartate o semplificate e poi faccio in modo che ci sia una sola chiamata al document.ready al cui interno si gestiscono le varie funzioni. Così nel frattempo creiamo uno standard che poi continuiamo a seguire per mantenere il tutto stabile e controllato ma allo stesso tempo espandibile. Mi serve la saggezza di @Utente:Alex brollo, di @Utente:Candalua e chiunque altro abbia inserito una funzione in commons, per sapere se posso agire e, nel caso in cui ci sia qualcosa da eliminare, se si può effettivamente eliminare. Samuele 15:25, 18 ott 2014 (CEST)

Hai stra-ragione, ma Common.js mi intimidisce e tranni rari edit non ho ancora trovato il coraggio di metterci mano. Ci ho messo le mani in passato, quando ero temerario e audace, e Candalua è stato una specie di santo a passare dietro di me e sistemare; adesso sono ancora temerario e audace, ma non su Common.js.
Per quanto mi riguarda, suggerirei di ripulire drasticamente, e poi verificare se manca qualcosa; e, certo, le variabili globali devono sparire e devono essere tutte ficcate dentro l'oggetto $ o l'oggetto mw. Con calma, dovranno sparire anche le funzioni globali. --Alex brollo (disc.) 15:55, 18 ott 2014 (CEST)
@Samuele Papa:vedi anche Discussioni progetto:Trascrizioni/newThumbs --Alex brollo (disc.) 10:31, 24 ott 2014 (CEST)

Tre domande facili :-)[modifica]

  1. Nelle iffy tipo (function(mw) {.....})(mediaWiki) vedo, in vari esempi, che il nome del parametro della funzione (mw) è diverso da quello nella parentesi esterna. Perchè? Cosa succede di male se sono uguali? Non vengono comunque passati per riferimento?
  2. A cosa serve l'accrocchio mw.config.set() e mw.config.get()? Cosa succede di male aggiungendo semplicemente ulteriori elementi all'oggetto mw con qualcosa come mw.nomeVariabile=valoreVariabile?
  3. Vedo che nel sorgente html delle pagine c'è anche l'elenco dei gadget attivati dall'utente corrente dentro l'oggetto mw.user.options.values; ha senso aggiungere nei gadget dei controlli per segnalare all'utente corrente eventuali dipendenze non rispettate? --Alex brollo (disc.) 10:50, 20 ott 2014 (CEST)
  1. E' utile chiamarli in modo differente per distinguerli. mediaWiki è una variabile globale, la si chiama in altro modo per ricordare che all'interno di quel contesto che si è generato con (function(mv), lei non è più editabile e la si usa solo in "modalità lettura ed esecuzione"
  2. Proprio per quello che ho detto nella risposta alla domanda 1, mv è solo di lettura ed esecuzione, quindi se si vuole aggiungere variabili globali (anche se il consiglio è quello di evitare sempre la globalità e cercare di isolare e "modularizzare") allora le si aggiunge attraverso una funzione. (questa cosa in particolare è un retaggio dei linguaggio più severi come C e famiglia o PHP dove ci sono classi, moduli, namespace, variabili pubbliche e private, eccetera)
  3. Sarebbe bello se l'utente non dovesse rispettare nessuna dipendenza, una volta attivato un gadget, quello funziona a se stante, sta in piedi da solo, ma a parte questa utopia, si, sarebbe utile. Samuele 20:00, 24 ott 2014 (CEST)

Cambiamento ID namespace Page e Index[modifica]

Ho intercettato una discussione sul possibile cambiamento (unificazione) del numero dei namespace Page e Index; occhio. Spaccherà molte chiamate API sia in javascript che nei bot. --Alex brollo (disc.) 10:29, 24 ott 2014 (CEST)

Sarà un'ottima occasione per pulire tutto commons.js, ci sono tante cose vecchie che non conosco, e altre nuove con cui però non sono familiare, nonostante il via libera, ho ancora paura di agire :( Un po' alla volta però lo affronterò, ma da solo non ce la farò mai ;) Samuele 20:10, 24 ott 2014 (CEST)
Perchè non inserisci commenti nei punti meno chiari? Magari dalle risposte dentro lo stesso commento verrà fuori un minimo di documentazione. ;-) --Alex brollo (disc.) 23:21, 26 ott 2014 (CET)
@Samuele Papa: Dai un'occhiata anche al Common.js di fr.source. Il contenuto degli script è profondamente diverso, ma l'impostazione generale è da copiare; volendo fare meglio, bisognerebbe spostare via dal namespace windows le funzioni, ma questo richiede la revisione di tutti gli altri script dipendenti da tali funzioni; al momento eviterei.... per ora mi pare sufficiente che le funzioni pubbliche dichiarate in Common.js siano raggruppate e ordinate. --Alex brollo (disc.) 10:46, 27 ott 2014 (CET)
Mi riprometto di darti una mano; già riordinare Common.js raggruppando in testa le variabili, poi le funzioni, infine i millanta document.ready sarebbe qualcosina. Se lo faccio, lo faccio in MediaWiki:Common-Sandbox.js. --Alex brollo (disc.) 13:11, 27 ott 2014 (CET)
Cercherò anch'io di inserire quanti più commenti riesco sul Common.js, e riordinare per quanto possibile. Procediamo un passo per volta e piano piano le cose diverrano più chiare. Candalùa (disc.) 14:35, 27 ott 2014 (CET)
Lascio Candalua lavorare direttamente su Common.js e continuo (pian piano) su Common-Sandbox.js; poi "fonderemo le idee". --Alex brollo (disc.) 16:09, 27 ott 2014 (CET)
Alex e Samuele (e chi altro volesse unirsi): ho iniziato a riordinare il Common.js; provate a dare un'occhiata, in particolare ai vari TODO che ho lasciato, e cercate di aggiungere informazioni dove potete. Candalùa (disc.) 17:40, 27 ott 2014 (CET)
Lo farò ma... ho trovato una pesante distrazione: ho capito da dove viene, e come si chiede, l'OCR dei file djvu; era l'anello mancante nell'evoluzione di newThumbs :-) Alex brollo (disc.) 17:55, 27 ott 2014 (CET)

Template Gap[modifica]

Per i testi teatrali in versi, c'è spesso bisogno di "indentatori" per le battute brevi che spezzano il verso. Io uso di solito {{spazi}} che ha un difetto: lo spazio in carattere proporzionale è piccino, per una indentatura grossa ce ne vogliono anche più di 60, l'html viene una cosa orrenda, con quelle catene di &nbsp;.

Perchè {{Gap}} è fortemente sconsigliato? Quali sono i "casi particolari" in cui usarlo? Ho provato a modificarne il motore da così:

<span style="display:inline-block; width:{{{1|2em}}};">&nbsp;</span>

a così:

<span style="letter-spacing:{{{1|2em}}};">&nbsp;</span>

e funziona. I motivi per scoraggiarne l'uso permangono? --Alex brollo (disc.) 23:18, 26 ott 2014 (CET)

Progetto: tool per estrarre bene il text layer dei djvu[modifica]

Ho in mente lo schema per un bot su Labs, che restituisca quando l'utente vuole (e non solo al momento della creaizone di una pagina) lo strato testo di una pagina djvu "come dico io" (ossia scegliendo il dettaglio a cui ottenere il testo, fino al massimo possibile), ma mi manca l'energia per risolvere le parti che sarebbero quelle più banali per un programmatore, in particolare il "giro di chiamate ajax" da wikisource al bot e restituzione del risultato.

Se qualcuno mi aiuta a creare l'interfaccia, poi io potrei darmi da fare per i dettagli delle chiamate a DjvuLibre da python su Labs (previo upload al volo del djvu su Labs; l'importazione da Commons con un buon cURL è molto veloce), e per la loro interpretazione e formattazione, o su Labs, o anche via js in locale, operando sul testo restituito. Forse potrei farcela da solo, ma sono certo che verrebbe fuori un accrocchio indicibile e rivoltante per un vero programmatore.

Qualcuno ci sta? --Alex brollo (disc.) 17:04, 27 ott 2014 (CET)

OOPPPPSSSS ....[modifica]

Aggiornamento: ho appena trovato (grazie al riordinamento di Common.js che Candalua ha cominciato su sollecitazione di Samuele: magnifica idea!) quali sono gli script che lanciano il caricamento dello strato OCR dai djvu. Da qui comincia una nuova avventura.... --Alex brollo (disc.) 17:57, 27 ott 2014 (CET)

In effetti, gli script di Phe, che ho trovato in oldwikisource, restituiscono un hOCR del testo (ossia: un xml contenente anche le coordinate delle parole). Manca qualcosa, ma come inizio è largamente sufficiente. l'hOCR della pagina corrente sarà conficcato in localStorage.hOCR. --Alex brollo (disc.) 22:58, 27 ott 2014 (CET)
Primo risultato: in newThumbs si può caricare al volo, su nuova pagina (in cui il sistema di caricamento automatico non carica l'OCR) il testo, ricavato dagli script OCR.js di Phe, con piccole modifiche integrate, per ora, in Utente:Alex brollo/pagina.js. Si tratta di due sole funzioni, chiamate alex_do_hocr() e alex_hocr_callback(); la prima è una chiamata semplificata ajax che restituisce l'hOCR della pagina, prodotto da un tool di Phe per trasformazione del layer testo djvu in hOCR, la seconda utilizza (per ora in modo primordiale) l'hOCR per estrarre il testo suddiviso in linee; l'hOCR originale della pagina corrente è memorizzato in localStorage.hOCR e il testo in localStorage.OCR. Ciò avviene, per ora, dopo la pressione del pulsante OCR nella maschera di edit di newThumbs; ma può essere facilmente esteso all'interfaccia di edit usuale. Disponendo delle coordinate almeno delle parole, e talora anche dei blocchi di testo di ordine superiore (paragrafi, linee...) in una struttura xml, ossia: facilmente elaborabile con jQuery, il campo dei possibili sviluppi è affascinante, è il sogno dei più audaci tool dreamers. Intravedo, con un po' di dedizione e di sudore jQuery:
  1. il riconoscimento delle aree poem;
  2. il riconoscimento dei testi centrati;
  3. il riconoscimento degli spazi bianchi fra le linee;
  4. il riconoscimento delle dimensioni dei font;
  5. il rinonoscimento delle aree di testo header e footer;
  6. i testi in formato tabella.
Coraggio ragazzi: diamoci dentro. Alex brollo (disc.) 08:25, 28 ott 2014 (CET)

OCR.js[modifica]

Mettetevi su una pagina qualsiasi, vuota o piena, nuova o vecchia che sia (non salvate però...)

Aprite la console js e provate:

  1. do_ocr()  : viene lanciato il vecchio OCR tesseract; il testo della pagina viene rullato.
  2. do_hocr()  : se esiste, viene caricato lo strato testo del file djvu; tuttavia non vengono rispettai i fine linea, il che nei poem è un bel problema. Il testo della pagina viene rullato.
  3. alex_do_hocr(wgPageName)  : svuotate la pagina prima di chiamarlo, perchè un eventuale testo non viene rullato: lo script scrive solo su pagina vuota (nuova o svuotata). Viene lanciata una variante di do_hocr(), che rispetta i fine linea e il cui codice sta in Utente:Alex brollo/pagina.js. Non solo: in localStorage.OCR c'è il testo (identico a quello caricato nella pagina), in localStorage.hOCR c'è il testo in formato hOCR; una miniera di dati. --Alex brollo (disc.) 16:06, 30 ott 2014 (CET)

Update[modifica]

@Candalua: In fiducia, Phe ha aggiornato il suo script mul:MediaWiki.OCR.js, e con l'aggiunta di una sola riga di codice adesso, quando cliccate il testo OCR, viene caricato in localStorage.ws_hOCR il testo del file xhtml che contiene l'hOCR della pagina (ossia: la "mappatura" x1,y1,x2,y2 di ogni parola). Questo è esattamente quello che mi serve per andare avanti! I test sono in corso su Utente:Alex brollo/hOCRlab.js ma per ora sono script in lavoro, che scavano dentro hOCR ma non producono nulla di praticamente utilizzabile. --Alex brollo (disc.) 11:26, 6 nov 2014 (CET)

Test: Pagina zero[modifica]

Nella sequenza delle pagine, una pagina zero come: Pagina:Così parlò Zarathustra.djvu/0 è irraggiungibile con le freccette di navigazione, eppure esiste. Dà fastidio? Causa qualche scompenso? Io ci provo; una pagina zero, raggiungibile solo chiamandola esplicitamente, avrebbe due vantaggi:

  1. sarebbe un utile contenitore per "oggetti" json specifici per il libro (es. correzioni ricorrenti, formato delle virgolette...)
  2. permetterebbe di allineare mirabilmente i "thumbs" con le pagine, perchè l'elemento 0 sarebbe appunto quella pagina, l'elemento 1 la pagina 1, ecc.

Geek maggiori: a voi le osservazioni. --Alex brollo (disc.) 17:39, 2 nov 2014 (CET)

Non sono sicuro di essere un geek, maggiore o minore che sia, ma ad ogni modo... Premesso che, come al solito, non sono affatto sicuro di aver capito cos'hai in mente; in generale non mi è mai piaciuto molto il fatto di ficcare dati o altri oggetti "strani" in pagine che sono nate per tutt'altri scopi. In particolare il fatto che in nsPagina scatti la proofread extension mi sembra un inutile intralcio per l'uso che proponi. Piuttosto userei un namespace "normale", o cercherei di sfruttare le pagine che già esistono (es. Indice, aggiungendo una o più caselle). Chiediamoci anche: questo "contenitore di oggetti" a chi deve servire, chi lo deve usare? Se la risposta è "più gente possibile", forse è meglio metterlo dove tutti lo possono trovare, invece che "nasconderlo" in una pagina che nessuno si aspetta che esista. P.S. a proposito: le pagine Wikisource:Thumbs ora si possono cancellare, vero? Candalùa (disc.) 11:52, 6 nov 2014 (CET)
La mia idea è: 90% di accesso alla pagina via software; 10% (opzionale) di accesso per l'utente. Situalione analoga a Modulo:Dati; se il formato di memorizzazione di LUA compatibile con un formato Javascript, allora i dati potrebbero essere mescolati nella stessa pagina. Pagine Thumbs: sì, possono essere cancellate tutte (magari conserviamone una "per ricordo" dell'avventura) --Alex brollo (disc.) 12:25, 11 nov 2014 (CET)

Analisi hOCR[modifica]

Sono preso (in modo pervasivo) da un problema statistico non facile: raggruppare elementi simili per valore, a distribuzione qualsiasi, ma con "concentrazioni" intorno a valori modali. Questo mi serve per interpretare le coordinate delle parole e delle linee nell'hOCR, in modo da rispondere ad alcune domande apparentemente banali:

1. è un testo in prosa o in versi? 2. se è in prosa, quali righe sono indentate? 3. vi sono righe speciali per spaziatura - posizionamento? 4. vi sono righe con font di dimensioni diverse?

Aubrey sa qual'è l'antico obiettivo - finalmente, a portata di mano. --Alex brollo (disc.) 12:24, 11 nov 2014 (CET)

Ai curiosi sottopongo due strane funzioni, histog() e groups(), che mi hanno fatto sudare parecchio, stanno per ora in Utente:Alex brollo/pagina.js ... ma in pochi giorni si dovrebbe passare dalla teoria alla pratica; il primo obiettivo è di separare il testo in blocchi di righe omogenee, utilizzando l'artificio tipografico di aumentare decisamente gli spazi fra le righe quando il testo "cambia tipo". Mi sembra più logico spezzare il testo in blocchi logici, e poi proseguire l'analisi blocco per blocco; gli obiettivi più a portata di mano sono il riconoscimento dei titoli dei capitoli o sezioni e la distinzione fra testo in prosa e in versi. Delle due funzioni, svilupperò la seconda; la prima è servita come esercizio.
Scusatemi se in questo momento non riesco a concentrarmi su nient'altro. --Alex brollo (disc.) 23:38, 11 nov 2014 (CET)

Help: selezionare un'area rettangolare in un'immagine[modifica]

@Candalua, Ricordisamoa, L0ll0: Per sviluppare come si deve il progetto hOCR ho bisogno del codice javascript che permetta di selezionare un rettangolo sull'immagine a fronte restituendo le coordinate del rettangolo rispetto all'immagine. Da qui procedo io. Ho visto un sacco di roba sul web per ottenere questo risultato, ma se mi fate la cortesia di prepararmi il codice pronto mi agevolate moltissimo.

PS: bisognerà ricordarsi di disattivare la draggabilità dell'immagine, quando il tool si attiva... basterà eliminare temporaneamente la classe draggable e poi reinserirla? --Alex brollo (disc.) 08:13, 12 nov 2014 (CET)

Non avevi fatto la stessa cosa sul gadget corners? Forse si riesce a scopiazzare da lì... Candalùa (disc.) 10:03, 12 nov 2014 (CET)
No, quella era una soluzione grossolana; io vorrei il classico "punta-trascina-molla" con il mouse, che semina, e poi "tira", un rettangolo semitrasparente. Oltre alla gestione degli eventi mouse, c'è anche la fastidiosa questione dell'allineamento fra le coordinate sullo schermo e le coordinate sull'elemento tenendo conto dei vari overflow.... quella volta avevo rinunciato; ma se adesso recuperiamo uno script decente, vorrei sostituire con il meccanismo nuovo anche il brutto trucco rabberciato su Ritaglio e pure su Imagemap.
Giusto to wet your appetite: l'idea è quella di selezionare pezzi di testo direttamente sull'immagine, dichiarandone con un click il "tipo" (es: poem) e permettendo un'alternativa e un'integrazione al riconoscimento del testo in via totalmente automatica, a cui sto lavorando ma che certamente non funzionerà in casi particolari (es. sarà dura sulle note laterali e sulle tabelle, e probabilmente anche su eventuali annotazioni a fine pagina) --Alex brollo (disc.) 13:54, 12 nov 2014 (CET)

mw.activeElement[modifica]

@Candalua: Ho ficcato in MediaWiki:Gadget-common.js un document.ready tale che memorizza in mw.activeElement l'elemento DOM che riceve il focus, quando tale elemento è uno di quelli in cui si inserisce testo (tutte le textarea, alcuni input filtrati). Questo mi serve per modificare la funzione magica selection(), in modò che lavori sempre e comunque sull'ultimo elemento "significativo" che ha preso il focus ignorando i click su altri elementi (es. link, bottoni). Avrai notato che molti tool di edit NON funzionano su campi speciali (es. sull'header o sul footer della pagina Pagina, o sui campi dei form autore o indice). Questa modifica dovrebbe permettere a tutti i tool che si basano su selection di agire dentro qualsiasi campo. --Alex brollo (disc.) 09:46, 18 nov 2014 (CET)

Vedi modifica a MediaWiki:Gadget-pulsante-rule.js per evitare l'incontrollabile metodo encapsulate e usare invece la nostra funzione incapsula(), capace di agire dovunque sia stato selezionato testo. --Alex brollo (disc.) 22:01, 18 nov 2014 (CET)
Ho verificato che si può anche forzare la memorizzazione di un elemento in ms.activeElement. Eseguita la "forzatura", scriviSel() esegue sull'elemento dichiarato "attivo". Questo permetterà di usare scriviSel() anche su elementi diversi da quello correntemente attivo (es. scrivere RigaIntestazione nell'header anche se il focus sta in un altro elemento, tipo il corpo della pagina) e quindi di emulare bene scriviBox(). Intravedo anche la possibilità di fondere in uno script unico, e più potente, leggiBox() e selection(). E adesso... pausa con un po' di editing.--Alex brollo (disc.) 22:22, 18 nov 2014 (CET)
Una domandina facile per i geek: a cosa serve il parametro "context" che viene passato nelle funzioni callback suggerite dai "piani alti" per i nuovi pulsanti, e perchè la funzione "truccata" che ho infilato in MediaWiki:Gadget-pulsante-rule.js funziona anche senza il parametro. o_O --Alex brollo (disc.) 08:59, 19 nov 2014 (CET)

test in corso[modifica]

Sto testando uno script, per ora funzionante in Utente:Alex brollo/common.js, che rintraccia, in nsIndice, nsPagina e ns0, l'eventuale pagina Indice attiva o collegata, ne registra il nome in localStorage.currentIndex e carica pagelist in localStorage.currentIndexData e il contenuto di Sommario in localStorage.currentIndexSummaryData. Se all'apertura di una nuova pagina l'indice collegato è lo stesso memorizzato, NON ricarica i dati di dettaglio; quindi, su qualsiasi pagina collegata a una pagina Indice, sono disponibili (in genere immediatamente) tutti i dati rilevanti della pagina Indice. Questo consente di riscrivere autoNs0 per velocizzarlo moltissimo sulle pagine Indice lunghe e sviluppare altre applicazioni utili.

Gli oggetti sono memorizzati in localStorage in formato JSON, quindi vanno parsati prima dell'uso. Lo script lo fa automaticamente e gli oggetti correnti sono memorizzati in mw.currentIndexData e mw.currentIndexSummaryData. --Alex brollo (disc.) 09:39, 22 nov 2014 (CET)

Revisione sistema di selezione aree[modifica]

Sto eseguendo dei test per un sistema più semplice e preciso di selezione di aree rettangolari sull'immagine della pagina; la selezione avviene semplicemente mediante spostamento/ridimensionamento di una div semitrasparente resizable e draggable, creata in Utente:Alex brollo/test.js. Il codice è estremamente semplificato con gestione di un minor numero di eventi; le coordinate sono ricavabili dai valori di top, left, width e height della div. Inoltre, la selezione può essere eseguita direttamente sull'immagine a fronte senza necessità di clonarla in un box dedicato.

Oltre alla selezione di parti dell'immagine, e del sottostante strato testo, questa speciale div potrà essere utilizzata in modo inverso, per evidenziare le parti di testo (linee, o parole) in cui sta agendo il cursore della modalità edit. --Alex brollo (disc.) 08:18, 28 nov 2014 (CET)

Ho i primi risultati nei testi di costruzione di una "griglia mobile" per la formattazione delle tabelle (non è semplice ma molto meno complessa di quello che immaginavo). Basta creare delle "div strette" orizzontali e verticali draggabili e confinate in un riguadro. Vediamo come la cosa si sviluppa, e soprattutto se, alla fine, c'è un guadagno evidente in termini di tempo e fatica: se non ci sarà.... via! --Alex brollo (disc.) 00:25, 3 dic 2014 (CET)

Avviso a chi usa javascript: parseTemplate() e rewriteTemplate()[modifica]

Ho "promosso" a MediaWiki:Gadget-common.js lo script parseTemplate(template, testo). E' uno script piuttosto potente; cattura in testo il template template e lo trasforma in un oggetto contenente nome e contenuto di ogni parametro, e l'ordine dei parametri. Una seconda funzione, rewritTemplate(), permette di ricostuire il template "standardizzato", con le eventuali modifiche. Buon divertimento. --Alex brollo (disc.) 09:07, 9 dic 2014 (CET)

Revisione recupero dati della pagina Indice[modifica]

@Candalua: Dopo alcune sperimentazioni di fr.source e importazione nel common.js personale, ho aggiunto a MediaWiki:Gadget-common.js alcune funzioni piuttosto potenti che:

  1. all’apertura di una pagina Pagina o di una pagina ns0 determinano se la pagina è connessa a una pagina Indice, e a quale;
  2. caricano sia in alcune variabili dell’oggetto mw, che in alcuni dati in localStorage, il nome dell’indice connesso e alcune serie di dati utili tratti da pagelist, Sommario ecc; le variabili hanno prefisso currentIndex;
  3. nel caso che la pagina sia connessa alla stessa pagina Indice già memorizzata in localStorage (ossia, se il "currentIndex", l’indice corrente, resta lo stesso), le variabili locali sono caricate direttamente da localStorage senza rileggere la pagina Indice.

Questo significa che, ad esempio, passando da pagina a pagina di uno stesso indice; oppure passando da pagina Pagina a testo ns0 collegato alla pagina; oppure passando da uno all’altro di capitoli di uno stesso libro, il parsing della pagina Indice non viene ripetuto il che sveltisce molto le cose.

Sulla base di questo accrocchio, possono essere riviste, e sveltite, molte procedure complesse, come la costruzione automatica del codice di transclusione dei nuovi capitoli e molto altro (es. il collegamento, se c’è, con le immagini originali su IA). Estendendo ulteriormente il numero di dati ottenuti da Indice, sono pensabili altri interessanti sviluppi. --Alex brollo bis (disc.) 09:09, 17 dic 2014 (CET)

Occhio a value[modifica]

Per misteriosi motivi, fino a ieri alcuni tool (tipo EditInView e newThumbs) funzionavano nonostante un errore logico nel codice; poi improvvisamente hanno cessato di funzionare; le aree testo restavano tristemente vuote, senza che ci fosse il minimo indizio o il minimo messaggio di avviso o di errore.

Per fortuna ho trovato rapidamente la soluzione. Le due istruzioni, che io credevo analoghe:

$("textarea").eq(0).attr("value","bla bla bla");
$("textarea").eq(0).val("bla bla bla");

non sono uguali affatto, la prima è errata. Eppure funzionava! Boh; in ogni caso, quella giusta è la seconda, se avete una textarea che fa le bizze controllate e correggete. --Alex brollo (disc.) 13:32, 21 dic 2014 (CET)

@Alex brollo: il motivo è tutt'altro che misterioso. Le due istruzioni che citi non sono più equivalenti da jQuery 1.9. Alcuni mesi fa, contestualmente all'aggiornamento di jQuery da 1.8.3 a 1.11.1 (phab:T46740, gerrit:133477), è stato introdotto in MediaWiki jQuery Migrate per facilitare la transizione. Infatti questa funzionalità di jQuery Migrate riguarda proprio il caso di .attr() usato per popolare le aree di testo. Come anticipato da Krinkle, però, jQuery Migrate è stato rimosso a partire da MediaWiki 1.25wmf12, quindi su Wikisource dal 16 dicembre. Dov'eri mentre jQuery Migrate emetteva avvisi nella console del tuo browser? ;-) --Ricordisamoa 02:23, 23 dic 2014 (CET)
Ovviamente, come il solito, dormivo. :-) Alex brollo (disc.) 08:55, 23 dic 2014 (CET)

Domanda su selettori css[modifica]

Chi mi sa dire perchè questo css (attivo nel mio common.css) non funziona?

.cellbordert>td {border-top:1px solid black;}

Nella mia testa dovrebbe significare: "seleziona tutti i td contenuti in un elemento di classe .cellbordert e assegna loro un border-top:1px solid black"; ma non funziona. Viene forse rullato da un css caricato in modo asincrono? Dove sbaglio? Codice test qui: Progetto:Trascrizioni/Tabelle. --Alex brollo (disc.) 11:51, 31 dic 2014 (CET)

Non esattamente. La > significa "prendi solo i figli diretti" e non tutti i discendenti. cellbordert a che elemento è applicato? Ho visto. Dovresti mettere lo spazio invece del >. Candalùa (disc.) 11:55, 31 dic 2014 (CET)
@Candalua: Hurrà! Grazie, adesso sì che va! Adesso si può in un colpo solo dare un border specifico generale a tutte le celle, e poi modificare con tl|Cs solo quelle |anomale" rispetto al default. Il codice di tabelle complicate si semplificherà parecchio! Faccio ancora un po' di test e poi monto in Common.js--Alex brollo (disc.) 12:35, 31 dic 2014 (CET)

Canvas[modifica]

Un annetto fa ho rovistato nei misteri del canvas, trovate in Utente:Alex brollo/CanvasLab un'interfaccina per trasformare un'immagine (non più larga di 600 px) in un canvas; per farla funzionare dovete caricarvi Utente:Alex brollo/CanvasLab.js. E dopo? Dopo, per ora, è affar vostro :-) ; l'idea sarebbe di montare la cosa su Ritaglio permettendo quindi di estrarre un vero ritaglio della pagina con lo stesso meccanismo di selezione grafica, eventualmente di modificarlo con qualche filtro, e poi di salvarlo e/o caricarlo come File locale e/o come File su Commons. Ma per ora è solo un'idea. --Alex brollo (disc.) 23:59, 4 gen 2015 (CET)

@Barbaforcuta: Partito il tentativo di inserire un tag canvas in Ritaglio. Tenuto conto della complessità di Ritaglio, non opero sullo script ma su un suo clone: MediaWiki:Gadget-cornersAlpha.js. Chi vuole seguire i lavori dal vivo, o (magari!) collaborare nel dissodamento del problema, basta che disabiliti Ritaglio e si colleghi al clone aggiungendo nel suo common.js importscript("MediaWiki:Gadget-cornersAlpha.js"); . --Alex brollo (disc.) 07:36, 6 gen 2015 (CET)
Habemus canvas
Habemus canvas :-) --Alex brollo (disc.) 18:35, 6 gen 2015 (CET)
Fine corsa.... sono incappato nell'errore "The canvas has been tainted by cross-origin data", non ci posso fare quasi niente se non salvarlo come immagine png nel pc; troppo poco rispetto a quello che speravo. Va be' ci ho provato. --Alex brollo (disc.) 23:57, 6 gen 2015 (CET)

Refactoring del progetto Canvas[modifica]

Vediamo se fra i rottami del progetto resta qualcosa.

  1. nonostante non sia minimamente elaborabile come canvas (aimè), l'immagine "croppata" può essere salvata sul PC come file PNG; è anche pensabile che si costruisca un nome automatico e si precompili un template Information adatto a un'immagine derivata. Resterebbe a carico dell'utente il "fastidio" di verificare, ed eventualmente ritoccare, l'immagine scaricata e di caricarla su Commons.
  2. serve anche a verificare che le coordinate per il ritaglio siano corrette, e con un click e una banale chiamata GET a un tool python su Labs potrebbe passargli tutto ciò che serve per estrarre la pagina dal file djvu come TIFF, alla massima risoluzione possibile, convertirla pin png o in jpg, ritagliarla e caricarla su Commons completa di nome automatico e di template Information compilato, sempre che il bot associato al tool abbia un account su Commons (cosa che al momento il mio bot, aimè, non ha). Se qualcuno con un bot globale su Labs ritiene la cosa fattibile e interessante, io posso passare qualche suggerimento sulle chiamate djvuLibre. --Alex brollo (disc.) 15:11, 7 gen 2015 (CET)

Contrordine[modifica]

Una risposta su Wikitech-l risolve il problema CORS e fa ripartire l'idea canvas (a questo punto l'immagine non è più "sporca" e può essere modificata e salvata); grazie Ricordisamoa. Ma mi prendo una pausa dagli "smanettamenti" e ritorno a lavorare smettendo di impersonare "braccia rubate all'agricoltura" ;-) --Alex brollo (disc.) 22:23, 8 gen 2015 (CET)

wg*[modifica]

Avremo presto degli avvisi (phab:T58550) quando vengono usate variabili globali invece di mw.config. Invito in particolare Alex brollo a risolverli ;-) --Ricordisamoa 13:19, 5 gen 2015 (CET)

Vorrei capire in cosa differisce la memorizzazione e recupero di un oggetto dentro mw con config, get, set, piuttosto che l'assegnazione diretta. Da un po' faccio grandi sforzi per "ripulire" dalle variabili globali, ma l'argomento è veramente ostico.... e alle volte questa "corsa in avanti" nella potenza, complessità e rigore del software sembra quasi fatta apposta per scoraggiare chi programma come può.
Grazie comunque della segnalazione. --Alex brollo (disc.) 22:50, 5 gen 2015 (CET)
@Ricordisamoa: Giusto per iniziare il chiarimento: io non tocco mai in modifica le variabili wg*, ma le leggo spesso; ed in effetti le leggo come globali, invece di leggerle con mw.config.get(wg*). Posso sostituire direttamente le chiamate dirette con le chiamate mw.config.get(wg*), o conviene caricare i valori in variabili locali e poi usarle? Oppure devo farlo solo se uso la variabile ripetutamente dentro un determinato scope? E in questo caso, "ripetutamente" a che numero di ripetizioni corrisponde? E la mia nuova policy di non creare variabili e funzioni globali, ma se mi servono cose globali, di definirle come elementi dell'oggetto globale mw come ho provato a fare in Ritaglio, è accettabile? --Alex brollo (disc.) 07:49, 6 gen 2015 (CET)
@Alex brollo: io uso mw.config.get() a meno che una stessa variabile non sia richiamata molte volte (vedi la regola del 3, per esempio). È anche da considerare che il valore, una volta assegnato ad una variabile locale, non può essere sovrascritto con mw.config.set(). --Ricordisamoa 12:47, 6 gen 2015 (CET)
Grazie, regola del tre, me ne ricorderò. E adesso sotto con il progetto canvas (assodato che il tool di cropping disponibile non mi piace). Magari sarà la riscoperta dell'acqua calda ma pazienza. --Alex brollo (disc.) 16:31, 6 gen 2015 (CET)
Aimè, il progetto canvas si è schiantato sulla questione CORS. --Alex sloggato 10:26, 7 gen 2015 (CET) Ripartito.

Esplorazione DIY di wbgetentities[modifica]

Sto caricando e parsando come posso ciò che wikidata restituisce con una chiamata action=wbgetentities, filtrando e semplificando. Una prima funzione che acchiappa l'output relativo alla pagina corrente lo trovate in User:Alex brollo/Ajax; si starebbe un attimo a lanciare la funzione di default nelle pagine collegate a un elemento wikidata e sia in una variabile di memoria, che in localStorage, sarebbe caricato l'oggetto risultante. Così com'è, tale oggetto è praticamente inutilizzabile; la fatica prossima ventura è di renderlo utilizzabile emulando, fin dove possibile, #property.

La necessità di disporre di questi dati nasce dall'esigenza di accedere a tali dati in edit, cosa che non è possibile con Lua, che si scatena solo in view/submit. Corriggetemi se sbaglio o se mi accingo alla solita fatica di rediscovering the wheel. --Alex brollo (disc.) 10:29, 14 gen 2015 (CET)

Intanto ho capito che le properties sono entities e che quindi le becco con wbgetentities. Poi mi pare di aver capito che due letture API bastano: nella prima, si acchiappa l'item e tutte le sue proprietà; nella seconda, si impacchettano in una lista tutte le entities contenute nell'item e di ciascuna si ottiene la descrizione in italiano. Ci provo :-) --Alex brollo (disc.) 20:05, 14 gen 2015 (CET)
Sembra funziare, il parsing dell'item per beccare tutte le entità annidate (P e Q) funzia, manca solo l'implementazione della chiamata di traduzione item->label in italiano; dopodichè dovrebbe essere possibile convertire l'intero oggetto inutilizzabile in un oggetto utilizzabile, salvando, per ora, una variante semplificata (nome della proprietà->valore della proprietà). --Alex brollo (disc.) 11:46, 15 gen 2015 (CET)

Nota banale su Lua[modifica]

Il template {{Cs}} costituisce anche una prova della (nota) capacità di Lua di eseguire il parsing di una stringa con possibilità di regex perfino superiori a quelle "canoniche" (in particolare, capaci di risolvere strutture annidate tipo "template dentro template" o "tag html dentro tag html"); sono talmente abituato a pensare in termini di sintassi template (in cui le funzioni di manipolazione delle stringhe sono state deliberatamente impedite) che non è facile capire quanto la fine di questa limitazione apre nuove possibilità.

Un template che secondo me andrebbe luizzato subito, usando queste tecniche, è Centrato, costruendo un super-parametro di formattazione che inserisca, nel modo più semplice e intuitivo possibile, nel template tutta la potenza di {{Type}}. In un colpo solo si potrebbe formattare perfettamente gran parte delle terribili righe dei frontespizi, in cui gli utenti più attenti alla formattazione desiderano controllare tutto (grandezza caratteri, spazi fra le linee, spazi fra caratteri....); tutto potrebbe essere passato in un solo parametro intuitivo, tipo: grandezza:2em, interlinea:3em, spaziatura:10px, maiuscoletto, italico ma anche g2em i3em s10px sc it per chi vuol far prima. Alex brollo (disc.) 10:40, 15 gen 2015 (CET)

Ripulitura delle chiamate dirette alle variabili wg*[modifica]

Ho cominciato la ripulitura delle chiamate diretta alle variabili wg* (wgPageName, wgAction...) ma non so come fare a scovarle tutte; perlomeno non so come fare operando da Chrome. In Firebug, che uso poco, avrei strumenti più efficienti?

Per quelli che non conoscono il problema: la chiamata diretta di variabili wg* è deprecata, e va sostituita con la chiamata "canonica" mediante mw.config.get("wg*"), come recentemente ci ha ricordato @Ricordisamoa:. Le console sono ingombre di deprecazioni, o meglio, di imprecazioni virtuali. --Alex brollo (disc.) 16:34, 15 gen 2015 (CET)

@Alex brollo: ho generato un report statico (URL provvisorio e instabile!) che credo ti sarà utile. --Ricordisamoa 11:27, 17 gen 2015 (CET)
Grazie! La console per ora è tacitata.... non credo che la pulizia sia finita, ma il grosso è fatto. --Alex brollo (disc.) 13:52, 17 gen 2015 (CET)
Grazie a te! Ho aggiornato l'elenco. --Ricordisamoa 14:00, 17 gen 2015 (CET)
@Ricordisamoa: Rilancialo per favore, è riemerso un avviso per un wgTitle sfuggito, e non lo trovo...--Alex brollo (disc.) 15:41, 17 gen 2015 (CET)
@Alex brollo: aggiornato di nuovo. Tieni presente che (per motivi di performance) copre solo il namespace MediaWiki, quindi è probabile che il wgTitle sia in uno script utente... Puoi però aggiungere il parametro "debug=1" alla querystring, il ResourceLoader non comprimerà il codice e i messaggi della console risulteranno più utili. --Ricordisamoa 04:04, 18 gen 2015 (CET)
@Ricordisamoa: Infatti! Beccato e soppresso, adesso la console tace :-)
Spero che la prossima volta non mi chiedano "sistema le nuove variabili fuori del namespace globale".... Quella sì che sarebbe durissima :-( --Alex brollo (disc.) 08:43, 18 gen 2015 (CET)

toollabs:itsource[modifica]

Ve lo ricordate? Giusto per dare un (illusorio?) segnale di vita, ho riavviato il webservice e messo un cartello in home page. --Ricordisamoa 11:17, 16 gen 2015 (CET)

@Ricordisamoa: itsource è un tool dormiente, sostituito da altri bot attivi e operosi. Ho perso la mano con python, aimè, e sono ben contento che altri se ne occupino. Approfitto per chiederti lumi e aiuto per l'istallazione su Toollabs di unpaper o di uno script simile. Il progetto opallibriantichi potrebbe essere riattivato. --Alex brollo (disc.) 08:54, 17 gen 2015 (CET)

API Internet Archive[modifica]

Non so se serve a qualcuno (vedo qualche intervento di un annetto fa) ma io adesso sto lavorando con Python sulle API di IA, tendenzialmente per prendere alcuni metadati dei libri. Se a qualcuno serve qualcosa, lo dica :-) --Aubrey (disc.) 10:20, 17 gen 2015 (CET)

Perchè non usi python da Tool Labs? C'è un progetto itsource abbandonato che aspetta di essere adottato.... :-) --Alex brollo (disc.) 15:53, 17 gen 2015 (CET)

Caricamento immagini da canvas: il passo finale[modifica]

@Ricordisamoa, Candalua: Nel progettuncolo canvas il passo finale è quello di eseguire l'upload del file jpg, che sta nella memoria del browser prodotto da .toDataURL, su Commons. Vista la pagina //www.mediawiki.org/wiki/API:Upload mi pare che i comandi API da utilizzare siano quelli previsti nel Chunked uploading. Sono sulla strada giusta? Se sì, proverò prima a caricare immagini su wikisource, dove posso far pulizia personalmente se qualcosa va storto, e solo dopo proverò su Commons.

Per inciso: avevo equivocato qualcosa nella mia richiesta di un flag bot su Commons, un commento finale positivo alla richiesta mi aveva dato l'impressione di aver ricevuto il flag... non l'ho ricevuto, quindi non posso usare il bot python per i caricamenti nemmeno se sapessi come fare. Caricare via javascript è un'altra cosa, perchè la richiesta via javascript è una richiesta normale che viene inviata da un utente normale. --Alex brollo (disc.) 08:18, 20 gen 2015 (CET)

MediaWiki:Common.css[modifica]

Sto facendo caso ai warning e agli info dei file css e js, e li sto eliminando tutti nella "mia roba"... in MediaWiki:Common.css che maneggio con cautela ci sono qualcosa come alcune decine di warnings e di info. Se qualcuno di quelli bravi vuole fare pulizia.... ;-) --Alex brollo (disc.) 11:32, 21 gen 2015 (CET)

Mediawiki:Common.js[modifica]

Ho visto che all'inizio del common.js è stato aggiunto il codice $("#mw-content-text > p > br").remove();. Da quel che capisco rimuove i doppi caporiga. Volevo chiedere / suggerire di spostarlo nel common.css (per una questione generale di fruibilità a favore di tutti gli utenti, anche quelli che non hanno javascript attivato), ma soprattutto di limitarlo solo nei namespace dove effettivamente serve (es. principale, pagina, indice, ???, ecc.) senza influire sugli altri namespace (es. utente). Ho testato il seguente codice che dovrebbe funzionare:

/* Elimina i "caporiga" multipli, solo per i namespace principale (0), pagina (108) e indice (110) */
.ns-0 #mw-content-text > p > br,
.ns-108 #mw-content-text > p > br,
.ns-110 #mw-content-text > p > br {
    display: none;
}

Grazie in anticipo. --FRacco (disc.) 22:33, 22 gen 2015 (CET)

Non avevo notato questa modifica. @Barbaforcuta:, qual è il motivo per cui era stata fatta? Can da Lua (disc.) 09:55, 23 gen 2015 (CET)
In attesa che Barbaforcura risponda, suggerirei di discutere la questione dei br: io cercherei di evitarli SEMPRE o almeno quasi sempre tranne che in casi assolutamente particolari (alcune note molto complesse, alcune annotazioni a lato, o cose del genere). Concordo comunque con l'idea che javascript NON dovrebbe modificare l'aspetto del testo vero e proprio: le modifiche ottenute sono illusorie, e non esportabili. --Alex brollo (disc.) 10:08, 23 gen 2015 (CET)
Quella modifica era una toppa momentanea per la Pagina Principale e il Portale Comunità, perché non ho capito quel br da dove spuntasse fuori. Annullatela pure se dà problemi; vedremo poi in che altro modo risolvere quell'imperfezione grafica.--Barbaforcuta (disc.) 19:10, 23 gen 2015 (CET)
A maggior ragione, se è solo per la pagina principale sposterei nel common.css (in attesa di risolvere il problema). Guardate ad esempio Aiuto:Guida del wikisourciano principiante (sia con Chrome sia con ie è illeggibile, anche se in fase di anteprima è tutto ok!). Grazie. --FRacco (disc.) 02:28, 24 gen 2015 (CET)
.page-Pagina_principale #mw-content-text > p > br { display: none; }

Il br era causato dall'uso del template:Fine blocco, che ora ho tolto. Provate a vedere se vi risulta tutto ok. Can da Lua (disc.) 10:36, 24 gen 2015 (CET)

Dubbio sulla sicurezza e JsBots[modifica]

Sapete che sto sperimentando vari tools per l'editing di pagine via Javascript, usando API. Man mano che procedo osservo che non ci sono limiti alle possibilità di questo tipo di edit, che rientrano fra quelli "normali" dell'utente. Non esistono nemmeno - mi pare - sistemi di controllo del numero di edit, in teoria (e anche in pratica, da test preliminari fatti cautamente) si possono lanciare "raffiche" di edit consecutivi a grande velocità.

Mi domando: ci sono problemi seri di sicurezza? Non trovo doc che metta in guardia dall'abuso di queste tecniche; il sistema è protetto solo dalla strategia "security by obscurity"? --Alex brollo (disc.) 12:11, 27 gen 2015 (CET)

Che io sappia, non esistono limiti all'edit throttle (ci sarebbe $wgRateLimits, ma non mi risulta che sia in uso in Wikimedia). Una volta, trovandomi senza PC con Python, ho improvvisato per Horcrux92 un "bot" in JavaScript che ha ha raggiunto 315 modifiche al minuto (284 senza contare quelle cancellate). Come di ogni strumento potente, anche delle API si può abusare — perfino all'insaputa della vittima, in certi casi — pertanto è sconsigliabile eseguire codice da fonti non verificate. --Ricordisamoa 16:10, 28 gen 2015 (CET)

Un problema: tecniche di allineamento[modifica]

Il problema è il seguente. Dato questo testo:

52

     Poiche pur veggio tormi
     Da un’acerba partita
     Il mio ben, la mia vita;
     Ma che parl’io di ritrovar accenti
     Conformi à miei tormenti?
     Ahi, che sì grave io sento il mio duol farsi,
     Che tempo è di morir, non di lagnarsi.

MAD. XXII.

O Ciel deh per pietà dammi tanti occhi
Quante hai tù chiare stelle
     Si che l’aspro dolor, che ’l cor mi svelle
     Per la dura partita
     In pianto almen trabocchi.
     Ma dove (ohime) poich’io son tutta ardore
     Havrò in mio scampo lagrimoso humore?
     O dolente mia vita
     Com’ogni nostro ben ratto se n’ fugge.
     Non m’ancide il dolor, e non mi strugge
     L’incendio, e non mi porge il pianto aìta.

MAD. XXIII.

NOn è gran Mago Amore,
Se da un bel volto candido, e vermiglio
     Tragge di morte un languido pallore?
     Se da ridente ciglio
     Move talhor per gioco
     Pena, ch’ancide un core?
     Se da la neve il foco,
     Se da tranquillo mar fiere procelle
     Desta, e la pioggia da serene Stelle?

All-

e dato questo secondo testo:

Poiché pur veggio tormi . -
Da vn'acerba partita
Il mio ben , la mia vita ;
Ma che parl'io di ricrouar accenti
Conformi a miei tormenti ?
Ahi,che sì graue io lento il mio duol farti,
Che tempo è di morir, non di lagnarti .
M A D. XXII.
OCiel deh per pietà dammi tanti occhi
Quante hai tu chiare ftelle
Si che l'afprp dolor, che'l cor mi fuelle
Per la dura partita q
In pianto almcn trabocchi.
Ma doue ( ohimè) poich'io fon tutta ardore
Haurò in mio (campo lagrimofo humore >
O dolente mia vita
Com'ogni noftro ben ratto fé n'fugge .
Non m'ancide il dolor, e non mi ftrugge
L'incendio,e non mi porge il pianto aita.
M A D. XXIII.
NOn è gran Mago Amore,
Se da vn bel uolto candido,e vermiglio
Tragge di morte vn languido pallore J
Se da ridente ciglio
Mone talhor per gioco
Pena , ch'ancide vn core ?
Se da la neue il foco ,
Se da tranquillo mar fiere procelle
Defta,e la pioggia da ferenc Stelle ?
i ; Air*

come si chiama la procedura per confrontare i due testi, e far corripondere ogni parola del testo 1 alla corrispondente parola del testo 2? Che software fanno questa operazione? Alex brollo (disc.) 17:08, 17 feb 2015 (CET)

Intendi la diff? Can da Lua (disc.) 17:27, 17 feb 2015 (CET)
No... la diff è tutt'altro. Qui si tratta di trovare il miglior appaiamento possibile 1:1 ignorando le differenze. Fatto questo appaiamento, diventa possibile sostituire, nello strato testo di un file djvu, il risultato dell'OCR con la correzione umana dell'OCR. Sono anni che ci penso, ma non so da dove cominciare. Ci sono alcune centinaia di migliaia di pagine wikisourciane che attendono questa procedura :-( --Alex brollo (disc.) 18:26, 17 feb 2015 (CET)

Ok, quello che dici tu credo si chiami w:en:Approximate string matching. Ricordo che anni fa avevo pure fatto uno script che calcolava la distanza di levershtein o come cavolo si chiama. Can da Lua (disc.) 20:52, 17 feb 2015 (CET)

Quasi.... Vediamo se riesco a esprimere il problema.
"Date due sequenze A, B simili identificare per ogni elemento di B il corrispondente elemento di A, tenendo conto della possibilità che un elemento A potrebbe corrispondere a un gruppo contiguo di elementi B o o l'inverso"
Esempio:
Sequenza originale A: [Desta,] [e] [la] [pioggia] [da] [serene] [Stelle?] da allineare con B: [Defta,e] [la] [pioggia] [da] [ferenc] [Stelle] [?]
Sequenza corretta A: [Desta, e] [la] [pioggia] [da] [serene] [Stelle][?] sequenza B: [Defta,e] [la] [pioggia] [da] [ferenc] [Stelle] [?]
Si tratta solo di spostare alcune parentesi quadre ;-) --Alex brollo (disc.) 09:38, 18 feb 2015 (CET)

Dunque. Tu vuoi suddividere la stringa A nelle singole parole che la compongono, e poi associare a ciascuna di esse il corrispondente frammento nella stringa B. Io proverei a (s)ragionare così:

  • siccome le singole parole possono ricorrere più volte, se proviamo ad allineare parola con parola è facile cadere in falsi match. Io cercherei di allineare prima le stringhe intere.
  • Prendi le stringhe A e B, e cerchi la più lunga sottosequenza comune (LCS) tra le due stringhe.
  • Quando l'hai trovata, spezzi le stringhe in 3 parti: l'inizio, la parte comune, la fine.
  • Poi ripeti ricorsivamente la ricerca della LCS per l'inizio e la fine, spezzando ogni frammento in 3 parti come prima.
  • Quando non trovi più delle LCS di lunghezza accettabile (es 3-4 caratteri), ti fermi.
  • A questo punto hai due serie di frammenti, appaiati 1-1: solo che alcuni sono uguali tra A e B, altri sono diversi. Ogni frammento può essere un pezzo di parola o contenere più parole.
  • A questo punto però a te servono le parole. Scorri l'elenco dei frammenti A: se dentro un frammento ci sono degli spazi, lo spezzi in n parole. Poi devi spezzare anche il corrispondente frammento B...
    • Se i frammenti A e B erano uguali tra loro, la cosa è banale perché anche gli spazi coincideranno tra A e B;
    • se erano diversi, devi cercare il punto esatto in cui spezzare B: ad esempio scorri le n parole del frammento A e se trovi la parola uguale in B sai dove spezzare; altrimenti devi probabilmente cercare uno spazio o un segno di punteggiatura "vicino", oppure spezzare all'incirca alla distanza che corrispondenza alla lunghezza della parola A che cerchi.
  • Quando arrivi alla fine di ogni frammento, devi vedere se c'è uno spazio alla fine di esso o all'inizio del frammento successivo: se sì, l'ultima parola del frammento appena processato va ricongiunta al frammento successivo
  • Alla fine in teoria dovresti avere le due sequenze di parole allineate 1-1 tra loro.

Potrebbe avere un senso tutto ciò? Can da Lua (disc.) 12:08, 19 feb 2015 (CET)

Intanto, grazie di averci riflettuto. Hai al volo l'indirizzo di uno script js per LCS? Tuttavia, vedo un elemento critico proprio nel passo 1 - il LCS. In certi OCR il riconoscimento è così basso, che la lunghezza del LCS (immagino, spesso minore di 10 caratteri!) potrebbe essere irrilevante e sostanzialmente casuale. Se si sbaglia il primo appaiamento, poi succede il disastro. Penso che la strada da battere invece sia quello di analizzare i separatori - gli spazi bianchi non sono riconosciuti sistematicamente, ma certamente sono il "carattere" riconosciuto meglio. Quindi vorrei ideare un algoritmo che confronti il "ritmo" del flusso dei caratteri - tenendo conto soprattutto della sequenza della lunghezza delle "parole" a prescindere dall'uguaglianza dei caratteri che le compongono.
Defta,e la pioggia da ferenc Stelle ? -> 7,2,7,2,6,6,1
Desta, e la pioggia da serene Stelle? -> 6,1,2,7,2,6,7
Qui c'è un match su 2,7,2,6 bellino, perchè prescinde totalmente dai caratteri, su cui si può usare il confronto dei caratteri come elemento di verifica del tutto indipendente. Alex brollo (disc.) 16:07, 19 feb 2015 (CET)

Sembra simile all'algoritmo usato per ContentTranslation, ben descritto qui. Off-topic? --Ricordisamoa 16:15, 19 feb 2015 (CET)

Grazie! Lo guarderò, anche se - per esperienza - gli algoritmi su questi argomenti scritti da "quelli bravi" sono così astratti che non riesco a capirli; per dire, per calcolare un "algoritmo di similitudine fra stringhe" ho costruito simil() da zero :-( --Alex brollo (disc.) 16:28, 19 feb 2015 (CET)

Vero, gli errori di ocr potrebbero essere molto "vicini" tra loro e quindi la LCS potrebbe non matchare bene. Quello che ci vorrebbe sarebbe una "longest almost common subsequence" (me la sono appena inventata). Potrebbe funzionare come LCS, con la differenza che invece di confrontare le stringhe per uguaglianza, dovrebbe calcolare l'edit distance tra le stringhe e dividere quel numero per la lunghezza della stringa A, ottenendo un "coefficiente di somiglianza" (es. le differenze sono 3, la lunghezza della stringa è 30, il coefficiente è 0.1). Quando il coefficiente è sotto una certa soglia (che so, ad esempio 0.2 cioè 1 differenza ogni 5 caratteri), si considerano le due stringhe come "quasi uguali". Il resto dell'algoritmo di LCS potrebbe restare invariato. Non ho calcolato la complessità computazionale di tutto questo, potrebbe essere spaventosa :D Poi magari non serve trovare proprio la LACS più lunga, anche perché è probabile che le differenze siano piuttosto ben distribuite nel testo; magari basta dividere il testo A in frammenti abbastanza lunghi da essere "unici" e poi cercare l'allineamento migliore. Si potrebbe tentare così:

  • spezzi a metà il testo A
  • ipotizzando di spezzare esattamente a metà il testo B, calcoli le distanze tra A1 e B1 e tra A2 e B2
  • poi provi a spostare il punto di "smezzamento" in entrambe le direzioni fino ad una certa distanza, calcolando ogni volta le distanze tra le coppie di frammenti fino a trovare la migliore combinazione
  • quando l'hai trovata ripeti lo smezzamento sui frammenti così ottenuti

Delirio di un povero informatico esaurito? :D Can da Lua (disc.) 17:27, 19 feb 2015 (CET)

Anni fa avevo inventato una strana cosa capace di trovare un paragrafo A in un testo B (B grandino: usavo l'intero dump di wikisource...) basandosi sulla pura somiglianza ed era spaventosamente veloce.... misurava la densità di match di piccole sottostringhe casuali di A nel testo B, interrompendosi subito quando emergeva un pattern significativo. Ma qui la cosa è del tutto diversa: io procederò con la "melodia delle lunghezze", vediamo dove l'idea mi porta. --Alex brollo (disc.) 00:54, 20 feb 2015 (CET)
Per chi volesse provarci, ecco le due "trasformate" che proverò a usare come caso test :-) :
2,6,3,6,5,2,9,7,2,3,4,2,3,5,2,3,7,2,8,7,8,1,4,9,4,3,2,5,2,5,2,3,4,6,3,5,1,2,6,3,2,9,4,5,1,4,3,3,5,5,5,5,6,3,2,6,6,2,3,7,6,3,2,3,2,6,3,2,4,7,2,6,5,10,2,4,7,8,3,5,6,5,2,3,6,9,7,1,7,3,4,8,6,3,5,2,2,6,3,8,2,6,1,3,2,7,11,1,3,2,5,2,6,5,4,6,3,1,4,4,6,2,2,2,3,5,8,1,9,6,2,5,2,8,8,2,2,7,6,4,6,3,5,5,9,2,5,2,2,2,4,2,5,2,2,10,3,5,8,6,1,2,7,2,6,7,4
6,3,6,5,1,1,2,9,7,2,3,3,1,2,3,4,1,2,3,7,2,8,7,8,1,4,8,1,7,2,5,2,5,2,3,4,6,3,5,1,2,6,3,2,8,1,1,1,2,5,5,3,3,5,5,5,5,6,3,2,6,6,2,3,7,6,5,3,2,6,3,2,4,7,1,2,6,5,10,2,4,1,6,8,3,5,6,5,2,3,6,9,6,1,1,7,3,4,8,6,3,5,2,7,1,3,8,2,6,1,3,2,7,12,3,2,5,2,6,5,1,1,2,6,3,1,4,4,6,2,2,2,3,5,9,9,6,2,5,2,8,7,1,2,2,7,6,4,6,3,5,4,1,9,2,4,1,2,2,2,4,2,4,1,2,2,10,3,5,8,7,2,7,2,6,6,1,1,1,4
--Alex brollo (disc.) 08:13, 20 feb 2015 (CET)
Trasformando le due liste in due testi, con ciascun numero su una linea, e facendo una banale diff (ho buttato dentro http://www.quickdiff.com/) il risultato è sorprendente e promettente. Alex brollo (disc.) 09:10, 20 feb 2015 (CET)
Il diff sulle trasformate già nel primo passaggio evidenzia un largo numero di corrispondenze nella pagina test (a occhio: oltre il 75%) e identifica, di conseguenza, tutti i segmenti disallineati. Un gran numero dei disallineamenti è di semplice risoluzione (differenze nella sequenza spazio-punteggiatura). Restano isolate sequenze difficili; solo a questo punto diventa necessario l'analisi dei caratteri, ma il più sembra fatto. --Alex brollo (disc.) 10:24, 20 feb 2015 (CET)
Sto spezzettando il problema, lavoro in puthon su una cartella dropbox, a cui dò volentieri accesso a eventuali interessati. Bisogna che siano installati, oltre a Python, pywikibot, pyquery, e DjvuLibre. L'estrazione dei dati dal djvu è pagina per pagina, come file dsed. I djvu devono avere uno strato testo con dettaglio word (quelli da IA vanno benissimo).--Alex brollo (disc.) 00:14, 24 feb 2015 (CET)

Ecco le prime righe degli appaiamenti sulla pagina test:

Poiché pur veggio tormi
Poiche pur veggio tormi

Da vn'acerba partita Il mio
Da un’acerba partita Il mio

la mia
la mia

Ma che parl'io di ricrouar accenti Conformi a miei
Ma che parl’io di ritrovar accenti Conformi à miei

sì graue io lento il mio duol farti, Che tempo è di morir, non di
sì grave io sento il mio duol farsi, Che tempo è di morir, non di

In questa pagina (nonostante sia seicentesca) l'algoritmo appaia 161 su 180 parole presenti nello strato OCR del file djvu. Tutto avviene solo basandosi sulle "trasformate" ossia sulla sequenza delle lunghezze delle singole parole, in totale automatismo (lo script riceve solo il nome del file djvu e il numero di pagina). Provo a stressarlo un po', con altre pagine da altri djvu, prima di entusiasmarmi troppo :-) --Alex brollo (disc.) 23:18, 24 feb 2015 (CET)

memoRegex[modifica]

Sono estremamente soddisfatto del sistema chiamato memoRegex, che consente di memorizzare (attraverso Trova & sostituisci) serie di sostituzioni regex opera-specifiche e di memorizzarle stabilmente. Tuttavia serve un sistema per automatizzare il salvataggio/il ricaricamento, al momento manuale; prima di imbarcarmi nell'ideazione di qualche accrocchio informe, c'è qualcuno che ha una buona idea? --Alex brollo (disc.) 16:06, 2 mar 2015 (CET)

Progetto Splitter[modifica]

In Indice:Cenere.djvu (pag. 9-15) i primi vagiti di un "caricatore OCR" python. L'attuale logica:

  • scaricare il file djvu
  • lanciare caricaDjvu([nome djvu],[pagina iniziale],[pagina finale])
    • estrazione dell'OCR della pagina con djvutxt.exe
    • mise en page python
    • caricamento in nsPagina
svantaggi per l'utente comune
  1. occorre python
  2. occorre djvuLibre
  3. occorre scaricare il file djvu in locale
  4. occorre un bot
  5. tutti gli script tipo postOCR ecc. vanno tradotti da javascript in python

Prossima strategia:

  1. in python estrarre il testo OCR di tutte le pagine, marcandole con delimitatori (per ora, in locale; poi, magari, da Tool labs)
  2. eventuale pre-elaborazione (minima, con conservazione dei fine riga)
  3. caricamento su una pagina ns0 (da decidere in che ns e con che nome, possibilmente "automatico" ottenuto dal nome dell'Indice)
  4. scrittura di un splitter.js che legga il testo, estragga l'OCR della pagina, la carichi dopo mise en page utilizzando tutti gli script js disponibili
vantaggi
  1. una sola operazione python attivabile anche da remoto
  2. tutto il resto sarebbe fattibile da parte dell'utente comune da wikisource
  3. uso di regex/sostituzioni/automatismi identici a quelli della normale mise en page --Alex brollo (disc.)

07:24, 3 mar 2015 (CET)

Primi test e problemi emergenti[modifica]

Lo "stressaggio" della routine su alcune pagine Indice di Deledda (Indice:Cenere.djvu; Indice:Il Dio dei viventi.djvu; Indice:Colombi e sparvieri.djvu) ha dato risultati interessanti.

  • la correzione degli scannos funziona;
  • RigaIntestazione (nel caso semplice delle opere dell'editore Treves) funziona;
  • autoPt (applicazione automatica sia del Pt finale, che del Pt iniziale) funziona a singhiozzo e va rifinito: si impiglia quando nella prima riga della pagina restano frammenti di Intestazione o quando a piè di pagina compaiono note o elementi abnormi del footer)

Appena implementata la funzione che legge il memoRegex standard in Discussioni indice lo applica in Python (da verificare alcune cosette relative ai caratteri Unicode e alla diversa sintassi per i gruppi)

  • todo:
    • implementare l'automazione di memoRegex rendendo inutile il salvataggio e il caricamento manuali; l'oggetto JSON ha caratteristiche formali sufficienti per essere riconosciuto da find_stringa() nel testo della pagina.
    • rifinire le ripuliture delle righe header e footer e aggirare il problema delle note che bloccano autoPt
    • stressare il meccanismo di autoRigaIntestazione nei casi più complessi (rigaIntestazione che varia nei capitoli)

Bug acchiappato[modifica]

Entro in modifica in una pagina e premo immediatamente Ritaglio: non succede niente o_O. Faccio qualcosa, e Ritaglio parte. Meno male che c'è la console che in caso di fallimento mi segnala che c'è un elemento indefinito: mw.activeElement; ne approfitto per dire cos'è per chi non lo conosce: memorizza l'ultimo campo attivo, capace di accettare testo (tutte le caselle testo dei form, tutte le aree testo). I vari tool di edit non infilano il loro testo nel box di edit generale (come scioccamente fanno molti pulsanti del toolbox vector), ma li infila nel campo dove stava il cursore, prima di pigiare il bottone.

Ma se il focus non era mai stato portato su uno di questi campi.... mw.activeElement era indefinito e tutto si piantava. Adesso, la textarea principale di edit è il mw.activeElement di default. Un bug in meno :-) --Alex brollo (disc.) 18:42, 5 mar 2015 (CET)

Vedere l'hOCR[modifica]

Screenshot ocr view.png

Questa a destra è la visualizzazione di una piccola parte dei dati contenuti in mw.pagina.linee. Ogni elemento linea contiene in realtà parecchi altri dati, tutti ottenibili dalle coordinate delle linee e dal testo che ciascuna linea contiene. Il passo successivo è di passare dai dati al loro significato. Esempio: il rapporto fra lunghezza della linea e il numero di caratteri, tenuto conto anche della sua altezza, è indicativa delle dimensioni del font. Una anomalia nella terna dei dati (pochi caratteri in una linea lunga e bassa) è indicativa di linea speciale con spazi vuoti all'interno. Sequenze di linee allineate sia a destra che a sinistra, ad eccezione della prima (indentata) e dell'ultima (di lunghezza casuale) costituiscono un paragrafo in prosa. Linee centrate in una sequenza di paragrafi sono quasi certamente titoli di sezioni/capitoli. Sequenze di linee a fine pagina con font più piccolo sono quasi certamente note.... --Alex brollo (disc.) 20:41, 10 mar 2015 (CET)

Il progetto: "cambiare colore" alle righe dei vari tipi rappresentate a dx in modo da poter visualizzare l'effetto degli algoritmi di classificazione automatica e conseguente aggiunta dell'appropriata formattazione. --Alex brollo (disc.) 10:54, 13 mar 2015 (CET)

raggruppa2()[modifica]

Finalmente ho l'algoritmo raggruppatore che cercavo da tempo. Adesso dovrei riuscire a fare qualche passo in avanti nell'interpretazione della formattazione dall'hOCR; l'opera test sarà Indice:L'edera (dramma).djvu. Le cose si sviluppano in Utente:Alex brollo/hOCRlab.js e Utente:Alex brollo/hOCRview.js. @Ricordisamoa:: ho montato il plugin JSLint su notepad++, e lo sto usando, e non sono in pace finchè tace :-) --Alex brollo (disc.) 19:56, 17 mar 2015 (CET)

Problema per i geek maggiori[modifica]

"If you are repeating yourself, you are going wrong". Sono imbarazzato dalla confusione che faccio mentre tento di programmare, ma anche i "big" qualche cattivo esempio me lo danno. Uno, fastidiosissimo, è la duplicazione dell'algoritmo per l'incapsulamento, usatissimo da noi, e presente in due diverse versioni che si comportano in maniera diversa - e la più recente è, inesplicabilmente, quella più sbagliata.

Come sapete, se provate a "incapsulare" il testo selezionato, ad esempio, nel markup il tag sup, potete farlo sia con il bottone A del toolbox Vector, che con il link in editTools. La differenza notevole è che il primo agisce - scioccamente - solo nella textarea principale; il secondo agisce - correttamente - in qualsiasi textarea o input area dove stia il cursore/la selezione. Qualsiasi bottone aggiuntivo in toolbox, scritto con la sintassi consigliata, ossia con il metodo encapsulate, si comporta nel modo sbagliato. Questo perchè ci sono due funzioni totalmente diverse per l'azione encapsulate - è mai possibile???

Come rimediare? Nei miei tool ho, con una certa fatica, emulato edittools; ma è ovvio che la soluzione sarebbe modificare il metodo encapsulate di Vector. --Alex brollo (disc.) 11:46, 18 mar 2015 (CET)

Vedo che la "mia" funzione incapsula è simile a mw.toobar.insertTag(), che è quella che viene lanciata negli edittools. Sostituirò quindi incapsula() con la funzione già presente anzi: incapsula() chiamerà semplicemente mw.toobar.insertTag, per ora, così non devo impazzire a modificare codice qua e là. Vediamo.... --Alex brollo (disc.) 09:22, 26 mar 2015 (CET)
Disgraziatamente (ma era logico) mw.toobar.insertTag esiste solo in edit. Chi poteva pensare che un matto usasse funzioni di edit in modalità view? Quindi, mi tocca rinunciare alla funzione in newThumbs, in cui si edita in modalità view... --Alex brollo (disc.) 17:22, 30 mar 2015 (CEST)

Il bottone Sc[modifica]

Ho appena modificato [582] il codice di MediaWiki:Gadget-pulsanti-Sc.js, sostituendo l'originario encapsulate con una chiamata callback a incapsula(). Risultato: adesso il bottone agisce anche sull'header (e questo mi salva le coronarie, perchè millanta volte ho cercato di inserire in RigaIntestazione un Sc ottenendo quello che sapete...).

Proporrei di convertire alla nuova sintassi i bottoni aggiuntivi che "incapsulano". --Alex brollo (disc.) 08:33, 25 mar 2015 (CET)

Template Ec con all'interno altri template[modifica]

Nella pagina Pagina:Storia delle arti del disegno.djvu/285 ho applicato un errata corrige originale che contiene un autore citato, ma come potete vedere la cosa non è compatibile. Togliendo "Autore citato" va tutto a posto, quindi utilizzando due template Ec dovrei risolvere la cosa, ma prima di procedere volevo sapere se esiste una alternativa. --Luigi62 (disc.) 22:00, 25 mar 2015 (CET)

@Luigi62:Purtroppo, per come è costruito il template, niente da fare. Il testo che viene passato come parametro 2 (testo corretto) è incorporato in un parametro html title, per essere visualizzato al passaggio del mouse; e deve essere "testo semplice", con parecchie limitazioni formali. Volendo usare Ec, la tua soluzione è la migliore "pezza" che si possa mettere in questo caso. --Alex brollo (disc.) 15:15, 14 apr 2015 (CEST)

problemino ePub[modifica]

Il testo L'edera (dramma) stressa molto il codice di Blocco a destra ecc. Mi sono accorto che ci sono problemi con il template Blocco a destra (che crea una tabella float:right e chiude con br clear="all"); il br clear=all non ha l'effetto voluto e in L'edera (dramma)/Atto I/Scena I veniva fuori un pasticcio. Bisognerebbe usare questo testo molto complesso per verificare i problemi di conversione ePub e aggiustare, eventualmente, i template critici con template non problematici. --Alex brollo (disc.) 14:19, 27 mar 2015 (CET)

Monitorare il buon proponimento[modifica]

Mi sono promesso di dominare il mio istinto alla divagazione e di lavorare in nsPagina per almeno i 4/5 dei miei edit. Ma come misurare comodamente la cosa? Chiedo l'elenco dei miei contributi (gli ultimi 500) e poi lancio:

n=0;
nt=0;
$(".mw-contributions-list li").each(function() {
   titolo=$("a",this).eq(1).attr("title"); 
   if (titolo.indexOf("Pagina:")===0) n+=1; nt+=1;
   })
   alert("nsPagina: "+n+"\nTotale: "+nt+"\nPercentuale in nsPagina :"+Math.round(n/nt*10000)/100)

Al momento non ci siamo: 72%. Deve arrivare a 80% :-( --Alex brollo (disc.) 06:45, 3 apr 2015 (CEST)

Curiosità: gli ultimi 500 edit complessivi di tutti gli utenti cadono in nsPagina per il 71%. Gli ultimi 500 contributi miei cadono in nsPagina per il 71.2%. Sono l'utente medio :-). --Alex brollo (disc.) 23:54, 3 apr 2015 (CEST)
Essendo una mission impossible mi sono ridimensionato a puntare all'80% di edit nsPagina + ns0, conteggiando separatamente i due tipi di edit e poi sommandoli per ottenere la percentuale globale. Adesso ci siamo :-) . --Alex brollo (disc.) 16:36, 13 apr 2015 (CEST)

Modifica MediaWiki:Epub.css[modifica]

Ho modificato .indent p in MediaWiki:Epub.css ma non riesco a far importare il file modificato. Che fo? --Alex brollo (disc.) 07:13, 3 apr 2015 (CEST)

A posto, dopo una snervante attesa adesso il generatore di ePub si è convinto a leggere il nuovo file Epub.css, l'ePub di Odio vince ha la formattazione desiderata. Se questo dipende dall'intervento di qualcuno... grazie. --Alex brollo (disc.) 09:46, 8 apr 2015 (CEST)

Progetto currentIndex[modifica]

A seguito di esperimenti, effettuati su fr.source, ho abbozzato, mesi fa, il progetto currentIndex.

L'idea è semplice: non appena si entra in una pagina (nsPagina, ns0, nsIndice) verificare a che pagina Indice quella pagina è collegata; verificare se è la stessa già caricata (come avviene passando da una pagina a una pagina dello stesso Indice o spostandosi da nsPagina a una pagina transclusa in ns0); se la pagina Indice è diversa, allora leggerne l'html ed estrarne tutti i dati disponibili, caricandoli in localStorage.

In qualsiasi momento, quindi, sia in nsPagina, che in ns0 (proofread), sono sempre disponibili tutti i dati presenti nella pagina Indice: sia quelli generati dal template principale, che quelli generati da pagelist e da ciò che è contenuto nel campo Sommario.

Questa parte del programma dovrebbe essere particolarmente robusta ed efficente, e dovrebbe girare in sottofondo di default, integrata in MediaWiki:Gadget-common.js.

Da qui in poi, su questa base, ci si può sbizzarrire nell'uso dei dati con i gadget opzionali più diversi; ma questa è sarà una fase successiva. --Alex brollo (disc.) 20:04, 5 apr 2015 (CEST)

Le cose sembra vadano bene. Corre sperimentalmente uno script autoNs0_test() (per ora come "giocattolo" lanciato da un bottone) che ha una struttura assai simile a ns0Auto ma che usa dati già disponibili in localStorage eche quindi non necessita di ulteriori letture. La logica è quindi molto più chiara, non richiamando script esterni, e la velocità molto superiore. Test in corso su Le piacevoli notti. Obiettivo di miglioramento: automatizzare anche la gestione di fromsection e di tosection. --Alex brollo (disc.) 06:44, 7 apr 2015 (CEST)

currentIndex(): update[modifica]

Sto rivedendo profondamente newThumbs, e ho sentito l'esigenza di "tirare su" altri dati dentro la famiglia di variabili mw.currentIndex. A questo punto sarà bene trasformarle in un unico oggetto; ma per non impelagarmi in troppe modifiche al momento ho continuato a creare oggetti indipendenti. Ciascuna variabile è accoppiata a un dato localStorage, quando si tratta di oggetti in formato JSON.

Ad oggi le variabili disponibili (estratti sia dall'html, che dal wikicode della pagina Indice) sono:

  • mw.currentIndex: il nome della pagina Indice
  • mw.currentIndexData: il dizionario pagina cartacea-pagina djvu
  • mw.currentIndexPagelist: la lista delle pagine (indice=pagina djvu; valore=pagina cartacea o ciò che appare da pagelist)
  • mw.currentIndexSummaryData: tutti i dati del campo Sommario
  • mw.currentIndexSource: il contenuto del campo fonte (utile se identificatore di IA)
  • mw.currentIndexPageSal: lista identica a mw.currentIndexPagelist come indice, il valore è il SAL della pagina
  • mw.currentiIndexBaseImg: l'URL base dei file immagine
  • mw.currentIndexMetadata: il valore dei vari campi del form base (titolo, autore...)

Questi dati sono, come già riportato, disponibili dopo l'accesso a qualsiasi pagina, anche in fase di creazione, collegata alla pagina Indice (nsIndice, nsPagina,ns0) e non vengono riletti finchè si nagiga in pagine collegate alla stessa pagina Indice. --Alex brollo (disc.) 14:28, 21 apr 2015 (CEST)

Disattivato negli script generali di default perchè di una certa "pesantezza"; lo conservo nel mio account come script personale. --Alex brollo (disc.) 15:46, 30 apr 2015 (CEST)

strumento "trova" in google[modifica]

In rilettura testi mi sarebbe molto utile lo strumento "trova", ma tale strumento, in google, non distingue alcuni caratteri. Ad esempio se cerco le ì (accentate) mi segnala anche quelle non accentate. C'è qualcuno che sa dirmi se esiste un modo per risolvere il problema? Grazie e cordiali saluti a tutti --Utoutouto (disc.) 12:19, 25 apr 2015 (CEST)

Raccomandazione[modifica]

Vedo di nuovo la console ingombra di messaggi di deprecazione causati dall'uso di importScript, che va sostituito con l'odioso mw.loader.load(). Io sto eliminando quelli nei miei script personali, preferirei che di quelli in nsMediaWiki si occupasse qualcun'altro, per quanto possibile ne starò lontano. --Alex brollo (disc.) 00:42, 3 mag 2015 (CEST)

@Alex brollo: La deprecazione si riferisce in realtà solo a importScriptURI e importStylesheetURI; importScript e importStylesheet non sono ancora rimpiazzabili (gerrit:206078). I messaggi spariranno dalla console non appena MediaWiki verrà aggiornato anche qui. --Ricordisamoa 05:55, 3 mag 2015 (CEST)
@Ricordisamoa: Non cambia, un po' di approfondimento mi ha orrificato, nei miei script sono miriadi le mute deprecazioni potenziali. Fra gli script borderline, non terminati, vorrei incoraggiare qualcuno che maneggia come si deve javascript a completare memoRegex, nella fase di memorizzazione/caricamento automatico (per ora, manuale e critico) passando da Indice a Indice. --Alex brollo (disc.) 08:28, 3 mag 2015 (CEST)
importScriptUri dovrebbe essere contenuto solo in MediaWiki:Common.js, e in un bel po' di pagine in nsUtente di utenti foresti. La deprecazione di importScript è forse un errore/una iniziativa intempestiva? In sè, importScript è una richiesta sincrona o asincrona? --Alex brollo (disc.) 08:33, 3 mag 2015 (CEST)

Stranezza per gli utenti sloggati[modifica]

Sono alex sloggato, sto facendo un giro esplorativo per vedere cosa trovano gli utenti non registrati e in quante "deprecazioni" incorrono (c'è un mucchio di deprecazioni per l'uso di skin, ma non ho capito da che script originano). Segnalo però un problema notevole: non vedo i radiobutton del SAL in edit di nsPagina. E' un problema noto? (alex brollo sloggato) --193.43.176.15 08:48, 6 mag 2015 (CEST)

Alex, te lo sei dimenticato? Dato che la rilettura va fatta da un utente diverso da chi ha trascritto, se sei sloggato non puoi impostare il sal. Non può essere altrimenti che così. Ci dovrebbe essere anche un avviso in alto. Can da Lua (disc.) 09:22, 6 mag 2015 (CEST)

Però al massimo non dovresti vedere il 100%, gli altri in teoria sì, almeno credo. --Cruccone (disc.) 21:31, 6 mag 2015 (CEST)

Fastidio!!![modifica]

Nella mia "configurazione di preferenze" avviene che la linguella Cronologia si visualizza dopo un paio di secondi, e sposta la linguella Modifica verso sinistra. Conseguenza: se clicco Modifica spesso il click viene raccolto da Cronologia, perchè Modifica mi è scappato via sotto il mouse... che grandissimo fastidio! Consigli? --Alex brollo (disc.) 14:06, 12 mag 2015 (CEST)

Visualizzazione affiancata di versioni[modifica]

@OrbiliusMagister, Candalua: Se andate in Dieci lettere di Publio Virgilio Marone/Dieci lettere/Lettera prima vedrete che è cpllegata mediante AltraVersione con l'edizione 1800.

Le due edizioni hanno la parte finale molto diversa, e si tratta di una scelta dell'autore; immagino che nel frattempo sia successo il pandemonio, e in qualche modo la differenza è giustificata da quello.

Due "sogni tecnici", uno piccolo, uno più impegnativo.

  1. Innanzitutto i link alla pagina disturbano; dovrebbero almeno essere convertiti in link interni al testo.
  2. In secondo luogo, sarebbe magnifico se fossero evidenziate le maggiori differenze nei due testi (una specie di diff con testo non corrispondente evidenziato da uno sfondo colorato, per esempio).

Poichè "sono in pausa" con javascript, non ci provo nemmeno, ma volevo condividere l'idea. --Alex brollo (disc.) 08:33, 28 mag 2015 (CEST)

Self M&S[modifica]

@Aubrey, Candalua: Migrato senza troppi traumi in core da compat, sto seguendo una idea bizzarra:il "self M&S". L'idea è la seguente: estrarre via bot un blocco di pagine dal file djvu e prepararci una pagina unica, con il testo di tutte le pagine a cui è stato aggiunto il codice magico split. Vedete il primissimo esperimento in Utente:Alex brollo/testo, nella cronologia vedete il primo caricamento da Alebot, poi l'intervento (andato a buon fine) di Phe-bot che adesso rollbackerò per procedere con la fase successiva: l'edit manuale prima dello splittaggio. Notate che l'OCR è stato pre-elaborato analogamente a quanto fanno postOCR, aggiustaParagrafi e unisciLinee, compresa l'aggiunta di RigaIntestazione non più dipendente da RigaIntestazione scritto sulle pagine precedenti.

L'idea potrebbe avere due vantaggi:

  1. il rigaIntestazione automatico senza creazione sequenziale delle pagine;
  2. la possibilità di editare pagine multiple (es. con trova & sostituisci) in un colpo solo.

In questa versione test, ho usato una pagina-sandbox, ma nulla impedisce che il bot scriva il testo estratto dentro una pagina ns0 definitiva realizzando quindi il "self M&S" completo: si editerebbe rapidamente il testo di un intero capitolo in ns0, portandolo a un "quasi SAL 75%", poi si lancerebbe lo split e su ns0 praticamente non si ritornerebbe più.

Che ne dite? E' completamente inutile/folle? :-) --Alex brollo (disc.) 19:32, 4 giu 2015 (CEST)

L'idea è interessante, SE riesci a convincere i due-tre utenti che potrebbero usarla ad usarla (Marco Lino, Xavier, forse Accurimbono). Cioè, mi pare davvero interessante, soprattutto il discorso di RigaIntestazione, che però potresti risolvere a priori e in maniera indipendente al "self M&S".
Ovviamente, il discorso di cercare/sostituire su tutto il testo è molto interessante anche lui.
Tutto ciò che risparmia tempo all'utente e automatizza lavori "stupidi" è cosa buona e giusta, ricordati però che l'usabilità è regina, e se la procedura è difficile o di difficile comprensione, nessuno l'userà. --Aubrey (disc.) 23:38, 4 giu 2015 (CEST)
@Aubrey: Sono andato un po' avanti, ho già sistemato le cose in modo da caricare il testo "self M&S" direttamente sulla pagina ns0 finale (prodotta da autoNs0). Lì il testo complessivo può essere corretto (aggiunta ref, sistemazione delle frattaglie in testa e in coda alle pagine, postOCr...) e una volta soddisfatti si lancia il M&S e la pagina diventa automaticamente "transclusa". Vedi la cronologia di Il risorgimento d'Italia/Parte I/Introduzione ‎ e di Il risorgimento d'Italia/Parte I/Prospetto generale d'Italia. In qualche modo, l'idea è anche correlata alla tua, di disporre subito del testo in ns0, fin dall'inizio dei lavori. Continuo gli esperimenti con un po' di try and learn, ovviamente "in corsa" emergono dei piccoli problemi difficilmente prevedibili. Hai ragione: esportando in javascript gli stessi script che consentono di ottenere RigaIntestazione in qualsiasi pagina, a prescindere dalla lettura delle pagine precedenti, è possibile ottenere la stessa cosa lavorando direttamente su wikisource; basta che esista una tabella che contenga i dati "da pagina a pagina lo schema rigaintestazione è questo; da pagina a pagina.... " ecc. Per fortuna, le differenze fra le regex python e quelle javascript è risultata minima :-) --Alex brollo (disc.) 08:06, 5 giu 2015 (CEST)
Come cavia sono sempre a disposizione, fatemi un fischio che inizio a provare. I testi su cui intendo lavorare sono questi: Aminta e Comedìa: OCR tosto ma a me servono tutti gli altri automatismi, es. immediata sostituzione s-ſ, poem automatico, numerazioni verso ogni 5 su tutto il testo in un solo click o rigaintestazione ecc. ecc.)@Alex brollo: su questi testi vale sempre quel discorso diplomatico/interpretativo che abbiamo inziato qualche tempo fa, quindi per ogni singola pagina farò sempre doppio lavoro: se esistesse un modo per velocizzare anche questa pratica, tipo un duplica nella riga sottostante il testo fra i tag poem con inserite già le section ecc., gradirei moltissimo :) --Xavier121 11:35, 5 giu 2015 (CEST)
Caro Xavier, non sarebbe molto più interessante e soddisfacente lavorare, che so, su bei romanzi di fine ottocento, dove la formattazione più complessa è un occasionale corsivo? :-P
Prima di affrontare quei testi là.... abbi pazienza.... nel frattempo dà una prima occhiata a come vengono le pagine dagli "esperimenti" in corso. Alex brollo (disc.) 12:10, 5 giu 2015 (CEST)
può andare questo? --Xavier121 16:28, 5 giu 2015 (CEST)
Questo è carino; offre il problema dei capitoli cortissimi e "sezionati". Ok, mi prenoto per qualche test sulla parte ancora non creata: primo passo, la creazione di una bella serie di pagine-capitolo in ns0 prima di creare le corrispondenti pagine Pagina; da quel punto, verifica della massima automazione possibile. Inserirò i dati sui "modelli di rigaIntestazione" in pagina Discussioni indice (in questo caso, semplicissimi: sono di un tipo solo....)--Alex brollo (disc.) 16:50, 5 giu 2015 (CEST)
@Aubrey: Immaginiamo che, fatta una pagina Indice (con un buon pagelist e un buon Sommario con i suoi Indice sommario) la pagina base di ns0 (quella con Intestazione), definiti gli schemi per rigaIntestazione e salvato l'eventuale memoRegex (vedi in Discussioni indice:Bettinelli - Opere edite e inedite, Tomo 7, 1799.djvu tutto il resto (creazione sottopagine e aggiunta in ciascuna sottopagina del testo con il codice SPLIT) sia totalmente automatizzato ossia: sia questione di n. 1 click: ti basterebbe come semplificazione? Gli "attrezzi" dovrei averceli ormai tutti.... mi manca un passo critico, portare la cosa su Labs, ma se il tutto funzia chiederò aiuto. --Alex brollo (disc.) 14:53, 6 giu 2015 (CEST)

test self M&S[modifica]

@Aubrey, Xavier121: Guardate la pagina-test Occhi e nasi/Le persone prudenti: è stata "creata dal nulla" da Alebot, con il comando:

  • carica("Occhi_e_nasi.djvu","Occhi e nasi/Le persone prudenti",True,True)

e null'altro. Com'è stata creata quella, potrebbero essere create tutte quelle che mancano. Direi che ci siamo quasi :-) (i due True finali sono provvisori, significano rispettivamente "aggiusta i paragrafi" e "sovrascrivi") Alex brollo (disc.) 16:49, 6 giu 2015 (CEST)

Ottimo, ma lo split? --Xavier121 19:07, 6 giu 2015 (CEST)
@Xavier121: Mi son perso la domanda.... è ancora valida? --Alex brollo (disc.) 00:39, 7 giu 2015 (CEST)
Update, sempre su Occhi e nasi. Adesso ha corso il comando:
  • carica("Occhi_e_nasi.djvu")
Lo script si è arrangiato a rovistare nel codice wikisource, identificando tutte le sottopagine ns0 ancora rosse, creandole e aggiungendo a ciascuna il "testo SPLIT". Manca la creazione automatica della pagina ns0 principale (quella che contiene Intestazione) ma lo script dispone già di tutti i dati necessari, è questione di poco. --Alex brollo (disc.) 08:25, 12 giu 2015 (CEST)
Lo script ha lavorato anche su altre opere, in corso i lavori su Arcadia (Sannazaro). Per due capitoli minori lo script ha lavorato da Tool Labs, ma in interattivo da console; per poterlo attivare da remoto, via URL, ce ne vuole.... --Alex brollo (disc.) 10:17, 22 giu 2015 (CEST)

Procedure Wikisource[modifica]

Proseguo qui giusto la discussione iniziata qui sopra per riflettere a voce alta e condividere con voi alcuni pensieri.
Il punto, credo, sia quello di raggiungere, il più possibile, una serie di procedure semplici, che semplifichino la vita dell'utente. Però dovremmo essere razionali e avere chiara in testa una panoramica delle azioni.

Abbiamo già un'azione molto semplice, accessibile a tutti, ed è il passaggio da 75% a 100%, la cosiddetta "rilettura". Secondo me è stato un traguardo importante e infatti i numeri lo dimostrano (soprattutto quelli dei concorsi di rilettura).

Siamo a buon punto (ma certo è da migliorare) per il caricamento di un libro su Wikisource: con i tool di Tpt, il passaggio da Commons, mettere un libro su Source è cosa accessibile. CONTINUA (Aubrey)

Attenzione: siamo in piena "rivoluzione wikidata", molte cose potrebbero cambiare. Pensiamoci, ma non nei dettagli.... --Alex brollo (disc.) 13:39, 5 giu 2015 (CEST)--Alex brollo (disc.) 13:39, 5 giu 2015 (CEST)

Estendere Trova & sostituisci[modifica]

@Candalua: Penso sia ora di mettere mano a Trova & sostituisci, sento la crescente necessità che possa agire, oltre che sul testo dell'intera pagina, sul solo testo selezionato. Non dovrebbe essere difficilissimo, appoggiandosi su mw.activeElement e la correlata sel(), che lo usa, ma la cosa è comunque un po' delicata. Ci sono due possibilità: o si aggiunge un flag al box, oppure si prevedono due comportamenti diversi del tool a seconda che, in ingresso, vi sia o non vi sia una selezione sull'elemento puntato da mw.activeElement. Please feedback! --Alex brollo (disc.) 08:13, 12 giu 2015 (CEST)

Sections[modifica]

@Candalua: Ultimo passo dell'automazione per la resa delle sottopagine ns0: riempire automaticamente fromsection= e tosection=.

Si può fare, leggendo al volo il codice della prima e dell'ultima pagina (nella mia versione personale di autoNs0, il to= punta alla prima pagina del capitolo successivo, ad abuntantiam, e non alla pagina precedente). Ci sono alcuni casi tipici e alcuni casi più rari; l'automazione è abbastanza semplice nei casi tipici.

  1. caso 1: in nessuna delle due pagine ci sono section: fromsection= e tosection= vuoti, to= punta alla pagina precedente quella del capitolo successivo (diminuire di 1 il valore di default).
  2. caso 2: nella prima pagina ci sono due section. Impostare fromsection sulla seconda.
  3. caso 3: nell'ultima pagina ci sono due section. Impostare tosection= sulla prima.
  4. caso anomalo: in qualsiasi pagina ci sono più di due section. verificare e compilare a mano.

Io proverò a implementare nel mio autons0 personale, poi ce la fai, Candalua, a esportare in quello per tutti? --Alex brollo (disc.) 17:19, 15 giu 2015 (CEST)

PS: proverò a fare violenza alla mia logica e a prevedere due letture asincrone con quello che ne consegue; ma so già che sarà dura. :-( --Alex brollo (disc.) 13:29, 19 giu 2015 (CEST)

Un nostro split (magari due)[modifica]

Il tool M&S è fantastico ma.... non sarebbe male avere una nostra, autonoma aplicazione che faccia lo split (anche perchè oggi, per esempio, tutto Tool labs è fermo!).

Ci sono sue strade per farci uno split:

  1. python (ci proverò stasera)
  2. js (sarebbe fattibile, velocissimo, eccellente ma non mi ci metto).

Lo split in python sarà leggermente più potente dello split di M&S perchè gestirà anche header e footer (quindi, metterà RigaIntestazione là dove deve stare). Tenete i diti incrociati... speriamo che tutto vada bene. --Alex brollo (disc.) 08:31, 19 giu 2015 (CEST)

@Xavier121: Grazie Xavier, ho stressato il nuovo aggeggio, adesso però sono in pausa meditativa... tutto funziona, ma editare un grosso blocco di pagine ha degli inconvenienti personali: la noia. Editare una pagina alla volta ha un effetto psicologico particolare: tutte le volte che una pagina "riesce bene", si riceve una piccolissima ricompensa.... forse l'utente preferirebbe ribaltare tutto: precaricare le pagine (con tutti i possibili automatismi) e ritrovarsi, fin dall'inizio, ns0 transcluso, per poter verificare la transclusione. Con i nuovi aggeggi non serve più procedere per pagine consecutive, per ricavare RigaIntestazione, nè occorre "seminare" manualmente un paio di pagine quando RigaIntestazione cambia; il che risolve il peggiore intoppo del vecchio Precarica, che tante soddisfazioni ha dato con Deledda. Ci rifletterò, probabilmente chiederò aiuto a Santa Caterina :-). Come va Bandello?
@Candalua: uploader6.py ha emesso un vagito da Tool Labs, adesso che Tool Labs si è riavviato. Deve mangiarne di polenta prima di essere un tool come si deve, ma finchè non emette il primo vagito....--Alex brollo (disc.) 18:48, 21 giu 2015 (CEST)

@Alex brollo:In che senso? Scusami, avevo lasciato indietro il lavoro (precedenza alle aldine per il progetto Wikimanuzio). Domani in serata carico gli indici separati dei 4 volumi. :P --Xavier121 22:59, 21 giu 2015 (CEST)

Incursione in javascript[modifica]

Ho fatto due cosette:

  • ho spostato Utente:Alex brollo/ParseIndice.js in MediaWiki:ParseIndice.js (lo script è quello che viene chiamato da importa dati e che crea il Modulo:Dati/....);
  • ho aggiunto in coda a Modulo:Dati/.... un oggetto JSON, dentro un commento Lua, che rappresenta il dizionario pagina djvu->pagina cartacea come primo passo per costruire automaticamente RigaIntestazione in modo "assoluto" superando il sistema, furbo ma non intelligente, di curiosare il RigaIntestazione di due pagine prima. Leggendo anche lo "schema RigaIntestazione" in pagina Discussioni Indice, dovremmo essere a posto.
  • Esiste l'alternativa di eseguire il parsing javascript dei dati codificati Lua di Modulo:Dati/.... e forse sarebbe la soluzione più pulita, ma siccome i dati sono generati da javascript mi sembrava seccante non memorizzarli anche in formato direttamente leggibile da javascript. Se i "piani alti" hanno risolto il problema della lettura diretta in Lua di dati JSON, ditemelo! --Alex brollo (disc.) 16:24, 22 giu 2015 (CEST)

PS: vedo che è stato aggiunto a Scribunto un mw.text.jsonDecode e mw.text.jsonEncode; devo solo studiarmeli.... che pasticcio; che dite, rollbacco tutto in attesa di scovare una buona struttura dati leggibile sia da Javascript che da Lua? --Alex brollo (disc.) 16:36, 22 giu 2015 (CEST)

Mi spiace di dovervi far scervellare dietro a problemi abbastanza astratti, ma ditemi cosa pensate di questa idea: registrare in Modulo:Dati gli oggetti javascript generati da parseIndice() passandoli a Lua come stringa JSON, e provare a farglieli decodificare; fare le cose in modo che javascript possa leggere l'intera pagina, scovare la stringa JSON, e decodificarla. A questo punto sia Lua che javascript leggerebbero gli stessi dati. Che ne dite? --Alex brollo (disc.) 17:22, 22 giu 2015 (CEST)

Modulo:Dati contenente dati JSON leggibili sia da Lua che da javascript[modifica]

In Modulo:Dati/Gozzi - Le fiabe. 1, 1884.djvu (che blocco per evitare accidentali riscritture) ho inserito manualmente i dati dell'oggetto d2b (dizionario numero pagina djvu -> numero pagina cartacea), codificati in JSON, nella variabile Lua d2b, con l'istruzione:

local d2b = mw.text.jsonDecode('....')

eliminando la lunga serie di istruzioni che caricava i dati uno per volta. Il modulo funziona regolarmente. Dopodichè dalla console, in edit della pagina Modulo, ho letto il codice e l'ho passato alla seguente istruzione javascript:

oggetto=JSON.parse(find_stringa(leggiBox(), "mw.text.jsonDecode('","')",0))

ricavando di nuovo il dizionario funzionante. :-)

Questo significa che si può effettivamente memorizzare rappresentazioni JSON di oggetti in una pagina scritta in LUA, in modo che l'oggetto (lo stesso oggetto!) sia accessibile sia in Lua che in javascript; il che significa che gli stessi identici dati, una volta generati, possono essere riutilizzati quante volte si vuole sia in edit che nel parsing del codice wiki (e quindi i dati compaiono regolarmente nell'html, e in tutte le loro derivazioni, come l'output dei normali template), senza ripetere la lettura, e l'analisi, di pagine diverse da quella dove i dati sono registrati. Intravedo delle grossissime semplificazioni nelle automazioni di RigaIntestazione e in autoNs0 e non solo.... :-) --Alex brollo (disc.) 19:56, 22 giu 2015 (CEST)

Uploader7.py[modifica]

@Candalua, Ricordisamoa: Ho sistemato provvisoriamente uploader7.py in Utente:Alex brollo/uploader7.py. La doc interna è estremamente incompleta, spero di poterla integrare, qualche funzione è interessante. Domanda: dov'è il posto giusto per i file python? Mica l'ho trovato.... :-( --Alex brollo (disc.) 06:50, 25 giu 2015 (CEST)

Progetto:Bot/Programmi in Python per i bot Can da Lua (disc.) 09:54, 25 giu 2015 (CEST)
@Candalua: Grazie, ✔ Fatto --Alex brollo (disc.) 10:03, 3 lug 2015 (CEST)

Note all'interno di note separate[modifica]

@Candalua: In Pagina:Caterina da Siena - Epistole, 1.djvu/39 ci sono rimandi a note separate (le prime , A, B,C contenute in Pagina:Caterina da Siena - Epistole, 1.djvu/39),risolvibili con {{Nota separata}}, ma disgraziatamente la nota C a pag 46 contiene ulteriori note, e questo Nota separata non lo regge. Non oso metterci mano.... --Alex brollo (disc.) 22:02, 1 lug 2015 (CEST)

@Candalua: Però, a pensarci, Nota separata già contiene metà del codice necessario a risolvere il problema della nota dentro una nota... forse basterebbe inserire l'altra metà. Da verificare. Da provare anche un template {{Ref}} che internamente usi la sinsassi alternativa #tag:ref. Forse semplificherebbe le cose. --Alex brollo (disc.) 08:21, 3 lug 2015 (CEST)
Vedo un tenue raggio di luce.... il caso è complesso, si tratta di una nota separata in più pagine ciascuna contenente note, ma chissà... il caso sembra comunque abbastanza raro nel testo, le lettere iniziali sono quelle più complesse, lunghe, e importanti (lettere di Caterina ai Papi); quindi non dovrebbe intralciare la trascrizione, anche se sarà necessaria una soluzione complessa ad hoc. --Alex brollo (disc.) 09:30, 3 lug 2015 (CEST)
@Candalua: ✔ Fatto. Vedi Epistole (Caterina da Siena) I/Lettera 1. Segnalo anche un nuovo template {{Ns}}, derivato da {{Nota separata}}, semplificato nei parametri (soprattutto nel caso di note che continuano su due o tre pagine; facilmente espandibile) Alex brollo (disc.) 11:24, 5 lug 2015 (CEST)

Problema astratto.... ma non del tutto[modifica]

@Candalua, Ricordisamoa: Data una textarea, in cui sia rappresentata una lista di parole separate da speciali caratteri-spazio e speciali caratteri-fine riga, ideare uno strumento che permetta di editare il testo aggiungendo o togliendo qualsiasi cosa, ma con l'assoluta impossibilità di aggiungere, o togliere, i due caratteri speciali sopra nominati.

Domanda: mi tocca lavorare sui malefici eventi di tastiera.... :-( ? --Alex brollo (disc.) 18:43, 3 lug 2015 (CEST)

Ti consiglio due alternative:
  • Crea un widget ad hoc con OOjs UI, oppure
  • Usa l'evento input e consenti all'utente di proseguire l'azione solo se il contenuto della textarea rispetta il formato richiesto, fornendo in caso contrario suggerimenti su come renderlo valido.
--Ricordisamoa 08:51, 4 lug 2015 (CEST)
@Ricordisamoa: Grazie. Al momento sembra più promettente una strada completamente diversa, quella che sto esplorando in Utente:Alex brollo/djvuEditor.js, ossia lo "spappolamento" del testo nelle singole parole, ciascuna dentro uno span che diventa un campo input cliccandoci sopra. In questo modo l'utente non può assolutamente far altro che editare le singole parole senza poterne variare nè il numero nè la posizione. Il che - per editare i file dsed e quindi lo strato OCR dei file djvu - è esattamente quello che voglio ottenere. --Alex brollo (disc.) 11:39, 5 lug 2015 (CEST)
@Ricordisamoa: Devo comunque esplorare l'evento input, in particolare quando scatta e se è possibile ricostruire la textarea com'era prima di un breaking input; altrimenti non c'è istruzione che permetta di risistemare le cose nel caso di un input distruttivo (tipo, seleziona e cancella tutto....). L'idea sarebbe di memorizzare la textarea ogni volta che l'input è stato regolare (cosa valutabile dopo la modifica), in modo da poter recuperare l'ultima versione corretta. Vediamo! --Alex brollo (disc.) 10:19, 6 lug 2015 (CEST)
@Ricordisamoa: Ok, tutto sembra funzionare, qualsiasi input nella textarea, che violi il "principio di intoccabilità dei caratteri protetti" viene bloccato, in apparenza l'input non ha effetto (in realtà non è proprio così ma gli eventi sono tanto rapidi da non essere avvertibili digitando dalla tastiera), e viene visualizzato un noioso alert. Gli script, ma già lo sai, in Utente:Alex brollo/djvuEditor2.js. Alex brollo (disc.) 21:27, 7 lug 2015 (CEST)
@Alex brollo: Ripeti 10 volte ad alta voce: "non devo modificare l'oggetto globale mediaWiki!" --Ricordisamoa 08:44, 8 lug 2015 (CEST)
@Ricordisamoa: Dammi un link dove posso capire la differenza fra mw.config.set("babbeo","Alex brollo") e mw.babbeo="Alex brollo"; e del successivo mw.config.get("babbeo") rispetto a mw.babbeo. Non ce l'ho mai fatta a capire!
Quella funzione mw. eccetera è in preparazione alla trasformazione dello script in una (function() ....)() per permettere che la funzione esista anche all'esterno dello scope e sia quindi accessibile da un bottone. Ma siamo vicini (probabilmente: oltre) il limite della mia comprensione. Alex brollo (disc.) 09:29, 8 lug 2015 (CEST)
Ho forse capito.... mw.config.set("babbeo","Alex brollo") non funziona perchè il set funziona solo se mw.babbeo esiste (eppure l'affermazione è, come dice la console, true :-) ); quindi il set funziona solo su variabili già esistenti, non le crea ma ne assegna solo un nuovo valore. Il set funziona se prima ho creato la variabile: mw.babbeo="Alex brollo"; allora funziona mw.config.set("babbeo","Alex brollo bis"), altrettanto true. Questo l'ho capito; mi resta da capire se l'oggetto globale mediawiki a cui ti riferisci è mw, oppure è window. :-( Alex brollo (disc.) 09:47, 8 lug 2015 (CEST)
Mi riferisco a "mediaWiki", abbreviato in "mw". Ma mw.config.set("babbeo","Alex brollo") e mw.config.get("babbeo") nulla c'entrano con mw.babbeo... --Ricordisamoa 10:25, 8 lug 2015 (CEST)

Riflessioni a ruota libera sull'edit[modifica]

Come effetto collaterale di test finalizzati a costruire, all'interno dell'interfaccia wikisource, un editor per strato OCR dei file djvu, mi ritrovo a disporre di due sistemi diversi di edit "alternativo" di cui vagamente sento ci potrebbero essere applicazioni e sviluppi del tutto diversi dall'obiettivo di partenza.

  1. il primo permette, dal normale html di visualizzazione, di editare istantaneamente il contenuto testuale di uno span qualsiasi.
  2. il secondo permette, all'interno di una textarea qualsiasi, di vietare la modifica di caratteri specifici; ad esempio, impedendo l'edit del carattere spazio, si può restringere l'edit ai caratteri delle singole parole; impedendo l'edit di caratteri fine linea, si può impedire di modificare la suddivisione in linee del testo; in teoria (anche se non vedo applicazioni pratiche ma chissà) impedendo l'edit di caratteri graffa, si può impedire l'aggiunta o la cancellazione di template.

Il primo caso non permette - ovviamente - la memorizzazione delle modifiche inserite; ma sono certo che se in sottofondo vi fosse il raw code della pagina, le modifiche potrebbero essere replicate nel codice, con possibilità sia di preview, che di memorizzazione. Ne verrebbe fuori (?) una specie di mini-Visual editor ultrasemplificato.

E adesso....? Adesso a chi legge scatenare la fantasia su come usare questi due nuovi attrezzi. --Alex brollo (disc.) 09:02, 8 lug 2015 (CEST)

@Alex brollo: Ti invito nuovamente a ripensare la UX. Dal punto di vista dell'utente, vedersi proibita — per di più senza alcun avviso — un'azione apparentemente innocua lascia perplessi. Io indicherei invece i problemi nell'input e inviterei l'utente stesso ad annullare le proprie modifiche, controllando che l'input sia valido prima di permetterne l'invio. --Ricordisamoa 09:42, 8 lug 2015 (CEST)
L'avviso c'è, e anche fastidioso (un alert immediato). Il problema è che l'utente potrebbe non essere più in grado di risistemare le cose (es: dopo un seleziona-cancella, un seleziona-incolla, un incolla). Devo verificare se la funzione undo del browser consente sempre di "tornare indietro": ma ottenere gli undo giusti non è una cosetta facilissima, richiede comunque delle manovre delicate dell'utente; mentre il sistema che ho implementato esegue un undo immediato e automatico. Ovvio che fare il controllo solo al momento del submit sarebbe un disastro totale e vanificherebbe anche il test di validità, per com'è costruito: lo script non troverebbe nulla di strano se si toglie un carattere critico e lo si aggiunge altrove, la "check sum" darebbe via libera nonostante gli errori. Ma come ho detto altrove, siamo ai limiti, anzi oltre, delle mie capacità. Non perderci più di tanto tempo, l'importante è la possibile idea di fondo, da sviluppare, se fosse buona, come si deve. Alex brollo (disc.) 09:58, 8 lug 2015 (CEST)
Semplificato con la previsione test di considerare semplicemente non editabili i normali spazi e caratteri acapo; ripristinato l'alert.
Da esplorare una "terza via" totalmente automatica per sistemare lo strato testo del djvu: quella di applicare semplicemente un postOCR modificato sullo strato testo (estrazione, analisi, modifica e ricaricamento); ispirandosi alle routine fr.source, una specie di "mise en page sul djvu" --Alex brollo (disc.) 08:20, 9 lug 2015 (CEST)

Ipotesi per i testi a fronte[modifica]

@Candalua: Sto macinando idee per i testi che, in ns0, è bene siano presentati a fronte, in due colonne con sezioni corrispondenti allineate. Non so se esista già una soluzione consolidata; se non c'è, sto immaginando una soluzione basata sulla creazione in ns0 di una tabella a due colonne, in ogni cella della quale siano transcluse, fianco a fianco, le sezioni da allineare. Oltre che su un'opera appena iniziata, avevo trovato recentemente l'identico problema su un testo ladino con traduzione a fronte, ma in sostanza l'avevo accantonato. E' ora di costruire (o di pubblicizzare se c'è) una soluzione "canonica".

Ci sono però due problemi css.

  1. transcludendo due testi affiancati, i link alle pagine si spataccano a sinistra e si confondono. Sarebbe bene ideare un css tale che in questo caso i link alle pagine comparissero "alla tedesca" all'interno le testo, invece di flottare in giro.
  2. la larghezza canonica della div class=testi è insufficiente per leggere decentemente una pagina con due colonne di testo a fronte; lo stesso css che modifica la posizione dei link pagina dovrebbe anche allargare sostanzialmente la class=testi.

Attendo feedback in mancanza del quale procederò con i soliti solerti pasticci. ;-) --Alex brollo (disc.) 10:07, 10 lug 2015 (CEST)

Se div.testi è troppo stretto, direi che conviene chiuderlo e "uscire" sul contenitore più esterno (magari possiamo aggiungere a {{Intestazione}} un div a tutta larghezza, con un nome "nostro"). Provando a buttar giù una bozza di soluzione:
  1. per prima cosa inserire nell'html (tramite un nuovo template) un div di chiusura, per chiudere div.testi e "uscire" sul contenitore
  2. poi aprire un div "testi-large" con larghezza passata come parametro (con un default) e margin: 0 auto.
  3. inserire n div con class=col-1, col-2 ecc. e con width: 50% o la dimensione desiderata, e poi display: inline-block; vertical-align: top. Dentro a ciascun div trascludere le parti desiderate sfruttando section
  4. chiudere il testi-large
  5. riaprire poi un altro div.testi in modo da "rimettere le cose a posto" (e rendere ripetibile la procedura)
  6. per fare questi passaggi, vediamo se conviene usare un solo template che contenga tutto o se spezzettare in tanti template per ciascuna operazione
  7. per i numeri di pagina, bisogna poi agire sulla classe numeropagina, ad esempio .col-2 .numeropagina si può farlo cadere a destra invece che a sinistra, oppure farlo proprio sparire.
  8. l'allineamento avverrebbe racchiudendo le parti da allineare dentro delle section da trascludere fianco a fianco con granularità a piacere (ripetendo se necessario l'intera struttura più volte per ciascuna coppia di section da allineare)
  9. Tutto questo solo in ns0. In nsPagina mi limiterei a marcare le section, e al massimo si possono usare {{Colonna}} e {{AltraColonna}}
Can da Lua (disc.) 11:44, 10 lug 2015 (CEST)
@Candalua: Studierò bene la tua proposta e proverò ad applicarla appena possibile giocando un po' con il mio css. Tuttavia, piuttosto che chiudere .testi, immaginavo di creare una classe .testiGrandi anche vuota, in modo di poter assegnare un css specifico a .testiGrandi .testi; questo permetterebbe di ficcare un templatino prima di Intestazione/IncludiIntestazione e non pensarci più, così penso si eviterebbero anche mancamenti dello script per la barra di navigazione. Lo svantaggio (ma secondo me non è un svantaggio) è che anche il box Intestazione si adeguerebbe alla larghezza del testo. Pienamente d'accordo sulle sezioni a fronte da allineare: una bella tabella, un pages dentro ciascuna cella (sfruttando bene i nuovi parametri tipo onlysection o di filtraggio pagine) e tanti saluti; purchè non restino link pagina flottanti qua e là. Alex brollo (disc.) 12:13, 10 lug 2015 (CEST)
PS aggiungo sperando che tu non abbia già "consumato il ping": il testo in corso, su cui provare, è Indice:Proverbi, tradizioni e anneddoti delle valli ladine orientali.djvu, in particolare ostici i racconti per esempio da Pagina:Proverbi, tradizioni e anneddoti delle valli ladine orientali.djvu/97 su cui mi sono arrabattato senza cavare il ragno dal buco (con codice decentemente semplice!) Alex brollo (disc.) 12:23, 10 lug 2015 (CEST)
@Alex brollo: Il templatino prima di Intestazione non mi piace tanto, ci sono già troppe cose in quella posizione; ma banalmente si può anche aggiungere un parametro |larghezza= a Intestazione. Questo permetterebbe di non aggiungere altri div e sfruttare il div.testi già esistente (possiamo proprio piazzare la dimensione come stile inline). Il rovescio è che l'intestazione e tutto il testo useranno la "larghezza large", ma questo può anche essere accettabile (non ho guardato come è fatto il testo e me ne guardo bene, il lavoraccio lo lascio fare a te :D ) Can da Lua (disc.) 17:48, 10 lug 2015 (CEST)
@Candalua, Alex brollo: Ok me la sono cercata. Test iniziali (in html) qui: Pírĕ dal Polver.. Alex brollo (disc.) 12:18, 11 lug 2015 (CEST)
@Candalua: Mi sembra che ci siamo, in ns0 mi appoggio su un nuove template {{Taf}} (acronimo di Testi a fronte) che fa tutto quello che serve. Alla fine mi sono trovato meglio con un codice tabella, tanto è tutto "nascosto" dentro il template. Il parametro larghezza= viene gestito bene da IncludiIntestazione e volendo inserire dei pezzi di testo con la larghezza di default di class=testi vasta aprire e chiudere una <div class="testi">: la barra di navigazione inferiore non ne risente. In nsPagina si può fare quello che si vuole, basta attribuire le section ai vari pezzi da montare in modo avveduto. Cercherò di rappresentare il gioco di section necessario con un'immagine. --Alex brollo (disc.) 11:36, 12 lug 2015 (CEST)
@Alex brollo: Non male la resa. Il modo d'uso del template mi piace, bisognerebbe solo generalizzarlo prevedendo la possibilità di ulteriori colonne e permettendo di assegnare una larghezza a piacere a ciascuna colonna. Can da Lua (disc.) 11:51, 13 lug 2015 (CEST)
@Candalua: In questo caso bisognerebbe luizzarlo: con il normale codice template è possibile, ma fastidioso, come sai, gestire cose multiple di numero non predeterminato. In ogni caso, la possibilità di usarlo in forma "semplificata" con parametri posizionali potrebbe risolvere il caso standard, lasciando a un numero indeterminato di parametri nominali il compito di gestire la personalizzazione. Fra l'altro: con la sola avvertenza di chiamare le section affiancate xxxS, xxxD (ossia: stesso nome base + suffisso Sinistra-Destra) potrebbe permettere di ridurre i parametri indispensabili da 5 a 4. Infine: il parametro larghezza= permetterà di risolvere anche altri casi, tipo quello spinoso delle tabelle larghe. Bisognerebbe controllare se si impappina il meccanismo per le annotazioni a lato (temo di sì....). Alex brollo (disc.) 13:54, 13 lug 2015 (CEST)
@Alex brollo: Anche senza Lua, basta prevedere max 3-4 colonne (non penso abbia senso prevederne più di così). Mi perplime un attimo la scelta della larghezza in percentuale... a seconda della larghezza dello schermo, questo potrebbe risultare in un div.testi più piccolo del normale... Can da Lua (disc.) 13:58, 13 lug 2015 (CEST)
@Candalua: La prima versione usava larghezza in em, ma ho visto che l'ePub risultante era illeggibile con Adobe; ho cambiato parecchie cose fra cui l'unità di misura della larghezza e non ho controllato ulteriormente. :-(
Mi pare comunque che a larghezza si possa dare qualsiasi unità di misura: verifico.... sì; pensi sia meglio prevedere il dimensionamento obbligatorio in em? Invece alla larghezza in percentuale delle colonne della tabella non rinuncerei. Metto nella doc di Taf il codice esplicito, così chiunque, se vuole fare un fine tuning, può farlo. --Alex brollo (disc.) 08:30, 14 lug 2015 (CEST)
@Alex brollo: Visto che normalmente div.testi ha width:33em, direi di dare una larghezza sempre in em (che per l'epub si può ovviamente scavalcare agendo su Mediawiki:Epub.css). Bene la larghezza in percentuale per le colonne. Can da Lua (disc.) 10:21, 14 lug 2015 (CEST)
@Candalua: OK ... basta una sciocchissima modifica di Intestazione e la correzione delle poche pagine che chiamano Taf. Intanto tu tieni i neuroni ben vispi per pescare, se trovi l'occasione, altri usi sia del parametro larghezza che del trucco Taf. --Alex brollo (disc.) 11:33, 14 lug 2015 (CEST)
@Candalua: Sistemato {{Intestazione}}, adesso accetta, come larghezza, solo un numero, che considera di default come em. Per i testi a fronte usuali, un numero da 50 a 55 non crea troppi pastrocchi con i link pagina. --Alex brollo (disc.) 07:47, 16 lug 2015 (CEST)

DjvuLibre bot[modifica]

Immaginiamo un bot su Tool Labs che riceva i comandi di DjvuLibre - tali quali, e che faccia solo due cose: o restituisce l'output allo script chiamante via Ajax (allo script chiamante il compito di usare in un modo o nell'altro ciò che riceve: puro testo, immagini, xml....). Aggiungiamo una banale routine per caricare il djvu chiamato in qualche cache e tenercelo per qualche giorno, per averlo a disposizione immediatamente in caso di richieste ripetute. Su tool labs djvuLibre c'è, e le richieste vengono immediatamente eseguite. E allora: chi lo fa, questo bot? Per gli skillheads dovrebbe essere questione di un'oretta di lavoro. Io ci proverò, ma è un secolo che non metto le mani su chiamate e risposte Ajax di un ipotetico bot ... e sì che anni fa lo sapevo (ok, in modo primitivo) fare.... --Alex brollo (disc.) 18:07, 13 lug 2015 (CEST)

Variabili globali javascript[modifica]

Per cortesia, qualcuno mi dice dove devo mettere le variabili globali che mi servono? Nell'oggetto windows (globali singole) no; nell'oggetto mediawiki no; men che meno nell'oggetto jquery; ma leggo che mediawiki e jquery dovrebbero essere le due uniche variabili globali da usare. E allora, "perdindirindina", dove le metto? Perchè qualcuna mi serve!!!! Soprattutto le variabili-funzione. --Alex brollo (disc.) 09:48, 24 lug 2015 (CEST)

[583] e [584], da leggere anche gli altri paragrafi. --Ricordisamoa 02:22, 25 lug 2015 (CEST)
@Ricordisamoa, Candalua: Grazie Ricordisamoa. A parte la questione delle variabili private, che mi sfugge completamente, e a parte il fatto che sono linee guida generali e non specifiche per mediawiki, ok: ci serve un "oggetto personale itsource" a cui potrebbe essere assegnato tutto ciò che deve essere pubblico, funzioni comprese; fermo restando che occorre riflettere bene sulla possibilità di evitare al massimo la necessità di "cose pubbliche". A questo punto però preferirei che l'organizzazione delle "linee guida" andasse nelle mani qualcuno che ne sa più di me e sa come tenere le cose in ordine. --Alex brollo (disc.) 09:17, 27 lug 2015 (CEST)

Limiti dei template Pr1-Pr2-Pr3[modifica]

@Candalua, Xavier121, Lino Marco: Dopo una dura battaglia ho dovuto gettare la spugna: {{Pr1}}, {{Pr2}}, {{Pr3}} non possono funzionare nei testi in prosa, ma solo in quelli in versi. Per ottenere l'effetto "a lato" nei testi in prosa non resta, per ora, che {{Annotazione a lato}} + {{NMIS}} in ns0. Fra l'altro: non oso vedere cosa {{Pr1}}, {{Pr2}}, {{Pr3}}, {{Annotazione a lato}} e {{NMIS}} combinano se usati con {{Taf}}.... temo degli orrori.

Mi pare di ricordare che i link pagina, in ns0, un tempo erano "float:left" mentre adesso sono "position:absolute" e che si appoggiano per il posizionamento a .testi che ha un "position:relative". Sono io che ricordo male o le cose erano diverse? --Alex brollo (disc.) 22:33, 4 ago 2015 (CEST)

Ribollimenti su mul.source[modifica]

Osservate questa riga di puro testo:

  • linee,es,Riunisce le linee di testo di u paragrafo *Alt+5*,unisciLinee

Ebbene, su mul.source questa riga, messa in una normale sottopagina utente /PersonalButtons, fa le seguenti cose:

  1. crea un bottone linee,
  2. al passaggio del mouse compare la scritta Riunisce le linee di testo di u paragrafo *Alt+5*,
  3. collega il bottone alla funzione unisciLinee(),
  4. ma, novità, immediatamente collega il bottone allo shortcut Alt+5, lasciando all'utente la completa scelta di tutto.

Grazie @Ricordisamoa: per avermi spintonato a approfondire qualcosetta su iffy e namespaces e dintorni; a @C.R.: per avermi dato l'opportunità di tentare la "formattazione" di tutto ripartendo da zero (ma gli strumenti c'erano già tutti, grazie al lavoro di @Candalua:.... è bastato ripensarli e riassemblarli); e ai "piani alti" per aver incasinato talmente la questione dei gadget, da incoraggiarmi a farne totalmente a meno :-P. Alex brollo (disc.) 14:01, 13 ago 2015 (CEST)

applausi!!! non vedo l'ora di fare prove tranquillamente--C.R. (disc.) 22:49, 13 ago 2015 (CEST)

TemplateScript[modifica]

@Candalua, Ricordisamoa: Linko un messaggio di Pathoschild a Samuele Papa riguardo a TemplateScript.

Ovviamente Pathoschild non può immaginare cos'abbiamo combinato noi in tema di script e gadgets :-D ma intravedo la possibilità di usare TemplateScript come "framework" per le nostre boldaggini - un'occasione di mettere le cose in ordine. Personalmente il primo approccio con lo script è stato disarmante (ha un notevole livello di astrazione/generalizzazione, lascia tramortiti....) ma mettendosi forse.... --Alex brollo (disc.) 10:39, 19 ago 2015 (CEST)

Aggiungo: su en.source si trovano già implementazioni pratiche di TemplateScript, in particolare in queste due pagine:
Forse questa è la migliore occasione per ritornare a lavorare. Credo veramente che questo strumento possa sistemare tutti i gadget che con gli anni sono stati creati. Sarebbe utile creare un elenco di script che vanno aggiornati, così lasciamo indietro quelli che deprechiamo. Comincio intanto provando a sostituire gli Strumenti per la rilettura che sono sempre così tanto utili, per creare anche degli esempi che possono essere utili per il futuro. Samuele 14:28, 19 ago 2015 (CEST)
Ho chiesto a Pathoschild di scrivere il codice per permettere a TemplateScript di creare un "bottone nella bottoniera"; la sidebar è scomoda, se i tools sono più di una manciata. Ha subito accettato :-) --Alex brollo (disc.) 16:25, 19 ago 2015 (CEST)
... e ha fulmineamente mantenuto la promessa, il codice è già nelle mani di Samuele che ne farà buon uso! Ammetto che TemplateScript al momento mi intimidisce un po'. Alex brollo (disc.) 13:57, 20 ago 2015 (CEST)
Con @Alex brollo: pensavamo di creare un elenco dei tool, così da poterli utilizzare con TemplateScript e aggiornarli nel caso in cui siano troppo macchinosi. Dove possiamo fare questo? Direttamente qui nel bar tecnico oppure dobbiamo dedicare una pagina apposita? Samuele 16:45, 20 ago 2015 (CEST)
A occhio e croce, il lavoro da fare sarà così impegnativo che occorrerà strutturarlo, io proporrei una sottopagina di Progetto:Trascrizioni (e sua pagina di discussione dedicata) Alex brollo (disc.) 18:40, 20 ago 2015 (CEST)
Ho creato il sottoprogetto Progetto:Trascrizioni/TemplateScript, provando anche a dare una struttura per poter rendere il lavoro più modulare e resistente possibile. Richiede ancora una formattazione più invitante. Samuele 15:58, 21 ago 2015 (CEST)

TemplateScript 2.0[modifica]

Hi! The next major version of TemplateScript will be 2.0. This version will streamline TemplateScript for the way users actually use it, and add support for the newest MediaWiki features. This includes:

  • simplifying script helpers (so you can use page.replace(...) instead of context.helper.replace(...));
  • adding more script helpers (like page.get() to get the page text and page.options({ minor: true, watch: true }) to set form options);
  • making forActions: 'edit' the default value (so you don't need to specify it anymore);
  • and supporting CodeEditor and VisualEditor.

The changes will be deployed gradually in the current 1.12.x branch, and it'll tick over into 2.0 once all usages have been updated and backward compatibility is removed.

Since you're planning to use TemplateScript heavily on this wiki, here's your chance to provide feedback for the next version. Feel free to comment here or in the GitHub repository. :) Pathoschild (disc.) 07:01, 23 ago 2015 (CEST)

TemplateScript 2.0 is released! This replaces the context argument for custom scripts with a more powerful editor. Some of the improvements:
  • You can use new helpers like editor.get() to get the text, editor.set(text) to change the text, editor.prepend(text) and editor.append(text) to insert text, and editor.options({ minor: true, watch: true }) to set form options. These methods are all compatible with the normal wiki editor and the CodeEditor.
  • You can now use helpers on custom textboxes. For example, when editing in the Page namespace this will add something to the header:
    editor.forField('#wpHeaderTextbox').prepend('{{RigaIntestazione|}}');
    
  • You can now specify namespaces by name:
    pathoschild.TemplateScript.add({ name: 'clean up OCR', script: ..., forNamespaces: 'discussioni utente' })
    
  • You no longer need to specify forActions: 'edit'; that's the default value now.
  • You can translate TemplateScript!
See m:TemplateScript for the updated documentation. Pathoschild (disc.) 02:31, 30 ago 2015 (CEST)

References in footer è diventato inutile?[modifica]

Mi pare che qualcosa sia cambiato: <references/> in footer non serve più, e a quanto sembra neppure altrove. Da quando? Come? Perchè? --Alex brollo (disc.) 08:19, 31 ago 2015 (CEST)

Forse phab:T68860. --Ricordisamoa 08:46, 31 ago 2015 (CEST)

Css: problema[modifica]

Domanda a chi "mastica" Css come una gomma americana. E' possibile, con style inline, attribuire a una div uno stile da applicarsi SOLO nei tag p figli, e non alla div stessa? Questa storia dei p automatici aggiunti a tradimento mi fa uscire pazzo. --Alex brollo (disc.) 11:10, 31 ago 2015 (CEST)

No, non con stili inline. Al massimo i figli possono ereditare qualcosa dal padre. Vedi http://stackoverflow.com/questions/10833075/can-inline-css-apply-to-child-elements-nested-in-the-styled-element Can da Lua (disc.) 11:40, 31 ago 2015 (CEST)
Grazie Candalua. Lo temevo... quindi su mul.source, dove per fortuna sono utente semplice e non posso pasticciare su MediaWiki:Common.css, non posso agire sullo stile dei tag p via stile div; però posso usare tag p espliciti e così (con qualche limitazione) frego il sistema. :-) --Alex brollo (disc.) 11:46, 31 ago 2015 (CEST)
@Candalua: Nel frattempo ho "aperto un task" su Phabricator, per chiedere che vengano sbloccati i due tag html colgroup e col, di cui sento terribilmente la mancanza, e che permetterebbero di formattare con una sola istruzione una intera colonna di celle - cosa vitale nelle tabelle "tipo Silvio". Spero che il fatto che il tag non è previsto dal markup wiki per le tabelle non sia un ostacolo "filosofico" insormontabile, anche perchè adesso con Lua si può generare html al volo. --Alex brollo (disc.) 16:05, 1 set 2015 (CEST)
https://phabricator.wikimedia.org/T2986 (capperi, che folla in dieci minuti!!!!) --Alex brollo (disc.) 16:22, 1 set 2015 (CEST)
Sembra che vi sia consenso wikisourciano sull'opportunità di rimuovere il filtro per i due tag html colgroup e col, e qualcuno supporta il mio suggerimento di togliere il filtro subito, e poi con calma aggiornare le funzioni parser del markup tabelle; questo permetterebbe di costruire dei template (meglio in Lua) che generino tabelle html bypassando il markup, e forse perfino semplificando le cose. Non appena il filtro sarà rimosso (speriamo presto, intravedo una possibile "philosophy war") c'è da sperimentare. E' curioso che esista un così ampio divario fra le legittime, banali necessità del povero utente comune (soprattutto wikisourciano) e le raffinatezze che appassionano i "piani alti". Alex brollo (disc.) 15:22, 2 set 2015 (CEST)

La riparazione di selAut[modifica]

... E' stata una cosa drammatica, ma forse mi ha permesso di capire una cosa astrusa, la scrivo qui anche per chiarirmi le idee.

Se dalla console cercate la funzione selAut(), quella base che viene chiamata dal pulsante Button AC.png e da nient'altro, non c'è; eppure il pulsante funziona e la chiama. Ciò avviene perchè la funzione è definita solo dentro il gadget che è interpretato come una "iffy"; e come selAut, tutte le altre funzioni collegate. Non solo: se un gadget richiede funzioni definite in altri gadget, ossia vi sono dipendenze, la sintassi che definisce le dipendenze ha, principalmente, lo scopo di rendere accessibili le funzioni da cui dipende il gadget al momento della creazione dell'oggetto; non è quindi solo questione di ordine di caricamento, è questione di condivisione di namespace; e le questione di namespace, notoriamente, sono uno dei peggiori problemi di javascript.

Non so se queste idee sono vere, verosimili o se la sensazione di aver capito è pura illusione; sta di fatto che, applicandole, selAut l'ho riparato in pochi minuti, dopo settimane di avvilimento profondo :-) --Alex brollo (disc.) 06:31, 1 set 2015 (CEST)

Tabellua[modifica]

Secondo voi, è fattibile/utile una implementazione in Lua della generazione tabelle, tale che passandogli come parametro semplicemente il copiaincollato da Excel (celle divise da tab, righe divise da acapo) venga fuori una tabella html regolare? Sarebbe ovviamente solo il primo passo, poi si potrebbe raffinare con la gestione degli stili (ho l'intuizione paranoide su un secondo parametro in cui venga passata una seconda copia opzionale della tabella, con la stessa struttura ma in cui ogni cella contenga, al posto del testo, lo stile). --Alex brollo (disc.) 08:15, 3 set 2015 (CEST)