Wikipedia:Bar/Discussioni/Passaggio da Tidy a RemexHTML: c'è del lavoro da fare

Se sei arrivato qui seguendo il link dal filtro anti-abusi o dall'oggetto di una modifica (riassunto breve)

Il succo di questa pagina è che fra qualche mese il software si aggiornerà per rispettare i nuovi standard di HTML5. Questo vuol dire che alcuni tag html non saranno più utilizzabili (in particolare <font>, <center>, <tt> e <strike>) e che gli altri tag andranno utilizzati correttamente. Ciò significa che i singoli tag dovranno avere il corrispondente tag di chiusura e tali chiusure dovranno rispettare l'ordine corretto. I suddetti errori vengono corretti in automatico via bot, tuttavia è particolarmente importante evitare di continuare ad inserirli, dato che la quantità di lavoro è già elevata. Per consigli su come evitare errori, fare riferimento alle specifiche di W3C e alle indicazioni riportate qui.

Questo annuncio è particolarmente tecnico, quindi cercherò di renderlo il più comprensibile possibile (anche perché nemmeno io sono un tecnico).

È stato annunciato pochi giorni fa sulla mailing list tecnica di WMF che la libreria HTML Tidy non dovrà essere più utilizzata su MediaWiki e che, progressivamente, si passerà all'uso di RemexHTML. La deadline che il gruppo tecnico di WMF si è data è la metà dell'anno prossimo.

Che cosa significa?

Significa che la libreria finora utilizzata per correggere in modo "automatico" determinati errori con i tag HTML (per esempio <small/> anziché </small>, ma anche errori di tabelle chiuse male) smetterà di essere utilizzata, perché ormai incompatibile con HTML5, e dunque verrà sostituita da una libreria che invece è compatibile.

"E quindi, ar popolo che je ne frega?" (cit.)

Al popolo gliene dovrebbe fregare, perché questo potrebbe comportare malfunzionamenti nella visualizzazione delle pagine. Essendo Tidy ideata per una vecchia versione di HTML, non solo potrebbe non correggere più gli errori, ma potrebbe crearne di nuovi. E noi non vogliamo mica caricarci ulteriori problemi in aggiunta a quelli che c'abbiamo già.

Vabbè, che si deve fare?

Fortunatamente non c'è tanto lavoro da fare, ma bisogna mettere mano con estrema attenzione da subito a determinati template e a determinate pagine.

La lista degli errori da correggere la trovate alla pagina Speciale:LintErrors, già ripartita in tre diverse categorie a seconda della priorità (alta, media, bassa). Ça va sans dire che gli errori a cui bisogna mettere mano innanzitutto sono quelli ad alta priorità.

Questi errori sono fondamentalmente facili da correggere (ci si può passare anche con AWB), ma ci sono anche alcuni template a cui bisognerà mettere mano (e che, una volta sistemati, permetteranno di svuotare notevolmente la categoria della priorità alta) sono:

• {{Tutto attaccato}}
• {{Bar7/light}} Fatto
  • Please see Discussioni_template:Bar7/light for a proposed fix. SSastry (WMF) (msg) 20:30, 8 lug 2017 (CEST)
• {{Incontro internazionale}} Fatto
• {{Incontro di club}} Fatto
  • The table from line 27 - 158 is badly nested. Either remove the nested table (line 27, and |} on line 158) or add "|" on its own line before line 27, depending on what you want. SSastry (WMF) (msg) 21:44, 8 lug 2017 (CEST)
    • Things with the latter templates are a bit complicated. Part of the fault is mine, 'cause I oversought the revision of both templates around 6-7 years ago. Probably, the best thing is to simplify them a lot and to pass to Lua modules, since my own solution of nested tables was already a subpar solution when I made it. --Sannita - L'admin (a piede) libero 16:19, 9 lug 2017 (CEST)

Per questi tre ultimi template, il problema riguarda le tabelle annidate e probabilmente necessiterà di un bel po' di lavoro. Soprattutto per i due template sportivi, potrebbe valere la pena iniziare a pensare un passaggio a Lua.

Questo per il momento è tutto, ma mi auguro ci sia qualcuno che possa intervenire a dare una mano. Se serve, io cercherò di aiutare per quel che posso fare. --Sannita - L'admin (a piede) libero 20:01, 8 lug 2017 (CEST)

Intanto credo di aver sistemato quel milioncino di "Missing end tag" causati da t:Portale --Bultro (m) 23:15, 8 lug 2017 (CEST)

Direi che ha funzionato, sta pian piano scendendo, forse il prossimo e {{personaggio}} problemi con "span" --ValterVB (msg) 20:49, 9 lug 2017 (CEST)

Segnalo Discussioni template:Incontro di club#Correzioni HTML. Serve qualche altro test giusto per maggiore sicurezza, e poi un amministratore che proceda. Ho controllato il risultato usando il gadget di migrazione e pare corretto.--Sakretsu (炸裂) 15:48, 10 lug 2017 (CEST)

[↓↑ fuori crono] Dopo altri test, penso che {{Incontro di club/Sandbox}} possa andare live. Qualcuno che aggiorna il template?--Sakretsu (炸裂) 16:04, 12 lug 2017 (CEST)

Molti, molti ringraziamenti per l'interessamento e il lavoro. (Il team aveva incluso istruzioni semplificate nella documentazione. Sarebbe interessante capire quanto sono comprensibili ed efficaci, così poi magari posso chiedere ai traduttori di concentrarsi su quella sezione, se effettivamente funziona. Grazie!) Elitre (WMF) (msg) 19:30, 10 lug 2017 (CEST)

La soluzione suggerita per {{tutto attaccato}} apparentemente causa problemi, vedi discussione in Discussioni_progetto:Coordinamento/Template#Template:M. Se spiegassero perchè in HTML5 l'istruzione <span style='white-space:nowrap;'>…</span> causa problemi potrebbe aiutare a correggere il template.--Moroboshi ^scrivimi 07:44, 11 lug 2017 (CEST)

SSastry (WMF), more details about what's wrong with <span style='white-space:nowrap;'>…</span> in HTML5 needed! Elitre (WMF) (msg) 10:50, 11 lug 2017 (CEST)

There is nothing wrong with <span style='white-space:nowrap;'>…</span> itself. However, if there is a <div> (or other block tags like blockquote, td, p) tag that wraps that span, we are saying that you should add a newline break before the span (because of a bug in the PHP parser which is quite hard to fix). However, looking at Discussioni_progetto:Coordinamento/Template#Template:M and the diff that Sannnita made, the problem is that they added a *new* div tag. The correct fix would be simply add a newline break between <includeonly> and <span>. BUT, in this case, Template:M which includes Template:Tutto_attacato does not have a surrounding div/td/p tag. Neither does Malta which includes Template:M. So, in this case, there is no need to make any change to these templates. The alert at the top of the page recommends this. I am happy to clarify the explanation on the page to explain this better. What is causing the confusion and should be changed on the help page? SSastry (WMF) (msg) 16:22, 11 lug 2017 (CEST)

I strongly recommend working from Speciale:LintErrors/pwrap-bug-workaround and looking at the pages listed there (just 4). In these very specific cases, I don't think any changes might be required at all unless it is a really wide table cell (td) that wraps, but that is more a detail you can ignore. It is safe to make the newline fix before the span even in these td cases on these 4 pages. SSastry (WMF) (msg) 16:22, 11 lug 2017 (CEST)

Moroboshi, altro? Chi può rispondere alla domanda di Subbu? :) Elitre (WMF) (msg) 22:11, 11 lug 2017 (CEST)

If I got this correctly the problem happen when the <span style='white-space:nowrap;'>…</span> is the only thing (or the first thing) between div/p/td or similar tag. I think the misunderstanding about mw:Parsing/Replacing Tidy/FAQ was that we interpreted the instructions in the section "Work around a parser bug for paragraph wrapping" as "add a <div>…</div> and a newline in the template definition". I would remove the div from the example or indicate clearly that they are the condition around the template use, but they are not to put in the template. --Moroboshi ^scrivimi 22:34, 11 lug 2017 (CEST)

(rientro) Dopo il macro-svuotamento della categoria "Table tag that should be deleted" per via dell'aggiornamento dei 2 template sportivi, sto procedendo un po' alla volta a sistemare le poche occorrenze rimaste (per lo più pagine di stagioni di squadre di pallacanestro, a cui va applicato {{Roster PC}} al posto delle vecchie tabelle manuali). Nel frattempo segnalo tra gli errori da correggere a bassa priorità una sfilza di occorrenze dovute ai template {{Citazione necessaria}}, {{Fumetto e animazione}} e {{Personaggio}}, che andrebbero anch'essi revisionati. In particolare, nel codice sorgente degli ultimi 2 campeggia in alto il seguente avviso nascosto: "Lo "span" serve per il VisualEditor"; ho come il vago sospetto che sia proprio quello la causa dell'errore di parsing... -- Mess what a happiness! 14:12, 14 lug 2017 (CEST)

Inoltre, tra gli errori a media priorità, nella categoria "Misnested tags" c'è una massiccia presenza dovuta ad {{Infobox arma}} (se ho capito bene, c'è un cattivo annidamento di tag <span> per colorare la dicitura in calce al template a seconda del tipo di arma). -- Mess what a happiness! 14:34, 14 lug 2017 (CEST)

Mess, fuoricrono, credo che gli span non servano più per l'editore visuale da un pezzo. Elitre (WMF) (msg) 08:44, 18 lug 2017 (CEST)

L'infobox arma dovrebbe essere a posto ora. Quanto a Personaggio e Fumetto e animazione, non si può inserire un table in uno span. Appena ci sono sviluppi qui aggiorno i due template.--Sakretsu (炸裂) 17:47, 14 lug 2017 (CEST)

Aggiunta: il problema del Citazione necessaria (e di altri template che usano {{Chiarimento}}) è il modo in cui viene incluso nelle voci. Ad esempio in Italofonia#.C2.A0Francia avvolge due paragrafi: questo significa che si viene a creare una situazione del tipo <p><span></p><p></span></p> che ora con Tidy si corregge in <p><span></span></p><p><span></span></p> mentre con RemexHTML diventerà <p><span></span></p><p></p> (si perde il secondo paragrafo). Dato che il template dovrebbe essere usato solo per singole affermazioni, andrebbe rimosso e sostituito con gli avvisi.--Sakretsu (炸裂) 18:05, 14 lug 2017 (CEST)

Oltre a sostituirlo con gli avvisi, una soluzione più veloce e "automatica" è anche spezzarlo sui paragrafi, lasciandolo inalterato solo sul primo e aggiungendolo sul secondo.--Daimona Eaytoy (Scrivimi!) 18:20, 14 lug 2017 (CEST)

Segnalo che il template {{Non enciclopedico}} ha bisogno di questo fix diff^89008642.--Sakretsu (炸裂) 20:37, 15 lug 2017 (CEST)

Fatto --ValterVB (msg) 21:00, 15 lug 2017 (CEST)

[@ ValterVB] attenzione, ci devono essere due parentesi graffe }} prima dell'ultimo #if. Grazie--Sakretsu (炸裂) 22:37, 15 lug 2017 (CEST)

Ops, rifatto --ValterVB (msg) 22:45, 15 lug 2017 (CEST)

Ho rivisto anche il template {{Benvenuto}}, il contenuto da copiare è in {{Benvenuto/Sandbox}}.--Sakretsu (炸裂) 23:29, 15 lug 2017 (CEST)

Fatto --ValterVB (msg) 08:58, 16 lug 2017 (CEST)

È rimasto un errore su uno span, a quanto pare la soluzione con br + andata a capo non va bene all'interno di una tabella. Serve quest'altro fix diff^89017814 lasciando il resto invariato.--Sakretsu (炸裂) 11:19, 16 lug 2017 (CEST)

Fatto --ValterVB (msg) 11:46, 16 lug 2017 (CEST)

(rientro) Per risolvere il problema di {{Tutto attaccato}} ho implementato la soluzione adottata dai colleghi di fr.wiki, ovvero l'inserimento di un apposito stile CSS in MediaWiki:Common.css (vedi ultime righe di codice), testando il tutto su questa mia sandbox e assicurandomi che il testo non viene effettivamente mandato a capo. Ad ogni modo, come già ribadito nei giorni scorsi, il bug non è dovuto a quel codice particolare, bensì ad altri tag lasciati appesi e che causano problemi (come ad esempio qui). -- Mess what a happiness! 09:39, 17 lug 2017 (CEST)

Sto provando a sistemare un problema di tag male annidati presente in Wikipedia:Modello di voce/Stagione di una divisione di un campionato di calcio (e di conseguenza propagatosi in diverse voci calcistiche), ma a quanto pare non riesco a trovare la soluzione. Gli errori segnalati sono [1], [2] e [3]; a me sembra che i tag <small> siano chiusi correttamente, ma l'errore persiste. Cosa non va? -- Mess what a happiness! 17:03, 17 lug 2017 (CEST)

A me piacerebbe in primis sapere qual'è il senso logico di usare degli <small>…</small> e style="font-size:85%" dove non è per niente necessario. Come soluzione base eliminarli sarebbe in toto sarebbe una buona partenza.--Moroboshi ^scrivimi 17:18, 17 lug 2017 (CEST)

Vabbè a parte quanto sopra, è corretto a livello di html aprire e chiudere gli small su paragrafi (e quindi elementi<div>…</div> multipli) ?--Moroboshi ^scrivimi 17:21, 17 lug 2017 (CEST)

Corretto o meno, l'importante è che il tutto sia compatibile con HTML5 (e quindi col futuro parser). Per il resto, concordo sul fatto di cercare di stroncare tutti quei barocchismi a livello di codice. -- Mess what a happiness! 17:38, 17 lug 2017 (CEST)

Il tag small non può contenere una lista dl. In sostanza il wikicodice corrisponde a <small><dl><dd></dd></dl></small> e si traduce in <dl><dd><small></small></dd></dl><small></small> con uno small in più alla fine, mentre la sequenza corretta sarebbe <dl><small><dd></dd></small></dl>.--Sakretsu (炸裂) 19:05, 17 lug 2017 (CEST)

[@ Sakretsu] OK, ora mi è molto più chiaro l'inghippo. Fatto sta che ho tentato vari modi per aggirare l'inconveniente cercando di mantenere grossomodo la stessa formattazione, ma finora non ci sono riuscito. La soluzione più scontata sarebbe quella di rinunciare completamente al testo rimpicciolito, ma credo che non sia praticabile di fatto. -- Mess what a happiness! 00:49, 18 lug 2017 (CEST)

Problema {{Personaggio}} e {{Fumetto e animazione}} risolto: ho rimosso il tag "span" e non ci sono stati effetti collaterali (VisualEditor funziona senza intoppi). Ora le categorie a bassa priorità si svuoteranno considerevolmente. -- Mess what a happiness! 18:44, 18 lug 2017 (CEST)

[@ Mess] dai un'occhiata a {{Bar3/barradisc}}, ha un bel po' di chiusure span di troppo.--Sakretsu (炸裂) 20:27, 18 lug 2017 (CEST)

Vedo che diversi errori di tag non chiuso sono in pagine di discussione, non inseriti da template. Credo dipendano dalle firme, in particolare ad es. qui c'è uno span non chiuso e l'unica possibilità dovrebbe essere la firma di LukeWiller. Nel caso occorrerebbe un'occhiata anche alle firme, dato che sono inserite su un numero tendenzialmente alto di voci (sebbene siano discussioni utente ed errori a bassa priorità).--Daimona Eaytoy (Scrivimi!) 10:07, 19 lug 2017 (CEST)

