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]
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]
@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]
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]
@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]
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]
Direi di sentire al Bar se qualcuno ha obiezioni. Per me va bene. --Accurimbono (disc) 13:24, 23 mar 2016 (CET)
