Wikisource:Domande tecniche

Fine pagina

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.

Premi qui per inserire la tua domanda o la tua osservazione

Stranezza CropTool: serio bug?

@Candalua A margine della triste vicenda Maschere nude, che sembra comunque terminata con un lieto fine, ho notato che nei tre file immagine, caricati via CropToool, il template Book (ricavato dal djvu da CropTool e caricato dal tool a nome dell'utente) risultava monco: mancavano le prime due right del template (il nome del template e l'autore). Avevo notato la stessa cosa in un recente caricamento di TrameOscure ma l'avevo considerato un errore occasionale: invece non lo è, e tempo che il problema riguardi altri caricamenti recenti. Se è così, è un grosso guaio, perchè il template Book non funziona e probabilmente i file caricati sono segnalati da qualche bot di Commons come gravemente carenti di metadati critici. Io cerco di approfondire, ma se dai un'occhiata anche tu sarei più tranquillo. Alex brollo (disc.). 00:23, 21 gen 2025 (CET)

@Alex brollo: vero! Io di solito non uso il template book (e non guardo mai il risultato del crop), quindi non me n'ero accorto, ma l'ha fatto anche a me su alcune immagini, ancora un paio di mesi fa. Prova a segnalarlo qui. Intanto bisognerebbe capire come trovare e sistemare tutti questi file... Can da Lua (disc.) 08:12, 21 gen 2025 (CET)

@Candalua Ok, lo segnalo, grazie del link. Per quanto riguarda i miei caricamenti, il primo della serie dei caricamenti fallati è del 31 dicembre scorso. Ho segnalato il problema anche a User:ShakespeareFan00, pregandolo di indicarmi qualche utente esperto in Commons proprio per ricercare i file fallati (e se possibile correggerli). Alex brollo (disc.). 09:48, 21 gen 2025 (CET)

@Candalua Fatto: qui Mi muovo male su GitHub, ti prego di dare un'occhiata ed eventualmente correggere/integrare. Alex brollo (disc.). 10:18, 21 gen 2025 (CET)