La firma corretta è <span style="font-family:Bookman Old Style;">'''[[Utente:LukeWiller|<span style="color:green;">LukeWiller</span>]]''' [[Discussioni utente:LukeWiller|<small><span style="color:green;">[Scrivimi]</span></small>]]</span>--Sakretsu (炸裂) 11:04, 19 lug 2017 (CEST)

Occorre un'occhiata anche a Template:ListaBio, incluso in parecchie liste: ci risulta uno span non chiuso. In particolare credo sia un tag di chiusura di troppo alla riga 18.--Daimona Eaytoy (Scrivimi!) 12:55, 19 lug 2017 (CEST)

Lo span di chiusura è corretto, è <span style="font-size:90%;"> a dover essere spostato alla riga sotto, davanti a L'aggiornamento è periodico e automatico e ricostruisce completamente la pagina.--Sakretsu (炸裂) 14:02, 19 lug 2017 (CEST)

[@ Sakretsu] Ho osservato il codice che mi avevi segnalato ieri sera: effettivamente ci sono troppi "span" di chiusura, ma sinceramente se non nuocciono (dato che non ne trovo traccia tra le liste di errori) non vedo il senso di rimuoverli senza un valido motivo. Nel frattempo segnalo che ho corretto {{Cancellazione/vota}} (che era usato massicciamente nelle vecchie procedure di cancellazione), così da far calare velocemente di numero i casi di "misnested tags". -- Mess what a happiness! 16:08, 19 lug 2017 (CEST)

[@ Mess]Gli errori di {{Bar3/barradisc}} li ho visti anche io, se non erro sono tutti in "Tag di chiusura mancante" ma potrei sbagliarmi sul posto. Sicuramente ne ho visti parecchi.--Daimona Eaytoy (Scrivimi!) 16:34, 19 lug 2017 (CEST)

C'è {{BloccoInfinito}} che ha problemi per via di <span style="margin:0em 1em;">[[File:Stop sign light red.svg|left|33px]]</span>. Sarebbe molto interessare sapere come sistemarlo, visto che è un altro template abbastanza diffuso. -- Mess what a happiness! 17:39, 19 lug 2017 (CEST)

Lo span va trasformato in un div.--Sakretsu (炸裂) 18:09, 19 lug 2017 (CEST)

[@ Sakretsu] Perfetto, grazie 1000! Altre migliaia di pagine sistemate in un solo colpo! ;-) -- Mess what a happiness! 23:16, 19 lug 2017 (CEST)

[@ Moroboshi] Progetti interessati causa un tr senza tag di chiusura. Ho provato a darci un'occhiata, ma proprio non capisco dove sia il problema... Probabilmente l'errore riguarda tutte e 100.000 le voci in cui è incluso.--Sakretsu (炸裂) 23:26, 19 lug 2017 (CEST)

Provo a guardare, a una prima occhiata è strano, usa la libreria mw.html che dovrebbe chiudere in automatico tutto quando genera il codice html.--Moroboshi ^scrivimi 06:32, 20 lug 2017 (CEST)

[← Rientro]Sto provando a istruire il mio Bot per la correzione (semiautomatica) di errori, ma sinceramente non saprei come caricargli le pagine. Non c'è un modo di prelevare l'intera lista di pagine con un dato errore? Detto questo, consiglio a chi può di fare la modifica proposta sopra al {{ListaBio}}, in quanto fra inclusioni e sotto-inclusioni include errori in almeno 12000 pagine. Inoltre vari template di guerra, e.g. Template:Campagnabox Fronte Occidentale (1914-1918) utilizzano il {{Pbrk}} che gli inserisce un p non chiuso. Come va corretto? Ci sarebbe infine il {{Composto chimico}} che dà errore di span non chiuso ma non riesco a capire da cosa dipenda.--Daimona Eaytoy (Scrivimi!) 13:32, 20 lug 2017 (CEST)

[@ Daimona Eaytoy] Purtroppo non esiste una formula univoca, ma con un pizzico d'ingegno si riesce a combinare qualcosa per ottenere delle liste da dare in pasto ai nostri amici (semi)automatici. Un primo passo è l'utilizzo del prefisso insource: nella casella di ricerca interna (vedi Aiuto:Ricerca oppure en:Help:Searching) per trovare le pagine che hanno all'interno del loro wikitesto una determinata stringa (e quindi uno specifico errore, ma occhio ai falsi positivi!). Un'altra tecnica è quella di copincollare letteralmente alcune pagine delle liste di errori Lint su un foglio di calcolo elettronico e ordinarle a proprio piacimento per intuire se vi sia un errore comune tra le voci indicate. -- Mess what a happiness! 18:33, 20 lug 2017 (CEST)

[@ Mess] Grazie mille, purtroppo io cercavo proprio il modo tutto-in-un-colpo. Ad esempio se volessi un'intera categoria ricorsiva è sufficiente l'opzione "category recursive" ma qui non ci sono di mezzo categorie né niente del genere, ed è un peccato perché bisogna andare un po' a tastoni. Anche sull'insource in realtà non è così semplice, ci vuole poco a far andare in timeout il motore delle ricerche anche senza bisogno di cose particolarmente esoteriche. Comunque segnalo che parecchie voci hanno problemi con i tag "cite"; ad esempio, in Agatocle derivante dal {{Note strette}} e in Nikola Tesla da template multipli. Da cosa dipende? Non sono riuscito a trovare una spiegazione.--Daimona Eaytoy (Scrivimi!) 18:39, 20 lug 2017 (CEST)

Segnalo un'altra grave magagna replicata su diverse pagine: mi riferisco alla firma di Utente:Yackyack, che genera numerosi avvisi a causa di un'errata chiusura del tag "span" e che quindi andrebbero sanate quanto prima. Oltre ad invitare cortesemente [@ Yackyack] a modificare al più presto posssibile la sua firma da '''''<span style="font-size:medium;font-family:Comic Sans MS">[[Utente:yackyack|<span style="color:#BB0011">YackYack</span>]]<sup>[[Discussioni utente:yackyack|<span style="font-size:x-small;color:#00B003"> (msg)</span>]]</sup>''''' a '''''<span style="font-size:medium;font-family:Comic Sans MS">[[Utente:yackyack|<span style="color:#BB0011">YackYack</span>]]<sup>[[Discussioni utente:yackyack|<span style="font-size:x-small;color:#00B003"> (msg)</span>]]</sup></span>''''', chiedo a qualcuno più esperto se sia possibile ottenere una deroga per il mio bot per intervenire automaticamente sulle pagine protette ed accessibili ai soli admin (so che potrei usare AWB direttamente con la mia utenza normale, ma andrei contro le regole che prevedono l'uso intensivo di modifica esclusivamente con utenze bot). -- Mess what a happiness! 19:09, 20 lug 2017 (CEST)

[@ Mess] WP:Flood editor + AWB?--Daimona Eaytoy (Scrivimi!) 19:37, 20 lug 2017 (CEST)

Per me puoi usare la tua utenza, ricordandoti del flag, anche perché non credo ci siano altre possibilità, c'é un solo BOT admin ed è quello del filtro. --ValterVB (msg) 19:47, 20 lug 2017 (CEST)

[@ Daimona Eaytoy] Le API permettono di interrogare la lista:/w/api.php?action=query&format=json&prop=&list=linterrors, se sei in grado di smanettarci puoi recuperare quello che vuoi, è prevista la classica paginazione. --ValterVB (msg) 19:51, 20 lug 2017 (CEST)

Se vuoi più dettagli per come filtrare il risultato usa la sandbox delle API e clicca su "list=linterrors". --ValterVB (msg) 19:55, 20 lug 2017 (CEST)

[@ ValterVB] Splendido, grazie mille. Non so se sono in grado ma proverò a smanettarci a vedere cosa riesco a ottenere.--Daimona Eaytoy (Scrivimi!) 20:06, 20 lug 2017 (CEST)

Incredibile! Solo rintracciando tra le pagine delle vecchie procedure di cancellazione le firme che contengono errori di tag HTML (oltre a YackYack, ho scovato quelle di Utente:Theirrulez - inattivo dal 2013 - e Utente:Soprano71 - che fortunatamente ha la firma attuale in piena regola) e sistemandole in modalità flood editing, sto riducendo a vista d'occhio la categoria "Misnested tags". -- Mess what a happiness! 00:55, 21 lug 2017 (CEST)

Ho visto che la mia firma dà' problemi, come dovrei cambiarla? Così per esempio andrebbe bene?YackYack ^(msg) 08:26, 21 lug 2017 (CEST)

Devi spostare l'ultimo span di chiusura all'interno del wikilink alle discussioni:

'''''[[[Utente:yackyack|<span style="color:#BB0011">YackYack</span>]]<sup>[[Discussioni utente:yackyack|<span style="font-size:x-small;color:#00B003"> (msg)</span>]]</sup>'''''

--Moroboshi ^scrivimi 09:20, 21 lug 2017 (CEST)

Fatto. Grazie, e scusate per l'inconveniente.YackYack ^(msg) 10:50, 21 lug 2017 (CEST)

[← Rientro]Segnalo anche uno span non chiuso in una o più versioni del {{Benvenuto}}, tosto da correggere perché è sempre substato. Lo si può vedere ad esempio qui e qui.--Daimona Eaytoy (Scrivimi!) 11:24, 21 lug 2017 (CEST)

[@ Daimona Eaytoy] ok ho fatto questo, dimmi che ne pensi. Sono 140k inclusioni su 600, poi vedo di sistemare quelle substate. --Vito (msg) 12:43, 21 lug 2017 (CEST)

[@ Vituzzu] Dà ancora errore. A quanto vedo dipende da due span annidati a riga 11 ("Wikipedia ha solo alcune regole inderogabili"...). Un'idea è spezzarli, l'altra (se non erro) sostituire il primo con un div.--Daimona Eaytoy (Scrivimi!) 13:01, 21 lug 2017 (CEST)

[@ Daimona Eaytoy] fai fai, quando hai finito rialzo la protezione. --Vito (msg) 13:03, 21 lug 2017 (CEST)

[@ Vituzzu] Ottimo, grazie. Ho fatto un paio di modifiche, in realtà forse l'errore era più semplice del previsto e potrei aver modificato fin troppo. Comunque in termini visivi mi sembra equivalente, solo una leggera spaziatura verticale di differenza e, ciò che conta, l'errore non c'è più.--Daimona Eaytoy (Scrivimi!) 13:11, 21 lug 2017 (CEST)

Occhio che questo span diff^89149862 è rimasto di troppo. Errori del genere finiscono in Stripped tags--Sakretsu (炸裂) 13:55, 21 lug 2017 (CEST)

[@ Sakretsu] dovrei aver corretto, cortesemente verifica. --Vito (msg) 14:09, 21 lug 2017 (CEST)

[@ Vituzzu] sì sì, tutto a posto.--Sakretsu (炸裂) 14:47, 21 lug 2017 (CEST)

[← Rientro] Segnalo un </sup> da inserire in {{ISBN}} al posto di </span>--Daimona Eaytoy (Scrivimi!) 18:40, 21 lug 2017 (CEST) E anche in Template:PaginaPrincipale/Titolo va aggiunto un </div> prima del <noinclude>.--Daimona Eaytoy (Scrivimi!) 19:08, 21 lug 2017 (CEST)

Fatto su entrambi --L736E^{l'adminalcolico} 19:18, 21 lug 2017 (CEST)

{{Squadra di calcio}} necessita di un tag small di chiusura diff^89162802.--Sakretsu (炸裂) 22:04, 21 lug 2017 (CEST)

Fatto--Moroboshi ^scrivimi 22:12, 21 lug 2017 (CEST)

Modulo:Interprogetto, riga 342, da correggere il tag span di chiusura.--Sakretsu (炸裂) 22:45, 21 lug 2017 (CEST)

Fatto--Vito (msg) 22:49, 21 lug 2017 (CEST)

Finalmente ho risolto la questione del Modulo:Progetti interessati. A quanto pare è necessario richiamare la radice html alla riga 297, il fix da fare è questo diff^89164997.--Sakretsu (炸裂) 00:28, 22 lug 2017 (CEST)

Facciamo che faccio te e Daimona Eaytoy admin temporanei per una settimana per fare questa roba direttamente? --Vito (msg) 00:31, 22 lug 2017 (CEST)

Ti ringrazio per la fiducia, ma personalmente non credo di poter promettere una certa costanza su questo fronte. Per di più la mole di lavoro è troppa, e credo che continueremo ad avere bisogno di qualche admin da queste parti per un bel po'. Comunque grazie davvero.--Sakretsu (炸裂) 00:49, 22 lug 2017 (CEST)

[← Rientro] Per una settimana è un po' troppo. Possiamo fare che per ora cerco di correggere quel che posso e tengo da parte le correzioni da fare, così è sufficiente un'oretta di flag al massimo.--Daimona Eaytoy (Scrivimi!) 09:54, 22 lug 2017 (CEST)

Una settimana non significa che ci dobbiate dedicare una settimana, l'unica condizione è che non facciate altre azioni da admin se non modificare roba collegata alla risoluzione degli errori. --Vito (msg) 12:08, 22 lug 2017 (CEST)

Altre azioni figuriamoci, è già tanto correggere questi errori. Comunque c'è anche da dire che di pagine protette da correggere ce ne sono sempre meno.--Daimona Eaytoy (Scrivimi!) 12:33, 22 lug 2017 (CEST)

[@ Daimona Eaytoy] Fatto, se [@ Sakretsu] vuole ci vogliono pochi secondi per smollare l'accollo anche a lui. --Vito (msg) 13:55, 22 lug 2017 (CEST)

Credo che sfrutterò [@ Daimona Eaytoy]: Modulo:CAS, riga 63, aggiusta quello span di chiusura! E così anche il Template:Composto chimico è a posto.--Sakretsu (炸裂) 19:56, 22 lug 2017 (CEST)

Mi faccio sfruttare volentieri, del resto ho quasi finito gli edit "succosi" di template super-inclusi. Comunque, Fatto sul CAS e rinnovo una vecchia domanda: si è capito da cosa dipendono i "cite" non chiusi presenti in numerose voci?--Daimona Eaytoy (Scrivimi!) 20:08, 22 lug 2017 (CEST)

Mi indichi qualche campione? Ancora meglio con poche fonti.--Sakretsu (炸裂) 01:47, 23 lug 2017 (CEST)

[← Rientro] Non sono difficili da trovare, in categoria missing end tag filtrando in ns0 ne trovi in abbondanza su qualsiasi pagina. Ad esempio ci sono questa (output da tl multipli), questa (idem), questa (qui le fonti sono parecchie ma l'errore viene dal {{Note strette}}). E ancora qui (tl multipli, pochissime fonti) e infine sono riuscito a trovare questa, con una sola nota; in quest'ultima l'errore era generato ancora dal Note strette, ma siccome era stato inserito con non so quale logica (dato che spezzava una nota di 3 righe in 4 colonne) e stava altamente urtando il mio sistema nervoso ho provveduto a inserire un tag references semplice. Così facendo, è rimasto l'errore e ora anche qui è da tl multipli.--Daimona Eaytoy (Scrivimi!) 10:26, 23 lug 2017 (CEST)

Forse dipendono dal parametro |citazione = dei vari template?--Dr ζimbu (msg) 10:57, 23 lug 2017 (CEST)

Sì, la citazione è posta in un dl che rompe il tag cite ed esce fuori. Sto cercando una soluzione.--Sakretsu (炸裂) 11:29, 23 lug 2017 (CEST)

OK, il modulo Citazione avvolge il contenuto del parametro citazione in un tag dl. Il tag cite però non può contenere un dl, ergo veniva buttato fuori. Fin qui, credevo ancora di poter salvare il dl portandolo fuori dal tag cite, ma a sorpresa mi sono reso conto che ogni volta che si pone qualcosa nel tag ref (e quindi in una nota), il software Mediawiki avvolge tutto in un tag span. Perfetto, morale della favola non ci può essere un dl nemmeno in uno span, quindi direi di ripiegare su qualcosa di diverso. L'unica cosa che fa il dl è creare un margine sinistro equivalente a 1.6em. Lo sostituiamo con uno span che fa la stessa identica cosa e il risultato visivo sarà identico, mentre il risultato HTML sarà impeccabile. Pareri o alternative?--Sakretsu (炸裂) 13:10, 23 lug 2017 (CEST)

D'accordo con la sostituzione in span, più semplice e immediata, senza alcun dubbio.--Daimona Eaytoy (Scrivimi!) 13:20, 23 lug 2017 (CEST)

Aggiungo che {{Volume Manga}} ha un tr non chiuso, ma sinceramente non riesco a trovarlo. Ne ho chiusi due in due edit ma ancora sembrano esserci problemi. [@ Sakretsu] visto che hai contribuito parecchio al template ti pingo, in teoria se ne conosci la struttura non dovrebbe essere un fix difficile.--Daimona Eaytoy (Scrivimi!) 13:51, 23 lug 2017 (CEST)

Fatto--Sakretsu (炸裂) 14:03, 23 lug 2017 (CEST)

Segnalo che alcuni man hanno un tt non chiuso derivante dal {{TabellaTemplate}} senza che nel man siano contenuti tag tt; è il caso ad esempio di Template:CaricaMonumento/man e Template:Collegio elettorale/man. C'è qualche problema in casi particolari con il suddetto template o sono io che non vedo qualcosa? Noto comunque con piacere che i "missing end tag" nel ns template si sono ridotti ad appena 3 pagine e nei prossimi giorni istruirò il mio bot per i {{Benvenuto}} substati e per le firme problematiche. --Daimona Eaytoy (Scrivimi!) 20:11, 23 lug 2017 (CEST)

Il template TabellaTemplate genera un tt che si rompe per via dei tag hr (----) inseriti in mezzo. Meglio rimuovere gli hr anomali sostituendoli con una riga vuota di stacco.--Sakretsu (炸裂) 20:45, 23 lug 2017 (CEST)

[← Rientro] Ah ecco, grazie mille. Sospettavo un qualcosa del genere ma non pensavo che l'hr potesse dare problemi. Me ne occuperò domani.--Daimona Eaytoy (Scrivimi!) 20:50, 23 lug 2017 (CEST) [@ Vituzzu] Sto per iniziare la correzione di tutta una serie di firme con tag errati, e inevitabilmente una buona quantità si trova in pagine protette. Quando e se ne avrò bisogno, assegnarmi il flag di flood editor per correggerle con AWB rientra tra quanto mi è possibile fare?--Daimona Eaytoy (Scrivimi!) 11:43, 24 lug 2017 (CEST)

E se no per quale motivo ti è stato dato il flag? :) Occhio che dopo che cambi il flag devi scollegarti e poi ricollegarti su AWB, se no non lo legge, mi ha fregato l'altro giorno --ValterVB (msg) 13:18, 24 lug 2017 (CEST)

Questo è vero, ma il flood è comunque una situazione "particolare". Cercherò di ricordarmene, l'ho anche letto l'altro giorno sulla pagina di aiuto ma c'è alta probabilità che me ne dimentichi lo stesso, anche perché potrebbe servirmi fra un'ora come fra una settimana. :P--Daimona Eaytoy (Scrivimi!) 13:25, 24 lug 2017 (CEST)

[@ Daimona Eaytoy] Per le firme non c'è alcuna urgenza: me ne sto occupando direttamente io un po' per volta in modalità flood editing (anche se limitatamente alla categoria "Misnested tag", che ho già ridotto da poco più di 70000 errori a meno di 30000), pertanto puoi concentrarti direttamente su altri fronti. -- Mess what a happiness! 14:07, 24 lug 2017 (CEST)

Io mi sto occupando dei missing end tag, quindi siamo su due ambiti diversi... Comunque ho notato che sono davvero tante, quindi più siamo meglio è. Anche sugli altri fronti non saprei dove andare a parare, per i template mancano (se non erro) soltanto manuali, dei quali possiamo occuparci con calma, e per ora vorrei continuare ad occuparmi dei missing end tag date le impostazioni del mio bot.--Daimona Eaytoy (Scrivimi!) 14:15, 24 lug 2017 (CEST)

Interruzione arbitraria per riportare che Subbu e il suo team sono molto felici e colpiti dal lavoro della comunità italiana su questo progetto. Al solito, se occorre qualcosa fatecelo sapere con un ping, ma sembrate messi abbastanza bene che io quasi quasi toglierei la pagina dagli oo.ss. ... Elitre (WMF) (msg) 20:02, 24 lug 2017 (CEST)

[@ Elitre] gentilmente, io avrei una domanda. After several tests, I've found out that <cite><dl><dd>text</dd></dl></cite> gets flagged as missing a cite end tag, while <ref><cite><dl><dd>text</dd></dl></cite></ref> does not. Why is that?--Sakretsu (炸裂) 21:28, 24 lug 2017 (CEST)

[@ Sakretsu] This is just a side-effect of how references are handled. Content in article text is wrapped in paragraphs, but content in <ref> tags is not wrapped in paragraphs. The problem arises you cannot add <p> tags around a dl. The HTML5 parser splits the paragraph at the start of the <p> tag. This in turn splits the surrounding <cite> tag (or any other tag that might be there). Try <ref><p><cite><dl><dd>text</dd></dl></cite></p></ref>. This is the same behavior with <span>\n*a\n</span>. The span tag gets split and you get a lint error (missing-end-tag + stripped-tag / misnested-tag). Does this clarify the behaviour? SSastry (WMF) (msg) 22:16, 24 lug 2017 (CEST)

[@ Elitre (WMF), SSastry (WMF)] yes, it does :-) Thank you very much.--Sakretsu (炸裂) 22:34, 24 lug 2017 (CEST)

[@ Sakretsu] Quindi una risoluzione per le note dovrebbe essere inserirle tutte in un loro paragrafo? Proviamo? --Valerio Bozzolan (msg) 22:45, 24 lug 2017 (CEST)

[@ Sakretsu] Uhm. Ho condotto un test e mi sembra impossibile inserire un paragrafo in un cite (<cite><p>test</p></cite>) dato che viene automaticamente convertito nel contrario (<p><cite></cite></p>). --Valerio Bozzolan (msg) 23:04, 24 lug 2017 (CEST)

Ho risposto anche per gli altri qui.--Sakretsu (炸裂) 23:21, 24 lug 2017 (CEST)

[← Rientro]Sto scoprendo solo adesso un altro aspetto negativo: le pagine speciali non conteggiano l'effettivo quantitativo di errori da sistemare, ma soltanto quelli rilevati dalle pagine salvate recentemente (sia con modifiche vere e proprie sia con "dummy edit" effettuati in automatico e/o volontariamente). Peccato, però, che prima che vengano completamente rilevati, quasi sicuramente il nuovo parser sarà già operativo al 100%, pertanto invito tutti quanti a non limitarsi ad osservare i nominativi nelle pagine speciali, ma a verificare la reale presenza di uno specifico errore anche (e soprattutto) attraverso il motore di ricerca interno usando il prefisso insource:. Mi sono accorto di tutto ciò nel momento in cui sono andato a controllare quanto fosse realmente diffuto un errore di tag male annidati nei messaggi di benvenuto delle pagine di discussione utente che avevo rilevato qualche giorno fa: sono rimasto sbalordito nel constatare che ci sono ancora oltre 128000 pagine che lo contengono (non per fare polemica spicciola, ma usare direttamente il template {{Benvenuto}} pareva brutto? Avete idea dell'enorme perdita di tempo che si dovrà sprecare per sistemare un errore così stupido che si sarebbe risolto in 5 minuti se fosse stato usato il template tal quale anziché substarlo - e quindi copincollarlo di fatto?) -- Mess what a happiness! 11:34, 25 lug 2017 (CEST) P.S.: per capirci meglio, mi riferisco a questo "rumorino da niente" (cit.)

