Discussioni aiuto:Pagina di discussione

---

...da fare in Pagina di discussione aggiorna cache · modifica Annota in questo spazio le cose da fare per migliorare la voce o segui i suggerimenti già indicati.

Paragrafi ancora da sistemare archiviare cambusa talk voce, Fatto talk progetto talk utente altri spazi di discussione. Punti da tener presente In "archiviare le discussioni" inserire quanto discusso in "linea guida omogenea sulle archiviazioni". separare e semplificare le istruzioni per archiviare pagina utente e pagine del progetto o altre talk. integrare e sponsorizzare il più possibile Aiuto:Tour guidato. Ordine dei template di avviso raggruppare gli avvisi per categorie funzionali decidere l'ordine dei tmp di avviso armonizzare i diversi tmp tra di loro

Archivio

---

• Indentatura delle discussioni
• Nuova indentatura delle discussioni
• Archivio 2008-2009
• Archivio 2010-2012

---

come archiviare  ·  modifica questa lista

Esempio di paragrafo

Ben fatto! ora clicca qui per tornare alla pagina di aiuto e proseguire con la lettura!

Per uno standard consigliato di archiviazione

Con riferimento a questa sezione della pagina di aiuto.

Secondo me è il caso di consigliare con più precisione uno standard di archiviazione della pagine di discussione diverse da ns3 (vedi anche questo passato tentativo).

Innanzitutto:

• bisognerebbe sempre aprire un archivio sottopaginato, ad es.: discussioni aiuto:Pagina di discussione/Archivio, con utilizzo di {{archivio}} (in particolare i progetti dovrebbero evitare modi sperimentali di linkare ai propri archivi: uno standard garantisce riconoscibilità del luogo di archiviazione).
• il singolo archivio dovrebbe avere questa forma standard: discussioni aiuto:Pagina di discussione/Archivio/01 (notare la A maiuscola, il numero archivio con slash, lo 0 davanti all'1, che rende più "ergonomico" l'uso di AllPages.
• il modo dell'archiviazione dovrebbe essere sempre del tipo:
  • sposto la pagina di discussione al titolo del nuovo archivio, ad es.: discussioni progetto:Abruzzo --> discussioni progetto:Abruzzo/Archivio/01
  • copio dal nuovo archivio le discussioni ancora in corso
  • incollo le discussioni ancora in corso in "discussioni progetto:Abruzzo", che a seguito dello spostamento è diventato un redirect

In questo modo la cronologia viene spezzettata per ogni singola pagina, il che è imho più coerente e più coeso. Non solo: quando la cronologia si allunga troppo (Restu vi darà spero qualche dettaglio in più), si viene a creare la necessità di un intervento sysop.

Infine, la sezione "Archiviare le discussioni" richiamata all'inizio dà consigli proprio sul ns3 (talk utente), quando questo è lo spazio più personale. Sarebbe più congruo che la sezione desse indicazioni su come archiviare pagine più propriamente comunitarie (in particolare talk voci e talk progetto: quelle che si gonfiano di più nel tempo).

Non sto proponendo standard obbligatori, ma almeno diamo una traccia effettivamente valida. La soluzione classica del copincolla non è affatto particolarmente più semplice: l'unico presunto vantaggio è quello di tenere in un unico filone la crono, ma come detto questo non può valere per sempre e cmq comporta di avere la crono di mettiamo 1000 post quando poi questi 1000 post si trovano di fatto in pagine diverse. Che ne pensate? --pequod ^..Ħƕ 11:06, 27 nov 2012 (CET)

Però piano: se viene spostata una discussione non ancora conclusa poi bisogna riportarla nella pagina "principale" in modo che il confronto possa continuare. Il problema è che a quel punto la crono di quella sezione resta nella parte appena archiviata, mentre la sezione vera e propria verrà archiviata in un'altra sottopagina, complicando così il lavoro di confronto tramite la crono. Io non uso molto gli archivi (se non per la mia talk), quindi non mi cambia molto, ma credo sia meno macchinoso chiedere una decronizzazione in WP:RA che spostare tutto ogni volta per poi dover anche rimettere a posto le sezioni ancora aperte. Ripeto, non ho molta esperienza, ma a naso mi sembra un avvitamento. --Dry Martini confidati col barista 18:17, 27 nov 2012 (CET)

@Dry: diciamo che il problema si presenta anche a rovescio: se si fa solo il copia e incolla, nella crono dell'archivio ci sono solo i copia e incolla e si perde completamente la cronologia degli interventi, che rimangono sì in un'unica crono, ma che diventa impossibile da usare se le versioni salgono vertiginosamente (sfido chiunque a cercare un diff nelle crono con 10 mila o più edit :-D). Poi un altro problema è che, mentre uno spostamento possono farlo tutti gli utenti autoconfermati, per la decronizzazione serve un admin. Io ci vedo più avvitamenti nel chiedere agli admin di decronizzare ogni tot le pagine piuttosto che schiacciare il tasto sposta quando si decide di archiviare. :-) Restu²⁰ 18:24, 27 nov 2012 (CET)

A questo punto lascio fare a chi se ne intende: a me pareva che dover ri-spostare al posto giusto le discussioni non concluse fosse un po' un casino, ma se dite che è peggio decronizzare (che però va fatto molto meno spesso, credo) allora, come disse quel tale, obbedisco. --Dry Martini confidati col barista 18:29, 27 nov 2012 (CET)

Dipende un po' dai punti di vista: decronizzare viene sicuramente fatto meno spesso, ma richiede l'intervento di un sysop e, a mio avviso, è un passaggio meno automatico di un singolo utente che sposta la pagina e poi copia le discussioni aperte. Ovviamente, come dice pequod, la cosa migliore sarebbe consigliare questo sistema, piuttosto che obbligarlo, anche perché a mio avviso avrebbe poco senso obbligare gli utenti ad archiviare tutti quanti nello stesso modo; la cosa migliore è indicare nella pagina di Aiuto che c'è un metodo "che sarebbe meglio seguire" per certi motivi, ma se poi uno decide di fare taglia e incolla mica viene fucilato. :-) Restu²⁰ 18:34, 27 nov 2012 (CET)

Ok, allora vada per lo sposta e risposta, sembra anche a me la soluzione più indolore per chi consulta molto gli archivi. Naturalmente si tratterebbe di una procedura solo consigliata e limitata alle discussioni esterne al ns-User_talk: obbligare a uno standard sarebbe inutile, forse controproducente. Ritiro le obiezioni, per quanto mi riguarda nihil obstat. --Dry Martini confidati col barista 18:44, 27 nov 2012 (CET)

Esattamente, credo che una precisazione sul "consiglio" possa essere fatto in pagina senza mettere vincoli o obblighi. :-) Restu²⁰ 19:14, 27 nov 2012 (CET)

intervengo solo per dire che un diff nelle crono con 10 mila o più edit è facilmente trovabile risalendo alla data nella firma --Salvo da PALERMO 20:36, 27 nov 2012 (CET)

Possiamo almeno aggiungere questa postilla sul metodo consigliato? Mi sembra questo il punto centrale della discussione. :-) Restu²⁰ 21:12, 27 nov 2012 (CET)

Lette le varie osservazioni, mi sembra di capire che l'unico in grado di archiviare veramente bbuono sia un admin, perché può spostare con soppressione di redirect e ripristinare una parte della crono (sempre che la crono segua lo sviluppo cronologico delle sezioni, il che accade in genere ma non sempre). Sia come sia, mi limiterei a dare una sistemata alla pagina in questione, visto che si tratta di mostrare i due metodi e di consigliarne uno: di fatto, la sincronia tra crono e svolgimento della discussione salta solo "intorno" al momento dello spostamento. Mi viene quindi una considerazione: forse il sistema davvero migliore è quello per cui (almeno nei progetti, lì dove le talk sono più contrinuativamente attive) si discute direttamente in archivio (si apre cioè un archivio49, mettiamo, e si discute lì: quando da altrove si segnala un thread non esisterebbe più il problema di far saltare il link, cosa che avviene sia con lo spostamento, sia con il copincolla). Ma dubito che ci sia in questo momento la volontà di seguire questa strada. --pequod ^..Ħƕ 22:40, 27 nov 2012 (CET)

Piuttosto ditemi se almeno sui primi due punti siamo d'accordo: quelli li consiglierei sempre, ma un po' più caldamente della media dei consigli umani. --pequod ^..Ħƕ 22:41, 27 nov 2012 (CET)

valutazione pagina

lo avevo chiesto qualche tempo fa, ma non avendo avuto risposta ripropongo questa domanda: perché non inserire nelle pagine una sezione sulla loro valutazione (come quella presente in fondo a questa pagina?--Luca1tr1fl☄Auguri!! 21:47, 4 gen 2013 (CET)

annullamento inserzione nuovo nome

mi è appena stato cancellato l'inserimento di un nuovo nome all'enciclopedia di wikipedia per

Contenuto palesemente non enciclopedico o promozionale

sinceramente non ne capisco il motivo... volevo inserire un'associazione di sommellerie che organizza corsi in Italia, legalmente ricosciuti...

Dove discutere: ruolo dei progetti e delle segnalazioni

I luoghi di discussione su wp sono tanti e, come i più assidui sanno, si fa un po' fatica a star dietro alle varie discussioni. Avanzo una proposta di massima che, pur riconoscendo che gli atteggiamenti non possono essere istituiti per decreto (ancor meno in un contesto di volontariato), quanto meno delinea un asintotico ordine, che può essere reso buona prassi con l'uso (a partire dagli utenti più esperti).

Partiamo dal principio che una talk ha per tema la stessa pagina a cui fa riferimento. A questo principio sfuggono le talk dei progetti, che invece, per definizione, si occupano innanzitutto di altre pagine (e solo secondariamente della pagina cui la talk fa riferimento).

Ecco quindi un elenco dei modi in cui collocare una discussione in base ai diversi namespace.

• ns1 (talk delle voci): la discussione deve riguardare la voce e può essere segnalata nelle talk dei progetti
• ns3 (talk degli utenti): la sua funzione normale è quella della discussione a due tra utenti
• ns5 (talk di wp): ns4 è molto variegato come ns, quindi non è possibile indicare un modus unitario; del resto, ns4 è già un luogo di discussione (un collega pediano mi suggerisce: "il luogo di rosicamento degli insoddisfatti"); in ns5 si svolgono molte discussioni che andrebbero fatte nelle talk dei progetti di servizio (mancano alcuni progetti di servizio che imho andrebbero creati - vedi sotto)
• ns7 (talk dei file): le discussioni nelle talk dei file sono molto difficili da intercettare: andrebbero sempre segnalate ad uno o più progetti potenzialmente interessati; le discussioni su file di servizio possono essere segnalate al progetto Coordinamento e/o ai sottoprogetti di servizio potenzialmente interessati
• ns9 (talk di mediawiki): l'interfaccia di Wikipedia non può cambiare senza che la comunità (come anche il lettore occasionale) ne abbia piena contezza: queste discussioni andrebbero svolte nella talk relativa, ma sempre segnalate al bar generalista
• ns11 (talk dei template): la discussione deve riguardare il template e, se giudicata particolarmente interessante, può essere segnalata nella talk del progetto:template (o anche di progetti tematici potenzialmente interessati); le discussioni di valenza generale (o che coinvolgono un gran numero di voci) possono essere aperte nella talk del progetto template
• ns13 (talk delle pagine di aiuto): la discussione deve riguardare la pagina di aiuto; manca un progetto che coordini le migliorie alle pagine di aiuto: imho andrebbe creato
• ns15 (talk delle categorie): sussiste lo stesso problema che per i file; anche in questo caso, la discussione deve riguardare la categoria relativa, ma la segnalazione al progetto categorie può risultare determinante (del resto non è neanche un bar intasato); la discussione può essere segnalata a progetti tematici potenzialmente interessati
• ns101 (talk dei portali): la discussione deve riguardare il singolo portale; discussioni generali sui portali non si sa dove farle e spesso vengono fatte nella talk di wp:portale o di aiuto:portale, con un risultato dispersivo; la soluzione è imho spostare portale:portali a progetto:portali, dato che al momento la pagina non è che un elenco di portali, che può ben esistere anche in ns:progetto. Non si tratta di una modifica formale: a noi serve un progetto di coordinamento sui portali e soprattutto una talk dove discutere di progetti in generale.
• ns103 (talk dei progetti): come detto, queste sono talk particolari; per discussioni generali sul tema "progetto", manca un progetto di coordinamento; abbiamo anche in questo caso una curiosa pagina portale:progetti, anche qui un elenco che può ben essere ospitato in progetto:progetti, nella cui talk si discuta di progetti in generale. Questo genere di discussioni si svolgono ad oggi nella talk di wp:progetto.

Tanto il progetto sui portali che quello sui progetti sono due normali progetti di servizio o, se si vuole, sottoprogetti di progetto:coordinamento.

Un altro punto. Per segnalare interventi o proposte, dovremmo abituarci a linkare il diff o il rinvio a sezione con permalink o l'archiviazione farà via via sballare tutti i collegamenti e ricostruire il filo delle discussioni diverrà molto difficile. A meno che non si affidi ai soli admin il compito di archiviare le discussioni (possono infatti spostare con soppressione del redirect - che poi ripristineranno selezionando nella crono). La cosa non mi pare praticabile. Proposta: istituire un gruppo di cambusieri, che possono fare questa operazione *esclusivamente di archiviazione* (viene insomma loro concesso il potere di cancellare, ma lo possono usare solo in questo contesto, pena la rimozione immediata del flag). Se così fosse, le archiviazioni taglia e incolla verrebbero abolite. Fantawiki? No, cerchiamo di capire che il nostro progetto ha una decina di anni alle spalle ma magari 100 davanti, 1000... Allora cerchiamo di ragionare su un piano lungo. --pequod ^..Ħƕ 15:28, 16 mar 2013 (CET)

Ulteriore proposta: invece di avere un progetto:Coordinamento/Vetrina e non avere una cosa analoga per le vdq, potremmo accentrare nella talk di progetto:qualità. Ciò è ancor più necessario da quando vetrina e vdq sono state in certo modo integrate. --pequod ^..Ħƕ 15:32, 16 mar 2013 (CET)

Sull'aggiunta di un altro flag sono abbastanza dubbioso, mi sembra un avvitamento burocratico e probabilmente non ci sarà consenso a dare a un utente degli strumenti che praticamente non potrà mai usare (basta vedere le mille proposte di potenziamento del flag di rollbacker, tutte - giustamente, imo - respinte, anche se relative a funzioni che sarebbero state molto più utilizzate dagli interessati rispetto a quelle proposte qui). Direi che in questo caso basta fare attenzione nel segnalare e abituarsi a seguire una prassi piuttosto che un'altra, magari bacchettando per i primi tempi chi si dimentica :) Per il resto, rispondo per quello che so:

• ns5: in realtà è giusto che le proposte di modifica a una linea guida siano fatte nella talk della linea guida stessa. In effetti manca un progetto attivo di coordinamento per le linee guida
• ns9: le poche volte che viene concretamente proposta la modifica di un messaggio di sistema la cosa viene anche segnalata al bar generale, a meno che la modifica non sia di poco conto. E va bene così, IMO: se si tratta di modifiche rilevanti è giusto che tutti partecipino o abbiano notizia della cosa
• Progetto di coordinamento per linee guida e pagine di aiuto: ci sono entrambi, ma sono inattivi o quasi. Per le pagine di aiuto sta un po' subentrando il progetto Accoglienza, che essendo un progetto non solo di coordinamento ma anche di assistenza attiva può contare su una certa presenza di utenti. Quindi per le pagine di aiuto credo sia meglio lasciare la situazione attuale. Anche per quanto riguarda le linee guida IMO va bene la prassi attuale: si discute nella singola talk e si segnala al bar, se c'è una questione generica è bene porla al bar direttamente. Come per MediaWiki, è bene che tutti sappiano delle modifiche alle "regole".
• La proposta sarebbe di sdoppiare (come già si fa per i progetti tematici, tipo Portale:Guerra e Progetto:Guerra?) Portale:Progetti trasferendo la parte "tecnica" a Progetto:Progetti? E la stessa cosa per Portale:Portali? Per il primo va bene, per il secondo sono dubbioso: le discussioni sul singolo portale o anche un po' più generali su portali collegati si tengono di solito nelle talk dei progetti competenti. Per le questioni più generali si va al bar.

In generale, occhio a non volere degli schemi operativi troppo rigidi e dettagliati, perché in fondo se facciamo così vuol dire che ci va bene così, e modificare le usanze fossilizzate non sempre è un bene :) Comunque i tuoi attacchi di logorrea su questioni di backstage e manutenzione sono sempre centrati e ben accetti, lo sai :D --Dry Martini confidati col barista 16:09, 16 mar 2013 (CET)

Sul flag di cambusiere: di fatto, gli unici a poter operare un'archiviazione adeguata ad oggi sono gli admin. "strumenti che praticamente non potrà mai usare"? Mah, veramente io archivio le talk piuttosto spesso e siccome non sono admin non lo posso fare nel modo più adeguato. A me pare che l'avvitamento burocratico consista proprio nell'attaccarsi ai vecchi modi e a non essere pronti a cambiamenti suggeriti dalla natura stessa del sistema. L'utilizzo circoscritto a certe funzioni del flag di admin è legato ad un discorso di fiducia e può essere gestito senza particolari esigenze tecniche (è un flag informale).

Grazie per avermi segnalato il Progetto:Coordinamento/Pagine di aiuto, non lo ricordavo più. In ogni caso il progetto:coordinamento dovrebbe organizzare la propria talk ad imitazione della talk del progetto:biografie. Mi sono accorto del ruolo del progetto:accoglienza nella gestione delle pagine di aiuto, ma sarebbe bene operare con un occhio al futuro: tu dici che se noi facciamo in un certo modo ci sarà una ragione. Scusami, ma è un modo di pensare che involontariamente getta alle ortiche ogni possibilità di cambiamento. Oggi noi facciamo così: se la comunità degli assidui fosse composta da 500 persone diverse dalle attuali, stanti così le cose, farebbero semplicemente in un altro modo e ad ogni proposta di cambiamento risponderebbero "se facciamo così un motivo ci sarà". Pensare agli utenti del futuro significa pensare a tutti gli utenti possibili: ciò prescrive di motivare le proprie scelte alla luce di ragionamenti. Che la comunità odierna faccia in un certo modo secondo me non significa praticamente nulla, finché non risulta spiegato il perché. Chi fa parte del progetto:accoglienza può valutare di seguire il progetto:pagine di aiuto (progetto:aiuto), senza forzare la struttura alle proprie esigenze, ma deviando il proprio operato secondo principi di efficienza. Quindi per le pagine di aiuto credo sia meglio lasciare la situazione attuale. E quale sarebbe? Quella di avere un progetto di coordinamento di fatto inattivo e lasciare le discussioni sparse? E che soluzione è? Anche per quanto riguarda le linee guida IMO va bene la prassi attuale: si discute nella singola talk e si segnala al bar, se c'è una questione generica è bene porla al bar direttamente. Come per MediaWiki, è bene che tutti sappiano delle modifiche alle "regole".: dimentichi che una posizione è scientifica finché è falsificabile. Analogamente, una scelta organizzativa su un wiki è falsificabile nella misura in cui può essere agevolmente richiamata la sua ratio. Per far ciò è importante poter rintracciare facilmente le discussioni che la informano. Praticamente è una verità universale che far ciò su wp è difficile, perché le discussioni sono sparse. Si pone un problema: su it.wiki 90 volte su 100 si ragiona così, "lasciamo le cose come stanno" (e poi si cambia, un buon 50% delle volte, solo con più fatica: se un problema c'è, non si può lasciare le cose come stanno, a meno che uno non rinunci a risolvere). Si tratta quindi non solo di aprire una discussione in un certo posto, ma di renderla rintracciabile per il futuro: a questo proposito, anche la segnalazione è qualcosa, ma l'importante è che ci sia un luogo centralizzato dove ritrovare in futuro le discussioni più importanti e più generali sui temi "portale" e "progetto". Per "progetto" di solito la soluzione è discutere nella talk di wp:progetto. Non è un dramma; per "portale" la situazione è più confusa (infatti per il portale c'è anche una pagina di aiuto, che per "progetto" non c'è). La proposta su portali e progetti è di spostare (con soppressione del redirect, perché no) le pagine portale:progetti e portale:portali rispettivamente a progetto:progetti e progetto:portali, due sottoprogetti del Coordinamento.

Il progetto:Norme e regolamenti, a parte il nome tremebondo (visto che le nostre sono più felicemente delle "linee guida"), è archiviato come storico. Bisogna valutare se servono due sottoprogetti di coordinamento per pagine d'aiuto e linee guida o ne basti uno.

Naturalmente non sono favorevole a cambiare solo per il gusto di cambiare: chiedo appunto solo di discutere delle proposte di cambiamento. --pequod ^..Ħƕ 17:03, 16 mar 2013 (CET)

Ultime modifiche nelle pagine di discussione

Al momento abbiamo uno strumento che permette di vedere le ultime modifiche che avvengono su Wikipedia e impostando il namespace "Discussione" è possibile vedere solo gli interventi nelle discussioni (vedi qui). Esiste o sarebbe possibile creare uno strumento simile che restringa il campo solo alle discussioni che fanno capo alle voci di una certa categoria e relative sottocategorie? La mia domanda nasce dal fatto che se avessimo uno strumento del genere penso sarebbe utilissimo nell'ambito dei progetti tematici, ad esempio gli utenti del progetto:Chimica potrebbero sapere quali sono state le ultime discussioni in tutte le voci che riguardano la chimica e parteciparvi. --Daniele Pugliesi (msg) 16:59, 16 mar 2013 (CET)

Prova ad aprire la categoria, cliccare su Modifiche correlate e selezionare il namespace Discussione: vedrai tutte le modifiche alle talk delle pagine inserite nella categoria. Copia il link da qualche parte e ogni volta che lo apri ti mostra l'elenco aggiornato. Esempio, allungato a 30 giorni dai 7 standard perché la nautica non se la fila nessuno :) --Dry Martini confidati col barista 17:19, 16 mar 2013 (CET)

Ho provato con "Categoria:Chimica" (vedi qui), ma questo strumento non mi pare adeguato, in quanto fornisce un elenco che non è per nulla completo; infatti negli ultimi 30 giorni ci sono state moltissime modifiche nelle voci e nelle pagine di discussione di voci sulla chimica, ma nell'elenco non compaiono. --Daniele Pugliesi (msg) 17:45, 16 mar 2013 (CET)

Questo perché funziona solo con le pagine che sono contenute nella categoria stessa, non nelle sottocategorie. Per uno strumento più ad ampio spettro puoi provare a generare una lista qui su wiki di tutte le voci contenute in una categoria e nelle sottocategorie e poi esaminare le modifiche correlate a quella lista. Solo che poi la lista va aggiornata ogni volta che una voce viene aggiunta o tolta dalla lista. Per generare una tabella in formato wiki (occhio alle impostazioni, però: il default restituisce tutt'altra cosa) con tutte le pagine contenute (anche indirettamente) in una categoria puoi usare questo tool (è molto lento, anche perché riguardo a ciascuna voce recupera informazioni per lo più inutili, ma il risultato è adatto all'uso che vuoi farne). Non so se ci siano strumenti più automatici per tenere d'occhio una determinata serie di pagine. --Dry Martini confidati col barista 15:45, 17 mar 2013 (CET)

Ancora per uno standard consigliato di archiviazione

Segnalo. --pequod ^..Ħƕ 22:49, 21 mar 2013 (CET)

Richiesta di valutazione pagina aziendale

Salve, ho creato dentro https://it.wikipedia.org/wiki/Utente:Barbieri.wiki/Sandbox una pagina relativa alla mia azienda e vi chiedo se ha i requisiti per diventare una voce di wikipedia. L'azienda è quotata in borsa, ha contribuito all'evoluzione tecnologica di elementi considerate voci enciclopediche ('gazebo', 'colonnina di ricarica' e 'stazione di ricarica per veicoli elettrici'), e alla creazione di nuove voci ('tunnel estensibile' che dovrò creare). Il titolare è anche un personaggio pubblico ha partecipato e continua a partecipare a trasmissioni di carattere politico come l'ultima parola su rai2. Infine, attraverso l'impegno a produrre nel campo delle rinnovabili e delle infrastrutture per le auto elettriche, dimostra di contribuire alla diffusione della cultura della difesa del patrimonio ambientale della nazione.