@Candalua Per ora, nessun esito... lo ammetto, sono troppo impaziente :-( Alex brollo (disc.). 12:55, 22 gen 2025 (CET)

@Candalua Scorrendo le numerose immagini croptoolate da Edo, nella serie in problema si manifesta a partire dall'agosto 2024. Tombale silenzio sul post in GitHub. Alex brollo (disc.). 19:40, 29 gen 2025 (CET)

Croptool è quasi abbandonato: basti vedere il salvataggio in extremis fatto nel febbraio 2024 durante il passaggio da Grid Engine a Kubernetes (phab:T319653), e le relative lamentele su Commons, come c:Commons:Village_pump/Archive/2024/01#Is someone willing to step up and salvage CropTool? --ZandDev (disc.) 02:34, 28 mar 2025 (CET)

Peccato, è molto comodo anche se ha IMHO due grossi problemi:

• non permette di salvare l'immagine per elaborarla prima di caricarla
• salva solo in jpg, oltretutto senza alcuna possibilità di personalizzare i parametri.

Sono due cose che penso si potrebbero fare facilmente. L'ottimale sarebbe anche avere qualche minimo tool di elaborazione delle immagini, ma si va in coding più complesso. -- TrameOscure (disc.) 21:57, 1 apr 2025 (CEST)

@Alex brollo, @Candalua, mi pare che qualcosa sia stato fatto negli ultimissimi giorni perchè ora il tmpl book viene messo per intero. 🎉 --TrameOscure (disc.) 17:17, 20 apr 2025 (CEST)

Bene! Resta comunque il fatto che il miglior uso possibile di CropTool, secondo me, è fargli fare quello che fa bene (eventuale rotazione, ritaglio e salvataggio su Commons), e immediatamente andare su Commons e ritoccare quello che va ritoccato, sia nella pagina testo che nell'immagine. Alex brollo (disc.). 17:23, 20 apr 2025 (CEST)

@Alex brollo certamente. In genere aggiungo/correggo didascalia e categorie (es.), visto che quelle di default non sono molto utili per un uso generalizzato del file. TrameOscure (disc.) 17:56, 20 apr 2025 (CEST)

@TrameOscure In genere io eseguo anche una conversione in toni di grigio e poi una regolazione dei livelli in modo da ottenere un fondo bianco per le immagini che in originale erano fatte con inchiostro nero su carta bianca. Fra i tanti programmi disponibili mi sono affezionato a XnView. Alex brollo (disc.). 22:17, 20 apr 2025 (CEST)

@Alex brollo, certo!, è esattamente quello che vorrei fare su una marea di immagini caricate tal-quali da altri e il motivo per cui ho chiesto il flag di autopatrolled, visto che chiedere i permessi immagine per immagine (coi tempi biblici di risposta dai 4 gatti di Commons) fa perdere troppo tempo.

Purtroppo poi vanno risalvate come jpg anche quando ha poco senso, ma convertirle in png sarebbe troppo un casino senza una procedura automatizzata per sostituirle anche in giro per le wiki. Sarebbe molto più semplice se CropTool facesse scegliere ab origine fra jpg e png... scartabellando github mi sembra pure che il supporto interno ci sia... -- TrameOscure (disc.) 10:05, 21 apr 2025 (CEST)

Aggiornamento: negli ultimi giorni ho [croppato] molte immagini di Indice:Yambo - Manoscritto trovato in una bottiglia, Roma, Scotti, 1905.pdf, senza notare alcun problema. Ora ho croppato una img da Indice:Le vite de i dodeci visconti che signoreggiarono Milano.djvu e di nuovo manca un pezzo del template {book} :-( In effetti nelle altre img di Yambo non viene messo... e al posto c'è un {information} funzionante. Non so se questo aiuta qualcuno nel debug del problema. --TrameOscure (disc.) 16:52, 13 mag 2025 (CEST)

@TrameOscure: il segreto per far sì che non si rompa il template Book è... non mettere il template Book! Can da Lua (disc.) 18:29, 13 mag 2025 (CEST)

@Candalua eh! ma lo mette croptool - rotto - mica io! :p TrameOscure (disc.) 18:46, 13 mag 2025 (CEST)

@TrameOscure: croptool non se lo inventa, lo prende dalla pagina del pdf/djvu. Can da Lua (disc.) 19:14, 13 mag 2025 (CEST)

Problema esportazione in pdf

@Candalua @Paperoastro L'esportazione in pdf mi rovina una delicata tabella spaccandola in due pagine. Una combinazione sfortunata, perchè è una tabella molto piccola (4 righe). Sapete se c'è modo di evitarlo? O se c'è una pagina dedicata ai casi particolari di esportazione in pdf? Alex brollo (disc.). 19:44, 29 gen 2025 (CET)

Il codice css page-break-inside: avoid; parrebbe essere adatto allo scopo. [1] TrameOscure (disc.) 12:01, 30 gen 2025 (CET)

@Alex brollo Oppure usare il codice css pagebreak per forzare il cambio di pagina prima della tabella. Magari usato dentro un includeonly. (Vedi qui) --Paperoastro (disc.) 12:56, 30 gen 2025 (CET)

Conflitto fra ref e section

@Modafix In questa discussione, Modafix mi ha segnalato che il tentativo di transcludere indipendentemente un pezzo di annotazione, usando il normale tag section, non dà esito (non viene segnalato un errore, semplicemente la transclusione è vuota).

Poichè non sono rari i casi in cui intere poesie sono stampate all'interno di annotazioni, sarebbe bene studiare qualche trucco per eseguire la transclusione senza copiare il testo. Alex brollo (disc.). 14:43, 10 feb 2025 (CET)

SAL 75%->100%

Ho appena scoperto che anche in ns0 se si salva una pagina al 75% non si può portarla al 100%. Sbaglio o è una novità? Cruccone (disc.) 18:27, 14 feb 2025 (CET)

@Cruccone: per portare al 100% il requisito è che ci deve essere un tag pages. Se per qualche motivo la pagina non deve trascludere nulla, ma è comunque parte di un'opera proofread, si può trascludere una pagina allo 0%, oppure una sezione vuota. Can da Lua (disc.) 21:27, 14 feb 2025 (CET)

Problema con tl Nsb

@Candalua Personalmente sono molto soddisfatto di {{Nsb}} ma c'è un piccolo fastidio: manca un link per consentire l'edit dell'annotazione in modo comodo e intuitivo. Aggiungerei al template un po' di codice, in modo da visualizzare (solo in nsPagina) il link alla pagina da cui viene transcluso il testo dell'annotazione. Che me dici? Per analogia con altri casi, lo farei apparire come un piccolo mod blu. Non dirmi che il nome del template fa ribrezzo... perchè lo so già. :-) Alex brollo (disc.). 10:13, 12 mar 2025 (CET)

"Libri" grossi in Villani (troppo...?)

@Candalua @OrbiliusMagister Per ora va tutto fin troppo bene, con Cronica (Villani), con la scelta di transcludere in blocco in ns0 gli interi libri; ma... quelli che ho transcluso sono piccoli rispetto ai successivi, il caso peggiore è il Libro IX nel volume IV. Ce la farà il software a reggere? E se non ce la farà, è accettabile sezionare i libri trpppo grossi in alcune "parti"? Mi ripugna spezzettare i libri in centinaia di sottopagine, una per "capitolo", molte delle quali di poche righe. Alex brollo (disc.). 23:24, 26 mar 2025 (CET)

Tralasciando che lo spezzettamento in sottopagine non è particolarmente vietato, cerchiamo di procedere "a vista": scommetto che Mediawiki reggerà, a condizione che si limiti all'indispensabile il numero dei template. A mia memoria abbiamo già testi che transcludono centinaia di pagine. Stressiamo il sistema e in caso negativo hai già prefigurato un piano B. εΔω 14:44, 27 mar 2025 (CET)

@OrbiliusMagister Grazie, era proprio quello che avevo idea di provare. Le note (se arricchite di AutoreCitato come io trascuro sempre di fare... :-( ) potrebbero essere l'elemento critico; per fortuna sono sempre meno numerose, man mano che si procede. Alex brollo (disc.). 17:49, 27 mar 2025 (CET)

Mi stavo ponendo un problema simile per La_figlia_di_Lady_Rose che è trascluso da pezzi di vari djvu. Per ora sto sostanzialmente "cercando i contorni" del testo, transcludendo solo i capisaldi, cioè inizio/fine delle "puntate" in cui è pubblicato, e capitoli (che non coincidono con le puntate). Non so ancora quanto pesa in totale, ma sarà bello lungo per essere una sola pagina di ns0 come ora. Pensavo -se necessario- di spezzettarlo non tanto capitolo per capitolo ma piuttosto in blocchi di 5 o 10 capitoli per volta a seconda di come verranno fuori. Per cui in ns0 potrebbe esserci un indice che rimanda a capitoli I-X, capitoli XI-XX ecc.

Non tanto per timori che MW non regga (crea la paginona in cache una volta e poi serve quella, ergo non penso abbia problemi prestazionali anche infarcendo di template), quanto più di comodità di fruizione del lettore (scrollare pagine di chilometri è scomodo). --TrameOscure (disc.) 11:20, 28 mar 2025 (CET)

URL delle anteprime

Qualcuno sa spiegarmi come è costruito l'URL delle anteprime dei file di immagine? Cioè, nell'url

https://upload.wikimedia.org/wikipedia/commons/thumb/5/55/Ars_et_Labor%2C_1906_vol._I.djvu/page236-500px-Ars_et_Labor%2C_1906_vol._I.djvu.jpg

quel 5/55/ è una cosa random o è predicibile in qualche modo? Perchè per es. per un altro djvu come questo

https://upload.wikimedia.org/wikipedia/commons/thumb/4/4f/Musica_e_Musicisti%2C_1905_vol._I.djvu/page1-500px-Musica_e_Musicisti%2C_1905_vol._I.djvu.jpg

è diverso... a me servirebbe dato un djvu, sapere a priori questo pezzo di URL come è "inventato" da mediawiki. --TrameOscure (disc.) 21:19, 29 mar 2025 (CET)

@TrameOscure: dovrebbero essere i primi caratteri dell'hash MD5 del nome del file. Se calcoli l'md5 di Musica_ecc. dovrebbe uscirti 4f... ecc. Can da Lua (disc.) 22:34, 29 mar 2025 (CET)

@Candalua: Grazie :). Purtroppo ho provato con varie grafie (spazi, _ , %2C, con/senza estensione djvu e jpg, ecc) ma è uscito qualunque numero e lettera, salvo quelli... :D

Vabbè, pazienza, vorrà dire che modifico a mano di volta in volta lo script, poco elegante ma efficace. Ah, si, perchè ovviamente lo scopo era il paciocco che c'è qua in fondo. Che funzionerebbe anche allo scopo se non fosse che i server wikimedia storcono spesso il naso per il numero (peraltro modesto, 10...) di richieste "esterne" (è un file locale sulla mia macchina), e che è allo stato il problema più seccante. --TrameOscure (disc.) 12:36, 30 mar 2025 (CEST)

@TrameOscure: va preso il nome del file compresa l'estensione .djvu, ma esclusa l'estensione jpg (perché quello è solo un file derivato), con gli underscore al posto degli spazi. Ho trovato qui una funzione md5 in javascript puro e l'ho provata con Musica_e_Musicisti,_1905_vol._I.djvu e ritorna 4f5b66fb2eac19fe8ed43f6e557a37a7. Can da Lua (disc.) 11:21, 31 mar 2025 (CEST)

@Candalua Un parallelepipedo di codice illeggibile... :D

var MD5 = function(d){var r = M(V(Y(X(d),8*d.length)));return r.toLowerCase()};function M(d){for(var _,m="0123456789ABCDEF",f="",r=0;r<d.length;r++)_=d.charCodeAt(r),f+=m.charAt(_>>>4&15)+m.charAt(15&_);return f}function X(d){for(var _=Array(d.length>>2),m=0;m<_.length;m++)_[m]=0;for(m=0;m<8*d.length;m+=8)_[m>>5]|=(255&d.charCodeAt(m/8))<<m%32;return _}function V(d){for(var _="",m=0;m<32*d.length;m+=8)_+=String.fromCharCode(d[m>>5]>>>m%32&255);return _}function Y(d,_){d[_>>5]|=128<<_%32,d[14+(_+64>>>9<<4)]=_;for(var m=1732584193,f=-271733879,r=-1732584194,i=271733878,n=0;n<d.length;n+=16){var h=m,t=f,g=r,e=i;f=md5_ii(f=md5_ii(f=md5_ii(f=md5_ii(f=md5_hh(f=md5_hh(f=md5_hh(f=md5_hh(f=md5_gg(f=md5_gg(f=md5_gg(f=md5_gg(f=md5_ff(f=md5_ff(f=md5_ff(f=md5_ff(f,r=md5_ff(r,i=md5_ff(i,m=md5_ff(m,f,r,i,d[n+0],7,-680876936),f,r,d[n+1],12,-389564586),m,f,d[n+2],17,606105819),i,m,d[n+3],22,-1044525330),r=md5_ff(r,i=md5_ff(i,m=md5_ff(m,f,r,i,d[n+4],7,-176418897),f,r,d[n+5],12,1200080426),m,f,d[n+6],17,-1473231341),i,m,d[n+7],22,-45705983),r=md5_ff(r,i=md5_ff(i,m=md5_ff(m,f,r,i,d[n+8],7,1770035416),f,r,d[n+9],12,-1958414417),m,f,d[n+10],17,-42063),i,m,d[n+11],22,-1990404162),r=md5_ff(r,i=md5_ff(i,m=md5_ff(m,f,r,i,d[n+12],7,1804603682),f,r,d[n+13],12,-40341101),m,f,d[n+14],17,-1502002290),i,m,d[n+15],22,1236535329),r=md5_gg(r,i=md5_gg(i,m=md5_gg(m,f,r,i,d[n+1],5,-165796510),f,r,d[n+6],9,-1069501632),m,f,d[n+11],14,643717713),i,m,d[n+0],20,-373897302),r=md5_gg(r,i=md5_gg(i,m=md5_gg(m,f,r,i,d[n+5],5,-701558691),f,r,d[n+10],9,38016083),m,f,d[n+15],14,-660478335),i,m,d[n+4],20,-405537848),r=md5_gg(r,i=md5_gg(i,m=md5_gg(m,f,r,i,d[n+9],5,568446438),f,r,d[n+14],9,-1019803690),m,f,d[n+3],14,-187363961),i,m,d[n+8],20,1163531501),r=md5_gg(r,i=md5_gg(i,m=md5_gg(m,f,r,i,d[n+13],5,-1444681467),f,r,d[n+2],9,-51403784),m,f,d[n+7],14,1735328473),i,m,d[n+12],20,-1926607734),r=md5_hh(r,i=md5_hh(i,m=md5_hh(m,f,r,i,d[n+5],4,-378558),f,r,d[n+8],11,-2022574463),m,f,d[n+11],16,1839030562),i,m,d[n+14],23,-35309556),r=md5_hh(r,i=md5_hh(i,m=md5_hh(m,f,r,i,d[n+1],4,-1530992060),f,r,d[n+4],11,1272893353),m,f,d[n+7],16,-155497632),i,m,d[n+10],23,-1094730640),r=md5_hh(r,i=md5_hh(i,m=md5_hh(m,f,r,i,d[n+13],4,681279174),f,r,d[n+0],11,-358537222),m,f,d[n+3],16,-722521979),i,m,d[n+6],23,76029189),r=md5_hh(r,i=md5_hh(i,m=md5_hh(m,f,r,i,d[n+9],4,-640364487),f,r,d[n+12],11,-421815835),m,f,d[n+15],16,530742520),i,m,d[n+2],23,-995338651),r=md5_ii(r,i=md5_ii(i,m=md5_ii(m,f,r,i,d[n+0],6,-198630844),f,r,d[n+7],10,1126891415),m,f,d[n+14],15,-1416354905),i,m,d[n+5],21,-57434055),r=md5_ii(r,i=md5_ii(i,m=md5_ii(m,f,r,i,d[n+12],6,1700485571),f,r,d[n+3],10,-1894986606),m,f,d[n+10],15,-1051523),i,m,d[n+1],21,-2054922799),r=md5_ii(r,i=md5_ii(i,m=md5_ii(m,f,r,i,d[n+8],6,1873313359),f,r,d[n+15],10,-30611744),m,f,d[n+6],15,-1560198380),i,m,d[n+13],21,1309151649),r=md5_ii(r,i=md5_ii(i,m=md5_ii(m,f,r,i,d[n+4],6,-145523070),f,r,d[n+11],10,-1120210379),m,f,d[n+2],15,718787259),i,m,d[n+9],21,-343485551),m=safe_add(m,h),f=safe_add(f,t),r=safe_add(r,g),i=safe_add(i,e)}return Array(m,f,r,i)}function md5_cmn(d,_,m,f,r,i){return safe_add(bit_rol(safe_add(safe_add(_,d),safe_add(f,i)),r),m)}function md5_ff(d,_,m,f,r,i,n){return md5_cmn(_&m|~_&f,d,_,r,i,n)}function md5_gg(d,_,m,f,r,i,n){return md5_cmn(_&f|m&~f,d,_,r,i,n)}function md5_hh(d,_,m,f,r,i,n){return md5_cmn(_^m^f,d,_,r,i,n)}function md5_ii(d,_,m,f,r,i,n){return md5_cmn(m^(_|~f),d,_,r,i,n)}function safe_add(d,_){var m=(65535&d)+(65535&_);return(d>>16)+(_>>16)+(m>>16)<<16|65535&m}function bit_rol(d,_){return d<<_|d>>>32-_}

Sembra una variabile dentro cui sono infilate una sfilza di funzioni... vedo di capire se riesco a infilarle come scatola nera nella mia paginetta. Tks :-)

Il problema della lentezza (o non-risposta) dei server alla richiesta dei thumb ho ipotizzato invece sia dovuta al fatto che lo script le chiede a 200px e 500px, mentre i thumb prodotti da commons hanno altre risoluzioni... motivo per cui mi immagino la richiesta a quella scalatura viene messa in coda e campa cavallo facilmente va in timeout. Allineando le misure a quelle proposte da Commons la cosa forse migliora un po', ammesso che quelle scalature siano effettivamente già in cache (non credo siano sempre pre-scalate per qualunque immagine si carichi). --TrameOscure (disc.) 12:30, 31 mar 2025 (CEST)

@TrameOscure Il codice è reso illeggibile apposta: è stato minificato e offuscato, pratica comune quando viene servito JavaScript dai server. Se questo codice (che applica MD5) è open-source (penso proprio di sì) prova a cercare la versione originale qui. -- ZandDev (disc.) 13:37, 24 apr 2025 (CEST)

E le cose in tal senso stanno cambiando (soprattutto nell'ultima settimana). Non mi sembra una genialata quella che hanno avuto in passato, salvando in cache perennemente qualsiasi formato richiesto (↗).

Intanto si sta procedendo a ridurre la frammentazione delle dimensioni delle immagini fornite, riducendosi ad una manciata di dimensioni standard (mw, task T360589: De-fragment thumbnail sizes in mediawiki, T372165: Reduce number of bucketsizes for MediaViewer) (oltre ad una brasatura una-tantum di tutte le immagini generate in cache, v. T379942: Gradually drop all thumbnails as a one-off clean up, e in futuro T211661: Automatically clean up unused thumbnails in Swift). Se uno richiede una dimensione differente riceverà (da circa una settimana al 100% di probabilità) la versione di dimensione direttamente superiore, e sarà successivamente scalata alla dimensione richiesta dal browser.

È stata anche aumentata la dimensione standard delle immagini (thumb), che è salita da 220px a 250px, v. T355914: Change default image thumbnail size. -- ZandDev (disc.) 14:54, 24 apr 2025 (CEST)

@ZandDevTi ringrazio. In realtà quel codice funziona, per cui potrebbe andar bene pure così "a scatola nera". Semmai il problema per cui non ho proceduto a implementare quella parte è che i thumb spesso non vengono serviti (probabilmente nei momenti di maggior richiesta) se chiesti "da fuori" di una pagina wiki (come è la mia che è ovviamente in locale e carica appunto 10 anteprime delle pagine di un djvu alla volta)... O almeno penso che la causa sia quella.

Ne vengono giù alcuni e altri no, per cui benchè in teoria la pagina funzioni bene, in pratica ha 'sto difetto.

L'alternativa che è stata suggerita sopra è di tirarsi giù tutto il djvu e sfogliarselo in locale: sicuramente funziona ma scaricarsi djvu di magari centinaia di pagine (magari 100MB) per controllarne solo 20 o 30 (2-3MB) è una cosa che mi fa venire l'orticaria... mi piace l'ottimizzazione delle risorse. :D

Allo stato attuale ho accantonato la cosa. -- TrameOscure (disc.) 19:35, 24 apr 2025 (CEST)

Script molesto...

Cercando di rendere più comodo (secondo i miei gusti) l'edit delle pagine ho scoperto che c'è qualche molestissimo script che costringe ad avere i box di modifica del testo (intestazione/corpo/piè di pagina) di una dimensione bloccata, che non sfrutta neanche bene lo spazio flex in quanto rimane molto vuoto verticale fra i vari box (trovo meglio flex 0, 6, 0 piuttosto che il forzato 1,6,1). Intervenendo via css non si riesce a far molto perchè qualcosa rimette le impostazioni di suo gusto 😤.

Ora, io trovo enormemente fastidioso non poter adattare come voglio larghezza della scansione e larghezza dei box di edit cosa che ha lo scopo di rendere più simile possibile la posizione degli acapo e quindi la lettura in parallelo di testo e scansione. Disattivando js magicamente la cosa è possibile, i box sono stiracchiabili come si vuole, ma si perde una marea di altre funzioni utili... Si può evitare questo comportamento? Tks. Pingo i presunti colpevoli @Candalua @Alex brollo che mi pare siano i più "jscriptori" del reame... :-D TrameOscure (disc.) 15:23, 7 apr 2025 (CEST)

@TrameOscure Io sono innocente. Da tempo prendo le cose come vengono (tranne che per alcuni trucchi di edit). Penso comunque che la struttura di nsPagina sia determinata dai "piani alti". Alex brollo (disc.). 15:58, 7 apr 2025 (CEST)

@Alex brollo. Ok :-D Io invece sono un rompiballe con specializzazione, specie se le cose sono molto fastidiose e se c'è chi mi dà corda chiedendo "cosa trovi più scomodo?" e poi rincara con "abbiamo proprio bisogno di questo tipo di "prospettiva" diversa"... ;-)

Scherzi a parte su fr.ws e en.ws si possono nascondere (e lo sono di default) intestazione e piè di pagina con un bottone... ma anche lì in effetti le larghezze dei box sono fisse e si "liberano" solo bloccando js... un vero peccato IMHO. --TrameOscure (disc.) 17:07, 7 apr 2025 (CEST)

@TrameOscure: abbiamo un gadget che si chiama "forza Intestazione e Piè di pagina" che è quello che li fa stare sempre aperti (e puoi disattivarlo), ma è solo css, non è JavaScript e non agisce sulla dimensione. Credo che la dimensione sia decisa dall'estensione ProofreadPage (che è quella che gestisce le pagine Pagina e Indice). Domani provo a guardare meglio. Can da Lua (disc.) 18:52, 7 apr 2025 (CEST)

@Candalua Quando io vedo settaggi flex mi ritraggo inorridito... e non ho più voglia di pasticciare :-) Alex brollo (disc.). 19:38, 7 apr 2025 (CEST)

@Candalua: ok, grazie, disattivando il gadget il funzionamento è come fr e en: c'è un bottone per aprirli. Resta il fatto che il flex verticale (quando aperti) spreca spazio per nulla fra gli elementi, e qualcosa di js blocca la imho comoda "stiracchiabilità" dei textbox. La quale poi non è neanche il vero punto della questione, che sarebbe la stiracchiabilità orizzontale del flex orizzontale. Per ora pasticciando il flex orizzontale ho allargato la parte della scansione a scapito del textbox, perchè di solito è questa a essere meno leggibile e quindi a sembrarmi più ergonomica se a zoom maggiore. Se però fosse una cosa regolabile al volo di pag in pagina a seconda del testo sarebbe molto comodo :-)

Concordo con @Alex brollo che i flex sono piuttosto macchinosi... non so nemmeno se applicarli qua sia così sensato, visto che li vedo più come una roba da design responsive che da impaginazione +/- statica, ma immagino che queste siano scelte dev wmf. TrameOscure (disc.) 21:05, 7 apr 2025 (CEST)

@Alex brollo, TrameOscure È vero che non sono semplicissimi, però sono molto utili e più puliti (io invece inorridisco nel vedere il codice HTML/CSS relativo alle tabelle usato per formattare contenuto non tabellare). Io ho imparato da devmo:Web/CSS/CSS flexible box layout e pagine relative. Dateci un'occhiata! -- ZandDev (disc.) 15:03, 24 apr 2025 (CEST)

@ZandDev Grazie del suggerimento. Mi fai un paio di esempi di HTML/CSS relativo alle tabelle usato per formattare contenuti non tabellari? Alex brollo (disc.). 18:53, 24 apr 2025 (CEST)

@Alex brollo Non ho formulato bene. Mi riferivo all'uso di tabelle generate con il wikicodice. Di esempi ce ne sono parecchi ancora presenti in giro, sia qua che su Wikipedia. -- ZandDev (disc.) 13:10, 25 apr 2025 (CEST)

@ZandDev Le tabelle si usavano per impaginare nella notte dei tempi, ma è vero che alcuni residuati bellici ancora usano tabelle per impaginare interi siti (argh!). Ma ormai sono abbastanza rari, credo.

Cmq dopo ardue lotte col flex delle nostre Pagine, sono riuscito in parte ad addomesticare l’impaginazione in un modo imho più confortevole ed ergonomico. :D

ps: grazie per il link, poi leggo. -- TrameOscure (disc.) 19:34, 24 apr 2025 (CEST)

In realtà resta il problema di .prp-page-edit-header e .prp-page-edit-footer che non ne vogliono sapere di avere una dimensione più ridotta 🤬 -- TrameOscure (disc.) 10:43, 25 apr 2025 (CEST) Ok, trovato la quadra :-) --TrameOscure (disc.) 11:19, 25 apr 2025 (CEST)

