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>…</font>, <center>…</center>, <tt>…</tt> e <strike>…</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 {{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)

[← Rientro] Segnalo. --Ignazio (msg) 12:03, 10 dic 2017 (CET)

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, <tt>Questo è un tt</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] I suppose Tidy is a gift that keeps on giving! I ran into other Tidy smarts/weirdnesses when I was working on the tidy-font-bug category. In any case, looks like Tidy tries to be smart and fix up tag pairs when the content ends in non-whitespace text (but nothing else). I will fix up that category to track these as well. Thanks for the heads up! SSastry (WMF) (msg) 00:24, 9 dic 2017 (CET)

[@ SSastry (WMF)] Thanks again! I hope to get my bot (and myself) ready ASAP to tear down the newcomers. --Daimona Eaytoy (Scrivimi!) 11:39, 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)

[@ Sakretsu] [@ Daimona Eaytoy] The script I had run 2 weeks back to crawl all pages on all wikis to get all lint errors had only done it on Main and Talk namespaces. I discovered this based on a bug report by an enwiki editor. I fixed the bug and restarted the script on Friday and it is now processing itwiki. So expect to see new entries from all the other namespaces, especially User and User Talk namespaces. SSastry (WMF) (msg) 06:31, 12 dic 2017 (CET)

Apologies for the delayed identification of these lint errors because of a bug in our crawler script. This is unrelated to Tidy replacement, but to fix Template:Softredirect that is generating errors in Speciale:LintErrors/multi-colon-escape, please see https://lists.wikimedia.org/pipermail/wikitech-ambassadors/2017-September/001693.html for a solution. SSastry (WMF) (msg) 07:02, 12 dic 2017 (CET)

[@ SSastry (WMF)] Well, that explains why some errors in the template namespace weren't listed :-) Anyway it's completely fine, it's much better to have thousands of errors with the certainty that they're all listed there, instead of no errors but a strong possibility of many unlisted errors. We'll fix what's needed as always. --Daimona Eaytoy (Scrivimi!) 12:32, 12 dic 2017 (CET)

I'm testing in sandbox the suggested edit to {{Soft redirect}}. It seems to work, but due to this task (that you know much better than me) the colon is translated into a <dl><dd>. This is actually really nasty and turns out to be a real pain in the neck in many situations. I'll apply a workaround, though it's certainly not the better thing to do. --Daimona Eaytoy (Scrivimi!) 12:43, 12 dic 2017 (CET)

[@ SSastry (WMF)] [@ Sakretsu] (se ci vuoi dare un'occhiata): Here is the result: Utente:Daimona Eaytoy/Sandbox3. I tried to prevent translating with nowiki and HTML entity for both colon and/or extra-spaces, but none of these works. I can only see 3 possible solutions: 1-I'm completely dumb and I'm missing something 2-Switch soft redirect to Lua 3-Fix the bug.--Daimona Eaytoy (Scrivimi!) 12:57, 12 dic 2017 (CET)

diff^93141975, but since multi-colon-escape category is already empty, I wouldn't do anything, at least for now.--Sakretsu (炸裂) 13:56, 12 dic 2017 (CET)

My bad, just to spare a couple of brackets ;-) Template fixed: empty category sounds bad, I think it'll be populated again, it's not the first time.--Daimona Eaytoy (Scrivimi!) 13:58, 12 dic 2017 (CET)

[@ Sakretsu] [@ Daimona Eaytoy] The new categories have been deployed and I have the script running to reparse all itwiki pages. It should be done within the next 12 hours. However, I noticed that the multiline-table-in-list and multiple-unclosed-formatting-tags have false positives. If they are too noisy with too many false positives, I'll fix them January first week after the deployment freeze is lifted. SSastry (WMF) (msg) 00:56, 15 dic 2017 (CET)

[@ SSastry (WMF)] It's fine, we'll see what to do. Thanks again, --Daimona Eaytoy (Scrivimi!) 16:33, 15 dic 2017 (CET)

[@ SSastry (WMF)] Also, description lists should be included.--Sakretsu (炸裂) 14:11, 16 dic 2017 (CET)

Indeed. I made this fix just now which I found separately when trying to look at our automated test results that compares Tidy and Remex output on a sample of itwiki pages. The linter category will get updated in January. SSastry (WMF) (msg) 22:02, 17 dic 2017 (CET)

[@ SSastry (WMF)] Thanks to [@ Bradipo Lento] I've noticed another weird behaviour from Tidy. As usual, here's a couple of tests. If I'm correct, the issue could be easily solved by editing Mediawiki.--Sakretsu (炸裂) 15:48, 17 dic 2017 (CET)

I did not understand what you meant by editing Mediawiki. Can you explain? It looks like Tidy is incorrectly modifying the output here. SSastry (WMF) (msg) 22:02, 17 dic 2017 (CET)

[@ SSastry (WMF)] Yes, it definitely is Tidy's fault, but since the final output has never been <dl><dt><dl><dt> as it was supposed to be, you might want to change it to <dl><dd><dl><dt>. Obviously, that's just an idea. I don't know either the full consequences of such a change or how many errors are currently involved :-)--Sakretsu (炸裂) 23:07, 17 dic 2017 (CET)

I am hesitant to make that fix since it is not the right HTML output whereas we want to slowly clean up MediaWiki output to be well formed HTML5 output. Plus, I think it is better for invalid markup to be cleaned up. Let us revisit in January once we fix the false positive errors for the linter categories. So far, itwiki's output is looking good overall in our automated visual diff tests. Looking at those older results, I think could have caught the Citazione error earlier if I had looked carefully. In any case, I'll paste here a list of titles that look odd. Check this where Tidy is behaving incorrectly but now it is good which indicates that Template:Bibliografia might have some markup error that could be fixed up. SSastry (WMF) (msg) 01:00, 19 dic 2017 (CET)

Thanks, I've proposed some solutions here. Anyway, it seems like tag li not wrapped in tag ul should be flagged.--Sakretsu (炸裂) 02:16, 19 dic 2017 (CET)

[@ Sakretsu, SSastry (WMF)] Look at this error. Sounds like sometimes Remex gets really mad and totally refuses to parse the page. This is the first one I notice, nor I know whether there are others around. What could be the reason? --Daimona Eaytoy (Scrivimi!) 12:49, 20 dic 2017 (CET)

No idea. If you delete the end tag div or move it to the next line in this situation, you get that error.--Sakretsu (炸裂) 14:04, 20 dic 2017 (CET)

Looks like someone reported a reduced test case here in case it helps fixing up the wikitext on that page. SSastry (WMF) (msg) 16:39, 20 dic 2017 (CET)

Looks like you have already fixed it up. Alright, we'll investigate the crasher. SSastry (WMF) (msg) 16:45, 20 dic 2017 (CET)

[← Rientro][@ SSastry (WMF)] Alright, thanks, I'll subscribe to phab task. Yes, that page wasn't that different than the others with similar problems and only needed a standard fix. The point was to understand why this is happening, since it can really break pages. Another good point would be to understand how many pages are affected, though I don't know if it's possible. --Daimona Eaytoy (Scrivimi!) 17:30, 20 dic 2017 (CET)

A margine, oggi pomeriggio ho (finalmente) finito i tag obsoleti, e nel darmi ad altro ho scelto i multiple unclosed etc etc. Ho notato che molti di essi provengono da voci sul calcio in cui le "legende" hanno puntualmente degli small che avvolgono le liste. Preso dall'ottimismo, ho aperto le prime due e scritto un paio di regex. Lancio AWB per valutare se e quanto correggono bene, scorre 100 pagine e non trova da correggere in nemmeno una. Armandomi di pazienza, ho spulciato altre 4 pagine e aggiunto altrettante regex, poi ho caricato 100 pagine a caso con le legende formattate male per vedere quanto sarei riuscito a penetrare. Risultato? Con 6 regex ne ha trovate 5. Tanto per la cronaca, le pagine con le legende da correggere sono circa 2000. Per avere qualche possibilità di successo proverò a rispolverare una regex generale, sempre che riesca a farla funzionare, ma forse sarebbe bene informare quelli del progetto e dirgli di standardizzare le legende, perché sinceramente ho poca voglia di scrivere decine di replacement per un problema, tutto sommato, piuttosto stupido. Tutto questo per dire che se anche gli altri errori derivano da dosi così massicce di fantasia c'è da star freschi (e non perché è inverno).--Daimona Eaytoy (Scrivimi!) 19:39, 20 dic 2017 (CET)

Sembra che il problema delle legende si possa risolvere bene con un <div style="font-size:smaller"> ad avvolgere tutto il pacchetto. Il risultato non è identico al 100%, ma quasi.--Daimona Eaytoy (Scrivimi!) 19:48, 20 dic 2017 (CET)

Facendo un po' di correzioni sui tag di formattazione multipli mi sono imbattuto in diverse pagine che segnalano un problema legato ad uno small. Sembrerebbe causato dal template "troll". --LucaRosty (Scrivimi) 17:54, 21 dic 2017 (CET)

Confermo, c'era uno small che avvolgeva praticamente tutto il template. Gli ho affibbiato un div come per le legende e adesso dovrebbe essere a posto. Il troll ha perso qualche centimetro di altezza ma vabbè, almeno non è ingrassato. --Daimona Eaytoy (Scrivimi!) 18:34, 21 dic 2017 (CET)