[@ Mess] Sbaglio o c'è discordanza tra la ricerca che hai postato e i risultati che restituisce? Nella lista dei risultati sembra non esserci il </span>. Comunque sono d'accordo sul Benvenuto.--Daimona Eaytoy (Scrivimi!) 11:57, 25 lug 2017 (CEST)

Perché la ricerca aggiunge uno <span class="searchmatch"> a ogni corrispondenza che si chiude in maniera anomala con quel tag span di chiusura fuori posto (e quindi quest'ultimo nella ricerca non appare). Comunque tutto questo spiega come mai gli errori calavano così lentamente nonostante il lavoro fatto. C'era Babbo Lint che ci regalava altri errori man mano che controllava le pagine.--Sakretsu (炸裂) 12:09, 25 lug 2017 (CEST)

Secondo me però non vale la pena farsi il sangue amaro a posteriori :) Non è che le persone facciano scelte apposta per complicare la vita agli altri in casi futuri di cui non possono nemmeno prevedere l'occorrenza. Nel caso specifico, substare il template di benvenuto è letteralmente tra gli esempi per cui è raccomandato il subst. Elitre (WMF) (msg) 12:20, 25 lug 2017 (CEST)

[@ Elitre (WMF)] Ma figurati, non sono il tipo che se la prende per così poco, però guardando questi intoppi un po' mi viene spontaneo storcere il naso. Tra l'altro, vorrei far presente che nell'era arcaica di it.wiki quel template era incluso normalmente (come si intuisce osservando i "puntano qui") e quindi della "storicità" del messaggio originario non ci si curava affatto. Anzi, secondo il mio modesto parere è pure altamente controproducente preservarlo a prescindere, perché se per assurdo un utente si registrasse adesso e poi ritornasse a collaborare dopo svariato tempo (chessò, 5 o 10 anni), ma nel frattempo il messaggio di benvenuto venisse modificato per l'ennesima volta, si potrebbe ritrovare potenzialmente con riferimenti obsoleti che non rispecchiano più la situazione corrente; però se per la maggioranza va bene substare a manetta il template, allora "obbedisco" alla garibaldina maniera. -- Mess what a happiness! 13:40, 25 lug 2017 (CEST)

Segnalo che non ci sono più errori di alta priorità in NS0.--Sakretsu (炸裂) 23:49, 26 lug 2017 (CEST)

Per fare il punto della situazione: la correzione delle firme è lungi dall'essere completata, anche solo per le pagine protette. Questo soprattutto per due problemi tecnici: il primo è che, come già detto sopra, spuntano errori Lint dal nulla come funghi; il secondo è che nel generare una lista di pagine dai contributi di un dato utente, AWB si ferma prima di aver finito e di conseguenza è un po' tricky trovare tutte le occorrenze. Detto questo, al momento mi sto occupando delle pagine non protette per sgrossare le occorrenze, ma essendo finita la settimana non posso più occuparmi delle protette. Chiederei quindi (in particolare a Vito, che qui è l'unico burocrate) se fosse possibile avere un'altra settimana da sysop. In caso di risposta negativa, vi metto senza problemi a disposizione la lista di tutte le firme da correggere e chiederei contestualmente la rimozione del flood che, senza diritti di sysop, mi è inutile e anzi deleteria.--Daimona Eaytoy (Scrivimi!) 14:10, 29 lug 2017 (CEST)

Segnalo che in Template:5pilastri è presente uno span che avvolge un elenco puntato, e che di conseguenza fa sistemato in modo che non si rompa.--Daimona Eaytoy (Scrivimi!) 20:57, 29 lug 2017 (CEST)

Dovrei aver corretto.--Sakretsu (炸裂) 22:07, 29 lug 2017 (CEST)

[← Rientro]Un altro paio di appunti: il primo è che gli errori stanno aumentando come non mai: ad esempio, per i tag non chiusi, ieri sera eravamo sui 390000 e adesso siamo a 405000. Il secondo è che andrebbe assolutamente e velocemente corretta questa pagina per evitare che i bot di benvenuto aggiungano ulteriori errori. Il testo corretto lo trovate qui e potete procedere con la cancellazione della sandbox dopo averlo trasferito.--Daimona Eaytoy (Scrivimi!) 12:47, 30 lug 2017 (CEST)

[@ Daimona Eaytoy] In realtà le occorrenze stanno aumentando per via dei salvataggi compiuti dal mio bot per correggere quei tag male annidati che avevo segnalato qualche giorno fa (ancora qualche ora e dovrei averli sistemati tutti); purtroppo quella stramaledetta abitudine di substare il template di benvenuto s'è portata appresso una tale vagonata di errori che andrebbero corretti simultaneamente. Non appena avrò finito le operazioni che ho condotto finora, vedrò di trovare un metodo unificato che contempli tutti gli errori a bassa priorità nei messaggi di benvenuto. -- Mess what a happiness! 14:51, 30 lug 2017 (CEST)

[@ Daimona Eaytoy] Intanto ho ricopiato (e cancellato) la tua sandbox contenente le firme corrette per Wikipedia:Benvenuto Bot/Firme. -- Mess what a happiness! 14:57, 30 lug 2017 (CEST)

Immaginavo, anche perché le nuove occorrenze sono tutte in discussioni utente. Sinceramente ho problemi a impostare la sostituzione per i benvenuti (anche se ancora non mi ci sono davvero dedicato) perché non so cosa cercare: gli errori possono essere praticamente in ogni versione del benvenuto. Grazie mille intanto per la correzione delle firme ;)--Daimona Eaytoy (Scrivimi!) 15:58, 30 lug 2017 (CEST)

[@ Daimona Eaytoy] Prego, non c'è di che. Continua pure ad occuparti delle firme, ai messaggi di benvenuto ci penso io. -- Mess what a happiness! 16:32, 30 lug 2017 (CEST)

[← Rientro] Dunque, ho rintracciato tutte le occorrenze nei messaggi di benvenuto che generavano errori ed ho elencato in dettaglio qui le correzioni da apportare. Dato che stiamo parlando di oltre mezzo milione (!?!) di pagine da revisionare, ho assoluto bisogno di ulteriori volontari che mi diano una mano a smazzare questa ingente mole di lavoro, poiché se dovessi proseguire da solo, col ritmo che ho sostenuto finora ci metterei almeno un mese per ultimare il tutto; per chi fosse interessato, per agevolare il compito condividerò via mail e/o messaggio privato il file XML contenente la configurazione delle sostituzioni che sto eseguendo su AWB. -- Mess what a happiness! 01:21, 31 lug 2017 (CEST)

Disponibile al massimo finché necessario. Fammi avere l'XML come preferisci e sono già pronto a partire. Mi chiedo però se non sia il caso di aggiungere anche la correzione delle firme (che posso condividere io).--Daimona Eaytoy (Scrivimi!) 10:06, 31 lug 2017 (CEST)

Vedo che di recente babbo lint ci ha regalato una nuova categoria ad alta priorità: "Tidy whitespace bug". Di cosa si tratta, o meglio, cosa c'è esattamente da correggere? Dai casi riportati non riesco a capirlo perché per ora sono listati pochissimi errori in ns0, tutti provenienti da template, ma tali template non compaiono nel loro settore filtrando gli errori. Qualcuno che gentilmente sa spiegare?--Daimona Eaytoy (Scrivimi!) 18:51, 20 ago 2017 (CEST)

Questa evidenziazionesu en.wiki ti può aiutare? --ValterVB (msg) 19:05, 20 ago 2017 (CEST)--ValterVB (msg) 19:05, 20 ago 2017 (CEST)