Grazie mille.

Silvia

Questa non è la pagina adatta, mi spiace. Per valutare l'enciclopedicità di una voce puoi chiedere aiuto al progetto tematico competente (in questo caso il progetto:Economia). Buona navigazione su Wikipedia in italiano! --Dry Martini confidati col barista 16:57, 10 mag 2013 (CEST)

pagina cancellata

Avevo iniziato a inserire una pagina su una persona (vivente) che è stata cancellata perchè, probabilmente passata come "promozione". In realtà si tratta di un personaggio, poco noto al grande pubblico, ma significativo per il suo impegno nell'arte e nella cultura di cui sarebbe interessante rimanesse un traccia del suo impegno disinteressato fondatore di associazioni psicanalatiche riconosciute e di molte iniziative di rilievo culturale e storico. La pagina non era completa, era solo un incipit rispetto alla notevole mole di informazioni (tutte reperibili) da inserire. Con quale criterio quindi viene deciso di cancellare? Grazie. — Questo commento senza la firma utente è stato inserito da Exfabbricadellebambole (discussioni · contributi) 08:42, 7 giu 2013‎ (CEST).

Se non dici a chi ti riferisci è un po' difficile aiutarti. :) Cmq questo non è il luogo adatto in cui discutere la cosa. Se vuoi, scrivimi e cercherò di chiarirti le idee. Ciao! --pequod ^..Ħƕ 15:00, 7 giu 2013 (CEST)

biografia cancellata - perche'?

Ho inserito una pagina su una persona vivente (Luigi Lovaglio) che è stata cancellata. Si tratta del Presidente della seconda piu' grande banca polacca e una delle piu' grandi banche del gruppo bancario UniCredit. Il Sig. Lovaglio e' stato insignito dell'onorificenza di Commendatore dell'Ordine della Stella della Solidarieta' Italiana, con decreto del presidente della Repubblica Italiana, Giorgio Napolitano, in riconoscimento del suo significativo contributo nello sviluppo delle relazioni economiche tra la Polonia e l'Italia. Con quale criterio la voce e' stata cancellata? Cosa posso fare per farla ripristinare? Grazie. — Questo commento senza la firma utente è stato inserito da 193.111.166.136 (discussioni · contributi) 12:58, 5 ago 2013 (CEST).

Per favore, leggi l'avviso in testa a questa pagina: è in giallo. pequod76^talk 15:32, 25 ott 2013 (CEST)

Salve, sono uno studente dell'I.I.S.S. "S.Mottura" di Caltanissetta e non vedo l'ora di poter contribuire alla creazione di una pagina dedicata al museo mineralogico Mottura. Spero nella vostra comprensione visto che sono ancora inesperto. Grazie.

bisogna aggiornare la pagina

Salve a tutti, vi segnalo che questo paragrafo è diventato obsoleto per quanto riguarda l'esempio di avviso di ricezione di messaggi da altri utenti. Ormai utilizziamo l'innovativo metodo notifiche, ma in quel paragrafo viene ancora fatto l'esempio della barra arancione (classe usermessage). Non dite di aggiornarla? Grazie per l'attenzione --Sepp.P 13:52, 11 dic 2013 (CET)

Sarà pure un metodo innovativo ma sarebbe da tenere presente che non sono tutte rose e fiori. D'accordo per l'aggiornamento che dovrebbe tenere conto del contenuto di questa discussione. In definitiva chi, per un motivo o per l'altro, volesse tornare al classico avviso su sfondo arancione lo può fare agendo sul monobook personale e il bello di tutto ciò è che mantiene attivato anche il nuovo sistema di notifica. --Pracchia 78 (scrivimi) 14:30, 11 dic 2013 (CET)

wikt:MediaWiki:Gadget-BannerNotifiche.js

Specificità dei titoli dei thread

Nell'ambito di un parziale riordino di questa pagina di aiuto sulle talk, ho inserito una raccomandazione sulla specificità dei titoli dei thread. Molto spesso vedo utenti anche esperti aprire discussioni con titoli come "Cancellazione" o "Avviso" (in particolare nelle talk dei prg).

Questo richiamo al bar soprattutto per porre brevemente l'attenzione su questo piccolo problema, che può comportare qualche grattacapo in termini di TOC (indice della pagina). Segnalare uno fra mille thread che si chiamano "Avviso" può essere inutilmente complicato. Per le pdc, ad es., è sufficiente scegliere il titolo "PDC NomePaginaInSemplificata".

Ai niubbi che dovessero leggere la p. di aiuto ho anche raccomandato l'uso dei wlink per agevolare le segnalazioni. Spesso si vede scrivere "Ho inserito una biografia ma mi è stata cancellata"... e uno deve controllare i contributi per capire di quale voce si stia parlando.

Con l'occasione vi segnalo anche diversi edit con cui ho inteso riordinare la p. di aiuto sulle talk. (diff). pequod76^talk 17:36, 3 feb 2014 (CET)

Bene, grazie. --109.54.1.234 (msg) 00:29, 4 feb 2014 (CET)

Ottimo. Ci voleva! --Daniele Pugliesi (msg) 02:12, 4 feb 2014 (CET)

Non esiste più il banner (o i messaggi interni)?

Un avviso da aggiornare, riguardante le pagine di discussione degli utenti, dice: "Non esiste più il banner (o almeno non esistono più quei messaggi interni)"

Io però, come detto, vedo eccome ancora il banner arancione.

E anche i messaggi (interni, in che senso, ne esistono altri?) ci sono ancora. --109.55.21.216 (msg) 15:29, 25 giu 2014 (CEST)

Se ho ben capito la novità è solo per gli utenti registrati. --109.55.21.216 (msg) 17:27, 25 giu 2014 (CEST)

Utente da convincere

Qualcuno può dire all'utente:Agatino Catarella che quando riceve un messaggio nella sua pagina di discussione non deve rispondere lì, ma nella pagina del mittente? Io ho provato a ripeterglielo ma non mi dà ascolto. Inoltre rimuove ripetutamente l'avviso di benvenuto.--Mauro Tozzi (msg) 09:57, 7 ott 2014 (CEST)

Qualcuno può dire all'utente Mauro Tozzi che qua si parla della pagina mentre certe richieste è meglio farle agli amministratori così quando cancella per l'ennesima volta lo bloccano per qualche ora e capisce :) Io glielo dico però meglio segnalare la richiesta in Wp:RA --Pierpao.lo (listening) 13:09, 7 ott 2014 (CEST)

Anzi no aspetta, non è italiano, è un wikipediano normale per posta discute come in tutti i progetti del mondo non italiani, adesso gli scrivo nella sua wiki--Pierpao.lo (listening) 13:11, 7 ott 2014 (CEST)

Proposta di revisione delle modalità sintattiche d'indentazione

Il sotto-paragrafo §3.3.5 della pagina di aiuto consiglia l'uso dei due punti per ottenere un'indentatura del testo che favorisca la leggibilità. Benché l'indentatura sia assai pratica e auspicabile, consigliamo di realizzarla attraverso un uso improprio della sintassi wiki, che genera codice HTML errato. Dovremmo individuare ed adottare una convenzione alternativa al più presto. La prima che mi viene in mente e molto simile a quella attuale, è l'uso di semplici liste puntate, usando l'asterisco.

Più nello specifico, la wikisintassi dei due punti è parte del costrutto utilizzato per creare liste di descrizioni che, come descritto in Aiuto:Markup#Sezioni, paragrafi, liste e linee, prevede l'uso di:

1. una sequenza di testo prefisso da punto e virgola,
2. una o più sequenze di testo prefisse da due punti.

La prescrizione ricalca esattamente la regola sintattica dell'elemento DL di HTML, che realizza una lista di descrizioni e nel quale è appunto tradotto. Usare i due punti all'inizio di un commento genera codice HTML come il seguente, che ho estratto da questa stessa pagina di discussione aggiungendovi qualche interruzione di linea:

 <p>
   Segnalo
   <a class="external text" href="http://liquidthreads.labs.wikimedia.org/wiki/Main_Page">Liquid threads</a>
   da labs.wikimedia.org, che dovrebbe agevolare il modo in cui si svolgono le discussioni.
   --<a href="/wiki/Utente:Pequod76" title="Utente:Pequod76">Pequod<span style="color:#008000;">76</span></a>
   <sup>(<a href="/wiki/Discussioni_utente:Pequod76" title="Discussioni utente:Pequod76">talk</a>)</sup>
   14:00, 26 ott 2009 (CET)
 </p>
 <dl>
     <dd>
       Se si tratta della
       <a href="/wiki/Wikipedia:Bar/Discussioni/Nuova_indentatura_delle_discussioni"
          title="Wikipedia:Bar/Discussioni/Nuova indentatura delle discussioni">stessa cosa
       </a>
       non aveva riscosso grande successo.
       --« <small><a href="/wiki/Discussioni_utente:Gliu" title="Discussioni utente:Gliu">Gliu</a></small> »
       19:54, 26 ott 2009 (CET)
       <dl>
           <dd>
             No, non è la stessa cosa.
             --<a href="/wiki/Utente:Nemo_bis" title="Utente:Nemo bis">Nemo</a> 23:07, 26 ago 2010 (CEST)
           </dd>
       </dl>
     </dd>
 </dl>
 

Come risulta evidente il codice HTML non è valido, perché in ogni DL manca l'elemento DT, che dovrebbe sempre precedere gli elementi DD, e che è quello che sarebbe generato dal punto e virgola se fosse stato presente. Questa pratica, anzi, questa gabola sintattica, è peraltro sconsigliata per lo stesso motivo anche dalla pagina di aiuto di Wikimedia (la pagina originale da cui fu tratta la traduzione che oggi è Aiuto:Markup), dove si avverte che [t]his workaround may harm accessibility (in italiano "questo trucco potrebbe compromettere l'accessibilità"). Penso dovremmo cambiare abitudine promuovendo l'uso di sintassi alternative e sconsigliando quella attuale.

--SoujaK (msg) 17:50, 11 dic 2014 (CET)

Orpo...! Mi sa che tu abbia ragione. Sto cercando la maniera di trovare un fallo nel tuo ragionamento, ma per ora mi sono dovuto arrendere :-) Nella mia ingenuità credevo che i "duepunti" utilizzassero il tag <blockquote> (quello che ho usato adesso per il mio intervento al fine di tacitare la mia coscienza), ma evidentemente non è così...--Lepido (msg) 18:14, 11 dic 2014 (CET)

valepert

si potrebbe provare a rispondere così! :D --18:33, 11 dic 2014 (CET) ps. ha il difetto che l'ora non si può inserire in "firma" poiché sono presenti i due punti.

SoujaK (msg) 18:45, 11 dic 2014 (CET)

E il primo livello di annidamento andrebbe fatto così. La trovo una proposta da non disdegnare, perché non lontana dalla semantica delle DL. Forse è pure possibile racchiudere automaticamente la data che è presente nella firma dentro un NOWIKI, cosicché si possa firmare con le quattro tildi, anziché tre. Formattazione del commento successivamente modificata dall'autore.

Anche io ero convintissimo come Lepido che i due punti si traducessero in <blockquote> :O Comunque, senza guardare dentro al MW, sostanzialmente direi che se provi qui a svuotare i DT (es: <dt></dt>), dovresti vedere che sparisce anche la riga, questo dovrebbe dire che il DT funziona solo se valorizzato, ma nessuno dice che debba esserlo (che debba cioè avere un contenuto), quindi se non c'è un titolo, l'HTML non mostra nemmeno la riga (il blocco, in realtà). Di fatto, gli elementi della nostra lista (DD) non hanno un titolo DT perché sarebbe vuoto: il post cui io rispondo indentando non è un titolo di ciò che sto postando io, nella sostanza è solo un altro post senza titolo, e se proprio dovessi mettere un DT sarebbe un DT vuoto.
Diciamo che si è trovato molto comodo a fini wikipediani (in MediaWiki come già in Usemod) usare i due punti per scrivere del testo indentato formattandolo velocissimamente (come indentato) con un solo carattere, ma la funzione propria, in HTML, del DD è tutt'altra cosa (fu sviluppato come modello per faq, se non ricordo male), e che possa esservi qualche problema con l'uso che ne facciamo qui mi pare comprensibile. A quel punto, dato che non dovrebbe esserci differenza di rendering, che sia andata così intenzionalmente o che ce lo siamo trovati così per qualità delle stimate terga, il tutto si può anche leggere come semplice omissione di tag ininfluenti perché vuoti. O per lo meno sono ininfluenti con la maggior parte di browser (e lo sono stati per la maggior parte del tempo, non ricordo infatti di aver mai avuto problemi su questo); anche un controllino specifico evidenzia (non li ho aperti tutti, ovviamente) solo minimi problemi (per ora vedo Dillo e Iceweasel su Deb 6, non si vedono i primi duepunti per i testuali Lynx e Links). Non so in questo momento chi potrebbe patire problemi di accesso, credo che prima dovremmo contestualizzare il reale malfunzionamento e poi vediamo se serve agire o se - come per molte altre cose - saremo costretti a restar vicini alla perfezione senza però raggiungerla ;-) -- g · ℵ (msg) 01:33, 12 dic 2014 (CET)

Forse c'è una via d'uscita. Ho cercato nella documentazione W3C e almeno per l'HTML5 dovrebbe essere un caso previsto, se ho capito bene. Qui infatti tra i vari casi c'è anche:

«If a dl element has one or more dd element children but no dt element children, then it consists of one group with values but no names.»

Quindi almeno per i browser che masticano qualcosa di HTML5 (quelli più recenti, insomma) il caso in esame è previsto ed è considerato codice valido. Occorrerebbe analizzare se anche per le versioni più veduste dell'HTML e dei browser questa validità persista, ma almeno per la mia coscienza (di cui sopra...) questo mi basta :-) --Lepido (msg) 08:10, 12 dic 2014 (CET)

Mi sembra però si stia discutendo sulla base di una premessa errata. Le specifiche HTML 4.01 non dicono da nessuna parte che il tag <dt> sia obbligatorio, anzi. La definizione formale delle liste di definizione nello standard HTML 4.01 è la seguente (vedi anche W3C):

 <!ELEMENT DL - - (DT|DD)+

che vuol dire che il tag DL può avere come figli diretti indifferentemente zero o più tag DT o anche zero o più tag DD, ossia un costrutto del tipo <dl><dd></dd> è perfettamente valida e coerente con la definizione formale di dipendenza. Non c'è quindi alcuna relazione di dipendenza obbligatoria del tag DD dalla presenza di un tag DT, anche perché altrimenti la definizione della raccomandazione sarebbe stata diversa e sarebbe stata espressa come:

 <!ELEMENT DL - - (DT)+

seguita da

 <!ELEMENT DT - - (DD)+

come avviene, per esempio, per la definizione delle tabelle dove sotto l'elemento padre TABLE l'unico figlio previsto è TR, il che vuol dire che "non si posson usare tag TD se non sono figli di un TR". Quindi, l'obiezione che "il codice HTML attuale non si valida" non mi sembra semplicemente fondata, alla luce delle definizioni formali dello standard HTML 4.01 in W3C. --L736E^{l'adminalcolico} 09:09, 12 dic 2014 (CET)

E così anche l'HTML 4.x è sistemato e questo penso tagli la testa al topo. Posso tornare a fare sonni tranquilli :-) --Lepido (msg) 09:14, 12 dic 2014 (CET)

Occhio agli incubi, però, guarda il validatore che chiede «one or more dt elements followed by one or more dd elements», "one or more" cioè "uno o più" cioè "non zero"... -- g · ℵ (msg) 10:50, 12 dic 2014 (CET)

[↓↑ fuori crono] Gianfranco ha ragione: il content model del DL in HTML 5 è definito appunto come segue e lascia poco spazio a intepretazioni a nostra scusa. «The dl element represents an association list consisting of zero or more name-value groups (a description list). A name-value group consists of one or more names (dt elements) followed by one or more values (dd elements), ignoring any nodes other than dt and dd elements. Within a single dl element, there should not be more than one dt element for each name.». --SoujaK (msg) 11:31, 12 dic 2014 (CET)

[↓↑ fuori crono] Ho trovato, nello stesso documento appena citato, una nota alquanto appropriata: «The dl element is inappropriate for marking up dialogue.» --SoujaK (msg) 11:50, 12 dic 2014 (CET)

[↓↑ fuori crono] La definizione di HTML 4 citata da L736E non è rilevante, visto che il codice generato è nella quinta versione. Peraltro l'operatore + indica "uno o più", non "zero o più".--SoujaK (msg) 11:31, 12 dic 2014 (CET)

[↓↑ fuori crono]La frase a cui Lepido fa riferimento all'inizio non è la definizione del content model, ma l'algoritmo di visualizzazione, che in questo caso gestisce codice HTML non aderente ad esso ed è pertanto non valido (stendiamo un velo pietoso sulla ridicola autocontradditorietà di un documento di specifica che definisce come gestire eccezioni ad essa stessa). Ma ciò che noi vogliamo è codice HTML valido, non codice che (in certi casi) funziona. Vero? --SoujaK (msg) 11:31, 12 dic 2014 (CET)

Domanda da profano, che problemi di accessibilità dà questo "errore"? In ogni caso, credo che in un futuro non troppo determinato si passerà a Flow, per cui se siamo andati avanti per più di un decennio con questo errore possiamo continuare un altro po'... --Cruccone (msg) 11:05, 12 dic 2014 (CET)

Credo che problemi concreti siano assenti per ogni utilizzatore medio che sia dotato di un browser pubblicato negli anni duemila :-) ma immagino possa dare seri problemi ad utenti ciechi che si fanno aiutare da un lettore automatico dello schermo o da altre tecnologie di assistenza che necessitino di interpretare l'HTML delle nostre pagine. Quanto a Flow, esso usa certi nuovi costrutti della quinta versione di HTML per offrire una soluzione indubbiamente più pulita rispetto all'orrido accrocchio che ci ritroviamo al momento, ma bisogna pur dire che la conformità allo standard proprio non sembra essere uno dei principi del suo sviluppo. --SoujaK (msg) 11:50, 12 dic 2014 (CET)

mah, abbiamo avuto utenti notissimi ipovedenti, che so per certo usassero (anche per testare) i reader, e non ricordo che abbiano mai sollevato un appunto circa la difficoltà di seguire i nostri thread, che immagino troveranno semplicemente impilati l'uno sopra l'altro senza indent (che altro può succedere se non funziona il tag di indent?). Quindi può essere più che un errore una non-compliance, in concreto, e non riesco a non considerare che con l'espediente della non-compliance noi abbiamo discussioni intelligibili e che invogliano alla partecipazione. "orrido accrocchio" onestamente non è, dai: mancano dei tag che definirei di formattazione come nell'80% dei siti del mondo (ma pure di più) mancano le chiusure dei tag <meta>, quindi io non auto-giustifico, ma tu non darci addosso :-P Nella media WP è un sito molto avanzato come accessibility, ma tutte le scelte sono compromessi, e questa scelta fu dello usemod, ere cybergeologiche fa, e fu una scelta utile, utillima, sotto altri profili. Con questo non intendo affatto ignorare il diritto degli ipovedenti ad avere una WP accogliente anche per loro, io ad esempio sostengo da sempre una gestione razionale, rispettosa e non fatuamente "creativa" delle immagini in voce, che mi sembra e mi consta essere una sollecitazione più impellente proprio sotto questo profilo. Teniamo conto che WP è uno strumento che è usato da chiunque a caso, che deve esserlo e che è stato creato per esserlo, e non dimentichiamo che ha una funzione di trasmissione di concetti i quali, indentati o meno, formattati o meno, con foto o senza, sono ciò che ci interessa debba passare con il reader, con il browser testuale o con qualsiasi altro interprete. Se si può risolviamo, certamente. Allora penso una cosa: i due punti a inizio paragrafo sono "letti" dal MediaWiki (che non lavora in questo caso da parser, solo da converter - è un semplice replace) come <dd>, serve il <dt>, se ne mettiamo uno vuoto non cambia nulla, facciamogli dunque tradurre i due punti con <dt></dt>\n <dd>$edit</dd>, e dovremmo essere a posto. Ma serve? -- g · ℵ (msg) 12:22, 12 dic 2014 (CET)

Sì, credo anche io che il problema sia ben più legato al rispetto di uno standard tecnologico che alle eventuali conseguenti ricadute pratiche per gli utenti. Ciononostante, dal punto di vista tecnico è a tutti gli effetti un errore, inammissibile per un progetto come l'Enciclopedia Libera (lo stesso terzo pilastro parla della scelta dell'uso di "formati aperti" [grassetto nell'originale]), oltre che di cattivo esempio per il settimo sito web più visitato in Italia. Penso che il problema possa e debba essere affrontato con coraggio, cogliendo l'occasione per farci promotori di un web accessibile, interoperabile ed aderente agli standard.

La soluzione "dietro le quinte" proposta da Gianfranco così com'è non può funzionare, ma potrebbe. Infatti il :Testo include il Testo non solo dentro ad un elemento dd, ma include anche quest'ultimo dentro un dl. La traduzione attuale è insomma la seguente:

 <dl>
     <dd>
         Testo
     </dd>
 </dl>

Come comportarsi nel caso in cui è presente un ;Termine nella riga precedente? Esso dovrebbe infatti appartenere allo stesso dl di ;Termine e non possiamo permetterci di introdurre un dl separato. Una variante della sua proposta, che ci permette di correggere l'errore senza modificare le nostre abitudini è: se il motore wiki non trova il ; precedente allore inserisce un dt vuoto.

(Grazie, Gianfranco, per la nota storica su usermod, che non conoscevo.)

--SoujaK (msg) 14:59, 12 dic 2014 (CET)

prego, figurati :-) comunque non intendevo che quello fosse uno snippet pronto all'uso, eh, era giusto per dare l'idea di un possibile metodo di workaround, per scrivere con precisione mancano i dettagli e bisognerebbe trovarli dentro il MW; se decidiamo che serve, ce lo andiamo a guardare e poi lo proponiamo. Quando it.wiki arriva prima dei Progetti fratelli io sono sempre contento ;-) -- g · ℵ (msg) 15:31, 12 dic 2014 (CET)

92 minuti di applausi per Gianfranco. Se Wikipedia dovesse essere un esempio di compliance agli standard html, staremmo freschi. E tra l'altro, con i 10 anni di discussioni archiviati finora che si fa? Ce li teniamo così o mandiamo uno squadrone di bot a correggere? E siamo sicuri che un bot sia in grado di interpretare correttamente tutti i guazzabugli di indentazioni senza fare danni? Come fa notare Gianfranco, nessuno si è mai lamentato delle indentazioni, e sappiamo di aver avuto ipovedenti che leggevano le discussioni, quindi se ci fossero veramente stati problemi, in 10 anni di attività e tra tutte le versioni linguistiche di Wikipedia e degli altri progetti, qualcuno si sarebbe lamentato. Quindi è un problema solo teorico, al massimo reputazionale. Dunque perché utilizzare risorse per un'operazione dispendiosa, a lungo termine (rieducare 3000 utenti attivi a non utilizzare più i "due punti" non si prospetta propriamente come una scampagnata) e a questo punto superflua? Se vogliamo pensare agli standard html, pensiamo alle tabelle, che a rigore sarebbero ormai sconsigliate in favore dei "div"! Se dobbiamo rivedere tutta la struttura delle discussioni solo per l'orgoglio di essere più compliant io dico "no, grazie!" :) --Dry Martini confidati col barista 15:54, 12 dic 2014 (CET)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘Faccio inoltre notare che la stragrande maggioranza degli "errori" ritornati dal validatore ha a che fare con molti altri elementi formalmente deprecati dal HTML 4.01 che però sono rimasti probabilmente per motivi di "compatibilità all'indietro". Gli errori relativi alla "traduzione" del due punti sono nettamente minoritari rispetto a tutto il resto: quindi stiamo qua a fare le pulci su questo dettaglio quando molto più in generale l'HTML generato è "sporco"? Sistemiamo quello e il validatore ritornerà, per questa voce, 140 errori invece di 145: ne vale la pena? Cambia qualcosa? IMO, no. Quel che conta è che la mancata validazione del codice non ha alcun effetto pratico sull'utente finale, a cui i contenuti sono e devono restare accessibili. Sarebbe invece molto più pericoloso modificare il wikicodice per ottenere delle bellissime pagine perfettamente "HTML5 valid" ma che diverrebbero meno accessibili o inaccessibili per quegli utenti che, per quanto pochi possano essere, usano browser con supporto "non conforme" ad HTML5. Avremmo una bellissima enciclopedia con tutte le bandierine del W3C ma uno strumento non più fruibile per tutti. E francamente, visto che lo scopo di Wikipedia non è quello di produrre degli esempi da manuale di codifica HTML ma quello di rendere la sua informazione il più possibile accessibile, preferisco tenermi le pernacchie del validatore ma consentire che il progetto possa essere fruito dal maggior numero possibile di utenti. --L736E^{l'adminalcolico} 16:49, 12 dic 2014 (CET)