Superare il template Pg?

Va bene che ogni scarafone è bello a mamma sua, ma mi domando se i costi/benefici di Pg sono abbastanza favorevoli da tenerlo in vita (se non come strumento intermedio di codifica).

I suoi vantaggi: un codice molto semplice e immediato, che trasforma il semplice numero pagina originale in un link differenziale, che in nsPagina punta a nsPagina, in ns0 punta a ns0.

Gli svantaggi: la semplicità del codice ha un elevato conto in termini di pesantezza dell'elaborazione, con possibile sovraccarico del sistema e superamento dei limiti mediawiki. Inoltre, nei casi (numerosi) in cui non c'è una relazione biunivoca fra numero pagina e pagina ns0 transclusa, sbaglia spesso bersaglio in ns0.

(comtinua) Alex brollo (disc.). 08:27, 16 apr 2025 (CEST)

Concordo: ci può stare se parliamo di un paio di paginette, ma lunghi indici analitici con centinaia di Pg sarebbero da evitare. Can da Lua (disc.) 09:32, 16 apr 2025 (CEST)

@Candalua Tutto non si può avere. L'evidenza del problema nasce dalle colossali sottopagine di Cronica (Villani), ed in particolare dalle centinaia di tl|Pg nelle pagine Tavola dei capitoli. L'idea che sto sviluppando sarebbe la seguente: utilizzare Pg e tutto quello che ci sta sotto come codice temporaneo, da utilizzare fino a che la sistemazione del testo e della struttura ns0 è stabilizzata; poi, sostituirlo (via javascript) con un codice più pesante per il rilettore, ma molto più leggero per il sistema, che contenga i link appropriati senza ricorrere a ModuloDati via Lua. Il libro IV è adatto alla sperimentazione per verificare quanto si guadagna in termini di risparmio di risorse. Alex brollo (disc.). 10:07, 16 apr 2025 (CEST)