Comunque stavo pensando di aggiungere un altro filtro per intercettare gli errori più comuni ad alta priorità (tipo tag che avvolgono le liste, poi vedo cosa riesco a fare). Però a tre condizioni: 1-nessun parere contrario in questa sede (né ovviamente a posteriori), 2-di riuscire a scrivere qualcosa che non becchi troppi falsi positivi e 3-di utilizzare una quantità relativamente ridotta di condizioni per non intasare il sistema (o in alternativa spegnendo una discreta quantità di vecchi filtri ormai pressoché inutili).--Daimona Eaytoy (Scrivimi!) 18:37, 21 dic 2017 (CET)

[@ Sakretsu] [@ Daimona Eaytoy] I have fixed the false positives and reprocessed the two categories. So, the multiple-unclosed-formatting-tags and multiline-html-table-in-list categories should have more useful information for you. Let me know if you see any other problems there. SSastry (WMF) (msg) 20:53, 2 gen 2018 (CET)

[@ Sakretsu] Stavo dando un'occhiata alla categoria delle tabelle nelle liste. Ho notato che molti problemi vengono dal template {{Quote}} usato un po' ovunque: in particolare, in molte pagine del ns4 viene utilizzato in varie occasioni negli interventi, indentati con : o *. Visto che non sarebbe semplice un fix che lasci tutto perfettamente inalterato, e vista la nota in testa al man del template, pensavo di dare una ripulita sostituendo tutti i quote con le virgolette a sergente, almeno nei casi in cui si può fare automaticamente. Pensi che vada bene o potrebbe esserci un'alternativa più comoda?--Daimona Eaytoy (Scrivimi!) 19:49, 3 gen 2018 (CET) Dimenticavo: un'altra idea sarebbe di posizionare manualmente le tabelle a capo, fuori dall'indentazione (così come già appaiono), l'idea era anche per la questione del quote fuori dal ns0.

Direi di spostarle a capo. È la soluzione più facile e implica una resa uguale.--Sakretsu (炸裂) 20:29, 3 gen 2018 (CET)

Vedo che quasi tutte le altre wiki, enwiki, ptwiki, eswiki, dewiki, ruwiki, utilizzano il tag blockquote per il template {{Citazione}}, non una tabella, adesso non ho tempo, ma vi proporrei di fare qualche prova in tal senso. --Rotpunkt (msg) 20:31, 3 gen 2018 (CET)

Riguardo alla nota nel manuale del 2007, mi sembra che non abbia senso, è un template più semplice di tanti altri usati a profusione al di fuori dell'ns0 e che se impiegato anche centinaia di volte in una pagina incrementa di qualche decimo di secondo il salvataggio. --Rotpunkt (msg) 21:18, 3 gen 2018 (CET)

La nota si può cancellare. Il tag blockquote mi sa che non è stato usato per via della doppia citazione (originale + in lingua italiana).--Sakretsu (炸裂) 22:40, 3 gen 2018 (CET)

@Sakretsu Non sono un grande utilizzatore del template, ma immagino che dei suoi circa 56000 utilizzi, quelli con la doppia citazione siano una piccola parte. Si potrebbe comunque all'interno dividere i due casi, e per quello senza doppia citazione usare il blockquote. Ancor meglio fare due template separati. --Rotpunkt (msg) 00:46, 4 gen 2018 (CET)

Negli altri ns ho dato una ripulita ieri (mandando a capo), in ns4 siccome sono quasi tutti in pagine protette non ho fatto quasi niente. --ZioNicco (msg) 09:47, 4 gen 2018 (CET)

Beh, non dubito che la nota sia vecchia e non abbia più molto senso. Riguardo alle altre wiki non saprei, il tag blockquote darebbe miglioramenti? Ad ogni modo vedo se riesco a dare una passata di adminbot in ns4 mandando a capo.--Daimona Eaytoy (Scrivimi!) 11:51, 4 gen 2018 (CET)

[← Rientro] Ho dato una passata di a capo in ns4, almeno quelli del quote dovrebbero essere corretti. Piuttosto ho notato un altro errore non segnalato nel ns10, nel template {{Chiusura}}: utilizza un {{Avviso}} indentato con i due punti, quindi andrebbe corretto pure lui. Si veda ad esempio il casino che salta fuori qui. Ho elaborato un fix che replica il dl/dd con un div, però non so se il valore scelto (22px), che nel mio caso funziona, vada bene per tutti. Qualcuno potrebbe confermare o smentire?--Daimona Eaytoy (Scrivimi!) 13:30, 4 gen 2018 (CET)

Ricordati di usare sempre lo strumento di migrazione. Ho applicato questo fix diff^93651395 di conseguenza. Comunque se l'errore non era ancora segnalato (non ci ho fatto caso), immagino che la categoria si stia ancora aggiornando.--Sakretsu (炸裂) 15:04, 4 gen 2018 (CET)

Ah, non avevo visto quella versione. Anche perché sbaglio o, anche con lo strumento di migrazione, bisognava andarla a cercare? Comunque è sicuramente così, ancora non ci sono tutti gli errori. Del resto vengono segnalate anche pagine che includono pagine già corrette, ad esempio questa... Vedo se conviene dare una passata di null edit per farle sparire.--Daimona Eaytoy (Scrivimi!) 15:45, 4 gen 2018 (CET)

in merito a Errori di Lint: Tabella multilinea in lista sono rimasti 26 pagine protette il resto ho pulito tutto, e per Errori di Lint: Molteplici tag di formattazione non chiusi c'è ne sono 518 che però sono praticamente tutti in pdc protette (e relative inclusioni) votazioni di admin protette ecc. per cui non posso fare niente --ZioNicco (msg) 16:15, 21 gen 2018 (CET)

Ottimo, grazie, cercherò di dare una passata a breve, almeno per le tabelle.--Daimona Eaytoy (Scrivimi!) 16:22, 21 gen 2018 (CET)

Grassetti e corsivi

Facendo alcune correzioni di tag mal annidati mi sono imbattuto diverse volte in problemi del tipo l'''aaa'', e l'''eeee'' che viene rilevato come un tag male annidato mentre uno degli apici è l'apostrofo da inserire nella frase. Come si può risolvere tale problema --LucaRosty (Scrivimi) 12:43, 11 dic 2017 (CET)