Non capisco l'assunzione che un documento valido possa diventare, a seguito di una correzione, meno accessibile o inaccessibile per certi utenti. Mi sembra infondata, ma forse non ho ben capito. Potresti argomentarla più approfonditamente, per favore? --SoujaK (msg) 17:27, 12 dic 2014 (CET)

[@ Dry Martini] Scartando un paio di argomentazioni povere (come "abbiamo sbagliato sinora, non è un problema se continuiamo" o "facciamo errori ben più grossi") quello che resta è la già sollevata problematica del costo della correzione. Ma se la correzione, come proponeva il gianfranco che hai appena applaudito, è fatta senza modificare le nostre abitudini anche questo argomento cade. (A quali tabelle ti riferisci? Il loro uso improprio andrebbe eradicato, insieme agli altri errori.) --SoujaK (msg) 17:42, 12 dic 2014 (CET)

(/me ringrazia commosso dei battimani e grato vi dedica una cara citazione :-D)
Forse è il caso di dare un cenno delle diverse mentalità che ci sono nel mondo wiki: è uscita da poco l'ultima versione di MediaWiki, la 1.24.0, con cui si sospende il supporto per Internet Explorer 6 e Internet Explorer 7 che avevano bisogno di apposite correzioni del MW (js) in quanto (vox populi, ma attendibile) non W3C-compliant. Insomma, non supportiamo più quei lettori (forse lo 0,5%?) che usano quei browser. Se il nostro ecumenismo fosse di impronta gandhiana, o anche solo aprioristico, dovremmo; eppure scegliamo di non farlo più, "sacrifichiamo" quei lettori. Perché non possiamo far tutto. Quelle striminzite righe di codice per farci leggere da IE6 e 7 ci pesano, assai di più di quanto si pensi, perché sono "lette" dal MW a ripetizione e stiamo tenendo a bollire i sistemi per questo irrisorio vantaggio. I sistemi che stanno bollendo son quelli pagati dai donatori, ecco perché dobbiamo a volte fare scelte che possono sembrare "non pure". Non è parte del ragionamento - va precisato - che MS poteva far meglio quei browser, che quando li ha fatti non le mancava nulla per farli bene, e simili moralismi; qui sono meri fatti e mere riflessioni gestionali che si valutano, non è anti-MS, come non è anti-altri la circostanza per cui sostanzialmente non siamo perfettamente leggibili con molti altri browser (gli anziani ricorderanno in quante amorose panìe ci ha fatto arrancare Opera, che è sempre stato un signor programma). In sintesi, le due righette, metti tre, che ci costavano quei due browser ora non le spendiamo più; io personalmente lo trovo pienamente coerente con la mentalità che abbiamo sempre preferito adottare. Veniamo alla modifica possibile:

• il nodo sta (Mediawiki 1.24.0) nel file /includes/parser/Parser.php, riga 2366 e ss. Qui il primo carattere ($char) del paragrafo viene letto e convertito. Quando $char è ":" (i nostri due punti) il parser aggiunge (.=) la stringa "<dl><dd>" che apre l'elemento di lista (poi lo chiude, naturalmente). E anche nel successivo blocco di codice (2460) lo elabora. E' qui che si potrebbe intervenire per inserire il nostro dummy tag "<dt></dt>\n", e chi vuole può proporre come. L'elemento dd non patisce danni da un eventuale dt già dichiarato e valorizzato, perché la coppia vuota "<dt></dt>" (senza fine riga, solo estetico) per l'html è di fatto come non letta e perché comunque non è vietato avere due o più dt di seguito, quindi non occorre ad es. guardare al blocco precedente, è proprio tutto limitato a questo blocco dd.
• una simile modifica non ci farebbe cambiare alcuna delle nostre abitudini, modificherebbe soltanto il codice sorgente di ognuna delle nostre pagine, praticamente a nostra integrale insaputa: i due punti si metterebbero esattamente come prima, ma non darebbero più errore al validatore e nel sorgente ci sarebbe qualche riga in più come se avessimo messo dei commenti. Tutto qui.
• ripeto che, ove si decida di voler essere compliant, sono del tutto contento se it.wiki porta agli altri Progetti (praticamente il progetto MW) una proposta sistemica; ma bisogna deciderlo.
• "abbiamo sbagliato sinora, non è un problema se continuiamo" e "facciamo errori ben più grossi" sono due osservazioni che in sé non varrebbero ad alcuna determinazione, ma quando si tratta di valutare una proposta di modifica sistemica non ci sono argomenti poco importanti a priori. Aggiungere 10 caratteri per ognuno dei nostri due punti, qui dove le talk saranno un milione e mezzo, mettiamo con una media di 5 indent ciascuna, significa andare dai dev e dire loro gioiosamente che abbiamo trovato come spendere 75 milioni di caratteri e qualche kw dei server pagati dai donatori solo per it.wiki (figuriamoci il resto del WikiWorld). Il tutto perché al momento noi non teniamo conto del W3C, che è un altro modo di descrivere il fatto che il W3C non tiene conto del settimo (o quinto?) sito del Pianeta. Conterà infatti o no, secondo voi, quale percentuale di tutti i dd e dl usati (poco) in tutto il web, sia usata da noi in WP? E perché talora e talaltra si son visti "riconoscimenti" come standard di alcuni grovigli di fattura commerciale, perché erano delle aziende top, e oggi non potremmo chiedere di contare numericamente quanti sono in percentuale i "nostri" dd quando noi tecnicamente siamo probabilmente over the top nel nostro specifico?
  Comunque potrei fare all'impronta qualche nome di alcuni dev che - posso garantire - dinanzi alla proposta uscirebbero dall'ufficio, in fretta cercherebbero per strada uno di Napoli (ce ne sono dappertutto, ci mettono poco), si farebbero dare qualche veloce istruzione e tornerebbero da noi pronunziandoci correttissimamente questa imperitura massima napoletana :-D

Io scherzo non per offendere, naturalmente, giusto per stemperare un pochettino (e tornare a climi più sguaiatamente consueti :P), e ripeto che se questo decideremo di voler proporre, vengo a proporlo anch'io. Però ripeto anche che vorrei che guardassimo alla cosa con un po' di realismo. E ripeto allora pure la domanda: ci serve? -- g · ℵ (msg) 21:41, 12 dic 2014 (CET)

Quanto all'eventuale modifica al codice, data la separazione in tre funzioni per la gestione dei gruppi (apertura e primo elemento, elemento intermedio, ultimo elemento e chiusura) forse è sufficiente forzare, nella funzione openList, l'aggiunta del DT vuoto prima del DD. Al momento non né ho tempo né lucidità per guardarci a fondo e verificare che non ci siano incartamenti nella nextItem o nella closeList. Intanto grazie per la preziosa dritta.

Settantacinquemilioni di caratteri? Allora perché non fare una colletta per Wikimedia per regalare lo spazio per cotanto stoccaggio, visto che siamo pure sotto Natale. Prese USB libere su qualcuno dei server per attaccarci una pennetta dite che ce l'hanno? Pensavo da 4GB, ma forse se la prendiamo da 8 stiamo a posto per un po'... voi che consigliate? Sapete, mi dispiacerebbe se andasse sprecata... (Si scherza, eh.)

Battere il consorzio col bastone per guidare il suo operato ha prodotto diverse storture, tra cui la ultima (e pessima) quinta versione di HTML. È questo il modo con il quale vogliamo diventare rispettosi dello standard? Se è così, accontentiamoci come scriveva Lepido, di produrre errori che siano contemplati dal documento di specifica e lasciamo perdere.

--SoujaK (msg) 00:50, 13 dic 2014 (CET)

ma secondo te quanti byte o quanti watt stiamo risparmiando con la cessazione del supporto IE6/7? Guarda che son state segate una ventina di righe, ma metti pure 40 in tutto, in due o tre file soltanto. Eppure, si segano, e né sono le prime né saranno le ultime nella costante spending review che si fa in MW. Pennetta? E' roba che già in un floppy ci sta duecento volte senza piegarla, eppure la si leva. Riesco a comunicare questa strana proporzione? :-)
Circa le "forzature", in realtà non le propongo per davvero, tanto meno propongo bastone o olio di ricino, però gli spazi per considerare in modo diverso il prodotto di quell'ente ci sono: non mi ci approccio con ostilità, ma non condivido nemmeno che gli standard W3C vadano presi quasi fideisticamente, perché - appunto - è pur sempre un ente con parti in causa all'interno del suo supporto strutturale. Quindi non è super partes, non è certo extra partes, e mi pare che concordiamo: si sente. L'ipotesi di sottoporre il caso al consorzio perciò non è impraticabile, almeno in teoria, e in fin dei conti si tratterebbe solo di suggerire di riconsiderare che oggi è qualificato come errore ciò nel concreto errore non è, e di guardarlo alla luce del vasto e verosimilmente maggioritario uso che ne facciamo qui. Gli standard li rispettiamo, ma se qui dobbiamo aggiungere un dummy tag per la compliance, e se questa compliance è solo formale perché in concreto un dummy tag non fa differenza alcuna, lo standard diventa privo di senso.
Una delle due dobbiamo provarla: o il dummy tag o una telefonata al consorzio. Pareri? -- g · ℵ (msg) 12:07, 13 dic 2014 (CET)

Sul risparmio ironizzavo sull'altrui posizione, ma ho mancato di spiegare meglio la mia. (Perdonate.) Colgo l'occasione per spiegare quella che credo essere la ratio dietro al caso portato ad esempio da gianfranco a proposito del frammento JS rimosso, per poi analizzare più approfonditamente quello in oggetto. Il punto problematico non è lo stoccaggio dei dati, ma il trasferimento degli stessi. Il risparmio di -906 B nel codice va moltiplicato, ignorando conservativamente la presenza di cache terze (proxy) o nei clienti (browser), per il numero di pagine richieste, diciamo mensilmente. A livello globale, dove abbiamo circa 20G pagine/mese (restringendoci al ns0), significa insomma risparmiare un volume di trasferimento dati di 18 TB/mese. E questo è un risparmio considerevole per i tempi attuali. Vediamo ora il nostro caso. Non ho trovato statistiche sul numero di visite alle pagine di discussione, quindi supponiamo che ne avvenga una ogni dieci modifiche in ns0 (che mi sembra alquanto conservativo, considerato il peso degli automi nel numero di modifiche). Supponiamo inoltre che: ogni aggiunta del DT vuoto consti di 10 caratteri, che ogni carattere occupi 4 B (codifica UTF-32 per stare molto larghi), e che una pagina di discussione contenga in media 10 indentature (stima di nuovo alquanto conservativa). Visto che di modifiche mensili a livello globale in ns0 ne avvengono circa 1.6 M, l'aggravio di traffico aggiuntivo eventualmente introdotto è quindi stimato in 64 M / mese. Tutti i conti sono fatti a spanne, è vero, ma a livello di ordini di grandezza stiamo comunque parlando di un milionesimo del risparmio del pezzo di JS di cui sopra. Briciole.

Quanto alla telefonata al consorzio, in effetti si potrebbe fare, vista l'importanza degli interessi che rappresentiamo (leggi forza contrattuale). Ed io l'appoggerei, se solo avessimo una proposta sensata da fare, una cambiamento da proporre che colma una lacuna o migliora qualcosa. Ma non è il caso, perché permettere elementi DD senza precedente DT è un evidente stravolgimento della semantica del costrutto come definito sin dalle prime versioni di HTML: una lista di descrizioni è un insieme eventualmente vuoto di coppie, composte da un termine e da un insieme eventualmente vuoto, composto a sua volta dalle relative descrizioni. Una descrizione senza termine è come un elenco numerato dove l'ordine non conta, o come un documento con tre BODY, o come un'intestazione di primo livello contenuta in una di secondo livello. Si può immaginare di tutto, ma non tutto è coerente. Quindi sono fortemente contrario nel merito tecnico della proposta attuale di adeguamento del linguaggio.

In sintesi, l'errore è di Mediawiki e/o delle abitudini sinora ereditate. Risolverlo tocca a noi, o correggendo Mediawiki, o cambiando le abitudini, ma di certo non scaricando il barile al consorzio facendo pressioni per il degrado di HTML. Visto che la correzione software sembra essere: tecnicamente fattibile, marginalmente costosa a livello di carico dei sistemi, gratuita a livello di abitudini della comunità, promotrice di un web che aderisce a standard aperti; credo che la via da percorrere sia questa.

--SoujaK (msg) 13:46, 13 dic 2014 (CET)

Ciò che spetta a me, invece, chiarire e non sottintendere più, è che il tuo discorso è correttissimo, e questo vorrei che lo tenessimo presente, perché nel mio tentativo di tenere il discorso su un piano leggero di semplicità (per la leggibilità anche dei no-tech) non lo sottovaluto affatto, tutt'altro. Però ci sono dei però. E per corretto che sia sotto un profilo che idealmente potrei anche condividere, non posso non sollevare le obiezioni che ti presento perché poi ci sono aspetti che non credo sia meno corretto valutare con la medesima attenzione. Vado con ordine.
E' vero, le stat non sono così dettagliate da dirci l'uso delle talk utente, talk voce, talk aiuto e del ns:wp, che sono i namespace in cui maggiormente si spendono i due punti. I rapporti numerici possono non essere ovvi, considera ad esempio (unrelated) che il ns:utente ha numeri molto prossimi al ns:0, e questo non se lo aspetta mai nessuno; quindi in mancanza di dati certi non farei calcoli basandomi su ns:0, son troppe le differenze nell'uso e son troppo specifiche le peculiarità delle nostre discussioni perché si possano rendere in una formula. In più, se proprio vogliamo calcolare qualcosa ad occhio, dovremmo considerare che gli stessi server che risparmiano sul js sono sempre quelli che servono anche tutto il multimediale (commons + tutti i progetti locali + tutto l'hotlinking che evidentemente sta all'esterno eppure lo foraggiamo gratis di contenuti nostri); se devo pensare alla banda che usa WMF, devo considerare che da una parte ci sono i Parser.php, certo, ma dall'altra ci sono i milioni di file multimediali, ciascuno col suo peso. Solo Commons ha 25 milioni di file, più di 50 Tb che sono distribuiti in continuazione, e solo il suo database fa una quindicina di Giga. Lo scorso novembre, come ricordavi, abbiamo fatto 21 miliardi di pageview fra tutti i Progetti, compreso Commons, senza quindi contare le immagini incluse in queste pagine o in pagine esterne. Su quanti Tera/mese andiamo a raffrontare i 18Tb/m (che non ho difficoltà a prendere per buoni) sopra isolati? Mi manca il numero, ma un'idea delle proporzioni me la faccio: per 228 miliardi di request totali ci sono 147 miliardi di request immagini contro 26 per le pagine (6 volte tanto), e una pagina può pesare in media 5~10 kb, un file medio dovrebbe essere almeno 100 kb, facilmente più. Direi proprio che non sia la banda consumata quello che guardiamo davvero con apprensione. E' l'impiego delle risorse, crederei, proprio come processing, e ancora una volta per meglio valutare deve soccorrere la conoscenza "storica", perché oggi i server non stallano più, cominciamo ad avere un uptime di prima scelta e ci stiamo dimenticando di quando i famosi criceti (che girando nella ruota fanno andare la dinamo che ci tiene su tutto :-) scioperavano ogni due per tre. Abbiamo avuto crisi di funzionamento a volte disastrose, eravamo diventati habitués di Nagios per vedere in tempo reale quali server ripartivano, quali no, dove stavano le nuvolette di fumo, tanto su WP non ci si poteva stare. Il codice è stato pulito e ripulito, e lucidato e cromato, con una maniacalità che ha rasentato l'ossessione. Ma oggi fila tutto che è una meraviglia, grazie a un lavoro mastodontico fatto di innumerevoli interventi di microscopio e nessuno pensa più a cosa abbiamo passato sino a non tanto tempo fa. E' l'uptime che ci interessa, non la banda, la sicurezza della stabilità. Allora è anche il tempo di processing, la sua linearità, la dimensione di cache, sono questi gli aspetti di interesse, perché anche 0,02 millisecondi alle proporzioni che hai calcolato tu sono un tempo critico se stiamo, come spesso stiamo, troppo vicini a termini di timeout o a limiti che sono stati stabiliti con tutti i criceti in mente. I 18 Tera per quel js ce li abbiamo, come ce li abbiamo per mille altre cose. E comunque possono sempre contare sulla tua pennetta e sul mio floppy :-)
Dicevo che il tuo punto è correttissimo, anche se si tratta di una correttezza formale, e forse ci siamo incontrati su un tipo di elemento che è diverso dal body (che se ripetuto impiccia un parser, il danno lo fa) e dalle intestazioni (peraltro, davvero se metto un H2 prima di un H1 mi segna errore? :-O). Con il dt abbiamo la perfetta mancanza di effetti oggettivi nel caso della nostra irregolarità, non c'è proprio nulla che potrebbe essere condotto a negatività in conseguenza di questo "errore". E' questo che lo rende non-errore, e allora la prescrizione diventa dogmatica se dovremo scoprire che sia difesa anche davanti all'evidenza della totale ininfluenza e inefficacia della regola. Se basta un espediente come il dummy tag ad eluderla, è la regola che ha un problema. E c'è un contesto per il quale mentre da un lato striglia i coder, dall'altro il W3C non riesce a costringere i browser agli adempimenti, perché browser 100% compliant non ce ne sono, e comunque non si giustificherebbero mai i diversi rendering; questo quando l'omogeneità funzionale dei browser è uno degli scopi congeniti e fondamentali del consorzio. In questo contesto in cui non c'è la perfezione client side, non mi faccio un grosso problema per una non compliance meramente formale server side. Lato server ho - più che un potere contrattuale - una casistica di difficile paragone e quindi una fattualità che fenomenicamente è un dato oggettivo. Non farei dunque mai una battaglia per il degrado dell'HTML (ellapeppa!), ne farei una per la sopravvivenza del buon senso, perché anche non guardando al fatto che qui con quei due punti ci si è fatto un prodotto editoriale impossibile da raffrontare adeguatamente, resta comunque assodato che la regola non serve, e non ha effetto la sua violazione. Non si tratta di scaricabarile, è il consorzio che mi dà errore per uno stile di comunicazione. Oggettivamente, non si tratta d'altro, siamo in area contenuto e sul contenuto - alle strette - il W3C non ce lo voglio. Lo standard è aperto non quando discende dall'alto come tavole della legge, non quando è eresia fare osservazioni sui comandamenti, è aperto quando elabora il suo e raccoglie l'altrui. Il nostro lo raccoglie o noi siamo figli della gallina nera? Nessuno forza alcuno, con ragionevolezza si può avanzare anche una domanda come quella che ci interessa. Poi ci possono dire no e restiamo come ora, ma questa enciclopedia è già "irregolare" e pesantemente non allineata sotto profili un po' più incisivi, se per portarla là dove serve dovremo essere al di fuori di qualche regola, i ragazzi e gli adulti che ne hanno bisogno l'avranno. Il resto sono parole, ognuno dà loro i significati che vi legge dentro e, parlando che stiamo, W3C per me sta ad indicare le "3 C" di Wikipedia: Cuore, Coscienza e Culo. Il Culo di avere qualcosa da condividere con chi ne ha bisogno. La Compliance, se c'è, va sotto la C di Culo. Incrociamo le dita allora ;-) -- g · ℵ (msg) 16:23, 14 dic 2014 (CET)

Se ho ben capito la questione dei costi è (almeno momentaneamente) accantonata come probabilmente non ostativa. Vengo quindi all'ipotesi di dialogo col W3C per un aggiornamento delle specifiche e alle considerazioni di Gianfranco.

Se sino ad oggi tutto ha funzionato senza che nessuno si accorgesse di nulla (almeno qui su it.wiki) è solo perché i browser, ormai da una ventina d'anni, sono progettati per visualizzare documenti non-HTML: estensioni non-standard ed errori comuni. Se presenti ad un compilatore o ad un interprete un sorgente di un programma che non rispetta la sintassi del linguaggio formale in cui è scritto (p.es. C o Haskell), prima ti schiaffeggia, poi ti spiega dove hai sbagliato e infine ti saluta. Niente file eseguibile, niente esecuzione. Addio. Se presenti ad un browser un HTML errato, il parser ti guarda compassionevole, ti dice di non preoccuparti, che sono cose che capitano, poi cerca di capire cosa avresti voluto scrivere e assembla, come meglio può, la visualizzazione della tua pagina. Ciononostante, almeno per ora, le regole ci sono e le nostre pagine le violano, anche se non ci sono effetti tangibili grazie all'eccessiva indulgenza del browser. L'assenza di controllo su una regola ne legittima la sua violazione? Che ce ne frega, tanto mica se ne accorgono!? :-)

Il nostro problema non è sul contenuto, come scriveva Gianfranco, ma è sulla forma. Anzi, sul formato. Formato di file. HTML. L'indentare non è contenuto, i due punti non sono contenuto e nemmeno il tag DL è contenuto. È tutta forma, per strutturare e meglio veicolare i contenuti messaggi. Nessuna ingerenza da parte del consorzio, quindi, loro fanno il loro lavoro, noi facciamo il nostro. Una tradizione plurisecolare ha cristallizzato le forme con cui formattare il testo (spazi, grassetti, paragrafi...), un software detta le forme con cui decorare velocemente testo, un consorzio detta le forme in cui rappresentare pagine web. Noi, che scriviamo contenuti formattati, o ci adeguiamo alle regole delle prassi e agli standard, o proponiamo correzioni e adeguamenti. Tertium non datur. Essendo contrario all'idea di cambiamento di HTML, che trovo inaccettabile per ragioni tecniche, come spiegavo prima, faccio fatica ad accettare anche l'idea di proporre tale cambiamento al W3C, foss'anche un suggerimento posto in tono interlocutorio. Proprio non vorrei farci fare una tale figuraccia.

Perciò la via maestra resta la correzione della wiki-sintassi. È nella wiki-sintassi che i "due punti" hanno assunto un diverso significato (non solo descrizione di una lista di descrizioni, ma anche mera indentazione) ed è quindi il software MediaWiki, che è permissivo nella wiki-sintassi e imbranato in quella di HTML, che deve adeguarsi, attraverso modalità probabilmente simili al dummy tag o (meglio, ma più costoso da sviluppare) con degli span o div personalizzati (come nel citato Flow).

Perché non approviamo questa piccola mozione interna a it.wiki e passiamo ai fatti, costituendo un gruppo di lavoro interno per proporre direttamente una patch, o per preparare una richiesta alla comunità di MediaWiki?

--SoujaK (msg) 15:18, 20 dic 2014 (CET)

Ho scoperto che la revisione del parser di MediaWiki fu chiesta già nel 2006. Segnalo che là, sul portale di sviluppo di MediaWiki, mi sono permesso di segnalare brevemente la presente discussione, cogliendo l'occasione per fare pressione e cercare collaboratori.

--SoujaK (msg) 18:37, 19 feb 2015 (CET)

Talk utenti: thread compatti con tmp:ping

Invece di scambiarci messaggi nel modo tradizionale, adesso con {{ping}} si potrebbe rispondere al mittente nella propria casella e tutte le conversazioni svolgersi in un unico thread.

Cmq, con Ping è una nuova possibilità, quindi la p. di aiuto va aggiornata.

Il testo da modificare sta in Aiuto:Pagina di discussione#Le pagine di discussione degli utenti, dove dice: È buona norma rispondere ai messaggi ricevuti con un messaggio nella pagina di discussione del mittente per sfruttare al meglio le funzionalità di avviso automatico del software (per ulteriori informazioni vedi: Wikipedia:Notifiche). Al contrario, se per un motivo valido si preferisse rispondere nella propria pagina di discussione, è buona norma avvisare l'altro ogni qual volta si è risposto ad un suo messaggio.

