Wikisource:Domande tecniche/Archivio/2014

Archivio delle domande tecniche del 2014

Portale progetti   Progetto qualità   Domande tecniche   Archivio   2014 

09:47, 30 dic 2013 (CET)

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)[rispondi]

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)[rispondi]
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)[rispondi]

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)[rispondi]

(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)[rispondi]
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)[rispondi]

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)[rispondi]

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)[rispondi]
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)[rispondi]
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)[rispondi]
È 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)[rispondi]
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)[rispondi]
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)[rispondi]
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)[rispondi]
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)[rispondi]
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)[rispondi]
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)[rispondi]

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)[rispondi]

@Alex brollo: qual è il problema? --Ricordisamoa 21:36, 17 gen 2014 (CET)[rispondi]
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)[rispondi]

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)[rispondi]

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)[rispondi]
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)[rispondi]
@RicordisamoaCome 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)[rispondi]
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)[rispondi]
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)[rispondi]
Trovato! action=wbgetentities in mediawiki :-) --Alex brollo (disc.) 14:53, 23 gen 2014 (CET)[rispondi]
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)[rispondi]
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)[rispondi]
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)[rispondi]

@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)[rispondi]

@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)[rispondi]
@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)[rispondi]
@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)[rispondi]

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)[rispondi]

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)[rispondi]
  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)[rispondi]
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)[rispondi]
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)[rispondi]
@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   --Ricordisamoa 22:21, 5 feb 2014 (CET)[rispondi]

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)[rispondi]

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)[rispondi]

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)[rispondi]
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)[rispondi]
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)[rispondi]
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)[rispondi]
@Alex brollo su Tool Labs sono ancora un novellino, fai bene a chiedere ad altri ;-) --Ricordisamoa 03:26, 13 feb 2014 (CET)[rispondi]

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)[rispondi]

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)[rispondi]

@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)[rispondi]

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)[rispondi]

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)[rispondi]

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)[rispondi]
Il template Autore non potrebbe includere anche i tag "section" già compilati? --Ricordisamoa 23:38, 16 feb 2014 (CET)[rispondi]
No, non si può inserire il tag section in un template. Magari.... --Alex brollo (disc.) 00:23, 17 feb 2014 (CET)[rispondi]

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

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)[rispondi]
Per i pythonomani: sto sperimentando la class Eye (la "classe occhio") :-) --Alex brollo (disc.) 09:30, 18 feb 2014 (CET)[rispondi]
Conosci imagemagick? Lo usavano qui in ufficio per ruotare-croppare-splittare in batch. --Aubrey (disc.) 12:58, 18 feb 2014 (CET)[rispondi]
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:

   

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)[rispondi]
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)[rispondi]

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)[rispondi]

Segnalazione modifica

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

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)[rispondi]

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)[rispondi]

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)[rispondi]

10:10, 10 mar 2014 (CET)

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)[rispondi]

Perché non CKEditor? --Ricordisamoa 16:48, 17 mar 2014 (CET)[rispondi]
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)[rispondi]
Non hai pensato a un plugin specifico per VisualEditor? --Ricordisamoa 15:25, 18 mar 2014 (CET)[rispondi]
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)[rispondi]
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)[rispondi]

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)[rispondi]

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)[rispondi]

@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 (IA) 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)[rispondi]
@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)[rispondi]
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)[rispondi]

19:56, 24 mar 2014 (CET)

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)[rispondi]

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)[rispondi]

10:00, 7 apr 2014 (CEST)

09:18, 14 apr 2014 (CEST)

10:34, 21 apr 2014 (CEST)

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

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)[rispondi]

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)[rispondi]

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)[rispondi]

Cosa aggiungono queste immagini ritagliate alle pagine già presenti su Commons? --Ricordisamoa 18:46, 26 apr 2014 (CEST)[rispondi]
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)[rispondi]
Niente da fare. :-( --Alex brollo (disc.) 16:54, 28 apr 2014 (CEST)[rispondi]

09:22, 28 apr 2014 (CEST)

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)[rispondi]
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)[rispondi]

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)[rispondi]

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)[rispondi]

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)[rispondi]

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)[rispondi]

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)[rispondi]
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)[rispondi]

10:29, 26 mag 2014 (CEST)

10:07, 2 giu 2014 (CEST)

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)[rispondi]

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)[rispondi]

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)[rispondi]

09:13, 16 giu 2014 (CEST)

09:20, 23 giu 2014 (CEST)

08:53, 30 giu 2014 (CEST)

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)[rispondi]

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)[rispondi]
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)[rispondi]

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)[rispondi]

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)[rispondi]

@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)[rispondi]

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)[rispondi]

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)[rispondi]

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)[rispondi]

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)[rispondi]

09:41, 21 lug 2014 (CEST)

10:08, 28 lug 2014 (CEST)

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)[rispondi]

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)[rispondi]

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)[rispondi]

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

09:43, 11 ago 2014 (CEST)

09:16, 18 ago 2014 (CEST)

11:21, 25 ago 2014 (CEST)

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)[rispondi]

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)[rispondi]

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)[rispondi]

@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)[rispondi]
@Alex brollo la documentazione è sempre d'aiuto! --Ricordisamoa 16:13, 2 set 2014 (CEST)[rispondi]
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)[rispondi]

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)[rispondi]

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)[rispondi]
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)[rispondi]

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)[rispondi]

Fico! E anche leggermente inquietante :D Candalùa (disc.) 16:29, 17 set 2014 (CEST)[rispondi]
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)[rispondi]
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)[rispondi]
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)[rispondi]

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)[rispondi]

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)[rispondi]
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)[rispondi]
@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)[rispondi]

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)[rispondi]

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)[rispondi]
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)[rispondi]
@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)[rispondi]
@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)[rispondi]
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)[rispondi]

<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)[rispondi]

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

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)[rispondi]

@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)[rispondi]

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)[rispondi]

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)[rispondi]
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)[rispondi]
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)[rispondi]

Primo passo verso la generalizzazione modifica

@Candalua, @RicordisamoaAdesso 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)[rispondi]

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)[rispondi]

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)[rispondi]

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)[rispondi]

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)[rispondi]
@Samuele Papavedi anche Discussioni progetto:Trascrizioni/newThumbs --Alex brollo (disc.) 10:31, 24 ott 2014 (CEST)[rispondi]

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)[rispondi]
  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)[rispondi]

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)[rispondi]

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)[rispondi]
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)[rispondi]
@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)[rispondi]
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)[rispondi]
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)[rispondi]
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)[rispondi]
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)[rispondi]
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)[rispondi]

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)[rispondi]

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)[rispondi]

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)[rispondi]

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)[rispondi]
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)[rispondi]

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)[rispondi]

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)[rispondi]

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)[rispondi]

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)[rispondi]
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)[rispondi]

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)[rispondi]

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)[rispondi]

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)[rispondi]

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)[rispondi]
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)[rispondi]

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)[rispondi]

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)[rispondi]
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)[rispondi]
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)[rispondi]

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)[rispondi]

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)[rispondi]

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)[rispondi]

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)[rispondi]

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)[rispondi]

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)[rispondi]

@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)[rispondi]
Ovviamente, come il solito, dormivo. :-) Alex brollo (disc.) 08:55, 23 dic 2014 (CET)[rispondi]

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)[rispondi]

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)[rispondi]
@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)[rispondi]