@Candalua La bozza di un template alternativo funzia: {{Pgt}} (solita siglaccia che sta per Pg via template). Nella doc l'indicazione della pagina di prova e sua transclusione di prova ns0. A questo punto ci vuole uno script che sappia fare la conversione {{Pg}}->{{Pgt}} (leggendo Modulo dati o pagelist e sommario) e contrario. Alex brollo (disc.). 08:38, 17 apr 2025 (CEST)

@Candaluae @Alex brollo,

Scusate ma mi intrometto a nome del Pover user di buona volontà ma poco tecnico che voglia rileggere pagine complesse: le parole «codice più pesante per il rilettore, ma molto più leggero per il sistema» mi hanno fatto risonare un campanello d'allarme.

Chi è al servizio di chi? siamo noi al servizio del sistema o il sistema al nostro servizio? La curva di apprendimento di Wikisource è già molto ripida e in effetti il nostro sforzo di formattatori dovrebbe permettere all'ultimo passaggio, quello del rilettore, di appurare la correttezza di un testo italiano piuttosto che imporre il destreggiarsi in uno slalom tra graffe e parametri; nel bene e nel male questa è la filosofia originaria di MediaWiki: evitare all'utente l'HTML sostituendolo con codice più semplice.

In pratica il problema non è la complessità del codice di script o moduli purché il risultato sia che all'utente finale non sia richiesto che il minimo sforzo possibile per usare il template.