[@ ValterVB] Meglio di niente, ho visto che un sacco di errori dipendono da {{Giocatore in rosa}}, in cui come per quello che mi hai linkato il problema deriva da uno <span style="white-space:nowrap;">...</span>. L'unica supposizione che posso fare è che la presenza, all'interno di tale span, di uno spazio indivisibile generi qualche sorta di errore dato che lo span dovrebbe inserirli da solo, ma non ne sono certo. P. S. Ho spostato gli interventi nella sezione principale, che è quella adatta.--Daimona Eaytoy (Scrivimi!) 19:12, 20 ago 2017 (CEST)

Non fate nulla, la spiegazione degli errori è qui e usa come esempio proprio it.wiki, ma la nota in cima alla pagina svela che forse alcuni errori inutili da correggere saranno rimossi nei prossimi tempi. Vediamo prima cosa succede e poi cerchiamo di capire il da farsi solo ove necessario.--Sakretsu (炸裂) 19:49, 20 ago 2017 (CEST)

Lol, che ci crediate o no ho appena trovato il link e stavo per metterlo, un minuto dopo Sakretsu. Per ora attendiamo, comunque la correzione sembra relativamente semplice e automatizzabile rispetto alle altre.--Daimona Eaytoy (Scrivimi!) 19:53, 20 ago 2017 (CEST)

E meno male... Tra parentesi, io avevo finito di correggere i pochi errori tag "table" rimasti in NS0, ma chi è l'eroe che ha ridotto le rimanenti 550 pagine a 136? Veramente una faticaccia...--Sakretsu (炸裂) 20:06, 20 ago 2017 (CEST)

[@ Sakretsu] Eh già, chissà chi sarà mai... :-D Tornando al discorso sulla nuova tipologia di errori, ho osservato che sono generati principalmente da 2 fattori: 1) spazio lasciato prima delle parentesi di chiusura in {{Tutto attaccato}} (e che va quindi rimosso); 2) tag "br" piazzati subito dopo {{Giocatore in rosa}} (in particolare nei template delle rose calcistiche e ciclistiche), anch'essi rimovibili senza troppi rimpianti. Ovviamente ce ne sono molti altri, ma già solo eliminando questi casi il quantitativo si ridimensionerebbe all'istante. -- Mess what a happiness! 22:49, 20 ago 2017 (CEST)

[← Rientro] Segnalo un problemino collaterale col tag center: al momento lo stiamo sostituendo con <div align="center">, ma anche questa sintassi non è supportata in HTML5. Occorrerebbe quindi correggere anche le correzioni (tanto mica c'era già abbastanza da fare, no no).--Daimona Eaytoy (Scrivimi!) 14:51, 15 set 2017 (CEST)

Mica tanto problemino :) Quindi come li sistemiamo? --ValterVB (msg) 21:19, 15 set 2017 (CEST)

Eh no, proprio per niente. Come riportato nella documentazione linkata, occorre usare un po' di CSS e mettere style="text-align:center". Il fatto che l'attributo sia obsoleto ovviamente non ha a che vedere con gli errori di Lint, né questo è l'unico obsoleto. Ma se dobbiamo adeguarci ad HTML5, tanto vale farlo per bene.--Daimona Eaytoy (Scrivimi!) 21:30, 15 set 2017 (CEST)

Non c'è motivo di cambiare codici che faranno il loro dovere anche dopo il passaggio. Anche se HTML5 non supporta nulla, sono i browser che convertono l'informazione nel risultato voluto. A noi interessa solo questo.--Sakretsu (炸裂) 22:06, 15 set 2017 (CEST)

Che la sostituzione non sia prioritaria è vero, però personalmente direi di metterla almeno come fix minore (cioè da eseguire solo se nella stessa pagina è presente un fix normale), dato che rimane una forma non totalmente corretta. E anche per ridurre un eventuale lavoro futuro in cui per motivi tecnici dovremo occuparci anche degli attributi.--Daimona Eaytoy (Scrivimi!) 11:03, 16 set 2017 (CEST)

Oggi modifichiamo 800000 voci con un codice "migliore" che in realtà non cambia nulla al livello di risultato. Tra altri 10 anni ci sarà un ulteriore passaggio da RemexHTML a BestHTML che non supporterà nemmeno il codice che stiamo per cambiare ora per questioni di previdenza. Morale della favola? Abbiamo fatto un lavoro inutile e per di più incompleto, perché HTML5 non supporta nemmeno i tag table e altre cose basilari che non si sa con cosa dovrebbero essere sostituite. Di conseguenza, per me c'è sempre e solo da aspettare la sentenza della Wikimedia Foundation. Nel peggiore dei casi, ci daranno altro lavoro da fare nei prossimi anni, ma sempre con mesi di tempo di anticipo per fare tutto, quindi non c'è fretta né è detto che HTML5 non inizierà a supportare più cose e che ci stiamo facendo problemi per nulla.--Sakretsu (炸裂) 11:29, 16 set 2017 (CEST)

L'idea infatti è di modificarne il minimo possibile, evitando semmai di introdurne altri. Sul fatto che HTML5 non supporti nulla si potrebbe parlare per ore, senza contare il fatto che ogni pagina è zeppa di errori; provare per credere: basta inserire un URL qualsiasi sul validatore W3C. Concordo comunque sull'evitare di focalizzarsi sulla correzione dei suddetti, ma almeno proseguiamo convertendo i center nella versione con lo style, che dovrebbe in teoria campare un po' di più dell'altra: magari sarà compatibile fino al BestHTML e andrà cambiata in un futuro lontano per l'adeguamento a Ultimate42SuperHTML--Daimona Eaytoy (Scrivimi!) 12:14, 16 set 2017 (CEST)

font -> span

Sto sostituendo il tag font con lo span in alcuni template, ma non sono equivalenti, in caso di link come dovrebbe essere sostituito? es prima e dopo guardate il titolo del template: tutto bianco prima, bianco solo il testo ma non il link, dopo. --ValterVB (msg) 12:14, 22 lug 2017 (CEST)

Non so risponderti, però faccio notare di un problema simile: sostituendo <tt> con <code> il testo viene evidenziato di bianco, e ciò può essere fastidioso ad esempio nei manuali di template con sfondo colorato. Per capirsi: Questo è un code, Questo è un tt. Potete vedere la differenza grazie allo sfondo verde di questa pagina, utilizzato anche in vari template. Anche questa come la risolviamo?--Daimona Eaytoy (Scrivimi!) 12:33, 22 lug 2017 (CEST)

[× Conflitto di modifiche] Due appunti: 1. color:#FFFFFF e non color=#FFFFFF; 2. lo span deve essere applicato sul testo e non sull'intero link, quindi diff^89172731 con pipelink. Poi tralasciamo il discorso dell'accessibilità in questa sede...--Sakretsu (炸裂) 12:37, 22 lug 2017 (CEST)

Per il tt, si può riprodurre quello che fa con uno span, e cioè: prova <span style="font-family:monospace,'Courier'">prova</span> oppure impostando lo stile del tag code: prova <code style="background-color:transparent; border:none">prova</code>.--Sakretsu (炸裂) 12:52, 22 lug 2017 (CEST)

Ottimo. Per semplificare ulteriormente potremmo anche trasferire lo stile su una classe css da mettere qui, o anche creare un template che inserisca il codice sopra. Bisogna vedere quanto ne vale la pena.--Daimona Eaytoy (Scrivimi!) 12:59, 22 lug 2017 (CEST)

Benissimo, quand'è pronto vado di adminbot perché due terzi delle occorrenze (a occhio) sono in pdc protette. --Vito (msg) 11:34, 23 lug 2017 (CEST)

(rientro) Riprendo questo discorso a un mese di distanza per segnalarvi che esiste il tag <kbd>, il quale risulta essere un buon sostituto di <tt> e non presenta l'inconveniente dello sfondo bianco generato da <code>. Io lo sto già utilizzando per correggere la firma di Yuma, che al suo interno cela il tag <tt>. -- Mess what a happiness! 11:49, 22 ago 2017 (CEST)