Di fatto mi pare che il "nuovo" sistema sia migliore, ma il vecchio ha il pregio di tenere nell'archivio talk del mittente le risposte (se ci sono state). Non è un pregio eccezionale: a me è capitato abbastanza di rado di andare a controllare gli archivi della MIA talk alla ricerca di riferimenti interessanti. Di solito poi le discussioni tra utenti hanno un valore momentaneo, quindi la "compattezza" del thread è utile soprattutto al momento.

Probabilmente il nuovo sistema può risultare utile per i niubbi: al solo costo di imparare tmp:ping si evitano di modificare le talk degli interlocutori, cosa che spesso produce qualche mal di testa.

Che ne pensate? pequod76^talk 15:10, 25 gen 2015 (CET) p.s.: grazie a Lepido, che ha suggerito di formalizzare la cosa. :)

Non saprei, da una parte si è persa la necessita di rispondere "alla en.wiki", ovvero nella propria talk, dall'altra è anche vero che se entrambi i modi ora sono "corretti" per uniformità globale io ne lascerei consigliato solo uno. In fondo chi risponde nella propria talk c'era prima (ricordo gli avvisi in cima alle talk di diversi utenti) e ci sarà anche in futuro. P.S. Se si decidesse per la modifica, scriverei esplicitamente di usare il {{ping}} se si risponde nella propria talk.--MidBi 16:27, 25 gen 2015 (CET)

Ovviamente a me sembra un sistema interessante. Adesso ormai ci ho fatto l'abitudine, ma quello che si usa solitamente non è un sistema naturale e comodo, soprattutto se in un secondo tempo si vuole seguire un vecchio discorso e almeno all'inizio della mia carriera wikipediana mi pareva proprio un modo strano di comunicare (poi mi ci sono rassegnato). Mi pare che col sistema del ping, il motivo principale per utilizzare il vecchio sistema (la notifica di un nuovo messaggio) sia decaduta, e la scomodità di usare il template è a mio avviso molto minore di saltare avanti e indietro da una talk all'altra. Quindi io proporrei il sistema "ping" proprio come metodo primario e consigliato, relegando l'altro a sistema alternativo. I niubbi saranno facilitati, ma anche i vecchi prima o poi ci faranno l'abitudine. --Lepido (msg) 17:10, 25 gen 2015 (CET)

Francamente non vedo perché, in un affare talmente indifferente, dovremmo consigliare l'uno o l'altro sistema. Una buona p. di aiuto semplicemente dovrebbe riportare entrambi i sistemi. Ciascun utente sceglierà quello che più gli conviene. :) pequod76^talk 17:15, 25 gen 2015 (CET)

È una faccenda didattica. Adesso diciamo: "per fare questo si usa il metodo 'A', ma se vuoi puoi usare il metodo 'B'". Io propongo di invertire le cose: "per fare questo si usa il metodo 'B', ma se vuoi puoi usare il metodo 'A'". È una questione di precedenza che ci spingerebbe lentamente a cambiare usanza, visto che adesso IMHO quella vecchia non ha molte ragioni per essere ancora usata se non perché ci siamo abituati. Per finire, un noto aforisma: "dai a un uomo un orologio e lui saprà sempre che ore sono, dagliene due e lui non sarà più sicuro..." :-) --Lepido (msg) 18:36, 25 gen 2015 (CET)

E se devo ritrovare una discussione a cui ho partecipato e che ho iniziato, come faccio? Almeno col "vecchio" metodo ci sono tutte le discussioni a cui ho partecipato, nel peggior dei casi devo solo cliccare sull'utente e leggere l'altra metà. Appunto perché l'uso è nell'immediato che non è una necessità che le risposte siano in ordine, non è un archivio che ogni tanto va letto e ricostruito. Per non parlare del fatto che mi sembra più "sicuro" lasciare ad ogni utente metà della conversazione. Il metodo del ping lo userei solo per le conversazioni a tre. --Emanuele676 (msg) 18:50, 25 gen 2015 (CET)

Scusate, il testo attuale dà conto della vecchia situazione, con la gran parte degli utenti che si scambiava pennuti viaggiatori e una minoranza che compattava. Adesso, come passo intermedio, metterei un bell'elenco puntato con due elementi. In passato c'è stata una sorda guerra di religione su questa cosa, con tanti utenti della maggioranza infastiditi dall'atteggiamento della minoranza e utenti della minoranza che persino mettevano in PU proclami più o meno minacciosi secondo cui mai e poi mai sarebbero passati al mainstream. Adesso la situazione è cambiata completamente e basta mettere in piano le due possibilità. Non metterei consigli, se volete indicherei pro e contro dell'uno e dell'altro sistema. Va però detto che con Ping c'è il problema dei niubbi che usano VisualEditor. Guardate come mi hanno pingato (vd). E poi, forse per disperazione, questo. Probabilmente se uno fa copincolla, il wikicodice viene riattivato. Non lo so, non uso VE e soprattutto per i tmp mi parve abbastanza ostico. Vediamo di capire meglio questo aspetto.

@Emanuele: ma ti è mai capitato di esserti andato a cercare una discussione a due? Di solito il taglio di questi dialoghi è quello di cercare la soluzione ad un problema di dettaglio, tanto è vero che appena viene assumendo un significato più interessante si cambia sede. pequod76^talk 19:54, 25 gen 2015 (CET)

Ad occhio, una volta a settimana. Magari quando qualcuno mi ha chiarito un dubbio che mi è ritornato. Col nuovo metodo dovrei rifare la domanda, non sapendo ovviamente chi mi ha risposto. Il fatto della sede pertinente non c'entra nulla, la discussione si sposta ma rimane traccia nella mia pagine di discussione, da cui posso trovare l'origine e seguire il link per andare nella sede opportuna per continuare a leggerla. --Emanuele676 (msg) 20:13, 25 gen 2015 (CET)

f.c. L'ho capito che non c'entra nulla, non ho mai detto che c'entrasse. Era per dire qual è il taglio di questi dialoghi: come facevo a sapere che fai una volta a settimana una cosa che io non faccio mai? Cmq, prendo atto, a me non capita davvero mai di guardare vecchie discussioni, per cui ecco non mi aspettavo che per qualcuno potesse essere diverso. pequod76^talk 21:06, 25 gen 2015 (CET)

personalmente preferisco il vecchio sistema, anche per la ragione che mi è molto più agevole controllare la mia talk per capire se devo rispondere, piuttosto che dover tener d'occhio diverse talk. In fondo quando si comunicava per lettera si faceva in questo modo.--Bramfab Discorriamo 20:30, 25 gen 2015 (CET)

Va be', ognuno sceglie il sistema che preferisce, non è questo il punto. Il punto è cosa scrivere nella p. di aiuto. O si sta suggerendo che questo sistema va deprecato? In passato qualcuno della "minoranza" rispondeva "da sé" e neanche avvertiva: il testo riflette un po' quella "deprecatio". Ora ci sono i presupposti per una spiegazione più "neutra"/indifferente. pequod76^talk 21:06, 25 gen 2015 (CET)

Secondo me va deprecato visto che crea disagi anche a chi non ama il metodo (l'inverso no, al massimo hai mezza discussione invece che nulla). --Emanuele676 (msg) 21:15, 25 gen 2015 (CET)

f.c. C'è molta gente che non ama le discussioni spezzettate e spero non siano altri a valutare il loro disagio. Quindi deprechiamo tutti e due i sistemi e smettiamo di comunicare? Io dico sìììììììì! :D pequod76^talk 21:24, 25 gen 2015 (CET)

f.c. In quel caso può copiare la propria risposta anche nella propria discussione, oltre a quella a cui stai rispondendo, e non ci sono problemi. Nel caso inverso no, non posso copiare il messaggio di un altro utente nella mia discussione senza suo permesso. Spero di essere stato abbastanza chiaro --Emanuele676 (msg) 21:30, 25 gen 2015 (CET)

f.c. "non posso copiare il messaggio di un altro utente nella mia discussione senza suo permesso". Noooooo, ma quando mai? :) Ma non è mica così! Tutta Wikipedia viene pubblicata con licenza libera e si può copiare, e non penso che esistano gli estremi di un problema di attribuzione per questo genere di "pubblicazioni". pequod76^talk 00:49, 26 gen 2015 (CET)

f.c. Non so, non si dovrebbe copiare anche la cronologia? Levando l'aspetto legale, mi sembra poco rispettoso. A parte questo, riflettendo meglio, chi ama il metodo "nuovo" se incontra uno col vecchio metodo avrà mezza discussione nella propria pagina, mentre se incontra uno col "nuovo" metodo invece avrà nessuna discussione nella propria pagina. Nella peggiore delle ipotesi ha un qualcosa in più, non in meno. Invece qualcuno che ama il vecchio metodo e incontra uno col vecchio metodo, avrà mezza discussione nella propria pagina, mentre se incontra uno col nuovo metodo avrà nessuna discussione. Quindi ha qualcosa in meno, non in più. --Emanuele676 (msg) 01:26, 26 gen 2015 (CET)

f.c. Il punto è che anche prima del Ping ciascuno poteva fare a modo proprio. Non possiamo pensare di normare questo genere di cose, è un chiaro avvitamente burocratico, per discussioni che hanno un peso specifico nullo per il progetto nel suo insieme. Le discussioni a due non sono affatto la norma, questo è un progetto collaborativo soprattutto perché le discussioni vengono fatte in contesti "pubblici". I "dialoghi" sono sostanzialmente richieste di chiarimento, appelli o proteste, tutte cose che in genere si risolvono in poche battute e hanno carattere assolutamente effimero. Non riesco a capire cosa di sostanziale tu possa cavare dal tuo archivio. Peraltro (IMPORTANTE) puoi benissimo controllare le tue notifiche (vedi Speciale:Notifiche) e avere un quadro assolutamente esauriente delle discussioni recenti che hai avuto. Mi pare semplicemente assurdo che si vogliano mettere dei paletti, soprattutto perché puoi scrivere tutto quello che vuoi sulla p. di aiuto, ma questo mica impedisce alle persone (a dei volontari, segnatamente) di fare un po' quello che credono in ambiti che non affettano seriamente il progetto. Insomma, non è roba per una policy! Ti ripeto, il testo attuale riflette semplicemente, a mio avviso, l'antipatia che la generalità degli utenti aveva per quelli che rispondevano "da sé" senza avvertire (peraltro questi "personalismi" si sono molto affievoliti negli ultimi anni). Ma quelli che avvertivano nella fase pre-ping non sono mai stati redarguiti, l'importante è che la conversazione sia efficace e che il suo risultato sia nella tua testa, non negli archivi. Puoi benissimo copiare queste robe, ma francamente mi sembra tempo rubato a cose più utili su wp (e soprattutto alla RL!). Aggiungo che se hai un dubbio e lo puoi risolvere solo guardando all'archivio della tua talk, forse sarebbe il caso di intervenire sulle p. di aiuto, perché è lì che dovremmo condensare "usi e costumi" del progetto. pequod76^talk 04:06, 26 gen 2015 (CET)

(f.c.) Già chiarito. Se il dubbio mi riviene, devo ridomandare? No, basta controllare l'archivio. Ma se la discussione sta nella pagina di Michele, io come posso ricordarlo? Dici di controllare le notifiche? E come faccio a sapere fra Michele, Marco, Mario e Giulio, chi è che mi ha pingato per la discussione che cerco? Anche per le discussioni a tre che si spostano, almeno rimane traccia dell'inizio e da lì posso arrivare alla discussione del progetto o della voce. Semplicemente il metodo del ping è inutile, poco comodo e dispersivo. --Emanuele676 (msg) 13:55, 26 gen 2015 (CET)

f.c. Divertiamoci. Ti descrivo una dinamica. C'è V, l'utente che ama il vecchio, e N, l'utente che ama il nuovo. Se è N il mittente, scriverà nella talk di V, il quale ovviamente risponderà da N, il quale pingherà V nella talk di N; a questo punto V può o rispondere nella talk di N (e quindi la discussione si compatta da N) oppure pingare N nella talk di V (semplicemente invertendo l'uso vecchio, in modo alquanto paradossale). Se è V il mittente, il processo è identico al precedente, solo che si consuma ancora prima. N con N avranno invece discussioni sempre compatte e V con V sempre discussioni spezzate. Io penso che la cosa più probabile è che i dialoghi si svilupperanno liberamente, in accordo tra utenti, e nei termini più utili, quale che sia il sistema utilizzato. Non credo che si voglia mettere in campo gli amministratori con i loro blocchi per irregimentare queste cose. Se non esiste alcuna probabilità che un comportamento venga sanzionato con un blocco, allora è sciocco vietare quel comportamento. Ora, nessun amministratore bloccherebbe mai qualcuno per una cosa del genere, quindi è assurdo istituire obblighi di sorta. pequod76^talk 04:19, 26 gen 2015 (CET)

Con l'avvento dell'interfaccia Flow nelle discussioni si potrà seguire una discussione specifica in una pagina, per cui in tal caso sarà molto più comodo continuare le discussioni nella stessa pagina dove sono state aperte. Adesso invece, per seguire la discussione nella pagina di un utente devo seguirmi anche tutte le altre discussioni che questo utente ha con altri utenti. Spero dunque che i programmatori si adoperino per introdurre al più presto la nuova interfaccia per le discussioni. Nel frattempo, per questi 1-2 anni che ci separano dall'avvento di Flow, possiamo continuare a usare i metodi tradizionali o il sistema qui proposto con il ping: mi sembrano entrambi buoni. --Daniele Pugliesi (msg) 21:21, 25 gen 2015 (CET)

Incidentalmente ho notato che ogni tanto il ping non mi arriva, inoltre se il mio interlocutore oppure il sottoscritto per qualche giorno e' lontano dalla tastiera al rientro avendo le risposte nella mia talk vedo immediatamente dove ho discussione, viceversa tra i messaggi in cui mi si avvisa di essere citato, mi si avvisa di variazioni nelle voci, ringraziamenti vari e' molto facile che mi sfugga un ping a cui rispondere, anche per il motivo che wiki non e' un social, per cui controllare le bandierine in alto a destra non e' la prima priorità. --Bramfab Discorriamo 08:58, 26 gen 2015 (CET)

Quoto Bramfab ed Emanuele; sono più comodo anch'io con il vecchio sistema, le discussioni sono più facilmente tracciabili e sono meglio segnalate. --Syrio posso aiutare? 09:12, 26 gen 2015 (CET)

Il vecchio sistema è certamente pessimo ed è il peggiore obbrobrio di wikipedia: credo sia stata per me la cosa più difficile da capire. Al momento il suo uso ha come unico vantaggio il sistema di alert: è difficile perdersi un messaggio scritto nella propria talk; per il resto presente lo svantaggio di rendere impossibile una discussione in cui sono coinvolti più di due utenti e rende molto difficile la ricostruzione di un dibattito.

Che io sappia, a parte i problemi tecnici, non è obbligatorio avere la notifica in caso di ping: nell'attesa dell'arrivo di Flow si potrebbe verificare se è possibile tecnicamente rendere obbligatoria e automatica la notifica al ping, in modo che abbia lo stesso effetto di un messaggio lasciato in talk utente, così da abbandonare il sistema attuale. --Cpaolo79 (msg) 11:30, 26 gen 2015 (CET)

Le discussioni che coinvolgono almeno tre utenti sono discussioni tipiche su argomenti di voci e sarebbe più opportuno che vengano svolte nelle pagine di discussione delle voci, anzi sarebbero obbligatoriamente da dirottare in quelle pagine di discussione. Incidentalmente e' già difficile far capire ai nuovi arrivati la necessita' di firmarsi nelle comunicazioni, figuriamoci se dobbiamo spiegare loro di usare la template ping e come capire quale sia il nome dell'utente da pingare, quando molti utenti hanno una firma che neppure coincide col loro nome utente, oppure hanno un nome utente complicato da scrivere quanto quello di Ramsete in geroglifico.

Forse sarebbe anche il caso di ripensare a cosa significa scrivere al di fuori di ns0 in wikipedia, le pagine extra ns0 sono pagine di servizio, le discussioni su argomenti che interessano più utenti sono discussioni tipiche delle pagine di discussione di progetti, di voci, di wikipedia, di mediawiki. Le pagine di discussione utenti servono per comunicazioni rapide da un utente ad un altro utente, se qualcuno vuole comunicare con me mi aspetto che scriva nella mia talk, come nella RL mi aspetto che mi telefoni o che mi mandi una email oppure un SMS.

Non controllerò certamente che si accenda un piccolo punto rosso (sia nella RL o in wiki) da cui dovrei scoprire che Caio ha qualcosa da dirmi o perfino che mi ha scritto qualcosa da qualche parte, il principio della comunicazione e' che chi vuol comunicare si deve prendere carico di far arrivare il suo messaggio...

Infine considerato che ognuno gestisce l'archivio delle sue talk come vuole, nonostante ci siano norme a riguardo, voglio poter gestire e conservare personalmente tutto quello che mi viene scritto direttamente, cosa che posso fare se ho le risposte nella mia talk.--Bramfab Discorriamo 12:21, 26 gen 2015 (CET)

Nella pratica, anche se raramente, può capitare che una discussione tra due utenti vede l'intervento di un terzo.

Per i nuovi arrivati, è davvero complicato capire che se io scrivo nella loro talk allora loro devono rispondere nella mia: d'altro canto è abbastanza controintuitivo, forse siamo l'unico sito al mondo dove una discussione, anziché essere raggruppata, è esplosa tra più pagine (non ti dico quando uno dei due utenti ha archiviato la propria talk!). Quanto alle firme fantasiose, proposi tempo fa di proibire del tutto la personalizzazione: ognuno deve usare solo ed esclusivamente il nome corretto, senza ricorrere a fantasie che danno molti problemi (accessibilità, comprensibilità, peso in byte, possibili insofferenze da parte degli utenti...).

Le discussioni andrebbero seriamente ripensate: da sempre sono l'aspetto più problematico di mediawiki; di recente è stato segnalato come sia semanticamente improprio il fatto che queste siano renderizzate dal software come dei "dd". Gli esempi di email e SMS sono impropri in quanto riguardano la comunicazione privata: i messaggi in talk sono invece pubblici; del resto la proposta di pequod riguarda solo le risposte, il primo messaggio andrà sempre scritto nella talk dell'utente da contattare: per questo il resto dell'obiezione ha poco senso.

