Discussioni progetto:Accessibilità

Da Wikipedia, l'enciclopedia libera.
Jump to navigation Jump to search
Bar tematico del Progetto Accessibilità Nuova discussione Nuova discussione
Crystal Clear app access.png
Questo è il bar tematico del Progetto Accessibilità. Per aprire una nuova discussione, clicca su "Nuova discussione".
Pix.gif
Pix.gif
Pix.gif
Pix.gif
Pix.gif
Archivio
Archivio


Avviso[modifica wikitesto]

Proposta di divieto di testo lampeggiante[modifica wikitesto]

Oggi sono finito in questa pagina utente e ho notato il gif animato lampeggiante. Dal momento che l'accessibilità al web secondo la Legge Stanca prevede di evitare tale tipo di testo, soprattutto per gli spiacevoli effetti che può causare in soggetti epilettici, e non avendo trovato una linea guida generale che ne descriva l'uso, vorrei proporre di vietare tale tipo di inserimento in tutta Wikipedia. Mi scuso anticipatamente qualora il discorso fosse già stato affrontato altrove, ma non ho trovato discussioni di carattere generale. --Aplasia 14:52, 2 apr 2013 (CEST)

c'era una bozza, ma mi sembra che non sia mai stata discussa l'elevazione al rango di linea guida. --valepert 15:31, 2 apr 2013 (CEST)
L'avevo notata e, secondo me, si potrebbe anche rendere ufficiale. Tuttavia nella bozza manca il riferimento ai testi lampeggianti, che quindi sarebbe da aggiungere, soprattutto alla luce dei potenziali effetti collaterali di tale tipo di inserimento. Non sia mai che ci tocchi leggere del tizio che ha avuto una crisi epilettica leggendo Wikipedia! --Aplasia 15:52, 2 apr 2013 (CEST)
Ovviamente Symbol support vote.svg Favorevole (è una legge, per cui). Fastidiosa e inutile fino a nociva per gli epilettici.--Giacomoseics (ama il tuo prossimo) 16:42, 2 apr 2013 (CEST)
Favorevole al divieto, in quanto eventuali eccezioni potrebbero essere gestite tramite il consenso Jalo 16:44, 2 apr 2013 (CEST)
Ufficializziamola ed integriamola per i testi lampeggianti --Bramfab Discorriamo 16:45, 2 apr 2013 (CEST)
Possiamo farlo anche subito e anche se non arrivano altri pareri visto che c'è la legge che lo dice. --Zero6 17:44, 2 apr 2013 (CEST)
Vogliamo dirgli che anche la firma è troppo vistosa? --5.175.48.13 (msg) 17:46, 2 apr 2013 (CEST)
[↓↑ fuori crono] Non mi sembra affatto una firma inappropriata, è un po' vistosa ok, ma non più di quella di Jalo qui sopra. :-) --Phyrexian ɸ 20:38, 2 apr 2013 (CEST)
[↓↑ fuori crono] Ma parliamo della stessa firma? Qualche giorno fa era come la vedi nella sua pagina utente oppure qui; ora si è "ridimensionato", ma quella di cui parlo mi pare proprio inadatta. Er Cicero.
Favorevole, concordo con tutto ciò che è stato sopra detto, visto che è tutto vero --Pietro 19:20, 2 apr 2013 (CEST)
Favorevole.--Pạtạfisik 22:04, 2 apr 2013 (CEST)
Favorevole. --pequod ..Ħƕ 11:56, 3 apr 2013 (CEST)
favorevole, alla vista di quel gif mi stava venendo mal di testa. Le gif animate a parer mio dovrebbero avere animazioni lente e poco appariscenti, senza cambi di colore bruschi. --Vale93b Fatti sentire! 13:49, 3 apr 2013 (CEST)
Favorevole. Ma fatemi capire: il problema era solo quella gif stroboscopica o anche un testo lampeggiante come questo dà problemi? Nel senso, l'esempio fornito è quello di una gif animata decisamente lontana dalle caratteristiche di un comune testo lampeggiante... --Dry Martini confidati col barista 15:11, 3 apr 2013 (CEST)
sinceramente la puntualizzazione di Dry Martini "non mi cale": un testo così lampeggiante non mi infastidisce. Tuttavia, se fosse abolito "tout court" non mi opporrei, anzi. --Vale93b Fatti sentire! 18:57, 3 apr 2013 (CEST)

[ Rientro] Confesso che l'ho chiesto più a beneficio d'archivio che per emendare la proposta di Aplasia :) Del resto, se questa riguardasse solo l'eccesso di lampeggìo e non il semplice testo lampeggiante in sé, assumerebbe proporzioni ben più modeste, anche come lavoro di adeguamento. --Dry Martini confidati col barista 19:11, 3 apr 2013 (CEST)

sbaglio o il tag html blink può essere integrato con comandi per modulare il lampeggìo? --Vale93b Fatti sentire! 19:26, 3 apr 2013 (CEST)
Stando a en.wiki no, la frequenza è fissa e, per esempio, è fuori dal range di frequenze sconsigliate negli Stati Uniti per i testi lampeggianti nelle pagine Web: provate a cercare 2 Hz nella voce di en.wiki; non che questo cambi nulla, ma conferma il mio dubbio. Il che, ancora una volta, non cambia nulla :) --Dry Martini confidati col barista 19:36, 3 apr 2013 (CEST)
Symbol support vote.svg Favorevole, con eccezioni laddove richieste nelle voci del namespace principale e comunque vietare quel lampeggiamento troppo veloce; sarebbe, inoltre, bene non usare immagini scorrevoli del genere nelle pagine utente, perché potrebbero coprire altro testo presente nelle stesse. --Gce (msg) 22:00, 3 apr 2013 (CEST)
Symbol support vote.svg Favorevole a vietare l'uso del testo lampeggiante o con effetti ad intermittenza, oltre che a rendere condivisa la pagina Wikipedia:Accessibilità del contenuto. -- Gi87 (msg) 08:51, 4 apr 2013 (CEST)
Symbol support vote.svg Favorevole a vietare l'uso del testo lampeggiante. Si comincia con il il testo lampeggiante, si prosegue con MacromediaFlash e infine si arriva alla pubblicità. Personalmente preferirei ci si fermasse prima. -- Utente:Livioenrico (msg) 16:52, 07 apr 2013 (CET)

Festival della qualità: voci non editate da più tempo[modifica wikitesto]