Come ho anticipato a Mess qualche giorno fa, ho elaborato questo moduletto per la conversione dei font in span. Per utilizzarlo è sufficiente una regex che prenda un testo del tipo <font........./font> e lo sostituisca con {{subst:#invoke:Sandbox/Daimona Eaytoy/Test4|main|1=$&}} dove $& è l'intero match della regex. Il modulo provvede da solo a convertire la dimensione del testo in px, aggiungere il cancelletto al colore esadecimale se manca, mettere tutto nello style dello span, eliminando ciò che non serve, aggiustando a dovere punti e virgola e virgolette e ad eliminare i parametri duplicati. Inoltre, se il testo tra i tag font consiste in un (solo) wikilink, porta lo span dentro al link per renderlo effettivo. Il limite è che il testo tra i tag deve O essere privo di quadre aperte O essere un wikilink, altrimenti per sicurezza non viene fatto nulla e restituisce il testo di partenza. Dopo questa presentazione degna della miglior campagna pubblicitaria, devo avvisare che conosco pochissimo il lua e che il modulo potrebbe fare un tantinello schifo, ma dai test preliminari sembra fare il suo sporco lavoro ed è a disposizione di chiunque voglia dedicarsi alla conversione dei font. Anche se è una mia sandbox (volendo si può spostare a modulo vero e proprio ma non so quanto serva) potete modificarlo ad libitum anche senza chiedere, magari scrivendo da qualche parte le novità e/o avvisando se le modifiche sono davvero sostanziali. Buon lavoro (e divertimento). --Daimona Eaytoy (Scrivimi!) 13:28, 4 set 2017 (CEST)

Complimenti per l'originalità della soluzione :) --Valerio Bozzolan (msg) 13:52, 4 set 2017 (CEST)

Grazie, del resto non era comodo utilizzare un esercito di regex per una sola conversione. Così in una botta fai tutto, pagando però il prezzo di non poter vedere il risultato live su AWB.--Daimona Eaytoy (Scrivimi!) 14:04, 4 set 2017 (CEST)

Supporto su voy

Ho difficoltà con la risoluzione dei problemi indicati in questa pagina (ho scritto in inglese per chiedere se necessario supporto "internazionale").

Avete modo di darmi mano? Ho fatto diversi test, specialmente nel primo caso ma non ne sono venuto a capo. Una volta risolti li condivido con le altre versioni linguistiche che hanno by design lo stesso problema. --Andyrom75 (discussioni) 21:39, 22 lug 2017 (CEST)

[@ Andyrom75] il tag span modifica solo testo, ergo se si trova dentro un altro paragrafo p generato dai due punti, va in panne. Normalmente si risolve tramutando lo span in un contenitore div, ma ho eliminato tutto in quanto le classi aggiunte non esistono su it.voy. Quanto al secondo problema, il testo alt deve essere solo testo senza tag come il corsivo.--Sakretsu (炸裂) 22:01, 22 lug 2017 (CEST)

[@ Sakretsu], tra le varie prove avevo anche utilizzato un DIV al posto dello SPAN, ma il problema permaneva. Nel caso dell'alt, capita a volte di avere la necessità di avere parti non in corsivo. Dal codice HTML però non capisco quale problema gli dia. PS Dimenticavo: grazie mille! ;-) --Andyrom75 (discussioni) 22:10, 22 lug 2017 (CEST)

Quello non è un problema HTML, è il software Mediawiki che non capisce dove si vuole arrivare. Due apici li tramuta in corsivo, tre in grassetto, quattro in un grassetto + un apice di resto, cinque in grassetto + corsivo. Se il corsivo non ci vuole in rari casi, basta usare in quelle voci <span style="font-style: normal"></span>, altrimenti va proprio tolto dal listing.--Sakretsu (炸裂) 22:35, 22 lug 2017 (CEST)

[@ Sakretsu] il listing editor ha smesso di funzionare perché utilizza almeno alcune di quelle classi. Provo a ripristinare solo quelle che vedo nel codice per vedere se riparte. Tuttavia se riesci a trovare una soluzione col DIV sarebbe preferibile. Per l'eliminazione del corsivo mi sembra un'ottima alternativa, vedo di creare un template ad-hoc PS Se già c'è su Wikipedia fammi sapere così lo chiamo nello stesso modo. --Andyrom75 (discussioni) 22:40, 22 lug 2017 (CEST)

[@ Sakretsu] con quelle che ho ripristinato sembrerebbe funzionare, ma non vorrei ci siano anomalie che non ho notato. --Andyrom75 (discussioni) 22:52, 22 lug 2017 (CEST)

[@ Sakretsu] ho aggiornato il codice sulla mia pagina di test per mostrare quello che viene fuori adesso. Nonostante il DIV che racchiude l'intero listing e l'assenza di tag che racchiudano la descrizione, il DL viene comunque piazzato al di fuori del DIV principale (direi inspiegabilmente). Idee? --Andyrom75 (discussioni) 23:31, 22 lug 2017 (CEST)

[@ Sakretsu] ti ho fatto admin temporaneo qui su it.wiki, se ti serve per it.voy scrivete due righe al bar per pro-forma e ci penso io. --Vito (msg) 10:06, 23 lug 2017 (CEST)

Singola pagina

Domanda: Come si fa a sapere se una specifica pagina ha qualche lint error? E.g. Speciale:PermaLink/89235545 --Valerio Bozzolan (msg) 17:33, 24 lug 2017 (CEST)

[@ Sakretsu] Sgamato :) Come facevi a sapere quando la tua sandbox spariva dalla lista? Mica l'avrai scorsa tutta... D: --Valerio Bozzolan (msg) 17:50, 24 lug 2017 (CEST)

[@ Valerio Bozzolan] Appare sempre tra le ultime pagine registrate tra gli errori (le puoi anche filtrare per namespace).--Sakretsu (炸裂) 17:52, 24 lug 2017 (CEST)

Fatto Ho appena scoperto che se si va in "Informazioni pagina" c'è una sezione dedicata ai "Errori di Lint" :D --Valerio Bozzolan (msg) 22:47, 11 ago 2017 (CEST)

Supporto su pms.wikipedia

Ho segnalato l'argomento sulla wiki in piemontese. Credo che uno dei problemi principali siano i 2 template che ho evidenziato in quella discussione che viaggiano accoppiati. Ho lasciato detto che se hanno problemi possono chiedere di qua, ma se qualcuno casualmente vede come risolvere  :) --ValterVB (msg) 21:12, 24 lug 2017 (CEST)

Confermo la richiesta di aiuto su pms.wikipedia! Grazie mille --Lissànder (msg) 23:05, 25 lug 2017 (CEST)

Il Sole 24 ORE

Facendo patrolling mi sono imbattuto in un errore "Errore Lua in mw.wikibase.entity.lua alla linea 37: data.schemaVersion must be a number, got nil instead." nella pagina in oggetto. Non so se centra con le modifiche che vengono apportate in questi giorni per il cambio di parser --LucaRosty (Scrivimi) 16:32, 26 lug 2017 (CEST)

[@ Lucarosty] Negativo, quello dipende da problemi "ai piani alti", ne avevamo parlato qui e su phabricator (link nella discussione) stanno cercando una soluzione.--Daimona Eaytoy (Scrivimi!) 16:40, 26 lug 2017 (CEST)

Grazie--LucaRosty (Scrivimi) 16:44, 26 lug 2017 (CEST)

Tag spaiati o anche no

Dopo questa modifica si crea uno spazio bianco in eccesso sotto le immagini delle divise --Bultro (m) 15:55, 29 lug 2017 (CEST)

Corretto diff^89446358.--Sakretsu (炸裂) 16:17, 29 lug 2017 (CEST)

Oppure no, vedo un attimo se si può convertire coi tag td.--Sakretsu (炸裂) 16:24, 29 lug 2017 (CEST) A posto --Sakretsu (炸裂) 16:36, 29 lug 2017 (CEST)

Numeri

Ci sarebbe mw:Parsing/Replacing Tidy/Linter/Stats/July31, per gli interessati. Elitre (WMF) (msg) 17:28, 31 lug 2017 (CEST)

Attiva parser strumento di migrazione

E' già un po' che ho notato nelle preferenze nella sezione Casella di modifica l'opzione selezionabile "Attiva parser strumento di migrazione", una volta attivata sulla sx appare il link "Modifica con strumento di migrazione" serve per fare il confronto della pagina fra parser attuale e prossimo parser? (Esempio) --ValterVB (msg) 20:10, 31 ago 2017 (CEST)

[@ ValterVB] A quanto pare sì. Ottima scoperta!--Daimona Eaytoy (Scrivimi!) 20:28, 31 ago 2017 (CEST)

Sfortunatamente era utile solo per gli errori di Lint di alta priorità. Purtroppo la maggior parte degli errori rimasti non provocano nessun effetto visivo lampante.--Sakretsu (炸裂) 20:46, 31 ago 2017 (CEST)

Template alternate

Ciao a tutti, mentre cercavo di ridurre alcuni errori nel portali ho notato che il Template:Alternate ha dei problemi se si inserisce all'interno dei parametri il tag "div" con attributi (vedi align e style) al posto del tag "center" --LucaRosty (Scrivimi) 14:13, 8 set 2017 (CEST)

[@ Lucarosty] Ciao, potresti cortesemente linkare un esempio? Comunque così a occhio direi che è dovuto alla sintassi stessa dei template e al conflitto con i simboli di uguale. In pratica, succede questo. Per ovviare sarebbe necessario chiamare i parametri dell'alternate come |1=...|2=... e così via, sempre che il problema sia quello.--Daimona Eaytoy (Scrivimi!) 14:29, 8 set 2017 (CEST)--Daimona Eaytoy (Scrivimi!) 14:28, 8 set 2017 (CEST)

[@ Daimona Eaytoy] Portale:Asti/Immagine/Multiview, questo è un esempio --LucaRosty (Scrivimi) 14:50, 8 set 2017 (CEST)

[@ Daimona Eaytoy] Confermo che mettendo i parametri 1= ... il template comincia a funzionare correttamente --LucaRosty (Scrivimi) 14:53, 8 set 2017 (CEST)

[@ Lucarosty] Eh sì, l'errore è dovuto a quello, occorre specificare i nomi dei parametri o sostituirli con numeri progressivi se si vogliono inserire segni di uguale all'interno. --Daimona Eaytoy (Scrivimi!) 15:03, 8 set 2017 (CEST)

Va fatto lo stesso anche per {{Immagine grande}}. In compenso per il template {{Diagramma scacchi piccolo}} non saprei come fare: esempio. Numerare tutto mi sa che complica la cosa e fa perdere di chiarezza il template. --ValterVB (msg) 17:26, 8 set 2017 (CEST)

Numerare il diagramma scacchi è improponibile, personalmente vedo due soluzioni: 1-si eliminano brutalmente tutti i center 2-si modifica il modulo in modo tale che quanto inserito in quel parametro sia automaticamente centrato, rimuovendo di conseguenza tutti i center e i tag div rimasti.— Questo commento senza la firma utente è stato inserito da Daimona Eaytoy (discussioni · contributi) 19:24, 8 set 2017 (CEST).

Esattamente, quei tag vanno rimossi a prescindere.--Sakretsu (炸裂) 23:17, 8 set 2017 (CEST)

Toh, il mio primo intervento non firmato :-D Sì, solo che prima servirebbe una richiestina nel progetto di competenza, che cerco di andare a fare giusto adesso.--Daimona Eaytoy (Scrivimi!) 10:26, 9 set 2017 (CEST)

Speciale:LintErrors/bogus-image-options

Tra le varie segnalazioni di errore ci sono anche queste, alcune evidentemente sono giuste altre sembra di no. In particolare:

• vengono segnalati gli errori quando nella didascalia sono presenti dei tmp o ref esempio
• segnala errore gli alt non dichiarati, mi confermate che è obbligatorio alt= esempio^91078763 in minuscolo esempio^91078801 e non può essere omesso?. --ZioNicco (msg) 14:26, 8 set 2017 (CEST)

<big> </big>

Come lo sostituite? Io ho usato <div style="font-size:118%"> </div> che, usando l'occhiometro, dà le stesse dimensioni. Ci sono altre soluzioni? --ValterVB (msg) 17:52, 8 set 2017 (CEST)

[@ ValterVB] È più o meno lo stesso problema della conversione del parametro size per font=>span. Avevo chiesto anche in officina, alla fine la soluzione è usare le dimensioni letterali. Questo caso non fa eccezione, in teoria il risultato davvero identico è con uno span (o div, a seconda) che abbia nello stile font-size:larger. Dai test occhiometrici in sandbox e documentazione W3C sembra la strada migliore.--Daimona Eaytoy (Scrivimi!) 19:17, 8 set 2017 (CEST)

Anzi, c'è di più. Questa pagina consiglia le sintassi alternative da usare. La sezione multi-big suppongo sia per i tag big annidati, tuttavia non sono convinto della totale correttezza: le corrispondenze per le dimensioni della sezione sopra mi risultano errate, quelli nella colonna di destra li vedo tutti più piccoli.--Daimona Eaytoy (Scrivimi!) 19:22, 8 set 2017 (CEST)

Personalmente la soluzione in percentuale la preferisco, in quanto si dovrebbe avere la matematica certezza del rapporto fra le varie dimensioni indipendentemente dal browser usato, i letterali ho paura che possano ancora soffrire dell'implementazione fatta all'interno dei browser. Forse per questo che le indicazioni date in quella pagina sembrano non corrispondere perfettamente all'occhiometro. Magari su un browser che segue pedissequamente le indicazioni HTML 5 e quelle precedenti il 120% corrisponde esattamente al <big> --ValterVB (msg) 22:50, 8 set 2017 (CEST)

In teoria percentuale e larger danno lo stesso risultato, però non so dirlo con certezza né ho fatto test. I letterali sono quelli consigliati da W3C per sostituire l'attributo size, quindi in teoria dovrebbero essere quelli più giusti da usare; anche perché essi, così come i numeri, non definiscono esplicitamente alcuna grandezza (a differenza i.e. di px, em etc) e credo possano essere interpretati a piacimento dai vari browser. Comunque mi sono espresso male: la tabella dei big la vedo correttamente, quella che non mi torna è la tabella sopra con le "font size ...". A questo punto però, visto anche che sto cercando una soluzione stabile per questo, mi viene un dubbio sulle conversioni: procedo con i letterali come da indicazioni W3C o me ne sbatto e torno a sostituire in em (o, equivalentemente, px) come da pagina di aiuto mw?--Daimona Eaytoy (Scrivimi!) 10:31, 9 set 2017 (CEST)

Barra degli strumenti di modifica

Non sarebbe il caso di modificare la Barra degli strumenti di modifica per evitare che si possa inserire il tag <big>…</big> ? Giusto per evitare che da una parte li leviamo e dall'altra li reinseriscono. --ValterVB (msg) 20:51, 10 set 2017 (CEST)

Certamente. Poi potrebbe essere una buona idea tenere, per un certo periodo, un abusefilter che rilevi inserimento di big/center/font e simili e avvisi l'utente. Ovviamente da attivare quando non ce ne saranno (quasi) più, per evitare che gli utenti continuino a reinserirli.--Daimona Eaytoy (Scrivimi!) 21:14, 10 set 2017 (CEST)

Per me va bene.--Sakretsu (炸裂) 21:53, 10 set 2017 (CEST)

OK, allora serve un volontario perché non so dove da toccare :) C'è da cambiare il <big>…</big> con lo <span style="font-size:larger">...</span> e naturalmente si perderà la possibilità del multi big. --ValterVB (msg) 22:27, 10 set 2017 (CEST)

Per i multi-big non c'è problema, con il font-size=larger funziona allo stesso modo essendo un ridimensionamento relativo. È solo più scomodo. --Daimona Eaytoy (Scrivimi!) 22:46, 10 set 2017 (CEST)

Ah-ehm, il tasto dovrebbe essere gestito da mw:Extension:WikiEditor e addirittura la traduzione si trova su translatewiki. Forse non c'è modo di modificarlo senza una richiesta su Phabricator.--Sakretsu (炸裂) 23:41, 10 set 2017 (CEST)

Uh, tanto meglio allora... Quanto spiegato qui suppongo non si possa fare, vero? --Daimona Eaytoy (Scrivimi!) 13:57, 11 set 2017 (CEST)

Avevo dato un'occhiata, ma non me ne intendo di Javascript e a prescindere non mi sembra una buona idea appesantire il caricamento della toolbar solo per modificare un tasto generalmente poco usato.--Sakretsu (炸裂) 14:28, 11 set 2017 (CEST)

Template giornaliero

In questi giorni mi sono scontrato un paio di volte con dei problemi legati al template giornaliero. Facendo il cambio del tag center con il div e mettendo i parametri 1=, 2= ... sono incappato nell'errore seguente Avvertenza: Portale:Diocesi/Vetrina chiama Template:Giornaliero con più di un valore per il parametro "1". Verrà utilizzato solo l'ultimo valore fornito.. Non riesco a capire dove sia il problema in quanto i parametri dovrebbero essere messi in modo corretto tanto che su 5 parametri solo due danno problemi! Un esempio qui: Portale:Diocesi/Vetrina --LucaRosty (Scrivimi) 09:03, 14 set 2017 (CEST)

Altro esempio qui. In questo caso il problema è sempre il parametro 1= che se inserito produce l'errore --LucaRosty (Scrivimi) 09:07, 14 set 2017 (CEST)

Se cambi dei parametri numerati impilicitamente e li nomini esplicitamente (campi il primo da "|=" in "|1=", il secondo "|=" in "|2=") devi cambiarli tutti o il primo che lasci non nominato viene numerato implicitamente "1" e va in conflitto con quello esplicito a cui hai assegnato esplicitamente "1=". Nel primo esempio avevi lasciato non nominato l'ultimo parametro del template (che da un "10" implicito diventa un "1" implicito e va in conflitto con il primo "1" implicito che hai fatto diventare un "1" esplicito). --Moroboshi ^scrivimi 09:39, 14 set 2017 (CEST)

Grazie delle informazioni. Ho risolto --LucaRosty (Scrivimi) 14:43, 14 set 2017 (CEST)

Portale:Aviazione

Nel tentativo di sistemare gli errori relativi al portale in oggetto (in particolare su Portale:Aviazione/Categorie) ho visto che viene segnalato un tag spaiato nella pagina delle categorie quando mi sarei aspettato di vedere un tag non chiuso in quanto nella sottopagina Portale:Aviazione/Header viene aperta una tabella che non viene chiusa da nessuna parte. La cosa ancora più strana è che lo stesso errore si dovrebbe presentare nella pagina principale del portale invece quella pagina non presenta lo stesso errore. Come si deve procedere in questi casi? --LucaRosty (Scrivimi) 10:25, 20 set 2017 (CEST)

MediaWiki:Edittools

Alla luce di questa modifica mi sono chiesto: Edittools va modificato, giusto? Dato che sotto il menu Wiki indica ancora <tt></tt> e, temo, altri codici da sostituire.--ƒringio · ✉ 19:54, 21 set 2017 (CEST)

Certamente, ho Fatto, grazie per la segnalazione.--Daimona Eaytoy (Scrivimi!) 20:00, 21 set 2017 (CEST)

Template T:TabellaTemplate e T:Parametro

Ho notato un problema con i template in oggetto, non ho indagato il problema ma volevo chiedere se qualcuno che ha seguito i problemi legati a Tidy/RemexHTML sa da cosa può dipendere. Come si può vedere in questa sandbox, e in qualunque manuale di template, da qualche tempo si crea uno spazio aggiuntivo dopo il primo parametro e prima dell'ultimo, inoltre (e questo è il problema grave) quando si fa copia incolla, rimane una riga vuota dopo il primo parametro. Guardando l'HTML generato vedo un tag "p" che si apre proprio dopo il primo parametro e si chiude prima dell'ultimo. --Rotpunkt (msg) 21:39, 21 set 2017 (CEST)

Dovrei aver risolto diff^91458809, in modo tale che entrambi i tag div non possano finire vittima del software Mediawiki che li integra in altri tag automatici come il p.--Sakretsu (炸裂) 23:01, 21 set 2017 (CEST)

Stupendo, grazie. --Rotpunkt (msg) 23:24, 21 set 2017 (CEST)

Punto della situazione

Ho aggiunto un filtro pubblico, Speciale:FiltroAntiAbusi/423, per avvisare l'utente in caso di inserimento di tag center. Vediamo per un po' come va, se non ci sono falsi positivi E i tag vengono inseriti lo stesso, faccio impedire l'azione. Fra poco aggiungerò anche il tag font, anch'esso quasi estinto in ns0, ma prima vorrei una conferma su questa modifica perché non so se il codice così modificato è ancora valido. Grazie, --Daimona Eaytoy (Scrivimi!) 22:30, 21 set 2017 (CEST) Dimenticavo, servirebbe anche una modifica al tag center su questa pagina, che però io non mi azzardo a fare.--Daimona Eaytoy (Scrivimi!) 22:32, 21 set 2017 (CEST)

Riguardo agli esempi nelle voci... nessuno vieta di aggirare^91464402 il problema :P --Valerio Bozzolan (msg) 01:20, 22 set 2017 (CEST)

Uh, non ci avevo neanche pensato all'intestazione. Grazie mille, --Daimona Eaytoy (Scrivimi!) 10:27, 22 set 2017 (CEST)

Eventuamente sono inseribili anche come entità html <CENTER>.--Moroboshi ^scrivimi 11:00, 22 set 2017 (CEST)

Cioè? Comunque sto pensando ad un pattern per estendere il filtro agli altri namespace (quando avrò finito le correzioni degli obsoleti, al momento in priorità massima), dove c'è il rischio concreto che il tag venga inserito a scopo esemplificativo. Per farlo però vorrei una rapida conferma sui possibili modi per inserire un tag evitandone l'interpretazione: che io sappia, abbiamo i nowiki, i pre e il template {{Codice}} con relativo redirect. Escludo volutamente l'inserimento con lt/gt (come fatto qui sopra da Moroboshi) perché già viene verificata la presenza di < e >, e i commenti perché non vanno inseriti neanche lì. Ce ne sono altri che non mi vengono in mente?--Daimona Eaytoy (Scrivimi!) 12:25, 22 set 2017 (CEST)

Elenchi e li non chiusi

Sono un po' insospettito dalla marea di voci con questo specifico tag non chiuso:

# <li value="8">Brano
# <li>Altro titolo

Non è che è rimasto qualche manuale che suggerisce ancora una roba del genere? --Valerio Bozzolan (msg) 19:32, 22 set 2017 (CEST)

Cercando la seconda riga (senza il due) non trovo nulla da nessuna parte, se non qui, quindi non saprei.--Daimona Eaytoy (Scrivimi!) 19:37, 22 set 2017 (CEST)

No voglio dire in generale, elencare cose (spessissimo titoli dei brani) senza chiudere il tag. Es: diff^91472874 --Valerio Bozzolan (msg) 20:01, 22 set 2017 (CEST)