Siamo l'unico progetto che ha affrontato e risolto il problema? Non escludo di sì, ma prima di impazzire e far impazziere magari non ci toccherà reinventare la ruota. εΔω 09:22, 17 apr 2025 (CEST)

Io l'ho usato spesso per i riferimenti interni ad ancore, ma effettivamente anche in quel caso è il link in nsPagina non è così necessario. --Cruccone (disc.) 09:23, 17 apr 2025 (CEST)

@Alex brollo, @OrbiliusMagister: in effetti il Pgt sembra un po' un passo indietro per l'utente: da 1-2 parametri facili si arriva a 4-5 non proprio intuitivi. D'altronde il match pagina-capitolo da qualche parte deve avvenire; provando a riassumere, mi pare che le opzioni siano queste:

1. ricerca del capitolo tramite modulo dati come è ora (o tramite altra pagina che contenga la corrispondenza): pesante perché il modulo dati si deve caricare per ogni template, quindi se sono centinaia il sistema non regge;
2. corrispondenza infilata direttamente nel template, come hai fatto in Pgt: evita di caricare altra roba, ma al prezzo di maggiore difficoltà di compilazione, a meno di fare anche un tool che te lo compila in automatico; ma comunque il wikitesto sarebbe in ogni caso più complicato e meno leggibile;
3. ci sarebbe una terza soluzione: ricerca fatta al momento mediante un gadget; il template potrebbe creare un "finto link", poi al momento del clic parte la ricerca del capitolo e l'utente viene reindirizzato alla pagina. Per non appesantire il frontend, questo gadget potrebbe caricarsi solo sulle pagine ns0 che usano il template. Lo svantaggio è che naturalmente il link non è un vero link, se in qualche circostanza il gadget non funziona, il link non funziona; d'altra parte, un vantaggio è che in caso di modifiche e correzioni dei numeri di pagina, non serve fare nulla per aggiornare il link.
4. oppure... c'è anche la quarta soluzione, ovvero: rinunciare a questo link "magico" che in nsPagina fa una cosa e in ns0 ne fa un'altra, e risolvere il problema il modo radicalmente diverso:
   1. sul numero di pagina, usare un template che però genera un link solo in nsPagina, mentre in ns0 mostra solo il numero come testo;
   2. aggiungere un link secco al capitolo sul nome del capitolo, invece che sul numero di pagina; che avrebbe anche più senso, perché alla fine una volta che il testo è digitale, dover cliccare su un numero di pagina del cartaceo è una cosa un po' strana. Questo link magari si può inserire in maniera semiautomatica (soprattutto se si usa qualcosa come Vi), ma dovrebbe essere un link diretto, o un template che comunque riceva il capitolo come parametro e non debba fare altre cose.