Vi informiamo che è in corso un Festival della qualità. Gli utenti che frequentano il progetto Accessibilità e chiunque lo desideri sono invitati a parteciparvi e a dare una mano.
Quanto dura: dal 22 maggio al 30 giugno 2013
Cosa c'è da fare?: Questo festival ha come argomento le voci non editate da più tempo
Chi può partecipare?: Chiunque ne abbia voglia.
Si ringrazia dell'attenzione e della collaborazione. Partecipate numerosi e ... con qualità!


Semplificazione dei progetti di servizio[modifica wikitesto]

Segnalo. --pequod ..Ħƕ 10:35, 27 mag 2013 (CEST)

Avviso FdQ[modifica wikitesto]

Vi informiamo che è in corso un Festival della qualità. Gli utenti che frequentano il progetto Accessibilità e chiunque lo desideri sono invitati a parteciparvi e a dare una mano.
Quanto dura: dal 7 luglio al 31 luglio 2013
Cosa c'è da fare?: Questo festival ha come argomento la rimozione dei template S inutili.
Chi può partecipare?: Chiunque ne abbia voglia.
Si ringrazia dell'attenzione e della collaborazione. Partecipate numerosi e ... con qualità!

Messaggio automatico generato da Botcrux (discussioni · contributi)

Proposta di accorpamento di tre progetti di servizio[modifica wikitesto]

Come già accennato qui, credo possa essere utile accorpare i seguenti tre progetti nell'unico titolo "Accessibilità":

Il primo dice di occuparsi di disabilità degli utenti ai fini della fruibilità dei contenuti (quindi, credo, soprattutto scelta dei colori per ipovedenti).

Il secondo è dedicato al "nuovo" (ormai vecchio) Vector.

Il terzo si spiega da sé.

In qualche modo, un unico "progetto:accessibilità" si occuperebbe di alleggerire il progetto:accoglienza, cioè di rendere le pagine di aiuto quanto più chiare e asciutte possibile. Connesso a questa funzione di base c'è l'aspetto legato all'interfaccia (migliorare l'accessibilità dei testi per gli ipovedenti, connessione con il Progetto:Wikipedia parlata, barre di scorrimento, dimensioni dei pulsanti, forma degli avvisi, uso di metafore iconiche non linguisticamente connotate, un link semplice per segnalare errori in home page o altrove etc.). Dato che Vector è penso uno standard comune a tutti o cmq la skin di riferimento, penso non sia un male se diamo un'asciugata ai progetti di servizio, accorpando funzioni. Del resto, il secondo e il terzo sembrano abbastanza al palo. --pequod ..Ħƕ 21:11, 18 lug 2013 (CEST)

Non so a dire il vero come venga seguito il progetto specifico e cosa persegua, ma l'accessibilità è qualcosa di molto specifico che non ha niente a che fare con l'accoglienza (pagine d'aiuto) e ha a che fare in modo complementare con l'usabilità. Dovrebbe occuparsi di valutare la rispondenza del sistema alle esigenze di soggetti che utilizzano tecnologie assistive per accedere a Wikipedia o che siano, con un qualsiasi grado, affetti da disturbi che rendano difficile l'approccio al sito (ipovedenti, ciechi, amputati, tetraplegici, affetti da disturbi cognitivi, ecc.). Quindi, sì certo, uso dei colori, ma soprattutto struttura, uso del codice, scorciatoie veloci, testi alternativi, sistemi di interazione, gestione immagini, form, e così via. Va detto che già dalla home page di it.wiki si notano vari problemi a questo proposito (basta provare a navigare la pagina disattivando i fogli di stile per vedere che succede), cosa che invece su en.wiki non si verifica. Potrebbe probabilmente essere accorpato col progetto usabilità, che dovrebbe affrontare l'approccio da un punto di vista più ampio, facilitando l'utilizzo del sito per qualsiasi fascia di utenti (agendo, per esempio, sulla GUI) e promuovendo iniziative pratiche per ottenere questo scopo (ci sono precise direttive ISO in proposito). Visto che nessuno dei due progetti può agire attivamente sul software mediawiki, l'unico "potere" che hanno è nello studiare linee guida per il rispetto dell'accessibilità e (poche) soluzioni tecniche con ciò che è implementabile localmente per l'usabilità. L'accoglienza è, invece, qualcosa di completamente distinto. Questo almeno da un punto di vista scientifico e tecnico. Poi non so bene come i progetti si muovano nel concreto :) Il problema è che per far le cose bene ci vorrebbero esperti con tempo a disposizione, e le due cose raramente vanno d'accordo. :) --Lucas 23:56, 18 lug 2013 (CEST)
Dando un'occhiata devo dire però che in effetti tutti i progetti sembrano abbastanza morti e forse sarebbe meglio valutare o una chiusura in attesa di tempi migliori o una qualche forma di accorpamento (almeno i primi due e quello su wikipedia parlata si possono tranquillamente unire e sono favorevole)... --Lucas 00:01, 19 lug 2013 (CEST)
confl. Sì, ho menzionato l'accoglienza perché quel progetto si mette in moto ogniqualvolta le nostre pagine di aiuto falliscono nell'offrire esse stesse una comunicazione semplice e attraente. Anche se, si sa, avere un tutor è un po' più attraente (non per forza tramite il progetto specifico). Parallelamente, sto pensando alla accessibilità in termini generali: sia quindi con riferimento agli ipovedenti, mettiamo, sia con riferimento alle barriere informatiche banali (come la leggibilità del font scelto). Il sito www.webaccessibile.org dichiara di non riferirsi solo a utenti che necessitino assistenze specifiche rispetto a problemi invalidanti, ma anche a quei siti che creano essi stessi barriere e che limitano la loro fruibilità, anche di fronte all'utente "normodotato". Data la povertà di contributi verso questi aspetti, pensavo che asciugare potesse andar bene, anche se mi rendo conto che sto mettendo insieme cose che potrebbero viaggiare bene ciascuna per conto proprio. Potremmo chiedere al curatore di webaccessibile di iscriversi a wp e di darci da utente dei consigli su come delineare il sito. --pequod ..Ħƕ 00:08, 19 lug 2013 (CEST)
Sì infatti, come scrivevo l'accessibilità riguarda chiunqua abbia un qualche tipo di disturbo che contrasti con la sua fruizione del dispositivo (tra parentesi elencavo quelli più evidenti, ma anche un soggetto generalmente definito "normodotato" può averne; ivi inclusi quelli cognitivi, comportamentali, se vogliamo anche culturali - ma quest'ultimo aspetto riguarda più l'usabilità e in parte andiamo nel filosofico). Il vero problema è che si farebbe molto prima a lavorare a stretto contatto con gli sviluppatori di mediawiki. Il software, ad essere onesti, non è mai stato molto accessibile (specie nella sua parte inerente all'edit, riguardo all'impaginazione la qualità è discretamente buona), anche se mi risulta che ci sia stata più di una iniziativa valida su en.wiki e wikimedia a tal proposito (ma poi non ho seguito per mancanza di tempo :-( ).
Un esempio di cosa concreta che un progetto locale può fare non potendo agire sul software sono linee di questo genere:
Vietato scrivere frasi come o usare elementi come:
  • "La foto qui a destra": frase completamente senza senso per chi legge senza vedere le immagini, usare indicazioni differenti o descrivere direttamente senza ricorrere a riferimenti.
  • "Il colore rosso indica": frase altrettanto senza senso per un daltonico, indicarlo casomai come "il terzo elemento", o in altro modo non equivoco.
  • "Clicca sul link in alto a sinistra", frase senza senso per chi visualizza la pagina senza CSS, la posizione non è rilevante, è un aspetto grafico, usare altro modo per identificarlo come "clicca su Ascolta il file audio a inizio pagina"
  • Testi alternativi automatici per le immagini, semanticamente assurdi (wiki ne è piena)
  • Link che non hanno senso concreto a sé stanti: tipo "per approfondire clicca qui" è totalmente deprecato, specie per chi usa il TAB per navigare, e andrebbe sostituito con qualcosa tipo "per approfondire vedi la pagina di approndimento sulla lina guida X".
  • Box, template ed altri elementi che si spandono nella pagina perdendo il loro senso e creano confusione, in mancanza dell'impaginazione grafica.
  • Difficoltà di capire "dove si è", e come fare una cosa (template inclusi, pulsanti di modifica che modificano altre parti, pagine di discussione divise, ecc.)
  • ecc. ecc. ecc.