È necessario scrivere l{{'}}''aaa'', cioè usando il template:' per l'apostrofo. Tuttavia, questo caso dovrebbe essere identificato come errore solo quando la resa sia effettivamente inaspettata. Non sempre "l'a" crea problemi. Di solito accade quando c'è un conflitto con altri apici nella sta riga.--Sakretsu (炸裂) 15:25, 11 dic 2017 (CET)

Si può anche evitare il Template:' ed usare l'<nowiki />''ostrogoto'' o meglio ancora l<nowiki>'</nowiki>''ostrogoto'' --Valerio Bozzolan (msg) 15:41, 11 dic 2017 (CET)

Vero, ma i template, specialmente quando sono mirati, aiutano a tenere sotto controllo la situazione. Tra parentesi Valè, non è che hai voglia di inviare un bot selvaggio? Posso procurarti la lista di pagine che hanno tag b e i male annidati. Se il bot esegue più di due sostituzioni di l/un/ecc.' + ''x'' o '''x''' o '''''x''''', aggiungi la pagina a un elenco da controllare.--Sakretsu (炸裂) 15:58, 11 dic 2017 (CET)

Te manda, chi lo legge prima passa il bot :) --Valerio Bozzolan (msg) 01:13, 15 dic 2017 (CET)

Le voci sono qua, ma in alcune il problema risiederà nelle inclusioni. P.S. dato che le ho estratte da Speciale:LintErrors/misnested-tag ci sono doppioni.--Sakretsu (炸裂) 14:55, 15 dic 2017 (CET)

Filtro

Ciao, un mio collega notava come il filtro 423 potrebbe limitarsi ad avvertire l'utente e a taggare l'edit, invece di impedire l'azione, visto che non scatta poi così spesso, in modo anche da poter capire meglio quali sono i problemi e correggerli a monte. (Il team Parsing intende anche costruire qualcosa di relativo, peraltro.) --Elitre (WMF) (msg) 00:50, 23 gen 2018 (CET)

[@ Elitre (WMF)] Grazie mille per la segnalazione, purtroppo non avevo notato né il topic che hai linkato, né quello in cui Codas riportava di non riuscire ad ultimare la traduzione; monitoro l'officina e la mia talk (linkata nell'avviso del filtro), non pensavo che il problema potesse essere riportato altrove. Parto comunque con qualche dato: il filtro è attivo dal 21 settembre 2017, e in 4 mesi ha registrato un totale di 1000 hit. Non sono molte, senza dubbio, ma a mio avviso neanche poche, con qualche abuso si potrebbe quantificare in 8 hit al giorno. Dico "con qualche abuso" perché capita (abbastanza spesso) che lo stesso utente lo faccia scattare una decina di volte di fila nel giro di pochi minuti, probabilmente pensando che si sia trattato di un errore o qualcosa del genere. In effetti condivido pienamente quanto detto di là: nella stragrande maggioranza dei casi gli utenti aggiungono questi tag senza volerlo davvero, quasi sempre traducendo voci da altre wiki. Quindi, in un certo senso, una soluzione efficace per questo problema sarebbe eliminare i tag deprecati dalle wiki più usate per la traduzione. Facile a dirsi, ma si tratta di quasi 16 milioni (!) di tag soltanto in enwiki, praticamente molti di più che tutti gli errori di lint che abbiamo mai avuto da queste parti messi insieme. Purtroppo ultimamente ho poco tempo per occuparmi di it.wiki, ancora meno per correggere gli errori da loro... Posso al più vedere di beccarne qualcuno in template molto inclusi per scremare il lavoro, ma tutti quelli che vengono copiati qui da noi sono presenti nel corpo della pagina, e rimarrebbero intatti dopo tale correzione. Altra cosa: mi è parso di aver letto (ma potrei sbagliarmi, in tal caso ignorate pure questa frase) che il filtro non sia adatto a gestire errori commessi in buona fede, come in questo caso; beh, questo non è vero, abbiamo anche filtri per modifiche in buona fede, è perfettamente normale, e proprio in quest'ottica era stato proposto su phab di rinominarlo in "edit filter", per evitare l'associazione "FAA = malafede/vandalismo". Detto questo, non metto in dubbio che diversi utenti non comprendano l'avviso su come correggere gli errori, anzi credo sia perfettamente normale. Nel buttare giù l'avviso ho chiesto un paio di pareri a giro, ma il problema (magari è mio, chissà) è che praticamente nessuno mi ha dato feedback a posteriori. Quando vedo un utente che lo hitta 5-6 volte di fila, solitamente vado in talk e gli chiedo cosa ci sia di non chiaro nell'avviso, dovesse anche rispondermi "tutto quanto". Il fatto è che di risposte non ce ne sono mai state, quindi non so nemmeno come regolarmi. Non so cosa non sia chiaro agli utenti che hittano: come trovare i tag? Cosa siano gli stessi? Come sostituirli? Senza una risposta ho praticamente le mani legate. Per concludere (sperando di non aver fatto venire il latte alle ginocchia a nessuno), preciso che all'inizio (fino al 14 novembre, cioè per i primi due mesi) il filtro si limitava ad avvisare, senza impedire. Risultato: quasi tutti salvavano lo stesso con i tag obsoleti, in un tempo così breve da non aver sicuramente nemmeno letto l'avviso, portandomi per questo motivo a mettere l'impedimento.

Tl;dr: Gli hit non sono proprio pochissimi, risolvere il problema a monte = ripulire (soprattutto) en.wiki da 16 milioni di tag obsoleti, siamo completamente d'accordo sul fatto che molti sono in buona fede ma non ho mai avuto feedback su come venirgli incontro. Per me nessun problema a togliere di nuovo l'impedimento ma il problema non si risolverebbe.

Sperando di non aver dimenticato nulla, --Daimona Eaytoy (Scrivimi!) 12:35, 23 gen 2018 (CET)

P.S. Ho dato una scorsa veloce (sono un po' a corto di tempo) alla bot policy di en.wiki e non mi sembra di aver notato particolari requisiti sul manovratore. Se fosse sufficiente l'autoconfirmed cercherò di chiedere il flag anche lì. --Daimona Eaytoy (Scrivimi!) 13:03, 23 gen 2018 (CET)

P.P.S. Parlando con Codas mi sembra di aver capito che, usando CX, succedano due cose abbastanza brutte: la prima è che non si può switchare in wikitesto e di conseguenza correggere manualmente gli errori. La seconda è che l'avviso del filtro compare sotto forma di codice raw e non nella sua forma esatta (cioè questa). --Daimona Eaytoy (Scrivimi!) 13:21, 23 gen 2018 (CET)

Ciao, apprezzo le risposte: puoi parlarne direttamente col mio collega comunque ;) --Elitre (WMF) (msg) 19:19, 23 gen 2018 (CET)

Volentieri :-) Intanto volevo scrivere il mattone qui. Provvedo anche di là --Daimona Eaytoy (Scrivimi!) 19:52, 23 gen 2018 (CET)

Apprezzo moltissimo che vi siate intesi e messi d'accordo, --Elitre (WMF) (msg) 20:33, 24 gen 2018 (CET)

Già, vediamo cosa si riesce a fare. Rimango però piuttosto scettico su una vera risoluzione del problema senza la pulizia di tutte le wiki e/o una qualche sorta di filtro integrato da parte di WMF. Per il momento ho fatto richiesta di bot su enwiki (già che sono di fretta qui, figuriamoci lì), anche se ovviamente non sono troppo happy di flaggarmi di punto in bianco, avendo in tutto una decina di edit lì e volendo effettuare un task dalle dimensioni colossali. Vedremo come va, per il momento possiamo accontentarci di essere quasi a secco di errori qui :) --Daimona Eaytoy (Scrivimi!) 20:43, 24 gen 2018 (CET)

Molteplici tag di formattazione non chiusi

Nelle ultime settimane ho ridotto la sezione urgente "Molteplici tag di formattazione non chiusi" da più di 400 errori ad una trentina. Gran parte delle volte è bastato usare questa regola:

• Find: (<small>(([^<\n]*(<(?! *(/ *)?small)[^<\n]*)*<small>[^<\n]*(<(?! *(/ *)?small)[^<\n]*)*</small>)?)*?(?!.*< */ *small>).*?)(<small>)?$
• Replace: $1</small>

--Horcrux_九十二 12:32, 8 feb 2018 (CET)

Ottimo lavoro, grazie mille. Nel mentre ho notato che gli errori (tanto per cambiare) non sono sincronizzati: vengono listati i log delle cancellazioni ma non le pdc in sé. Ho dummy-editato il {{Votazione cancellazione}} nella speranza di far comparire quelle che mancano, che comunque dovrebbero essere poche.--Daimona Eaytoy (Scrivimi!) 12:44, 8 feb 2018 (CET)

Commenti HTML: falsi positivi?

Salve, ho notato che la voce Antiochia di Pisidia è elencata tra gli "Errori di Lint: Tag annidati male". Facendo un paio di prove, ho visto che l'errore è generato dalla presenza nel template Sito Archeologico di quei commenti tipo <!-- Localizzazione -->,<!-- Dimensioni -->, <!-- Scavi --> ecc.

Ci sono altre voci che utilizzano i commenti di codice HTML in svariate posizioni che generano errori. Ma sono da considerare degli errori veri e propri? Io li trovavo pure utili... --Skyfall (msg) 10:59, 9 feb 2018 (CET)

[@ Skyfall] Ciao, in realtà l'errore non viene da quei commenti. Il problema era l'utilizzo del corsivo nel parametro "nome_altro", che include già un corsivo di fabbrica. In questi casi il fix è questo, per evitare conflitti tra corsivi. Al volo, colgo l'occasione per suggerire come individuare gli errori più velocemente: usare Speciale:EspandiTemplate per convertire il template dove si trova l'errore in HTML, incollare il risultato in una sandbox e verificare da lì, così viene evidenziato solo il pezzo veramente colpevole. --Daimona Eaytoy (Scrivimi!) 11:35, 9 feb 2018 (CET)

In realtà lì non credo che si volessero annidare due corsivi, anzi il contrario (i due '' erano usati per rimuovere il corsivo solo da una parte del testo). Infatti con questo edit si ottiene lo stesso risultato senza generare l'errore.

In linea di massima, per questi casi potrebbe essere utile un template come {{no corsivo|prova}} che andrebbe a generare </i>prova<i>, però nella pratica questo template potrebbe solo ridurre e non azzerare il numero di errori di questo tipo (il corretto annidamento infatti dipende anche da altre variabili...).--Horcrux_九十二 12:00, 9 feb 2018 (CET)

Non è comunque corretto interagire in quel modo col codice del template, perché il template potrà sempre essere modificato per conto suo senza ragionevolmente tenere in conto casi del genere. Il codice corretto da inserire in voce è <span style="font-style:normal">(Profeta)</span>.--Sakretsu (炸裂) 12:27, 9 feb 2018 (CET)

Vero, motlo meglio. E ancora meglio se messo in un template (appena scoperti: en:Template:Noitalic e en:Template:Nobold :-)). --Horcrux_九十二 13:09, 9 feb 2018 (CET)

Il problema di base rimane: capita spesso che apici di formattazione vengano inseriti in template che già li hanno incorporati, più o meno volontariamente e con obiettivi diversi. Senz'altro il riposizionamento degli apici all'interno del template risolve qualcosa, ma effettivamente quei template da inserire in loco potrebbero far comodo. --Daimona Eaytoy  (Scrivimi!) 13:30, 9 feb 2018 (CET)

Problemi analoghi interessano i moltissimi template, maggioranza di quelli elencati nella terza colonna qui (non proprio tutti, perlomeno hanno questo problema "Template:struttura militare", "Template:Sito archeologico", "Template:Composizione musicale", "Template:isola" ecc.). In pratica tutti quelli con un codice per il titolo un po' troppo elaborato,tipo:

TitoloInt = {{Pipetrick||{{{Nome|}}}}}{{#if:{{{Nome_altro|}}}|<br/><small>''{{{Nome_altro}}}''</small>}} oppure

TitoloInt = {{Pipetrick||{{{Nome|}}}|{{{nome|}}}}} |SottoTitolo = {{#if:{{{Nome originale|}}}|''{{{Nome originale}}}''{{#if:{{{Parte di|}}}|<br/>}}}}{{{Parte di|}}} oppure

TitoloInt = {{Pipetrick||{{{Nome|}}}}}{{#if:{{{Nome_originale|}}}|<br/>''{{{Nome_originale}}}''}}{{#if:{{{Soprannome|}}}|<br/>''{{{Soprannome}}}''}}

A questo punto verrebbe da chiedersi se è meglio mettere mano al codice dei template (tipo con soluzioni proposte prima) o alle pagine voci che utilizzano i template. --Skyfall (msg) 18:48, 9 feb 2018 (CET)

Al momento non posso indagare bene quali siano i problemi effettivi, ma c'è poco che si possa fare all'interno dei template stessi, almeno in casi come quello sopra. Se il parametro ha il corsivo preimpostato e si vuole inserire in quel campo qualcosa per metà senza corsivo, occorre uno dei fix detti sopra. Alcuni più user-friendly (template), altri meno (tag i o span con opportuno CSS), ma serve comunque che sia l'utente a risolvere caso per caso. --Daimona Eaytoy (Scrivimi!) 20:40, 9 feb 2018 (CET)

Si può anche aspettare "che sia l'utente a risolvere caso per caso", ma i casi in quella categoria forse sono migliaia. A volte non servono delle gran modifiche per rendere i template piu robusti. Ad esempio, il primo di quelli riportati sopra é il codice di "Template:Sito archeologico" e la parte critica è:

 <small>''{{{Nome_altro}}}''</small>

Se l'utente aggiunge delle altre virgolette o degli altri small va in errore. Ma la formattazione del titolo aggiuntivo la si può fare anche con lo  span, tipo:

<span style="font-style:italic;font-size:80%;">{{{Nome_altro}}}</span>

--Skyfall (msg) 07:59, 10 feb 2018 (CET)

[← Rientro] È vero, ma a maggior ragione in questi casi il codice diventa ancora più elaborato. Senza contare il fatto che a quel modo l'utente perde la possibilità di usare alcune soluzioni semplici per la formattazione. Ad esempio, qualunque inserimento di apici per cambiare formattazione diventa inutile (cioè non fa nulla) e occorre lo stesso ricorrere a soluzioni come quelle proposte. In sostanza, si corregge l'HTML ma si cambia il risultato grafico. --Daimona Eaytoy (Scrivimi!) 12:51, 10 feb 2018 (CET)

Secondo me il fatto che "si cambia il risultato grafico" (e "occorre lo stesso ricorrere a soluzioni come quelle proposte") non è necessariamente un male. Usare, come si fa ora, il doppio apice per rimuovere il corsivo è fuori standard e rischia, come vediamo, solo di creare confusione. Nel modo descritto da Skyfall si obbliga l'utente a usare strumenti più adatti. --Horcrux_九十二 13:17, 10 feb 2018 (CET)

Il fatto di usare soluzioni come il template che hai proposto non è un male, anzi! Risolverebbe un sacco di cose. Ma non possiamo pensare di risolvere migliaia di errori con quella modifica al template e basta. Certo, gli errori HTML spariscono, ma il parametro in questione diventa tutto in corsivo nonostante la presenza di apici. Ciò moralmente vuol dire che va comunque data una passata per sostituire gli apici con il suddetto template. Del resto sono del tutto d'accordo, gli apici per togliere il corsivo sono il male, è un utilizzo fuori standard e alle volte imprevedibile. Con la proposta di Skyfall + template "no corsivo" andrebbe molto meglio, ma la botolata serve comunque, tutto qui. --Daimona Eaytoy (Scrivimi!) 13:43, 10 feb 2018 (CET)

Sì, è esattamente quello che dicevo io. Ora si dà la botolata, mentre in futuro l'utente che prova a usare il doppio apice per rimuovere il corsivo dovrà adeguarsi (chiedendo, guardando le altre voci, o consultando le linee guida che saranno aggiornate a dovere). --Horcrux_九十二 13:48, 10 feb 2018 (CET)

Concordo. Abbiamo già una lista di template da cui partire? --Daimona Eaytoy (Scrivimi!) 14:26, 10 feb 2018 (CET)

È difficile generare un elenco, ma possiamo partire dai template presenti in Speciale:LintErrors/misnested-tag, ovvero:

Elenco template

1. Template:16TeamBracket
2. Template:3TeamRR-TennisWide
3. Template:4TeamRR-TennisWide
4. Template:Aerogeneratore
5. Template:Album
6. Template:Alimentare
7. Template:Approfondimento
8. Template:Auto
9. Template:Azienda
10. Template:Bio
11. Template:Box successione
12. Template:Brano musicale
13. Template:Carica pubblica
14. Template:Cita libro
15. Template:Cita news
16. Template:Cita pubblicazione
17. Template:Cita web
18. Template:Citazione
19. Template:Citazione necessaria
20. Template:ClimaAnnuale
21. Template:College
22. Template:Competizione sportiva
23. Template:Composizione musicale
24. Template:Composto chimico
25. Template:Computer
26. Template:Diagramma scacchi
27. Template:Diagramma scacchi piccolo
28. Template:Divisa Calcio
29. Template:Doppia immagine
30. Template:Dx
31. Template:Elezioni
32. Template:Ensemble
33. Template:FictionTV
34. Template:Film
35. Template:Finestra
36. Template:Fiume
37. Template:Fumetto e animazione
38. Template:Incontro di club
39. Template:Incontro internazionale
40. Template:bombardamento
41. Template:conflitto
42. Template:isola
43. Template:Infobox nave
44. Template:stazione ferroviaria
45. Template:struttura militare
46. Template:Unità militare
47. Template:Lang
48. Template:Legend2
49. Template:Libro
50. Template:Lingua
51. Template:Mappa di localizzazione+
52. Template:Monarca
53. Template:Navbox ferrovia
54. Template:Nazionale di calcio
55. Template:NazioneGiochiOlimpici
56. Template:Nihongo
57. Template:Opera d'arte
58. Template:Organizzare
59. Template:Parco
60. Template:Percorso fer1
61. Template:Percorso linea metropolitana
62. Template:Personaggio
63. Template:Polytonic
64. Template:Quote
65. Template:Sito archeologico
66. Template:Sportivo
67. Template:Squadra di calcio
68. Template:Statistiche dei giocatori
69. Template:Stato
70. Template:Stato storico
71. Template:Tassobox
72. Template:Terremoto
73. Template:Testata giornalistica
74. Template:Titolo nobiliare
75. Template:Torneo ottavi finalina
76. Template:Torneo quarti finalina
77. Template:Torneo-tennis-4 colonne
78. Template:Tour musicale
79. Template:Tracce
80. Template:Tracklist
81. Template:Valle
82. Template:Videogioco
83. Template:ViolazioneCopyright
84. Template:Volume Manga

che mi sembra verosimilmente completo.

In ogni caso, credo che sia necessario fare un riassuntino della questione e chiedere consenso in DP:Template. --Horcrux_九十二 17:11, 10 feb 2018 (CET)

Ammazza! Dopo aver completato l'elenco c'è sempre tempo per vedere se manca qualcosa. Non so quanto potrò occuparmene perché fra una cosa e l'altra ultimamente il mio bot è a riposo, comunque vediamo cosa ne pensano in progetto.--Daimona Eaytoy (Scrivimi!) 17:32, 10 feb 2018 (CET)

Se si tratta di chiedere consenso in DP:Template (oppure di fare un bot che riordini le "licenze estetiche" usate nei vari template), segnalo che in Template:Carica pubblica spesso vedo che in incarichi2=, specie quando gli incarichi minori sono molti, mettono un <small> all'inizio e alla fine (tipo Giovanni Nonne o Carlo Aristide Dal Sasso). Ebbene, tale <small> da errore "Tag annidati male". Sono tanti così. --Skyfall (msg) 19:52, 10 feb 2018 (CET)

[← Rientro] L'equivalente del tag small sarebbe font-size:small. La resa deve sempre essere gestita automaticamente dai browser, perché potrebbe cambiare in futuro. Comunque non sono molto convinto riguardo alla botolata. Gli errori relativi a questa specifica problematica sono probabilmente molti di meno di quello che sembra. Non vorrei che invece finissimo per spammare template come il No corsivo dove non servono.--Sakretsu (炸裂) 20:17, 10 feb 2018 (CET)

È vero ma, almeno secondo me, la botolata non avrebbe come scopo principale la risoluzione degli errori, quanto piuttosto la scomparsa degli apici utilizzati per togliere il corsivo, che oltre agli errori generano anche confusione. Si prenderebbero due piccioni con una fava. --Daimona Eaytoy (Scrivimi!) 11:53, 11 feb 2018 (CET)

(Certo che se fate tutto voi poi vi stancate :) Non ci sono altri a cui potete delegare almeno la decisione - poi se vi tocca implementarla, almeno è una cosa in meno che vi è toccata? :) Comunque in realtà passavo solo per segnalare questo a proposito di Linter. Grazie, --Elitre (WMF) (msg) 19:21, 11 feb 2018 (CET))

Dovremmo vedere cosa ne pensano gli altri in DP:Template :) Al momento però non posso praticamente occuparmene perché ho messo casa su phab. Comunque per Linter non credo sia un problema troppo grosso, a meno che non sia troppo grossolano. --Daimona Eaytoy (Scrivimi!) 14:39, 12 feb 2018 (CET)

Template:NazioneGiochiOlimpici

Il template in oggetto causa una valanga di tag annidati male (small per la precisione). Ho notato che all'interno del template vengono richiamate delle sottopagine del template che hanno dei tag "div" che rimangono all'interno dello small. Questo per quanto riguarda html5 è ammesso? Come si può risolvere il problema? --LucaRosty (Scrivimi) 14:31, 12 feb 2018 (CET)

Forse ho risolto --LucaRosty (Scrivimi) 14:38, 12 feb 2018 (CET)

Non ho indagato sul perché desse errore prima, comunque ora dovrebbe andare. Solo un appunto: l'equivalente dello small è font-size:smaller, che lascia al browser la gestione effettiva della dimensione ;) --Daimona Eaytoy (Scrivimi!) 14:44, 12 feb 2018 (CET)

L'errore dovrebbe dipendere dal fatto che questi contengono l'annidamento <div><span></span></div>. Il template {{NazioneGiochiOlimpici}} prende la sottopagina e la wrappa con gli <small>…</small>, ottenendo come risultato finale <small><div><span></span></div></small>. Evidentemente al parser ciò non piace, infatti:

«Element div not allowed as child of element small in this context.

Contexts in which element div may be used:
:Where flow content is expected.
:As a child of a dl element.
Content model for element small:
:Phrasing content.»

(vedi anche Discussioni utente:Blackcat#Inserimento errori di Lint). --Horcrux_九十二 16:10, 12 feb 2018 (CET)

Smaltimento errori tag non chiusi

[@ Daimona Eaytoy, Horcrux92, Sakretsu] Vi segnalo che a distanza di 6 mesi dal mio ultimo intervento tramite bot, sono ripartito di nuovo alla ricerca di soluzioni automatizzate per ridurre drasticamente i copiosi errori di formattazione non ancora risolti. In particolare, tra ieri ed oggi ho trovato (non senza qualche difficoltà) una soluzione per chiudere correttamente tutti quei grassetti e corsivi lasciati "appesi" come se nulla fosse; al momento mi sto limitando solo ai doppi/tripli apici adiacenti alle doppie parentesi quadre, ma a breve cercherò di estendere il concetto anche a tutti gli altri casi pendenti. Le regex che ho dato in pasto a Messbot sono le seguenti:

CHIUSURA GRASSETTO

• Find: (?<![Ll])(\'\'\'\[\[(?:(?!\]\]).)*\]\])(?!(.*\'\'\'))
• Replace: $1'''

CHIUSURA CORSIVO

• Find: (?<![Ll])(\'\'\[\[(?:(?!\]\]).)*\]\])(?!(.*\'\'))
• Replace: $1''

Inoltre ho scoperto che in realtà i casi di tag HTML non chiusi riportati in Speciale:LintErrors sono inferiori rispetto a quelli effettivamente elencati in Speciale:LintErrors/missing-end-tag: quando ieri sera ho estratto tutti i nominativi presenti lì dentro, ho conteggiato poco più di 170000 errori nel solo NS0 a dispetto dei circa 126000 errori indicati nella pagina speciale riassuntiva (ora i numeri sono diversi, avendo fatto girare il mio bot, ma il discorso non cambia; tra l'altro ho notato che quando procedo al refresh di quella pagina, quel valore oscilla di qualche migliaio per qualche strano motivo che non sono riuscito ad identificare). -- Mess what a happiness! 22:32, 16 mar 2018 (CET)

[@ Mess] Grazie per il lavoro. Qualche giorno fa anche io avevo provato a dare una passata, arrendendomi quasi subito. Ultimamente sono un po' impegnato su phab e non potrò riprovare, ma vi passo volentieri le impostazioni scritte a suo tempo per questo genere di errori. Mi basta sapere se preferite l'xml completo (auguri!) o il minimo indispensabile e ve lo faccio arrivare.--Daimona Eaytoy (Scrivimi!) 01:43, 17 mar 2018 (CET)

[@ Daimona Eaytoy] Ti ringrazio per la proposta, ma per il momento preferisco procedere per conto proprio, risolvendo gli errori un passo alla volta. -- Mess what a happiness! 10:04, 17 mar 2018 (CET)

Non c'è problema, se a qualcuno servissero basta un fischio :-).--Daimona Eaytoy (Scrivimi!) 10:43, 17 mar 2018 (CET)

Intanto ho scoperto il motivo per cui i conteggi degli errori non combaciano alla perfezione: lo trovate in questo maniphest su Phabricator (in sostanza hanno dichiarato che, per ovviare al fatto che c'erano ancora delle pagine già corrette ancora segnalate come da correggere, i conteggi nelle wiki maggiori vengono approssimati tramite un'apposita funzione MySQL). Il caso l'avranno pure dichiarato chiuso, ma per me il problema non è stato comunque risolto: trovo assurdo (tanto per fare un esempio) leggere da un lato 2 errori in "Tabella multilinea in lista" e poi dall'altro aprire la sottopagina per scoprire che ce ne sono zero! [@ Elitre, Elitre (WMF)], visto che ti sei interessata al problema, gradirei cortesemente che tenessi in conto tale effetto collaterale e che ci informassi tempestivamente nel caso in cui si riuscisse a ripristinare l'esatto conteggio; in caso contrario, aprirò un nuovo maniphest per sollecitare chi di dovere su quest'aspetto. -- Mess what a happiness! 11:15, 17 mar 2018 (CET)

Ehm, come non detto: tale inconveniente ha ancora un maniphest aperto qui. Per la fretta di leggere ho mischiato 2 problematiche in 1: in realtà i conteggi "virtuali" sono dovuti meramente ad una questione di performance (dato che per calcolare il tutto servono tempo e risorse). Va be', vorrà dire che attenderemo fiduciosi... -- Mess what a happiness! 15:59, 17 mar 2018 (CET)

Piccolo aggiornamento dopo circa 2 settimane di attività. Qualche ora fa ho conteggiato singolarmente le varie categorie (visto che ancora adesso i calcoli ufficiali sono orientativi) e al momento i numeri (in ordine decrescente di quantità) sono i seguenti:

• Tag di chiusura mancante: 128206 (mentre il conteggio ufficiale ne riporta quasi 75000; il bello è che prima del mio intervento nel solo NS0 ce n'erano poco più di 170000 ed ora li ho ridotti a circa la metà);
• Tag spaiati: 15041 (a fronte del quantitativo quasi doppio - circa 28000 - del conteggio ufficiale);
• Tag annidati male: 7490 (anche qui il quantitativo stimato è 2 volte quello reale, ovvero poco più di 15000);
• Contenuto di tabella in posizione errata: 344 (una delle poche categorie in cui conteggio stimato e conteggio reale coincidono);
• Tutte le altre categorie: al di sotto di 20

In totale ci sono quindi poco più di 150000 errori da sistemare ancora; è sicuramente la parte più dura (visto che a mano a mano che si scava in fondo si trovano solo casi particolari che non si riescono a correggere in blocco), ma sono convinto che in qualche modo ce la faremo a levarceli di torno in tempi molto rapidi. -- Mess what a happiness! 14:36, 28 mar 2018 (CEST)

Grazie dell'aggiornamento! --LucaRosty (Scrivimi) 11:29, 30 mar 2018 (CEST)

Intanto ho scoperto il modo per avere un conteggio corretto in maniera automatica grazie alle query su Quarry: lo trovate qui e lo aggiornerò in maniera costante. Purtroppo le categorie sono numerate e non è possibile risalire direttamente al nome corrispondente, ma orientativamente la legenda è questa:

• Linter_cat 1: Contenuto di tabella in posizione errata;
• Linter_cat 2: Tag HTML obsoleti;
• Linter_cat 3: Parametri di "File:" inesistenti;
• Linter_cat 4: Tag di chiusura mancante;
• Linter_cat 5: Tag spaiati;
• Linter_cat 7: Tag "table" che dovrebbe essere cancellato;
• Linter_cat 8: Tag annidati male;
• Linter_cat 13: Problema di Tidy che riguarda i tag font contenenti collegamenti;
• Linter_cat 14: Molteplici tag di formattazione non chiusi.

-- Mess what a happiness! 16:49, 3 apr 2018 (CEST)

Aggiungo Linter_cat 12: Tag annidati male con resa differente in HTML5 e HTML4 --LucaRosty (Scrivimi) 17:53, 13 apr 2018 (CEST)

Linter_cat 6: Tag autochiusi --LucaRosty (Scrivimi) 12:47, 27 apr 2018 (CEST)

Linter_cat 16: Tabella multilinea in lista --LucaRosty (Scrivimi) 12:15, 16 mag 2018 (CEST)

Linter_cat 17: Vari problemi di sostituzione di Tidy -- Mess what a happiness! 11:51, 7 ago 2018 (CEST)

Ho visto oggi questa nuova categoria. "Vari problemi di sostituzione di Tidy" Detto in poche parole di cosa si tratta? --LucaRosty (Scrivimi) 14:13, 11 ago 2018 (CEST)

La normale sequenza div > span (div contenente span) è ribaltata, per cui si ha uno span che contiene un div. Il fix non è invertire i tag, ma capire perché è stato inserito un div in uno span e agire di conseguenza. Ad esempio qui il div era immotivato (lo span che avvolge il div non si vede perché è generato dal template Mappa di localizzazione~).--Sakretsu (炸裂) 16:31, 11 ago 2018 (CEST)

Ciao a tutti, ho visto che il problema del tag div > span è presente nelle pagine generate automaticamente Nati nel... e Morti nel.... Dovrei aver sistemato il template ma per evitare di passare manualmente tutte le pagine sarebbe possibile far fare un giro a bioBot per sistemare tutte le pagine? --LucaRosty (Scrivimi) 15:39, 22 ago 2018 (CEST)

Come non detto gli errori sono andati via! --LucaRosty (Scrivimi) 15:49, 22 ago 2018 (CEST)

Linter_cat 15: Apici non chiusi in intestazione --LucaRosty (Scrivimi) 14:29, 3 set 2018 (CEST)

Linter_cat 9: Errore di capoverso aggirabile --LucaRosty (Scrivimi) 09:22, 20 set 2018 (CEST)

È comparso un errore nella categoria Errore di capoverso... Questa tipologia di errore come la si può risolvere? --LucaRosty (Scrivimi) 17:04, 20 set 2018 (CEST)

Il problema non risiedeva nel template:Pro B, ma nei template in esso richiamati {{Basket Chartres}}, {{Basket Gries Oberhoffen}} e {{Basket Parigi}} che avevano un tag aperto e testo distribuito su più righe che provocava la rottura dello span del {{Tutto attaccato}}. Comunque come errore di alta priorità era un falso positivo dato che la resa alla fine era identica.--Sakretsu (炸裂) 00:58, 21 set 2018 (CEST)

Tag spaiati

Stavo notando come i più dei 30.000 tag spaiati consistano essenzialmente da una gran quantità di tag di chiusura senza i relativi tag di apertura. Quelli che per intenderci, a chi usa la "Evidenziazione della sintassi nel wikitesto" (nelle funzionalità sperimentali, una meraviglia), vengono segnalati in rosso perché errori palesi. Ma che senso ha mantenerli (tranne giusto nelle sandbox e nelle pagine di esempio? La loro eliminazione non farebbe che migliorare la leggibilità del testo. Almeno in n0, non sarebbe meglio spazzarli tutti via con un bot? --Skyfall (msg) 20:11, 30 mar 2018 (CEST)

[@ Skyfall] A parte il fatto che (come già annunciato sopra) i tag spaiati sono 15000 e non 30000 (ignora i dati che leggi nel report generale: al momento vengono calcolati in maniera indiretta perché il conteggio effettivo automatico ha comportato una serie di problemi che non sto qui a spiegare), il punto è che tali errori (ma anche quelli delle altre categorie) non hanno un pattern predefinito (o, se ce l'hanno, è di difficile risoluzione). Se potessi avere un valido aiuto su come trovare un metodo per automatizzare il processo di rimozione dei tag su un ampio quantitativo di voci e senza scompaginare involontariamente il testo, non mi farei pregare due volte nell'attivare il mio bot e metterlo a disposizione di tutti. -- Mess what a happiness! 23:06, 30 mar 2018 (CEST)

È molto più semplice dirsi che farsi: tutti e i soli tag di chiusura che la evidenziazione della sintassi nel wikitesto fa apparire in rosso. Quando sono di tale colore, non scompagini il testo perché lo è già, in quanto manca il tag di apertura. Casomai, si migliora il testo presente. --Skyfall (msg) 01:42, 31 mar 2018 (CEST)

Credo che Mess volesse dire che è impossibile dire a un bot "togli i tag evidenziati di rosso", altrimenti senz'altro sarebbe più facile e veloce --Daimona Eaytoy (Scrivimi!) 12:26, 31 mar 2018 (CEST)

Sì, [@ Daimona Eaytoy], è proprio così: magari esistesse un bot che cancellasse automaticamente quei tag tramite le evidenziature di quella funzionalità speciale! Tecnicamente sarebbe pure possibile, però molto probabilmente bisognerebbe costruire il bot da zero (io, così come tanti altri manovratori di bot, operiamo tramite AutoWikiBrowser, ma quest'ultimo non è personalizzabile sotto questo punto di vista), sperando soprattuto che l'evidenziatura sia integrabile con esso. Ovviamente ordinare ad AWB di eliminare (tanto per fare un esempio) due tag "div" di chiusura consecutivi non ha alcun senso, perché in una pagina potrebbere essere sintomo di un tag spaiato (come nel link indicato da [@ Skyfall]), ma in un'altra no, perché essi potrebbero servire a chiudere correttamente due tag "div" di apertura. Come vedete, non è tutto oro ciò che luccica... -- Mess what a happiness! 14:30, 31 mar 2018 (CEST)

Concordo. Forse potrebbe esserci la possibilità di reperire le informazioni del syntax highlight, ma non sarebbe semplice. --Daimona Eaytoy (Scrivimi!) 14:36, 2 apr 2018 (CEST)

[@ Daimona Eaytoy] In realtà il modo a quanto pare esiste: qualche giorno fa ho letto questo topic in cui un collega di zh.wiki (la Wiki cinese, per intenderci), che ha realizzato un bot in PHP ad hoc per la risoluzione degli errori di Lint, chiedeva consigli su come implementare la localizzazione di tali evidenziature, visto che richiedendo delle apposite query con le API di MediaWiki (ad esempio questa è per la categoria "Tag HTML obsoleti") si ottengono gli intervalli di testo in cui sono presenti gli errori (indicati con un numero di caratteri di offset rispetto all'inizio del wikitesto: ad esempio un "location: [7146, 7167]" significa che l'errore è compreso tra il carattere n. 7146 e il carattere n. 7167). Purtroppo non sono molto esperto in quest'ambito, però se da quelle query si potessero almeno estrapolare i pezzi di testo contenenti gli errori e successivamente raggrupparli per gruppi omogenei (ad esempio per tipo di tag), si potrebbe avere un quadro d'insieme su quali errori sono più ricorrenti e di conseguenza intervenire più puntualmente su di essi (senza dover pescare nel mucchio come sto facendo finora). -- Mess what a happiness! 15:53, 2 apr 2018 (CEST)

Infatti era immaginabile che un modo esistesse :) Il fatto è che bisognerebbe impiegare del tempo per scrivere un bot ad hoc come ha fatto il collega, e anche io non so bene come utilizzare le query. Un'alternativa potrebbe essere (richiede comunque di costruire da zero il bot) di implementare direttamente l'engine del syntax highlight per sapere dove sono i tag da eliminare. --Daimona Eaytoy (Scrivimi!) 17:15, 2 apr 2018 (CEST)

Forse ho capito male ma serve qualcosa tipo: questo? La fonte sono le API indicate, la formattazione può essere cambiata in qualsisasi maniera. --ValterVB (msg) 18:36, 2 apr 2018 (CEST)

[@ ValterVB] Ma sei un grande! È proprio quello che desideravo! Si potrebbe avere un report completo (o comunque un'indicazione su come generarlo)? -- Mess what a happiness! 14:34, 3 apr 2018 (CEST)

Si, è molto carino. Non è proprio quello che avevo scritto io (mi stavo riferendo ai tag di chiusura per i quali non risultano dei tag di apertura), ma potrebbe essere estremamente utile. Si potrebbe fare un bel bot se non fosse che esiste anche un tipo di errore intermedio (e più complesso), i Tag annidati male, per cui il tag di chiusura ci sarebbe, però un po' più in la, dopo un altro tag o un accapo. --Skyfall (msg) 14:54, 3 apr 2018 (CEST)

Chiaramente quella pagina è solo un esempio se serve per un altro tipo di errore come per esempio "Errori di Lint: Tag spaiati" si può fare. Diciamo che la differenze fra API e Pagina speciale è che con l'API viene indicato la parte di testo incriminato. [@ Mess] Il BOT l'ho fatto in C# quindi se usi normalmente Visual Studio posso passartelo, può lavorare sia in Wikipedia che in Wikidata e può usare le liste generate da strumenti come Wikidata Query Service o Petscan, se no basta che indichi cosa serve. In quella pagina ho riportato solo un tipo di errore e solo in ns0. --ValterVB (msg) 19:47, 3 apr 2018 (CEST)

[@ ValterVB] Sì, ti sarei grato se me lo passassi. Comunque a me servirebbe praticamente per visionare tutti gli errori ancora pendenti su qualunque namespace (al limite si potrebbe pure restringere la ricerca su piccoli gruppi specifici, ma solo se non li si può elencare per intero). Nel frattempo proseguirò i miei interventi manuali sui casi più sporadici (come i contenuti di tabella in posizione errata e i molteplici tag di formattazione non chiusi). -- Mess what a happiness! 23:07, 3 apr 2018 (CEST)

[@ Mess] Eccolo qua Spero sia tutto a posto perché sono molto esperto con Github. Il form principale è quello che si chiama "frmVBot", seleziona il tab "Wikipedia report" vicino al pulsante "Lint error" c'è la casella di testo dove inserire la categoria di errore, e subito dopo il checkbox per selzionare solo l'ns0 se non selezionato mostra tutto. Attualmente è limitato a 100 elementi se vuoi cambiarlo lo modifichi in "Site.cs", nelle procedure public string LintError(string lntcategories) e public string LintError(string lntcategories,string ns) Se non hai un'utenza bot puoi mettere al massimo 500, se no puo iinserire 5000. Utenza e password le inserisci all'avvio del programma, nelle caselle "Bot user" e "Bot password" usa l'utenza bot se ce l'hai se no per molte transazioni basta un'utenza normale. Leggi il readme nella pagina di github. Se hai problemi fammi sapere magari nella mia pagina di discussione, se invece vuoi direttamente il report dimmi come e dove lo vuoi. --ValterVB (msg) 23:32, 6 apr 2018 (CEST)

[@ ValterVB] Grazie 1000! Fortunatamente ho capito come far funzionare il bot, come si può osservare da questa mia sandbox. Purtroppo mi sono reso conto che devo limitarmi a 500 risultati non tanto per la questione "hai il bot/non hai il bot" (perché ad avercelo ce l'ho), ma semplicemente per una mera questione di dimensione del report generato (visto che già a 500 si ottengono file di centinaia di migliaia di byte, quindi moltiplicando per 10 si avrebbe un testo mostruoso di svariati megabyte che verrebbe generato troppo lentamente, quindi meglio lasciar perdere; tanto a me interessa individuare dei cluster di errori omogenei anche su un campione ridotto dell'intera categoria). Inoltre ho modificato il codice sorgente per far sì che la categoria di errore immessa nella casella di testo venisse effettivamente recepita dal bot, poiché nel master che ho scaricato da Github la categoria era fissata staticamente nel codice e non poteva essere modificata (in pratica, per com'era stato scritto, quella casella di testo non serviva affatto; ora l'ho resa pienamente funzionale inserendo textLintCat.Text). -- Mess what a happiness! 10:05, 8 apr 2018 (CEST)

Bellissimo! Vedo che individua abbastanza bene i "tag rossi" di cui parlavo prima, che in voci come Eulemur, Ochotona, N-idrossiarilammina O-acetiltransferasi, poiché sono posti al di fuori dei template sono più facilmente eliminabili in automatico. Magari ci sono tag di chiusura come </span> e </div> più delicati, ma gli </small>, sono chiaramente degli errori. --Skyfall (msg) 10:35, 8 apr 2018 (CEST)

Per quanto riguarda la velocità in realtà si potrebbe ottimizzare, in questo momento legge le pagine una a una, dovrei modificarlo per caricare 500 pagine per volta (50 se non si è BOT) migliorerebbe di molto. Se ho tempo magari lo modifico e lo metto in un form a parte e lo faccio un po' più flessibile con la correzione (grazie del debug, avevo buttato giù velocemente il tutto). --ValterVB (msg) 11:23, 8 apr 2018 (CEST)

[@ Mess] L'ho ottimizzato come dicevo (Github aggiornato), con utenza bot elabora 5000 pagine in un paio di minuti forse meno. Seleziona la tab "Wikipedia", e clicca sul pulsante "Lint errors", si apre un form dove puoi scegliere il progetto, impostare il massimo numero di errori da importare o selezionare se solo ns0 o tutto. Se metti la spunta a "is a BOT" e sei un BOT recupera 500 pagine per volta, se no, ne recupera solo 50, intanto ho anche iniziato a ripulirlo un po' non ho messo la paginazione per andare oltre i 5000 errori perché non so se ne vale la pena. --ValterVB (msg) 19:24, 8 apr 2018 (CEST)

"Retrospettiva"

Ciao a tutti. Come saprete, molte wiki stanno passando a Remex in questo periodo, mentre alcune tra le più grosse, tipo en.wp, probabilmente lo faranno all'ultimo momento ;) Penso possiamo essere d'accordo che il passaggio anticipato su questa wiki sia stato una buona idea e che una combinazione di fattori lo abbiano reso vincente. Adesso saremmo interessati a sapere se ci sono raccomandazioni, consigli ecc. che vorreste fornire, sia a noi in quanto supporto alle comunità che devono ancora effettuare lo switch, sia a quei membri delle comunità che come voi si accingono a fare le varie correzioni necessarie. Per esempio, c'è qualcosa che avreste voluto sapere prima di iniziare a lavorare su questo progetto? Della documentazione (anche non ufficiale) che sapete per certo abbia aiutato le persone a capire cosa c'era da fare? Un tool che se non era per quello non si andava da nessuna parte? Un promemoria che persone come me avrebbero dovuto mandare e invece non lo hanno fatto? Vorremmo rendere la transizione il più lineare possibile per quanti rimangono, sottolineando allo stesso tempo i vostri sforzi e i vostri successi. Grazie per quanto vorrete dirci! --Elitre (WMF) (msg) 14:48, 27 apr 2018 (CEST)

[@ Elitre (WMF)] È da un po' che non passo a correggere errori, quindi la mia risposta non sarà freschissima, ma ci provo. La documentazione credo sia stata buona; alcune cose sono spuntate fuori con un po' di ritardo, per alcune la documentazione andava chiarita, ma tutto nella norma, soprattutto considerando che qui siamo stati tra i primi ad occuparsene; chi lavora al passaggio in questo momento ha tutte le informazioni necessarie. Il tool per visualizzare la pagina prima e dopo la transizione era molto utile, ma sarebbe stato ancora più utile se un gadget come il lintHint fosse stato distribuito in maniera "ufficiale", dato che trovare gli errori a partire da Special:LintErrors (o dalle info pagina) non è affatto comodo (anche solo per il fatto che ogni errore aveva la sua riga, il che è comprensibile ma uno non può pensare di aprire 10 finestre di modifica per 10 errori). E a proposito di questo, forse non sarebbe stata male neanche l'aggiunta di qualche opzione alle liste in Special:LintErrors, ad esempio per poter aumentare il numero di elementi per pagina. Oppure, molto meglio, una funzione di ricerca per pagine con errori (come abbiamo, ad esempio "hastemplate" e simili). Tutte queste sono comunque puntigliosità, cose che se ci sono è meglio ma se non ci sono si fa lo stesso. Insomma, per chi si è occupato della parte tecnica del lavoro non credo (parlo un po' per me) ci siano state grosse difficoltà. L'unica cosa che davvero poteva essere migliorata è l'impatto dal punto di vista degli utenti non tecnici (cioè la maggioranza). Forse avrebbe fatto comodo qualche istruzione semplificata anche per chi è meno tecnico o, meglio ancora, uno strumento che indicasse gli errori in fase di salvataggio. Qualcosa di simile al filtro che avevo scritto, ma più selettivo: in grado quindi di mostrare solamente le istruzioni precise per risolvere l'errore in oggetto, senza perdersi in chiacchiere generali (come faccio io :D). Credo di aver detto tutto, nel complesso le cose sono andate bene e per migliorare c'è ancora tempo. --Daimona Eaytoy (Scrivimi!) 10:51, 28 apr 2018 (CEST)

Grazie. In merito alle istruzioni semplificate, visto che le abbiamo fornite e pensavamo bastassero, puoi chiarire se il problema è solo di dove si trovano? Abbiamo chiesto innumerevoli volte aiuto per migliorarle, visto il silenzio immagino siano perfette così :) --Elitre (WMF) (msg) 11:04, 2 mag 2018 (CEST)

Sì, è solo di dove si trovano. Io intendevo proprio inserire delle istruzioni a prova di stupido sul problema specifico. Esempio: inserisco un tag autochiuso; quando tento di salvare, il sistema impedisce il salvataggio e mi dice "Hey, guarda che ciò che hai scritto non va bene, quella sbarrettina lì spostala in un tag separato un po' più in là a questo modo {esempio concreto}". Per il resto, come dicevo, l'aiuto è stato notevole. --Daimona Eaytoy (Scrivimi!) 14:55, 2 mag 2018 (CEST)

Grazie, riferirò. Se ci sono altre opinioni aggiungetele. --Elitre (WMF) (msg) 15:01, 2 mag 2018 (CEST)

Daimona Eaytoy (e altri), ho riferito i complimenti sl creatore di lintHint, il quale sta per rilasciare una versione 3 del tool e vorrebbe aiuto nel tradurre le seguenti stringhe in italiano. Grazie mille! --Elitre (WMF) (msg) 12:08, 7 mag 2018 (CEST)

[@ Elitre (WMF)] Ne sono felice, cerco di dargli subito le traduzioni :-) --Daimona Eaytoy (Scrivimi!) 17:07, 7 mag 2018 (CEST)

Come non detto! [@ Sakretsu] Sei dappertutto :P --Daimona Eaytoy (Scrivimi!) 17:08, 7 mag 2018 (CEST)

Tag CODE

Monitorato su Phabricator
Task T68655

Ciao a tutti, ho notato in diverse pagine comportamenti strani che si hanno quando nella pagina è presente un tag "CODE". Nello specifico si vedono prima e dopo diversi "box" grigi prima e dopo l'effettivo "box" dove si trova il contenuto del tag CODE. Qui un esempio. Come si può risolvere questo problema? Inoltre questo genera un errore di tag mal annidati --LucaRosty (Scrivimi) 13:12, 4 mag 2018 (CEST)

Ce l'ho anche sulla mia wiki privata, il che mi fa sospettare fortemente di un problema del parser wikitesto. --Daimona Eaytoy (Scrivimi!) 13:15, 4 mag 2018 (CEST)

Il problema sembra vecchiotto, v. task nel tracked qui accanto. --Daimona Eaytoy (Scrivimi!) 13:21, 4 mag 2018 (CEST)

Un tag code non può contenere più tag pre su righe a sé. Dato che il tag si rompe, si generano tag code vuoti che in RemexHTML danno come risultato . La soluzione è rimuovere il tag code che non serve a nulla.--Sakretsu (炸裂) 13:56, 4 mag 2018 (CEST)

Toh, non avevo notato i pre (cioè le indentature). Confermo. --Daimona Eaytoy (Scrivimi!) 13:59, 4 mag 2018 (CEST)

Grazie a entrambi! --LucaRosty (Scrivimi) 14:09, 4 mag 2018 (CEST)

Estinzione errori residui

[@ Daimona Eaytoy, Sakretsu, Lucarosty] Dopo non poche difficoltà, ho quasi azzerato la categoria "Contenuto di tabella in posizione errata", in cui sopravvivono soltanto 2 casi simili che non sono riuscito a risolvere: Template:MedalTable e Template:IntestazioneMedagliere tecnicamente non generano errori nelle voci in cui sono contenute, ma ne scatenano comunque uno all'interno del loro codice sorgente; ho provato in tutti i modi a porvi rimedio, ma senza alcun esito positivo. Al contempo, vorrei che si risolvessero definitivamente anche i casi contenuti in "Tag "table" che dovrebbe essere cancellato" (chiedo agli utenti coinvolti [@ Yiyi, Playluk314], qualora avessero concluso i rispettivi esperimenti, se fosse possibile procedere ad una rimozione completa di quelle loro pagine di prova che generano quel tipo di errore) e in "Tag HTML obsoleti" (qui forse si potrebbe utilizzare il tag "nowiki" o qualcosa di simile che sopisca l'errore senza stravolgere eccessivamente il codice sorgente originario). -- Mess what a happiness! 18:41, 19 mag 2018 (CEST)

Così su due piedi direi che quei casi di contenuto di tabella in posizione errata sono falsi positivi generati dai noinclude.--Sakretsu (炸裂) 18:57, 19 mag 2018 (CEST)

Concordo con Sakretsu per quanto riguarda i due casi dei template. --LucaRosty (Scrivimi) 09:09, 21 mag 2018 (CEST)

[@ Mess] a quanto pare a qualcuno non è piaciuta la tua modifica relativa a Template:Roster Gara PC/allenatore. Ha semplicemente annullato la modifica senza chiedere spiegazioni --LucaRosty (Scrivimi) 09:02, 22 mag 2018 (CEST)

[@ Playluk314] Rinnovo il ping a Playku314. Se escludessimo la sua sandbox (che da Tag table che dovrebbe essere cancellato), oggi sarebbe il primo giorno in cui gli errori di Lint ad alta priorità si sono portati a zero. --Skyfall (msg) 17:38, 23 mag 2018 (CEST)

Veramente no, li abbiamo portati a zero il 21 novembre, ma è normale che ogni tanto ne ricompaia qualcuno.--Sakretsu (炸裂) 18:23, 23 mag 2018 (CEST)

Considerato anche che l'ultimo edit di tale sandbox che da errore fu il 23 ottobre 2011, mi pare che ci sia un problema nei conteggi degli errori residui (tanto per cambiare). Se vado qui e apro uno ad uno i link agli errori ad alta priorità, a dare errori oggi mi ritrovo solo quella pagina. E' comunque un bel risultato. --Skyfall (msg) 18:39, 23 mag 2018 (CEST)

[← Rientro][@ Lucarosty] Ho annullato io la modifica al Template:Roster Gara PC/allenatore senza sapere di questa discussione. L'ho fatto perché dopo questa modifica, perché così si sballa l'ultima riga quando si usano tutti e tre i template, come potete vedere da qui. Mi potete aiutare voi nel sistemare il tutto? Grazie --Towerman86 (scrivimi) 16:40, 25 mag 2018 (CEST)

[@ Towerman86] Ho visto che sei riuscito a risolvere nel modo corretto! --LucaRosty (Scrivimi) 16:44, 25 mag 2018 (CEST)

[@ Lucarosty] In realtà non ho risolto, ho fatto un po' di prove ma vedo ancora lo spazio. In pratica crea un <p></p> nell'ultima cella dell'ultimo giocatore. Scusate per l'ignoranza, chiedo a voi una mano ;) --Towerman86 (scrivimi) 17:31, 25 mag 2018 (CEST)

[@ Towerman86] Dovrei aver sistemato il tutto! è bastato mandare a capo la chiusura del noinclude e mettere subito dopo l'apertura della riga della tabella (era l'andare a capo prima dell'inizio dell'apertura che creava il p) --LucaRosty (Scrivimi) 17:41, 25 mag 2018 (CEST)

[@ Lucarosty] Grazie mille e scusate ancora per la modifica --Towerman86 (scrivimi) 10:42, 28 mag 2018 (CEST)

[@ Mess, Sakretsu] Finalmente anche gli ultimi due errori nella categoria "Contenuto di tabella in posizione errata" sono scomparsi. È stato sufficiente mettere il codice di formattazione della tabella nel noinclude e aggiungere un includeonly con la formattazione. Non è il massimo perché duplica il codice ma almeno ci toglie anche gli ultimi due errori — Questo commento senza la firma utente è stato inserito da Lucarosty (discussioni · contributi) 15:52, 29 mag 2018 (CEST).

Ci siamo...

Ormai manca soltanto una settimana per il mese di luglio, ovvero la scadenza prefissata lo scorso anno per il passaggio definitivo a RemexHTML. Al momento, però, non trovo nessun comunicato dettagliato in merito. Nel frattempo il quantitativo di errori totali è calato al di sotto delle 127000 occorrenze, ma non sarà possibile smaltirlo in tempi rapidi, visto che come dissi già precedentemente sono rimasti quasi esclusivamente errori difficilmente risolvibili automaticamente. [@ Elitre (WMF)], tu che sei nella stanza dei bottoni, potresti fornirci qualche dettaglio in più sull'agenda della riconversione del parser? Grazie. -- Mess what a happiness! 08:31, 23 giu 2018 (CEST)

Per passaggio definitivo si intende che anche sulle rimanenti wiki sarà disattivato Tidy in favore di Remex. Noi siamo già passati mesi fa perché avevamo risolto tutti gli errori di alta priorità. Gli errori di media e bassa priorità non provocano cambiamenti di resa e quindi sono solo un optional.--Sakretsu (炸裂) 10:51, 23 giu 2018 (CEST)

[@ Sakretsu] Va bene, pensavo che entro luglio si dovessero risolvere anche quelli (o perlomeno l'unica categoria superstiste di errori a media priorità, ovvero "Tag annidati male"), ma se non ci sono urgenze impellenti è meglio, così potremo lavorare senza avere il fiato sul collo. Io comunque proseguirò lo stesso l'opera di bonifica, così da essere pronti qualora la soglia di tolleranza venga ulteriormente abbassata. -- Mess what a happiness! 11:25, 23 giu 2018 (CEST)

Certo che la Wikipedia in inglese è messa male. Speriamo che sviluppino qualche script avanzato (e affidabile, da lanciare tranquillamente con un bot) per risolvere il problema dei tag senza chiusura riciclabile anche da noi. Noi ne avremmo poco più di 60 mila, ma loro ne hanno più di 10 milioni (il loro contatore ne segna 10.030.972, ma dovrebbe essere il valore massimo misurabile, in realtà saranno molti di più)... --Skyfall (msg) 14:16, 23 giu 2018 (CEST)

Questi i dati aggiornati per quanto ci riguarda (estratti con una query come suggerito da [@ Mess]

Tag obsoleti			     9
Tag di chiusura mancante 	109471
Tag spaiati			 11621
Tag annidati male		  1725
Tag con resa differente		     2

--LucaRosty (Scrivimi) 11:44, 25 giu 2018 (CEST)

it.wp ha completato la sua transizione mesi fa. Tutti gli errori ora sono considerabili come qualunque altro backlog, ci si può mettere mano quando si vuole. Alla fine della fiera molti si sono anche fatti i conti in tasca stabilendo che non vale nemmeno la pena mettersi lì a cambiare milioni di pagine solo perché la firma che qualcuno voleva verde sarà blu. en.wp, ovviamente anche più delle altre, è stata allertata in tutti i modi possibili, ma non so se effettivamente faranno alcunché prima dello switch. A questo punto è più probabile che qualunque intervento sarà fatto a posteriori, se e quando qualcuno solleverà un problema localmente. Voi siete stati bravissimi e se per qualche motivo volete aiutare un'altra comunità, fatevi pure avanti da loro. --Elitre (WMF) (msg) 12:09, 25 giu 2018 (CEST)

Nella mailing list degli ambassadors ci sono un paio di email di ringraziamento, ma non potevo esimermi dal lasciare un ennesimo messaggio a tutti quelli che qui, partendo da Utente:Sannita che ha inaugurato la pagina, hanno reso possibile lo switch - soprattutto in anticipo. Questo progetto è stato notevole per numerosi motivi, e il modo in cui tanti utenti qui si sono impegnati è uno dei miei preferiti. Spero che in futuro altri progetti tecnici riescano ad "appassionarvi" allo stesso modo :) --Elitre (WMF) (msg) 17:54, 13 lug 2018 (CEST)

Mi accodo volentieri ai ringraziamenti di Elitre per il lavoro svolto. Io non me ne prendo granché merito, ho soltanto avvisato che c'era questo passaggio "storico", il vero lavoro l'ha fatto chi ha corretto manualmente i template incriminati ed è poi passato a sistemare gli errori successivi. Grazie a tutti voi! --Sannita - L'admin (a piede) libero 10:11, 19 lug 2018 (CEST)

Situazione errori rimanenti

Ciao a tutti, ho modificato la query proposta da [@ Mess] alcuni mesi fa per estrarre anche la situazione di ogni errore nel singolo namespace. La potete trovare qui [4]. Come potete vedere la maggior parte degli errori sono in NS0 ma sono tutti a bassa priorità. Il secondo namespace nel senso di quantità di errori è il namespace Utente. Come si può procedere per sistemare in particolare quest'ultimo (persistono circa 21000 errori in parecchie categorie, anche quelle che alcuni mesi fa erano state azzerate) --LucaRosty (Scrivimi) 14:59, 12 ott 2018 (CEST)

Quarry

Continuando a portare avanti il lavoro di eliminazione degli errori ho utilizzato abbastanza spesso quarry per estrarmi dei dati. Questa mattina mi fallisce con questo errore "View 'itwiki_p.page' references invalid table(s) or column(s) or function(s) or definer/invoker of view lack rights to use them". Sapete dirmi se è cambiata qualche policy? --LucaRosty (Scrivimi) 09:29, 3 dic 2018 (CET)

Il problema è rientrato ieri sera. --LucaRosty (Scrivimi) 09:17, 4 dic 2018 (CET)

Errori nuovi

Stamani in Parametri di "File:" inesistenti vi sono elencati 25 errori. La maggior parte delle voci elencate non è stata mai editata nel 2019, qualcuna a gennaio, nessuna a febbraio. Due giorni fa erano zero voci. Non è la prima volta che vedo comparire voci che, nella loro cronologia, risultano non modificate da molti mesi. --Skyfall (msg) 07:40, 23 feb 2019 (CET)

L'estensione ha sempre avuto problemi nel tenere continuamente traccia di tutti gli errori sul sito. In passato ne rilevava migliaia in ritardo.--Sakretsu (炸裂) 12:39, 23 feb 2019 (CET)

A proposito delle voci che [@ Skyfall] ha segnalato la maggior parte degli errori che "compaiono" senza che siano modificate hanno per la maggior parte lo stesso tipo di errore, cioè il parametro upright duplicato. Sarebbe possibile fare una ricerca in tutte le pagine e poi passarle ad un bot per eliminare tutti gli errori? --LucaRosty (Scrivimi) 21:50, 7 mar 2019 (CET)