Quanto al "piccolo punto rosso" è già da oggi molto evidente (è nell'angolo in alto a destra) e proponevo, appunto, di rendere l'alert più evidente, in stile messaggio in talk.

Infine, se qualcuno ti scrive, questo metodo suggerito non solo non cambia nulla, ma migliora l'esistente perché conserverai anche le tue risposte; per le discussioni iniziate da te, basterà usare il "puntano qui", usando il ns corretto. --Cpaolo79 (msg) 13:04, 26 gen 2015 (CET)

Permettimi di contraddirti sui nuovi arrivati: avendoci avuto molto a che fare, non ricordo casi in cui, dopo aver spiegato come funzionano le talk, la cosa non sia stata compresa (e perché dovrebbe, poi? È un concetto banalissimo! Come le lettere, né più né meno). E i "puntano qui" non sono neanche lontanamente comodi per la consultazione come avere un archivio col vecchio metodo. Di fatto, scrivere tutto nella pagina utente di uno solo comporta la totale dispersione delle discussioni, perché a parte tu non sai più dove e quando hai scritto una data cosa (a parte per le discussioni iniziate da altri, ma a quel punto sono loro che non sanno più dove stanno). --Syrio posso aiutare? 13:13, 26 gen 2015 (CET)

Il punto rosso non e' evidente affatto, solitamente mi trovo a meta' scroll dello schermo, pur usando un monitor più' grande un foglio A3. Sulla differenza fra SMS e lettere da una parte e messaggi in talk il fatto che gli uni siano pubblici e gli altri privati cambia poco la sostanza: se scrivo in una talk di un utente e' perché' voglio comunicare qualcosa a quell'utente, (con al 80% buoan pace di chi si inserisce sucessivamente nel dialogo). Credo che il succo sia che le discussioni sono quelle che devono avvenire nelle pagine delle voci o altre pagine comunitarie e vengono archiviate assieme, come avviene in tutti i siti internettiani. Tutti i siti internettiani piu' avanzati hanno anche la possibilità per gli utenti iscritti di scambiarsi messaggi fra di loro senza intasare le pagine comunitarie (solitamente indicate come pagine di forum). La macedonia o insalata russa la trovi nei cosiddetti social, dove la caciarra alla fine la fa da padrona. --Bramfab Discorriamo 13:34, 26 gen 2015 (CET)

Perdonami, penso di non aver capito allora di che punto rosso stai parlando: a me si trova nell'angolo in alto a destra, come su Facebook.

La distinzione tra sms e messaggi in talk sta proprio nella differenza tra pubblico e privato: su Facebook posso scrivere sulla tua bacheca, ma in questo caso il messaggio è pubblico e chiunque può intervenire e la tua risposta rimarrà sulla tua bacheca e non sulla mia; in alternativa esistono i messaggi privati che equivalgono a scambiarsi una mail qui.

[@ Syrio] probabilmente sono stato particolarmente sfortunato: ho l'abitudine, quando scrivo ad un nuovo arrivato, di mettere la sua talk negli OS: il 90% delle volte la risposta la vedo nella sua talk. Personalmente, più che il "puntano qui", ancora oggi vado a vedere i miei contributi nel ns3. --Cpaolo79 (msg) 13:42, 26 gen 2015 (CET)

Sì, questo lo faccio anch'io; in molti casi non spiego esplicitamente la faccenda della talk ai neoutenti a cui faccio da tutor (specie se li vedo particolarmente impacciati - non perché penso che non capirebbero, ma perché non mi sembra il caso di aggiungere ulteriori istruzioni); nei casi in cui lo faccio, di solito viene compresa. --Syrio posso aiutare? 13:56, 26 gen 2015 (CET)

Tu hai l'opzione che la barra scende, mentre lui no. --Emanuele676 (msg) 13:59, 26 gen 2015 (CET)

E' vero che formalmente: "chiunque può intervenire", ma dato che siamo qui per scrivere un enciclopedia, e non per fare socialite, e' il caso sia di scoraggiare il chiunque a intervenire tanto per intervenire in un discorso a due, e sia di scoraggiare ad usare talk di utenti per discutere di tematiche a respiro comunitario, perché se e' un discorso o una discussione a piu' ampio respiro la pagina di discussione non e' quella utente.--Bramfab Discorriamo 14:36, 26 gen 2015 (CET)

Il problema imho è che entrambi i metodi di comunicazione non sono perfetti: quello attuale è antintuitivo per i nuovi utenti, mentre il metodo "ping" ha il problema che non si ha un archivio con tutte le discussioni affrontate, che almeno anche per me è importante anche se non fondamentale. Tuttavia a me sembra che il metodo che abbiamo ora venga imparato abbastanza in fretta dopo le prime perplessità, mentre dover costringere gli utenti ad imparare anche l'uso di un template, seppur molto semplice, rischia di dare più problemi, considerando anche la questione delle firme che non rispecchiano il nome reale dell'utente. In conclusione dunque ritengo che sia meglio restare con le cose come stanno. Comunque a me la notifica risulta sufficientemente evidente, e quindi non ho problemi nel notarla, ma faccio notare invece che molti utenti, io compreso, segnalano che piuttosto frequentemente il ping non "arriva". --Fullerene (msg) 13:30, 27 gen 2015 (CET)

Credo che nessuno abbia ancora fatto notare che le notifiche per i ping si possono disattivare e non c'è modo di sapere se il nostro interlocutore ha sfruttato questa possibilità. Detto ciò, a me sembra che qui la guerra di religione sia più infervorata che mai e che nessuno dei "terribili paradossi" (che alcuni evocano immaginando lo scontro delle due culture) sia veramente un problema concreto. Nella pratica io non ho mai avuto problemi a comunicare con gli utenti dell'uno e dell'altro "tipo", nemmeno quando questi si incrociavano in una discussione a tre in talk utente. La verità è che la prassi è complicata e che non c'è una vera regola, ma si procede a occhio. Io sarei, con buona pace di chi lo odia, per presentare il vecchio metodo come principale (perché buona parte di noi lo usa ed è bene che i nabbi capiscano come funziona, anche se magari lo useranno poco) e addolcire la descrizione del metodo alternativo, con l'importante aggiunta che non è detto che il ping funzioni. Allo stato, in effetti, il vecchio metodo è l'unico che assicura al mittente la comparsa di una notifica "attiva" (gli osservati speciali non sono altrettanto affidabili, per quanto mi riguarda), e siccome lo scopo è l'affidabilità delle comunicazioni credo sia opportuno quanto meno familiarizzare i nuovi utenti con il metodo più sicuro e presentarglielo come tale. --Dry Martini confidati col barista 11:18, 2 ago 2015 (CEST)

(Fuori tema, ma non troppo) Io continuo a chiedermi come mai dovremmo investire così tante risorse per conversare fra noi o a proposito dei nostri articoli usando pagine wiki. Non ci credo che non ci sia plugin Mediawiki con linguaggio wiki. --SoujaK ✍ 05:01, 3 ago 2015 (CEST)

Perché in origine era probabilmente la cosa più semplice (visto che all'epoca il linguaggio wiki probabilmente era considerato "quello semplice", confrontato con l'unico concorrente dell'epoca, cioè l'html) da implementare: un unico sistema per scrivere ovunque, col vantaggio di poter inserire nelle discussioni qualunque elemento grafico. Il problema dovrebbe risolversi con l'arrivo di Flow, un plugin per gestire le discussioni e le relative notifiche. --Dry Martini confidati col barista 08:09, 3 ago 2015 (CEST)

redirect da sotto-sottopagine di discussione

Vi porrei una riflessione su un "problema" non urgente.

Dopo aver fatto questo intervento, ho realizzato che ho visto nei giorni scorsi casi come questo di pagine dove non interviene nessuno da anni mentre magari gli stessi argomenti si dibattono con più successo alla discussione dei progetti vera e propria... e che in passato dopo aver impostato direttamente in alcune talk redirect verso livelli di pagine di discussione "superiori", ho avuto anche l'approvazione di altri utenti. Altri casi di trasformazione in redirect di pagine anche "frequentate" ci sono stati con esplicito consenso in questi anni.

Alla luce di questa esperienza mi chiedo se non sia il caso di iniziare a "formalizzare" da qualche parte che forse per pagine di discussione di sotto-pagine sarebbe da valutare seriamente per chi le crea se un redirect a una pagina di discussione di ordine generale non sia opportuno fin dall'inizio. Non pretendo un obbligo ma che utenti esperti inizino a farci attenzione. Credo che non ci sia alcun giovamento dalla frammentazione di discussioni soprattutto da parte di utenti meno esperti in livelli secondari su cui non passa mai nessuno. Un po' di accortezza e educazione civica in merito mi sembra si possa in qualche modo stimolare.

In particolare, se possibile, chiederei un EGO di pagine di discussione di sottopagine di servizio che non esistono e di quelle che sono non editate da anni per procedere a inserire qualche redirect opportuno. O magari, se preferite, facciamo un bel festival di ripulitura di questi livelli che sono chiaramente in semiabbandono, e valutiamo caso per caso quali "redirectare" alla luce degli ultimi anni.--Alexmar983 (msg) 18:12, 22 ago 2015 (CEST)

Va fatta un'analisi caso per caso, perché ovviamente alcune talk di sottopagine sono necessarie. Però il problema esiste e ogniqualvolta ho potuto, ho orientato la cosa nel senso del redirect alla talk principale, in qualche caso (se ricordo bene) con avviso tipum soft redirect. pequod76^talk 02:19, 23 ago 2015 (CEST)

Io vorrei solo che la maggioranza degli utenti esperti imparasse che l'analisi caso per caso fosse fatta fin da subito dalla creazione della sottopagina. Cioè di non preoccuparsene dopo qualche anno a seconda di come va... e quindi un minimo accenno al problema, due righe, in questa pagina andrebbe messo. Sono apertissimo alla forma e alla posizione in cui inserirlo.--Alexmar983 (msg) 02:25, 23 ago 2015 (CEST)

Ok per me. Vediamo che dicono gli altri. pequod76^talk 02:26, 23 ago 2015 (CEST)

prima di linkare al bar vorrei fare un confronto su qualche dettaglio. Si potrebbe mettere in "Mettere le discussioni al posto giusto: la cambusa". Cambiare titolo in "mettere le discussioni al posto giusto" e poi creare due sezioni "cambusa" e "redirect verso pagine di discussione". In questo seconda sezione specificare una cosa come è consentito che una pagina di discussione sia redirect a un'altra pagina di discussione. Questo può avvenire come prodotto di uno spostamento del nome della pagina associata alla pagina di discussione, ma anche come scelta specifica di chi ha creato la pagina a cui la pagine di discussione è associata. Qui però mi fermo un attimo, anzitutto c'è una ltro modo cn cui chiamare la "pagina associata alla pagina di discussione"? E inotlre qualcuno sa in gergo tecnico wikipediano come si chiama la "sottopagina" che si crea con la "/" e in che pagina di aiuto sono descritte le modalità del suo utilizzo? Grazie.--Alexmar983 (msg) 01:50, 24 ago 2015 (CEST)

come esempi metterei una sottopagina della forma "progetto:X/Y", è il caso più frequente che penso sia utilissimo ridurre come uso.--Alexmar983 (msg) 01:51, 24 ago 2015 (CEST)

per pagine che hanno testo per avvisi inevitabili (ScroporoUnione, esempio Discussioni Wikipedia:Confronto tra voci di qualità e voci in vetrina) o hanno bisogno di uno smistamento, suggerirei la crazione di header quale ad esempio Discussioni aiuto:Content Translation/Header--Alexmar983 (msg) 13:03, 24 ago 2015 (CEST)

Favorevole in toto alla proposta di [@ Alexmar983]. Oltre a questa linea guida inserirei un suggerimento anche in Aiuto:Sottopagina, però eviterei di fare cenno degli spostamenti e di limitarne l'uso ai namespace che non siano 1, 11 e 15 per lo stesso motivo per il quale si sta discutendo qui, scrivendo ad esempio:

Nei namespace che non siano 1, 11 e 15, è consentito avere una pagina di discussione che sia un redirect ad un'altra pagina di discussione, quando vi è l'utilità di convergere le discussioni in un'unica pagina. Ad esempio...

Per l'EGO invece non saprei come fare per averne uno esauriente, perchè oltre alle pagine di discussione già create ci sono anche quelle che ancora non esistono e per le quali sarebbe bene inserire il redirect preventivamente: un elenco completo sarebbe quello di tutte le sottopagine, ma ovviamente sarebbe ingestibile. --Fullerene (msg) 19:36, 8 set 2015 (CEST)

Segnalo che la questione dei redirect nei namespace 1, 11 e 15 ora si è sbloccata, perciò ho rivisto le linee guida inerenti[1][2], le quali eventualmente andrebbero integrate con quanto proposto in questa discussione. [@ Alexmar983, Pequod76] la segnalazione al bar generale poi era stata fatta? --Fullerene (msg) 04:13, 26 nov 2015 (CET)

No Fullerene ma che tu ci creda o no pensavo proprio ieri di farla a breve. Se la vuoi fare te tanto meglio, io da oggi pomeriggio a domemica pomeriggio sono sicuramente poco attivo su wiki, ma tornerei in tempo per leggere altri pareri.--Alexmar983 (msg) 11:11, 26 nov 2015 (CET)

[@ Alexmar983] ti aspetto, non c'è mica fretta ;) --Fullerene (msg) 15:27, 26 nov 2015 (CET)

Centralizzare le discussioni è utile nel momento in cui si aprono le discussioni poiché in questo modo si ha un maggior numero di partecipanti, ma d'altra parte richiede uno sforzo maggiore nel ricercare le vecchie discussioni. A tale proposito, penso che siano utili i redirect proposti, ma allo stesso tempo ci vorrebbe un metodo di archiviazione delle vecchie discussioni più efficace, in modo che se uno cerca una vecchia discussione ad un bar tematico o al bar generale su una specifica questione possa rintracciarla subito. Le cose si fanno ancora più complicate quando le discussioni si chiudono e poi se ne riaprono di nuove senza sapere che già c'era stata una discussione simile.
Da questo punto di vista, mi piace il metodo utilizzato dal sito "Yahoo Answer": ogni volta che si apre una nuova discussione su quel sito, il motore di ricerca mostra una lista di discussioni che potrebbero essere pertinenti al titolo della discussione che si sta proponendo. Una cosa del genere fatta per i bar tematici di Wikipedia faciliterebbe la ricerca di vecchie discussioni. Immagino le complicazioni di natura tecnica, ma se si potesse fare per me sarebbe formidabile! --Daniele Pugliesi (msg) 14:26, 19 dic 2015 (CET)

Visto il consenso ho integrato le linee guida inerenti[3][4][5]: controllate se possa andare. --Fullerene (msg) 21:03, 29 dic 2015 (CET)

Riutilizzo del tmp:progetto nelle pagina di discussione delle voci

Segnalo Discussioni_progetto:Coordinamento/Progetti#Riutilizzo del tmp:progetto in ns1. --62.19.51.99 (msg) 02:03, 29 gen 2016 (CET)

che riguarda come indicare a quali progetti / bar tematici segnalare una discussione. --62.19.50.184 (msg) 12:08, 30 gen 2016 (CET)

Linea guida omogenea sulle archiviazioni

cb La discussione proviene dalla pagina Discussioni progetto:Coordinamento#Linea_guida_omogenea_sulle_archiviazioni.
– Il cambusiere -- Helichrysum Italicum ^{(chiamami "Heli")} 20:58, 6 mar 2016 (CET)

Dopo aver visto che la votazione di Utente:Epìdosis è finita arhiviata nel secondo semestre del 2015 mentre l'anno scorso Utente:MapiVanPelt finì nel primo del 2015 pur essendo entrambe iniziate a dicembre e finite a gennaio, riprendo in mano una discussione già avuta mesi fa qui con Utente:Er Cicero.

Il problema è che manca totalmente coordinazione sulle archiviazioni. Come dimostra la modifica di qualche settimana fa con Utente:Fullerene e Utente:pequod76 per evitare la frammentazione di pagine di discussioni, più aumenta la nostra complessità, più è essenziale tenere ordinati gli archivi e le pagine di discussione e coordinamento. Purtroppo mi sono scontrato spesso con la sensazione che si tenda minimizzare e dire che è tutto "semplice" o "chiaro" che sono solo "dettagli risolvibili" o cose simili ma scondo me non è così. Si possono trovare esempi di ogni tipo, oltre che violazioni dei suddetti esempi. Francamente penso che una semplice linea guida generale che faccia meglio il punto della situazione aiuterebbe non poco. Così ogni volta che si crea un nuovo archivio abbiamo un'indicazione derivante dall'esperienza pregressa su come impostarlo.

Il punto è che le modalità di archiviazione sono basate sulla crono di inizio, di fine e temo alcune se si cerca bene, anche su ordine alfabetico. Almeno sapere quali modalità esistono e la necessità di essere consistenti con esse e di riportarle chiaramente come istruzioni mi sembra il minimo. Anche perché alcune forme di archiviazione semiautomatica sono allo studio, ma penso valgano solo con alcune modalità.

Specificare che le modalità di archiviazione dovrebbe essere chiaramente indicate è il minimo, ma secondo me ci vuole uno schema generale che suggerisca salvo eccezioni motivate p.e. che ogni procedura collettiva dovrebbe archiviarsi per esempio alla data di conclusione mentre ogni discussione in talk progetto e utente alla data di inizio. Il che non implica che non ci possano essere eccezioni (e poi la rgola in sè può essere qualunque...) ma appunto che alcune devono essere viste come eccezioni e specificate come tali. Se ognuno inizia a fissare uno standard diverso e non lo scrive, poi cambiando utenti che se ne occupano le archiviazioni rishciano di cambiar a loro volta in corso d'opera, magari dopo una pausa. Eppure con un minimo di coordinazione derivante da una media dei casi in esame finora, questo problema non si avrebbe.

In ogni caso Aiuto:Cronologia#Archivi è abbastanza minimale e bisognerebbe dire di più. Alcuni elementi mancano in Aiuto:Pagina_di_discussione#Archiviare_le_discussioni.--Alexmar983 (msg) 12:32, 9 gen 2016 (CET) Come sempre prima segnalo alle pagine di coordinamento più intressate, poi si passa al bar.

Anch'io penso come te che il problema non sia gigantesco, ma che venga sistematicamente ignorato, tanto che non abbiamo uno standard di archiviazione delle discussioni, con il risultato che ciascun progetto archivia con titoli diversi. Il tutto risulta impredicibile e questo non è certamente un bene. IMHO il miglior standard, da adottare in tutti i casi, è archiviare per data di inizio della procedura o della discussione. È un metodo facile da ricordare, tanto è convenzionale: imho non vale la pena differenziare per tipologia d'archivio. Quanto al formato, un archivio discussioni dovrebbe avere un formato standard di questo tipo: discussioni progetto:NomeProgetto/Archivio/01. "/Archivio" conterrà {{archivio}}, mentre il titolo "/Archivio/01" invece che "Archivio01" o peggio "Archivio1" permette di utilizzare i link a sottopagine che il sistema automaticamente offre appena sotto al titolo e di ottenere un ordine alfabetico (che irrimediabilmente si rompe tra "1" e "10" ma non tra "01" e "10". In qualche caso, via bot, sarà necessario spostare da "01" a "001". Invito Giaccai a dirci cosa ne pensa, forte della sua sensibilità archivistica. Comunque, Favorevole ad ottenere uno standard: non obbligatorio, nel senso che non è un delitto archiviare altrimenti, ma almeno non si verrà a dire che usare un bot per correggere tutti gli archivi secondo lo standard individuato è una perdita di tempo. L'importante è affermare l'esigenza e l'importanza di tenere una linea uniforme e predicibile. pqd...Ƿƿ 12:54, 9 gen 2016 (CET)

Grazie Utente:Pequod76 per la chiamata in causa. Dal mio punto di vista l'esigenza di avere una struttura organizzata dell'archivio delle discussioni è fortissima; perchè o si stabilisce che che le regole sono solo quelle di cui ha memoria il tuo interlocutore o è necessario rendere accessibile facilmente le discussioni archiviate; discussioni che si auspica abbiano sempre un paragrafo conclusivo con indicate con chiarezza le conclusioni ;-). E dato che il mestiere dei bibliotecari è quello di dare un ordine ai libri per favorirne l'accesso, penso sarebbe anche possibile attivare un piccolo gruppo di bibliotecari che periodicamente catalogano le discussioni e le indicizzano, cioè costruiscono un indice coerente. Sarebbe però necessario avere un template che visualizzi la lista delle discussioni e renda semplice attribuire a ciascuna una categoria. Se vi pare una attività troppo invasiva, lo posso capire. Quanto al nome dell'archivio la proposta Archivio/01 mi pare la più logica. --Susanna Giaccai (msg) 13:16, 9 gen 2016 (CET)

Favorevole a qualunque iniziativa vogliate prendere per in questa direzione, non vedo perchè dovrebbe essere una attività percepita come invasiva. -- Helichrysum Italicum ^{(chiamami "Heli")} 13:43, 9 gen 2016 (CET)

molto semplicemente, fra le operazioni di manutenzione le archiviazioni (in generale) non sono mai state così avvincenti da veder litigare utenti che se le contendessero... In pratica, essendo un lavoro svolto da pochi benemeriti, il succo era "grazie che l'hai fatto, non ci speravamo, come l'hai fatto l'hai fatto, se non lo facevi pazienza". Se riesco a rendere l'idea, il disordine nasce da questa impostazione sostanzialmente "irregolare" (nel senso che non c'era alcuna sorta di regolarità di esecuzione prevedibile). Questo comporta che in diversi settori del sito ci si comporta diversamente o, come nell'esempio fatto da Alexmar, ci sono soluzioni diverse agli stessi problemi. Sicuramente un'indicazione di massima si rende necessaria. Ma dobbiamo anche tenere presente che abbiamo discussioni (ma il problema non riguarda affatto solo le discussioni, anzi) abbastanza eterogenee, da archiviare, e che è forte il rischio che non tutto vada bene per tutti i casi. Arrivo qui da un link in talk di UP, dove a suo tempo si stabilirono dei punti necessari per l'archiviazione, soprattutto in termini di tempi minimi prima dell'archiviazione; ebbene, non credo che possa essere lo stesso per procedure di elezioni, richieste agli amministratori, o altro, e questo per il contenuto di ciò che si deve archiviare e i suoi effetti su ciò che resta online. Manca una logica comune ("Archivio/01" e la facilità di sottopaginazione automatica sono una linea per me validissima) e l'archiviazione delle talk utente mi pare indicare una certa fantasiosità generale nell'approccio al tipo di azione. Proviamo, a mio vedere dovrebbe essere opportuno, a fare intanto il quadro delle specificità: ci sono tipi di archiviazione differenti o con specifiche connesse problematiche? Intanto inquadriamoli. Dopodiché, vediamo se è possibile effettivamente organizzare anche una sorta di regolarizzazione delle attività. Ecco, il "paragrafo conclusivo con la sintesi delle discussioni" lo vedo con il naso forse un po' prematuro: è sufficiente archiviare correttamente, seguendo ordini non solo quantitativi o cronologici ma anche di contenuto delle singole discussioni, e poi rendere ben raggiungibili le sottopagine. Non solo non tutte le discussioni hanno un esito conclusivo (tutto è sempre in fieri per definizione, qui dentro), ma la sintesi dell'altrui espressione nel nostro ambiente è sempre sottilmente tangente l'orlo della suscettibilità di quello sintetizzato (e non faccio satira, ho in mente infiniti esempi), quindi lascerei ad una specifica discussione separata questo punto. Ma per il resto concordo, stabiliamo come muoverci -- g · ℵ (msg) 17:49, 9 gen 2016 (CET)

Sul discorso dei benemeriti siamo d'accordo. L'intento infatti non è quello di tirare le orecchie a qualcuno o di dire "o fai così o è meglio che non fai". Piuttosto, è quello di dire "grazie di aver archiviato: prima o poi qualcuno la farà completa e sistemerà secondo lo standar che puoi vedere qui. Certo che se uno è un cambusiere fisso e ignora scientemente lo standard, una tiratina d'orecchie inizia a starci! :D

Per me sarebbe già importante fissare lo standard delle talk, sia talk voce che talk progetto (o policy o pagina di aiuto o tmp ecc.). A parte il formato che ho suggerito e già descritto, imvho l'unico veramente sostenibile da un pdv razionale (a meno che l'ordine alfabetico non divenga anch'esso materia di opinioni), per quanto riguarda la tempistica opterei per un approccio generale da adottare cum grano salis. Provo a descriverlo:

• Tendere a lasciare nella pagina le discussioni del mese corrente (ovviamente) e del mese precedente.
• Nel caso al mese precedente siano partite delle discussioni ancora in corso, lasciare ovviamente che esse procedano nella pagina, senza archiviare.
• No ad archiviazioni selettive (tipum per questione risolta): non fanno che incasinare l'ordine naturale delle cose, appunto perché WP è un WIP e quindi ciò che è ritenuto risolto da qualcuno è bene che stia un certo tempo a disposizione di chi potrebbe vederci dei problemi. Senza contare che, con l'archiviazione a base cronologica, la disponibilità dei testi è sempre più chiara e lineare: le discussioni possono essere rilinkate soprattutto quando conquistano il loro "posto fisso": quando cioè vengono archiviate! Quando invece si linka ad una discussione magari già vecchia ma non ancora archiviata, il link è fragile e suscettibile di rompersi. Ovviamente una discussione di meno di 60 giorni fa non può essere considerata "vecchia".
• Considerare l'ipotesi di archiviare a parte discussioni di particolare momento per una voce o per un progetto o per una policy o per una pagina di aiuto. Infatti, queste discussioni di particolare momento a) saranno presumibilmente lunghe e b) sarà bene che possano essere "viste" in archivio con una certa immediatezza.
• Quando una discussione, se anche in corso, è partita troppo in là, si consideri l'opportunità di sottopaginarla (evidentemente è una discussione che ha un certo rilievo) o, se ha avuto fasi di stanca, archiviarla e richiamarla tramite link. Evitare, quindi, di intervenire oggi in una discussione aperta ad ottobre 2015 solo perché non è stata ancora archiviata. Meglio archiviarla e riaprire la discussione, facendo riferimento alla vecchia discussione con un semplice link.
• Ovviamente il peso delle pagine è un parametro da considerare. Pagine troppo lunghe vanno ad un dato momento archiviate. Ma questo non significa che sia un bene NON archiviare thread del 2006 solo perché la talk è relativamente piccola. Ovviamente entro i 32kbyte non ne vale la pena, ma quando si va oltre (inutile indicare una soglia specifica, andiamoci a naso), archiviare serve, come detto sopra, a fissare un posto per quel testo. Consideriamo anche che molti wikipediani utilizzano ormai uno smartofono, se non per editare quanto meno per leggere le discussioni, magari in metro o in treno... Teniamoci quindi relativamente corti. E soprattutto, proposta che volevo fare da mo', inserire sistematicamente {{torna su}} in tutte le pagine di discussione. E magari anche uno speculare "tmp:vai giù". Infatti con gli smartofoni non si può premere CTRL+page up/down e la cosa è abbastanza fastidiosa. Ovviamente sto dando per scontato che molti di quelli che usano smartofono per consultare le discussioni lo facciano dalla versione desktop.

Come detto, i punti che ho snocciolato lasciano da parte l'archiviazione delle procedure, per rispondere all'opportuno invito di Gianfranco ad essere più specifici. Già definire uno standard per le archiviazioni dei ns dispari sarebbe un gran fatto. Ciauuu! pqd...Ƿƿ 14:46, 10 gen 2016 (CET)

Problema con il template Avviso archivio

Segnalo che il template {{avviso archivio}} soffre del problema .../Archivio1, .../Archivio2...con conseguenze spiacevoli e link rossi nel caso in cui l'archivio sia invece organizzato con 01, 02, ecc... come in questo esempio. -- Helichrysum Italicum ^{(chiamami "Heli")} 12:22, 11 gen 2016 (CET)

Nome standard per le sottopagine: scegliere

il papello di pequod mi sembra molto pertinente. Propongo di iniziare prima dalle questioni "teniche" e poi di passare alla "teoria dell'archiviazione". Cosa scegliamo? -- Helichrysum Italicum ^{(chiamami "Heli")} 16:33, 12 gen 2016 (CET)

1. ..../Archivio01 ; ..../Archivio02;
2. ..../Archivio e poi ..../Archivio/01 ; ..../Archivio/02 ;
3. (altro...?)

Come dicevo:

• /Archivio deve contenere {{archivio}}.
• I singoli archivi è utile che si chiamino "Archivio/01", in modo da sfruttare al meglio la funzionalità automatica del sistema. pqd...Ƿƿ 00:27, 29 gen 2016 (CET)

Possiamo adottare uno standard per gli archivi?

Viste le discussioni pregresse, pensavo fosse ora di adottare uno standard unico per gli archivi delle discussioni. Per questa pagina di aiuto avevo fatto quanto segue:

• Discussioni Aiuto:pagina di discussione

  Discussioni Aiuto:pagina di discussione/Archivio

  Discussioni Aiuto:pagina di discussione/Archivio/01

  Discussioni Aiuto:pagina di discussione/Archivio/02

  Discussioni Aiuto:pagina di discussione/Archivio/03

Ma mi accorgo con mio grande dispiacere che il template {{avviso archivio}} supporta solo le sottopagine del tipo "Archivio01" e non "Archivio/01".

Quindi, che vogliamo fare? Cerchiamo di andar per gradi, parliamo prima dei namespace di servizio, che proporrei di gestire tutti allo stesso modo: Wikipedia, Aiuto, Progetto. Che sistema vogliamo adottare? Le opzioni sono riassunte nella sezione precedente di questa discussione.

NB: Fanno ovviamente eccezione quelle pagine che hanno già un sistema di archiviazione per necessità indipendente (come la Vetrina).-- Helichrysum Italicum ^{(chiamami "Heli")} 22:38, 7 mar 2016 (CET)

Meglio Archivio01 senza ulteriori slash. Inoltre ricordo che itwiki ha un bot, che avevo configurato a marzo 2014, che è in grado di archiviare automaticamente le pagine, senza alcun intervento (vedi per esempio Speciale:Contributi/ItwikiBot). L'avevo già proposto per lo sportello informazioni a Discussioni_aiuto:Sportello_informazioni#Archiviazione_automatica ma probabilmente pochi lo conoscono. Risegnalo Utente:ItwikiBot/Archiver per chi vuole leggere come si configura per la propria pagina di discussione (inoltre prima o poi immagino che sarà anche disponibile mw:Extension:Flow). --Rotpunkt (msg) 23:07, 7 mar 2016 (CET)

