Quindi il problema non sta nella povera mw.toolbar.insertTags, ma in qualcosa che mw.toolbar.insertTags e quella diversa funzione hanno in comune. A questo punto mi perdo. Però, sotto eis, lancio una volta la ridefinizione della funzione mw.toolbar.insertTags e tutti i miei attrezzi e bottoni funzionano. Non mi pare il caso, comunque, di iniziare a mettere pezze, perchè il bug è così grosso che per forza devono sistemarlo i professionisti, i "developers" :-) --[[User:Alex brollo|Alex brollo]] ([[User talk:Alex brollo|disc.]]) 23:52, 15 feb 2018 (CET)
Quindi il problema non sta nella povera mw.toolbar.insertTags, ma in qualcosa che mw.toolbar.insertTags e quella diversa funzione hanno in comune. A questo punto mi perdo. Però, sotto eis, lancio una volta la ridefinizione della funzione mw.toolbar.insertTags e tutti i miei attrezzi e bottoni funzionano. Non mi pare il caso, comunque, di iniziare a mettere pezze, perchè il bug è così grosso che per forza devono sistemarlo i professionisti, i "developers" :-) --[[User:Alex brollo|Alex brollo]] ([[User talk:Alex brollo|disc.]]) 23:52, 15 feb 2018 (CET)
: Scusa {{ping|Alex brollo}}, il problema è la deprecazione di mw.toolbar? --<span style="font-variant:small-caps">[[Utente:Ricordisamoa|<span style="color:#004B70">Ricordi</span>]][[Discussioni utente:Ricordisamoa|<span style="color:#00703E">samoa</span>]]</span> 14:28, 16 feb 2018 (CET)
: Scusa {{ping|Alex brollo}}, il problema è la deprecazione di mw.toolbar? --<span style="font-variant:small-caps">[[Utente:Ricordisamoa|<span style="color:#004B70">Ricordi</span>]][[Discussioni utente:Ricordisamoa|<span style="color:#00703E">samoa</span>]]</span> 14:28, 16 feb 2018 (CET)
:: {{ping|Ricordisamoa}} No, il [ https://phabricator.wikimedia.org/T187454 ticket aperto] illustra la dinamica del bug, che non riguardava esclusivamente mw.toolbar; una modifica generale del sistema di selezione del testo fatta per facilitare l'applicazione di VisualEditor; almeno così mi è parso di capire. La cosa più seria però è la mancata emissione di un '''avviso generale''' che ammetta l'esistenza del bug in atto causato dalle nuove versioni, e dia indicazioni su come comportarsi, fornendo anche i tempi (approssimativi) della soluzione del problema. [[User:Alex brollo|Alex brollo]] ([[User talk:Alex brollo|disc.]]) 15:47, 16 feb 2018 (CET)
Versione delle 16:47, 16 feb 2018
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.
A parte questo template, che indico più che altro perché è stato il punto di partenza della mia esplorazione, ho visto che in alcune pagine della Wikisource francese il link alle correzioni funziona, apre un box che mostra le correzioni applicate, la parte corretta si evidenzia con un colore, queste stesse sono inoltre riportate singolarmente in ciascuna pagina (nelle discussioni) e poi raccolte tramite transclusione nella pagina di discussione dell'indice. Non in tutte le edizioni questo "sistema" viene applicato così coerentemente, ma la possibilità di farlo viene offerta. Si potrebbe avere anche qui? --Naamar (disc.) 02:03, 16 gen 2016 (CET)[rispondi]
Cose da non credere.... la raccolta di tool rende maneggiare il testo dentro i pdf facile come maneggiarlo dentro i djvu; anzi, forse più facile. Non in scrittura; ma in lettura sì. Aspettatevi qualche pensata stravagante (test in corso su nap.source).
Ho il piacere di segnalarvi una invenzione promettente: mul:Template:Nap, una specie di template magico che ficcato dentro una pagina Indice autocategorizza, potenzialmente, in base a qualsiasi contenuto della pagina, e qualsiasi combinazione dei vari contenuti; in pratica, in modo pressochè illimitato. L'applicazione del template non è difficile.... basta scrivere {{nap}} :-) --Alex brollo (disc.) 09:14, 6 feb 2016 (CET)[rispondi]
Sto ampliando la sperimentazione, adesso il template restituisce nell'html di qualsiasi pagina (all'interno di un tag pre invisibile, ma accessibile a javascript) l'intero wikicode corrente della pagina. Un mio vecchio sogno... da qui si parte per nuove avventure. --Alex brollo (disc.) 12:19, 8 feb 2016 (CET)[rispondi]
Disabilitata l'incorporazione del markup.... ci sono troppi "casi particolari" in cui il sistema dà segni di sconforto. Come "generatore di categorie dinamiche" invece nap fa faville, districandosi anche in casi difficili come i parametri a elementi multipli (in numero qualsiasi!) o i parametri che ricevono un link invece che un testo liscio. @Candalua se puoi dacci un occhietto... prova a pensare se potrebbe semplificare la vita anche qui (si potrebbe eliminare parecchia roba dal codice Intestazione). --Alex brollo (disc.) 23:14, 14 feb 2016 (CET)[rispondi]
Continuo a sviluppare l'idea; è veramente un template buffo, prima lo si aggiunge e poi, con calma, si decide cosa fargli fare....:-) --Alex brollo (disc.) 16:08, 3 mar 2016 (CET)[rispondi]
Inside Djvu
Ho finalmente "rotto il ghiaccio" con la manipolazione degli strati immagine (djvuextract & djvumake, e altri script che fanno varie cose) dei file djvu. Qualcuno vuole farmi compagnia? --Alex brollo (disc.) 15:22, 15 mar 2016 (CET)[rispondi]
@Xavier121 Ottimo: la solitudine pesa :-). Stamattina ho ottenuto il primo risultato concreto: dato un djvu brutto, come Indice:Verga - Vagabondaggio.djvu, con un orribile colore di fondo, eliminare l'immagine di background (grigio scura) lasciando solo l'immagine di foreground, salvando lo strato testo. Ne viene fuori un pulitissimo djvu B/N. Il tutto viene fatto da python con miriadi di chiamate alle routine di DjvuLibre, ma fa tutto da solo: basta passargli il nome del file djvu. Mi manca l'ultimo passetto, la ricomposizione di un file djvu unico dal set di pagine isolate, ma con djvm è una questione che dovrebbe essere facile. Non appena vedrai sistemato Indice:Verga - Vagabondaggio.djvu, vorrà dire che la cosa è conclusa e ti passo lo script (è brevissimo, saranno si e no una trentina di righe) --Alex brollo (disc.) 08:34, 16 mar 2016 (CET)[rispondi]
Il template {{VoceIndice}} sembra avere un problema nell'allineamento verticale dei numeri di pagina, quando è presente uno spazio: vedi ad esempio nel manuale. Può essere un mio problema di visualizzazione o capita ad altri? Qui ho risolto con uno spazio non divisibile. --Omino di carta (disc.) 13:01, 19 mar 2016 (CET)[rispondi]
@Alex brollo Vedo ancora il primo elemento col numero più in alto del resto della riga. Le altre righe sono a posto. Ho provato a cambiare il larghezzap, ma non cambia niente. Tu lo visualizzi correttamente?--Omino di carta (disc.) 20:09, 22 mar 2016 (CET)[rispondi]
@Candalua Sto cercando di capire come funziona la questione dell'header automatico generato (su mul.source, en.source, fr.source) dal parametro header=1 nel tag pages, ma mi sono perso. Il mio tentativo con Modulo:Modulo è aimè una ennesima "riscoperta dell'acqua calda", prima occorre capire bene come, dove e quando le cose funzionano normalmente, altrimenti invece di provare a allinearci ci differenziamo ulteriormente. Ce la fai a capire, o a individuare qualcuno che potrebbe aiutarci a capire? Io ci ho provato ma getto la spugna.... --Alex brollo (disc.) 11:08, 22 mar 2016 (CET)[rispondi]
@Candalua, OrbiliusMagister Nel corso della mia ostinata indagine su perchè da noi la "magia" di header=1 non funzioni, ho aperto una discussione su wikisource-l avendo utili (ma ancora incomplete e in parte esoteriche) indicazioni da un utente polacco, Zdzislaw. C'è una concatenazione di pagine speciali che devono essere correttamente sistemate con i giusti parametri; il passaggio dei parametri dalla pagina Indice al tag pages richiede i giusti settaggi di MediaWiki:Proofreadpage_index_data_config, MediaWiki:Proofreadpage_header_template e di un template Intestazione. Per non interferire con le nostre pagine esistenti ho creato un Template:Header che funge da Template:Intestazione e che può essere provato in una pagina test come Test. Naturalmente sono solo prove: nel momento in cui il sistema desse i primi segni di vita, discuteremo se è il caso di provare ad applicare la questione alle nostre pagine reali (la vedo dura). --Alex brollo (disc.) 08:39, 23 mar 2016 (CET)[rispondi]
PS: Zdzislaw si è cortesemente offerto di editare le nostre pagine chiave per risolvere il problema, ma questo richiederebbe che gli venissero assegnati privilegi temporanei di sysop. Vi sottopongo la proposta. Alex brollo (disc.) 08:48, 23 mar 2016 (CET)[rispondi]
@Candalua, OrbiliusMagisterForse ci sono riuscito! In Test il primo vagito: header=1 ha funzionato. Vedete un box Intestazione "strano" per il fatto che non usa Template:Intestazione ma un Template:Header importato da mul.source; mi sono ben guardato dal pasticciare sui nostri template di sistema; ma la cosa fondamentale era riuscire a farlo girare una volta, e in effetti, gira. Adesso possiamo andare avanti, rifinire quanto vogliamo, prima di riflettere, a lungo e profondamente, sulla possibilità di fare la "seconda rivoluzione" di Intestazione. Sarà durissima, e delicata, ma secondo me riallinearci alle altre wikisource sarebbe una cosa fantastica. Alex brollo (disc.) 15:43, 23 mar 2016 (CET)[rispondi]
@Alex brollo ho notato già un piccolo intoppo: noi sugli indici abbiamo il campo "Nome della pagina nel namespace principale", che valorizziamo sempre, e "Titolo da visualizzare", che valorizziamo solo se diverso. Ergo il dato "title" a volte non si vedrà, perché non c'è sull'indice :( Bisognerebbe in qualche modo scambiare i due campi tra loro, se capisci cosa intendo... Can da Lua (disc.) 18:39, 24 mar 2016 (CET)[rispondi]
@Candalua gli intoppi saranno innumerevoli. Tempo al tempo, intanto apro una pagina di coordinamento :Progetto:Trascrizioni/Pages, con la sua brava pagina discussioni; ci schiaffo dentro l'elenco dei template/accrocchi critici; ci aggiungo l'elenco delle pagine Indice test; poi vediamo. Alex brollo (disc.) 19:08, 24 mar 2016 (CET)[rispondi]
regexLoad.py
@CandaluaOgni promessa è debito, io sono carico di debiti ma qualcuno cerco di sistemarlo. Ecco quindi Progetto:Bot/Programmi in Python per i bot/regexLoad.py, dove ho cercato di spiegare come funziona una singola, breve ma potente funzione regexLoad() che ho escogitato per caricare da un file txt una lista lunga a piacere di regex da lanciare in blocco su un testo qualsiasi, rendendo facile sia l'edit delle regex, che la loro attivazione/disattivazione a seconda delle necessità. La potenza e la velocità delle regex in python fa il resto.
Poichè concettualmente niente impedisce di fare la stessa identica cosa in javascript, a tempo perso cercherò di implementare qui la stessa cosa, sostituendo quanto necessario, per supportare il "memoRegex" in fase di memorizzazione. --Alex brollo (disc.) 07:28, 13 apr 2016 (CEST)[rispondi]
djvuCl.py
In Progetto:Bot/Programmi in Python per i bot/djvuCl.py il primo script che è riuscito a trasformare in automatismo integrale una cartella di immagini IAId_jp2.zip e il relativo file IAId_djvu.xml in un djvu con testo mappato, che evita anche il "bug della prima pagina troppo piccola".
E' puro python, le uniche routine esterne sono quelle di djvuLibre; le trasformazioni delle immagini avvengono con il modulo PIL di python.
La routine main() mostra chiaramente i passi:
estrazione dallo zip
trasformazione in jpg
trasformazione in djvu
elaborazione di IAid_djvu.xml e suo caricamento del djvu
Ci stavo uscendo pazzo, alla fine mi sono convinto che in questa versione di File:Della_geografia_di_Strabone_libri_XVII_volume_2.djvu c'era un serio problema nella struttura del djvu che provocava due conseguenze:
il testo OCR presentato alla creazione pagina era disallineato con l'immagine;
analogamente il M&S veniva ingannato e combinava un analogo pasticcio
Il problema è stato risolto caricando il djvu in FineReader e ottenendo un djvu con nuovo strato testo; ricaricato il file djvu, i problemi sono svaniti. --Alex brollo (disc.) 08:29, 16 mag 2016 (CEST)[rispondi]
Vi trovate i djvu che saranno mano mano prodotti dagli item senza djvu di IA. Scaricateli, entrate nell'item IA dello stesso nome <ref>Per entrare nell'item IA corrispondente al djvu seguite l'URL costruito con https://archive.org/details/ + nome del file, senza l'estensione .djvu. Esempio: per il file digitami_LO1E003647.djvu, usare l'URL https://archive.org/details/digitami_LO1E003647per raccogliere i metadati, caricateli, se vi va, su Commons e poi lasciate qui un messaggio per riferire il nome del file su Commons. Buon lavoro --Alex brollo (disc.) 07:53, 17 mag 2016 (CEST)[rispondi]
Apprezzo il coraggio, ma le cose (ancora) non sono affatto semplici.
Innanzitutto devi installare due moduli non standard di python: Pillow e internetarchive.
fatto questo devi creare una cartella lab (dove vuoi) e creare alcune sottocartelle, input, output, jp2, djvu e jpg.
A questo punto devi mettere nella cartella lab lo script djvuCl.py, scegliere un testo IA, esempio dalla collezione https://archive.org/details/sbmilano (il primo è Paolina, ID: digitami_LO10534041, aprire una console cdm, posizionarti sulla cartella lab, lanciare python djvuCl.py digitami_LO10534041 e organizzarti per segnalarmi il messaggio di errore che certamente comparirà :-(
Penso che sia invece più utile, in questa fase, che tu provi a caricare qualche djvu di queli pronti su Commons e provi a creare il relativo Indice. Non voglio scoraggiarti, eh.... è solo che lo script è ancora estremamente grossolano e poco testato fuori della sua culla. Alex brollo (disc.) 18:34, 17 mag 2016 (CEST)[rispondi]
@Alex brollo è proprio questo il problema: al momento non si può, si può solo recuperare l'elemento connesso alla pagina corrente e passare su quelli a lui collegati. C'è un bug aperto (phab:T74815) ma sembra che non sia facile risolverlo (incredibilmente nessuno ci aveva pensato al momento di progettare Wikidata...). Can da Lua (disc.) 17:38, 18 lug 2016 (CEST)[rispondi]
Da un po' mi frulla l'idea di costruire un "tool per la revisione rapida", ispirato al vecchio editor dai thumbnails che è stato "ucciso" dalle modifiche del software mediawiki.
L'idea è quella di fare una pagina speciale vuota in cui poter richiamare rapidamente pagine nsPagina, sia come anteprima che con un box di editing (ovviamente visualizzando l'immagine della pagina), salvandole senza ricaricare la pagina e potendo quindi rapidamente passare da una pagina alla precedente/successiva; la novità sarebbe che incorporerei anche una specie di pagelist in modo di poter dare un'occhiata generale all'insieme delle pagine. Insomma, una specie di "Edit in View" sganciato però dal nsPagina.
@Candalua, Ricordisamoa Non vengo a capo nel cercare da dove viene lo style di un elemento; come faccio a rintracciare l'origine? In particolare sto litigando con vertical-align:middle che qualcuno-qualcosa attribuisce agli elementi fantasma tbody. --Alex brollo (disc.) 10:06, 23 ago 2016 (CEST)[rispondi]
Per come vengono "incollati" i CSS non è detto che sia così facile, ma se usi gli strumenti da sviluppatore del browser (F12) e selezioni il tbody in questione ti dovrebbe dire anche il file in cui sta la regola CSS. Male che vada ti dice qual'è la regola che viene usata per quel tag tbody (qualcosa come "tbody, ... {") e così poi puoi cercarla all'interno dei file di sistema sperando di trovare dove viene definita (e perché).
@L0ll0 Il problema è che vertical-align per i td è inherit, ma il vertical-align:middle su tbody "rompe" la catena di inherit e impedisce che il settaggio in table sia ereditato da td. Grazie @Ricordisamoa sotto Chrome non ne vengo fuori, vediamo sotto Firefox. --Alex brollo (disc.) 10:59, 23 ago 2016 (CEST)[rispondi]
@Candalua, Ricordisamoa Ho inserito tbody {vertical-align:inherit;} in MediaWiki:Common.css; adesso, uno style="vertical-align:top|middle|bottom" all'elemento table effettivamente viene ereditato da tutti gli elementi td. Ovviamente, non c'è quasi nessuna tabella in cui tutti gli elementi td abbiano lo stesso vertical-align ma un piccolo miglioramento c'è IMHO. Alex brollo (disc.) 00:49, 24 ago 2016 (CEST)[rispondi]
Referencetooltip e nota separata
@Candalua, OrbiliusMagister Inserendo qualche centinaio di tl|nota separata e guardando il risultato, mi disturba il numeropagina che si sovrappone al testo nel bel quadrello, e l'ho eliminato nel mio common.css con:
Gira nell'ambiente delle pagine wiki l'oggetto "misterioso" OO, generato da OOjs, e costituito da una poderosa libreria javascript che mi pare di aver capito è ampiamente sfruttata da Visual Editor per le sue operazioni pazzescamente complesse. E' un peccato non usarlo, e "reinventare l'acqua calda" (sprecando per di più risorse di tempo personale e di tempo macchina) costruendo a mano strumenti che già sono disponibili. Qualcuno di "quelli bravi" lo conosce, ricordo che @Ricordisamoa mi ha incoraggiato a prenderlo in considerazione, ma fino ad ora mi è mancato il coraggio. C'è qualche altro coraggioso "programmatore-fai-da-te" che vuole condividere con me l'avventura dell'esplorazione? Aggiorno la firma per attivare il ping. --Alex brollo (disc.) 15:54, 15 set 2016 (CEST)[rispondi]
Domanda sulla finestra di edit a campi orizzontali
@Candalua C'è qualcosa da sistemare nella finestra di edit nsPagina, versione a campi orizzontali sovrapposto piuttosto che affiancati; il problema è che il campo di edit è troppo alto e nel visualizzare le ultime righe in basso si "perde" l'immagine che scorre verso l'alto. Bisognerebbe ritoccare l'altezza della finestra di edit, ma solo in questa particolare visualizzazione, altrimenti (modificando l'altezza della cella di edit in Preferenze) resta "bassa" anche nella normale visualizzazione affiancata. Avete incontrato il problema anche voi? Qualcuno ha una soluzione, possibilmente via css "differenziale"? Lo script che alterna le visualizzazioni è accessibile o è centrale? --Alex brollo (disc.) 15:52, 15 set 2016 (CEST)[rispondi]
lo script fa ovviamente parte della ProofreadPage Extension, direi che è la funzione toggleLayout() di ext.proofreadpage.page.edit.js. Basterebbe modificare la dimensione della casella impostando il css #wpTextbox1 { height: 10em; } (e ripristinandolo nell'altro caso). Nessuno se la sente di lanciarsi a creare una patch? :D Sennò possiamo chiedere a Tpt. Tra l'altro nella visualizzazione "normale" io allungherei la casella, mi pare che le immagini siano sempre decisamente più corte (almeno sul mio pc). Can da Lua (disc.) 11:52, 16 set 2016 (CEST)[rispondi]
@Candalua Nel frattempo ho ideato questo rappezzo:
Sarà pure brutto ma funziona (scatta nella visuualizzazione orizzontale, come si clicca sulla barra di scrolling, ossia al momento giusto). --Alex brollo (disc.) 16:01, 16 set 2016 (CEST)[rispondi]
Aperto un bug (attività che mi mette sempre in grande agitazione, per favore integrate/precisate/verificate se avete confidenza con quell'ambiente, e datemi feedback di eventuali svarioni!): https://phabricator.wikimedia.org/T145923
Non ho portato al 100% Il Trentino/Prefazione perché la sezione note non viene formattata correttamente e nei capitoli successivi è ancora peggio. Ho visto che <page ...> è diverso dal solito. Si tratta di una versione sperimentale? --BluesBrothers (disc.) 15:05, 16 set 2016 (CEST)[rispondi]
@BluesBrothers E' una sintassi diversa (contiene quel "header=1") che viene usata in particolare da fr.source e che abbiamo provato a sperimentare qui. Purtroppo perché funzioni appieno sono necessarie delle modifiche al nostro layout di pagina, per cui al momento è meglio non usarla. Quindi togli pure header=1 e mettici IncludiIntestazione come di consueto. Can da Lua (disc.) 15:38, 16 set 2016 (CEST)[rispondi]
Il tl|Wikidata list
Una cosa un po' astratta, mi è stata segnalata in telegram nel gruppo wikipedia; in pratica, un template (anzi una coppia di template) che fa da "interfaccia" per un bot, il quale restituisce (come wikitesto) nella pagina il risultato della query su wikidata, contenuta nei parametri del template. Il template non viene sostituito, il wikitesto viene "intercalato" nello spazio racchiuso fra la coppia di template, e viene aggiornato ogni 24 ore circa.
Modello wikidata attualeModello wikidata pre-elaboratoRipesco una vecchissima (2104) discussione nel bar di wikidata: d:Wikidata:Bar/Archive/2014/02#Modello_stella_e_modello_bengala. Ipotizzavo, per il "modello bengala", un bot che tenesse aggiornata una "copia locale" dei dati nei progetti locali (già semplificati, tradotti, ecc), da cui pescare con grande semplicità. Ebbene, il sistema wikidata list fa proprio questo! Il "modello bengala", volendo, può essere implementato e testato. Le due immagini storiche che avevo preparato e pubblicato in quel vecchio post, a destra. I tratti rossi sono le connessioni fra progetti e wikidata, i tratti verdi (usando wikidata list) sono le connessioni fra le pagine di un progetto e la pagina che contiene wikidata list. --Alex brollo (disc.) 09:51, 20 set 2016 (CEST)[rispondi]
Ho proposto a Magnus di includere il codice wiki della lista, prodotto dal bot, in una section. Di rimando, mi ha confermato che è una cosa facilissima, ed anzi che può inserire in specifiche section ogni sezione della lista (opzionalmente la lista può essere suddivisa in "blocchi").
Se e quando Magnus lo farà, allora noi potremo produrre una lista in una pagina dedicata a una specifica query, e poi transcludere il risultato (o parti del risultato) per quante volte vorremo in qualsiasi pagina dove lo vorremo. Non solo: supereremo anche l'attuale limitazione "una query per pagina", perchè nulla impedirà di transcludere nella stessa pagina il risultato, o sezioni dei risultati, di query provenienti da diverse pagine. Ma anche senza questo "sezionamento", potremo usare un modulo Lua (sul tipo di Modulo:ParseTemplate) per analizzare gli item della lista e pescare da questa lista qualsiasi dato singolo vorremo, molto più semplicemente (e immagino anche con una notevole efficenza) qualsiasi dato che la lista conterrà. Il tutto senza studiarci la sintassi delle query, che resteranno un "compito per specialisti". Notate la differenza con quello che avviene adesso; in nsAutore, ad esempio, i dati provenienti da wikidata sono effettivamente visualizzati, ma non esistono nel codice wiki, e per usarli altrove occorre richiamarli di nuovo da wikidata; estraendoli da una tabella che li contiene come codice wiki fisicamente presente nella pagina, tutto cambia, diventano "nostri". --Alex brollo (disc.) 22:20, 20 set 2016 (CEST)[rispondi]
Penso che questo caso vada segnalato ad Alex brollo, l'autore del nuovo template {{RaccoltaNew}}, a cui Raccolta si appoggia.
@Alex brollo Che sia il caso di dare priorità a quanto indicato manualmente dagli utenti e poi a Wikidata, invece che l'opposto come ora? Ammetto però che l'idea del database centrale unico a cui attingere mi aggrada assai. :-) --L0ll0 (disc.) 18:05, 2 dic 2016 (CET)[rispondi]
Modulo dati non funziona?
Seguendo l'ottima Guida, ho provato a creare una pagina indice usando il modulo dati. Ma premendo sul link "Importa Dati" nella sidebar degli Strumenti, non succede niente anche dopo diversi minuti. Quale può essere il problema?
Due idee, entrambe parenti di eis (grazie a chi lo usa! E' per me un'enorme soddisfazione!):
ris, Read In Sequence. Intanto che il lettore di nsPagina legge una pagina, un processo asincrono potrebbe caricare html e immagine della pagina successiva; al click su "prossima pagina" la visualizzazione potrebbe essere istantanea;
miglioramento di eiv (Edit In View):
spostamento del cursore nel box di edit esattamente dove sta nella pagina in view al momento del lancio di eiv;
possibilità di memorizzare modifiche multiple prima di salvare il codice wiki modificato.
Sembra che i dati ci siano ancora (la pagina pesa ancora più di 6 KB), ma non siano riconosciuti dal sistema che quindi mostra quel blob. Siccome però la pagina indice non è una pagina wiki "classica" i dati grezzi non sono modificabili dagli utenti comuni per cui bisogna sentire da qualche amministratore. @Candalua, OrbiliusMagister sapete dare qualche info in più al riguardo? --L0ll0 (disc.) 11:09, 27 mag 2017 (CEST)[rispondi]
La cronologia mi sembra chiara: nel 2012 c'è stata una modifica di Alebot che ha rimosso quasi tutto il contenuto. Ho ripristinato usando l'ultima versione buona. Quello che non mi spiego è come abbiamo fatto a non accorgercene per 5 lunghi anni... Can da Lua (disc.) 17:41, 27 mag 2017 (CEST)
Mi viene il dubbio però che la diff non stia funzionando bene, vedo una rimozione di testo ma non una corrispondente variazione in dimensione. Can da Lua (disc.) 17:54, 27 mag 2017 (CEST)[rispondi]
@Silvio Gallio sembra lo stesso problema, ma nel tuo caso è ancora peggiore: negli altri indici sono riuscito a recuperare il testo da una versione vecchia della pagina, nel tuo invece qualunque revisione sembra contenere solo la stringa "{{:MediaWiki:Proofreadpage_index_template\n}}" e null'altro. Ovviamente ciò è implausibile, quindi senz'altro c'è qualche malfunzionamento in corso. Però ho provato con altri indici e funzionano. Quindi la cosa sembra essere randomica. Can da Lua (disc.) 11:29, 29 mag 2017 (CEST)[rispondi]
Ho trovato un elemento in comune: tutti gli indici corrotti sembrano essere stati creati o modificati circa nel 2011/2012. Gli indici creati dopo questa data non sembrano invece danneggiati. La mia ipotesi è che intorno al 2011 ci sia stata qualche anomalia che ha causato degli edit "non buoni", ma che in qualche modo venivano ugualmente "tollerati" dal sistema. Di recente invece è avvenuto qualche altro cambiamento che fa sì che queste vecchie modifiche non siano più "accettate" (non saprei come esprimermi meglio). Can da Lua (disc.) 11:44, 29 mag 2017 (CEST)[rispondi]
Uno? Chissà quanti saranno. Bisognerà controllare i 1500 indici uno per uno. Intanto inizio a segnare qui quelli che ho trovato e che sono stati almeno parzialmente sistemati. A volte non è stato possibile recuperare tutte le informazioni, in particolare l'indice sommario. Can da Lua (disc.) 12:17, 29 mag 2017 (CEST)[rispondi]
@Candalua Intervengo solo ora, mi ero "perso" la discussione. Me ne sono accorto per la prima volta in Indice:Strade ferrate nello Stato Pontificio.djvu che ho editato normalmente per aggiustare il pagelist, sembrava tutto ok, poi d'improvviso si è rotto in modo non recuperabile (scomparso/inaccessibile anche il codice wiki in cronologia). Vinti i sensi di colpa (cos'ho combinato) ho rabberciato, ma poi è successo di nuovo su altri indici. Recuperando dalla cronologia, quando si può, ho notato la perdita del numero di pagina da visualizzare come thumb, che adesso si inserisce con un menu popup e non più con codice.
Proverò a leggere via bot il codice delle versioni precedenti, eventualmente si dovrebbe poter fare un controllo massivo di parsing del codice attivo, sempre via bot. Mi pare impossibile che siano riusciti nell'impresa di cancellare i codici wiki dalla cronologia! --Alex brollo (disc.) 15:40, 29 mag 2017 (CEST)[rispondi]
Io sto leggendo ma posso solo dire: "Questo MI SEMBRA ok o meno"...Non mi pare un grande aiuto. sob! Noto peraltro che lavori ferroviari sono massicciamente presenti... ri-*sob! Se posso fare altro ditemi cosa e come. Gli indici "Sistemati da ricontrollare": ho dato un'occhiata random mi sembrano Ok con qualche piccola grattatina da dare (tipo i template Pt (vedi più sotto) che immagino preesistenti --Silvio Gallio (disc.) 16:08, 29 mag 2017 (CEST)[rispondi]
@Silvio Gallio, Alex brollo da quel che sappiamo finora, il problema dovrebbe essere limitato alla pagina Indice e non alle pagine Pagina. Quello che a volte è andato perduto nella "ricostruzione" sono ad esempio l'editore, la città, la qualità 75%-100%, il pagelist, più il template Indice sommario (a cui possiamo a fin dei conti rinunciare, se il testo ns0 è già stato creato — mi dispiace solo che OrbiliusMagister si era fatto un bel mazzo a suo tempo per compilarlo...). Dove non è possibile recuperare, temo che non rimanga altro che reinserire le informazioni daccapo... e purtroppo nei corrotti "irrecuperabili" ce ne sono molti sulle ferrovie. Una bella beffa. E meno male che nel mondo wiki dicono che "è tutto in cronologia, è impossibile perdere informazioni..." e invece anche interrogando una revisione specifica, ecco il risultato :( Can da Lua (disc.) 20:01, 29 mag 2017 (CEST)[rispondi]
Scoperta importante: a volte c'è una revisione "buona" in mezzo ad una serie di revisioni "cannate". Quindi a volte, anche se la più vecchia è corrotta, cercando bene se ne trova una recuperabile. Can da Lua (disc.) 20:43, 29 mag 2017 (CEST)[rispondi]
AAARGH! In questo periodo sono presissimo dalla RL. Quest'ultima scoperta mi getta nello sconforto di non poter aiutare. Portate pazienza, se ho due minuti avrete notato dai miei edit che prendo una pagina a caso e rileggo. εΔω07:26, 30 mag 2017 (CEST)[rispondi]
@Alex brollo per te sarebbe abbastanza facile realizzare un "visualizzatore di indici", cioè una specie di vis che mi carichi il primo indice in ordine alfabetico, e con due freccie mi faccia navigare avanti e indietro (magari facendo un purge prima)? Can da Lua (disc.) 18:08, 30 mag 2017 (CEST)[rispondi]
@Candalua Sto battendo una strada diversa: ho scaricato il dump ed estratto tutti i codici wiki di tutti gli indici. Ci sono. Per ora come xml grezzo, ma ci sono. Domani è un'altra sera....79.31.237.19300:50, 31 mag 2017 (CEST)[rispondi]
Ottimo! Comunque io non pensavo solo a questa emergenza: in generale credo sarebbe utile uno strumento di "monitoraggio" degli indici, tipo per uniformarli tra loro (molti non hanno l'indicazione della fonte, per esempio), oppure per valutare l'avanzamento del lavoro. Can da Lua (disc.) 10:45, 31 mag 2017 (CEST)[rispondi]
dall'elemento text dell'xml dal dump con queste modifiche del testo:
normalizzazione delle entità html
eliminazione dell'area dati
eliminazione del template Indice pagina
conversione in numero del campo Immagine
L'elemento critico bloccante è Area dati; il tentativo di salvare il testo con l'Area dati fallisce silenziosamente senza alcun messaggio di errore, e qui sta un grosso errore dei "piani alti", evidentemente Area dati è una follia italsourciota che non si sono immaginati.
PS: anche BrolloBot, leggendo il testo di un Indice corrotto, trova solo un template MediaWiki:Proofreadpage_index_template vuoto, quindi tutti gli indici corrotti possono essere individuati via bot. Mi sembra prudente bloccare immediatamente lo script di aggiunta di Area dati in editing, se non è stato fatto, e rimuovere Area dati da tutte le pagine Indice esistenti, se per combinazione qualche pagina la contiene ed esiste ancora. Ce la fai Candalua ad ammazzare lo script che aggiunge Area dati? Io non ce la faccio a cercarlo adesso! --Alex brollo (disc.) 07:25, 31 mag 2017 (CEST)[rispondi]
@Alex brollo questa è un'ottima notizia. Di quando è l'ultimo dump? Anch'io sospettavo di areadati, in particolare il fatto che inizialmente la mettevamo all'inizio del wikitesto. Probabilmente è questo che ha "sporcato" le pagine, mentre quelle create in seguito con l'areadati dentro il campo "Volumi" sono rimaste "pulite". Ora avranno introdotto qualche parser più restrittivo, e quindi ciaone. Ormai mi pare che la strada intrapresa dai piani alti sia chiara: validazioni e controlli sempre più "strict" e sempre meno spazio alla... chiamiamola "creatività". Quindi temo che tu abbia ragione: è il momento di mandare in pensione l'areadati, inutile rimandare. Stacco lo script da Common.js. Can da Lua (disc.) 10:41, 31 mag 2017 (CEST)[rispondi]
@Candalua 20 maggio, penso di aver usato quello, verificherò (in realtà ho fatto solo un affrettato test, ho dovuto anche ricostruire il "lettore di dump" di anni fa, perduto da qualche parte). L'attuale script lettore è un fulmine, in pochi secondi si passa, linea per linea, quasi un giga di testo xml.... ovviamente trattato come puro testo (altro non so fare).
per qualche motivo il software si rifiuta, da un certo momento in poi, di salvare pagine Indice in cui ci sia robaccia prima del template canonico
per un errore nel sistema di notifica errori, il sistema NON comunica il mancato salvataggio con un messaggio di errore.
gli indici recenti o recentemente editati non hanno più la robaccia bloccante.
CandalBot parte e fa un giro correggendo il numero pagina immagine e cavando Indice pagina. Lascia il resto com'è, robaccia compresa, e salva (crede di salvare). In realtà carica un template perfettamente vuoto. Questo accade solo negli indici vecchi, che non siano mai stati editati, e avviene in perfetto silenzio.
rimedio: cercare nel dump tutti gli indici con robaccia prima del template, ed eliminarla; fare anche le correzioni che avrebbe fatto CandalBot, se ci fosse riuscito; ricaricare. Alex brollo (disc.) 15:44, 31 mag 2017 (CEST)[rispondi]
Secondo me è un po' diverso: la robaccia non impedisce il salvataggio in sè (infatti al passaggio di CandalBot la dimensione non è diminuita di molto, e la modifica sono certo che funzionava). Probabilmente prima il wikitesto veniva semplicemente processato come avviene sulle pagine ns0, e veniva sparato fuori l'html qualunque esso fosse; mentre ora viene "validato" secondo il modello della pagina (proofread-index), quindi se c'è qualcosa di sporco la validazione fallisce miseramente e la pagina appare come fosse vuota. E anche la diff non mostra più quelle differenze che secondo il modello pagina "non esistono" (ma la dimensione della pagina invece ne risente). Forse il dump che hai è precedente agli ultimi passaggi di CandalBot. Comunque, ormai fa poca differenza. :( Can da Lua (disc.) 16:06, 31 mag 2017 (CEST)[rispondi]
┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ @Candalua BrolloBot lanciato. Dovrebbe essere in grado di riconoscere gli indici fallati e recuperarli. Alex brollo (disc.) 20:37, 31 mag 2017 (CEST)[rispondi]
Da vero babbeo, ho lavorato esclusivamente con funzioni volatili, da IDLE, non salvate.... la procedura è comunque abbastanza semplice, dovrei ricostruirla, fammi fare un paio di prove, vediamo. Alex brollo (disc.) 19:43, 1 giu 2017 (CEST)[rispondi]
@Candalua Non avevo ancora chiuso Idle, ho recuperato gli script e li ho fatti correre (filtrandoli per utente Candalua). Spero bene, non ho visto disastri. Restano gli Indici corrotti corretti manualmente da altri. Sei in grado di farmene un elenco? Alex brollo (disc.) 21:47, 1 giu 2017 (CEST)[rispondi]
┌────────────────────────────────────────────────────────────────────────────────────────────────────┘Tutto è bene quel che finisce bene! Certo questa è una dura lezione: non solo ai piani alti Wikisource non è particolarmente amata, ma a maggior ragione le soluzioni locali (anche efficaci) sono scoraggiate sempre più esplicitamente. Prendiamone atto. εΔω08:48, 2 giu 2017 (CEST)[rispondi]
Se ricordate, tempo fa avevo debolmente proposto di "normalizzare" completamente la pagina Indice e di utilizzare gli automatismi canonici previsti dall'estensione proofread, ma la proposta è stata giudicata troppo forte. A suo tempo potremo ripensarci. Alex brollo (disc.) 11:53, 3 giu 2017 (CEST)[rispondi]
@Alex brollo, OrbiliusMagister ieri sera ho ricontrollato il tuo "secondo giro" di correzioni, sistemando le varie minuzie rimaste; non trovo altri problemi. Temo che prima o poi ci toccherà passare all'uso di header=1... al momento l'ostacolo è che va cambiato il layout sennò si rompe. Non so se avete fatto caso a Speciale:LintErrors che è comparso da qualche tempo... il warning che ricorre in quasi tutte le pagine è "Missing end tag", che deriva proprio dal fatto che il nostro template Intestazione lascia aperto un div in modo da creare il layout "a colonna centrata". Per il momento sono solo warning, ma prima o poi... Can da Lua (disc.) 09:50, 6 giu 2017 (CEST)[rispondi]
@Candalua Condivido due cosette su Lua, che sono state, per me, delle novità (magari sono vecchie come il cucco...) e su cui si può fare qualche pensata.
la lettura, da Lua, del codice di una pagina qualsiasi non è più "server-espensive" ma equivale a una semplice transclusione;
esistono due funzioni per la codifica e decodifica JSON.
Dal punto di vista operativo, questo significa che eventuali dati locali possono essere codificati e salvati in JSON (e quindi in un formato di puro testo facilmente leggibile sia da Lua che da Javascript, il che non guasta) memorizzandoli in semplici pagine testo facilmente leggibili sia da Lua che da javascript e scrivibili via javascript. --Alex brollo (disc.) 06:28, 21 giu 2017 (CEST)[rispondi]
Verso un algoritmo per la evidenziazione nel testo delle parole ricercate
Ho scoperto che dato un testo t e dati a e b (due stringhe), si può ottenere la sostituzione di tutti gli a con b dentro t con questa semplicissima istruzione:
t=t.split(a).join(b);
Se t è html, si può applicare l'istruzione 1 senza modificare alcun tag html (ossia, agendo solo sui nodi txt) usando l'html "codificato" in cui tutti i tag html sono stati sostituiti con un codice, analogamente a quanto già eseguito per unisciLionee o apostrofi.
In breve: siamo vicini alla possibilità di evidenziare nel testo visualizzato lr parole ricercate, la prima applicazione sarà in vis, ma poi la cosa potrà essere generalizzata. --Alex brollo (disc.) 13:13, 2 lug 2017 (CEST)[rispondi]
No, no, non sfuggimmi. Come a te non sarà sfuggito che ti avevo detto che sarei stato lontano dai computer fino lunedi. Invece ho problemi con l'auto e quindi sono fermo e quindi ti scasso i. Poi non so cosa sarà di me, non mi preoccupo e spero non preoccuperà te pure. Non ti sarà sfuggito che ho buttato due righe da qualche parte a bar, appunto perché appiedato. Nondimanco la mia richiesta non è pro domo mea in quanto, come certo non ti è sfuggito, pascolo qui solo occasionalmente, ritengo infatti che sia fonte di comodo e felicità per altri (spero molti). Un saluto impressionato. Silvio Gallio (disc.) 16:32, 2 lug 2017 (CEST)[rispondi]
Classe wl
Tl|Wl adesso inserisce un codice span di classe class="wl", chi vuole e sa come farlo può cominciare a pensare a uno script che, avendo a disposizione il QID, può "fare cose" a seguito di un click su un elemento della classe. Alex brollo (disc.) 18:37, 10 set 2017 (CEST)[rispondi]
Modulo dati non funziona? (2, la vendetta)
Non mi sono mai sentito cosí tanto niubbo! Perdonatemi. Ripeto paro paro la domanda di Pepato del 16 feb 2017.
Seguendo l'ottima Guida, ho provato a creare una pagina indice usando il modulo dati. Ma premendo sul link "Importa Dati" nella sidebar degli Strumenti, non succede niente anche dopo diversi minuti. Quale può essere il problema?
L'opera a cui mi riferisco è questa (una robetta piccola giusto per imparare, ma totalmente inedita e scansita - ok, maluccio - personalmente nella mia biblioteca)
Forse più che un problema è un equivoco. Modulo:Dati serve per alcuni automatismi, in particolare per "alimentare" il template Pg, e a poco altro. Cosa, di preciso, vuoi ottenere? --Alex brollo (disc.) 23:50, 6 nov 2017 (CET)[rispondi]
wkhtmltopdf
@Candalua, Ricordisamoa Non sono lettere a caso, quelle del titolo, ma i pingati lo sanno..... qualcuno di voi conosce wkhtmltopdf, tool a linea di comando per la trasformazione da html in pdf? Oppure, qualcuno conosce altre applicazioni, sempre a linea di comando, per fare la stessa trasformazione? Mi "punge vaghezza" di costruire il pdf che vorrei - tratto da nsPagina, pagina per pagina, e intravedo che uno strume nto del genere me lo consentirebbe. --Alex brollo (disc.) 23:43, 6 nov 2017 (CET)[rispondi]
Da xml a dsed
Ho il piacere che sono sul punto di riuscire a convertire i file _djvu.xml (strato testo in formato xml, molto ostico) in file "dsed" (molto compatti e molto maneggevoli). Lo so che forse non vi entusiasmerete, è un tecnicismo un po' spinto, ma io sono anni che ci tento senza successo.... Dal punto di vista pratico, questo consentirà il "trapianto di strato testo" più rapido e sicuro dai file _djvu.xml di Internet Archive a file djvu senza strato testo, ad esempio nei casi di caricamento fallito con IA Upload (in cui il punto critico è proprio il maneggiamento dell'odioso _djvu.xml). --Alex brollo (disc.) 09:27, 4 dic 2017 (CET)[rispondi]
Ce l'ho fatta, ma solo per verificare che il famoso bug "text hierarchy corrupt" si ripresenta nella pagina 251 (il testo del file _djvu.xml, tentando l'inserimento nel file djvu, produce l'errore nonstante che il file xml che il file dsed derivato siano apparentemente perfetti). Trattasi di mistero misterioso; da verificare se l'errore si ripete con detail line. Ipotizzo che una certa sequenza di caratteri confonda bzz. --Alex brollo (disc.) 22:49, 4 dic 2017 (CET)[rispondi]
Ho ripreso in mano jp2todjvu.py, progenitore dello script di IA Uploader per i djvu da costruire; superato il promo disorientamento ("ma questa roba chi l'ha scritta???") dovrei riuscire a montare la nuova strategia di caricamento testo, se andrà bene come spero inoltro a "quelli bravi". --Alex brollo (disc.) 12:52, 6 dic 2017 (CET)[rispondi]
Fatto, vedi Progetto:Bot/Programmi in Python per i bot/xml2dsed.py, che trasforma il _djvu.xml di Internet Archive nel più maneggevole "formato dsed", eventualmente adattandolo a variazioni delle dimensioni pagina, e lo carica nel djvu; corregge anche (per ora svuotandole del testo) le occasionali pagine con "strato testo corrotto". La prospettiva interessante è di convertire in "formato dsed" anche l'output hOCR di tesseract, dopodichè sarà possibile ottenere file djvu con OCR in totale autonomia, con programmi liberi e con un singolo comando python.
@Candalua, OrbiliusMagister Il "salatore" ha alcune caratteristiche che ne permetterebbero una generalizzazione e interessanti applicazioni.
Il sistema funziona così:
dall'html della pagina Indice estrae tutti i titoli delle pagine comprese in .pagineDellEdizione (prodotti da pagelist), salatore li filtra per .quality3 ma è un dettaglio specifico (selezione primaria);
si esegue una batteria di chiamate api query, a blocchi di 50 pagine al colpo, ottenendo il wikitesto di tutte le pagine;
il wikitesto viene esaminato e si crea una lista delle pagine che soddisfano un certo criterio (per salatore l'unica dato rilevante è il user= contenuto nell'header del testo pagina) e fa qualcosa per le pagine che soddisfano il criterio;
terminate tutte le chiamate asincrone (sudore! O_o) il nome base della pagina e la lista dei numeri pagina che soddisfano il criterio viene salvata in localStorage.salatore.
ai link alle pagine in Indice si aggiunge un target in modo che la pagina si apra, dopo click, in un'altra scheda (quindi la pagina Indice trattata" resta aperta).
Cambiando i criteri di selezione primaria e i criteri di filtraggio in base ai dati restituiti dalla query (che sono numerosissimi, oltre al wikitesto) lo stesso meccanismo potrebbe essere usato per fare "molto altro" e perfino, con somma cautela, per modificare massivamente il contenuto delle pagine selezionate. --Alex brollo (disc.) 09:44, 18 dic 2017 (CET)[rispondi]
Questo ciò che viene salvato in localStorage.salatore:
La struttura permette quindi di salvare altri set di pagine selezionate in base a criteri diversi; un criterio di selezione potrebbe essere il controverso SAL 50% (desumibile facilmente dalla sola analisi della pagina Indice) Alex brollo (disc.) 09:49, 19 dic 2017 (CET)[rispondi]
@OrbiliusMagister, Candalua Pingo solo voi come rappresentanti dei possibili interessati: gli utenti "gestori" e gli utenti"sviluppatori". Ci siamo; adesso, in pagina Indice, il click sull'incona per visualizzare i "SAL 75% promuovibili" genera o rigenera anche l'elenco di tutti gli utenti che hanno contribuito all'ultimo livello SAL + tutti gli utenti che hanno fatto l'ultima modifica in qualsiasi pagina dell'Indice. Naturalmente sarebbe bello disporre anche dell'elenco di tutti gli utenti che hanno, comunque, contribuito in cronologia di ciascuna pagina, ma questo richiederebbe una elaborazione molto, molto più pesante.
Naturalmente non ho fatto in modo che le pagine attribuibili ai vari utenti fossero contate: sarebbe stato possibile ma non mi piace, sapete che detesto la competitività.
Al momento la lista è semplicemente salvata in localStorage.contributors, vorrei un suggerimento su dove/come salvarla, sempre che sia il caso di salvarla. --Alex brollo (disc.) 07:39, 31 gen 2018 (CET)[rispondi]
Magari non sempre, ma sarebbe utile (ritengo) arrivare (anche) alla lista completa. E sarebbe utile che fosse ben inchiodata, amalgamata nel file quando dal testo se ne trae un epub o simile. Così che almeno chi usa il lavoro ne "paghi" le conseguenze... --Silvio Gallio (disc.) 08:18, 31 gen 2018 (CET)[rispondi]
@Silvio Gallio Eh, lo so... il problema è una questione di "risparmio energetico", rintracciare la cronologia completa di ciascuna pagina richiederebbe una chiamata al server per ciascuna pagina, mentre così le chiamo a blocchi di 50. Lo script diventerebbe quindi 50 volte più "pesante", a meno di trovare un trucco del tutto diverso. Lascio la cosa a "quelli bravi". --Alex brollo (disc.) 11:28, 31 gen 2018 (CET)[rispondi]
Interessante. In effetti, dal mio punto di vista, era più che altro uno sfizio, per cercare di stabilire dei diritti di wikisource (non certo miei) in opere derivate che sono in genere piuttosto "dimenticose" di certe correttezze. Cmq ottimo lavoro, al solito. Ciao! --Silvio Gallio (disc.) 22:34, 31 gen 2018 (CET)[rispondi]
@Luigi62 In effetti un problema c'è: per come è costruito il tool, una sventagliata di chiamate ajax asincrone, l'ordine dei contributori è casuale e cambia ad ogni attivazione dello script, e quindi la pagina viene modificata anche se la lista dei contributori è formata dagli stessi elementi: vedi cronologia. Un rimedio c'è, stasera è tardino e rimando a domani: basterà, prima di scrivere la lista, ordinarla in ordine alfabetico; così se non ci sono variazioni nell'elenco, non ci dovrebbe essere una modifica della pagina. Alex brollo (disc.) 23:40, 5 feb 2018 (CET)[rispondi]
@Luigi62Me smemorato; dal codice vedo che avevo già fatto tutto questo bel ragionamento.... e poi avevo cannato la funzione di ordinamento. Adesso dovrebbe essere sistemato. Alex brollo (disc.) 06:12, 6 feb 2018 (CET)[rispondi]
@Luigi62 Verifica anche tu, a me il problema sembra risolto: se la lista dei contributori non ha subito modifiche, adesso lo script non carica più una nuova versione della pagina in cronologia. Lo farà una volta sola, nelle vecchie liste, per mettere i contributori in ordine alfabetico. Alex brollo (disc.) 09:40, 7 feb 2018 (CET)[rispondi]
@Candalua Un template terribilmente complesso, per risolvere un problema effettivamente complesso: gli alberi genealogici. Occorrerebbe verificare se qualche altro progetto ha soluzioni più semplici, in caso contrario: lo importiamo? --Alex brollo (disc.) 23:19, 2 feb 2018 (CET)[rispondi]
Modifiche di eis
all'atto della creazione di una pagina il SAL viene adesso impostato a 25%
spostandosi su una pagina diversa vengono adeguati al nuovo numero pagina:
Buongiorno a tutti.
Sono interessato soprattutto alla versione "semplice testo" dei documenti pubblicati da Wikisource per eseguire delle elaborazioni successive.
Ecco, per esempio, un frammento di Pandolfo Collenuccio, Canzone alla morte nella versione "semplice testo":
+++
Q
UAL peregrin nel vago errore stanco
+++
che ho dovuto correggere in:
+++
Qual peregrin nel vago errore stanco
+++
Mi domando perché conservare nel "semplice testo" residui del formato tipografico (in questo caso il capolettera).
In generale, le proprietà di stile non andrebbero sempre rigorosamente separate dal "semplice testo"?
Grazie. (post non firmato di ProtoMeandro)
Il quesito andrebbe rivolto ai "piani alti" come diciamo in gergo (gli sviluppatori di mediawiki), i tool di esportazione non sono sotto il notro controllo. Noi abbiamo fatto uno sforzo perchè il "testo semplice" che si ottiene semplicemente selezionando il testo e ricopiandolo su text editor sia corretto, e lo è, tranne il fastidio costituito dal numero dei versi:
QUAL peregrin nel vago errore stanco
De’ lunghi e faticosi suoi viaggi
Per lochi aspri e selvaggi,
4Fatto già incurvo per etate e bianco,
Al dolce patrio albergo
Sospirando s’affretta e si rimembra
Le paterne ossa e la sua prima etate:
8Di sè stesso pietate
Tenera il prende; e le affannate membra
Posar disía nel loco ove già nacque,
E il buon viver gli piacque:
. Ugualmente corretta una estrazione del testo via jQuery dagli elementi .poem (in questo caso specifico). Come i "piani alti" abbiano creato il tool di esportazione "txt", non ne ho idea. --Alex brollo (disc.) 17:06, 12 feb 2018 (CET)[rispondi]
Grazie. Effettivamente il copia e incolla funzione. Solo che, per testi lunghi, su più capitoli, diventa gravoso. Anche la prosa crea problemi. Questo è un esempio tratto dalle favole di Esopo:
Due giovani comprarono insieme da mangiare da un cuoco, ed essendo il cuoco in certi altri negozj occupato, un di quei [p. 101 modifica]giovani pigliò un pezzo di carne, e lo diede all’altro.
Si possono usare le espressioni regolari, per purificare il testo, ma mi resta la curiosità di sapere perché i "piani alti" trattino in questo modo il testo semplice.
@Candalua, Ricordisamoa Una "funzione che funziona", ma molto grossolana (non risistema la posizione del cursore) è la seguente:
mw.toolbar.insertTags=function(pre,post) {
var t=selection();
t[1]=pre+t[1]+post;
$(mw.activeElement).val(t.join(""));
return false;
}
Magicamente, quasi tutto torna a posto, i pulsanti che devono "incapsulare" incapsulano ecc., ma continuano a non funzionare i pulsanti del toolbox (tipo grassetto e corsivo) che usano una funzione diversa di incapsulamento, irragiungibile e immodificabile perchè murata viva all'interno di un oggetto creato da una mostruosa funzione anonima.
Quindi il problema non sta nella povera mw.toolbar.insertTags, ma in qualcosa che mw.toolbar.insertTags e quella diversa funzione hanno in comune. A questo punto mi perdo. Però, sotto eis, lancio una volta la ridefinizione della funzione mw.toolbar.insertTags e tutti i miei attrezzi e bottoni funzionano. Non mi pare il caso, comunque, di iniziare a mettere pezze, perchè il bug è così grosso che per forza devono sistemarlo i professionisti, i "developers" :-) --Alex brollo (disc.) 23:52, 15 feb 2018 (CET)[rispondi]
@Ricordisamoa No, il [ https://phabricator.wikimedia.org/T187454 ticket aperto] illustra la dinamica del bug, che non riguardava esclusivamente mw.toolbar; una modifica generale del sistema di selezione del testo fatta per facilitare l'applicazione di VisualEditor; almeno così mi è parso di capire. La cosa più seria però è la mancata emissione di un avviso generale che ammetta l'esistenza del bug in atto causato dalle nuove versioni, e dia indicazioni su come comportarsi, fornendo anche i tempi (approssimativi) della soluzione del problema. Alex brollo (disc.) 15:47, 16 feb 2018 (CET)[rispondi]
Direi di sentire al Bar se qualcuno ha obiezioni. Per me va bene. --Accurimbono (disc) 13:24, 23 mar 2016 (CET)