Spero di aver esposto bene i miei ragionamenti. Ovviamente nessuna di questa soluzione è perfetta, sono tutte un compromesso; al momento non ho nemmeno io una preferenza netta. Can da Lua (disc.) 16:59, 17 apr 2025 (CEST)

@Candalua @OrbiliusMagister La conversione Pg->Pgt può essere anche fatta via regex: vedi prima pagina test Pagina:Villani - Cronica, Tomo IV, 1823.djvu/327, e sua transclusione in Cronica (Villani)/Libro IX/Parte I.

Confrontati i due NewPP limit report della pagina test che usa Pgt e della versione in cronologia che usa Pg, la differenza è minima, e quindi il test che avevo in mente è concluso: non si guadagnerebbe niente. Sta il fatto che i due template possono coesistere, e che in rari casi, quando Pg dà un risultato errato in ns0, Pgt potrebbe forzare la creazione di due link esatti.

Torno a editare Cronica, Libro IX Parte II. Grazie dell'attenzione! Alex brollo (disc.). 23:13, 17 apr 2025 (CEST)

@Candalua @OrbiliusMagister ... ed ecco qua, proprio nelle poche pagine che ho editato, materializzarsi in Pagina:Villani - Cronica, Tomo IV, 1823.djvu/335 il caso in cui un tl Pg non funziona in ns0 mentre il template Pgt forza il link giusto :-) Alex brollo (disc.). 00:27, 18 apr 2025 (CEST)