Considera che molte di queste cose faciliterebbero la vita anche solo alla navigazione via cellulare a persone normalissime.
Il problema è che la vedo durissima applicare cose del genere in un sistema aperto come quello di Wikipedia (e in parte obsoleto tecnicamente). Per questo dopo qualche tentativo solitario rinunciai tanti anni addietro. :) L'accorpamento dei tre progetti che dicevo sopra comunque mi pare un'ottima proposta, visto lo stato comatoso nel quale versano. :) --Lucas 00:47, 19 lug 2013 (CEST)
mmmh, Usabilità è stato dedicato al Vector, e per come si legge anche in via esclusiva, e così ci scrivono i messaggi gli emigrati grati (e graditi) :-) Gli altri due non si sa se producono qualcosa di più, ma tutti e tre servirebbe funzionassero ciascuno per le proprie competenze, servirebbe molto. Il progetto cumulativo non so come potrebbe collegare i tre campi di (in)azione, ma pur di uscire dallo stallo complessivo proviamolo... Ma ho difficoltà ad immaginare un topic comune, anche solo di pagina iniziale, che non appaia troppo eterogeneo. Se questo, tuttavia, serve ad imporre standard di edizione compatibili con quanto necessario per gli ipovedenti, quanto necessario per tutti in termini di usabilità per tutte le piattaforme e per tutte le applicazioni, e se riesce a metter mano agli aiuti (delle tre la cosa più distante, a mio avviso, rispetto alle altre), ben venga :-)
Una nota sul software: nel tempo è divenuto complesso, ma lo sono divenute anche le nostre pagine. Il fatto è che le sperimentazioni incontrano regolarmente resistenze di cui alcune di mera pigrizia, e quindi non si implementano molte cose che ci sono già. Inoltre il software di un megasito come questo deve innanzitutto essere "robusto", e meno male che questa filosofia resiste sennò saremmo in crash due volte l'ora, e "popolare", nel senso che il nostro lettore ideale è quello con il computer di terza mano, i più fortunati possono provvedere per loro conto. Dunque c'è da garantire, questa io vedo come urgenza permanente, voci "leggibili" da chiunque, purgando le velleità da webmaster creativo che si notano in molte voci, e questo è un primo importante punto di contatto fra Accessibilità e Usabilità. Questi due si potrebbero unire da subito. Il terzo non lo so come si possa armonizzare, ma credo che necessiti più di un arruolamento di una volenterosa sporca dozzina che si proponga una missione (suicida :-) immediata e inizi a sistemare; tanto non credo ci sia bisogno di nuove regole, son da applicare quelle che ci sono con un pizzico di buon senso, il resto sono maniche tirate su:-) -- g · ℵ (msg) 01:43, 19 lug 2013 (CEST)
Forse mi ripeto, ma per me il trait d'union è la parola accessibilità, che tira in ballo la doppia natura di wp: la puoi leggere e la puoi modificare.
Quindi accessibilità di wp significa sia poter fruire dei suoi contenuti, sia poterla modificare. La lettura comporta una serie di problemi, per utenti normodotati (continuo a usare questa espressione, tanto sono pochi i pazzi che si sentono a proprio agio con questo aggettivo) e invalidati. Modificare ha un'altra serie di problemi e le pagine di aiuto servono a minimizzare questi problemi, così come, per un altro verso, cerca di fare il prg:accoglienza. Ritengo quindi che ci sia una sufficiente omogeneità per accorpare. Non so poi se questo significherà una svolta, non credo, ma non penso ne deriverà un danno. Anzi, ritengo che si possa discutere con profitto in un luogo unificato. Peraltro, una volta controllata l'attualità delle pagine di progetto, si può meditare di avere tre pagine di progetto e una sola talk, nell'ambito del medesimo progetto. --pequod ..Ħƕ 02:40, 19 lug 2013 (CEST)

[ Rientro] faccio banalmente notare che il progetto Usabilità si è esaurito a gennaio 2011 e su commons tutti i riferimenti all'iniziativa sono migrati verso un generico "User experience". è strano che tra i programmi relativi alla UX non figuri il Visual Editor... --valepert 09:27, 19 lug 2013 (CEST)

VisualEditor[modifica wikitesto]

VisualEditor-logo.svg