Ah, pensavo fosse tipo un'intestazione. Non trovo nulla, comunque; magari semplicemente il pattern è stato ideato da un utente che se l'è messo in sandbox e l'ha usato per creare parecchie voci, che a loro volta sono state usate come modello. Anche se in effetti a giro ce ne sono parecchi.--Daimona Eaytoy (Scrivimi!) 20:13, 22 set 2017 (CEST)

Sarà proprio come dici. Quanto sarebbe bello avere un wikiblame globale? --Valerio Bozzolan (msg) 20:27, 22 set 2017 (CEST)

Una ricerca sarebbe effettuabile in qualche comodo secolo, suppongo :-D --Daimona Eaytoy (Scrivimi!) 20:45, 22 set 2017 (CEST)

Considerando che c'erano 300 voci di rugby con lo stesso codice errato copincollato da vari utenti, direi che è ben possibile. Col tempo più che i manuali sono le voci stesse a dare il buono o il cattivo esempio.--Sakretsu (炸裂) 21:34, 22 set 2017 (CEST)

Che bello scoprire che...

...il tag <font> era stato segnalato come deprecato già 10 anni fa, ma che non tutti abbiano seguito quell'indicazione. Va be', ormai è solo questione di tempo, dato che col mio massiccio intervento in NS4 ho quasi rimosso completamente quel tag dalle firme di numerosi utenti. -- Mess what a happiness! 17:18, 24 set 2017 (CEST)

Eh sì, e pensa bello sapere che da altrettanto tempo esiste questo avviso. Non voglio nemmeno provare a pensare a quante correzioni avrebbe evitato il seguirlo fin da subito. Ad ogni modo sì, per fortuna gli obsoleti se ne stanno andando e vedrò di evitarne il ritorno con il filtro.--Daimona Eaytoy (Scrivimi!) 17:21, 24 set 2017 (CEST)

Nuove categorie di errori

Vi segnalo l'introduzione di 2 nuove categorie di errori: Speciale:LintErrors/html5-misnesting (per info vedi qui) e Speciale:LintErrors/multi-colon-escape (per info vedi qui). -- Mess what a happiness! 12:00, 29 set 2017 (CEST)

E io approfitto per segnalare che la nuova categoria di misnested raccoglie i casi più gravi, fra cui quello del {{cn}} spalmato su più righe, che come si può vedere ad esempio qui (sez. 1.2) viene brutalmente tagliato dal nuovo parser. Aggiungo che non sarebbe male ampliare il filtro esistente dei tag obsoleti per fargli beccare questo genere di errori e, quando sarà quasi immune da FP, fargli impedire l'azione. Del resto c'è già abbastanza lavoro da fare, non è propriamente comodo se laggente continua ad aggiungerne altri.--Daimona Eaytoy (Scrivimi!) 12:06, 29 set 2017 (CEST)

T:Citazione

Da ormai alcune settimane o mesi il {{citazione}}, che utilizza una tabella, nel caso in cui contenga tag <br/> (es. in Rigmo) visualizza uno spazio anomalo dopo la prima riga. Cosa ne pensate? --Epìdosis 15:23, 29 set 2017 (CEST)

Mi viene il dubbio che sia questo stesso problema. Rimetto comunque la questione a qualcuno più esperto, non voglio fare casini.--Daimona Eaytoy (Scrivimi!) 15:30, 29 set 2017 (CEST)

Il problema esiste da prima. Come da manuale, il testo va inserito solo di seguito coi br in mezzo e senza andate a capo. Tuttavia se c'è consenso, io direi di applicare la stessa soluzione che ho applicato nella discussione segnalata da Daimona per lasciare che gli utenti possano spezzare il testo e renderlo più facilmente leggibile nel wikicodice.--Sakretsu (炸裂) 16:12, 29 set 2017 (CEST)

Dopo aver scritto ho controllato ed effettivamente è il software che aggiunge un tag p spezzando tutto. Purtroppo i manuali spesso e volentieri sono ignorati (non che sia sempre un male) e sono favorevole alla correzione.--Daimona Eaytoy (Scrivimi!) 16:18, 29 set 2017 (CEST)

[@ Epìdosis] ho aggiornato il template, non dovresti più riscontrare il problema.--Sakretsu (炸裂) 23:30, 17 ott 2017 (CEST)

T:§

Mi sono accorto che la nuova categoria di tag annidati malamente male annovera (almeno) alcune voci calcistiche (esempio) in cui la rottura è causata dal template {{§}}, all'interno del quale è inserito {{Incontro di club}}. Il problema è che il primo utilizza un tag span, che si rompe quando prova ad avvolgere la tabella etc del secondo. Una soluzione di per sé sarebbe modificare il template:§ affinché utilizzi un div, però questo produce spaziature indesiderate sopra e sotto il testo (basta fare una prova in sandbox con il contenuto di T:§/man). Quale potrebbe essere un'alternativa indolore?--Daimona Eaytoy (Scrivimi!) 21:22, 29 set 2017 (CEST)

Premesso che dentro il {{§}} non dovrebbe mai essere inserito qualcosa come l'{{Incontro di club}}, la soluzione è questa modifica. In sostanza, basta rimuovere § e aggiungere a ognuno di quei template rispettivamente id=1, id=2, ecc. Magari se si può fare pure con un bot andiamo di lusso.--Sakretsu (炸裂) 22:28, 29 set 2017 (CEST)

Questo è solo un esempio della fantasia che si trova a giro. La modifica posso farla io via bot, sono circa 400 pagine, ma non so quando potrò occuparmene.--Daimona Eaytoy (Scrivimi!) 09:57, 30 set 2017 (CEST)

Ho iniziato la correzione, esempio. Le due regex sembrano valide e credo di poter finire in automatica nel giro di un'oretta. Tuttavia, per complicare un po' la cosa, ho notato un altro problema: in alcune pagine (esempio) erano presenti ancore con id duplicato, quindi anche con la correzione rimangono elementi con id uguale. Nel dubbio, oltre a chiedermi perché si voglia inserire per forza un attributo HTML senza utilizzarlo correttamente, mi limito a lasciare le cose come stanno e (per rimanere in tema), passare la palla al progetto calcio.--Daimona Eaytoy (Scrivimi!) 13:54, 1 ott 2017 (CEST)

Sì, fai bene. Alla fine la nostra priorità è solo assicurarci che il codice sia corretto. Ottimo lavoro :-) --Sakretsu (炸裂) 15:04, 1 ott 2017 (CEST)

Esattamente. Segnalo che il lavoro in questione è finito e che ho aggiunto in testa a questa pagina un avviso (dal voluto effetto "cazzotto in un occhio") contenente il riassunto breve per chi giunge qui seguendo il link nell'oggetto delle modifiche o dall'avviso del filtro.--Daimona Eaytoy (Scrivimi!) 16:26, 1 ott 2017 (CEST)

Qualche novità

L'eliminazione dei tag obsoleti procede bene, abbiamo ancora circa 1000 center e 7000 font. Se qualcuno volesse dare una mano, condivido volentieri il mio xml con le correzioni del caso. Segnalo inoltre che con la risoluzione di questo task adesso i tag span di chiusura compaiono correttamente nei risultati di ricerca e consiglio di dummy-editare i template super-inclusi (come ho Fatto con {{fatto}}) per sincronizzare i LintErrors con gli errori effettivamente presenti... È un metodo che, a quanto vedo, funziona discretamente.--Daimona Eaytoy (Scrivimi!) 13:06, 6 ott 2017 (CEST)

A mali estremi, estremi rimedi: buona idea il dummy-fatto. Fra l'altro, quanto sarebbe grazioso se come novità si potesse cercare lint specifici dalla ricerca? phab:T177547 --Valerio Bozzolan (msg) 19:37, 6 ott 2017 (CEST)

Ohhhh sì! Farebbe ultra-comodo, anche se prima è necessario continuare con i dummy per sincronizzarlo. Seguo volentieri il task. Comunque un altro paio di cose che (credo) ho sempre dimenticato di dire:

1. FYI vengono segnalati al massimo 20 errori per tipo per pagina, anche se ce ne sono di più. Ho trovato pagine con centinaia di tag da chiudere e ne venivano segnalati solo 20.
2. Qualcuno riesce a capire cosa diamine ha questa pagina? Sono giorni che ci impazzisco ma non trovo l'errore.
3. Sarebbe carino anche se il software si impegnasse da solo ad evitare certe azioni con errori di lint. Esempio: impedire di salvare la firma se contiene errori. Il filtro funziona bene (nonostante qualcuno lo ignori tranquillamente), ma se ci metto una regex per riconoscere i tag non chiusi, una per gli spaiati, per i misnested etc. (che oltretutto darebbero diversi FP e FN) possiamo anche iniziare ad abituarci a salvare sì e no una modifica al minuto.

Prevedo comunque di estinguere anche i tag center in settimana.--Daimona Eaytoy (Scrivimi!) 19:51, 6 ott 2017 (CEST) E ancora, dimenticavo: dummyeditate furiosamente i template più inclusi se vedete che generano qualche errore particolare, e non esitate ad usare il mio modulo per le correzioni: in queste settimane ha dato pochissimi problemi già risolti.--Daimona Eaytoy (Scrivimi!) 19:55, 6 ott 2017 (CEST)

Per quell'errore specifico, stavano parlando di un template da creare e hanno mancato un nowiki diff^91812206 per mostrare il codice (se 1 non è compilato, i due punti si attaccano ed esce fuori il malfamato escape di due punti multipli). Quanto al dummyeditare i template: 1) quando possibile, tentate di fare un solo dummy edit che non costringa anche a riannullare (giusto per non intasare le cronologie); 2) tenete conto che ogni dummyedit comporta l'aumento della coda di voci da aggiornare, per cui cercate di farli a intervalli regolari in modo da ridurre il carico sui server.--Sakretsu (炸裂) 20:02, 6 ott 2017 (CEST)

Ma guarda te, io avevo cercato tutte le combinazioni possibili di due punti senza trovare nulla; grazie mille! Solitamente questi template hanno cronologie snelle e il peso di due edit è poco; riguardo alla coda sono d'accordo, ma del resto non sono molti i template che necessitano di questo intervento.--Daimona Eaytoy (Scrivimi!) 22:13, 6 ott 2017 (CEST)

Ci mancava questa...

Dopo averli estinti negli ultimi giorni, oggi ho notato una ricomparsa relativamente massiccia di tag center nelle discussioni utente. Andando a indagare, la causa è la rivista This month in GLAM, questa qua per intendersi, che annovera dei tag center e font. Ne avevo corretti diversi ultimamente ma speravo che si fossero aggiornati anche loro, cosa che evidentemente non è successa. Poiché avere un bot che recapita massmessage contenenti errori non è il massimo (anche se tutto sommato le persone interessate sono poche), stavo cercando di capire dove segnalare la cosa, senza però riuscirci. Va forse segnalato qui? O qui? O da qualche altra parte? Al momento purtroppo non ho troppo tempo da perderci, e se qualcuno sapesse dirmi dove scrivere gli sarei molto grato; poi posso pensare io a scrivere il messaggio. Grazie, --Daimona Eaytoy (Scrivimi!) 13:17, 9 ott 2017 (CEST)

interruzione arbitraria

Scusate, solo per dire che non è vero che <font>, <center>, <tt> e <strike> non saranno più supportati. Dove lo avete letto? Le categorie ad alta priorità non riguardano questo. Inoltre, ping Utente:Sannita che sa di un paio di quelle più urgenti (che non riguardano questi tag). Elitre (WMF) (msg) 12:58, 16 ott 2017 (CEST)

Non saranno più supportati per ora. Prima o poi, che sia questione di uno o di dieci anni, anche noi ci dovremo adeguare totalmente ad HTML5, e allora non saranno davvero supportati. Nella pagina mw sugli errori di Lint c'è scritto chiaramente che per ora e "per un po'" quei tag non daranno problemi, ma siccome arriverà il giorno in cui dovremmo sbarazzarcene, tanto vale iniziare a farlo ora che siamo in ballo. E tanto vale farlo, da subito, senza lasciare campo ad eccezioni, così da essere pronti per il passaggio "vero", al di là del momento in cui avverrà. Del resto, passando ad una sintassi strettamente HTML5 c'è solo da guadagnarci, almeno nel futuro relativamente prossimo.--Daimona Eaytoy (Scrivimi!) 13:40, 16 ott 2017 (CEST)

c'è un motivo però se sono state date delle priorità. Non c'è realmente bisogno di sobbarcarsi ora del lavoro non vitale. Non mi pare utile far sembrare che ora bisogna scalare le montagne se ciò non è accurato, uno ci rinuncia in partenza, mi pare demotivante, proprio mentre stiamo cercando di reclutarle, le persone. :) se Luca non mi anticipa domani riporto l'unico nodo davvero importante ancora da sciogliere (sono i template Cn/Citazione necessaria, mi pare). Grazie. --91.253.126.228 (msg) 14:01, 16 ott 2017 (CEST) Elitre (WMF)

Un momento, le categorie ad alta priorità sono già state tutte svuotate da tempo (ne è stata aggiunta un'altra un mese fa, ma vabbè). Non dovevamo occuparci anche degli errori medi e bassi?--Sakretsu (炸裂) 14:28, 16 ott 2017 (CEST)

La linea guida di cui sopra affida alle volontà delle comunità delle singole wiki il modo di gestire gli errori a bassa priorità, dicendo che per il momento non sono fondamentali. Però, appunto, la categoria ad alta priorità è quasi estinta, mentre i lavori per quella a bassa priorità sono in un certo senso più automatizzabili e gestibili in modo relativamente veloce via bot. Sul reclutare le persone occorre un distinguo: coloro che hanno competenze HTML scarse o nulle sarà difficile reclutarle a priori, mentre gli altri magari se vedono che c'è più lavoro da fare potrebbero essere più invogliati a dare una mano; altrimenti uno potrebbe dire "si beh, c'è un centinaio di errori da correggere, ci penserà qualcun altro". A mio avviso è bene che tutti da subito si adeguino ad HTML5, e per chi ne sa poco è più facile capire che non deve usare certi tag o mettere tutte le chiusure (nel modo giusto), piuttosto che gestire tag table di troppo. Del resto prima o poi le montagne andranno scalate, quindi è bene iniziare subito ed evitare di dover fare più lavoro dopo. Riguardo alla maggioranza degli errori ad alta priorità rimasti (i tag annidati malamente molto male), sì, parecchi derivano dal {{cn}} spalmato su più paragrafi, nel quale lo span del template viene rotto dal paragrafo aggiunto dal software. Per correggerlo ho già inserito un piccolo avvertimento nel manuale del template e iniziato a pensare ad una correzione automatica via bot, della quale però mi occuperò dopo i tag obsoleti. È infine problematico il fatto che Speciale:LintErrors non sia sincronizzata con la quantità di errori effettivamente presenti, e trovare tutte le occorrenze di quell'errore è difficile senza avere una lista già generata; questo considerando anche il fatto che (ma forse è un problema mio) non ho ancora capito come cercare le newline con elastic.--Daimona Eaytoy (Scrivimi!) 16:00, 16 ott 2017 (CEST)

Cn

[@ Daimona Eaytoy] Stavo pensando, sul {{Cn}} multi-paragrafo non so se dovremmo essere noi a smazzarci il lavoro :) Potrebbe essere il caso di coinvolgere la comunità per fare la "dovuta" sostituzione, ovvero con l'{{F}}: diff^91910718. Oppure, se davvero si vuole mettere un {{Cn}} per più righe, piuttosto sondiamo per risolvere a lungo termine trasformandolo in un modulo Lua che si auto-infili per ogni singola riga e così non dia errori :P --Valerio Bozzolan (msg) 16:35, 16 ott 2017 (CEST)