Modifica delle pagine in ns0 che usano aree dati

Ultimamente ogniqualvolta che edito le pagine dei capitoli nel namespace principale, le quali usano una struttura dati non visibile (che viene inserita e rimossa via JavaScript tramite il gadget MediaWiki:Gadget-areadati/MediaWiki:Gadget-common-areadati.js per evitare che gli utonti inavvertitamente la rimuovano), come questa, questa o questa. Il vero problema è che in realtà io me ne accorgo ed è altrettanto difficile reinserirla, visto che viene di nuovo rimossa in fase di annullamento della modifica. Questo comportamento mi sta facendo salire il nervoso... Sto facendo copincolla togliendo le varie spaziature che vengono per qualche altro motivo immesse in mezzo. Si può trovare un'alternativa a questo strambo accrocchio? Tipo passare definitivamente a Wikidata? -- ZandDev (disc.) 17:07, 29 apr 2025 (CEST)

Come ti dicevo nella tua talk, mi avevano spiegato che è un ingegnoso meccanismo inventato pre-wikidata e basato su sections per gestire i metadati. In fondo la presenza di quel blocco non è molto diversa dagli accrocchi con cui è fatto il bar di Wikipedia (e forse altre pagine) in cui ci sono quelle righe ======NON TOCCARE SCRIVERE QUA SOTTO========== (o roba del genere) che se le tocchi esplode il bar.