quel bot è bellissimo! Sicuramente lo integrerò nella pagina, almeno con una segnalazione nella sezione "archiviare"! Aspetto altri pareri prima di fare la modifica. - Helichrysum Italicum ^{(chiamami "Heli")} 00:26, 8 mar 2016 (CET)

+1 alla proposta. --Epìdosis 07:16, 8 mar 2016 (CET)

Perché 01 senza slash? pqd...Ƿƿ 14:32, 8 mar 2016 (CET)

Come peq, e aggiungo: perché "01" e non "1"? --Horcrux_九十二 14:35, 8 mar 2016 (CET)

01 serve per l'ordine alfabetico quando hai decine di archivi (da 01 a 99). pqd...Ƿƿ 14:54, 8 mar 2016 (CET)

Eh ma quando si sfora il 99° (es Aiuto:Sportello informazioni)? Spostiamo tutte le sottopagine? L'ordinamento alfabetico dovrebbe essere effettuato tramite sortkey. --Horcrux_九十二 15:11, 8 mar 2016 (CET)

Come tutti sopra ma con un ordinamento che funzioni e sia scalabile--Pierpao.lo (listening) 15:16, 8 mar 2016 (CET)

ragazzi/e, cerchiamo di non complicarci la vita, io chiedevo come procedere per la norma e non guardando alle eccezioni. con "norma" intendo le normali discussioni di Pagine di Aiuto, Progetti, e pagine di Wikipedia "normali" (come Wikipedia:Progetto etc.). Pagine "speciali" come Oracolo, Sportello informazioni, Vetrina etc. possono eventualmente esser gestite in altro modo. -- Helichrysum Italicum ^{(chiamami "Heli")} 16:03, 8 mar 2016 (CET)

Anche io vorrei capire perché da alcuni sia preferito Archivio01 ad Archivio/01 Quest'ultimo secondo me avrebbe il vantaggio di raggruppare meglio le varie sottopagine, qualora vi fossero anche sottopagine di altro tipo.( È anche vero che nei risultati di pagine come Indice delle pagine per lettere iniziali o nelle categorie (anche senza ricorrere a ordinamenti esplicitamente impostati) sarebbero comunque elencati tutti assieme, difficile che altre sottopagine si mettano in mezzo all'ordinamento alfabetico.) Inoltre da Archivio/01 è più facile risalire a Archivio (contenente gli indici dell'archivio).

Che ci sia già un bot che faccia così per archiviazioni automatiche (automatismo su cui ho delle perplessità, già manualmente finiscono in archivio discussioni che dovrebbero continuare), non vuol dire che debba per forza far così, si potrebbe viceversa modificare il bot.--5.170.9.127 (msg) 17:25, 8 mar 2016 (CET)

Il caso delle discussioni delle voci è così differente da doversi trattare a parte?

[↓↑ fuori crono] @5.170....il bot archivia così di default ma può essere personalizzato con il nome desiderato per la sottopagina di archiviazione (se ho capito bene le istruzioni) -- Helichrysum Italicum ^{(chiamami "Heli")} 19:40, 8 mar 2016 (CET)

Condivido il pensiero espresso dall'IP sull'utilizzo della forma "Archivio/01". Da valutare magari se non sia il caso di trasformarlo in "Archivio/001" in modo tale che lo standard possa andare bene per qualsiasi pagina di WKP, incluse le pagine speciali (così avremmo a disposizione ben 999 pagine di archivio, credo proprio che ci possano bastare!). -- Gi87 (msg) 17:32, 8 mar 2016 (CET)

Io eviterei 001, quanto meno perché L'ordinamento alfabetico dovrebbe essere effettuato tramite sortkey. Lascerei 01 come standard, di modo che anche in assenza di sortkey la cosa funzioni cmq da sé. Però vorrei capire perché Rotpunkt dice che è meglio senza slash. Io l'ho trovato sempre migliore come standard perché si accorda meglio con il sistema mediawiki. pqd...Ƿƿ 01:18, 10 mar 2016 (CET)

[← Rientro] Allora, ci sono tante cose da dire. Innanzitutto io fino a tre giorni fa non ho mai neppure saputo che esistesse una pagina, questa, dove si parlava di nomenclatura delle pagine di archiviazione. Sinceramente non ci vedo troppa importanza, ci sono casi dove può essere più utile farlo per data, altri numericamente, altri in un modo, altri diversamente. Alla domanda secca "meglio Archivio01 o Archivio/01" senza andare a leggere tutto il pregresso ho risposto Archivio01, perché non vedo l'esigenza di isolare gli archivi in una ulteriore directory /Archivio/ quando nel namespace discussione non ci sono altro che archivi. Se vado a vedere cosa fa il bot archiviatore di enwiki en:User:ClueBot III mi consolo perché vedo che in generale fa proprio così: esempio e esempio. Poi ci sono casi in cui archivia per anno e con lo slash esempio, ma appunto io lascerei un po' di libertà. Piuttosto avrei da tempo automatizzato tutta l'archiviazione di tutti i progetti e delle pagine di discussione più usate, in modo da non pensarci più, che poi ci sia o meno uno slash o uno zero per me è secondario. --Rotpunkt (msg) 01:45, 10 mar 2016 (CET)

[← Rientro] Butto la pietra nello stagno e prima di dire no vi prego di riflettere anche se effettivamente sarebbe una rivoluzione. A noi italiani è sconosciuto come ordinamento ma e molto effficace e infinito: se ordinassimo per data alla americana "Archvio AAAA-MM--GG (progressivo archivio)" o "Archvio/AAAA-MM--GG (progressivo archivio)"?--Pierpao.lo (listening) 08:01, 10 mar 2016 (CET)

Riscrittura della pagina

per rendere la pagina più accessibile, ho iniziato a fare alcune modifiche di stile. Vedi cronologia. -- Helichrysum Italicum ^{(chiamami "Heli")} 20:18, 6 mar 2016 (CET)

sto facendo modifiche intense al testo della pagina, ma i contenuti rimangono gli stessi (l'idea è di migliorarli e completarli, a dir la verità!) -- Helichrysum Italicum ^{(chiamami "Heli")} 20:39, 7 mar 2016 (CET)

ho completato buona parte della riscrittura della pagina (che riceve oltre 200 visite al giorno di media). Mancano gli elementi indicati in Discussioni_aiuto:Pagina_di_discussione/da_fare, tra i quali la sezione relativa agli archivi, che va chiarita alla luce di quanto verrà deciso qui sopra. -- Helichrysum Italicum ^{(chiamami "Heli")} 22:49, 7 mar 2016 (CET)

Ordine dei template di avviso per le voci

Da più parti viene l'esigenza di avere delle indicazioni sull'ordine in cui inserire i template di avviso nelle pagine di discussione delle voci. Segnalo che ho creato questa sottopagina temporanea in cui elaborare una linea guida in merito (niente di vincolante, ma ha senso anche avere un posto in cui si raccoglie "tutto il materiale" relativo ai template di avviso, per avere un colpo d'occhio). Controllate se ne manca qualcuno? grazie.

Per osservazioni, se ne discute qui (la sottopagina è temporanea, penso che le informazioni verranno integrate nel corpo della pagina di aiuto principale a discussione conclusa). -- Helichrysum Italicum ^{(chiamami "Heli")} 11:38, 13 mar 2016 (CET)

Segnalo questa vecchia discussione naufragata. --Epìdosis 06:55, 14 mar 2016 (CET)

Heli, quanta carne al fuoco tutta contemporaneamente... un po' dura in questo periodo a stare dietro a tutte le discussioni! Cmq mi ero messo anch'io a ragionare sui template che possano esserci in una pag. di disc. di una voce e sul loro ordine di apparizione, li avevo raccolti qui. Giusta l'idea di raggruppare i tmp per tipo, rivedrei però l'ordine di qualche tmp. Vorrei però rivedermi anche con calma la disc. precedente. PS: io credo invece che creare delle sottopagine per la pagina di aiuto vada bene altrimenti rischiamo di appensantirla troppo. Soprattutto userei le sottopagine per piazzarci gli esempi. -- Gi87 (msg) 09:32, 14 mar 2016 (CET)

Anche secondo me meglio una sottopagina apposita (anche perché la pagina generale è sulle pagine di discussione in generale, anche su quelle utenti), ovviamente un richiamo nella pagina generale ci può stare, anzi sarebbe ben utile. E, anche conseguentemente, di potrebbero raggruppare nella relativa pagina di discussione tutte le discussioni sull'ordine degli avvisi.

Poi guardo la discussione indicata da Epìdosis e la prova fatta da Gi87. Per questa nuova proposta di Helichrysum Italicum, sicuramente è da spostare {{ScorporoUnione}} dal gruppo "c) altre informazioni di servizi" a quello "b) informazioni relative al copyright e all'origine delle informazioni contenute nella voce". --5.170.13.204 (msg) 14:39, 14 mar 2016 (CET)

Concordo con il creare una nuova pagina di aiuto, trattandosi quello dei template di avviso un argomento slegato dalle discussioni vere e proprie, oltre ad essere rivolto a utenti più esperti. Riguardo all'ordine, suggerisco di mettere in cima gli avvisi che non verranno mai rimossi, quali il il template discussione, il monitoraggio, l'otrs, il tradotto da, lo scorporo-unione, seguiti dai template "temporanei", quali richiesta di immagini, promemoria, ecc. --Daniele Pugliesi (msg) 17:18, 14 mar 2016 (CET)

Per iniziare, concordo con le considerazioni espresse da Daniele sull'ordine, nonché sulla proposta - avanzata dall'IP - di spostamento del tmp "ScorporoUnione" nella cat. B. -- Gi87 (msg) 17:41, 14 mar 2016 (CET)

[@ Gi87] abbiamo duplicato il lavoro! senza saperlo ho iniziato a far la stessa cosa che avevi iniziato tu in bozza. se vuoi prova a integrare la tua bozza nella sottopagina. NB: l'importante è che la pagina sia organizzata razionalmente a seconda del tipo di informazioni e funzioni dei template stessi, non credo sia assolutamente impellente "regolamentare" l'ordine dei singoli template all'interno di ciascun sottogruppo. -- Helichrysum Italicum ^{(chiamami "Heli")} 00:24, 15 mar 2016 (CET)

[← Rientro] È stata un'occasione per ragionarci su. Tenendo in dovuta considerazione anche i pareri degli altri utenti, l'ordine del gruppo a e d va bene. Non va invece bene l'ordine del gruppo b e c che vanno invertiti (prima tmp fissi, poi quelli "mobili"). Faccio notare che poi ogni avviso ha un suo colore specifico secondo questa legenda.
Riassumendo, questo il nuovo ordine:

• a) informazioni preliminari
  • {{Discussione}}
  • {{Progetti interessati}}
  • {{Cronologia valutazioni}}
• b) ulteriori informazioni - origine dei contenuti presenti
  • {{Tradotto da}}
  • {{ScorporoUnione}}
  • {{Voce GLAM}}
  • {{Share Your Knowledge}}
  • {{Crediti}}
  • {{Attribuzione}}
  • {{Attribuzione MediaWiki}}
  • {{Pubblicato}}
• b bis) Altre info extra
  • {{Voce su un wikipediano}}
  • {{Avviso genere}}
• c) richieste
  • {{Promemoria}}
  • {{Richiesta immagini}}
• d) sempre per ultimo, prima dell'inizio delle discussioni:
  • {{Archivio}}

Rivedrei in un secondo momento i nomi dei gruppi. -- Gi87 (msg) 11:58, 15 mar 2016 (CET)

A quanto capisco, quel codice dei colori si riferisce agli avvisi temporanei nel corpo della voce, non credo c'entri con quello che stiamo facendo qui. Però costruire una pagina di aiuto che raccoglie i template avviso per il ns1 sarà anche una occasione per valutare se si può standardizzare l'aspetto grafico di alcuni di essi (come è stato fatto finora per {{promemoria}}, {{progetti interessati}}, {{cronologia valutazioni}}. PS: i nomi dei gruppi li ho messi solo per comodità organizzativa e per la leggibilità della pagina di aiuto, nient'altro. -- Helichrysum Italicum ^{(chiamami "Heli")} 13:01, 15 mar 2016 (CET)

A me sembra che gli avvisi temporanei, proprio perché rappresentano una richiesta, non vadano solo per questo "sottomessi". Al contrario. L'ordine che seguirei io è quindi: a) (come Gi87 et al., in testa); poi le richieste c); poi il gruppo b) (che anzi, nel riordino grafico, potrebbero essere sensibilmente rimpiccioliti, senza pregiudizio e nei limiti del riconoscimento dei contributi). Per la loro importanza (pur se relativa alla singola voce), metterei il gruppo b) bis direttamente dopo "a)"; l'archivio a chiusura (possibilmente - e a latere - con una modifica che eviti i conflitti che spesso tale tmp ha con l'indice/TOC).

Con tutto il rispetto dovuto per l'origine dei contenuti, sul piano operativo hanno poco o nulla di rilevante, per cui non è utile dare loro tutto questo spazio. Sono troppo cicciotti, andrebbero asciugati: distolgono l'attenzione da un'area squisitamente operativa: quali sono i progetti interessati/stato della voce; l'iter delle valutazioni/se è stata sottoposta a pdc e cosa è successo; se è stata scritta dal diretto interessato; l'uso del genere che il soggetto adotta per sé (controllo che sia così); promemoria su cose da fare; richiesta immagini. Che tutto ciò sia semiseppellito da notizie relative alla licenza mi pare dannoso. pqd...Ƿƿ 14:33, 15 mar 2016 (CET)

sono abbastanza d'accordo con quanto scrivi, e sosterrei anche io un ordine simile. Ricapitolo in una tabella le due opzioni secondo me in gioco (in verde le sezioni su cui mi pare si possa concordare).

Riassunto proposte

Proposte per l'ordine dei gruppi di template in testa alla talk voce

Info generali essenziali voce + extra {{Discussione}} {{Progetti interessati}} {{Cronologia valutazioni}} {{Voce su un wikipediano}} {{Avviso genere}} a seguire:
OPZIONE UNO	OPZIONE DUE
b) Ulteriori informazioni - Origine/provenienza dei contenuti presenti {{Tradotto da}} {{ScorporoUnione}} {{Voce GLAM}} {{Share Your Knowledge}} {{Crediti}} {{Attribuzione}} {{Attribuzione MediaWiki}} {{Pubblicato}} c) Indicazioni pratiche per stesura/miglioramento voce {{Promemoria}} {{Richiesta immagini}} {{Richiesta Wikipedia parlata}}	c) Indicazioni pratiche per stesura/miglioramento voce {{Promemoria}} {{Richiesta immagini}} {{Richiesta Wikipedia parlata}} b) Ulteriori informazioni - Origine/provenienza dei contenuti presenti {{Tradotto da}} {{ScorporoUnione}} {{Voce GLAM}} {{Share Your Knowledge}} {{Crediti}} {{Attribuzione}} {{Attribuzione MediaWiki}} {{Pubblicato}}
{{Archivio}}

Ovviamente se la comunità lo ritiene opportuno si può fare un lavoro di "restyling" dei template del gruppo "ulteriori informazioni", per renderli meno visivamente ingombranti. -- Helichrysum Italicum ^{(chiamami "Heli")} 15:29, 15 mar 2016 (CET)

Nella bozza della pagina di aiuto trovate le due versioni da mettere a confronto: vers. uno e vers. due. -- Gi87 (msg) 21:05, 15 mar 2016 (CET)

commenti

• +1 all'opzione due. -- Helichrysum Italicum ^{(chiamami "Heli")} 15:31, 15 mar 2016 (CET)
• Propenso alla vers. uno. Ho sempre pensato che gli avvisi del gruppo b "Ulteriori informazioni - Origine/provenienza dei contenuti presenti" fossero più da scheda "cronologia" che "discussione". Non potendoli però spostare, concordando che siano un gruppo un po' ingombrante ed aspettando che un giorno magari essi vengano inglobati in un unico tmp {{Cronologia voce}} (sulla falsariga del tmp "Cronologia valutazioni"), preferisco avere il gruppo c "Indicazioni pratiche per stesura/miglioramento voce" alla fine di tutto per un motivo molto semplice: su un gruppo nutrito di avvisi, mi cade l'occhio sui primi e sugli ultimi. Meglio averli quindi in prossimità della parte "operativa della pagina", la discussione. Mi riesce un po' difficile trovare una collocazione ideale per gli avvisi {{Voce su un wikipediano}} e {{Avviso genere}}, forse perché avvisi un po' sui generis e che non mi dicono proprio espressamente in che modo tenerne conto da un punto di vista pratico (testo migliorabile quindi). -- Gi87 (msg) 21:19, 15 mar 2016 (CET)
• favorevole alla versione uno: sia perché mi sembra più facile da leggere sia perché mettendo alla fine gli annunci temporanei non è vero che gli diamo meno risalto (come sostiene chi ha proposto la seconda opzione), anzi gliene diamo di più; infatti dalle nozioni sul bias sappiamo che gli elementi centrali di una lista sono i primi ad essere dimenticati, mentre i primi e gli ultimi elementi sono quelli che si ricordano di più. --Daniele Pugliesi (msg) 02:07, 16 mar 2016 (CET)
• Versione uno: non solo più leggibile ma anche più coerente con il "peso" degli avvisi - prima quelli permanenti, poi quelli temporanei che, messi in fondo, attirano di più l'attenzione. --L736E^{l'adminalcolico} 14:26, 16 mar 2016 (CET)

Conclusione

Bene, trascorsa una settimana senza ulteriori pareri allora vada per l'opzione uno. -- Helichrysum Italicum ^{.(chiamami "Heli")} 12:25, 24 mar 2016 (CET)

Proporrei di rinominare la pagina "Aiuto:Pagina di discussione/Ordine dei template di avviso" in "Aiuto:Pagina di discussione della voce" in cui inserire tutto quanto riguarda quel tipo di pag. di disc. specifica mantenendo nella sezione Le pagine di discussione delle voci della pag. Aiuto:Pagina di discussione una semplice riga esplicativa con il rimando

. -- Gi87 (msg) 17:03, 24 mar 2016 (CET)

Mi sembra una buona idea. -- Helichrysum Italicum ^{(chiamami "Heli")} 17:34, 24 mar 2016 (CET)

Ho iniziato a modificare la pagina in tal senso. [@ Helichrysum Italicum], se mi dessi una mano volevo migliorare la tabella Ordine dei template di avviso in testa alla pagina di discussione di una voce. In particolare volevo aggiungerci una colonna dedicata a spiegare in breve la funzione/uso di ciascun template. Vorrei dividere la tabella in cinque colonne coi seguenti titoli "Gruppo" (contiene: A, B, C, D), "Tipologia" (contiene: Informazioni essenziali, Provenienza dei contenuti...), "Template" (contiene: {{Discussione}}, {{Progetti interessati}}...) e "Funzione" (contiene: Indicazione del tipo di pagina, Indicazione dei progetti di riferimento...). Ogni tmp deve avere la sua riga in modo tale che a fianco ci sia la riga che corrisponda alla sua funzione. -- Gi87 (msg) 20:34, 24 mar 2016 (CET)

ti ho impostato la tabella (inutile separare "gruppo" e "tipologia" IMHO). Per il titolo della pagina, forse ha più senso lasciarla come sottopagina della attuale (cambiando cmq il titolo a quello che hai proposto), per evitare di dover "sdoppiare" le talk. -- Helichrysum Italicum ^{(chiamami "Heli")} 00:47, 25 mar 2016 (CET)

Fatto spostato a nuovo titolo: Aiuto:Pagina di discussione/Pagina di discussione della voce. -- Helichrysum Italicum ^{(chiamami "Heli")}

Ho concluso il lavoro di organizzazione di Aiuto:Pagina di discussione/Pagina di discussione della voce: ho inserito la tabella con l'ordine d'apparizione dei tmp qui deciso e strutturato meglio il resto del contenuto già presente, migliorandone solo la forma. Per questo motivo ho anche tolto l'avviso di Wikibozza. Spero apprezziate il lavoro fatto. :-) Se ci sono altre integrazioni da fare, segnalate pure qui. [@ Helichrysum Italicum]: grazie per la predisposizione della tab. -- Gi87 (msg) 01:45, 28 mar 2016 (CEST)

ben fatto. Mi pare vada bene! de nada. -- Helichrysum Italicum ^{(chiamami "Heli")} 00:03, 29 mar 2016 (CEST)

Qualcuno è in grado di far in modo che i tmp di avviso inseriti nella pag. non la categorizzino automaticamente? [@ Rotpunkt], hai qualche idea? -- Gi87 (msg) 00:44, 29 mar 2016 (CEST)

@Gi87, un po' per volta si può fare, sono diversi template da correggere. Per ciascuno bisogna controllare dove effettivamente possono essere usati, correggerli e/o eventualmente rivederne la forma (per esempio, prendo uno a caso, vedo il "Tradotto da" in Discussioni template:Storia della lingua greca, sarà corretto che categorizzi in "*Voci* tradotte da en.wiki"?) --Rotpunkt (msg) 14:12, 29 mar 2016 (CEST)

No [@ Rotpunkt], non intendevo questo. Nella pagina Aiuto:Pagina di discussione/Pagina di discussione della voce sono stati inseriti dei template solo a titolo d'esempio (per mostrare una pagina di discussione tipo). Vorrei fare in modo che i tmp lì inseriti non categorizzino in automatico la pag. Aiuto:Pagina di discussione/Pagina di discussione della voce. Ora abbiamo che per quella pagina ci siano in fondo le categorie: Voci biografiche su Wikipediani, Voci tradotte da en.wiki, GLAM/Touring Club Italiano, Crediti, Immagini richieste - stazioni ferroviarie. Tutte cat. che non dovrebbero apparire in questo caso in quanto è solo una pagina di aiuto. -- Gi87 (msg) 14:40, 29 mar 2016 (CEST)

[↓↑ fuori crono] @Gi87 Che io sappia non è possibile inibire la categorizzazione agendo su Aiuto:Pagina di discussione/Pagina di discussione della voce. Puoi solo intervenire sui singoli template e limitarne la categorizzazione ai namespace più oppurtuni, nel caso non sia stato fatto, oppure aggiungendovi un parametro o un controllo ad hoc, ma sempre sui template devi lavorare. --Rotpunkt (msg) 14:45, 29 mar 2016 (CEST)

[↓↑ fuori crono] Ho capito. Quello che vorrei ottenere è la non categorizzazione automatica della pagina suddetta. Dimmi tu quale sia la cosa migliore per farlo. -- Gi87 (msg) 14:57, 29 mar 2016 (CEST)

Ho creato il redirect Aiuto:Pagina di discussione della voce e sarei anche per una inversione. (Ma come potete soffrire questi slash insopportabili?). Ho creato anche un altro redirect, Aiuto:talk voce. pqd...Ƿƿ 14:41, 29 mar 2016 (CEST)

Ho aggiunto anche il reindirizzamento da Aiuto:Discussione voce. Per me la pagina si può anche spostare ad Aiuto:Pagina di discussione della voce. Mi pare che [@ Helichrysum Italicum] proponesse invece di creare una sottopagina per non sdoppiare le discussioni. -- Gi87 (msg) 14:55, 29 mar 2016 (CEST)

[@ Gi87, Pequod76] spostate pure. Gi87: l'unica soluzione è sostituire ogni chiamata al template con il codice del template stesso. Me ne occupo io. -- Helichrysum Italicum ^{(chiamami "Heli")} 15:17, 29 mar 2016 (CEST)

Però per chi apre la pagina in "modifica" è più utile vedere il template vero e proprio inserito piuttosto che il codice. Non credo proprio sia una buona idea. [@ Helichrysum Italicum], attendiamo prima di vedere se si possa fare in un altro modo. -- Gi87 (msg) 15:20, 29 mar 2016 (CEST)

Gi87, questa non deve essere una pagina di aiuto su come usare i template. Per imparare a usarli ci sono i vari /man scritti su ciascuno di essi. è molto più utile che il niubbo sia inviato a leggersi e imparare a usare ciascun template nella pagina dedicata, piuttosto che copiando il codice che trova qui. Ho letto il tuo messaggio troppo tardi e ormai ho fatto! -- Helichrysum Italicum ^{(chiamami "Heli")} 15:56, 29 mar 2016 (CEST)

PS: spostate pure ma mantenete il redirect della pagina di discussione a questa pagina, inutile sdoppiarle! -- Helichrysum Italicum ^{(chiamami "Heli")} 15:57, 29 mar 2016 (CEST)