Valerio, quando si tratta di coinvolgere la comunità il lavoro diventa duro. Personalmente ho fatto qualche correzione via bot dividendolo sui paragrafi e qualcuna a mano mettendo l'F, a seconda un po' del caso. Anche perché, diciamocelo, vedere una sezione discretamente lunga costituita interamente da CN fa ridere i polli. Il cn su più righe secondo me non ha utilità: il template dovrebbe servire per segnalare specifiche affermazioni senza fonte, per tutto il resto c'è l'F. Poi si può sempre trasferirlo in lua in modo che non si incasini, ma la terrei come cosa "segreta" evitando di dire che si può spalmare e continuando a raccomandarne l'utilizzo attuale. Tra l'altro, quando avverrà il passaggio a remex l'errore diventerà palese (basta vederlo con il parsermigrationedit), e allora forse cesserà l'utilizzo sbagliato del cn.--Daimona Eaytoy (Scrivimi!) 16:46, 16 ott 2017 (CEST)

Non si può fare tramite bot? Se il cn avvolge tutto il contenuto di una sezione, si sostituisce con l'F in cima.--Sakretsu (炸裂) 17:19, 16 ott 2017 (CEST)

Se la avvolgesse interamente sì, ma capita che magari ci sia qualche frase fuori, e allora...--Daimona Eaytoy (Scrivimi!) 17:24, 16 ott 2017 (CEST)

Perfetto, allora per i casi come quello del diff di Valerio cominciate a fare una passata e a sostituirli con l'F, no? Già è qualcosa. Poi si potrebbe avere una lista per vedere quante voci hanno ancora l'errore? Se sono poche le facciamo a mano.--Sakretsu (炸裂) 17:31, 16 ott 2017 (CEST)

Infatti vorrei occuparmene dopo i tag obsoleti, per due motivi: il primo è che non voglio balzare troppo da una cosa all'altra. Il secondo è che appunto avere una lista non è semplice: come dicevo sopra, la pagina non è aggiornata e con la ricerca insource non so come si ricerchino le andate a capo.--Daimona Eaytoy (Scrivimi!) 18:35, 16 ott 2017 (CEST)

Ho messo l'elenco qui --Horcrux_九十二 21:05, 16 ott 2017 (CEST)

Poteva andare peggio.--Sakretsu (炸裂) 00:16, 17 ott 2017 (CEST)

[← Rientro][@ Horcrux92] Grazie per l'elenco. Queste sono le pagine con CN che avvolgono tutta un'intera sezione, giusto? O comprende tutti i CN con paragrafi all'interno?--Daimona Eaytoy (Scrivimi!) 11:36, 17 ott 2017 (CEST)

Tutte le sezioni aventi almeno due righe e il cui intero contenuto è incluso in {{cn}}. Le righe sono ottenute tramite \n; se pensate possa servire, posso ripetere la ricerca considerando anche <br> e varianti, ma non credo cambi molto. --Horcrux_九十二 12:51, 17 ott 2017 (CEST)

Credo che il br sia tecnicamente legittimo (non ho testato). --Valerio Bozzolan (msg) 13:58, 17 ott 2017 (CEST)

Sì sì il br è perfettamente legittimo, il problema sono solo le andate a capo consecutive che il software interpreta come "paragrafo" e ci inserisce un tag P (il quale no, non va bene). Per il momento va benissimo questo, dato che si può correggere velocemente. Quando tutte quelle pagine saranno state sistemate, servirà l'elenco di quelle con un {{Cn}} (o varianti) che abbia all'interno due linebreak consecutivi, indipendentemente dalle sezioni. Non dovrebbe essere complicato ma con l'insource non ci riesco.--Daimona Eaytoy (Scrivimi!) 14:37, 17 ott 2017 (CEST)

Pare che abbiate individuato il problema. Lo stesso che andrebbe fixato nelle occorrenze di Citazione necessaria, mi dicono. Elitre (WMF) (msg) 15:58, 18 ott 2017 (CEST)

Qualcuno è riuscito a fixare quanto spiegato? :) Elitre (WMF) (msg) 19:04, 31 ott 2017 (CET)

Altri non so, io parto come avevo detto dopo i font. Con molta calma sono arrivato a circa un centinaio di pagine rimanenti nel namespace utente, più circa altrettante protette. Quindi spero dalla prossima settimana di potermene occupare.--Daimona Eaytoy (Scrivimi!) 19:07, 31 ott 2017 (CET)

Ho finito i font in ns2, adesso sto cercando di iniziare con i cn. Tuttavia c'è un problemino: per inserire il template F da dove lo prendo l'argomento? Controllo la presenza di altri avvisi in cima alla voce? Categorie? Portali? --Daimona Eaytoy (Scrivimi!) 16:53, 1 nov 2017 (CET)

P.S. Si potrebbe fare anche un'altra cosa: generare un elenco di pagine che hanno il template F in cima e almeno un cn da qualche parte. In quei casi il Cn si potrebbe anche eliminare e via...--Daimona Eaytoy (Scrivimi!) 16:56, 1 nov 2017 (CET)

(Sì, scusate i troppi messaggi) Stavo pensando ad eventuali alternative per il template che permettano di non dover modificare tutte le voci incriminate. Purtroppo nulla sembra funzionare, in particolare neanche T:Chiarimento/Sandbox visibile in Utente:Daimona Eaytoy/Sandboxcn. Quella versione non introduce errori ma il risultato non è certo quello voluto. Stavo quindi pensando che forse conviene lavorare al trasferimento in lua piuttosto che alla modifica di non so quante pagine.--Daimona Eaytoy (Scrivimi!) 17:19, 1 nov 2017 (CET)

Qui un esempio con Lua (differenze incluse, a conti fatti solo miglioramenti). Ci leveremmo il problema di torno in maniera semplice e definitiva.--Sakretsu (炸裂) 15:11, 12 nov 2017 (CET)

Grazie [@ Sakretsu], purtroppo non avevo potuto occuparmene (e forse non ne sarei stato in grado). Il fatto che ripeta la nota alla fine è ottimale, se a qualcuno dà noia impara ad utilizzare a dovere l'F. Purtroppo rimane il fatto che certi cn che avvolgono decine di righe fanno letteralmente schifo, ma meglio così che provare tutte quelle sostituzioni senza sapere bene come farle.--Daimona Eaytoy (Scrivimi!) 19:19, 12 nov 2017 (CET)

[@ Valerio Bozzolan] che dici, va bene il codice o avevi altro in mente?--Sakretsu (炸裂) 21:54, 13 nov 2017 (CET)

[@ Sakretsu] Lunga vita allo split :) Se si è sicuri che sia meglio ripetere la nota per ogni riga, direi di proporlo in T:Cn con le dovute piccole correzioni grafiche. --Valerio Bozzolan (msg) 21:32, 14 nov 2017 (CET)

Mmh, quali correzioni grafiche? A parte la ripetizione della nota (che se vogliamo, ovviamente possiamo anche mantenere solo alla fine), non mi pare che con Lua ci siano altri cambiamenti grafici. C'erano altre modifiche da fare?--Sakretsu (炸裂) 23:01, 14 nov 2017 (CET)

Dico solo del colore nel <sup>…</sup> di questi ultimi due esempi che dovrebbe essere in entrambi blu se non erro: ultimi 2 esempi --Valerio Bozzolan (msg) 23:36, 14 nov 2017 (CET)

Come non detto :D Proponiamo subbbbito. --Valerio Bozzolan (msg) 23:38, 14 nov 2017 (CET)

Ahhhh ecco, non capivo :-) Allora procedo domani.--Sakretsu (炸裂) 00:43, 15 nov 2017 (CET)

Fatto ho aggiornato il template col Modulo:Chiarimento, anche se poi ho deciso di tenere la nota solo alla fine perché moltiplicata sarebbe stata eccessiva in casi come Hornow-Wadelsdorf. Tra parentesi il modulo gestisce ora non solo i paragrafi divisi da riga vuota, ma anche gli escape * : #. Il test più fantasioso che mi è venuto in mente è stato questo che mi pare venga generato correttamente senza errori sia di HTML sia di resa (sì, anche quel *a iniziale che non genera il pallino imita il comportamento precedente senza modulo).--Sakretsu (炸裂) 22:35, 15 nov 2017 (CET)

Very bene! --Valerio Bozzolan (msg) 23:29, 15 nov 2017 (CET)

Nuova categoria

Segnalo, per gli amanti del genere, la comparsa di una nuova categoria ad alta priorità. Fondamentalmente riguarda i tag font che avvolgono link: tidy li sposta all'interno dei link per dare i colori, mentre remex li lascia all'esterno. Fortunatamente lo spostamento fa parte del processo di conversione font->span e gli errori non saranno moltissimi.--Daimona Eaytoy (Scrivimi!) 18:42, 31 ott 2017 (CET)

Ritardo magistrale?

Mah, stamattina gli errori di Lint non si smuovono. Ad esempio ho persino svuotato la pagina utente di Utente:Andreasquizzato, ma l'errore del tag table non è scomparso. Ho provato a correggere un tag annidato male in Una matta, matta, matta corsa in Russia e niente, segna ancora errore...--Sakretsu (炸裂) 11:20, 16 nov 2017 (CET)

Se stai guardando Special:LintErrors, non temere, Subbu ha lanciato uno script ieri per tutte le voci di tutte le wiki. Elitre (WMF) (msg) 11:49, 16 nov 2017 (CET)

È normale, per alcuni fix di tag obsoleti ho dovuto aspettare due giorni. Se hai fretta un purge su ogni pagina è sufficiente, altrimenti purtroppo l'attesa è quella.--Daimona Eaytoy (Scrivimi!) 13:21, 16 nov 2017 (CET)

Tra parentesi, tra gli errori di tag annidati super malamente male, ho notato (in mezzo a della roba iper fantasiosa) che diversi di essi vengono da template lingua (es. {{russo}}) che hanno già di fabbrica il corsivo dove serve ma ci viene aggiunto a caso chiamando il template, esempio. Così ovviamente si rompe tutto e addio. Che soluzione possiamo usare? Che non preveda di cercare le pagine e correggerle tutte via bot (e se non ci fosse alternativa, come? Togliendo indiscriminatamente la formattazione manuale, spero).--Daimona Eaytoy (Scrivimi!) 17:45, 16 nov 2017 (CET)

Stavo per l'appunto bottando prima che se ne andasse via la corrente. Nel template Russo non ci vanno a prescindere né corsivi né grassetti. Considerando che il problema sarà derivato dai copia e incolla effettuati in massa dagli utenti, è meglio fare semplicemente una passata di bot.--Sakretsu (炸裂) 19:15, 16 nov 2017 (CET)

Ottimo così allora. Per ora ci sto dando duro con i tag font, un altro migliaio di pagine e addio tag obsoleti. Poi ci rimboccheremo le maniche per i casi fantasiosi...--Daimona Eaytoy (Scrivimi!) 19:17, 16 nov 2017 (CET)

Piccolo appunto: gli errori non sono sincronizzati, roba come questa secondo lui aveva solo un tag non chiuso e uno annidato malamente e questa pagina non è l'unica, anzi!--Daimona Eaytoy (Scrivimi!) 21:35, 16 nov 2017 (CET)

Di quei 2444 errori di tag malamente annidati, 400 sono in NS0. Ho il timore però che gran parte del lavoro sia da fare a mano...--Sakretsu (炸裂) 19:17, 19 nov 2017 (CET)

Timore che, a una rapida occhiata, purtroppo condivido. Negli altri ns si può fare qualcosa con alcune firme, ma per il resto c'è poco da farci. Nel mio XML ho un tentativo di correzione che "spalma" vari tag (span, small etc.) sui singoli elementi delle liste anziché sulla lista intera, ma purtroppo non funziona bene e alle volte va in timeout. Quello, se riuscissi a farlo funzionare, potrebbe aiutare per parecchie pagine.--Daimona Eaytoy (Scrivimi!) 19:37, 19 nov 2017 (CET)

Il più fastidioso problema è che ora nemmeno il purge funziona. Ogni volta devo aspettare minimo mezz'ora per scoprire se il fix abbia funzionato o meno :-/ Comunque dato che molti errori sono ripetuti nelle stesse pagine, penso che possiamo chiudere l'NS0 entro la prossima settimana.--Sakretsu (炸裂) 01:05, 20 nov 2017 (CET)

[← Rientro] Già, suppongo sia ancora il problema della coda di lavoro zeppa. Credo di non poter aiutare più di tanto, ma sarebbe comunque un risultato ottimo.--Daimona Eaytoy (Scrivimi!) 11:10, 20 nov 2017 (CET)

Credo fosse una cosa temporanea, un effetto collaterale del crawling che stava avvenendo. Elitre (WMF) (msg) 18:54, 20 nov 2017 (CET) PS: link

Confermo, il problema è sparito entro oggi come previsto da Ssastry. Comunque segnalo che ad esempio un errore di tag annidato male con resa differente in HTML5 e HTML4 in Utente:Sakretsu/Sandbox/4 viene evidenziato così, quando invece l'errore HTML era dovuto a questa riga. A quanto pare capita solo con gli errori nei tag ref (non sempre, alcuni li identifica correttamente).--Sakretsu (炸裂) 23:52, 21 nov 2017 (CET)

Già, tra l'altro errori di codesto tipo (con il corsivo che "avvolge" il titolo) sono (o erano?) molto frequenti in ns0, come se fosse scritto in qualche linea guida o fosse un bug di VE.--Daimona Eaytoy (Scrivimi!) 09:54, 22 nov 2017 (CET)

Non so cosa usiate per i fix, ma stando a quanto spiegato su en:Wikipedia:Linter, se usate il gadget di PerfektesChaos, "If LintHint says you fixed one or more lint errors, you almost certainly did fix them, even if page information and the specific lint errors page aren't updated yet." Elitre (WMF) (msg) 11:06, 23 nov 2017 (CET)

@Elitre No no, non ti preoccupare. Semplicemente segnalavo la totale imprecisione del software nell'evidenziare la parte di testo che genera alcuni errori di tag annidati male all'interno delle note. Su it.wiki non so se ce ne siano altri di media priorità, ma comunque ormai so già dove andare a guardare per trovare la causa. Lo dicevo più che altro per i nostri amici delle altre Wikipedie che magari ancora ci devono avere a che fare e che sarebbero grati se questa evidenziazione fosse corretta :-)

@Daimona non so il perché di questi corsivi inutili, ma più che altro il problema è stato che un bot sfortunatamente non l'aveva previsto e ha spostato in un punto sbagliato i due apici di apertura tag i.--Sakretsu (炸裂) 11:36, 23 nov 2017 (CET)

Interessante il gadget, vedrò di provarlo! Per ora ho sempre fatto a mano con l'aiuto del syntax highlight. Per i corsivi non saprei, bisognerebbe indagare un po'...--Daimona Eaytoy (Scrivimi!) 12:23, 23 nov 2017 (CET)

[@ Daimona Eaytoy] Mi applichi questa modifica sulle vecchie candidature? Non so quante voci siano però.--Sakretsu (炸裂) 13:47, 2 dic 2017 (CET)

[@ Sakretsu] Volentieri, ci guardo subito.--Daimona Eaytoy (Scrivimi!) 13:55, 2 dic 2017 (CET)

Gracias--Sakretsu (炸裂) 14:09, 2 dic 2017 (CET)

Fatto, ho corretto circa 200 pagine, fra cui un paio di PU bonus. --Daimona Eaytoy (Scrivimi!) 14:11, 2 dic 2017 (CET)

Ottimo, erano tutti errori di alta priorità ancora non spuntati fuori.--Sakretsu (炸裂) 14:14, 2 dic 2017 (CET)

