Immaginiamo un bot su Tool Labs che riceva i comandi di DjvuLibre - tali quali, e che faccia solo due cose: o restituisce l'output allo script chiamante via Ajax (allo script chiamante il compito di usare in un modo o nell'altro ciò che riceve: puro testo, immagini, xml....). Aggiungiamo una banale routine per caricare il djvu chiamato in qualche cache e tenercelo per qualche giorno, per averlo a disposizione immediatamente in caso di richieste ripetute. Su tool labs djvuLibre c'è, e le richieste vengono immediatamente eseguite. E allora: chi lo fa, questo bot? Per gli ''skillheads'' dovrebbe essere questione di un'oretta di lavoro. Io ci proverò, ma è un secolo che non metto le mani su chiamate e risposte Ajax di un ipotetico bot ... e sì che anni fa lo sapevo (ok, in modo primitivo) fare.... --[[User:Alex brollo|Alex brollo]] ([[User talk:Alex brollo|disc.]]) 18:07, 13 lug 2015 (CEST)
Immaginiamo un bot su Tool Labs che riceva i comandi di DjvuLibre - tali quali, e che faccia solo due cose: o restituisce l'output allo script chiamante via Ajax (allo script chiamante il compito di usare in un modo o nell'altro ciò che riceve: puro testo, immagini, xml....). Aggiungiamo una banale routine per caricare il djvu chiamato in qualche cache e tenercelo per qualche giorno, per averlo a disposizione immediatamente in caso di richieste ripetute. Su tool labs djvuLibre c'è, e le richieste vengono immediatamente eseguite. E allora: chi lo fa, questo bot? Per gli ''skillheads'' dovrebbe essere questione di un'oretta di lavoro. Io ci proverò, ma è un secolo che non metto le mani su chiamate e risposte Ajax di un ipotetico bot ... e sì che anni fa lo sapevo (ok, in modo primitivo) fare.... --[[User:Alex brollo|Alex brollo]] ([[User talk:Alex brollo|disc.]]) 18:07, 13 lug 2015 (CEST)
== Variabili globali javascript ==
Per cortesia, qualcuno mi dice ''dove devo mettere le variabili globali che mi servono''? Nell'oggetto windows (globali singole) no; nell'oggetto mediawiki no; men che meno nell'oggetto jquery; ma leggo che mediawiki e jquery dovrebbero essere le due uniche variabili globali da usare. E allora, "perdindirindina", dove le metto? Perchè qualcuna mi serve!!!! Soprattutto le variabili-funzione. --[[User:Alex brollo|Alex brollo]] ([[User talk:Alex brollo|disc.]]) 09:48, 24 lug 2015 (CEST)
Versione delle 09:48, 24 lug 2015
Domande tecniche
il punto d'incontro e discussione tra geek e niubbi!
Pagina dedicata a domande sul software, sulla struttura organizzativa del progetto, sulla visualizzazione e i bug dei browser.
Le comunicazioni Tech News verranno ricevute su Wikisource:Domande tecniche/Tech News.
Latest tech news from the Wikimedia technical community. Please inform other users about these changes. Not all changes will affect you. Translations are available.
Recent software changes
You can now see the text of DjVu and PDF files in search results on wikis testing the new search tool (CirrusSearch). [1][2]
With the new version of the Wikibase DataModel extension, you can install it outside Wikimedia wikis. [3]
Images are now shown inside VisualEditor as HTML5<figure /> elements. Comments are welcome. [4]
You can now test a basic version of VisualEditor on mobile devices; see this article as an example.
Problems
On December 23, Wikimedia Labs was broken for 4 hours due to an NFS problem. [5]
Future software changes
CirrusSearch will be added as the second search method for Spanish (es), French (fr), Portuguese (pt) and Russian (ru) wikis on December 30. Wikimedia Commons, Wikispecies and Wikinews users will also be able to enable it in their Beta Features options.
Latest tech news from the Wikimedia technical community. Please inform other users about these changes. Not all changes will affect you. Translations are available.
Recent software changes
The latest version of MediaWiki (1.23wmf9) was added to test wikis and MediaWiki.org on January 2. It will be enabled on non-Wikipedia wikis on January 7 and on all Wikipedia wikis on January 9 (calendar).
On January 2, Wikimedia Commons, Wikidata and all Wikivoyage projects were broken for 2 hours due to language cache update issues.
On the same day, it was not possible to edit most wikis for about 30 minutes, due to a database replication problem.
Future software changes
The new search tool (CirrusSearch) will be added as the default search method for Italian Wikipedia, French Wikisource, Wikidata and all Wikivoyage sites, and as a second search method for the German Wikipedia and all Wikibooks sites on January 6. [13]
Spanish, French, Portuguese and Russian Wikipedia users will also be able to enable CirrusSearch in their Beta Features options. [14]
Plural form rules for some languages will be changed. Many translations of the user interface for Belarusian, Russian, Serbian, Ukrainian and other languages will need to be changed. [15][16][17]
You will see a warning when you try to delete a page linked to from other pages. [18][19]
You will be able to use keyboard shortcuts in the Translate tool, by pressing Alt+1 and similar key groups. [22][23]
E-mails sent by MediaWiki will include the name of the site in their From: line. You will be able to change this name on your wiki by editing the MediaWiki:Emailsender page. [24][25]
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.
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
Essendomi stato vietato di produrre nuovi tool, ho giocato un po' con il css (per alleggerire il codice delle tabelle).
/* 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]
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]
È 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".
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]
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]
Latest tech news from the Wikimedia technical community. Please inform other users about these changes. Not all changes will affect you. Translations are available.
You can read a recent blog post about how Tech News is put together, translated and sent to you across wikis each week.
Recent software changes
The latest version of MediaWiki (1.23wmf10) was added to test wikis and MediaWiki.org on January 9. It will be added to non-Wikipedia wikis on January 14, and all Wikipedia wikis on January 16 (calendar).
Searching in the File: namespace on Wikimedia Commons may be slow due to a search engine issue. [28]
VisualEditor news
VisualEditor will be added for all users on several Wikipedias on January 13. [29]
You can now add and remove __NOTOC__, __FORCETOC__ and __NOEDITSECTION__ in the page metadata menu. [30][31][32]
Problems
For a few hours on January 6, it was not possible to edit pages using the Translate tool on Wikimedia Commons and the Wikimania 2013 wiki, due to a settings error. [33][34]
For about 20 minutes on January 9, there were problems with CSS and JavaScript due to high server load.
Future software changes
Wikidata will be added to all Wikisource wikis on January 14. [35]
The new search tool (CirrusSearch) will be added as the second search method for the English Wikipedia on January 13. On Wikibooks and the German Wikipedia, you will also be able to test it by adding it in your Beta Features options.
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)
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]
Latest tech news from the Wikimedia technical community. Please inform other users about these changes. Not all changes will affect you. Translations are available.
Recent software changes
The latest version of MediaWiki (1.23wmf11) was added to test wikis and MediaWiki.org on January 16. It will be added to non-Wikipedia wikis on January 28, and all Wikipedia wikis on January 30 (calendar).
As of January 16, you can make and use guided tours on the Asturian, Farsi and Russian Wikipedias. If you want this tool on your wiki, you need to translate it and ask in Bugzilla. [41][42]
You can give comments on an idea to have a fixed toolbar at the top of wiki pages. [43]
quest'anno non anrò in montagna perchè impegnato col lavoro. [44]
VisualEditor news
In the toolbar, the menu to edit the styles (like bold, italic, etc.) now has a down arrow (). The order of the Insert menu has also changed a little.
You can now edit <gallery /> tags with a very basic tool. [45]
You can now see a help page about keyboard shortcuts in the page menu. [46]
When you change categories, you will now see them when you save the page. [47]
When you edit templates, you will now see the parameters in the right order. The ones that you must add have a star (*). [48][49]
The page will now be saved faster, thanks to a new way of coding the text that sends 40% less text to the servers. [50]
There was a problem with search on the English and German Wikipedias between January 6 and January 14. You could not see new pages and changes in search results. [52]
There were "pool timeouts" errors on several wikis on January 13; it was caused by a code change that was made to fix another problem. [53]
On January 17, Bugzilla and Wikimedia Labs were broken for about 20 minutes due to network problems. IRC channels with recent changes (irc.wikimedia.org) were broken for about two hours. [54]
Future software changes
Orange bar with new messages
If you have removed JavaScript in your web browser, you will soon be able to see the orange bar saying that you have new messages. If you have changed how the bar looks with a gadget, you may need to change the gadget again. [55][56]
You will soon be able to add a given Flickr user to a blacklist so that their files can't be uploaded using UploadWizard on Wikimedia Commons and other wikis. [57]
You will see a warning when you try to delete a page included in at least one other page. [58]
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]
Alex, da quello che diceva Ricordisamoaqui, 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]
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]
@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]
@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
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 --Ricordisamoa22:21, 5 feb 2014 (CET)[rispondi]
Soppressione di dehyphen()
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]
Latest tech news from the Wikimedia technical community. Please inform other users about these changes. Not all changes will affect you. Translations are available.
Cambiamenti recenti al software
Pages from Wikimedia sites now load faster in your browser thanks to "module storage", a way for your browser to save data like JavaScript and CSS on your computer to avoid downloading them again. See video. [61]
The code used to show videos has changed. You should be able to play the video on the page, with the play button on top of the video. If you see the play button on the right of the video, or if clicking on the video leads you to the original file, please file a bug or tell User:Bawolff. [62]
The Special:ActiveUsers page will be removed because it's too slow. [63]
The latest version of MediaWiki (1.23wmf11) was added to test wikis and MediaWiki.org on January 16. It will be added to non-Wikipedia wikis on January 28, and all Wikipedia wikis on January 30 (calendar).
Problemi
On January 21, Universal Language Selector was turned off on all Wikimedia sites because it makes pages load slowly. If you want to use web fonts, or write in scripts that aren't on your keyboard, you need to add it as an option in your preferences. It will be turned back on when the issues are resolved. [64]
For about 20 minutes on the same day, there were problems with CSS and JavaScript due to high server load.
Cambiamenti futuri di software
You can give comments about the new version of "Winter", a proposal to have a fixed toolbar at the top of wiki pages. [65]
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]
Latest tech news from the Wikimedia technical community. Please inform other users about these changes. Not all changes will affect you. Translations are available.
Recent software changes
The latest version of MediaWiki (1.23wmf12) was added to test wikis and MediaWiki.org on January 30. It will be added to non-Wikipedia wikis on February 4, and all Wikipedia wikis on February 6 (calendar).
You can now link to diffs using [[Special:Diff/12345]] and similar links. [70]
There is no longer an option to hide tables of contents on all pages. [71]
Searching in the File: namespace on Wikimedia Commons is now faster, after a bug was fixed on January 29. [72]
All Wikimedia wikis now have high-resolution favicons. [73]
VisualEditor news
You can now see a list of keyboard shortcuts by pressing Ctrl+/ inside VisualEditor. [74]
Future software changes
Edits and files hidden with the Oversight tool will be moved to the RevisionDelete system. The Oversight tool will then be removed from Wikimedia wikis. [75][76][77]
For languages where not all sister projects exist, you will be able to link to other language projects using double interwikis (:ko:v, :v:ko, etc.). [78]
It will soon be possible to use the GettingStarted tool on other wikis than the English Wikipedia. You can translate it on Translatewiki.net. [79]
che strumenti sono disponibili sul server per l'elaborazione di immagini? C'è ancora ImageMagick? Altri?
esiste nconvert (che è quello che uso io nel mio povero pc vintage)?
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?
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]
Latest tech news from the Wikimedia technical community. Please inform other users about these changes. Not all changes will affect you. Translations are available.
Recent software changes
The latest version of MediaWiki (1.23wmf13) was added to test wikis and MediaWiki.org on February 6. It will be added to non-Wikipedia wikis on February 11, and all Wikipedia wikis on February 13 (calendar).
The Vector search box was changed to fix old display and accessibility issues; for example, you can now use full-text search even if you have disabled JavaScript. Please report any problems you see. The option to disable the "simplified search bar" on Vector will also be removed. [85][86][87][88][89]
You are now notified when someone adds a link to your user page on wikis where it didn't work before (wikis with dates in the year-month-day order, including Hungarian, Japanese, Korean and some variants of Chinese). [90]
VisualEditor news
You can now set media items' alt text and position, and directly set their size, in the media tool. [91][92]
The gallery tool was improved and several issues were fixed. [93][94][95]
Problems
On February 3, all wikis were broken for about an hour due to a traffic balancing issue. [96]
On February 6, some wikis were broken for about half an hour in total due to a problem with the Math extension.
Future software changes
Some methods from Scribunto's mw.message library will be removed after February 18. If you use them in your templates or modules, please check to make sure that things will not break. [97][98]
You will soon be able to use GettingStarted on 23 new Wikipedias. It helps new users by listing possible tasks and giving help. The new version was also added to the English Wikipedia on February 7th. [99]
You will soon see results from other wikis when you use the new search tool (CirrusSearch). [100][101]
The WikiLove tool was redesigned and should also load faster. [102]
bugzilla.wikimedia.org will be updated this week. You won't be able to access it from 22:00 UTC on February 12 until 01:00 UTC on February 13 at the latest. [111]
The <poem> tag will be renamed to <lines>. The old tag will still work. [112]
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]
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]
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]
Le ultime tech news dalla comunità dei tecnici Wikimedia. Per favore informa latri utenti di questi cambiamenti. Non tutti i cambimenti avranno effetto su di te. Sono disponibili traduzioni in altre lingue.
Cambiamenti recenti al software
La più recente versione di MediaWiki (1.23wmf14) è stata aggiunta ai test wikis e a MediaWiki.org il 13 febbraio. Sarà aggiunta ai non-Wikipedia wikis il 18 febbraio, e a tutte le Wikipedie il 20 febbraio (calendario).
Il nuovo motore interno di ricerca (CirrusSearch), se cerchi tra più namespace, ora dà la precedenza ai risultati relativi ai namespace di contenuto. [115]
Ora puoi creare link direttamente a file visualizzati tramite MultimediaViewer, il nuovo strumento per visualizzare i file multimediali. [116]
IL Wikimedia engineering report di gennaio 2014 è stato pubblicato. Puoi tradurne una versione più corta e più semplice. [117]
Problemi
Il 9 febbraio, Wikimedia Labs è collassato per circa 2 ore a causa di un problema all'XFS file system. [118]
L'11 febbraio per circa 20 minuti si sono verificati problemi con il VisualEditor per un problema ai registri del server (server logging) [119]
Lo stesso giorno, per circa 20 minuti, si sono verificati problemi con il caricamento delle pagine a causa di problemi al database.
Si sono verificati per gli utenti europei problemi al caricamento di pagine tra le 21:00 UTC del 13 febbraio e le 11:00 UTC del 14 febbraio, a causa di un problema ai server della cache.
Il 14 febbraio tutti i siti sono collassati per circa 15 minuti per gli utenti dell'Asia sudorientale, Oceania e zona occidentale del nord America. È avvenuto per problemi con i cache server.
VisualEditor news
Lo strumento link ora ti dice quando stai creando un collegamento a una pagina di disambiguazione o un redirect. [120]
Ora puoi cambiare il formato dell'immagine (come "thumbanil", "frame" e "frameless") con VisualEditor [121]
Gli avvisi del Wikitesto saranno nascosti quando rimuoverai testo da paragrafi tu che stai modificando [122]
Tra breve potrai creare e modificare pagine di redirect con VisualEditor! [123][124][125]
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:
c'è qualcuno esperto nella manipolazione delle immagini a basso livello, filtri, PIL ecc?
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]
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]
Latest tech news from the Wikimedia technical community. Please inform other users about these changes. Not all changes will affect you. Translations are available.
Recent software changes
The latest version of MediaWiki (1.23wmf15) was added to test wikis and MediaWiki.org on February 20. It will be added to non-Wikipedia wikis on February 25, and all Wikipedia wikis on February 27 (calendar).
The new search tool (CirrusSearch) was added to the Italian Wikiquote and all Wikiversity projects. Users can now enable it in their Beta options. [126][127]
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.
Latest tech news from the Wikimedia technical community. Please inform other users about these changes. Not all changes will affect you. Translations are available.
Recent software changes
The latest version of MediaWiki (1.23wmf16) was added to test wikis and MediaWiki.org on February 27. It will be added to non-Wikipedia wikis on March 4, and all Wikipedia wikis on March 6 (calendar).
When users enable web fonts by default, Universal Language Selector will now log if they don't have fonts to display pages correctly. This information will be used by developers to improve font support in the future. Read more about missing fonts. [141]
Article Feedback Tool will be removed from the English and French Wikipedias on March 3. It will also no longer be possible to add this tool to any Wikimedia wiki. [158][159]
Wikis using the new search tool will come back to the old tool for a few hours starting at 00:00 UTC on March 6. [160]
Problems
For about an hour on February 23, there were problems with page loading due to a MediaWiki bug. [161]
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
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
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?
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)
})
Latest tech news from the Wikimedia technical community. Please inform other users about these changes. Not all changes will affect you. Translations are available.
Recent software changes
The latest version of MediaWiki (1.23wmf17) was added to test wikis and MediaWiki.org on March 6. It will be added to non-Wikipedia wikis on March 11, and all Wikipedia wikis on March 13 (calendar).
It is now easier to edit templates. Complex tools are now in the "advanced" mode. [164][165]
It is also easier to edit images. You now have more options and they are explained better. [166]
VisualEditor adds fake blank lines so you can put your cursor there. They are now smaller and animated to be different from actual blank lines. [167]
We have improved the tool to add special characters. The buttons are now larger. More changes are coming. [168]
You can now use new keyboard shortcuts to undo the last action, clear formatting, and show the shortcut help window. [169][170][171]
Future software changes
You will soon be able to use a Beta option to show a shorter list of language links. That way, Universal Language Selector will only show languages that are relevant to you. You will still be able to search for other languages. [172]
An IRC discussion with the Wikimedia Foundation Language Engineering team will take place on March 12 at 17:00 UTC on the channel #wikimedia-office on Freenode (time conversion). [176]
Latest tech news from the Wikimedia technical community. Please inform other users about these changes. Not all changes will affect you. Translations are available.
Recent software changes
The latest version of MediaWiki (1.23wmf18) was added to test wikis and MediaWiki.org on March 13. It will be added to non-Wikipedia wikis on March 18, and all Wikipedia wikis on March 20 (calendar).
You can now view smaller versions of PNG images bigger than 20 megapixels. [177]
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]
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]
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]
Ipotesi per l'inserimento delle immagini nelle pagine
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
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.
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
@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]
Latest tech news from the Wikimedia technical community. Please inform other users about these changes. Not all changes will affect you. Translations are available.
Recent software changes
The latest version of MediaWiki (1.23wmf19) was added to test wikis and MediaWiki.org on March 20. It will be added to non-Wikipedia wikis on March 25, and all Wikipedia wikis on March 27 (calendar).
VisualEditor news
You can now double-click or press the ↲ Enter key on an image or template to change its settings. [189][190]
Pages that don't exist will now show as red links in the edit mode. [191]
You will no longer be able to try to use VisualEditor on pages translated using the Translate extension, and you will see a warning if you try to edit pages marked for translation. [192]
You will now see a full warning, including the most recent log entry, when you try to edit protected pages with VisualEditor. [193]
Future software changes
Typography Refresh will be enabled for test wiki and MediaWiki.org users who use the Vector skin on March 27. For users on non-Wikipedia wikis, it will be enabled on April 1, and for Wikipedia users on April 3. If you don't use Vector as your skin, you will not be affected.
You will be able to use the Hovercards tool as a beta feature on all wikis from March 26.
Le ultime tech news dalla comunità dei tecnici Wikimedia. Per favore informa altri utenti di questi cambiamenti. Non tutti i cambiamenti avranno effetto su di te. Sono disponibili traduzioni in altre lingue.
Cambiamenti recenti al software
La più recente versione di MediaWiki (1.23wmf20) è stata aggiunta ai test wikis e a MediaWiki.org il 27 marzo. Sarà aggiunta alle wiki non-Wikipedia il 1° aprile, e a tutte le Wikipedia il 3 aprile (calendario).
Typography Refresh è stato aggiunto a test wikis e MediaWiki.org il 27 marzo. Lo potrai vedere solo se usi la skin Vector. Per gli utenti delle wiki diverse da Wikipedia, sarà abilitato il 1° aprile mentre per gli utenti Wikipedia sarà abilitato il 3 aprile.
CirrusSearch, il nuovo motore di ricerca interno, sarà abilitato come funzionalità sperimentale (Beta) su più di 30 altre wiki il 27 marzo. [196][197]
VisualEditor news
Gli utenti bloccati vedranno lo stesso messaggio sia in VisualEditor che nell'editor classico. [198][199]
La casella di ricerca per riusare una nota in VisualEditor viene ripulita dopo ogni utilizzo. [200]
I link nuovi alle sotto pagine, non punteranno più alla posizione sbagliata nel VisualEditor. [201]
VisualEditor's media dialog no longer breaks when opening some types of images. [202]
Cambiamenti futuri al software
Non sarai abilitato a editare Wikitech per un breve periodo attorno alle 16:00 UTC del 1° aprile a causa di un cambio di server. [203]
CirrusSearch will become the main search engine for all non-Wikipedia wikis except Commons, Meta and Incubator on April 2.
Sarà possibile usare una nuova Pagina speciale che lista i file duplicati. [204]
Cancellare una versione di un file o cancellare la sua pagina di descrizione saranno mostrati in maniera differente nel log. [205]
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]
Le ultime tech news dalla comunità dei tecnici Wikimedia. Per favore informa altri utenti di questi cambiamenti. Non tutti i cambimenti avranno effetto su di te. Sono disponibili traduzioni in altre lingue.
Cambiamenti recenti al software
The latest version of MediaWiki (1.23wmf21) was scheduled to be deployed to test wikis and MediaWiki.org on April 3, however it was temporarily put on hold due to localization issues. (calendar).
Typography Refresh è stato abilitato su tutte le wiki non-Wikipedia il 1° aprile e su tutte le Wikipedia il 3 aprile. Sarà visibile solo se si usa la skin Vector.
CirrusSearch è stato abilitato come metodo di ricerca principale su oltre 400 wiki non-Wikipedia il 2 aprile. [206]
Latest tech news from the Wikimedia technical community. Please inform other users about these changes. Not all changes will affect you. Translations are available.
We are looking for contributors to help write new issues every week. If you would like to help, please contact us.
Recent software changes
The latest version of MediaWiki (1.23wmf22) was added to test wikis and MediaWiki.org on April 10. It will be added to non-Wikipedia wikis on April 15, and all Wikipedias on April 17 (calendar).
MediaViewer was enabled for all users on MediaWiki.org on April 10. It will be enabled for all users on the Catalan (ca), Hungarian (hu) and Korean (ko) Wikipedias and English Wikivoyage on April 17. Comments are welcome. [214][215][216]
You will now see only three options when you try to add a template parameter in VisualEditor; you will see other options after a click. [219]
The size changing controls in VisualEditor media editing dialog were simplified further.
The wikitext editor tab will now fold into a drop-down menu in the Vector skin if there is not enough space on your screen. [220][221]
Future software changes
The font used for body text on Wikimedia wikis will change to your system default sans-serif font. This temporary change will be enabled on all non-Wikipedia wikis on April 15, and on all Wikipedias on April 17. [222][223]
Files from Commons seen on another wiki will soon have a tab saying "View on Wikimedia Commons". The create tab will change to "Add local description" (see screenshot). [224]
An IRC discussion with the Wikimedia Foundation Multimedia team will take place on April 16 at 18:00 UTC on the channel #wikimedia-office on Freenode (time conversion). [234]
Problems
Wikimedia Foundation servers were updated after a security bug called Heartbleed was discovered last week. You should change your password as an extra precaution. [235]
Latest tech news from the Wikimedia technical community. Please inform other users about these changes. Not all changes will affect you. Translations are available.
We are looking for contributors to help write a new issue every week. If you would like to help, please contact us.
Recent software changes
The latest version of MediaWiki (1.24wmf1) was added to test wikis and MediaWiki.org on April 17. It will be added to non-Wikipedia wikis on April 22, and all Wikipedias on April 24 (calendar).
Problems with various fonts in SVG files were fixed last week. Files that use DejaVu Sans Condensed, DejaVu Serif Condensed, DejaVu Sans Light, Kochi Gothic and Kochi Mincho fonts now show correctly. [239][240][241][242]
You can read a summary of the Wikimedia technical report for March 2014. [244]
VisualEditor news
If you try to add a category which redirects to another category, VisualEditor will now suggest adding the target category directly. [245][246]
VisualEditor tabs will no longer appear on Education Program pages. [247][248]
You can now use VisualEditor on Meta-Wiki and the French Wikinews by enabling it in your preferences. [249][250][251]
Future software changes
MediaViewer will be enabled for all users on the Czech (cs), Estonian (et), Finnish (fi), Hebrew (he), Polish (pl), Romanian (ro), Slovak (sk), Thai (th) and Vietnamese (vi) Wikipedias on April 24. Feedback is welcome. [252]
Edits by anonymous users will now be marked with a new CSS class (mw-anonuserlink). This way, you can easily make those edits use a different color, font or background. [253][254]
An IRC discussion about Phabricator will take place on April 22 at 03:30 AM UTC on the channel #wikimedia-office on freenode (time conversion). [264]
Problems
For about 40 minutes on April 17, there were problems with page loading due to high server load.
There is a problem with the rendering of formulas with MathJax. If you enabled MathJax in your preferences, you might need to turn it off and on again. [265]
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).
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]
Latest tech news from the Wikimedia technical community. Please inform other users about these changes. Not all changes will affect you. Translations are available.
Recent software changes
The latest version of MediaWiki (1.24wmf2) was added to test wikis and MediaWiki.org on April 24. It will be added to non-Wikipedia wikis on April 29, and all Wikipedias on May 1 (calendar).
You can now use interwiki prefix c: to link to pages on Wikimedia Commons. [266]
VisualEditor news
You will soon be able to set content language and direction with VisualEditor. [267]
VisualEditor now works on all Wikipedias after broken MediaWiki:Common.js pages (and similar) were fixed last week. [268]
VisualEditor dialogs now use an animation of moving lines rather than animated GIF images.
Future software changes
CirrusSearch will be enabled as a beta feature on 41 new wikis, including Meta-Wiki and the Swedish (sv), Russian (ru), Polish (pl), Japanese (ja) and Chinese (zh) Wikipedias next week. This change means that CirrusSearch will now be enabled on all Wikimedia wikis.
MediaViewer will be enabled for all users on the French (fr) and Dutch (nl) Wikipedias on May 1. Feedback is welcome. [269]
The mobile version of Wikimedia wikis will soon include filters to limit the number of uploaded files that are copyright violations. [270]
Latest tech news from the Wikimedia technical community. Please inform other users about these changes. Not all changes will affect you. Translations are available.
Recent software changes
The latest version of MediaWiki (1.24wmf3) was added to test wikis and MediaWiki.org on May 1. It will be added to non-Wikipedia wikis on May 6, and all Wikipedias on May 8 (calendar).
The Compact Personal Bar was added as a beta feature to test wikis and MediaWiki.org on May 1. It will be added as a beta feature to non-Wikipedia wikis on May 6, and to all Wikipedias on May 8. To test it, you can enable it now in your preferences on MediaWiki.org. [278]
External links in VisualEditor are now in the same light blue color as in MediaWiki. [280]
The template tool now tells you if a parameter is obsolete. [281]
You can now add "suggested" parameters in TemplateData; VisualEditor will add them like required ones. [282]
There is a new type for TemplateData parameters: wiki-file-name for file names. [283][284]
Editing formulae in VisualEditor will soon be enabled for all users. [285][286]
You will soon be able to try a new beta feature to edit text in another language. [287][288]
Future software changes
MediaViewer will be enabled for all users on the Japanese (ja), Portuguese (pt), Spanish (es), Swedish (sv) and Telugu (te) Wikipedias on May 8. Feedback is welcome. [289]
You can help translate about 100 new language names that have been added to our data source. They are used, for example, as hover text for interwiki links. Send an e-mail to Nemo if you want to help.
If you click on a redirect page in your watchlist, you will soon access the redirect itself. [290][291]
Problems
For about 40 minutes around 00:20 UTC on April 29, there were problems with page loading due to high server load.
Tre domandine facili per i "geek maggiori" (@Candalua, @Ricordisamoa) con familiarità con l'ambiente del SO di Tool Labs.
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)?
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.
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]
Latest tech news from the Wikimedia technical community. Please inform other users about these changes. Not all changes will affect you. Translations are available.
Recent software changes
The latest version of MediaWiki (1.24wmf4) was added to test wikis and MediaWiki.org on May 8. It will be added to non-Wikipedia wikis on May 13, and all Wikipedias on May 15 (calendar).
VisualEditor news
A new citation system in VisualEditor was enabled on the English Wikipedia. It will soon be enabled on more wikis. [292]
Templates that were previously broken in VisualEditor should now appear correctly. [293]
Future software changes
It will soon be possible to move category description pages. Pages in changed categories will still have to be moved independently. [294][295]
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]
Latest tech news from the Wikimedia technical community. Please inform other users about these changes. Not all changes will affect you. Translations are available.
Tech News updates
Tech News is one year old this week; thank you for being with us!
Recent software changes
The latest version of MediaWiki (1.24wmf5) was added to test wikis and MediaWiki.org on May 15. It will be added to non-Wikipedia wikis on May 20, and all Wikipedias on May 22 (calendar).
The jQuery JavaScript library was updated on May 16. Please check that your gadgets and scripts still work. [310][311][312]
MediaViewer was enabled for all users on the Kannada (kn) and Telugu (te) Wikipedias on May 13. It will be enabled on the German (de), English (en), Italian (it) and Russian (ru) Wikipedias and on all Wikisource wikis on May 22. Feedback is welcome. [313][314]
VisualEditor was added as a beta feature to Wikimedia Commons on May 15. You can enable it in your preferences. [315][316]
You can read a summary of the Wikimedia technical report for April 2014.
VisualEditor news
VisualEditor's buttons and icons can now be accessed using keyboard keys. [317][318]
VisualEditor's new citation tool now matches templates like {{cite_web}} and not just {{Cite web}}. [319][320]
VisualEditor's welcome message will no longer be shown to users who have already seen it. [321][322]
VisualEditor now shows a clearer message when you cancel an edit. [323]
The toolbar of the PageTriage extension will no longer be visible inside VisualEditor. [324][325]
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]
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]
Latest tech news from the Wikimedia technical community. Please inform other users about these changes. Not all changes will affect you. Translations are available.
Recent software changes
The latest version of MediaWiki (1.24wmf6) was added to test wikis and MediaWiki.org on May 22. It will be added to non-Wikipedia wikis on May 27, and all Wikipedias on May 29 (calendar).
MediaViewer will be enabled on all Wikisource wikis on May 29, and on the German (de) and English (en) Wikipedias on June 3. Feedback is welcome.
VisualEditor news
VisualEditor's welcome message and wikitext warning now say that you can switch to source mode editing and keep your edits without saving them. [329][330][331][332]
A bug that caused files not to appear after saving edits in the File: namespace was fixed last week. [333][334]
VisualEditor tabs will no longer appear in namespaces where VisualEditor is disabled. [335][336]
It is now possible to edit inline images with VisualEditor; many minor bugs related to images have also been fixed. [337]
VisualEditor will no longer convert spaces to underscores inside links to pages in namespaces that include spaces in their names. [338]
Future software changes
Wikimedia Labs will stop working for about 10 minutes around 18:00 UTC on May 30 due to a server upgrade. [339]
It will soon no longer be possible to upload different files under the same name at the same time using the UploadWizard tool. [340][341]
Links to TIFF, DjVu or PDF files created with the syntax [[File:Name.ext|thumb|page 15 is my favourite]] will now show an image caption if there is any text after page number; previously they caused the given page to appear. [342][343][344]
You will soon see information about global blocks for IP addresses on their contributions page on your local wiki. [345][346]
Latest tech news from the Wikimedia technical community. Please inform other users about these changes. Not all changes will affect you. Translations are available.
Recent software changes
The latest version of MediaWiki (1.24wmf7) was added to test wikis and MediaWiki.org on May 29. It will be added to non-Wikipedia wikis on June 3, and to all Wikipedias on June 5 (calendar).
CirrusSearch was enabled as the primary search method on all Wikipedias with less than 100,000 pages on May 30. [347]
VisualEditor news
Templates that redirect to other templates now get the TemplateData of their target. [348]
The toolbar of the PageTriage extension will no longer be visible after you save an edit with VisualEditor. [349][350]
VisualEditor now checks if your browser supports SVG files to avoid displaying broken icons. [351]
There is now a new type for TemplateData parameters: date for dates and times in the ISO 8601 format. [352]
Future software changes
MediaViewer will be enabled on the German (de) and English (en) Wikipedias on June 3. Feedback is welcome.
You will soon see a warning if you visit a contributions page for a user that does not exist. [353][354]
The search tab will soon be removed from user preferences. You will be able to set your search preferences on Special:Search. [355][356]
You will soon see a label next to the little triangle arrow for the Actions menu in the Vector skin (screenshot). [357][358]
Problems
For about 20 minutes on May 29, all wikis were broken due to a configuration error. [359]
Latest tech news from the Wikimedia technical community. Please inform other users about these changes. Not all changes will affect you. Translations are available.
Recent software changes
The latest version of MediaWiki (1.24wmf8) was added to test wikis and MediaWiki.org on June 5. It will be added to non-Wikipedia wikis on June 10, and to all Wikipedias on June 12 (calendar).
You can now use guided tours on the Arabic (ar), Bengali (bn) and Norwegian (no) Wikipedias. If you want this tool on your wiki, you need to translate it and ask in Bugzilla. [360][361]
VisualEditor news
You should no longer be able to add empty references with VisualEditor. [362][363]
The "use an existing reference" button in the reference tool is now shown as disabled, rather than hidden, when the reference has content. [364][365][366]
You will now see category contents again after saving an edit to a category page with VisualEditor. [367][368]
You will be able to use information from Wikidata directly in Wikiquote pages starting on June 10. [370]
On wikis with the Translate extension enabled, translation administrators will soon be able to use the page migration tool to import existing translations to the new system. [371][372]
You will soon see metadata on file description pages for Ogg files (example video, example audio). Some metadata with non-English characters may need to be purged or transcoded to UTF-8 before they show correctly. [373][374]
Templates containing <ref> or <references> tags will no longer need dummy parameters to prevent caching. [375][376][377]
You will no longer be able to use Special:Thanks directly. The page will soon show an error message when you visit it. [378][379]
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
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
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:
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;
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.
Latest tech news from the Wikimedia technical community. Please inform other users about these changes. Not all changes will affect you. Translations are available.
Reminder
You can subscribe to the wikitech-ambassadors mailing list to get news more quickly and to send feedback or report problems.
Recent software changes
The latest version of MediaWiki (1.24wmf9) was added to test wikis and MediaWiki.org on June 12. It will be added to non-Wikipedia wikis on June 17, and to all Wikipedias on June 19 (calendar).
You can now read a summary of the Wikimedia technical report for May 2014.
VisualEditor news
You can now easily see the target of a link or other information using the context menu. [381]
When you edit a reference, you can now empty it and click the "use an existing reference" button to switch it to re-use another reference. [382][383]
You can now add and edit {{DISPLAYTITLE}} and __DISAMBIG__ in the page settings menu. [384][385][386][387]
The tool to insert special characters is now wider and simpler; the order of mathematical symbols is now correct. [388][389][390]
You will no longer see image thumbnails on search results pages on Wikibooks and Wikisource wikis. [393][394]
It will soon be possible to globally rename global (SUL) users. [395][396]
Tablet users will be redirected to the mobile view of Wikimedia wikis starting on June 17. [397]
The special page that lists most linked-to templates will soon include pages from all namespaces; it will also be renamed to Special:MostTranscludedPages. [398]
An IRC discussion about Phabricator will take place on June 17 at 17:30 UTC on the channel #wikimedia-office on freenode (time conversion). You can also read a blog post about the upcoming switch to Phabricator.
You can now comment on the draft 2014-15 goals of the Wikimedia Foundation engineering department. [399]
Latest tech news from the Wikimedia technical community. Please inform other users about these changes. Not all changes will affect you. Translations are available.
Recent software changes
The latest version of MediaWiki (1.24wmf10) was added to test wikis and MediaWiki.org on June 19. It will be added to non-Wikipedia wikis on June 24, and to all Wikipedias on June 26 (calendar).
VisualEditor news
You can now drag-and-drop selections of content, not just files and templates. [400][401]
When dragging an item, you will now see a line that helps you to drop it. [402][403]
You can now only move an image to the start of a paragraph, not to the middle of it, so you don't accidentally split it. [404][405]
You will now be warned if you add wikitext to file captions and references. [406][407]
Future software changes
You will no longer be able to upload files on wikis that do not have any copyright tags. [408][409]
CirrusSearch results will soon take into account categories, the first paragraph and the wikitext of a page. You will also be able to use regular expressions to search the wikitext. It will take a few days for the changes to be enabled on all wikis. [411]
An IRC meeting to organize old high priority MediaWiki bug reports will take place on June 24 at 17:00 UTC on the channel #wikimedia-office on freenode (time conversion). [414]
Problems
On June 19, all wikis were broken for about 15 minutes due to a high server load.
Between June 13 and June 15 there were problems with the scaling of video files due to a configuration error. [415]
Latest tech news from the Wikimedia technical community. Please inform other users about these changes. Not all changes will affect you. Translations are available.
Recent software changes
The latest version of MediaWiki (1.24wmf11) was added to test wikis and MediaWiki.org on June 26. It will be added to non-Wikipedia wikis on July 1, and to all Wikipedias on July 3 (calendar).
VisualEditor news
Context menus in VisualEditor will no longer flicker and disappear when you insert a new reference, formula, image, etc. [416][417]
A bug that prevented relocating items due to cache was fixed last week. [418][419]
VisualEditor will no longer scroll to the bottom of the page when you try to edit section 0. When you try to add a formula, VisualEditor will no longer scroll to the top of the page. [420][421][422][423]
Links to category pages or file pages added with VisualEditor will now work correctly. [424][425]
Future software changes
You will no longer be able to upload files on wikis that do not have any copyright tags. [426][427]
Toolserver tools will be stopped on June 30. Please make sure to change gadgets that link to the Toolserver to point to Tool Labs instead.
CirrusSearch will be enabled on June 30 as the primary search method on 34 new wikis, including the Czech (cs), Danish (da), Finnish (fi) and Hebrew (he) Wikipedias. [428]
All Wikimedia wikis will be using a security method called perfect forward secrecy starting on July 1. If you see a problem, please report it. [429][430]
Starting on July 1, it will be possible to globally rename global (SUL) users. [431]
You will soon see block information when you visit the contributions page or try to edit the user page or user talk page of a user who is affected by an IP range block. [432][433]
You will soon be able to use {{!}} as a magic word to produce the pipe character, for instance for use in tables. [434]
Latest tech news from the Wikimedia technical community. Please inform other users about these changes. Not all changes will affect you. Translations are available.
Tech News updates
We are looking for contributors to help write a new issue every week. If you would like to help, please contact us.
Recent software changes
The latest version of MediaWiki (1.24wmf12) was added to test wikis and MediaWiki.org on July 3. It will be added to non-Wikipedia wikis on July 8, and to all Wikipedias on July 10 (calendar).
CirrusSearch was enabled on July 1 as the primary search method on 36 new wikis, including the Norwegian (no), Portuguese (pt) and Ukrainian (uk) Wikipedias. [435]
It is now possible to create Atom or RSS feeds for Word of the Day, Word of the Week and similar entries on Wiktionary wikis. [436][437]
Saving an edit with VisualEditor will now be much faster. [440][441]
You can now add a caption when you add a file to a page with VisualEditor. You can also change the file to a different one and keep the existing caption. [442][443][444]
When you switch to the Edit source tab, you are now asked to keep your changes. You no longer need to find the option in the menus. [445][446][447]
The reference tool that adds empty <ref></ref> tags is now at the bottom of the Cite menu, below references that use templates like {{Cite web}}. [448]
Context menus will no longer be shown over items that you can edit directly, for example formulæ. [449][450][451]
Future software changes
Starting on July 9, it will be possible to globally rename global (SUL) users. The feature was first scheduled for July 1, but was delayed due to bugs.
A plan to enable CirrusSearch as the primary search method on the 11 largest Wikimedia wikis has now been prepared. [452]
If you use references on a page, you will soon always see them at the bottom of the page, even if you forget to add the <references /> tag (or a template). [453][454]
Black-and-white XCF images will soon display correctly. [455][456]
Description pages of SVG files will soon always show download links for multiple resolutions (example). The links were previously shown only for SVG files in large original resolutions. [457][458]
Problems
Between July 2-3, there were problems with loading pages on multiple wikis due to a configuration issue. [459][460]
For a few hours on July 1, there were problems with uploading new files on Wikimedia Commons due to a configuration error. [461][462]
@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.
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
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:
Importazione di fr:User:Alex brollo bis/GetIndexData.js
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
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]
Latest tech news from the Wikimedia technical community. Please inform other users about these changes. Not all changes will affect you. Translations are available.
Recent software changes
The latest version of MediaWiki (1.24wmf13) was added to test wikis and MediaWiki.org on July 10. It will be added to non-Wikipedia wikis on July 15, and to all Wikipedias on July 17 (calendar).
The tool to add templates and citations will now work for templates that include HTML comments or templates in their titles. [465][466]
The button to make images full size should now work correctly. [467][468][469]
References will now be shown in the default font size again. [470]
Future software changes
CirrusSearch will be enabled as the primary search method on the Dutch (nl) and Japanese (ja) Wikipedias on July 14, and on the Polish (pl) and Russian (ru) Wikipedias on July 16. [471]
The Special:Version page will soon show the exact version of MediaWiki and all extensions installed on your wiki (example). [472][473]
It will soon no longer be possible to order printed books of wiki articles via PediaPress. You will still be able to create PDF files. [474]
Pages that use {{DISPLAYTITLE:''title''}} more than once will soon show a warning. You can use {{DISPLAYTITLE:''title''|noerror}} to hide it. [475][476]
@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:
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]
Latest tech news from the Wikimedia technical community. Please inform other users about these changes. Not all changes will affect you. Translations are available.
Recent software changes
The latest version of MediaWiki (1.24wmf14) was added to test wikis and MediaWiki.org on July 17. It will be added to non-Wikipedia wikis on July 22, and to all Wikipedias on July 24 (calendar).
CirrusSearch was removed as the primary search method from Wikimedia Commons and the Spanish (es) Wikipedia due to a high server load. The plan to enable it on the Dutch (nl), Japanese (ja), Polish (pl) and Russian (ru) Wikipedias was also postponed to a later date. [482][483][484]
The tool that stores information about languages (CLDR) was updated to its latest version. You can still help translate language names into your own language so they can be used in the sidebar and other places. [485]
Tablet users visiting the mobile version of Wikimedia wikis will be able to use a special version of VisualEditor starting on July 31. You can test the new tool by choosing the beta version of the mobile view in the Settings menu. Feedback is welcome. [489]
All windows in VisualEditor have now a new design. Main action buttons will always be located in the top bar and will use simple words rather than icons. [490]
You can now easily open links inside the link editor, for example to see their target. [491]
Several bugs related to the positioning of the cursor around some items (like images and references) were fixed last week. [492][493][494][495][496][497]
Future software changes
It will soon be possible to watch individual discussions in the Topic namespace rather than whole pages for talk pages using Flow. [498]
You can give comments about the new version of Winter, a proposal to have a fixed toolbar at the top of wiki pages. [499]
An IRC meeting to organize Pywikibot bugs will take place from July 24 to July 27 on the channel #pywikibot on freenode. [500]
Latest tech news from the Wikimedia technical community. Please inform other users about these changes. Not all changes will affect you. Translations are available.
Recent software changes
The latest version of MediaWiki (1.24wmf15) was added to test wikis and MediaWiki.org on July 24. It will be added to non-Wikipedia wikis on July 29, and to all Wikipedias on July 31 (calendar).
You can now download the latest version of the anti-vandalism tool Huggle.
The cancel button in VisualEditor toolbar has been removed. You can still use the Read tab and the Back button in your browser to cancel your edit. [504]
If you try to use a template which has no suggested or required parameters in TemplateData, you will now be asked to add the parameters. [505][506]
You will no longer be able to edit a page if you can't create it, for example on pages protected against recreation. [507][508]
Wikidata will soon be able to store data about article status, for example "good article" or "featured article". If your wiki has highlighted content, please make sure it is on Wikidata's list. [511]
It will soon be possible to directly create empty pages, for example in the user namespace. [512][513]
Latest tech news from the Wikimedia technical community. Please inform other users about these changes. Not all changes will affect you. Translations are available.
Tech News updates
Tech News will be presented at the Wikimania 2014 conference in London! If you will be attending the conference, please join us in Auditorium 2 at 14:30 local time on Sunday, August 10.
Recent software changes
The latest version of MediaWiki (1.24wmf16) was added to test wikis and MediaWiki.org on July 31. Due to the Wikimania 2014 conference, it will be added to non-Wikipedia wikis on August 12, and to all Wikipedias on August 14 (calendar). [514]
You can now test a new tool to render wiki pages as PDF files. [515][516][517]
You can now download an update to the archive of Wikimedia Commons files (uploaded up to December 31, 2013). If you have free space on your computer, please help preserve the files. [518]
New users using the mobile Commons site now need to make 75 edits before they can upload a file. [519][520]
VisualEditor news
You will no longer see an edit confirmation message after making a null edit with VisualEditor. [521][522]
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....
.... 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....
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]
Latest tech news from the Wikimedia technical community. Please inform other users about these changes. Not all changes will affect you. Translations are available.
Cambiamenti recenti al software
Due to the Wikimania 2014 conference, there were no MediaWiki changes this week. The latest version of MediaWiki (1.24wmf16) will be added to non-Wikipedia wikis on August 12, and to all Wikipedias on August 14 (calendar). [538]
Bureaucrats on all Wikivoyage wikis are no longer able to merge two accounts into one. [539]
VisualEditor news
Tablet users visiting the mobile version of non-Wikipedia wikis will be able to use VisualEditor starting on August 12. The feature will also be enabled on all Wikipedias on August 14. [540]
Cambiamenti futuri al software
Internet Explorer 6 users will soon see a JavaScript-free version of Wikimedia wikis; JavaScript tools and scripts will no longer work on that browser. If you use Internet Explorer 6, make sure to update to a newer browser! [541][542][543]
If you visit a special page that requires you to be logged-in, you will soon be automatically redirected to the log-in page instead of seeing a warning. [544][545]
You will now always see recent changes to the source language text when editing a translation with the Translate extension. [546][547]
An IRC meeting to discuss VisualEditor will take place on August 14 at 09:00 UTC on the channel #wikimedia-office on freenode (time conversion). [548]
Latest tech news from the Wikimedia technical community. Please inform other users about these changes. Not all changes will affect you. Translations are available.
Recent software changes
The latest version of MediaWiki (1.24wmf17) is on test wikis and MediaWiki.org since August 14. It will be on non-Wikipedia wikis on August 19, and on all Wikipedias on August 21 (calendar).
There is a new protection level called superprotection. At the moment, only some Wikimedia Foundation employees have access to it. Administrators can't edit "superprotected" pages. [549][550][551]
You can now create empty pages directly. A message asks you to confirm that you want to create an empty page. [552][553]
You can watch the first videos from Wikimania 2014. Some of them are about technical topics. More videos will come later.
Wikidata
After August 19, you can use Wikidata for inter language links on Wikinews. [555]
After August 19, you can use Wikidata for badges like "good" or "featured" articles. Next week, you will be able to show the badges in the article sidebar on Wikipedia, Wikisource and Wikiquote. [556]
Problems
There was an issue with ProofreadPage and WikiEditor on Wikisource wikis. It is now fixed. [557][558]
Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.
VisualEditor news
There was a error when you put your cursor directly after a reference list. It is now fixed. [559]
You can now add colors to links in the editor using gadgets. You can do this to see links to redirects or disambiguation pages. [560]
If you use Internet Explorer, you will soon be able to use VisualEditor. [561][562][563]
Future software changes
The latest version of MediaWiki (1.24wmf18) is on test wikis and MediaWiki.org since August 21. It will be on non-Wikipedia wikis on August 26, and on all Wikipedias on August 28 (calendar).
After August 26, you will have a central JavaScript and CSS page. They will be on Meta-Wiki and will work on all wikis. Read more on the help page. [564]
Latest tech news from the Wikimedia technical community. Please inform other users about these changes. Not all changes will affect you. Translations are available.
Cambiamenti recenti al software
You can now test a new Beta Feature to see links to other wikis in the sidebar. The links come from Wikidata. [565][566]
You can now search pages that link to a page. Use the linksto: keyword in your search. [567][568]
A redirect to a section now changes the URL in the address bar of your browser. If "Dog" redirects to "Animals#Dog", you now see "Animals#Dog" instead of "Dog#Dog". [569][570]
If you are testing Flow, you now have a Flow tab in your Notifications. It is called "Messages". [571]
Notizie su VisualEditor
Non è più possibile cancellare campi obbligatori nei template. [572]
Abbiamo risolto numerosi bug relativi a Internet Explorer. Se usi Internet Explorer 11, potrai usare VisualEditor settimana prossima. Il supporto per le versioni precedenti arriverà in seguito. [573][574][575]
VisualEditor ora ha un aspetto migliore in Monobook. [576]
Abbiamo fixato un bug per cui parte di quanto digitato poteva essere annullata quando si usava il comando "taglia" (Ctrl+X). [577]
Non vedrai più categorie vuote o cancellate tra i suggerimenti quando se ne aggiunge una. [578]
Cambiamenti futuri al software
The latest version of MediaWiki (1.24wmf19) is on test wikis and MediaWiki.org since August 28. It will be on non-Wikipedia wikis on September 2, and on all Wikipedias on September 4 (calendar).
There is a proposal to build a database on Commons for file data. It will make it easier to see the author, license and topics. You can give feedback on this idea. You can also come to the IRC chat on September 3 at 18:00 (UTC) in #wikimedia-office at freenode. [579]
You can give feedback on Media Viewer until September 7. You can say what needs to be improved and ask other people to give feedback too. [580]
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()
@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.
@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]
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
@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]
Sto cautamente rivedendo i miei script sulla base di queste convenzioni:
ficcare tutte le variabili dentro un oggetto mw.p
ficcare tutte le funzioni dentro un oggetto mw.m
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....
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]
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]
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.
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
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:
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:
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:
memorizzare il carattere precedente il cursore e una sua copia normalizzata (ossia, carattere base senza diacritico);
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]
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]
@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]
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]
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
@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
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.
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
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. Samuele15: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]
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?
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?
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]
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"
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)
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. Samuele20:00, 24 ott 2014 (CEST)[rispondi]
Cambiamento ID namespace Page e Index
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 ;) Samuele20: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]
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]
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
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 .
Perchè {{Gap}} è fortemente sconsigliato? Quali sono i "casi particolari" in cui usarlo? Ho provato a modificarne il motore da così:
Progetto: tool per estrarre bene il text layer dei djvu
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.
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:
il riconoscimento delle aree poem;
il riconoscimento dei testi centrati;
il riconoscimento degli spazi bianchi fra le linee;
il riconoscimento delle dimensioni dei font;
il rinonoscimento delle aree di testo header e footer;
Mettetevi su una pagina qualsiasi, vuota o piena, nuova o vecchia che sia (non salvate però...)
Aprite la console js e provate:
do_ocr() : viene lanciato il vecchio OCR tesseract; il testo della pagina viene rullato.
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.
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
@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
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:
sarebbe un utile contenitore per "oggetti" json specifici per il libro (es. correzioni ricorrenti, formato delle virgolette...)
permetterebbe di allineare mirabilmente i "thumbs" con le pagine, perchè l'elemento 0 sarebbe appunto quella pagina, l'elemento 1 la pagina 1, ecc.
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
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?
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.
Help: selezionare un'area rettangolare in un'immagine
@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]
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
@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]
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
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
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()
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
@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:
all’apertura di una pagina Pagina o di una pagina ns0 determinano se la pagina è connessa a una pagina Indice, e a quale;
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;
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
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]
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]
Canvas
Un annetto fa ho rovistato nei misteri del canvas, trovate in Utente:Alex brollo/CanvasLab un'interfaccina per trasformare un'immagine (non più larga di 600 px) in un canvas; per farla funzionare dovete caricarvi Utente:Alex brollo/CanvasLab.js. E dopo? Dopo, per ora, è affar vostro :-) ; l'idea sarebbe di montare la cosa su Ritaglio permettendo quindi di estrarre un vero ritaglio della pagina con lo stesso meccanismo di selezione grafica, eventualmente di modificarlo con qualche filtro, e poi di salvarlo e/o caricarlo come File locale e/o come File su Commons. Ma per ora è solo un'idea. --Alex brollo (disc.) 23:59, 4 gen 2015 (CET)[rispondi]
@Barbaforcuta Partito il tentativo di inserire un tag canvas in Ritaglio. Tenuto conto della complessità di Ritaglio, non opero sullo script ma su un suo clone: MediaWiki:Gadget-cornersAlpha.js. Chi vuole seguire i lavori dal vivo, o (magari!) collaborare nel dissodamento del problema, basta che disabiliti Ritaglio e si colleghi al clone aggiungendo nel suo common.js importscript("MediaWiki:Gadget-cornersAlpha.js"); . --Alex brollo (disc.) 07:36, 6 gen 2015 (CET)[rispondi]
Fine corsa.... sono incappato nell'errore "The canvas has been tainted by cross-origin data", non ci posso fare quasi niente se non salvarlo come immagine png nel pc; troppo poco rispetto a quello che speravo. Va be' ci ho provato. --Alex brollo (disc.) 23:57, 6 gen 2015 (CET)[rispondi]
Refactoring del progetto Canvas
Vediamo se fra i rottami del progetto resta qualcosa.
nonostante non sia minimamente elaborabile come canvas (aimè), l'immagine "croppata" può essere salvata sul PC come file PNG; è anche pensabile che si costruisca un nome automatico e si precompili un template Information adatto a un'immagine derivata. Resterebbe a carico dell'utente il "fastidio" di verificare, ed eventualmente ritoccare, l'immagine scaricata e di caricarla su Commons.
serve anche a verificare che le coordinate per il ritaglio siano corrette, e con un click e una banale chiamata GET a un tool python su Labs potrebbe passargli tutto ciò che serve per estrarre la pagina dal file djvu come TIFF, alla massima risoluzione possibile, convertirla pin png o in jpg, ritagliarla e caricarla su Commons completa di nome automatico e di template Information compilato, sempre che il bot associato al tool abbia un account su Commons (cosa che al momento il mio bot, aimè, non ha). Se qualcuno con un bot globale su Labs ritiene la cosa fattibile e interessante, io posso passare qualche suggerimento sulle chiamate djvuLibre. --Alex brollo (disc.) 15:11, 7 gen 2015 (CET)[rispondi]
Contrordine
Una risposta su Wikitech-l risolve il problema CORS e fa ripartire l'idea canvas (a questo punto l'immagine non è più "sporca" e può essere modificata e salvata); grazie Ricordisamoa. Ma mi prendo una pausa dagli "smanettamenti" e ritorno a lavorare smettendo di impersonare "braccia rubate all'agricoltura" ;-) --Alex brollo (disc.) 22:23, 8 gen 2015 (CET)[rispondi]
Vorrei capire in cosa differisce la memorizzazione e recupero di un oggetto dentro mw con config, get, set, piuttosto che l'assegnazione diretta. Da un po' faccio grandi sforzi per "ripulire" dalle variabili globali, ma l'argomento è veramente ostico.... e alle volte questa "corsa in avanti" nella potenza, complessità e rigore del software sembra quasi fatta apposta per scoraggiare chi programma come può.
@Ricordisamoa Giusto per iniziare il chiarimento: io non tocco mai in modifica le variabili wg*, ma le leggo spesso; ed in effetti le leggo come globali, invece di leggerle con mw.config.get(wg*). Posso sostituire direttamente le chiamate dirette con le chiamate mw.config.get(wg*), o conviene caricare i valori in variabili locali e poi usarle? Oppure devo farlo solo se uso la variabile ripetutamente dentro un determinato scope? E in questo caso, "ripetutamente" a che numero di ripetizioni corrisponde? E la mia nuova policy di non creare variabili e funzioni globali, ma se mi servono cose globali, di definirle come elementi dell'oggetto globale mw come ho provato a fare in Ritaglio, è accettabile? --Alex brollo (disc.) 07:49, 6 gen 2015 (CET)[rispondi]
@Alex brollo io uso mw.config.get() a meno che una stessa variabile non sia richiamata molte volte (vedi la regola del 3, per esempio). È anche da considerare che il valore, una volta assegnato ad una variabile locale, non può essere sovrascritto con mw.config.set(). --Ricordisamoa12:47, 6 gen 2015 (CET)[rispondi]
Sto caricando e parsando come posso ciò che wikidata restituisce con una chiamata action=wbgetentities, filtrando e semplificando. Una prima funzione che acchiappa l'output relativo alla pagina corrente lo trovate in User:Alex brollo/Ajax; si starebbe un attimo a lanciare la funzione di default nelle pagine collegate a un elemento wikidata e sia in una variabile di memoria, che in localStorage, sarebbe caricato l'oggetto risultante. Così com'è, tale oggetto è praticamente inutilizzabile; la fatica prossima ventura è di renderlo utilizzabile emulando, fin dove possibile, #property.
La necessità di disporre di questi dati nasce dall'esigenza di accedere a tali dati in edit, cosa che non è possibile con Lua, che si scatena solo in view/submit. Corriggetemi se sbaglio o se mi accingo alla solita fatica di rediscovering the wheel. --Alex brollo (disc.) 10:29, 14 gen 2015 (CET)[rispondi]
Intanto ho capito che le properties sono entities e che quindi le becco con wbgetentities. Poi mi pare di aver capito che due letture API bastano: nella prima, si acchiappa l'item e tutte le sue proprietà; nella seconda, si impacchettano in una lista tutte le entities contenute nell'item e di ciascuna si ottiene la descrizione in italiano. Ci provo :-) --Alex brollo (disc.) 20:05, 14 gen 2015 (CET)[rispondi]
Sembra funziare, il parsing dell'item per beccare tutte le entità annidate (P e Q) funzia, manca solo l'implementazione della chiamata di traduzione item->label in italiano; dopodichè dovrebbe essere possibile convertire l'intero oggetto inutilizzabile in un oggetto utilizzabile, salvando, per ora, una variante semplificata (nome della proprietà->valore della proprietà). --Alex brollo (disc.) 11:46, 15 gen 2015 (CET)[rispondi]
Nota banale su Lua
Il template {{Cs}} costituisce anche una prova della (nota) capacità di Lua di eseguire il parsing di una stringa con possibilità di regex perfino superiori a quelle "canoniche" (in particolare, capaci di risolvere strutture annidate tipo "template dentro template" o "tag html dentro tag html"); sono talmente abituato a pensare in termini di sintassi template (in cui le funzioni di manipolazione delle stringhe sono state deliberatamente impedite) che non è facile capire quanto la fine di questa limitazione apre nuove possibilità.
Un template che secondo me andrebbe luizzato subito, usando queste tecniche, è Centrato, costruendo un super-parametro di formattazione che inserisca, nel modo più semplice e intuitivo possibile, nel template tutta la potenza di {{Type}}. In un colpo solo si potrebbe formattare perfettamente gran parte delle terribili righe dei frontespizi, in cui gli utenti più attenti alla formattazione desiderano controllare tutto (grandezza caratteri, spazi fra le linee, spazi fra caratteri....); tutto potrebbe essere passato in un solo parametro intuitivo, tipo: grandezza:2em, interlinea:3em, spaziatura:10px, maiuscoletto, italico ma anche g2em i3em s10px sc it per chi vuol far prima. Alex brollo (disc.) 10:40, 15 gen 2015 (CET)[rispondi]
Ripulitura delle chiamate dirette alle variabili wg*
Ho cominciato la ripulitura delle chiamate diretta alle variabili wg* (wgPageName, wgAction...) ma non so come fare a scovarle tutte; perlomeno non so come fare operando da Chrome. In Firebug, che uso poco, avrei strumenti più efficienti?
Per quelli che non conoscono il problema: la chiamata diretta di variabili wg* è deprecata, e va sostituita con la chiamata "canonica" mediante mw.config.get("wg*"), come recentemente ci ha ricordato @Ricordisamoa. Le console sono ingombre di deprecazioni, o meglio, di imprecazioni virtuali. --Alex brollo (disc.) 16:34, 15 gen 2015 (CET)[rispondi]
@Alex brollo aggiornato di nuovo. Tieni presente che (per motivi di performance) copre solo il namespace MediaWiki, quindi è probabile che il wgTitle sia in uno script utente... Puoi però aggiungere il parametro "debug=1" alla querystring, il ResourceLoader non comprimerà il codice e i messaggi della console risulteranno più utili. --Ricordisamoa04:04, 18 gen 2015 (CET)[rispondi]
@Ricordisamoa Infatti! Beccato e soppresso, adesso la console tace :-)
Spero che la prossima volta non mi chiedano "sistema le nuove variabili fuori del namespace globale".... Quella sì che sarebbe durissima :-( --Alex brollo (disc.) 08:43, 18 gen 2015 (CET)[rispondi]
@Ricordisamoa itsource è un tool dormiente, sostituito da altri bot attivi e operosi. Ho perso la mano con python, aimè, e sono ben contento che altri se ne occupino. Approfitto per chiederti lumi e aiuto per l'istallazione su Toollabs di unpaper o di uno script simile. Il progetto opallibriantichi potrebbe essere riattivato. --Alex brollo (disc.) 08:54, 17 gen 2015 (CET)[rispondi]
API Internet Archive
Non so se serve a qualcuno (vedo qualche intervento di un annetto fa) ma io adesso sto lavorando con Python sulle API di IA, tendenzialmente per prendere alcuni metadati dei libri. Se a qualcuno serve qualcosa, lo dica :-) --Aubrey (disc.) 10:20, 17 gen 2015 (CET)[rispondi]
@Ricordisamoa, Candalua Nel progettuncolo canvas il passo finale è quello di eseguire l'upload del file jpg, che sta nella memoria del browser prodotto da .toDataURL, su Commons. Vista la pagina //www.mediawiki.org/wiki/API:Upload mi pare che i comandi API da utilizzare siano quelli previsti nel Chunked uploading. Sono sulla strada giusta? Se sì, proverò prima a caricare immagini su wikisource, dove posso far pulizia personalmente se qualcosa va storto, e solo dopo proverò su Commons.
Per inciso: avevo equivocato qualcosa nella mia richiesta di un flag bot su Commons, un commento finale positivo alla richiesta mi aveva dato l'impressione di aver ricevuto il flag... non l'ho ricevuto, quindi non posso usare il bot python per i caricamenti nemmeno se sapessi come fare. Caricare via javascript è un'altra cosa, perchè la richiesta via javascript è una richiesta normale che viene inviata da un utente normale. --Alex brollo (disc.) 08:18, 20 gen 2015 (CET)[rispondi]
MediaWiki:Common.css
Sto facendo caso ai warning e agli info dei file css e js, e li sto eliminando tutti nella "mia roba"... in MediaWiki:Common.css che maneggio con cautela ci sono qualcosa come alcune decine di warnings e di info. Se qualcuno di quelli bravi vuole fare pulizia.... ;-) --Alex brollo (disc.) 11:32, 21 gen 2015 (CET)[rispondi]
Ho visto che all'inizio del common.js è stato aggiunto il codice $("#mw-content-text > p > br").remove();. Da quel che capisco rimuove i doppi caporiga. Volevo chiedere / suggerire di spostarlo nel common.css (per una questione generale di fruibilità a favore di tutti gli utenti, anche quelli che non hanno javascript attivato), ma soprattutto di limitarlo solo nei namespace dove effettivamente serve (es. principale, pagina, indice, ???, ecc.) senza influire sugli altri namespace (es. utente). Ho testato il seguente codice che dovrebbe funzionare:
/* Elimina i "caporiga" multipli, solo per i namespace principale (0), pagina (108) e indice (110) */
.ns-0 #mw-content-text > p > br,
.ns-108 #mw-content-text > p > br,
.ns-110 #mw-content-text > p > br {
display: none;
}
In attesa che Barbaforcura risponda, suggerirei di discutere la questione dei br: io cercherei di evitarli SEMPRE o almeno quasi sempre tranne che in casi assolutamente particolari (alcune note molto complesse, alcune annotazioni a lato, o cose del genere). Concordo comunque con l'idea che javascript NON dovrebbe modificare l'aspetto del testo vero e proprio: le modifiche ottenute sono illusorie, e non esportabili. --Alex brollo (disc.) 10:08, 23 gen 2015 (CET)[rispondi]
Quella modifica era una toppa momentanea per la Pagina Principale e il Portale Comunità, perché non ho capito quel br da dove spuntasse fuori. Annullatela pure se dà problemi; vedremo poi in che altro modo risolvere quell'imperfezione grafica.--Barbaforcuta (disc.) 19:10, 23 gen 2015 (CET)[rispondi]
Sapete che sto sperimentando vari tools per l'editing di pagine via Javascript, usando API. Man mano che procedo osservo che non ci sono limiti alle possibilità di questo tipo di edit, che rientrano fra quelli "normali" dell'utente. Non esistono nemmeno - mi pare - sistemi di controllo del numero di edit, in teoria (e anche in pratica, da test preliminari fatti cautamente) si possono lanciare "raffiche" di edit consecutivi a grande velocità.
Mi domando: ci sono problemi seri di sicurezza? Non trovo doc che metta in guardia dall'abuso di queste tecniche; il sistema è protetto solo dalla strategia "security by obscurity"? --Alex brollo (disc.) 12:11, 27 gen 2015 (CET)[rispondi]
Che io sappia, non esistono limiti all'edit throttle (ci sarebbe $wgRateLimits, ma non mi risulta che sia in uso in Wikimedia). Una volta, trovandomi senza PC con Python, ho improvvisato per Horcrux92 un "bot" in JavaScript che ha ha raggiunto 315 modifiche al minuto (284 senza contare quelle cancellate). Come di ogni strumento potente, anche delle API si può abusare — perfino all'insaputa della vittima, in certi casi — pertanto è sconsigliabile eseguire codice da fonti non verificate. --Ricordisamoa16:10, 28 gen 2015 (CET)[rispondi]
Un problema: tecniche di allineamento
Il problema è il seguente. Dato questo testo:
52
Poiche pur veggio tormi
Da un’acerba partita
Il mio ben, la mia vita;
Ma che parl’io di ritrovar accenti
Conformi à miei tormenti?
Ahi, che sì grave io sento il mio duol farsi,
Che tempo è di morir, non di lagnarsi.
MAD. XXII.
O Ciel deh per pietà dammi tanti occhi
Quante hai tù chiare stelle
Si che l’aspro dolor, che ’l cor mi svelle
Per la dura partita
In pianto almen trabocchi.
Ma dove (ohime) poich’io son tutta ardore
Havrò in mio scampo lagrimoso humore?
O dolente mia vita
Com’ogni nostro ben ratto se n’ fugge.
Non m’ancide il dolor, e non mi strugge
L’incendio, e non mi porge il pianto aìta.
MAD. XXIII.
NOn è gran Mago Amore,
Se da un bel volto candido, e vermiglio
Tragge di morte un languido pallore?
Se da ridente ciglio
Move talhor per gioco
Pena, ch’ancide un core?
Se da la neve il foco,
Se da tranquillo mar fiere procelle
Desta, e la pioggia da serene Stelle?
All-
e dato questo secondo testo:
Poiché pur veggio tormi . -
Da vn'acerba partita
Il mio ben , la mia vita ;
Ma che parl'io di ricrouar accenti
Conformi a miei tormenti ?
Ahi,che sì graue io lento il mio duol farti,
Che tempo è di morir, non di lagnarti .
M A D. XXII.
OCiel deh per pietà dammi tanti occhi
Quante hai tu chiare ftelle
Si che l'afprp dolor, che'l cor mi fuelle
Per la dura partita q
In pianto almcn trabocchi.
Ma doue ( ohimè) poich'io fon tutta ardore
Haurò in mio (campo lagrimofo humore >
O dolente mia vita
Com'ogni noftro ben ratto fé n'fugge .
Non m'ancide il dolor, e non mi ftrugge
L'incendio,e non mi porge il pianto aita.
M A D. XXIII.
NOn è gran Mago Amore,
Se da vn bel uolto candido,e vermiglio
Tragge di morte vn languido pallore J
Se da ridente ciglio
Mone talhor per gioco
Pena , ch'ancide vn core ?
Se da la neue il foco ,
Se da tranquillo mar fiere procelle
Defta,e la pioggia da ferenc Stelle ?
i ; Air*
come si chiama la procedura per confrontare i due testi, e far corripondere ogni parola del testo 1 alla corrispondente parola del testo 2? Che software fanno questa operazione? Alex brollo (disc.) 17:08, 17 feb 2015 (CET)[rispondi]
No... la diff è tutt'altro. Qui si tratta di trovare il miglior appaiamento possibile 1:1 ignorando le differenze. Fatto questo appaiamento, diventa possibile sostituire, nello strato testo di un file djvu, il risultato dell'OCR con la correzione umana dell'OCR. Sono anni che ci penso, ma non so da dove cominciare. Ci sono alcune centinaia di migliaia di pagine wikisourciane che attendono questa procedura :-( --Alex brollo (disc.) 18:26, 17 feb 2015 (CET)[rispondi]
Quasi.... Vediamo se riesco a esprimere il problema.
"Date due sequenze A, B simili identificare per ogni elemento di B il corrispondente elemento di A, tenendo conto della possibilità che un elemento A potrebbe corrispondere a un gruppo contiguo di elementi B o o l'inverso"
Dunque. Tu vuoi suddividere la stringa A nelle singole parole che la compongono, e poi associare a ciascuna di esse il corrispondente frammento nella stringa B. Io proverei a (s)ragionare così:
siccome le singole parole possono ricorrere più volte, se proviamo ad allineare parola con parola è facile cadere in falsi match. Io cercherei di allineare prima le stringhe intere.
Prendi le stringhe A e B, e cerchi la più lunga sottosequenza comune (LCS) tra le due stringhe.
Quando l'hai trovata, spezzi le stringhe in 3 parti: l'inizio, la parte comune, la fine.
Poi ripeti ricorsivamente la ricerca della LCS per l'inizio e la fine, spezzando ogni frammento in 3 parti come prima.
Quando non trovi più delle LCS di lunghezza accettabile (es 3-4 caratteri), ti fermi.
A questo punto hai due serie di frammenti, appaiati 1-1: solo che alcuni sono uguali tra A e B, altri sono diversi. Ogni frammento può essere un pezzo di parola o contenere più parole.
A questo punto però a te servono le parole. Scorri l'elenco dei frammenti A: se dentro un frammento ci sono degli spazi, lo spezzi in n parole. Poi devi spezzare anche il corrispondente frammento B...
Se i frammenti A e B erano uguali tra loro, la cosa è banale perché anche gli spazi coincideranno tra A e B;
se erano diversi, devi cercare il punto esatto in cui spezzare B: ad esempio scorri le n parole del frammento A e se trovi la parola uguale in B sai dove spezzare; altrimenti devi probabilmente cercare uno spazio o un segno di punteggiatura "vicino", oppure spezzare all'incirca alla distanza che corrispondenza alla lunghezza della parola A che cerchi.
Quando arrivi alla fine di ogni frammento, devi vedere se c'è uno spazio alla fine di esso o all'inizio del frammento successivo: se sì, l'ultima parola del frammento appena processato va ricongiunta al frammento successivo
Alla fine in teoria dovresti avere le due sequenze di parole allineate 1-1 tra loro.
Intanto, grazie di averci riflettuto. Hai al volo l'indirizzo di uno script js per LCS? Tuttavia, vedo un elemento critico proprio nel passo 1 - il LCS. In certi OCR il riconoscimento è così basso, che la lunghezza del LCS (immagino, spesso minore di 10 caratteri!) potrebbe essere irrilevante e sostanzialmente casuale. Se si sbaglia il primo appaiamento, poi succede il disastro. Penso che la strada da battere invece sia quello di analizzare i separatori - gli spazi bianchi non sono riconosciuti sistematicamente, ma certamente sono il "carattere" riconosciuto meglio. Quindi vorrei ideare un algoritmo che confronti il "ritmo" del flusso dei caratteri - tenendo conto soprattutto della sequenza della lunghezza delle "parole" a prescindere dall'uguaglianza dei caratteri che le compongono.
Defta,e la pioggia da ferenc Stelle ? -> 7,2,7,2,6,6,1
Desta, e la pioggia da serene Stelle? -> 6,1,2,7,2,6,7
Qui c'è un match su 2,7,2,6 bellino, perchè prescinde totalmente dai caratteri, su cui si può usare il confronto dei caratteri come elemento di verifica del tutto indipendente. Alex brollo (disc.) 16:07, 19 feb 2015 (CET)[rispondi]
Grazie! Lo guarderò, anche se - per esperienza - gli algoritmi su questi argomenti scritti da "quelli bravi" sono così astratti che non riesco a capirli; per dire, per calcolare un "algoritmo di similitudine fra stringhe" ho costruito simil() da zero :-( --Alex brollo (disc.) 16:28, 19 feb 2015 (CET)[rispondi]
Vero, gli errori di ocr potrebbero essere molto "vicini" tra loro e quindi la LCS potrebbe non matchare bene. Quello che ci vorrebbe sarebbe una "longest almost common subsequence" (me la sono appena inventata). Potrebbe funzionare come LCS, con la differenza che invece di confrontare le stringhe per uguaglianza, dovrebbe calcolare l'edit distance tra le stringhe e dividere quel numero per la lunghezza della stringa A, ottenendo un "coefficiente di somiglianza" (es. le differenze sono 3, la lunghezza della stringa è 30, il coefficiente è 0.1). Quando il coefficiente è sotto una certa soglia (che so, ad esempio 0.2 cioè 1 differenza ogni 5 caratteri), si considerano le due stringhe come "quasi uguali". Il resto dell'algoritmo di LCS potrebbe restare invariato. Non ho calcolato la complessità computazionale di tutto questo, potrebbe essere spaventosa :D Poi magari non serve trovare proprio la LACS più lunga, anche perché è probabile che le differenze siano piuttosto ben distribuite nel testo; magari basta dividere il testo A in frammenti abbastanza lunghi da essere "unici" e poi cercare l'allineamento migliore. Si potrebbe tentare così:
spezzi a metà il testo A
ipotizzando di spezzare esattamente a metà il testo B, calcoli le distanze tra A1 e B1 e tra A2 e B2
poi provi a spostare il punto di "smezzamento" in entrambe le direzioni fino ad una certa distanza, calcolando ogni volta le distanze tra le coppie di frammenti fino a trovare la migliore combinazione
quando l'hai trovata ripeti lo smezzamento sui frammenti così ottenuti
Anni fa avevo inventato una strana cosa capace di trovare un paragrafo A in un testo B (B grandino: usavo l'intero dump di wikisource...) basandosi sulla pura somiglianza ed era spaventosamente veloce.... misurava la densità di match di piccole sottostringhe casuali di A nel testo B, interrompendosi subito quando emergeva un pattern significativo. Ma qui la cosa è del tutto diversa: io procederò con la "melodia delle lunghezze", vediamo dove l'idea mi porta. --Alex brollo (disc.) 00:54, 20 feb 2015 (CET)[rispondi]
Per chi volesse provarci, ecco le due "trasformate" che proverò a usare come caso test :-) :
Il diff sulle trasformate già nel primo passaggio evidenzia un largo numero di corrispondenze nella pagina test (a occhio: oltre il 75%) e identifica, di conseguenza, tutti i segmenti disallineati. Un gran numero dei disallineamenti è di semplice risoluzione (differenze nella sequenza spazio-punteggiatura). Restano isolate sequenze difficili; solo a questo punto diventa necessario l'analisi dei caratteri, ma il più sembra fatto. --Alex brollo (disc.) 10:24, 20 feb 2015 (CET)[rispondi]
Sto spezzettando il problema, lavoro in puthon su una cartella dropbox, a cui dò volentieri accesso a eventuali interessati. Bisogna che siano installati, oltre a Python, pywikibot, pyquery, e DjvuLibre. L'estrazione dei dati dal djvu è pagina per pagina, come file dsed. I djvu devono avere uno strato testo con dettaglio word (quelli da IA vanno benissimo).--Alex brollo (disc.) 00:14, 24 feb 2015 (CET)[rispondi]
Ecco le prime righe degli appaiamenti sulla pagina test:
Poiché pur veggio tormi
Poiche pur veggio tormi
Da vn'acerba partita Il mio
Da un’acerba partita Il mio
la mia
la mia
Ma che parl'io di ricrouar accenti Conformi a miei
Ma che parl’io di ritrovar accenti Conformi à miei
sì graue io lento il mio duol farti, Che tempo è di morir, non di
sì grave io sento il mio duol farsi, Che tempo è di morir, non di
In questa pagina (nonostante sia seicentesca) l'algoritmo appaia 161 su 180 parole presenti nello strato OCR del file djvu. Tutto avviene solo basandosi sulle "trasformate" ossia sulla sequenza delle lunghezze delle singole parole, in totale automatismo (lo script riceve solo il nome del file djvu e il numero di pagina). Provo a stressarlo un po', con altre pagine da altri djvu, prima di entusiasmarmi troppo :-) --Alex brollo (disc.) 23:18, 24 feb 2015 (CET)[rispondi]
memoRegex
Sono estremamente soddisfatto del sistema chiamato memoRegex, che consente di memorizzare (attraverso Trova & sostituisci) serie di sostituzioni regex opera-specifiche e di memorizzarle stabilmente. Tuttavia serve un sistema per automatizzare il salvataggio/il ricaricamento, al momento manuale; prima di imbarcarmi nell'ideazione di qualche accrocchio informe, c'è qualcuno che ha una buona idea? --Alex brollo (disc.) 16:06, 2 mar 2015 (CET)[rispondi]
Progetto Splitter
In Indice:Cenere.djvu (pag. 9-15) i primi vagiti di un "caricatore OCR" python. L'attuale logica:
RigaIntestazione (nel caso semplice delle opere dell'editore Treves) funziona;
autoPt (applicazione automatica sia del Pt finale, che del Pt iniziale) funziona a singhiozzo e va rifinito: si impiglia quando nella prima riga della pagina restano frammenti di Intestazione o quando a piè di pagina compaiono note o elementi abnormi del footer)
Appena implementata la funzione che legge il memoRegex standard in Discussioni indice lo applica in Python (da verificare alcune cosette relative ai caratteri Unicode e alla diversa sintassi per i gruppi)
todo:
implementare l'automazione di memoRegex rendendo inutile il salvataggio e il caricamento manuali; l'oggetto JSON ha caratteristiche formali sufficienti per essere riconosciuto da find_stringa() nel testo della pagina.
rifinire le ripuliture delle righe header e footer e aggirare il problema delle note che bloccano autoPt
stressare il meccanismo di autoRigaIntestazione nei casi più complessi (rigaIntestazione che varia nei capitoli)
Bug acchiappato
Entro in modifica in una pagina e premo immediatamente Ritaglio: non succede niente o_O. Faccio qualcosa, e Ritaglio parte. Meno male che c'è la console che in caso di fallimento mi segnala che c'è un elemento indefinito: mw.activeElement; ne approfitto per dire cos'è per chi non lo conosce: memorizza l'ultimo campo attivo, capace di accettare testo (tutte le caselle testo dei form, tutte le aree testo). I vari tool di edit non infilano il loro testo nel box di edit generale (come scioccamente fanno molti pulsanti del toolbox vector), ma li infila nel campo dove stava il cursore, prima di pigiare il bottone.
Ma se il focus non era mai stato portato su uno di questi campi.... mw.activeElement era indefinito e tutto si piantava. Adesso, la textarea principale di edit è il mw.activeElement di default. Un bug in meno :-) --Alex brollo (disc.) 18:42, 5 mar 2015 (CET)[rispondi]
Vedere l'hOCR
Questa a destra è la visualizzazione di una piccola parte dei dati contenuti in mw.pagina.linee. Ogni elemento linea contiene in realtà parecchi altri dati, tutti ottenibili dalle coordinate delle linee e dal testo che ciascuna linea contiene. Il passo successivo è di passare dai dati al loro significato. Esempio: il rapporto fra lunghezza della linea e il numero di caratteri, tenuto conto anche della sua altezza, è indicativa delle dimensioni del font. Una anomalia nella terna dei dati (pochi caratteri in una linea lunga e bassa) è indicativa di linea speciale con spazi vuoti all'interno. Sequenze di linee allineate sia a destra che a sinistra, ad eccezione della prima (indentata) e dell'ultima (di lunghezza casuale) costituiscono un paragrafo in prosa. Linee centrate in una sequenza di paragrafi sono quasi certamente titoli di sezioni/capitoli. Sequenze di linee a fine pagina con font più piccolo sono quasi certamente note.... --Alex brollo (disc.) 20:41, 10 mar 2015 (CET)[rispondi]
Il progetto: "cambiare colore" alle righe dei vari tipi rappresentate a dx in modo da poter visualizzare l'effetto degli algoritmi di classificazione automatica e conseguente aggiunta dell'appropriata formattazione. --Alex brollo (disc.) 10:54, 13 mar 2015 (CET)[rispondi]
"If you are repeating yourself, you are going wrong". Sono imbarazzato dalla confusione che faccio mentre tento di programmare, ma anche i "big" qualche cattivo esempio me lo danno. Uno, fastidiosissimo, è la duplicazione dell'algoritmo per l'incapsulamento, usatissimo da noi, e presente in due diverse versioni che si comportano in maniera diversa - e la più recente è, inesplicabilmente, quella più sbagliata.
Come sapete, se provate a "incapsulare" il testo selezionato, ad esempio, nel markup il tag sup, potete farlo sia con il bottone A del toolbox Vector, che con il link in editTools. La differenza notevole è che il primo agisce - scioccamente - solo nella textarea principale; il secondo agisce - correttamente - in qualsiasi textarea o input area dove stia il cursore/la selezione. Qualsiasi bottone aggiuntivo in toolbox, scritto con la sintassi consigliata, ossia con il metodo encapsulate, si comporta nel modo sbagliato. Questo perchè ci sono due funzioni totalmente diverse per l'azione encapsulate - è mai possibile???
Come rimediare? Nei miei tool ho, con una certa fatica, emulato edittools; ma è ovvio che la soluzione sarebbe modificare il metodo encapsulate di Vector. --Alex brollo (disc.) 11:46, 18 mar 2015 (CET)[rispondi]
Vedo che la "mia" funzione incapsula è simile a mw.toobar.insertTag(), che è quella che viene lanciata negli edittools. Sostituirò quindi incapsula() con la funzione già presente anzi: incapsula() chiamerà semplicemente mw.toobar.insertTag, per ora, così non devo impazzire a modificare codice qua e là. Vediamo.... --Alex brollo (disc.) 09:22, 26 mar 2015 (CET)[rispondi]
Disgraziatamente (ma era logico) mw.toobar.insertTag esiste solo in edit. Chi poteva pensare che un matto usasse funzioni di edit in modalità view? Quindi, mi tocca rinunciare alla funzione in newThumbs, in cui si edita in modalità view... --Alex brollo (disc.) 17:22, 30 mar 2015 (CEST)[rispondi]
Il bottone Sc
Ho appena modificato [582] il codice di MediaWiki:Gadget-pulsanti-Sc.js, sostituendo l'originario encapsulate con una chiamata callback a incapsula(). Risultato: adesso il bottone agisce anche sull'header (e questo mi salva le coronarie, perchè millanta volte ho cercato di inserire in RigaIntestazione un Sc ottenendo quello che sapete...).
Nella pagina Pagina:Storia delle arti del disegno.djvu/285 ho applicato un errata corrige originale che contiene un autore citato, ma come potete vedere la cosa non è compatibile. Togliendo "Autore citato" va tutto a posto, quindi utilizzando due template Ec dovrei risolvere la cosa, ma prima di procedere volevo sapere se esiste una alternativa. --Luigi62 (disc.) 22:00, 25 mar 2015 (CET)[rispondi]
@Luigi62Purtroppo, per come è costruito il template, niente da fare. Il testo che viene passato come parametro 2 (testo corretto) è incorporato in un parametro html title, per essere visualizzato al passaggio del mouse; e deve essere "testo semplice", con parecchie limitazioni formali. Volendo usare Ec, la tua soluzione è la migliore "pezza" che si possa mettere in questo caso. --Alex brollo (disc.) 15:15, 14 apr 2015 (CEST)[rispondi]
problemino ePub
Il testo L'edera (dramma) stressa molto il codice di Blocco a destra ecc. Mi sono accorto che ci sono problemi con il template Blocco a destra (che crea una tabella float:right e chiude con br clear="all"); il br clear=all non ha l'effetto voluto e in L'edera (dramma)/Atto I/Scena I veniva fuori un pasticcio. Bisognerebbe usare questo testo molto complesso per verificare i problemi di conversione ePub e aggiustare, eventualmente, i template critici con template non problematici. --Alex brollo (disc.) 14:19, 27 mar 2015 (CET)[rispondi]
Monitorare il buon proponimento
Mi sono promesso di dominare il mio istinto alla divagazione e di lavorare in nsPagina per almeno i 4/5 dei miei edit. Ma come misurare comodamente la cosa? Chiedo l'elenco dei miei contributi (gli ultimi 500) e poi lancio:
n=0;
nt=0;
$(".mw-contributions-list li").each(function() {
titolo=$("a",this).eq(1).attr("title");
if (titolo.indexOf("Pagina:")===0) n+=1; nt+=1;
})
alert("nsPagina: "+n+"\nTotale: "+nt+"\nPercentuale in nsPagina :"+Math.round(n/nt*10000)/100)
Curiosità: gli ultimi 500 edit complessivi di tutti gli utenti cadono in nsPagina per il 71%. Gli ultimi 500 contributi miei cadono in nsPagina per il 71.2%. Sono l'utente medio :-). --Alex brollo (disc.) 23:54, 3 apr 2015 (CEST)[rispondi]
Essendo una mission impossible mi sono ridimensionato a puntare all'80% di edit nsPagina + ns0, conteggiando separatamente i due tipi di edit e poi sommandoli per ottenere la percentuale globale. Adesso ci siamo :-) . --Alex brollo (disc.) 16:36, 13 apr 2015 (CEST)[rispondi]
A posto, dopo una snervante attesa adesso il generatore di ePub si è convinto a leggere il nuovo file Epub.css, l'ePub di Odio vince ha la formattazione desiderata. Se questo dipende dall'intervento di qualcuno... grazie. --Alex brollo (disc.) 09:46, 8 apr 2015 (CEST)[rispondi]
Progetto currentIndex
A seguito di esperimenti, effettuati su fr.source, ho abbozzato, mesi fa, il progetto currentIndex.
L'idea è semplice: non appena si entra in una pagina (nsPagina, ns0, nsIndice) verificare a che pagina Indice quella pagina è collegata; verificare se è la stessa già caricata (come avviene passando da una pagina a una pagina dello stesso Indice o spostandosi da nsPagina a una pagina transclusa in ns0); se la pagina Indice è diversa, allora leggerne l'html ed estrarne tutti i dati disponibili, caricandoli in localStorage.
In qualsiasi momento, quindi, sia in nsPagina, che in ns0 (proofread), sono sempre disponibili tutti i dati presenti nella pagina Indice: sia quelli generati dal template principale, che quelli generati da pagelist e
da ciò che è contenuto nel campo Sommario.
Questa parte del programma dovrebbe essere particolarmente robusta ed efficente, e dovrebbe girare in sottofondo di default, integrata in MediaWiki:Gadget-common.js.
Da qui in poi, su questa base, ci si può sbizzarrire nell'uso dei dati con i gadget opzionali più diversi; ma questa è sarà una fase successiva. --Alex brollo (disc.) 20:04, 5 apr 2015 (CEST)[rispondi]
Le cose sembra vadano bene. Corre sperimentalmente uno script autoNs0_test() (per ora come "giocattolo" lanciato da un bottone) che ha una struttura assai simile a ns0Auto ma che usa dati già disponibili in localStorage eche quindi non necessita di ulteriori letture. La logica è quindi molto più chiara, non richiamando script esterni, e la velocità molto superiore. Test in corso su Le piacevoli notti. Obiettivo di miglioramento: automatizzare anche la gestione di fromsection e di tosection. --Alex brollo (disc.) 06:44, 7 apr 2015 (CEST)[rispondi]
currentIndex(): update
Sto rivedendo profondamente newThumbs, e ho sentito l'esigenza di "tirare su" altri dati dentro la famiglia di variabili mw.currentIndex. A questo punto sarà bene trasformarle in un unico oggetto; ma per non impelagarmi in troppe modifiche al momento ho continuato a creare oggetti indipendenti. Ciascuna variabile è accoppiata a un dato localStorage, quando si tratta di oggetti in formato JSON.
Ad oggi le variabili disponibili (estratti sia dall'html, che dal wikicode della pagina Indice) sono:
mw.currentIndex: il nome della pagina Indice
mw.currentIndexData: il dizionario pagina cartacea-pagina djvu
mw.currentIndexPagelist: la lista delle pagine (indice=pagina djvu; valore=pagina cartacea o ciò che appare da pagelist)
mw.currentIndexSummaryData: tutti i dati del campo Sommario
mw.currentIndexSource: il contenuto del campo fonte (utile se identificatore di IA)
mw.currentIndexPageSal: lista identica a mw.currentIndexPagelist come indice, il valore è il SAL della pagina
mw.currentiIndexBaseImg: l'URL base dei file immagine
mw.currentIndexMetadata: il valore dei vari campi del form base (titolo, autore...)
Questi dati sono, come già riportato, disponibili dopo l'accesso a qualsiasi pagina, anche in fase di creazione, collegata alla pagina Indice (nsIndice, nsPagina,ns0) e non vengono riletti finchè si nagiga in pagine collegate alla stessa pagina Indice. --Alex brollo (disc.) 14:28, 21 apr 2015 (CEST)[rispondi]
In rilettura testi mi sarebbe molto utile lo strumento "trova", ma tale strumento, in google, non distingue alcuni caratteri. Ad esempio se cerco le ì (accentate) mi segnala anche quelle non accentate. C'è qualcuno che sa dirmi se esiste un modo per risolvere il problema? Grazie e cordiali saluti a tutti --Utoutouto (disc.) 12:19, 25 apr 2015 (CEST)[rispondi]
Raccomandazione
Vedo di nuovo la console ingombra di messaggi di deprecazione causati dall'uso di importScript, che va sostituito con l'odioso mw.loader.load(). Io sto eliminando quelli nei miei script personali, preferirei che di quelli in nsMediaWiki si occupasse qualcun'altro, per quanto possibile ne starò lontano. --Alex brollo (disc.) 00:42, 3 mag 2015 (CEST)[rispondi]
@Alex brollo La deprecazione si riferisce in realtà solo a importScriptURI e importStylesheetURI; importScript e importStylesheet non sono ancora rimpiazzabili (gerrit:206078). I messaggi spariranno dalla console non appena MediaWiki verrà aggiornato anche qui. --Ricordisamoa05:55, 3 mag 2015 (CEST)[rispondi]
@Ricordisamoa Non cambia, un po' di approfondimento mi ha orrificato, nei miei script sono miriadi le mute deprecazioni potenziali. Fra gli script borderline, non terminati, vorrei incoraggiare qualcuno che maneggia come si deve javascript a completare memoRegex, nella fase di memorizzazione/caricamento automatico (per ora, manuale e critico) passando da Indice a Indice. --Alex brollo (disc.) 08:28, 3 mag 2015 (CEST)[rispondi]
importScriptUri dovrebbe essere contenuto solo in MediaWiki:Common.js, e in un bel po' di pagine in nsUtente di utenti foresti. La deprecazione di importScript è forse un errore/una iniziativa intempestiva? In sè, importScript è una richiesta sincrona o asincrona? --Alex brollo (disc.) 08:33, 3 mag 2015 (CEST)[rispondi]
Stranezza per gli utenti sloggati
Sono alex sloggato, sto facendo un giro esplorativo per vedere cosa trovano gli utenti non registrati e in quante "deprecazioni" incorrono (c'è un mucchio di deprecazioni per l'uso di skin, ma non ho capito da che script originano). Segnalo però un problema notevole: non vedo i radiobutton del SAL in edit di nsPagina. E' un problema noto? (alex brollo sloggato) --193.43.176.1508:48, 6 mag 2015 (CEST)[rispondi]
Alex, te lo sei dimenticato? Dato che la rilettura va fatta da un utente diverso da chi ha trascritto, se sei sloggato non puoi impostare il sal. Non può essere altrimenti che così. Ci dovrebbe essere anche un avviso in alto. Can da Lua (disc.) 09:22, 6 mag 2015 (CEST)[rispondi]
Nella mia "configurazione di preferenze" avviene che la linguella Cronologia si visualizza dopo un paio di secondi, e sposta la linguella Modifica verso sinistra. Conseguenza: se clicco Modifica spesso il click viene raccolto da Cronologia, perchè Modifica mi è scappato via sotto il mouse... che grandissimo fastidio! Consigli? --Alex brollo (disc.) 14:06, 12 mag 2015 (CEST)[rispondi]
Le due edizioni hanno la parte finale molto diversa, e si tratta di una scelta dell'autore; immagino che nel frattempo sia successo il pandemonio, e in qualche modo la differenza è giustificata da quello.
Due "sogni tecnici", uno piccolo, uno più impegnativo.
Innanzitutto i link alla pagina disturbano; dovrebbero almeno essere convertiti in link interni al testo.
In secondo luogo, sarebbe magnifico se fossero evidenziate le maggiori differenze nei due testi (una specie di diff con testo non corrispondente evidenziato da uno sfondo colorato, per esempio).
@Aubrey, Candalua Migrato senza troppi traumi in core da compat, sto seguendo una idea bizzarra:il "self M&S". L'idea è la seguente: estrarre via bot un blocco di pagine dal file djvu e prepararci una pagina unica, con il testo di tutte le pagine a cui è stato aggiunto il codice magico split. Vedete il primissimo esperimento in Utente:Alex brollo/testo, nella cronologia vedete il primo caricamento da Alebot, poi l'intervento (andato a buon fine) di Phe-bot che adesso rollbackerò per procedere con la fase successiva: l'edit manuale prima dello splittaggio. Notate che l'OCR è stato pre-elaborato analogamente a quanto fanno postOCR, aggiustaParagrafi e unisciLinee, compresa l'aggiunta di RigaIntestazione non più dipendente da RigaIntestazione scritto sulle pagine precedenti.
L'idea potrebbe avere due vantaggi:
il rigaIntestazione automatico senza creazione sequenziale delle pagine;
la possibilità di editare pagine multiple (es. con trova & sostituisci) in un colpo solo.
In questa versione test, ho usato una pagina-sandbox, ma nulla impedisce che il bot scriva il testo estratto dentro una pagina ns0 definitiva realizzando quindi il "self M&S" completo: si editerebbe rapidamente il testo di un intero capitolo in ns0, portandolo a un "quasi SAL 75%", poi si lancerebbe lo split e su ns0 praticamente non si ritornerebbe più.
L'idea è interessante, SE riesci a convincere i due-tre utenti che potrebbero usarla ad usarla (Marco Lino, Xavier, forse Accurimbono). Cioè, mi pare davvero interessante, soprattutto il discorso di RigaIntestazione, che però potresti risolvere a priori e in maniera indipendente al "self M&S".
Ovviamente, il discorso di cercare/sostituire su tutto il testo è molto interessante anche lui.
Tutto ciò che risparmia tempo all'utente e automatizza lavori "stupidi" è cosa buona e giusta, ricordati però che l'usabilità è regina, e se la procedura è difficile o di difficile comprensione, nessuno l'userà. --Aubrey (disc.) 23:38, 4 giu 2015 (CEST)[rispondi]
@Aubrey Sono andato un po' avanti, ho già sistemato le cose in modo da caricare il testo "self M&S" direttamente sulla pagina ns0 finale (prodotta da autoNs0). Lì il testo complessivo può essere corretto (aggiunta ref, sistemazione delle frattaglie in testa e in coda alle pagine, postOCr...) e una volta soddisfatti si lancia il M&S e la pagina diventa automaticamente "transclusa". Vedi la cronologia di Il risorgimento d'Italia/Parte I/Introduzione e di Il risorgimento d'Italia/Parte I/Prospetto generale d'Italia. In qualche modo, l'idea è anche correlata alla tua, di disporre subito del testo in ns0, fin dall'inizio dei lavori. Continuo gli esperimenti con un po' di try and learn, ovviamente "in corsa" emergono dei piccoli problemi difficilmente prevedibili. Hai ragione: esportando in javascript gli stessi script che consentono di ottenere RigaIntestazione in qualsiasi pagina, a prescindere dalla lettura delle pagine precedenti, è possibile ottenere la stessa cosa lavorando direttamente su wikisource; basta che esista una tabella che contenga i dati "da pagina a pagina lo schema rigaintestazione è questo; da pagina a pagina.... " ecc. Per fortuna, le differenze fra le regex python e quelle javascript è risultata minima :-) --Alex brollo (disc.) 08:06, 5 giu 2015 (CEST)[rispondi]
Come cavia sono sempre a disposizione, fatemi un fischio che inizio a provare. I testi su cui intendo lavorare sono questi: Aminta e Comedìa: OCR tosto ma a me servono tutti gli altri automatismi, es. immediata sostituzione s-ſ, poem automatico, numerazioni verso ogni 5 su tutto il testo in un solo click o rigaintestazione ecc. ecc.)@Alex brollo su questi testi vale sempre quel discorso diplomatico/interpretativo che abbiamo inziato qualche tempo fa, quindi per ogni singola pagina farò sempre doppio lavoro: se esistesse un modo per velocizzare anche questa pratica, tipo un duplica nella riga sottostante il testo fra i tag poem con inserite già le section ecc., gradirei moltissimo :) --Xavier12111:35, 5 giu 2015 (CEST)[rispondi]
Caro Xavier, non sarebbe molto più interessante e soddisfacente lavorare, che so, su bei romanzi di fine ottocento, dove la formattazione più complessa è un occasionale corsivo? :-P
Prima di affrontare quei testi là.... abbi pazienza.... nel frattempo dà una prima occhiata a come vengono le pagine dagli "esperimenti" in corso. Alex brollo (disc.) 12:10, 5 giu 2015 (CEST)[rispondi]
Questo è carino; offre il problema dei capitoli cortissimi e "sezionati". Ok, mi prenoto per qualche test sulla parte ancora non creata: primo passo, la creazione di una bella serie di pagine-capitolo in ns0 prima di creare le corrispondenti pagine Pagina; da quel punto, verifica della massima automazione possibile. Inserirò i dati sui "modelli di rigaIntestazione" in pagina Discussioni indice (in questo caso, semplicissimi: sono di un tipo solo....)--Alex brollo (disc.) 16:50, 5 giu 2015 (CEST)[rispondi]
@Aubrey Immaginiamo che, fatta una pagina Indice (con un buon pagelist e un buon Sommario con i suoi Indice sommario) la pagina base di ns0 (quella con Intestazione), definiti gli schemi per rigaIntestazione e salvato l'eventuale memoRegex (vedi in Discussioni indice:Bettinelli - Opere edite e inedite, Tomo 7, 1799.djvu tutto il resto (creazione sottopagine e aggiunta in ciascuna sottopagina del testo con il codice SPLIT) sia totalmente automatizzato ossia: sia questione di n. 1 click: ti basterebbe come semplificazione? Gli "attrezzi" dovrei averceli ormai tutti.... mi manca un passo critico, portare la cosa su Labs, ma se il tutto funzia chiederò aiuto. --Alex brollo (disc.) 14:53, 6 giu 2015 (CEST)[rispondi]
carica("Occhi_e_nasi.djvu","Occhi e nasi/Le persone prudenti",True,True)
e null'altro. Com'è stata creata quella, potrebbero essere create tutte quelle che mancano. Direi che ci siamo quasi :-) (i due True finali sono provvisori, significano rispettivamente "aggiusta i paragrafi" e "sovrascrivi") Alex brollo (disc.) 16:49, 6 giu 2015 (CEST)[rispondi]
Update, sempre su Occhi e nasi. Adesso ha corso il comando:
carica("Occhi_e_nasi.djvu")
Lo script si è arrangiato a rovistare nel codice wikisource, identificando tutte le sottopagine ns0 ancora rosse, creandole e aggiungendo a ciascuna il "testo SPLIT". Manca la creazione automatica della pagina ns0 principale (quella che contiene Intestazione) ma lo script dispone già di tutti i dati necessari, è questione di poco. --Alex brollo (disc.) 08:25, 12 giu 2015 (CEST)[rispondi]
Lo script ha lavorato anche su altre opere, in corso i lavori su Arcadia (Sannazaro). Per due capitoli minori lo script ha lavorato da Tool Labs, ma in interattivo da console; per poterlo attivare da remoto, via URL, ce ne vuole.... --Alex brollo (disc.) 10:17, 22 giu 2015 (CEST)[rispondi]
Procedure Wikisource
Proseguo qui giusto la discussione iniziata qui sopra per riflettere a voce alta e condividere con voi alcuni pensieri.
Il punto, credo, sia quello di raggiungere, il più possibile, una serie di procedure semplici, che semplifichino la vita dell'utente. Però dovremmo essere razionali e avere chiara in testa una panoramica delle azioni.
Abbiamo già un'azione molto semplice, accessibile a tutti, ed è il passaggio da 75% a 100%, la cosiddetta "rilettura". Secondo me è stato un traguardo importante e infatti i numeri lo dimostrano (soprattutto quelli dei concorsi di rilettura).
Siamo a buon punto (ma certo è da migliorare) per il caricamento di un libro su Wikisource: con i tool di Tpt, il passaggio da Commons, mettere un libro su Source è cosa accessibile. CONTINUA (Aubrey)
@Candalua Penso sia ora di mettere mano a Trova & sostituisci, sento la crescente necessità che possa agire, oltre che sul testo dell'intera pagina, sul solo testo selezionato. Non dovrebbe essere difficilissimo, appoggiandosi su mw.activeElement e la correlata sel(), che lo usa, ma la cosa è comunque un po' delicata. Ci sono due possibilità: o si aggiunge un flag al box, oppure si prevedono due comportamenti diversi del tool a seconda che, in ingresso, vi sia o non vi sia una selezione sull'elemento puntato da mw.activeElement. Please feedback! --Alex brollo (disc.) 08:13, 12 giu 2015 (CEST)[rispondi]
Sections
@Candalua Ultimo passo dell'automazione per la resa delle sottopagine ns0: riempire automaticamente fromsection= e tosection=.
Si può fare, leggendo al volo il codice della prima e dell'ultima pagina (nella mia versione personale di autoNs0, il to= punta alla prima pagina del capitolo successivo, ad abuntantiam, e non alla pagina precedente). Ci sono alcuni casi tipici e alcuni casi più rari; l'automazione è abbastanza semplice nei casi tipici.
caso 1: in nessuna delle due pagine ci sono section: fromsection= e tosection= vuoti, to= punta alla pagina precedente quella del capitolo successivo (diminuire di 1 il valore di default).
caso 2: nella prima pagina ci sono due section. Impostare fromsection sulla seconda.
caso 3: nell'ultima pagina ci sono due section. Impostare tosection= sulla prima.
caso anomalo: in qualsiasi pagina ci sono più di due section. verificare e compilare a mano.
Il tool M&S è fantastico ma.... non sarebbe male avere una nostra, autonoma aplicazione che faccia lo split (anche perchè oggi, per esempio, tutto Tool labs è fermo!).
Ci sono sue strade per farci uno split:
python (ci proverò stasera)
js (sarebbe fattibile, velocissimo, eccellente ma non mi ci metto).
Lo split in python sarà leggermente più potente dello split di M&S perchè gestirà anche header e footer (quindi, metterà RigaIntestazione là dove deve stare). Tenete i diti incrociati... speriamo che tutto vada bene. --Alex brollo (disc.) 08:31, 19 giu 2015 (CEST)[rispondi]
@Xavier121 Grazie Xavier, ho stressato il nuovo aggeggio, adesso però sono in pausa meditativa... tutto funziona, ma editare un grosso blocco di pagine ha degli inconvenienti personali: la noia. Editare una pagina alla volta ha un effetto psicologico particolare: tutte le volte che una pagina "riesce bene", si riceve una piccolissima ricompensa.... forse l'utente preferirebbe ribaltare tutto: precaricare le pagine (con tutti i possibili automatismi) e ritrovarsi, fin dall'inizio, ns0 transcluso, per poter verificare la transclusione. Con i nuovi aggeggi non serve più procedere per pagine consecutive, per ricavare RigaIntestazione, nè occorre "seminare" manualmente un paio di pagine quando RigaIntestazione cambia; il che risolve il peggiore intoppo del vecchio Precarica, che tante soddisfazioni ha dato con Deledda. Ci rifletterò, probabilmente chiederò aiuto a Santa Caterina :-). Come va Bandello?
@Candalua uploader6.py ha emesso un vagito da Tool Labs, adesso che Tool Labs si è riavviato. Deve mangiarne di polenta prima di essere un tool come si deve, ma finchè non emette il primo vagito....--Alex brollo (disc.) 18:48, 21 giu 2015 (CEST)[rispondi]
ho spostato Utente:Alex brollo/ParseIndice.js in MediaWiki:ParseIndice.js (lo script è quello che viene chiamato da importa dati e che crea il Modulo:Dati/....);
ho aggiunto in coda a Modulo:Dati/.... un oggetto JSON, dentro un commento Lua, che rappresenta il dizionario pagina djvu->pagina cartacea come primo passo per costruire automaticamente RigaIntestazione in modo "assoluto" superando il sistema, furbo ma non intelligente, di curiosare il RigaIntestazione di due pagine prima. Leggendo anche lo "schema RigaIntestazione" in pagina Discussioni Indice, dovremmo essere a posto.
Esiste l'alternativa di eseguire il parsing javascript dei dati codificati Lua di Modulo:Dati/.... e forse sarebbe la soluzione più pulita, ma siccome i dati sono generati da javascript mi sembrava seccante non memorizzarli anche in formato direttamente leggibile da javascript. Se i "piani alti" hanno risolto il problema della lettura diretta in Lua di dati JSON, ditemelo! --Alex brollo (disc.) 16:24, 22 giu 2015 (CEST)[rispondi]
PS: vedo che è stato aggiunto a Scribunto un mw.text.jsonDecode e mw.text.jsonEncode; devo solo studiarmeli.... che pasticcio; che dite, rollbacco tutto in attesa di scovare una buona struttura dati leggibile sia da Javascript che da Lua? --Alex brollo (disc.) 16:36, 22 giu 2015 (CEST)[rispondi]
Mi spiace di dovervi far scervellare dietro a problemi abbastanza astratti, ma ditemi cosa pensate di questa idea: registrare in Modulo:Dati gli oggetti javascript generati da parseIndice() passandoli a Lua come stringa JSON, e provare a farglieli decodificare; fare le cose in modo che javascript possa leggere l'intera pagina, scovare la stringa JSON, e decodificarla. A questo punto sia Lua che javascript leggerebbero gli stessi dati. Che ne dite? --Alex brollo (disc.) 17:22, 22 giu 2015 (CEST)[rispondi]
Modulo:Dati contenente dati JSON leggibili sia da Lua che da javascript
In Modulo:Dati/Gozzi - Le fiabe. 1, 1884.djvu (che blocco per evitare accidentali riscritture) ho inserito manualmente i dati dell'oggetto d2b (dizionario numero pagina djvu -> numero pagina cartacea), codificati in JSON, nella variabile Lua d2b, con l'istruzione:
local d2b = mw.text.jsonDecode('....')
eliminando la lunga serie di istruzioni che caricava i dati uno per volta. Il modulo funziona regolarmente.
Dopodichè dalla console, in edit della pagina Modulo, ho letto il codice e l'ho passato alla seguente istruzione javascript:
Questo significa che si può effettivamente memorizzare rappresentazioni JSON di oggetti in una pagina scritta in LUA, in modo che l'oggetto (lo stesso oggetto!) sia accessibile sia in Lua che in javascript; il che significa che gli stessi identici dati, una volta generati, possono essere riutilizzati quante volte si vuole sia in edit che nel parsing del codice wiki (e quindi i dati compaiono regolarmente nell'html, e in tutte le loro derivazioni, come l'output dei normali template), senza ripetere la lettura, e l'analisi, di pagine diverse da quella dove i dati sono registrati. Intravedo delle grossissime semplificazioni nelle automazioni di RigaIntestazione e in autoNs0 e non solo.... :-) --Alex brollo (disc.) 19:56, 22 giu 2015 (CEST)[rispondi]
@Candalua Però, a pensarci, Nota separata già contiene metà del codice necessario a risolvere il problema della nota dentro una nota... forse basterebbe inserire l'altra metà. Da verificare. Da provare anche un template {{Ref}} che internamente usi la sinsassi alternativa #tag:ref. Forse semplificherebbe le cose. --Alex brollo (disc.) 08:21, 3 lug 2015 (CEST)[rispondi]
Vedo un tenue raggio di luce.... il caso è complesso, si tratta di una nota separata in più pagine ciascuna contenente note, ma chissà... il caso sembra comunque abbastanza raro nel testo, le lettere iniziali sono quelle più complesse, lunghe, e importanti (lettere di Caterina ai Papi); quindi non dovrebbe intralciare la trascrizione, anche se sarà necessaria una soluzione complessa ad hoc. --Alex brollo (disc.) 09:30, 3 lug 2015 (CEST)[rispondi]
@Candalua, Ricordisamoa Data una textarea, in cui sia rappresentata una lista di parole separate da speciali caratteri-spazio e speciali caratteri-fine riga, ideare uno strumento che permetta di editare il testo aggiungendo o togliendo qualsiasi cosa, ma con l'assoluta impossibilità di aggiungere, o togliere, i due caratteri speciali sopra nominati.
Usa l'evento input e consenti all'utente di proseguire l'azione solo se il contenuto della textarea rispetta il formato richiesto, fornendo in caso contrario suggerimenti su come renderlo valido.
@Ricordisamoa Grazie. Al momento sembra più promettente una strada completamente diversa, quella che sto esplorando in Utente:Alex brollo/djvuEditor.js, ossia lo "spappolamento" del testo nelle singole parole, ciascuna dentro uno span che diventa un campo input cliccandoci sopra. In questo modo l'utente non può assolutamente far altro che editare le singole parole senza poterne variare nè il numero nè la posizione. Il che - per editare i file dsed e quindi lo strato OCR dei file djvu - è esattamente quello che voglio ottenere. --Alex brollo (disc.) 11:39, 5 lug 2015 (CEST)[rispondi]
@Ricordisamoa Devo comunque esplorare l'evento input, in particolare quando scatta e se è possibile ricostruire la textarea com'era prima di un breaking input; altrimenti non c'è istruzione che permetta di risistemare le cose nel caso di un input distruttivo (tipo, seleziona e cancella tutto....). L'idea sarebbe di memorizzare la textarea ogni volta che l'input è stato regolare (cosa valutabile dopo la modifica), in modo da poter recuperare l'ultima versione corretta. Vediamo! --Alex brollo (disc.) 10:19, 6 lug 2015 (CEST)[rispondi]
@Ricordisamoa Ok, tutto sembra funzionare, qualsiasi input nella textarea, che violi il "principio di intoccabilità dei caratteri protetti" viene bloccato, in apparenza l'input non ha effetto (in realtà non è proprio così ma gli eventi sono tanto rapidi da non essere avvertibili digitando dalla tastiera), e viene visualizzato un noioso alert. Gli script, ma già lo sai, in Utente:Alex brollo/djvuEditor2.js. Alex brollo (disc.) 21:27, 7 lug 2015 (CEST)[rispondi]
@Ricordisamoa Dammi un link dove posso capire la differenza fra mw.config.set("babbeo","Alex brollo") e mw.babbeo="Alex brollo"; e del successivo mw.config.get("babbeo") rispetto a mw.babbeo. Non ce l'ho mai fatta a capire!
Quella funzione mw. eccetera è in preparazione alla trasformazione dello script in una (function() ....)() per permettere che la funzione esista anche all'esterno dello scope e sia quindi accessibile da un bottone. Ma siamo vicini (probabilmente: oltre) il limite della mia comprensione. Alex brollo (disc.) 09:29, 8 lug 2015 (CEST)[rispondi]
Ho forse capito.... mw.config.set("babbeo","Alex brollo") non funziona perchè il set funziona solo se mw.babbeo esiste (eppure l'affermazione è, come dice la console, true :-) ); quindi il set funziona solo su variabili già esistenti, non le crea ma ne assegna solo un nuovo valore. Il set funziona se prima ho creato la variabile: mw.babbeo="Alex brollo"; allora funziona mw.config.set("babbeo","Alex brollo bis"), altrettanto true. Questo l'ho capito; mi resta da capire se l'oggetto globale mediawiki a cui ti riferisci è mw, oppure è window. :-( Alex brollo (disc.) 09:47, 8 lug 2015 (CEST)[rispondi]
Mi riferisco a "mediaWiki", abbreviato in "mw". Ma mw.config.set("babbeo","Alex brollo") e mw.config.get("babbeo") nulla c'entrano con mw.babbeo... --Ricordisamoa10:25, 8 lug 2015 (CEST)[rispondi]
Riflessioni a ruota libera sull'edit
Come effetto collaterale di test finalizzati a costruire, all'interno dell'interfaccia wikisource, un editor per strato OCR dei file djvu, mi ritrovo a disporre di due sistemi diversi di edit "alternativo" di cui vagamente sento ci potrebbero essere applicazioni e sviluppi del tutto diversi dall'obiettivo di partenza.
il primo permette, dal normale html di visualizzazione, di editare istantaneamente il contenuto testuale di uno span qualsiasi.
il secondo permette, all'interno di una textarea qualsiasi, di vietare la modifica di caratteri specifici; ad esempio, impedendo l'edit del carattere spazio, si può restringere l'edit ai caratteri delle singole parole; impedendo l'edit di caratteri fine linea, si può impedire di modificare la suddivisione in linee del testo; in teoria (anche se non vedo applicazioni pratiche ma chissà) impedendo l'edit di caratteri graffa, si può impedire l'aggiunta o la cancellazione di template.
Il primo caso non permette - ovviamente - la memorizzazione delle modifiche inserite; ma sono certo che se in sottofondo vi fosse il raw code della pagina, le modifiche potrebbero essere replicate nel codice, con possibilità sia di preview, che di memorizzazione. Ne verrebbe fuori (?) una specie di mini-Visual editor ultrasemplificato.
@Alex brollo Ti invito nuovamente a ripensare la UX. Dal punto di vista dell'utente, vedersi proibita — per di più senza alcun avviso — un'azione apparentemente innocua lascia perplessi. Io indicherei invece i problemi nell'input e inviterei l'utente stesso ad annullare le proprie modifiche, controllando che l'input sia valido prima di permetterne l'invio. --Ricordisamoa09:42, 8 lug 2015 (CEST)[rispondi]
L'avviso c'è, e anche fastidioso (un alert immediato). Il problema è che l'utente potrebbe non essere più in grado di risistemare le cose (es: dopo un seleziona-cancella, un seleziona-incolla, un incolla). Devo verificare se la funzione undo del browser consente sempre di "tornare indietro": ma ottenere gli undo giusti non è una cosetta facilissima, richiede comunque delle manovre delicate dell'utente; mentre il sistema che ho implementato esegue un undo immediato e automatico. Ovvio che fare il controllo solo al momento del submit sarebbe un disastro totale e vanificherebbe anche il test di validità, per com'è costruito: lo script non troverebbe nulla di strano se si toglie un carattere critico e lo si aggiunge altrove, la "check sum" darebbe via libera nonostante gli errori. Ma come ho detto altrove, siamo ai limiti, anzi oltre, delle mie capacità. Non perderci più di tanto tempo, l'importante è la possibile idea di fondo, da sviluppare, se fosse buona, come si deve. Alex brollo (disc.) 09:58, 8 lug 2015 (CEST)[rispondi]
Semplificato con la previsione test di considerare semplicemente non editabili i normali spazi e caratteri acapo; ripristinato l'alert.
Da esplorare una "terza via" totalmente automatica per sistemare lo strato testo del djvu: quella di applicare semplicemente un postOCR modificato sullo strato testo (estrazione, analisi, modifica e ricaricamento); ispirandosi alle routine fr.source, una specie di "mise en page sul djvu" --Alex brollo (disc.) 08:20, 9 lug 2015 (CEST)[rispondi]
Ipotesi per i testi a fronte
@Candalua Sto macinando idee per i testi che, in ns0, è bene siano presentati a fronte, in due colonne con sezioni corrispondenti allineate. Non so se esista già una soluzione consolidata; se non c'è, sto immaginando una soluzione basata sulla creazione in ns0 di una tabella a due colonne, in ogni cella della quale siano transcluse, fianco a fianco, le sezioni da allineare. Oltre che su un'opera appena iniziata, avevo trovato recentemente l'identico problema su un testo ladino con traduzione a fronte, ma in sostanza l'avevo accantonato. E' ora di costruire (o di pubblicizzare se c'è) una soluzione "canonica".
Ci sono però due problemi css.
transcludendo due testi affiancati, i link alle pagine si spataccano a sinistra e si confondono. Sarebbe bene ideare un css tale che in questo caso i link alle pagine comparissero "alla tedesca" all'interno le testo, invece di flottare in giro.
la larghezza canonica della div class=testi è insufficiente per leggere decentemente una pagina con due colonne di testo a fronte; lo stesso css che modifica la posizione dei link pagina dovrebbe anche allargare sostanzialmente la class=testi.
Se div.testi è troppo stretto, direi che conviene chiuderlo e "uscire" sul contenitore più esterno (magari possiamo aggiungere a {{Intestazione}} un div a tutta larghezza, con un nome "nostro"). Provando a buttar giù una bozza di soluzione:
per prima cosa inserire nell'html (tramite un nuovo template) un div di chiusura, per chiudere div.testi e "uscire" sul contenitore
poi aprire un div "testi-large" con larghezza passata come parametro (con un default) e margin: 0 auto.
inserire n div con class=col-1, col-2 ecc. e con width: 50% o la dimensione desiderata, e poi display: inline-block; vertical-align: top. Dentro a ciascun div trascludere le parti desiderate sfruttando section
chiudere il testi-large
riaprire poi un altro div.testi in modo da "rimettere le cose a posto" (e rendere ripetibile la procedura)
per fare questi passaggi, vediamo se conviene usare un solo template che contenga tutto o se spezzettare in tanti template per ciascuna operazione
per i numeri di pagina, bisogna poi agire sulla classe numeropagina, ad esempio .col-2 .numeropagina si può farlo cadere a destra invece che a sinistra, oppure farlo proprio sparire.
l'allineamento avverrebbe racchiudendo le parti da allineare dentro delle section da trascludere fianco a fianco con granularità a piacere (ripetendo se necessario l'intera struttura più volte per ciascuna coppia di section da allineare)
Tutto questo solo in ns0. In nsPagina mi limiterei a marcare le section, e al massimo si possono usare {{Colonna}} e {{AltraColonna}}
@Candalua Studierò bene la tua proposta e proverò ad applicarla appena possibile giocando un po' con il mio css. Tuttavia, piuttosto che chiudere .testi, immaginavo di creare una classe .testiGrandi anche vuota, in modo di poter assegnare un css specifico a .testiGrandi .testi; questo permetterebbe di ficcare un templatino prima di Intestazione/IncludiIntestazione e non pensarci più, così penso si eviterebbero anche mancamenti dello script per la barra di navigazione. Lo svantaggio (ma secondo me non è un svantaggio) è che anche il box Intestazione si adeguerebbe alla larghezza del testo. Pienamente d'accordo sulle sezioni a fronte da allineare: una bella tabella, un pages dentro ciascuna cella (sfruttando bene i nuovi parametri tipo onlysection o di filtraggio pagine) e tanti saluti; purchè non restino link pagina flottanti qua e là. Alex brollo (disc.) 12:13, 10 lug 2015 (CEST)[rispondi]
@Alex brollo Il templatino prima di Intestazione non mi piace tanto, ci sono già troppe cose in quella posizione; ma banalmente si può anche aggiungere un parametro |larghezza= a Intestazione. Questo permetterebbe di non aggiungere altri div e sfruttare il div.testi già esistente (possiamo proprio piazzare la dimensione come stile inline). Il rovescio è che l'intestazione e tutto il testo useranno la "larghezza large", ma questo può anche essere accettabile (non ho guardato come è fatto il testo e me ne guardo bene, il lavoraccio lo lascio fare a te :D ) Can da Lua (disc.) 17:48, 10 lug 2015 (CEST)[rispondi]
@Candalua Mi sembra che ci siamo, in ns0 mi appoggio su un nuove template {{Taf}} (acronimo di Testi afronte) che fa tutto quello che serve. Alla fine mi sono trovato meglio con un codice tabella, tanto è tutto "nascosto" dentro il template. Il parametro larghezza= viene gestito bene da IncludiIntestazione e volendo inserire dei pezzi di testo con la larghezza di default di class=testi vasta aprire e chiudere una <div class="testi">: la barra di navigazione inferiore non ne risente. In nsPagina si può fare quello che si vuole, basta attribuire le section ai vari pezzi da montare in modo avveduto. Cercherò di rappresentare il gioco di section necessario con un'immagine. --Alex brollo (disc.) 11:36, 12 lug 2015 (CEST)[rispondi]
@Alex brollo Non male la resa. Il modo d'uso del template mi piace, bisognerebbe solo generalizzarlo prevedendo la possibilità di ulteriori colonne e permettendo di assegnare una larghezza a piacere a ciascuna colonna. Can da Lua (disc.) 11:51, 13 lug 2015 (CEST)[rispondi]
@Candalua In questo caso bisognerebbe luizzarlo: con il normale codice template è possibile, ma fastidioso, come sai, gestire cose multiple di numero non predeterminato. In ogni caso, la possibilità di usarlo in forma "semplificata" con parametri posizionali potrebbe risolvere il caso standard, lasciando a un numero indeterminato di parametri nominali il compito di gestire la personalizzazione. Fra l'altro: con la sola avvertenza di chiamare le section affiancate xxxS, xxxD (ossia: stesso nome base + suffisso Sinistra-Destra) potrebbe permettere di ridurre i parametri indispensabili da 5 a 4. Infine: il parametro larghezza= permetterà di risolvere anche altri casi, tipo quello spinoso delle tabelle larghe. Bisognerebbe controllare se si impappina il meccanismo per le annotazioni a lato (temo di sì....). Alex brollo (disc.) 13:54, 13 lug 2015 (CEST)[rispondi]
@Alex brollo Anche senza Lua, basta prevedere max 3-4 colonne (non penso abbia senso prevederne più di così). Mi perplime un attimo la scelta della larghezza in percentuale... a seconda della larghezza dello schermo, questo potrebbe risultare in un div.testi più piccolo del normale... Can da Lua (disc.) 13:58, 13 lug 2015 (CEST)[rispondi]
@Candalua La prima versione usava larghezza in em, ma ho visto che l'ePub risultante era illeggibile con Adobe; ho cambiato parecchie cose fra cui l'unità di misura della larghezza e non ho controllato ulteriormente. :-(
Mi pare comunque che a larghezza si possa dare qualsiasi unità di misura: verifico.... sì; pensi sia meglio prevedere il dimensionamento obbligatorio in em? Invece alla larghezza in percentuale delle colonne della tabella non rinuncerei. Metto nella doc di Taf il codice esplicito, così chiunque, se vuole fare un fine tuning, può farlo. --Alex brollo (disc.) 08:30, 14 lug 2015 (CEST)[rispondi]
@Alex brollo Visto che normalmente div.testi ha width:33em, direi di dare una larghezza sempre in em (che per l'epub si può ovviamente scavalcare agendo su Mediawiki:Epub.css). Bene la larghezza in percentuale per le colonne. Can da Lua (disc.) 10:21, 14 lug 2015 (CEST)[rispondi]
@Candalua OK ... basta una sciocchissima modifica di Intestazione e la correzione delle poche pagine che chiamano Taf. Intanto tu tieni i neuroni ben vispi per pescare, se trovi l'occasione, altri usi sia del parametro larghezza che del trucco Taf. --Alex brollo (disc.) 11:33, 14 lug 2015 (CEST)[rispondi]
Immaginiamo un bot su Tool Labs che riceva i comandi di DjvuLibre - tali quali, e che faccia solo due cose: o restituisce l'output allo script chiamante via Ajax (allo script chiamante il compito di usare in un modo o nell'altro ciò che riceve: puro testo, immagini, xml....). Aggiungiamo una banale routine per caricare il djvu chiamato in qualche cache e tenercelo per qualche giorno, per averlo a disposizione immediatamente in caso di richieste ripetute. Su tool labs djvuLibre c'è, e le richieste vengono immediatamente eseguite. E allora: chi lo fa, questo bot? Per gli skillheads dovrebbe essere questione di un'oretta di lavoro. Io ci proverò, ma è un secolo che non metto le mani su chiamate e risposte Ajax di un ipotetico bot ... e sì che anni fa lo sapevo (ok, in modo primitivo) fare.... --Alex brollo (disc.) 18:07, 13 lug 2015 (CEST)[rispondi]
Variabili globali javascript
Per cortesia, qualcuno mi dice dove devo mettere le variabili globali che mi servono? Nell'oggetto windows (globali singole) no; nell'oggetto mediawiki no; men che meno nell'oggetto jquery; ma leggo che mediawiki e jquery dovrebbero essere le due uniche variabili globali da usare. E allora, "perdindirindina", dove le metto? Perchè qualcuna mi serve!!!! Soprattutto le variabili-funzione. --Alex brollo (disc.) 09:48, 24 lug 2015 (CEST)[rispondi]
). The order of the Insert menu has also changed a little.
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)
--Ricordisamoa 22:21, 5 feb 2014 (CET)