Ciao a tutti! Entro la serata di lunedì 29 luglio, anche gli utenti non registrati potranno usare VisualEditor su it.wiki. Ecco alcune indicazioni utili:

  • Nella pagina Wikipedia:VisualEditor/Cosa cambia c'è un riassunto delle novità e, tra l'altro, anche la rassegna delle caratteristiche della nuova interfaccia preferite dagli utenti;
  • potrebbe essere necessario "aggiustare" alcuni edit, date dunque un'occhiata in più, in questi giorni, alle voci di pertinenza del vostro progetto;
  • per funzionare meglio, i template avranno bisogno di una leggera modifica, già apportata a numerosi template chiave; controllate dunque quelli relativi al vostro progetto - per i namespace principale e Utente - ed eventualmente, considerate di aggiornarli presto, magari usando uno degli strumenti già disponibili che fanno quasi tutto il lavoro al posto nostro.
Su Wikipedia:VisualEditor/Commenti potrete ricevere aiuto dalla comunità per eventuali problematiche. Questo messaggio vale anche come sincero ringraziamento per gli incredibili sforzi profusi sinora da decine di persone per rendere la transizione a VisualEditor più semplice per la comunità italofona. Grazie! --Elitre (WMF) (msg)


Messaggio automatico di Botcrux (discussioni · contributi)

FdQ Agosto 2013[modifica wikitesto]

Vi informiamo che è in corso un Festival della qualità. Gli utenti che frequentano il progetto Accessibilità e chiunque lo desideri sono invitati a parteciparvi e a dare una mano.
Quanto dura: tutto il mese di agosto 2013
Cosa c'è da fare?: Questo festival ha come argomento la riscrittura da zero delle voci con dubbio di violazione di copyright più vecchie
Chi può partecipare?: Chiunque ne abbia voglia.
Si ringrazia dell'attenzione e della collaborazione. Partecipate numerosi e ... con qualità!

Messaggio automatico generato da Botcrux (discussioni · contributi)

Avviso FdQ[modifica wikitesto]

Messaggio automatico generato da Botcrux (msg) 19:44, 10 ott 2013 (CEST)

FdQ novembre 2013[modifica wikitesto]

Messaggio automatico generato da Botcrux (discussioni · contributi)

FdQ - Dicembre 2013[modifica wikitesto]

Messaggio automatico generato da Botcrux (discussioni · contributi)

FdQ gennaio 2014[modifica wikitesto]

Messaggio automatico generato da Botcrux (discussioni · contributi)

Avviso FdQ - febbraio 2014[modifica wikitesto]

Messaggio automatico generato da Botcrux (discussioni · contributi)

Avviso FdQ[modifica wikitesto]

Messaggio automatico generato da Botcrux (discussioni · contributi)

Avviso FdQ - Aprile 2014[modifica wikitesto]

Messaggio automatico generato da Botcrux (discussioni · contributi)

Avviso FdQ - Maggio 2014[modifica wikitesto]

Messaggio automatico generato da Botcrux (discussioni · contributi)

Avviso FdQ - giugno 2014[modifica wikitesto]

Messaggio automatico generato da Botcrux (discussioni · contributi)

FdQ del prossimo trimestre: a voi la scelta![modifica wikitesto]

Messaggio automatico generato da Botcrux (discussioni · contributi)

Avviso FdQ - Luglio 2014[modifica wikitesto]

Messaggio automatico generato da Botcrux (discussioni · contributi)

Avviso FdQ Agosto 2014: immagini non usate[modifica wikitesto]

Messaggio automatico generato da Botcrux (discussioni · contributi)

Avviso FdQ - settembre 2014[modifica wikitesto]

Messaggio automatico generato da Botcrux (discussioni · contributi)

Pagine troppo lunghe per le versioni mobile[modifica wikitesto]

C'è ancora qualcuno in questo progetto? Volevo un parere su una proposta concreta che ho fatto in Discussione:Catalogo della National Gallery e che potrebbe valere in generale per pagine con elenchi troppo grandi. La visualizzazione di queste pagine è problematica su alcuni modelli di cellulare anche moderni. Ci sono già tanti elenchi lunghi spezzati in sottoelenchi (ad esempio Lista di asteroidi).--Vespiacic (msg) 08:30, 30 gen 2015 (CET)

Corsivo e parentesi[modifica wikitesto]

Segnalo Discussioni_aiuto:Corsivo#Corsivo_e_parentesi--Alexmar983 (msg) 15:21, 3 feb 2015 (CET)

Uso del tmp References[modifica wikitesto]

Il tmp {{references}} in presenza di poche note dà notoriamente risultati altamente indesiderabili. Esempio, ma c'è anche di peggio.

Vogliamo fare qualcosa? pequod76talk 18:28, 15 feb 2015 (CET)

Be', nel tuo esempio penso che la cosa migliore sarebbe inserire il {{Treccani}}. In ogni caso, non si potrebbe modificare il template in modo da impedirgli di spezzare una stessa nota su più colonne? --Epìdosis 18:40, 15 feb 2015 (CET)
A parte il tmp treccani, che non risolve il topic, la questione è non solo non spezzare una stessa nota in due colonne, ma anche non avere due colonne per appena due note... pequod76talk 18:43, 15 feb 2015 (CET)
Guardando il template equivalente su enwiki vedo che è possibile impedire alla stessa nota di spezzarsi in più colonne. Invece sembra che il template non possa riconoscere da solo il numero di note presenti, quindi per come è fatto adesso bisognerebbe evitare di usarlo in tali casi. L'altra possibilità è ovviamente rendere opzionale la divisione in colonne e prevederne di default una sola. --Incola (posta) 19:00, 15 feb 2015 (CET)
Confermo che il problema lo riscontro da tempo e che quando ho poche note utilizzo il comando <references/> mentre quando ne ho molte passo al {{references}} con l'esplicitazione del parametro del numero di colonne (in genere due). --Leo P. - Playball!. 19:11, 15 feb 2015 (CET)
Io faccio sempre come Leo. pequod76talk 19:22, 15 feb 2015 (CET)
[× Conflitto di modifiche] Veramente avevamo già quagliato in questa discussione. Si era stabilito di non usare il template fino ad una ragionevole quantità di note (in base a WP:BS) ed erano state fatte due richieste agli amministratori (1 e 2) per chiedere una modifica al template mai arrivata poiché probabilmente non fattibile. Se qualcuno è capace di modificare il template secondo richieste lo faccia, per favore, altrimenti ci dica almeno perché non è fattibile, grazie. --Umberto NURS (msg) 19:23, 15 feb 2015 (CET)
P.S. Vorrei anche ricordarvi che il man del {{references}} recita: "Va utilizzato solo quando è davvero necessario, ovvero quando la sezione note è eccessivamente lunga a causa del numero elevato di note brevi.". --Umberto NURS (msg) 19:28, 15 feb 2015 (CET)
Forse ci vuole una passata di bot, perché situazioni "due colonne-due righe" le trovo *spessissimo*.
Ipotesi di soluzione: un bot rileva quante volte è usato "<ref>" in una voce. Meno di... enne? Sostituisce il tmp con il normale <references/>. Non so se sia possibile... Oppure evitiamo che {{references}} corrisponda a {{references|auto}} e facciamo sì che corrisponda a {{references|1}}. Non so se questa seconda abbia senso... pequod76talk 19:58, 15 feb 2015 (CET)
Se intanto si potesse fare una passata di bot meglio; si potrebbe intervenire almeno nei casi con meno di 5 note (ma farei anche 10), visto che altrimenti si rischia di vederle "spaccate" in 2/3/4 colonne, a seconda della risoluzione e del browser. Facciamo una richiesta? --Umberto NURS (msg) 20:05, 15 feb 2015 (CET)

