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.
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]
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]
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]
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]
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]
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]
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]
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]
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)
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]
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]
Ho appena modificato [1] 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]
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]
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]
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]
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]
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]
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]
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]
@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]
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]
@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]
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]
@Ricordisamoa, Candalua Grazie Ricordisamoa. A parte la questione delle variabili private, che mi sfugge completamente, e a parte il fatto che sono linee guida generali e non specifiche per mediawiki, ok: ci serve un "oggetto personale itsource" a cui potrebbe essere assegnato tutto ciò che deve essere pubblico, funzioni comprese; fermo restando che occorre riflettere bene sulla possibilità di evitare al massimo la necessità di "cose pubbliche". A questo punto però preferirei che l'organizzazione delle "linee guida" andasse nelle mani qualcuno che ne sa più di me e sa come tenere le cose in ordine. --Alex brollo (disc.) 09:17, 27 lug 2015 (CEST)[rispondi]
@Candalua, Xavier121, Lino Marco Dopo una dura battaglia ho dovuto gettare la spugna: {{Pr1}}, {{Pr2}}, {{Pr3}} non possono funzionare nei testi in prosa, ma solo in quelli in versi. Per ottenere l'effetto "a lato" nei testi in prosa non resta, per ora, che {{Annotazione a lato}} + {{NMIS}} in ns0. Fra l'altro: non oso vedere cosa {{Pr1}}, {{Pr2}}, {{Pr3}}, {{Annotazione a lato}} e {{NMIS}} combinano se usati con {{Taf}}.... temo degli orrori.
Mi pare di ricordare che i link pagina, in ns0, un tempo erano "float:left" mentre adesso sono "position:absolute" e che si appoggiano per il posizionamento a .testi che ha un "position:relative". Sono io che ricordo male o le cose erano diverse? --Alex brollo (disc.) 22:33, 4 ago 2015 (CEST)[rispondi]
linee,es,Riunisce le linee di testo di u paragrafo *Alt+5*,unisciLinee
Ebbene, su mul.source questa riga, messa in una normale sottopagina utente /PersonalButtons, fa le seguenti cose:
crea un bottone linee,
al passaggio del mouse compare la scritta Riunisce le linee di testo di u paragrafo *Alt+5*,
collega il bottone alla funzione unisciLinee(),
ma, novità, immediatamente collega il bottone allo shortcut Alt+5, lasciando all'utente la completa scelta di tutto.
Grazie @Ricordisamoa per avermi spintonato a approfondire qualcosetta su iffy e namespaces e dintorni; a @C.R. per avermi dato l'opportunità di tentare la "formattazione" di tutto ripartendo da zero (ma gli strumenti c'erano già tutti, grazie al lavoro di @Candalua.... è bastato ripensarli e riassemblarli); e ai "piani alti" per aver incasinato talmente la questione dei gadget, da incoraggiarmi a farne totalmente a meno :-P. Alex brollo (disc.) 14:01, 13 ago 2015 (CEST)[rispondi]
Ovviamente Pathoschild non può immaginare cos'abbiamo combinato noi in tema di script e gadgets :-D ma intravedo la possibilità di usare TemplateScript come "framework" per le nostre boldaggini - un'occasione di mettere le cose in ordine. Personalmente il primo approccio con lo script è stato disarmante (ha un notevole livello di astrazione/generalizzazione, lascia tramortiti....) ma mettendosi forse.... --Alex brollo (disc.) 10:39, 19 ago 2015 (CEST)[rispondi]
Aggiungo: su en.source si trovano già implementazioni pratiche di TemplateScript, in particolare in queste due pagine:
Forse questa è la migliore occasione per ritornare a lavorare. Credo veramente che questo strumento possa sistemare tutti i gadget che con gli anni sono stati creati. Sarebbe utile creare un elenco di script che vanno aggiornati, così lasciamo indietro quelli che deprechiamo. Comincio intanto provando a sostituire gli Strumenti per la rilettura che sono sempre così tanto utili, per creare anche degli esempi che possono essere utili per il futuro. Samuele14:28, 19 ago 2015 (CEST)[rispondi]
Ho chiesto a Pathoschild di scrivere il codice per permettere a TemplateScript di creare un "bottone nella bottoniera"; la sidebar è scomoda, se i tools sono più di una manciata. Ha subito accettato :-) --Alex brollo (disc.) 16:25, 19 ago 2015 (CEST)[rispondi]
... e ha fulmineamente mantenuto la promessa, il codice è già nelle mani di Samuele che ne farà buon uso! Ammetto che TemplateScript al momento mi intimidisce un po'. Alex brollo (disc.) 13:57, 20 ago 2015 (CEST)[rispondi]
Con @Alex brollo pensavamo di creare un elenco dei tool, così da poterli utilizzare con TemplateScript e aggiornarli nel caso in cui siano troppo macchinosi. Dove possiamo fare questo? Direttamente qui nel bar tecnico oppure dobbiamo dedicare una pagina apposita? Samuele16:45, 20 ago 2015 (CEST)[rispondi]
Hi! The next major version of TemplateScript will be 2.0. This version will streamline TemplateScript for the way users actually use it, and add support for the newest MediaWiki features. This includes:
simplifying script helpers (so you can use page.replace(...) instead of context.helper.replace(...));
adding more script helpers (like page.get() to get the page text and page.options({ minor: true, watch: true }) to set form options);
making forActions: 'edit' the default value (so you don't need to specify it anymore);
The changes will be deployed gradually in the current 1.12.x branch, and it'll tick over into 2.0 once all usages have been updated and backward compatibility is removed.
TemplateScript 2.0 is released! This replaces the context argument for custom scripts with a more powerful editor. Some of the improvements:
You can use new helpers like editor.get() to get the text, editor.set(text) to change the text, editor.prepend(text) and editor.append(text) to insert text, and editor.options({ minor: true, watch: true }) to set form options. These methods are all compatible with the normal wiki editor and the CodeEditor.
You can now use helpers on custom textboxes. For example, when editing in the Page namespace this will add something to the header:
Domanda a chi "mastica" Css come una gomma americana. E' possibile, con style inline, attribuire a una div uno stile da applicarsi SOLO nei tag p figli, e non alla div stessa? Questa storia dei p automatici aggiunti a tradimento mi fa uscire pazzo. --Alex brollo (disc.) 11:10, 31 ago 2015 (CEST)[rispondi]
Grazie Candalua. Lo temevo... quindi su mul.source, dove per fortuna sono utente semplice e non posso pasticciare su MediaWiki:Common.css, non posso agire sullo stile dei tag p via stile div; però posso usare tag p espliciti e così (con qualche limitazione) frego il sistema. :-) --Alex brollo (disc.) 11:46, 31 ago 2015 (CEST)[rispondi]
@Candalua Nel frattempo ho "aperto un task" su Phabricator, per chiedere che vengano sbloccati i due tag html colgroup e col, di cui sento terribilmente la mancanza, e che permetterebbero di formattare con una sola istruzione una intera colonna di celle - cosa vitale nelle tabelle "tipo Silvio". Spero che il fatto che il tag non è previsto dal markup wiki per le tabelle non sia un ostacolo "filosofico" insormontabile, anche perchè adesso con Lua si può generare html al volo. --Alex brollo (disc.) 16:05, 1 set 2015 (CEST)[rispondi]
Sembra che vi sia consenso wikisourciano sull'opportunità di rimuovere il filtro per i due tag html colgroup e col, e qualcuno supporta il mio suggerimento di togliere il filtro subito, e poi con calma aggiornare le funzioni parser del markup tabelle; questo permetterebbe di costruire dei template (meglio in Lua) che generino tabelle html bypassando il markup, e forse perfino semplificando le cose. Non appena il filtro sarà rimosso (speriamo presto, intravedo una possibile "philosophy war") c'è da sperimentare. E' curioso che esista un così ampio divario fra le legittime, banali necessità del povero utente comune (soprattutto wikisourciano) e le raffinatezze che appassionano i "piani alti". Alex brollo (disc.) 15:22, 2 set 2015 (CEST)[rispondi]
... E' stata una cosa drammatica, ma forse mi ha permesso di capire una cosa astrusa, la scrivo qui anche per chiarirmi le idee.
Se dalla console cercate la funzione selAut(), quella base che viene chiamata dal pulsante e da nient'altro, non c'è; eppure il pulsante funziona e la chiama. Ciò avviene perchè la funzione è definita solo dentro il gadget che è interpretato come una "iffy"; e come selAut, tutte le altre funzioni collegate. Non solo: se un gadget richiede funzioni definite in altri gadget, ossia vi sono dipendenze, la sintassi che definisce le dipendenze ha, principalmente, lo scopo di rendere accessibili le funzioni da cui dipende il gadget al momento della creazione dell'oggetto; non è quindi solo questione di ordine di caricamento, è questione di condivisione di namespace; e le questione di namespace, notoriamente, sono uno dei peggiori problemi di javascript.
Non so se queste idee sono vere, verosimili o se la sensazione di aver capito è pura illusione; sta di fatto che, applicandole, selAut l'ho riparato in pochi minuti, dopo settimane di avvilimento profondo :-) --Alex brollo (disc.) 06:31, 1 set 2015 (CEST)[rispondi]
Secondo voi, è fattibile/utile una implementazione in Lua della generazione tabelle, tale che passandogli come parametro semplicemente il copiaincollato da Excel (celle divise da tab, righe divise da acapo) venga fuori una tabella html regolare? Sarebbe ovviamente solo il primo passo, poi si potrebbe raffinare con la gestione degli stili (ho l'intuizione paranoide su un secondo parametro in cui venga passata una seconda copia opzionale della tabella, con la stessa struttura ma in cui ogni cella contenga, al posto del testo, lo stile). --Alex brollo (disc.) 08:15, 3 set 2015 (CEST)[rispondi]
Trovo dentro TemplateScript di Pathoschild questa laconica istruzione:
var pathoschild= pathoschild || {}
Dopo spremitura di meningi interpreto: "Se esiste un oggetto globale pathoschild allora usa quello; altrimenti crea un oggetto vuoto, che resterà locale". E' giusto? --Alex brollo (disc.) 12:14, 7 set 2015 (CEST)[rispondi]
Se per caso qualcuno altrettanto matto legge, gli pongo un quesito.
L'idea fondante di Modulo:Tab è di suddividere nettamente i valori dalla formattazione (con sicuri vantaggi nella rilettura di un testo estremamente semplificato). Per i dati non c'è discussione: verrebbero passati come una tabella :-) ma gli attributi/gli stili? La prima idea è quella di passarli con una seconda tabella, ma c'è un'alternativa, utile nel caso di discreta omogeneità: si potrebbero passare come elenco di dichiarazioni esplicite:
table style="border collapse:collapse;"
column1, column2 style="text-align:right;"
row1 style="border-bottom:1px solid black;"
cell(1,2) style="...."
.....
In alcune tabelle, molto intricate, sarebbe più comodo il primo metodo, in altre, più semplici, il secondo. L'ideale sarebbe poterli usare contemporaneamente. --Alex brollo (disc.) 15:21, 8 set 2015 (CEST)[rispondi]
Un po' di approfondimento mi mostra i limiti del tag col, non c'è niente da fare: molte proprietà, che non siano comuni alle righe, devono essere applicate a livello di cella (es allineamento), sia nelle tabelle vere che nelle tabelle "false". Ne prendo atto... peccato. Alex brollo (disc.) 16:32, 16 set 2015 (CEST)[rispondi]
Nelle tabelle complesse occorre usare pesantemente css per formattare particolari delle celle, diversi per ciascun gruppo di celle. Si può fare assegnando stile css inline (come fa il template tl|Cs) ma si potrebbe ottenere lo stesso risultato assegnando un corrispondente set di classi "granulari", ciascuna delle quali produce un risultato particolare (es. una classe per il bordo a destra, una per il bordo sopra.... una per il testo centrato in verticale, una per il testo bottom.... ecc.). Domanda: vale la pena di sforzarsi con fatica di evitare lo stile inline, e di convertire quanto più possibile in stile via classi? --Alex brollo (disc.) 17:15, 24 set 2015 (CEST)[rispondi]
@Samuele Papa, Luigi62 Aimè! Ho mollato la presa sui tool vari per la comunità, limitandomi a predisporre un tool personale (meno potente), dopo il crash generalizzato prodotto dalle nuove versioni di Mediawiki, lasciando che Samuele tenti l'eroica impresa di fare ordine. Avete qualche feedback da Samuele? Io sto facendo tutt'altro. --Alex brollo (disc.) 08:52, 2 nov 2015 (CET)[rispondi]
Per i tre pulsantini ho attivati la bottoneria, gli strumenti per la rilettura, memoRegex e la raccolta dei giocattoli, solo a quel punto mi sono apparsi i tre bottoni. È un po' un disastro. Sto lavorando a rendere funzionanti gli script per la gestione della Bibbia, che sono quelli con cui ho più familiarità, così nel frattempo creo l'infrastruttura per poi caricare e aggiornare il resto di tool utilizzati. Samuele17:57, 2 nov 2015 (CET)[rispondi]
Forza @Samuele Papa! Quando mi sono finalmente reso conto dell'immane bordello che nei mesi e anni di programmazione avevo combinato, era troppo tardi. Spero di resistere alla tentazione di fare altri danni, non tocco più niente prima che tu abbia finito, e prima di aver capito per bene come fare per tenere le cose in ordine. Potrebbe anche essere che .... questa attesa sia molto lunga. :-( Alex brollo (disc.) 00:23, 20 nov 2015 (CET)[rispondi]
Ho notato che da un po' quando si inserisce una nota appare uno spazio prima del richiamo alla nota1. A me sembra un errore, per lo meno se la nota viene chiamata con un apice, in alcuni casi l'ho vista andare a capo. È una scelta imposta dall'alto o comunque voluta, o è un baco del software? Grazie. --Cruccone (disc.) 22:18, 19 nov 2015 (CET)[rispondi]
Viene inserito proprio un carattere , francamente non ci ho mai fatto caso; ma penso sia una novità "automatica", bisognerebbe rovistare negli anfratti della cronologia del codice delle estensioni o in qualche messaggio di doc scritto chissà dove.... io non ci arrivo :-( --Alex brollo (disc.) 00:15, 20 nov 2015 (CET)[rispondi]
Ce l'ho messo io! Non mi piace moltissimo, ma senza di quello, quando le note sono più di una venivano appiccicate l'una all'altra, tipo così: 123 quasi fosse una sola nota con numero 123. Can da Lua (disc.) 12:47, 20 nov 2015 (CET)[rispondi]
@Candalua, Cruccone A me non disturba; mi disturba un po' che abbia disturbato altri. Uno spazio aggiunto dall'utente, quando serve, fra ref e ref non funziona? No che non funziona.... va a capo :-(. Magari mettere il   dopo e non prima? --Alex brollo (disc.) 14:59, 22 nov 2015 (CET)[rispondi]
Grazie per la spiegazione, effettivamente risolve un problema non da poco. In realtà anche uno spazio dopo il richiamo può essere problematico, se viene messo prima della punteggiatura. Una possibilità sarebbe avere qualcosa che riconosca due note vicine e metta automaticamente uno spazio nbsp (o una virgola) tra le due, ma non so se sia qualcosa che possa essere gestito da MediaWiki. Oppure, raccomandare agli utenti di "separare" le due note con lo spazio nbsp. Cruccone (disc.) 22:57, 23 nov 2015 (CET)[rispondi]
@Candalua, Cruccone Manipolando un pochino l'html ho visto che c'è una via più pulita css: basta prevedere un css "padding-left:5px" per gli elementi di classe .reference. Sempre di non andare a cozzare con un fastidiosissimo problema di ordine di caricamento del css via ResourceLoader, che "rulla" il css che si tenta di modificare (ho lottato a lungo con i settaggi css del tag p prima di gettare la spugna). --Alex brollo (disc.) 08:42, 24 nov 2015 (CET)[rispondi]
Come qualcuno saprà, mi sono completamente perso nella gestione dei gadget; lavorando su mul.source mi sono costruito un "gadget personale monoblocco", riunendo tutte le funzioni utili in qualsiasi progetto in un unico megascript e tanti saluti. Nessuna dipendenza da nulla, una meraviglia; lo stesso script corre dappertutto ignorando bellamente le "cose" locali e senza neppure aprire la pagina Preferenze->Accessori.
Tornando qui, ovviamente le script corre perfettamente, ma non comprende i trucchi specifici di it.source (es. numerazione versi; oppure autoNs0).
Penso quindi di riunire in un secondo megascript, anche lui privo di dipendenze, tutti gli script specifici per progetto, ovviamente riunendo solo quelli che giudico utili; l'insieme del megascript generico e del megascript locale dovrebbe soddisfare tutte le mie necessità, e forse anche quelle di altri. La soluzione "pulita", usando i gadget e ResourceLoader, la lascio a chi ci capisce e a chi ha la pazienza di seguire le modifiche che ogni tanto i "piani alti" impongono all'architettura del sistema; io mi sono stufato di corrergli dietro. --Alex brollo (disc.) 08:29, 24 nov 2015 (CET)[rispondi]
Bravo @Alex brollo Hai fatto bene! I redirect vanno tutti creati quando necessarie, ma (che io sappia) non collegati a Wikidata.
A Wikidata va collegata una e una sola pagina autore, quella principale (in questo caso quella col nome di Papa, che è stato scelto come per tutti gli altri autori in base al criterio wikipediano = si usa qui su it.source il nome autore di it.wiki). I redirect sono utili localmente ma non vanno collegati su Wikidata (e in quanto redirect il software MediaWiki non li indicizza nelle Pagine non collegate agli elementi).
@Alex brollo Sarebbe da ripensare come il template testo gestisce il campo autore, in maniera tale da consentire di indicare un nome autore "redirect" e fargli indicizzare il testo come appartenente al nome principale. Stessa cosa per il tl intestazione: invece che la cat "Testi di Achille Ratti" dovrebbe categorizzare con il nome principale "Testi di Papa Pio XI".
Questa era la necessità base dell'authority control: da tanti nomi (i nostri redirect) unire il catalogo verso un unico identificatore (la nostra pagina autore), in questo Wikisource è ancora indietro. --Accurimbono (disc) 09:11, 30 nov 2015 (CET)[rispondi]
Non mi piace; per ora ci metto una pezza (che categorizza come si deve) simulando in ns0 un doppio autore, Achille Ratti/Papa Pio XI. Chi segue il primo dovrebbe in qualche modo capire che si tratta della stessa persona.
che effetto curioso.... sembra quasi che l'output di Testo lo dica, che Achille Ratti è Papa Pio XI ;-) - stessa cosa in ns0. Penso possa andare, come soluzione temporanea.Alex brollo (disc.) 09:43, 30 nov 2015 (CET)[rispondi]
Sì, soluzione furba che può momentaneamente andare, ma per gli altri autori non papi credo sia meglio non usarla.
Uhm, i redirect nelle categorie sono pericolosi, perché lasciano delle categorie semi-inaccessibili (Questa non è vuota). In generale sarebbe utile avere un sistema che funzioni per le opere pubblicate con nome diverso (ad esempio uno pseudonimo), o per gli autori disambiguati. Cruccone (disc.) 22:38, 30 nov 2015 (CET)[rispondi]
Si usa il template AltraVersione da Ns0 {{AltraVersione|Catullo e Lesbia/Al Passere di Lesbia ecc.|Trad. Rapisardi}}, dovrebbe funzionare. Puoi fare una prova per capire anche in NsPagina (ma si vede l'immagine a fronte). --Xavier12112:38, 12 dic 2015 (CET)[rispondi]
Fatto. Vedi Epistole (Caterina da Siena) I/Lettera 1. Segnalo anche un nuovo template {{Ns}}, derivato da {{Nota separata}}, semplificato nei parametri (soprattutto nel caso di note che continuano su due o tre pagine; facilmente espandibile) Alex brollo (disc.) 11:24, 5 lug 2015 (CEST)
e da nient'altro, non c'è; eppure il pulsante funziona e la chiama. Ciò avviene perchè la funzione è definita solo dentro il gadget che è interpretato come una "iffy"; e come selAut, tutte le altre funzioni collegate. Non solo: se un gadget richiede funzioni definite in altri gadget, ossia vi sono dipendenze, la sintassi che definisce le dipendenze ha, principalmente, lo scopo di rendere accessibili le funzioni da cui dipende il gadget al momento della creazione dell'oggetto; non è quindi solo questione di ordine di caricamento, è questione di condivisione di namespace; e le questione di namespace, notoriamente, sono uno dei peggiori problemi di javascript.