Per editare quella parte il modo che avevo trovato io quando m'era capitato di dover cambiarci delle cose dentro è banalmente disattivare js il tempo necessario a fare la modifica. Che poi ogni tanto sparisca nel nulla (non venga rimesso quando salvi) se non erro ne avevo parlato con @Candalua, ma a me pare sia successo solo una volta. Che a te capiti spesso è strano... forse fai più edit in parallelo e fai impazzire lo script? :-D TrameOscure (disc.) 20:47, 29 apr 2025 (CEST)

Anche a me piacerebbe buttare via l'accrocchio... il fatto è che per brutto che sia, è incredibilmente semplice da usare per l'utente: basta compilare l'indice, poi a cascata ti trovi il template Intestazione in gran parte già compilato, il SAL lo metti con i quadratoni, salvi e il template Testo è già in grado di fare la magia, cioè mostrare autore, anno e SAL. Compilare un elemento Wikidata non è altrettanto semplice che compilare un template, in particolare il SAL che è parecchio nascosto, e già con i template gli utenti fanno abbastanza casini... Bisognerebbe scrivere non solo un qualche modulo Lua che legga i valori, che sarebbe il meno; ma anche un gadget in grado di scrivere direttamente in Wikidata dalle nostre pagine, altrimenti stiamo freschi. Poi c'è un limite al numero di elementi Wikidata che riesci a caricare... e temo che le pagine Autore con più testi non reggerebbero. L'alternativa è caricare i dati con un gadget JavaScript, ma si andrebbe a fare un botto di chiamate rallentando il frontend. Can da Lua (disc.) 23:24, 29 apr 2025 (CEST)

Dei tecnicismi di cui parlate e di cosa implichino capisco ben poco. Tuttavia concordo con Candalua che wikidata sia un giocattolo abbastanza complesso e a me sembra anche piuttosto delicato e probabilmente poco controllato. Ci ho già fatto un po' di edit e nessuno m'ha detto nè A ne BA, ovvero, se già su wikipedia IMHO il controllo dei contenuti è molto scarso (almeno nel merito, non parlo dei "facili vandalismi" da bimbiminkia), figuriamoci su wikidata dove chi capisce qualcosa sono pochissimi e vedere gli errori è ben più difficile (anche perchè si verificano "altrove", cioè su altri progetti). Non è molto diverso dall'altro "progetto transwiki" che è Commons, in cui di sono code di richieste di mesi su migliaia di entità, ovvero controlli praticamente inesistenti in mano a 4 gatti (gli admin che effettivamente lavorano sono pochissimi rispetto alla mole mostruosa di edit su 24 fusi orari).

Questo per dire che se qualche cosa (che per dirla con @Alex brollo "funziona, quindi perchè aggiustarla") resta "isolato" e "qua da noi", si rischia di importare meno casini "dal wikidata-estero". Anche perchè immagino che gran parte degli edit su wikidata venga da utenti wikipedia, che magari capiscono un tubo delle "esigenze tecniche" di ws, e rischiano quindi di rompere cose senza volerlo.

Insomma se il problema è l'episodico fail dello script che toglie&rimette i metadati, forse si può capire dove e perchè fallisce, che immagino sia già un task piuttosto sfidante visto che sembra randomico... TrameOscure (disc.) 11:28, 30 apr 2025 (CEST)

@ZandDev La transclusione è un meccanismo vitale per wikipedia, che lo utilizza per i template, ma doppiamente vitale per wikisource, che fa larghissimo uso delle section. Essendo fondamentale, è stato studiato a lungo per avere una elevata efficienza; e l'accrocchio area dati, sfruttando proprio questa elevata efficienza, permette delle cose utili. Poi, com'è noto, ogni scarafone... ecc. Siamo da anni in attesa della rivoluzione che potrebbe avvenire con la "transclusione interprogetto", se sarà altrettanto efficiente.

Che tipo di modifiche, precisamente, dell'area dati (accessibile direttamente solo disattivando javascript) ti è capitato di voler effettuare? Alex brollo (disc.). 13:18, 30 apr 2025 (CEST)

@Alex brollo Nessuna! Semplicemente ad ogni modifica che faccio essa viene cancellata, rimossa. -- ZandDev (disc.) 13:38, 30 apr 2025 (CEST)

Mi funziona al contrario: si toglie facilmente, si rimette con difficoltà... -- ZandDev (disc.) 13:43, 30 apr 2025 (CEST)

@ZandDev: sei sicuro di non avere errori in console, dovuti magari a qualche script personale? Can da Lua (disc.) 13:55, 30 apr 2025 (CEST)

@Candalua Sulla console del browser vedo solo i soliti errori di cookie intersito (che dovrebbero sparire a breve con una delle prossime versioni di MediaWiki). Non so come debuggare codice JavaScript qua. Di script personali in questa wiki non dovrei averne. Ne ho due globali da Meta, dubito che c'entrino (anche se non lo posso escludere), visto che uno serve a far renderizzare le immagini vettoriali client-side, cosicché nelle pagine dei file possa visualizzare le immagini vettoriali direttamente e non tramite una miniatura raster; l'altro permette di effettuare una modifica direttamente dai diff, facendo apparire un pulsante a destra. -- ZandDev (disc.) 14:31, 30 apr 2025 (CEST)