IMHO basta usare il buon senso e non metterlo (come già previsto e richiamato nella discussione sopra) quando ci sono poche note. Quando ce ne sono molte è meglio lasciarlo in auto perchè su monitor molto larghi possa anche dividersi in tre (o più colonne) mentre su quelli più piccoli si divide in due (o anche una sola colonna). Forzarlo a un numero fisso di colonne è sbagliato perchè impedisce questo adattamento. @Incola da quello che dice il manuale di Reflist si impedisce di spezzare una nota su più colonne modificando il MediaWiki:Common.css non il template.--Moroboshi scrivimi 21:34, 15 feb 2015 (CET)

Infatti nella precedente discussione che ho linkato si optava per un numero massimo di colonne (si convergeva su tre) e non di fissare il numero preciso, anche perché se poi uno legge da smartphone è antipatico vedere le cose su (per esempio) due o tre colonne fisse. --Umberto NURS (msg) 22:25, 15 feb 2015 (CET)
Favorevole al bot proposto.
Il numeretto manuale mi chiedo se non sarebbe il caso di abolirlo del tutto; o almeno abolirlo nella versione mobile, se è possibile farlo con il CSS --Bultro (m) 23:26, 15 feb 2015 (CET)
@Umberto, mi riferisco a quanto hanno scritto Leo e Pequod76 che dicono che inseriscono esplicitamente il numero di colonne (2) invece di lasciare all'automatismo del template.--Moroboshi scrivimi 06:07, 16 feb 2015 (CET)
Ah ok, Moroboshi, ho capito. Grazie. Allora, anche tenendo conto del tema smartphone, non è forse il caso di togliere proprio la possibilità di indicare il numeretto? Non solo per versione mobile, ma in generale... È vero che basterebbe il buonsenso, ma allora non mi spiego com'è che sia così poco diffuso 'sto buonsenso. :D Davvero, mi imbatto in tantissimi casi "una nota" spezzata in due colonne: fastidio! :) pequod76talk 08:18, 16 feb 2015 (CET)
Per me nessun problema a "non mettere" il parametro fisso. Però togliamolo dalle possibilità perché come è diventata mia inconsapevole abitudine, così potrebbe diventarla per altri. --Leo P. - Playball!. 08:55, 16 feb 2015 (CET)
@Pequod76, ho l'impressione che stiamo mischiando due problemi diversi (anche se simili): in modalità automatica il template fissa la larghezza delle colonne a 30 em e quindi vengono messe tante colonne quante ce ne stanno nello schermo usato dal lettore; se una nota è a fondo fondo alla colonna potrebbe finire spezzata a metà tra una colonna e l'altra (e questo problema almeno stando al manuale di en.wiki lo si potrebbe risolvere - ma personalmente non mi fido a mettere mani nel common.css - non sono molto esperto di css e non vorrei causare problemi per non aver considerato qualche effetto collaterale). Il secondo problema è quello di poche note presenti in voce che finiscono distribuite su più colonne e questo è risolvibile nelle voci con poche note solo fissando a 1 il numero di colonne )oppure limitandosi a usare l'istruzione <References /> senza usare del tutto il template) e usare il template solo nelle voci con molte note. --Moroboshi scrivimi 10:21, 16 feb 2015 (CET)
Direi che diversi problemi necessitano di diverse soluzioni. Per evitare che se ci sono poche note si creino più colonne bisogna rimuovere il template con un bot (come indicato nel manuale del template perché si tratta di un uso scorretto). Si può modificare il css per evitare che la stessa nota si spezzi in più colonne come hanno fatto su enwiki. Si può modificare il template evitando di poter specificare a mano il numero di colonne, perché anche se ci sono tante note non vogliamo creare un numero fisso di colonne su un dispositivo con uno schermo piccolo. Rimane da capire come affrontare la questione delle troppe colonne su schermi molto grandi, ma probabilmente col passaggio del bot e la modifica del css si mitiga di molto il problema. --Incola (posta) 11:47, 16 feb 2015 (CET)
Comunque, su IE8 le 2 colonne non funzionano, e a mia memoria non hanno mai funzionato, né con l'una né con l'altra soluzione... char_aznable 12:04, 16 feb 2015 (CET)
Con quale risoluzione? --Umberto NURS (msg) 12:09, 16 feb 2015 (CET)
[@ Umberto NURS] 1024 x 768 su questo al lavoro e 1280 x 1024 sul mio PC a casa, entrambi con XP SP3 a 32bit (Pro e Home). Parecchio tempo fa, mi ero infatti chiesto a cosa mai servisse quel "|2". Poi, sul mio notebook con Win7 ovviamente funzionano sia con IE11 che con firefox. Ho da tempo rinunciato a segnalare i problemi del SW mediawiki con IE8, visto che poi non vengono comunque risolti. char_aznable 13:06, 16 feb 2015 (CET)