[← Rientro] Propongo allora di fare così:

• spostamento della pag. da Aiuto:Pagina di discussione/Pagina di discussione della voce a Aiuto:Pagina di discussione della voce; Fatto
• spostamento della sez. Esempio e le successive sez. d'es. di disc. tipo nella pag. di discussione Discussioni aiuto:Pagina di discussione della voce, in modo tale da avere una vera e propria pagina d'esempio (ora abbiamo il problema di non riuscire ad avere l'es. compiuto, con sezionamenti non del tutto corretti);
• aggiungere in cima alla Discussioni aiuto:Pagina di discussione della voce un rimando che dica "Questa è un esempio di una pagina di discussione di una voce. Per discutere della pagina d'aiuto, utilizzare Discussioni aiuto:Pagina di discussione.", per avere un'unica pag. di disc. sull'argomento.

-- Gi87 (msg) 17:04, 29 mar 2016 (CEST)

Faccio lo spostamento. Per il resto, sinceramente titolare la sezione "Esempio" mi pare sufficiente, senza la necessità di una pagina separata...e il redirect mi sembra più sicuro di un avviso per rimandare un ipotetico neoutente a questa talk. Sentiamo di che parere son gli altri... -- Helichrysum Italicum ^{(chiamami "Heli")} 23:09, 29 mar 2016 (CEST)

segnalazione al bar

Per chi arriva dal bar: segnalo che è stata completata la bozza pagina di Aiuto per le discussioni sulle voci, in particolare per fare un po' di "ordine" nell'inserimento dei template di avviso. I feedback sono apprezzati!

A latere, vedendo tutti quei template in colonna mi vien da pensare: non è che si possono standardizzare un po', graficamente? I tre template di testa (cronologia valutazioni, progetti interessati, discussione) e il terzultimo (il promemoria) sono tutti più o meno nella stessa veste grafica. Gli altri sono un po' più da "svecchiare". Suggerimenti? -- Helichrysum Italicum ^{(chiamami "Heli")} 21:10, 30 mar 2016 (CEST)

Un osservazione preliminare: mi sembra che il titolo della pagina più corrispondente al contenuto attuale potrebbe essere Struttura della pagina di discussione di una voce. Probabilmente non mi è chiaro questo: chi arriva a questa pagina passa necessariamente da Aiuto:Pagina di discussione? Se sì, bene, perché trova lì le informazioni chiave (cos'è, a cosa serve, dove si trova, come si partecipa a una discussione); se no, almeno metterei in cima un rimando ad Aiuto:Pagina di discussione. --Michelino12 (msg) 22:40, 31 mar 2016 (CEST)

ma c'è già un {{torna a}} in cima... Non basta? -- Helichrysum Italicum ^{(chiamami "Heli")} 22:49, 31 mar 2016 (CEST)

Non so rispondere; probabilmente, come dicevo prima, non ho capito.Riguardo ai contenuti, complimenti per la tabella dei template. --Michelino12 (msg) 23:29, 31 mar 2016 (CEST)

Ok, ora ho capito. In effetti il {{torna a}} in cima fa capire che questa è una pagina che specifica le informazioni generali, presenti nella voce madre, al caso particolare di una pagina di discussione di una voce. --Michelino12 (msg) 23:15, 1 apr 2016 (CEST)

Sulla sequenzialità delle discussioni

Ho notato che spesso si tendono a trascurare le discussioni più vecchie in una pagina. Ciò penso che sia dovuto al fatto che molti utenti non capiscono che ciascuna discussione e a sé, per cui si possono continuare anche discussioni vecchie nella sezione che è già creata se queste non sono correlate alle discussioni seguenti. Molti invece ogni volta che riaprono una discussione creano una sezione nuova o peggio ancora la riaprono in un'altra pagina diversa da quella dove era presente la discussione iniziale, a volte molto peggio ancora senza indicare la vecchia discussione attraverso un link.
Come conseguenza, molte discussioni sono spezzate e ciò comporta una certa difficoltà nel lettore a comprendere come la discussione è nata e come si è evoluta.
Che ne dite di aggiungere una frase alla pagina aiuto:Pagina di discussione in modo che sia chiaro tale concetto di "sequenzialità" delle discussioni, secondo il quale, sebbene le discussioni più vecchie (cioè che hanno avuto inizio prima) sono in cima alla pagina, non è detto che discussioni vecchie (cioè in cima alla pagina) si concluderanno prima delle discussioni più recenti (cioè in fondo alla pagina)? --Daniele Pugliesi (msg) 16:42, 24 mar 2016 (CET)

+1, bisogna trovare il luogo e il modo giusto di inserire questa precisazione! -- Helichrysum Italicum ^{(chiamami "Heli")} 17:35, 24 mar 2016 (CET)

Favorevole all'aggiunta. La collocherei nella sez. Organizzazione della pagina. -- Gi87 (msg) 17:43, 24 mar 2016 (CET)

Off-topic ma non troppo: e a volte sono spezzate anche tra pagine di discussioni differenti (ad esempio, ma non è l'unico caso, il problema segnalato in Discussioni Wikipedia:Bar#Discussione (o magari più discussioni) al Bar su un argomento di una pagina di discussione specifica). --5.170.18.164 (msg) 11:09, 31 mar 2016 (CEST)

Avviso copyviol: Braccio di ferro sportivo

Si fa presente a Wikipedia che, l'autore dell'articolo in oggetto è sempre il sottoscritto che ha pubblicato l'articolo su: http://www.olympiaclub.it/files/il_braccio_di_ferro_sportivo.pdf

Quindi, si prega cortesemente Wikipedia di sboccare l'articolo così come richiesto in precedenza.

Cordialmente Prof. Salvatore Romeo— Questo commento senza la firma utente è stato inserito da Salvatore Romeo (discussioni · contributi) .

vedi WP:CONCEDI --ignis scrivimi qui 16:07, 14 nov 2016 (CET)

Sistematizzare l'uso del tmp Torna su

Il tmp {{Torna su}} dovrebbe stare un po' in tutte le pagine di discussione, quanto meno in quelle relative a progetti. Poi forse lo si potrebbe aggiungere per soprammercato anche nelle talk per cui sia già stato creato un archivio. Il tmp è molto comodo e mi stupisce che non appaia più spesso. Che ne dite? pequod ^Ƿƿ 02:28, 10 mag 2017 (CEST)

Queste cose mi fanno pensare quanto sia urgente la creazione della voce it.wiki sul tasto home (en:home key) della nostra cara tastiera. asd --Valerio Bozzolan (msg) 03:24, 10 mag 2017 (CEST)

Mi sa che ha ragione Valerio: cancelliamo in immediata questa inutility. — Questo commento senza la firma utente è stato inserito da 143.225.143.59 (discussioni · contributi) 08:48, 10 mag 2017‎ (CEST).

Favorevole ad inserire il tmp in tutte la pagine di discussione, è utile. Il comando indicato da Valerio è sicuramente utile e funziona (appena provato), ma praticamente sconosciuto quasi a tutti (d'accordo sulla necessità di creare quella voce in it.wiki). -- Gi87 (msg) 10:26, 10 mag 2017 (CEST)

Se però stiamo parlando di tutte le pagine di discussione, io mi sentirei Contrario dato che sarebbe sufficiente una riga di JavaScript del tema del sito (o meglio ancora un gadget solo per chi lo desidera) :D --Valerio Bozzolan (msg) 10:40, 10 mag 2017 (CEST)

Favorevole Valerio, non è che son tutti fenomeni, e poi non tutti ce l'hanno quel tasto. Io sul mio vecchio pc (fino a un anno fa) non ce l'avevo. Il WP:BS ci dirà quando una pagina è sufficientemente lunga da renderlo utile. Ma poi, perché solo nelle discussioni? Qui sarebbe così fuori luogo? --Carlomartini86^(Dlin-Dlon) 13:28, 10 mag 2017 (CEST)

Contrario come Valerio, inutile spreco di risorse inserirlo in tutte le pagine. Meglio automatizzare la cosa con javascript. Poi si può discutere se renderlo opt-in o opt-out. --Horcrux_九十二 14:12, 10 mag 2017 (CEST)

Mi va bene che venga fatto nel modo che preferite purché venga fatto. Non so se sono l'unico ma uso la versione desktop da smartofono e risalire è un inferno. :) pequod ^Ƿƿ 14:14, 10 mag 2017 (CEST)

Son d'accordo con [@ Carlomartini86]: anche in tante voci il comando "Torna su" potrebbe servire. Scusate, fatemi capire una cosa: è possibile automatizzare il tutto facendo sì che in ogni pagina compaia nel riquadro azzurrino in fondo alla pagina (ove si trova ora la scritta "Categorie: [altre]") il tasto "Torna su" senza dover inserire manualmente il tmp? Perché in tal caso sposerei anch'io la soluzione di [@ Valerio Bozzolan] e [@ Horcrux92]... -- Gi87 (msg) 14:27, 10 mag 2017 (CEST)

[@ Pequod76] Se ti fidi (u_u) dimmi se ti stuzzica. Copia questo: TurnBackAnchors.js qui: Special:MyPage/common.js --Valerio Bozzolan (msg) 15:27, 10 mag 2017 (CEST)

• Favorevole, lo cercavo giusto ieri da smartphone, la funzione andrebbe integrata nell'interfaccia e via. :-) --Lucas ✉ 16:02, 10 mag 2017 (CEST)

  Però anche per chi ha javascript diasbilitato Valerio, su su, e i browser testuali??? :-) --Lucas ✉ 16:12, 10 mag 2017 (CEST)

• Favorevole alla funzione per tutti! -- Gi87 (msg) 16:14, 10 mag 2017 (CEST)

  [@ Lucas] Ho apprezzato moltissimo quello che hai detto, dato che sono uno di quelli che naviga con NoScript :D Però per farlo bisogna avere accesso al server, e direi che non sia il caso per sta roba asd. --Valerio Bozzolan (msg) 16:18, 10 mag 2017 (CEST)

  [@ Valerio Bozzolan] Ormai conosco i tuoi punti deboli. :-)) Si può sempre creare un bel tickettazzo su phabricator. :-) Oppure più semplicemente usare qualche pagina di Mediawiki per introdurre il codice e poi tramite i css globali farlo collocare dove si colloca attualmente il template, no? :-) Almeno sarebbe una funzioncina democratica utilizzabile da tutti. :-)) Qualche idea? --Lucas ✉ 17:14, 10 mag 2017 (CEST)

Come accessorio opzionale fatelo pure, ma per il resto Contrario. Ho i miei dubbi che il PC di Carlomartini86 davvero non avesse il tasto... E anche i cellulari hanno i loro metodi (es. iOS). Non è compito nostro reinventare funzioni che sono generali del browser, per non dire di tutto il dispositivo; semmai, facciamo propaganda a quelle vere --Bultro (m) 18:11, 10 mag 2017 (CEST)

[↓↑ fuori crono] [@ Bultro], se ti faccio vedere il mio vecchio pc potresti stupirti del fatto che avesse uno schermo e una tastiera! --Carlomartini86^(Dlin-Dlon) 23:34, 10 mag 2017 (CEST)

Anche io lo metterei come accessorio opzionale. Per quanto riguarda il fatto che esista un tasto (e io da vecchio utente dos uso molto la tastiera. ho anche un tastierino a sinistra per usare backspace e mouse insieme) la realtà è la maggior parte delle persone non informatiche usa solo la mano destra quindi solo il mouse. Abbiamo anche (compreso in questa pagina) il {{a fine pagina}}, che non serve a chi conosce il tasto fine, ma la sua diffusione dice appunto che molti preferiscono il mouse--Pierpao.lo (listening) 18:23, 10 mag 2017 (CEST)

In ogni caso un cenno alle funzioni del browser in qualche pagina esistente p in una nuova non sarebbe affatto male--Pierpao.lo (listening) 18:42, 10 mag 2017 (CEST)

Non so, mi sembrano un po' questioni di lana caprina. :-) Non dobbiamo insegnare agli utenti a usare le funzionalità dei propri dispositivi al meglio, se possiamo fornire un link che più d'uno più trovare utile perché non farlo? Fastidio di certo non dà... ;) --Lucas ✉ 21:14, 10 mag 2017 (CEST)

Che sia utile Utente:Lucas siamo tutti d'accordo, mi sembra. La discussione sarebber se metterlo in utte le discussioni di default e appesantire il codice o come opzionale. Non ho capito come la pensi--Pierpao.lo (listening) 12:47, 12 mag 2017 (CEST)

• Fortemente favorevole, almeno nelle talk dei progetti. Non ne posso più di scorrere con il dito in alto quando lavoro via smartphone o tablet. --Holapaco77 (msg) 17:16, 14 mag 2017 (CEST)

Spaventato dall'idea di ficcare template ovuque ho azzardato la pubblicazione della nuoverrima tecnologia "Torna su"® abilitabile dalle proprie preferenze :3 Basterebbe una cosa del genere? --Valerio Bozzolan (msg) 22:53, 15 mag 2017 (CEST)

Non funzionerebbe per gli utenti non registrati.--STS Manager(Push to talk) 13:59, 16 mag 2017 (CEST)

Esatto, quindi non è una soluzione, anche per i registrati che magari da telefono utilizzano WKP senza registrarsi. -- Gi87 (msg) 15:16, 16 mag 2017 (CEST)

Veramente il problema non si pone: i gadget si possono abilitare di default (per tutti) :) --Valerio Bozzolan (msg) 15:05, 10 set 2017 (CEST)

Visualizzare i banner da mobile

In una discussione con l'utente Micheledisaverio, è uscito fuori un problema riguardante la visualizzazione degli avvisi in pagina di discussione da mobile.

Usando un dispositivo mobile, infatti, si può accedere alla discussione della voce Italia in tre modi:

1. Cliccare sul tasto Discussione che è presente in fondo alla voce (mi pare che appaia solo agli utenti registrati), venendo rimandati a Italia#/talk.
2. Dopo aver aperto la pagina di discussione in versione mobile, si può cliccare su "Leggi come pagina wiki", ottenendo un risultato più simile alla versione desktop.
3. Scrivere direttamente l'url ".../Discussione:Italia" nella barra degli indirizzi, ottenendo lo stesso risultato di cui al punto 3.

Nel caso 1, i banner come {{cronologia valutazioni}}, ma soprattutto quelli per il copyright come {{attribuzione}}, {{crediti}}, {{tradotto da}} o {{ScorporoUnione}} non vengono visualizzati. Ciò accade perché nella versione Italia#/talk non viene mostrato nulla che sia nella sezione 0, ovvero che non sia contenuto in una specifica discussione.

È un vero problema? Se sì, possiamo risolverlo in qualche modo?

L'unica soluzione che attualmente mi viene in mente è aggiungere un header in cima, come == Sezione iniziale == o = Discussioni =. Segnalo anche in officina. --Horcrux_九十二 16:20, 9 mag 2018 (CEST)

[@ Horcrux92] se non ci sono inconvenienti, suggerirei di rendere disponibile il tasto Discussione anche agli utenti non loggati in versione mobile: se non sbaglio, ora un utente non loggato via mobile può modificare sia le voci che le pagine di discussione (accedendovi con link "/wiki/Discussione:titolo_voce"). Però, la maggior parte degli utenti mobili che legge Wikipedia (non loggati), forse non è pratica della sintassi di questo link alle pagine di discussione. E' abituata alla navigazione a schede, che trova da PC fisso, ma non ritrova nella versione mobile.

Non conosco le statistiche di traffico, ma credo che la maggioranza degli utenti si colleghi da mobile. E la collaborazione dell'enciclopedia passa anche dalla visibilità e accessibilità delle pagine di discussione. Se l'utente mobile non riesce a vedere le discussioni aperte per la voce, non si iscrive/logga su it.wiki per partecipare: o fa un edit anonimo, o si limita a leggere la voce senza editare nulla. Si perdono parecchi potenziali contributi utili.

Si potrebbe invertire la modalità per la pagina di discussione: settare come predefinita la "visualizzazione come pagina wiki". che non pesenta problemi coi banner, assegnarla al tasto Discussione, ed inserire in testa alla pagina di discussione un link "passa alla visualizzazione in modalità #talk". Almeno in attesa che sia risolta la parte minima di problema rimasta aperta.Micheledisaverio (msg) 17:27, 9 mag 2018 (CEST)

Entrambi i punti (mostrare il tasto "Discussione" agli anonimi e l'inversione dei metodi di visualizzazione) non so se potrebbero essere messi in atto da noi o bisognerebbe segnalarli agli sviluppatori. Per il primo aprirei una sezione a parte, dato che va leggermente fuori argomento. --Horcrux_九十二 17:40, 9 mag 2018 (CEST)

[@ Horcrux92] perfetto, ma a guardare bene non importa molto alla fine. Tra un link discussione in alto con la vusualizzazione desktop, e in fonti alla pagina con vusualizzazione mobile (per tornare alla vista desktop), forse conviene la via intermedia di un link alla pagina di discussione e cronologia della voce che si era leggendo/editando, e messo a lato della pagina dopo i collegamenti alla home e ad una pagina a caso.un'opinione possibile come tante.Micheledisaverio (msg) 13:48, 10 mag 2018 (CEST)

Indentazione, riparliamone…

Anno nuovo, discussione vecchia: visto il crescente uso di Wikipedia da mobile (vedi questo da uno smartphone) ed alcuni problemi tecnici al riguardo (di cui non ho capito nulla), mi domando se non sia il caso di abbandonare del tutto il complicato sistema di indentazione per qualcosa di più semplice, come i quattro trattini delle linee di divisione orizzontali, per distinguere i messaggi nelle discussioni. Ah, buon 2019! --Fabius Cunctator 00:10, 1 gen 2019 (CET)

E in che modo sarebbe piú semplice? Le persone possono usare quello che riescono, poi altri possono correggere. È il bello dei wiki. Nemo 10:32, 1 gen 2019 (CET)

Per indentare correttamente devo stare attento a quanti due punti ha messo l'utente prima di me, mi devo preoccupare se l'indentazione è eccessiva e devo ricordarmi di usare {{rientro}}, ottenendo un risultato che di certo non migliora la fruibilità su mobile. Se ci mettiamo d'accordo per usare le linee invece, il lavoro di correzione da parte degli altri risulta molto più immediato. --Fabius Cunctator 11:20, 1 gen 2019 (CET)

"stare attento a quanti due punti ha messo l'utente prima di me"? Fai copia-incolla e ne aggiungi uno --Lombres (msg) 17:04, 1 gen 2019 (CET)

Sono anche io favorevole al cambio di sistema, il metodo attuale è un casino, non permette di rispondere direttamente ad un utente se non rompendo la cronologia, obbligando ad usare template che poi rendono ancora più difficile agli altri sapere dove e come rispondere. Il sistema di en.wiki è un buon punto di partenza. Per non parlare poi dei problemi già citati. --Emanuele676 (msg) 19:01, 1 gen 2019 (CET)

Sinceramente io mi trovo bene così e non vedo dei veri vantaggi nel sistema di en.wiki, sono solo convenzioni diverse, per cui non vale la pena cestinare una prassi consolidata; sarebbe un po' come cambiare il senso di marcia da destra a sinistra senza un reale perché. Consultare Wikipedia da mobile è più scomodo in generale, non è un problema delle indentazioni nelle discussioni (che personalmente trovo comunque semplici da seguire anche da mobile, specialmente se si ruota il telefono). Se si vuole rispondere direttamente a un utente intervenuto prima con il {{fc}} ben venga, imho non crea confusione, per il resto ci sono i {{ping}} e i "Per rispondere a Tizio..." e in generale il contesto della frase che possono rendere tutto più chiaro. --goth nespresso 03:51, 2 gen 2019 (CET)

[@ Goth nespresso] "prassi consolidata" mica tanto. Basta vedere l'ultima discussione sulle PdC per accorgersi che attualmente ognuno fa come gli pare, c'è chi rientra a caso senza segnalarlo, c'è chi usa un elenco puntato, chi invece il metodo di en.wiki. Questo a dimostrazione del fatto che il sistema è oggettivamente scomodo. --Fabius Cunctator 07:39, 2 gen 2019 (CET)

ma il metodo di en.wiki cosa avrebbe di diverso dal nostro di preciso? Da quello che vedo l'indentazione la usano anche loro --Lombres (msg) 11:37, 2 gen 2019 (CET)

[@ Lombres] Come già detto nella vecchia discussione, su en.wiki usano l'indentazione solo per rispondere ad un messaggio specifico (come ho fatto io adesso con te), mentre le nostre linee guida la consigliano anche per distinguere i messaggi tra loro, quando per quello basterebbero quattro  trattini (come ho fatto sotto), rendendo l'indentazione una superflua complicazione. --Fabius Cunctator 13:03, 2 gen 2019 (CET)

non vedo molta differenza: in una discussione come questa tutti i messaggi sono risposte a quanto detto prima e di conseguenza hanno l'indentazione, mentre in cose come le proposte di cancellazione e le richieste di pareri si separano già i vari pareri con l'elenco puntato, e le risposte ai singoli messaggi sono indentate. La linea che hai messo qui sotto serve a poco, è ovvio che se qualcuno risponde ora si riaggancerà anche a quello che ho detto io --Lombres (msg) 13:43, 2 gen 2019 (CET)

Neanche io ho capito. Quali messaggi andrebbero divisi. Puoi fare un esempio in una sandbox?--Pierpao.lo (listening) 14:05, 2 gen 2019 (CET)

Voi trovate una regola chiara e facilmente divulgabile su come usare l'indentazione osservando questa discussione? Quando rispondere aggiungendo un "due punti"? Quando rispondere senza usare nessun "due punti"? Quando rompere la cronologia per rispondere? Quando rispondere alla fine della discussione ma usando un numero di "due punti" minore di quello normale? --Emanuele676 (msg) 14:28, 2 gen 2019 (CET)

[@ Emanuele676] Non ci sono "regole" fisse, ma solo convenzioni utilizzate dai più. Io per esempio aggiungo sempre un ":" in più al commento sotto a cui inserisco il mio, per separarlo dagli altri. C'è chi non lo fa, c'è chi rientra sempre, c'è chi usa l'elenco puntato, c'è chi usa i {{ping}} al posto del {{fuori crono}} e continua sotto agli altri messaggi, ecc... non è un dramma, il contesto e le parole ti faranno sempre capire il senso del messaggio e a chi è indirizzato. Personalmente preferisco continuare a utilizzare la nostra indentazione e separare i messaggi fisicamente, e faccio notare (v. esempio del senso di marcia di prima) che se magicamente da domani imponessimo a tutti di adottare il sistema di en.wiki molti continuerebbero a fare come hanno sempre fatto, semplicemente per comodità e abitudine. I vantaggi di cambiare sistema non li vedo.--goth nespresso 16:59, 2 gen 2019 (CET)

[← Rientro][@ Pierpao] Ho proposto questo esempio, spero possa essere più chiaro. --Fabius Cunctator 18:02, 2 gen 2019 (CET)

è già come nel tuo esempio (ma con la differenza che si usano gli elenchi puntati anziché i trattini) nelle discussioni che richiedono più pareri separati, come le proposte di cancellazione e le richieste di pareri. In discussioni come questa, invece, è meglio scoraggiare un "intervento generico" e favorire un flusso di discussione in cui ognuno risponde tenendo conto di quanto ha detto quello sopra. L'unica cosa che potrei approvare è un uso di quelle linee al posto dell'elenco puntato nelle procedure di cancellazione e nelle richieste di pareri: rispondere a un intervento in elenco puntato, con cose come *: o :* (li metto entrambi perché anche in questo momento non ricordo qual è quello giusto) è veramente scomodo e crea caos. Sarebbe meglio separare con le linee e poi rispondere con una semplice indentazione. Ma questo solo nelle discussioni in cui attualmente usiamo gli elenchi puntati --Lombres (msg) 19:48, 2 gen 2019 (CET)

Per completezza riporto come sarebbe l'esempio fatto da Fabius nel modo in cui indentiamo normalmente. Personalmente trovo i quattro trattini meno chiare delle indentazioni, e comunque come ha detto Lombres questo sistema sarebbe più adatto in luoghi tipo le PdC, dove usiamo gli elenchi puntati (che trovo anch'essi più chiari delle righe).--goth nespresso 19:58, 2 gen 2019 (CET)

Esempio di Fabius Cunctator, ma indentato tradizionalmente

Salve a tutti, avrei questa proposta per evitare le complicazioni che riguardano l'indentazione, che ne pensate? --Tizio 18:00, 2 gen 2019 (CET)