[← Rientro] Eh, non avevo dubbi. Comunque, non so se erano quelli ma ora ce ne sono 40 in meno.--Daimona Eaytoy (Scrivimi!) 14:20, 2 dic 2017 (CET)

Per la cronaca, mi sa che pagine non editate da molto tempo anche se con errori non vengono segnalate. Me ne sono accorto su Wikidata, c'erano 3 pagine nella categoria "Escape di due punti multipli", poi però ho cercato lo stesso problema con "insource" e ne ho trovate una cinquantina, tutte pagine in effetti non editate da molto. --ValterVB (msg) 15:32, 2 dic 2017 (CET)

[@ ValterVB] Purtroppo è un problema noto, al quale non esiste nessuna "vera" soluzione. L'unica cosa è appunto cercare insource (quando possibile, perché con molte categorie di errori non lo è) oppure fare in modo che il software purghi da solo le pagine. A questo proposito, ho appena dummyeditato il {{Cassetto}} per cercare di strizzare qualche altro errore a giro.--Daimona Eaytoy (Scrivimi!) 16:05, 2 dic 2017 (CET)

[@ Daimona Eaytoy] probabilmente ci sono un bel po' di voci che necessitano di questo fix. Continuano a spuntare come funghi tra gli errori per via del dummy edit.--Sakretsu (炸裂) 21:41, 2 dic 2017 (CET)

[@ Sakretsu] Ancora i benvenuti?! Oddio... Vedo cosa posso fare, più che altro che io sappia con la ricerca insource non si possono cercare le andate a capo, quindi potrebbe non essere semplice generare una lista.--Daimona Eaytoy (Scrivimi!) 11:12, 3 dic 2017 (CET)

Ho trovato solo 17 pagine con quel problema, due le ho corrette via bot e le altre 15 sono protette. Le sto facendo a mano con calma, senza flood editor che non ne vale neanche la pena per 15 modifiche. Poi mi sembra che di alta priorità ci sia rimasto poco altro...--Daimona Eaytoy (Scrivimi!) 11:23, 3 dic 2017 (CET)

Già, direi proprio che è fatta. Per quanto riguarda i tag HTML obsoleti, come mai ci sono ancora 1800 errori? Invece per i tag annidati male, sarebbero tutti facilmente risolvibili, ma siccome la resa non cambia e la modifica dovrebbe consistere in questo mi sa che è meglio non fare nulla.--Sakretsu (炸裂) 23:15, 3 dic 2017 (CET)

Ci sono ancora 1800 errori perché ho mandato il bot in ferie... Prima o poi riprenderò, non c'è (troppa) fretta. Di tag da spalmare a quel modo ce ne sono a bizzeffe, ma siamo sicuri che la resa grafica è invariata?--Daimona Eaytoy (Scrivimi!) 09:35, 4 dic 2017 (CET)

Può darsi che ancora non ci si sia resi conto di errori che comportino un cambio di resa, ma in tal caso direi che verrà creata un'altra categoria di alta priorità apposita.--Sakretsu (炸裂) 14:43, 4 dic 2017 (CET)

Un ringraziamento, e i prossimi passi

Ciao a tutti.

A luglio del 2017 abbiamo annunciato l'intenzione di rimpiazzare Tidy con RemexHTML sui siti Wikimedia entro 12 mesi. Per permettere che ciò avvenga abbiamo identificato una serie di sequenze di wikitesto non funzionante che necessitano di essere riparate sulle wiki, evidenziandole tramite le categorie ad alta priorità dell'estensione Linter.

Oggi dobbiamo riconoscere il progresso veloce e significativo ottenuto dai volontari di questa wiki nelle "riparazioni" necessarie per rimpiazzare Tidy. Quasi tutti i problemi più importanti nel namespace principale sono stati riparati in pochissimi mesi: è un risultato notevole, e a nome del team Parsing, vorrei ringraziare tutti voi che lo avete reso possibile.

Mentre la data definitiva per l'addio a Tidy resta luglio 2018, dei passaggi anticipati delle wiki da Tidy a Remex ci permetteranno di identificare eventuali restanti problemi non già colti dalle categorie linter e dai nostri test QA. Stiamo incoraggiando alcune wiki maggiori, che hanno lavorato molto finora, ad effettuare tale passaggio.

In base a quanto vediamo attualmente sui problemi linter ad alta priorità, riteniamo che questa wiki sia già pronta a passare a Remex. Tanto per essere chiari, se noteremo problemi (o se la wiki lo chiedesse) faremo revert del passaggio, dopo aver identificato la fonte del problema. Se notate dei rendering scorretti, potete usare ?action=parsermigration-editper identificare se proprio il passaggio a Remex ne sia la causa.

Suggeriamo il 5 dicembre 2017 come data per il possibile passaggio (in modo che resti un bel po' di tempo per risolvere eventuali problemi dovuti al passaggio prima dell'arrivo delle festività). Siamo curiosi di sapere cosa ne pensate, e come possiamo aiutarvi a rendere la transizione il più semplice possibile. Grazie! Elitre (WMF) (msg) 19:34, 20 nov 2017 (CET)

PS: Ping @Utente:Daimona Eaytoy, Utente:Sakretsu, Utente:Sannita e Utente:Valerio Bozzolan, del quale ho seguito il workshop sui bot ieri a Trento e che mi fa essere molto ottimista sul fatto che questo genere di lavori sia in ottime mani! Elitre (WMF) (msg) 19:35, 20 nov 2017 (CET)

Barnstar tecnica per tutti quelli che si sono impegnati qui. <3

Grazie Elitre. Concordo sul passaggio a breve, eventuali altri errori saranno risolti strada facendo. Sarebbe utile anche se venisse risolto questo task, ma per ora va bene così. L'unica cosa che mi preoccupa un po' è che bisognerebbe "istruire" gli utenti nella nuova direzione: con l'apposito filtro vengono continuamente impedite aggiunte di tag obsoleti, che dovrebbero essere la cosa più facile da correggere per i non addetti ai lavori. Purtroppo non riesco neanche a immaginare un filtro in grado di trovare tutti gli altri possibili errori, ma ci vuole comunque qualcosa per evitare che gli utenti continuino ad inserirne. --Daimona Eaytoy (Scrivimi!) 20:14, 20 nov 2017 (CET)

Mancano solo un centinaio di errori di alta priorità in NS0. Per me si può procedere.--Sakretsu (炸裂) 21:22, 20 nov 2017 (CET)

Con molta calma e con l'aiuto del bot, sono rimaste circa 950 user talk per chiudere definitivamente la categoria dei tag obsoleti. Preciso comunque che ancora gli errori non vengono aggiornati neanche con il purge, il che rende abbastanza difficile capire se sono state fatte tutte le correzioni necessarie o no.--Daimona Eaytoy (Scrivimi!) 18:15, 21 nov 2017 (CET)

Zero errori di alta priorità in NS0.--Sakretsu (炸裂) 23:55, 21 nov 2017 (CET)

Purtroppo ne sono comparsi altri! --LucaRosty (Scrivimi) 09:02, 22 nov 2017 (CET)

È normale, ogni tanto vengono ricaricati alcuni template (in questo caso l'infobox conflitto) e compaiono altri errori... Ma finché sono pochi va bene così.--Daimona Eaytoy (Scrivimi!) 09:54, 22 nov 2017 (CET)

Nel segnalarvi la vs meritatissima barnstar a fianco, chiedo: a questo punto dobbiamo davvero aspettare il 5, o facciamo settimana prossima? (Così mi regolo sulla data da mettere nel Wikipediano) Elitre (WMF) (msg) 10:07, 22 nov 2017 (CET)

Personalmente propongo di aspettare. Del resto si tratta solo di un paio di settimane,nelle quali diamo il tempo agli errori rimasti di fare capolino. Siamo comunque di diversi mesi in anticipo rispetto alla scadenza prefissata, credo che un paio di settimane in più non possano far male.--Daimona Eaytoy (Scrivimi!) 10:12, 22 nov 2017 (CET)

Ok, il 5 è domani, verosimilmente lo switch avverrà intorno alle 18 14 UTC. In alto ho spiegato il metodo per verificare se un problema di rendering è causato dallo switch o no. Se dovesse servire aiuto urgente, passate su IRC in #mediawiki-parsoid, oppure pingate me o mw:User:SSastry (WMF). Nella peggiore delle ipotesi possiamo diagnosticare il problema e tornare a Tidy. Lascio una nota in merito sul canale IRC di it.wiki. Ciao, Elitre (WMF) (msg) 11:58, 4 dic 2017 (CET)

Dato che a breve avverrà lo switch, cosa ne direste di un sitenotice (da tenere qualche giorno) che avvisi del passaggio e inviti gli utenti a riportare determinate tipologie di problemi nel posto giusto (officina)?--Daimona Eaytoy (Scrivimi!) 12:53, 5 dic 2017 (CET)

Monitorato su Phabricator
Task T181190

Secondo me è eccessivo: se ci sono problemi gravi, lo si noterà presto e alla peggio si reverta lo switch; se i problemi non sono gravi, l'utente medio non saprà distinguerli da un banale disguido tipo un template lasciato aperto, e rischi un mare di falsi positivi. Al limite, sarebbe il caso di metterlo in un notice visibile solo ai registrati, se possibile. My2c comunque! Elitre (WMF) (msg) 15:06, 5 dic 2017 (CET) PS: anche perché i problemi si notano solo se la pagina è editata/purged. Switch appena avvenuto!

PPS: Ricordo Special:LintErrors per chi vuole aiutare a correggere gli errori rimasti, documentazione su mw.org.

Sì beh, è vero. Ottimo comunque, aspettiamo e vediamo.--Daimona Eaytoy (Scrivimi!) 15:25, 5 dic 2017 (CET)

Monitorato su Phabricator
Task T182170

[@ SSastry (WMF)] check out User talk:Kirk39. No high priority errors are detected. I've tested a fix in my sandbox and here's the missing end tag. The tag del has the same problem, even though its effect is reduced since it affects only a single paragraph (example).--Sakretsu (炸裂) 22:10, 5 dic 2017 (CET)

[@ Sakretsu], Thanks. Interesting. Yes, looks like this scenario hasn't been detected as a high priority error. I'll have to play with it to figure out what is going on. SSastry (WMF) (msg) 22:32, 5 dic 2017 (CET)

[@ Sakretsu], You provided one more reason to get rid of Tidy sooner than later. :-) Check this version with 1 small tag vs this version with 2 small tags. So, in the first case, Remex and Tidy both leak the small tag to the entire page. In the second case, Tidy closes both unclosed tags whereas Remex (correctly) leaks the unclosed tag everywhere. This looks like an edge case right now and should not be very common, but if you see more instances, I can add another high priority category to detect this. Let me know what you think. SSastry (WMF) (msg) 23:10, 5 dic 2017 (CET)

[@ SSastry (WMF)] well, without knowing the extent of the damage I can't properly judge. Also, if you check the tags small detected in the missing-end-tag category, you can notice different strange behaviours, like this article showing a similar problem that I've highlighted here. Remex leaves the tag small open, while Tidy closes it just because it is preceded by a span in the same ref (or at least, I guess so). Other examples of unexpected behaviour: 1, 2, 3 and 4 (in the last one, something happened with the Wikimedia Commons and Wikispecies links on the left too). I suggest you to further investigate and add another high priority category if it feels necessary.--Sakretsu (炸裂) 02:06, 6 dic 2017 (CET)

[@ Sakretsu] Thanks very much for these leads. Will investigate. SSastry (WMF) (msg) 04:48, 6 dic 2017 (CET)

I think this is primarily an issue for <small> and <big> tags where the effects accumulate with each unclosed tag. We'll investigate a bit more closely and see what kind of linter category to introduce. You can fix up those pages now. I have the tests cases I need. SSastry (WMF) (msg) 05:01, 6 dic 2017 (CET)

Filed phabricator:T182170 SSastry (WMF) (msg) 05:15, 6 dic 2017 (CET)

[← Rientro] Thanks [@ SSastry (WMF)], we'll wait and see what should be done. I'd personally suggest to put <big> tags in the obsolete ones category, since they're not supported in HTML5 and we'll need to get rid of them sooner or later. Many thanks again for the support.--Daimona Eaytoy (Scrivimi!) 09:31, 6 dic 2017 (CET)

[@ Daimona Eaytoy] yes, both big and small tags will be covered by that linter category SSastry (WMF) (msg) 19:23, 6 dic 2017 (CET)

[@ SSastry (WMF)] the user [@ Rotpunkt] has just reported in my talk that the article Federico II di Svevia shows bad indentation caused by the template {{Citazione}}. This error has never been detected before and is highlighted here.--Sakretsu (炸裂) 13:19, 6 dic 2017 (CET)

Certo però che per mettere una tabella (in questo caso una citazione, che è lo stesso) in un elenco puntato ci vuole fantasia eh...--Daimona Eaytoy (Scrivimi!) 14:23, 6 dic 2017 (CET)

[@ Sakretsu] Looks like it is a PHP parser bug that Tidy covers up but Remex does not. But, since the output from Tidy is not the same as the markup anyway, one option is for us to flag when this kind of table nesting is present in lists and the markup can be fixed. Parsoid does not have this bug but for now, the simplest fix would be fix the markup unless we find a quick fix for the PHP parser bug. We can add a linter category to detect this pattern. SSastry (WMF) (msg) 19:23, 6 dic 2017 (CET)

[@ Sakretsu], [@ Daimona Eaytoy], The Parsoid and Linter extension patches have been merged. I've also created the help pages and linked them to mw:Help:Extension:Linter. The code will be deployed next week and the categories will start populating from Thursday. For all Remex-deployed wikis, we'll also run a script to process all pages and initialize these new categories. I'll notify you all here when that completes. SSastry (WMF) (msg) 17:34, 8 dic 2017 (CET)

[@ SSastry (WMF)] Regarding multiple unclosed tags, it is true that only the effects of small and big tags can stack up, but whenever unclosed tags are two (or four, six, and so on), Tidy interprets them as pairs. This means that when we have, let's say, four start tags, we get a completely different result. As in the example, Remex always underlines everything until the end of the page, whereas Tidy only underlines what is included in each pair. The same goes for the other tags (I've just noticed it thanks to a report from the user Ignazio Cannata about the help page Aiuto:Lua#Richiamare_un_modulo_Lua). But beware, we get such behaviour only when Tidy can read exactly <open tag>text<open tag>, hence cases like this one, this one, or this one are safe. Hope it helps.--Sakretsu (炸裂) 00:02, 9 dic 2017 (CET)

[@ Sakretsu] Mi è stato fatto notare che gli archivi degli autoverificati da qui in puoi soffrono di rimpicciolimento. Dando un'occhiata ho visto che mancano puntualmente i tag small di chiusura nelle intestazioni (dopo il link ai blocchi). Al momento non ho modo di indagare se il problema è riconducibile alle casistiche segnalate qui sopra, né posso preparare subito un XML per correggerli, comunque intanto ti segnalo la cosa, evitando di scomodare il buon SSastry per quel che potrebbe essere un problema minore ;-) --Daimona Eaytoy (Scrivimi!) 10:03, 7 dic 2017 (CET)

Direi che sia un comportamento riconducibile a quello degli small segnalati sopra. Per risolvere, si può sostituire {{Utente/Link|*nome utente*|blocchi}})</span> con {{Utente/Link|*nome utente*|blocchi}}</small>)</span>.--Sakretsu (炸裂) 11:29, 7 dic 2017 (CET)

Anche la categoria Contenuto di tabella in posizione errata per quanto riguarda il ns0 è vuota --LucaRosty (Scrivimi) 17:48, 7 dic 2017 (CET)