[ Rientro] A suo tempo (non me lo ricordavo...) io avevo contribuito alla modifica del template aggiungendo il multicolonna, ma avevo preferito (anche proprio per evitare il problema di cui stiamo trattando) che tale modalità dovesse essere indicata esplicitamente (parametro "auto"). In seguito il default del template è stato modificato in funzione del multicolonna automatico, per annullare il quale adesso occorre utilizzare {{References|1}} oppure <references />. Una delle soluzioni da adottare quindi, oltre al bot, potrebbe essere quella di disattivare il comportamento multicolonna di default, che andrebbe quindi evocato esplicitamente e (si spera) a ragion veduta. --Lepido (msg) 13:59, 16 feb 2015 (CET)

Molto bene, fin qui vi ho seguiti. L'ultimo passaggio non l'ho ben chiaro: viste le diverse caratteristiche di browser e/o apparati di visualizzazione cui prestare attenzione, quali sono le occasioni in cui si può prestabilire a ragion veduta il numero delle colonne delle note? --Leo P. - Playball!. 17:03, 16 feb 2015 (CET)
Mi riferivo alla discussione. In pratica il problema nasce con voci con "poche" note. Cosa significhi "poche" ovviamente è opinabile, ma penso che siamo tutti d'accordo che 2 o 3 note siano "poche". In realtà il problema non è esattamente il numero di note, ma la lunghezza del testo delle note stesse, ma qui sto un po' semplificando, perché altrimenti non si finisce più :-) Comunque in presenza di poco testo, l'effetto multicolonna ha una resa deleteria, tipograficamente parlando. Anzi, dirò di più. Nel dubbio sarebbe meglio lasciare il testo delle note su di una colonna piuttosto che arrischiarsi a metterlo su più colonne in presenza di poche note. Ecco perché proponevo di cambiare il comportamento di default del template. Se metto il template {{References}}, senza specificare altro, sarebbe forse meglio che il testo restasse su di una colonna (cosa che danni non fa...). Solo scrivendo esplicitamente {{References|auto}} il testo si porrebbe su più colonne. L'adozione del multicolonna verrebbe quindi fatta "a ragion veduta" (cioè si spera sapendo esattamente quello che si sta facendo) e non in maniera automatica. Ovviamente il processo "a ragion veduta" è fallibile, ma se non altro non sarebbe un cieco automatismo. --Lepido (msg) 18:39, 16 feb 2015 (CET)
Beh scegliere tra usare {{References}} e <References /> non mi pare che sia un cieco automatimo, d'altra parte sarebbe più omogeneo chiamare sempre il template e decidere con un parametro. Fate vobis.--Moroboshi scrivimi 20:20, 16 feb 2015 (CET)
In Template:References/man leggo che (attulmente) c'è precisato "Va utilizzato solo quando è davvero necessario, ovvero quando la sezione note è eccessivamente lunga a causa del numero elevato di note brevi." --109.53.233.233 (msg) 21:53, 16 feb 2015 (CET)

Uso improprio dei colori in alcune tabelle[modifica wikitesto]

Segnalo, problemi di accessibilità e usabilità. --ArtAttack (msg) 09:52, 7 mar 2015 (CET)

Wikipedia per non vedenti -ipovedenti[modifica wikitesto]

A gennaio al Bar avevo sollevato il problema di permettere ai non vedenti/ipovedenti l'accesso ai vari progetti Wikimedia. La prima nuova iniziativa è per gli .epub di Wikisource. Martedì 24 alla biblioteca Valvassori Peroni, al primo piano si inizia a caricare su un computer dell'Associazione Nazionale Subvedenti alcuni .epub dove l'associazione inizierà a fare dei test. Se qualcuno gravita su Milano, può venire liberamente: per gli altri è graditissimo ogni consiglio. Per gli ipovedenti si proverà a vedere fino a quanto si possono ingrandire i caratteri permettendo ancora una lettura relativamente facile. Per i non vedenti bisogna contare sulla sintesi vocale, ovviamente anch'essa da testare.

Per quello che riguarda Wikipedia, mi sembra, che la maggiore esperienza è stata quella di Winguido, che hanno in passato anche tentato di contattarci Si può vedere se questa volta si riesce a fare un cammino comune. So poi che Ubuntu ha buona esperienza per i non vedenti, ma non so se si sono occupati in particolare di Wikipedia; Nel frattempo è uscita la versione 3.1 di ViVo Next che è free Annuncio sul blog del Majorana di Gela

vedi anche Discussioni_progetto:Wikipedia_parlata#il_progetto_fermo--Mizar (ζ Ursae Maioris) (msg) 09:53, 17 mar 2015 (CET)

Uso di template nel testo[modifica wikitesto]