Fortemente favorevole Mi piacciono i quattro trattini, sono più semplici da usare, rendono la pagina più ordinata e meno confusa. Così le discussioni sono più chiare da leggere anche da mobile, oltre ad avere un wikicodice più leggibile. --Caio 18:00, 2 gen 2019 (CET)

[↓↑ fuori crono] La leggibilità del wikicodice non dovrebbe essere una nostra preoccupazione. --Sempronio 18:00, 2 gen 2019 (CET)

Favorevole In effetti, devo dire che piace anche a me come soluzione. --Quintiliano 18:00, 2 gen 2019 (CET)

Contrario/a Io non sono d'accordo, abbiamo sempre usato le indentazioni, perché dobbiamo cambiare?! --Sempronio 18:00, 2 gen 2019 (CET)

[@Sempronio] Potresti spiegare per quali ragioni non sei d'accordo? --Caio 18:00, 2 gen 2019 (CET)

Commento: Non sono d'accordo perché sono brutti, inutili, non ne vale la pena, il gioco non vale la candela, evviva il mos maiorum! --Sempronio 18:00, 2 gen 2019 (CET)

Io non capisco come l'indentazione dovrebbe favorire la fruibilità di questo caotico flusso di discussione. Se la convenzione delle linee fosse stato lo standard, al confronto le indentazioni apparirebbero come un grosso avvitamento burocratico, oltre che un problema di accessibilità. --Fabius Cunctator 20:09, 2 gen 2019 (CET)

Per dire, io sono appena ritornato e ho notato solo ora di aver dimenticato un due punti nel mio commento. Cosa dovrei fare? Modificarlo? Ma mi hanno già risposto. Modificare anche i commenti sotto, non miei? Lasciare tutto come è e sperare che chi legga capisca? --Emanuele676 (msg) 21:39, 2 gen 2019 (CET)

Il punto è proprio questo, Emanuele, che si è capito tutto perfettamente anche se ti sei dimenticato i due punti in più. Fintanto che si va a capo e ci si firma va tutto bene, puoi anche non metterli mai i due punti; tutto il resto (indentazioni, righe, elenchi puntati) sono orpelli grafici che importano fino a un certo punto. --goth nespresso 23:08, 2 gen 2019 (CET)

Se it.wiki vuole sembrare un sito professionale, credibile, affidabile, ben curato e non un forum senza regole, anche la grafica è importante, in tutte le sue pagine, non solo le voci. Se la discussione si capisce anche senza indentazione, tanto vale smettere di usarla. --Fabius Cunctator 09:11, 3 gen 2019 (CET)

Sulle discussioni le uniche necessità, per essere professionali, non sono formalismi, ma la richiesta della firma e di una proprietà di linguaggio, unita alla concisione e la capacità di mantenere la discussione nell'argomento in oggetto, senza divagazioni e dispersioni argomentative.--Bramfab Discorriamo 15:17, 4 gen 2019 (CET)

Sono contrario, quando sono troppi i due punti si rientra anche senza bisogno di usare il template. Poi non mi pare sia mai successo che qualcuno sia stato morso per non averli usati, tutt'al più gli si dice gentilmente. Bramfab ha espresso il mio stesso parere. --Tostapane_{corrispondenze} 09:17, 7 gen 2019 (CET)

Prendo atto del consenso a mantenere l'indentazione, lasciando aperta la possibilità di usare la convenzione che ciascuno trova più comoda. --Fabius Cunctator 14:55, 7 gen 2019 (CET)

Bandiere del mondo.

Spostata a WP:SI#Bandiere del mondo--Pierpao.lo (listening) 15:56, 4 mar 2019 (CET)

Come posso creare una pagina di prova senza che mi venga cancellata immediatamente dalla sand box ?

cb La discussione prosegue nella pagina Aiuto:Sportello_informazioni/Archivio/2019_marzo#Come_posso_creare_una_pagina_di_prova_senza_che_mi_venga_cancellata_immediatamente_dalla_sand_box_?.
– Il cambusiere --Scalvo98 (🏎🏎)

Sport

Buongiorno io vorrei fare una proposta a wikipedia cioe di fare dei suggerimenti dei giocatori da comprare alle societa sportive ed avere un collegamento tifosi e tutte le societa sportive potete rispondermi commentandomi??

A malapena facciamo maluccio il nostro lavoro ovverosia scrivere l'enciclopedia: lasciamo che i giocatori vengano scelti dai selezionatori, senza interferire, che lo fanno meglio di noi :). Sul collegamento tifosi non ho capito. In ogni caso i nostri scopi sono definiti dai 5 pilastri e non possiamo prefiggercene altri--Pierpao.lo (listening) 10:44, 13 mag 2019 (CEST)

Mettere le discussioni al posto giusto: la cambusa

«Le discussioni, se non si tengono nelle pagine specifiche opportune, e in particolare nelle pagine di discussione delle pagine che hanno per oggetto (tipicamente, pagina di aiuto, di servizio o di linee guida e procedure o altre norme interne), diventano sostanzialmente irreperibili e quindi rendono incomprensibili certe modifiche alle pagine: dovrebbero andare nelle pagine di discussione delle pagine che hanno per oggetto perché sia facile sempre trovare tutto quello che si è detto su una data pagina; questo è importante soprattutto per le linee guida e le norme interne, perché altrimenti non è possibile capire dove si sia formato il consenso che ha portato alla loro creazione o modifica.»

(Aiuto)

Non mi sembra molto chiaro. Forse è da riscrivere in modo più intuibile. Saluti, --Micheledisaveriosp (msg) 21:46, 11 gen 2020 (CET)

Buone pratiche di archiviazione

Una pagina di discussione eccessivamente lunga diventa inutile, perchè i topic più recenti vanno in coda e non vengono letti. Una pagina piena di topic brevi e vecchi di 10 anni dà l'immagine che la discussione non sia granchè gradita.

Il problema non è soltanto scegliere la pagina di discussione appropriata, ma avere una pagina che non sia particolarmente scomodo per chi vuole partecipare e rispondere. Altrimenti, fra discussione sul portale, al bar, nella voce o nella pagina utente si finisce per scegliere di salvare il topic non in base alle regole, ma a quello libero. Che forse verrà letto da qualcuno.

Credo che i topic brevi e senza risposta siano proprio quelli da archiviare per primi. Che cosa ci stanno a fare sbrodolate di topic del 2006-2007 con una o due risposte di una paio di righe ciascuna, in cima alle pagine di discussione di voci come Discussione:Pisa, Discussione:Brescia, ecc.? Inoltre, i topic lunghi dovrebbero restare dove sono per l'importanza che hanno per la comunità e per la voce di interesse..

Un compromesso sarebbe archiviare per data. Cominciare ad archiviare i topic vecchi di 10 anni e con 1-2 risposte è una buona pratica.

Se c'è una regola non scritta che prevede di archiviare soltanto le pagine con almeno 40 topic in totale, andrebbe indicata, anche per evitare errori come questa discussione riguardo a Discussioni:Pisa (che ne ha solo 31). Che ne pensate? Saluti, --Micheledisaveriosp (msg) 22:02, 11 gen 2020 (CET)

Ripristino pagina cancellata "Giovanni Giusto" a seguito di nuove pubblicazioni dell'autore

Buongiorno, vorreti poter inserire nuovamente la voce biografica "Giovanni Giusto" nel portale Psichiatria con le linee essenziali, evitanto qualsiasi forma "promozionale" diretta o indiretta.

La persona in questione ha pubblicato vari libri con editori di rilevanza nazionale, l'utlimo dei quali ha titolo "La fattoria terapeutica. Interventi di Psicoterapia residenziale". Editore Bruno Mondadori, 2019. In precedente le principali opere sono:

• Lavorare in Psichiatria, Ed. Bollati Boringhieri, 2005
• Etica, estetica e matematica, Ed. Antigone, 2009
• Intelligenze rovesciate: dialoghi a regola d'arte, Ed. Antigone, 2011
• Comunità Terapeutiche. Storie di lavoro quotidiano, Ed. Pearson, 2015
• Cibo e corpo negati. Anoressia e bulimia oggi, Ed. Bruno Mondadori, 2016
• Tra il dire e il fare (presentazione), Ed. Erga 2017
• La mente ampliada (prefazione), Ed. Ind.edit 2018
• La Fattoria Terapeutica. Interventi di Piscoterapia residenziale. Ed. Bruno Mondadori, 2019

Ringrazio tutti per l'attenzione e per i suggerimenti che potrete darmi. Tiziano (msg) 11:45, 12 mar 2020 (CET)

TERRORISTI

Mi avete ACCUSATO di aver modificato una pagina di JOSEPH GOEBBELS quando non sono nemmeno registrato. Mi avere MINACCIATO di bloccare l'editor se faccio ancora una cosa del genere e non sono nemmeno capace di modificare una virgola. VERGOGNATEVI, SIETE DEI TERRORISTI. — Questo commento senza la firma utente è stato inserito da 146.241.140.41 (discussioni · contributi) 22:53, 12 ott 2020 (CEST).

Wikipedia:Bar/Discussioni/Evitare equivoci per gli avvisi a IP dinamici o condivisi

Segnalo discussione: Wikipedia:Bar/Discussioni/Evitare equivoci per gli avvisi a IP dinamici o condivisi. --95.237.218.42 (msg) 11:53, 21 nov 2020 (CET)

Pagina di benvenuto

Perché sono entrato nella pagina italiana quando ho ricevuto automaticamente il benvenuto? --David mystery books research (msg)

CDF Records risposta

Ciao Francesco, va bene allora non l'aggiungo, era giusto per creare un link con la pagina dell'etichetta. Grazie MuzikPerson19

Rimozione del template di benvenuto

Ero certo che fosse esplicitamente previsto il fatto che il template benvenuto possa essere rimosso a discrezione del destinatario, ma apparentemente non lo è. Direi che sia tempo di rimediare, non ha senso imporre un messaggio che dovrebbe essere "amichevole". A me succede di ricevere messaggi simili nelle wiki più disparate ma non ne faccio un dramma, un certo numero di utenti non italofoni che ricevono il messaggio automatico apparentemente sì. Il perché mi risulta oscuro ma non ha comunque senso incaponirsi e imporglielo. Perciò direi che si debba prevedere la possibilità che i messaggi automatici non legati al patrolling siano rimuovibili a discrezione del destinatario, senza necessità di archiviarli. --Vito (msg) 18:33, 23 apr 2022 (CEST)

Concordo--Pierpao (listening) 18:37, 23 apr 2022 (CEST)

Anch'io ero convinto di questo, infatti quando nel patrolling trovavo un utente che toglieva il messaggio di benvenuto dalla sua talk ho sempre lasciato correre; concordo con proposta. --Bradipo Lento (msg) 18:39, 23 apr 2022 (CEST)

Ah aggiungo una cosa, proporrei anche di prevedere la possibilità di farla cancellare qualora contenga solo questo tipo di messaggi e non ci siano archivi che vanno comunque linkati. --Vito (msg) 18:41, 23 apr 2022 (CEST)

+1, ostinarsi non ha alcun senso, tanto più che in molti progetti cancellare i contenuti dalla propria talk è del tutto legittimo (poi io i messaggi di benvenuto li trovo carini anche se incomprensibili e non capisco chi si arrabbia ma vabbé, so' strana io) --Civvì (Parliamone...) 18:57, 23 apr 2022 (CEST)

Pienamente d'accordo. --Lollo Scrivimi 19:42, 23 apr 2022 (CEST)

[↓↑ fuori crono] [@ Civvì]: asd no no no. Chiariamo che la maggior parte dei messaggi di benvenuto sono sia incomprensibili che orripilanti. Al massimo sono molto tenerini (perché fra Wikipediani siam' tutti scarrafoni e son belli a noi… asd) ma non possiamo addirittura concedere loro complimenti di estetica. asd --Valerio Bozzolan (msg) 09:52, 25 apr 2022 (CEST)

[↓↑ fuori crono][@ Valerio Bozzolan] OT, riformulo l'eccesso di sintesi: "trovo carino che venga appioppato un messaggio di benvenuto anche nei progetti in lingue incomprensibili, RTL e alfabeti indecifrabili", meglio? :-D --Civvì (Parliamone...) 11:21, 25 apr 2022 (CEST)

[← Rientro] non ho ben capito cosa si voglia aggiungere nella pagina di aiuto. probabilmente una nota dopo "Le pagine di discussione degli utenti non vanno svuotate ma archiviate." in cui si specifica che si possono svuotare se contengono esclusivamente il template di benvenuto? --valepert 20:27, 23 apr 2022 (CEST)

@Valepert Il problema è che non dovrebbe servire dirlo. --Ruthven (msg) 21:32, 23 apr 2022 (CEST)

forse sarebbe meglio scriverlo da qualche parte per evitare i dubbi? (non degli amministratori, ma degli utenti che sanno che gli avvisi non si cancellano e considerano il benvenuto come facente parte dei template che non vanno rimossi :) ). --valepert 22:23, 23 apr 2022 (CEST)

Semi-OT: sapete se è possibile disattivare i messaggi di benvenuto et sim. via bot su qualsiasi progetto wiki tramite Meta o altro? Faccio spesso edit crosswiki per sostituire o implementare immagini e ogni volta è un florilegio di complimenti "per il decimo edit in wikisource in azero" e così via... --Sailko 10:15, 24 apr 2022 (CEST)

D'accordo anche io con la proposta. In particolare, che si possano rimuovere i messaggi automatici come il benvenuto, le notizie tecniche, le iniziative, ecc. che non contribuiscono minimamente a ricostruire la storia di un'utenza è sempre stato ammesso da quando ho memoria. Se può essere utile metterlo per iscritto da qualche parte, non c'è problema.
@Sailko bot non credo, ma puoi impostare nelle tue preferenze globali le notifiche che desideri ricevere disattivando quelle per i traguardi di modifica --Sakretsu (炸裂) 11:18, 24 apr 2022 (CEST)

Sono completamente d’accordo. Non ha senso che chi non voglia vedere il benvenuto corra addirittura il rischio di trovarsi con l’avviso (quasi come fosse un vandalo) che la talk non si può svuotare. Personalmente mi trovo spesso ad avere a che fare in altri progetti con utenti che svuotano la talk anche dai messaggi (che si interpreta come “ho letto” anche se rende difficoltosa la lettura della crono), quindi soprattutto gli utenti stranieri sono abituati a farlo, ogni volta che arrivano qui e incappano nel benvenuto hanno problemi nella gestione dei messaggi. D’accordo anche che ciò venga applicato su tutti i tipi di messaggi automatici eccetto quelli legati al patrolling e che si possa rendere il link rosso se un utente lo preferisce. Personalmente lo davo per scontato però bene metterlo per iscritto! --Superpes15^(talk) 12:46, 24 apr 2022 (CEST)

Scusate la domanda ingenua: c'è veramente bisogno di specificare una cosa di assoluto buon senso?

Capisco che se qui è stata posta la domanda è perché qualche patroller l'ha fatto ma non sarebbe più semplice farglielo presente e, al massimo, aprire un thread al progetto:Patrolling per mettere il principio a fattor comune. --Antonio1952 (msg) 16:47, 24 apr 2022 (CEST)

[← Rientro]+1 Yep. Comunque al momento il messaggio di benvenuto è ancora un po' troppo wall of text e non sarei stupito se meno del 5% delle persone che lo riceve lo stesse leggendo. Quindi, se non possiamo costringere le persone a leggerlo, non è comunque annullando questo tipo di modifiche che facciamo innamorare le persone del progetto. Quando poi faranno qualcosa di sbagliato si ricorderà quella regola specifica come al solito. --Valerio Bozzolan (msg) 09:38, 25 apr 2022 (CEST)

Ora che mi ci fai pensare se non erro il benvenuto non appare nemmeno su mobile, si vedono solo le sezioni cassettate. Saranno forse più lette le pagine di aiuto linkate su Speciale:PaginaIniziale --Sakretsu (炸裂) 14:54, 25 apr 2022 (CEST)

Fatto--Vito (msg) 17:43, 9 mag 2022 (CEST)

i nomi delle persone vanno aggiornati

Se due persone cambiano nome, è giusto riportare la dicitura aggiornata anche se questo causa delle incongruenze, al massimo per dovere di cronaca forse si potrebbe riportare la dicitura che un tempo avessero un nome differente, ma al presente, nella pagina corrente, i nomi delle due registe sono quelli. — Questo commento senza la firma utente è stato inserito da Federicofasullo (discussioni · contributi) 16:47, 9 mag 2022 (CEST).

Le due registe? Cioè? pequod76^talk 16:59, 9 mag 2022 (CEST)

penso si riferisse alla voce Bound - Torbido inganno nuovamente vandalizzata. si invita l'utente a leggere WP:DANNEGGIARE e visionare la discussione in merito segnalata al bar proprio qualche giorno fa. --valepert 19:33, 9 mag 2022 (CEST)

Indentazione

Leggendo la pagina d'aiuto non mi sembra molto chiaro come deve essere fatta l'indentazione. Utilizzando il pulsante "[ rispondi ]" l'indentazione e la posizione è relativa al messaggio a cui si sta rispondendo, in quella che per me è la maniera corretta. Es A scrive, B risponde ad A e viene indentato di 1, C risponde ad A e viene indentato di 1, D risponde a C e viene indentato di 2 e messo sotto C, E risponde a A e viene indentato di 1 :

A xxxx

B xxx

C xxx

D xxx

E xxx

mentre in molti casi vedo che un'indentatura di questi tipo viene corretta aumentando sempre e comunque l'indentatura. In queta pagina di aiuto da una parte si dice di aggiungere sempre in fondo tutti gl interventi per mantenere l'ordine cronologica, mentre dall'altra si dice di usare il pulsante "[ rispondi ]" che fa l'indentatura come in questo esempio. Forse è da chiarire: va sempre in fondo o l'indentatura va normalmente riferita al messaggio a cui si sta rispondendo? --ValterVB (msg) 10:50, 26 mag 2022 (CEST)

Aggiungo che nel tutorial Aiuto:Tutorial/Discussione#Indentazione viene indicato "quando si risponde ad un utente, indentare la propria risposta di un livello in più rispetto al commento di quest'ultimo" che è esattamente quello che il pulsante "[ rispondi ]" fa. --ValterVB (msg) 14:26, 13 set 2022 (CEST)

Test: risposta da desktop --101.56.86.58 (msg) 10:12, 21 ott 2022 (CEST)

Test: risposta da mobile Pierpao (listening) 10:15, 21 ott 2022 (CEST)

User:ValterVB Il problema è che siccome noi italiani siano tuttologi in passato è sorto spontaneamente il sistema ad albero di natale, perché più che rispondere ognuno tendeva a dire la sua, almeno era così all'inizio immagino; poi siamo diventati più wikipediani ma l'albero di natale è rimasto; quindi a differenza degli standard delle altre wiki, non si è usata l'indentazione per evidenziare la risposta: si rispondeva immediatamente sotto l'edit a cui rispondere con {{FC}} (spesso formattando più a destra del flusso ad albero, per evidenziare il FC) oppure, seguendo la crono e continuando ad indentare ad albero di natale, iniziando con "re a pincopallino" o "@pincopallino". Poi è arrivato il "rispondi" internazionale (che indenta di 1 e non è poi neanche tanto internazionale, perché in realtà per esempio su meta: m:Help:Talk page#Formatting è ancora diverso) e ha sparigliato i giochi. Tra l'altro è solo il rispondi desktop che funziona così, quello mobile non funziona. Io direi che bisogna scrivere: se si risponde al primo intervento di apertura si va a destra di 1 rispetto al precedente (albero di natale) mentre se si risponde a qualcuno successivo o si mette immediatamente sotto con FC oppure: o si risponde in fondo indentando di 1, rispetto però a chi si risponde, (come il tasto rispondi, obbligatorio se sei da mobile) o si preme "rispondi"; con il consiglio di aggiungere un "Re a pinco pallino". Perchè il nuovo sistema non è noto a tutti. Spero di essere stato chiaro Pierpao (listening) 10:40, 21 ott 2022 (CEST)

[@ Pierpao] il consiglio mi è un po' oscuro... Io però mi trovo bene con il tasto rispondi anche perché, per me, è più chiaro il l"chi dice a chi" ;-) --ValterVB (msg) 19:05, 21 ott 2022 (CEST)

Archiviazione

Il paragrafo archiviazione sembrerebbe far riferimento alle sole discussioni delle pagine utente; occorrerebbe generalizzare e riformulare l'esempio dato, in modo che sia coerente con l'incipit del paragrafo. Inoltre, dal paragrafo non risulta chiaro cosa dovrebbe essere fatto riguardo ai link entranti alla discussione archivata. Esiste una policy in merito? --Mr buick (msg) 15:06, 29 lug 2022 (CEST)

user:Mr buick Quando si linka una discussione conclusa dal campo oggetto di una modifica maggiore fatta in base a quella discussione sarebbe meglio usare special:Diff in modo che anche dopo l'archiviazione il link continui a funzionare, ma non è proprio semplicissimo per un utente non esperto. Poi scrivo come si fa. Per quanto riguarda le discussioni segnalate è un lavoraccio sistemare i link entranti magari mesi dopo (quando si archivia), quindi non è stata mai stabilita la policy. Pierpao (listening) 10:50, 21 ott 2022 (CEST)

Sui link in ingresso: è vero che archiviando si rompono i link ma l'onere e l'impegno necessari per sistemarli superano di gran lunga i benefici. Soprattutto se l'archiviazione avviene (come è consigliato) su base cronologica, trovo eccessivo disporre diversamente e comunque rischia di essere una raccomandazione che, nella pratica, viene ignorata da tutti. Limiterei la cosa ai soli link che compaiano in pagine diverse da quelle di discussione (non mi riferisco al ns0, dove ovviamente non ce ne sono, ma alle pagine di servizio dei namespaces Aiuto: e Wikipedia:). --Argeste ^soffia 10:56, 21 ott 2022 (CEST)

Wikipedia

Come aprire pagina wikipedia Marco Reggiani (msg) 23:02, 16 gen 2023 (CET)

Non ho capito puoi spiegarti meglio per favore? --Pierpao (listening) 23:28, 16 gen 2023 (CET)

ChatBot sulle pagine di discussione

Sulla pagina di discussione di Benito Mussolini c'è un utente anonimo che sta inserendo l'opinione di un ChatBot riguardo l'appartenenza del Duce alla Massoneria. Io e un altro utente l'abbiamo rollbackato. Il motivo del mio revert è che a mio parere le discussioni dovrebbero essere riservate agli utenti umani, e non a programmi, i quali per il momento non sono in grado di sostenere una discussione logica (si veda a proposito l'intervista a un chatbot apparsa sul Corriere della sera qualche giorno fa). Altro sarebbe però se l'utente facesse scrivere il suo commento al ChatBot e se assumesse la responsabilità, firmandolo (ma qua non è il caso, in quanto l'anonimo ha sottolineato che il commento è stato prodotto automaticamente). Un altro problema secondo me potrebbe derivare dalla facilità con cui i Chatbot generano commenti: questi potrebbe saturare facilmente le pagine di discussione. Cosa ne pensate? Visto i progressi nella tecnologia AI penso comunque che Wikipedia dovrebbe avere una linea guida al riguardo e inserirla qua, in modo da orientare gli utenti. Alessandro57 (msg) 07:11, 23 feb 2023 (CET)

Sono d'accordo sulla necessità di aggiornare le linee guidaː nella Pagina di discussione su Kant nel paragrafo "Kant e Massoneria" un anonimo ha citato CharBot e ne è seguita una breve discussione. La mia opinione è che Wikipedia dovrebbe utilizzare solo fonti attendibili e verificabili. Ontoraul (msg) 12:02, 23 feb 2023 (CET)

Discussione recente al bar Wikipedia:Bar/Discussioni/ChatGPT e Wikipedia --ValterVB (msg) 13:19, 23 feb 2023 (CET)

Visto che non sono attendibili, non vedo perché menzionarli in discussione. --Meridiana solare (msg) 13:23, 23 feb 2023 (CET)

P.S. @Ontoraul, in Discussione:Benito Mussolini vedo sì una recente discussione sulla Massoneria, ma non vedo riferimenti a Chatbot (facendo una ricerca in tutta la pagina, non c'è proprio "chat"). --Meridiana solare (msg) 13:27, 23 feb 2023 (CET)

Guarda qui Alessandro57 (msg) 13:52, 23 feb 2023 (CET)