Mi chiedevo quanto vada d'accordo con l'accessibilità (e con molte altre cose tra cui il buon senso) l'utilizzo nell'ambito del testo di template i quali rendono un altro testo, che si potrebbe invece perfettamente scrivere col caro vecchio wikicodice fatto di alfabeto latino, |, [ e ]. L'esempio che porto è la voce Fabio Semenzato in cui si legge in modifica «affrontando il [[12 febbraio]] l'{{RU|ENG}}»; si fa troppa fatica a scrivere invece «affrontando il [[12 febbraio]] l'[[Nazionale di rugby a 15 dell'Inghilterra|Inghilterra]]»? Tale uso di un template mi pare fortemente anomalo, e non riesco a fare a meno di metterlo in relazione a una certa deriva che nella struttura e composizione delle voci i progetti sportivi hanno troppo a lungo tollerato, e i non-sportivi non hanno combattuto abbastanza (il proliferare di bandierine è un altro aspetto del problema). Presso il progetto storia medievale ho la ferma intenzione, quindi, di proporre di creare il template {{RGN}} in maniera da evitare di scrivere ogni volta [[Regno d'Inghilterra|Inghilterra]], [[Regno di Castiglia e León|Castiglia]] eccetera >-). --AttoRenato le poilu 17:20, 19 apr 2015 (CEST)

Concordo sul fatto che sia un uso improprio. Se fosse previsto un bot che passi periodicamente a substarlo avrebbe ancora ancora un minimo di senso, ma per il resto concordo con quanto scritto.--Moroboshi scrivimi 17:52, 19 apr 2015 (CEST)
Un altro esempio è il template {{WC}}, usato per le edizioni dei mondiali di calcio. Ritengo anche quello un template inutile.--Mauro Tozzi (msg) 21:29, 19 apr 2015 (CEST)
concordo anch'io. --Superchilum(scrivimi) 22:48, 19 apr 2015 (CEST)
+1. Tra l'altro le bandierine le sostituirei ovunque con ad esempio IT Testo, anche se in questo caso andrebbero proprio rimosse.--Sakretsu (炸裂) 16:07, 20 apr 2015 (CEST)

Per quanto riguarda il template {{RU}} che ha dato il via al discorso in realtà si dovrebbe substare il {{NazNB}} da questo richiamato e che viene usato per creare wikilink alle nazionali sportive di diverse attività sportive.--Moroboshi scrivimi 14:09, 23 apr 2015 (CEST)

[@ Moroboshi] Col risultato di...? abbi pazienza ma non ho MAI capito che cavolo fosse sto subst che vedo richiedere ai bot - e anche dopo che ne ho letto su en.wiki non l'ho capito lo stesso... :DDD --AttoRenato le poilu 21:18, 23 apr 2015 (CEST)
leggilo su itwiki! --ppong (msg) 21:28, 23 apr 2015 (CEST)
[× Conflitto di modifiche] La differenza è che, pur inserendo nel codice il template, in realtà ne salvi solo il risultato: in Utente:Sakretsu/Sandbox/4 ho appena salvato {{subst:Benvenuto}}, eppure se editi la voce vedi che essa contiene il messaggio, non il template.--Sakretsu (炸裂) 21:36, 23 apr 2015 (CEST)
Grazie a entrambi, ora so a che serve il subst, mi manca solo di comprenderne l'utilità in questo caso #) In altri termini: IMO sarebbe meglio in questo caso eliminare il template (via bot se possibile) e sostituirlo col normale wikitesto, non comprendo l'utilità del passaggio a substare... --AttoRenato le poilu 22:12, 23 apr 2015 (CEST)
In pratica gli utenti abituati ad usare il template, potranno continuare ad inserirlo nelle voci senza lasciare scritto ad esempio {{RU|ENG}}, bensì [[Nazionale di rugby a 15 dell'Inghilterra|Inghilterra]]. In questo modo non si verrà ad intaccare l'accessibilità, dato che anche gli utenti "alle prime armi" si ritroveranno scritti nel testo i normal wikilink.--Sakretsu (炸裂) 22:29, 23 apr 2015 (CEST)
Ahhhh, adesso è più chiaro, quindi sarebbe la soluzione che salva caprinae & brassicaceae! Lascio dunque a chi ne sa l'onere di attuare la proposta fatta più sopra da Moroboshi. Grazie! ^^ --AttoRenato le poilu 22:36, 23 apr 2015 (CEST)

[ Rientro] Noto anche l'esistenza del template {{nave}} su cui si debbono fare le medesime considerazioni e modifiche. --AttoRenato le poilu 06:01, 29 apr 2015 (CEST)

già. c'è consenso quindi direi di quagliare. aggiorniamo i template indicando di substarli e passiamo via bot? --ppong (msg) 11:15, 29 apr 2015 (CEST)
+1 ovviamente da parte mia. --AttoRenato le poilu 08:54, 1 mag 2015 (CEST)
ci sto provando ma è un gran macello, il nazNB ha un monte di template annidiati e va messo il safesubst anche a loro e a tutte le parser. alcune pagine poi sono protette. [@ bultro]. --ppong (msg) 11:39, 1 mag 2015 (CEST)
notizia sciagurata: non mi riesce di far funzionare il safesubst sugli invoke, quindi mi pare che il template nave non possa essere substato in nessuna maniera. l'unica possibilità sarebbe quella di creare un template gemello che utilizzi i subst (e non i safesubst) e sostituire le occorrenze di {{nave}} con {{subst:nave1}}. al che rimpiazzare il vecchio template con quello nuovo. la questione del naznb resta più complessa. --ppong (msg) 11:48, 1 mag 2015 (CEST)
Segnalo anche {{RWC}}. Nulla di nuovo sul fronte tennico? Templatologi dove siete? :/ --AttoRenato le poilu 10:43, 11 mag 2015 (CEST)

Visto che si parla di rugby chiederei a [@ Blackcat].--151.67.198.144 (msg) 00:17, 13 mag 2015 (CEST)

Lo spiego subito.
  1. Sono termini ricorrentissimi, e ogni volta wikilinkare si diventa matti
  2. Metti caso cambia il nome della competizione basta cambiare il nome nel template e ti eviti una marea di redirect.
-- SERGIO (aka the Blackcat) 02:57, 13 mag 2015 (CEST)
La ratio d'uso era chiara (almeno il primo punto; il secondo non sono sicuro sia corretto, in quanto se ho ben capito il sistema e se si fosse usato tale sistema per il calcio, vado estremizzando, leggeremmo di Helenio Herrera che nel '63 vinse una Uefa Champions League, non una Coppa dei Campioni, ma i redirect per evitare tale effetto sono proprio quel che ci vuole), e altri ambiti di interesse possono reclamare le medesime esigenze; però concorderai che non è proprio un uso normale per un template. Se si potessero substare non ci sarebbero problemi (l'ho imparato poche righe sopra ^^). Si possono substare? --AttoRenato le poilu 09:00, 13 mag 2015 (CEST)
Io già uso template "Substabili" come {{All blacks}}, {{Springbok}} e {{Wallabies}}, il fatto è che RU si appoggia su {{Naz}}, è possibile? Non ne faccio una guerra di religione, solo di evitare i redirect. Non so se sul server pesi più un template o più un redirect (dal momento che comunque le voci di sportivi già di loro sono piene di template). -- SERGIO (aka the Blackcat) 19:46, 13 mag 2015 (CEST)
[@ Blackcat] Non sono tennico ma umanistico (come direbbe forse l'attuale premier) per cui faccio più attenzione ai testi che alle formule: la mia segnalazione nasce dal fatto che a me pare anomalo - e non sono il solo - un uso all'interno del testo per rendere altro testo di template come quelli che ho scovato. Sul piano del carico ai server ho sempre sentito dire che pesano più i template, ma non è questo ad avere importanza dato che vale la regola di non curarsi delle prestazioni se una modifica è utile. Sul piano della leggibilità del wikicodice (e credo che moltissimi ancora lo leggano) i template usati in quel modo sono un disastro, difficile negarlo. Da cui la proposta di substare. Riformulo quindi la domanda da (im)perfetto profano: NON si possono substare i template che ho citato e che in parte sono opera tua? Hai suggerimenti tecnici per modificarli o per sostituirli? Grazie. --AttoRenato le poilu 10:47, 16 mag 2015 (CEST)
Renato, qui ci vorrebbe Bultro, la massima autorità vivente sui ténpleit. Per quanto riguarda quelli non parametrizzati posso dirti io subito un sonante "Sì", perché li substo regolarmente. Per quelli che richiedono un parametro a valorizzazione non ho una risposta. -- SERGIO (aka the Blackcat) 10:51, 16 mag 2015 (CEST)
RWC si può substare già adesso, non contiene parser. il modo migliore di procedere per quanto riguarda il naznb sarebbe di portarlo in lua, dato che si appoggia su una miriade di sottotemplate che potrebbero essere trasformati in un unico database. al che substarlo diverrebbe più semplice. però il safesubst non funziona per gli invoke quindi il subst diverebbe obbligatorio (altrimenti il tmp non funzionerebbe). --ppong (msg) 11:35, 16 mag 2015 (CEST)
segnalo discussione per rendere substabile il {{nave}}. (non capisco dove avevo visto un invoke, non ce n'è) --ppong (msg) 12:33, 16 mag 2015 (CEST)
Dato che è ancora ferma se volete preparo un bot per sostituire le ricorrenze correnti con i wikilink, però dato che [@ Rotpunkt] sta finalizzando la conversione dei vari template Bandiera ed affini in Lua potrebbe essere un lavoro inutile.--Moroboshi scrivimi 11:25, 30 mag 2015 (CEST)
proprio la conversione dei template naznb in lua ci viene in aiuto, gliel'ho chiesta apposta! diventeranno substabili e non servirà nessun bot sofisticato. piuttosto: il template nave se substato lascia entità html per gli spazi nelle voci, o si sostituisce con wlink tramite bot o si converte in lua pure quello. --ppong (msg) 12:36, 30 mag 2015 (CEST)

(rientro) Arrivo qui per il ping di Moroboshi e per una segnalazione per cui in questa discussione si sarebbe parlato di subst in relazione anche alle performance, ma che invece non risulta. Vorrei comunque chiarire un paio di punti:

  1. anche se qui non se n'è parlato, ma a scanso di equivoci, vorrei ribadire che il subst: non va *mai* usato per motivi di performance. Come è già scritto in en:Wikipedia:Substitution: << Substituting en masse may ultimately speed up the site, but this is not a reason to prefer substitution over transclusion. Don't worry about performance of Wikipedia's servers. >> citando en:Wikipedia:Don't worry about performance. Ci saranno casi rarissimi in cui per un template particolarissimo che impiega un tempo troppo lungo a espandersi possa valerne la pena, ma non me ne risultano, quando capiteranno li vedremo. Ho trovato anche questa discussione di quattro anni fa, dove i più tecnici dicevano già queste cose: come Ingala << Nella quasi totalità dei casi, qualunque azione fatta al solo fine di "ridurre il carico dei server" è una perdita di tempo. >> e Jalo << Lavoro a mio parere inutile >>. Quindi chiederei gentilmente a [@ Blackcat] di non fare mai più subst dei template {{fc}} {{conflittato}} {{rientro}}, unico utente a farlo, riempiendo così le discussioni da pochi caratteri a decine di righe.
  2. il subst va usato solo quando non si vuole che modifiche al template determinino cambiamenti nella pagina in cui era stato inserito, esempio il {{Benvenuto}} (si vuole che rimanga nella versione al momento del benvenuto), oppure perché al momento del subst verranno generati informazioni valide solo in quel momento come una data. Poi, per un uso non da utente, c'è poi quello preload.

Ora vi è anche un altro caso, di cui io sinceramente non ho mai usufruito, ossia come metodo per risparmiare tempo a scrivere del wikitesto. Allora abbiamo template come {{Ref}}, {{All blacks}} o {{British lions}}. Mi sembra un po' esagarato, ma se fa comodo a chi li usa nessun problema. Quello di cui non sono convinto è trasformare template che non sono nati come risparmio di tempo come {{NazNB}} in template per questo utilizzo. Col {{NazNB}} viene generato un wikilink, dipendente da quello che c'è in una sottopagina di Naz (in futuro con una table Lua). Substandolo al momento di una eventuale modifica alla configurazione i wikilink non cambieranno. Io sarei per definire qualche regola sul suo utilizzo, ma non per substarlo globalmente, né per dire che è un template che va sempre substato. --Rotpunkt (msg) 14:35, 30 mag 2015 (CEST)

Trovo anche {{OI}} (ma tutti io li trovo???). Non ci sono novità sul fronte tecnico? --AttoRenato le poilu 18:58, 25 giu 2015 (CEST)

Tool per daltonici[modifica wikitesto]

Segnalo meta:Grants:IEG/Color blindness content checker--Alexmar983 (msg) 21:37, 2 ott 2015 (CEST)

Template Nota[modifica wikitesto]

Segnalo Discussioni template:Nota#Valutazione dell'accessibilità. --5.170.10.93 (msg) 22:57, 26 gen 2016 (CET)

formule piccolissime rispetto al testo[modifica wikitesto]

cb La discussione proviene dalla pagina Wikipedia:VisualEditor/Commenti#formule piccolissime rispetto al testo.
– Il cambusiere fringio · 20:25, 24 nov 2016 (CET)

Salve, perché da alcuni giorni quando apro Wikipedia sul cellulare LG android con il browser explorer (mappamondo blu)il testo si vede normalmente mentre tutte le formule si vedono piccolissime? grazie Questo commento senza la firma utente è stato inserito da 2.38.1.132 (discussioni · contributi) .

Inattività del progetto[modifica wikitesto]

Visto che il progetto risulta inattivo, provvedo a censire gli utenti interessati--Ferdi2005 (Posta 14:16, 5 mar 2017 (CET)

Nuovo strumento[modifica wikitesto]

Segnalo la creazione di uno strumento per tentare la risoluzione dei vari problemi di accessibilità dovuti ai colori nei diff, volto inoltre alla ricerca di uno standard di colori adatto a tutti. Vi invito ad utilizzarlo e, quando sarà il momento, esprimere le vostre preferenze in un sondaggio.--Daimona Eaytoy (Scrivimi!) 11:54, 22 giu 2017 (CEST)

  • Letto, in corso di test e a seguire, impressioni. Grazie !--☼Windino☼ [Rec] 13:04, 22 giu 2017 (CEST)

Festival della qualità - Aprile 2019[modifica wikitesto]

Segnalo, data la grande attinenza all'argomento. --Torque (scrivimi!) 12:11, 1 apr 2019 (CEST)