Wikipedia:Bar/2015 01 7

Il bar di Wikipedia Bar completo Indice della settimana Not Italian? It-0? Go to the Embassy Desk! New message? Deutsch · English · Español · Français  |   Aggiorna la pagina

Cambusa Bar giornaliero 6 maggio · 5 maggio · 4 maggio · 3 maggio · 2 maggio · 1 maggio · 30 aprile Bar delle scorse settimane 22 aprile · 21 aprile · 20 aprile · 19 aprile · 18 aprile · 17 aprile · 16 aprile · 15 aprile · 14 aprile · 13 aprile · 12 aprile · 11 aprile · 10 aprile · 9 aprile Archivio della settimana · Archivio del mese Cambusa · Archivio generale (fino a luglio 2006 e cronologia al 6 lug 2006)

Discussioni in corso Oggi, 6 maggio Nessuna discussione. segui    non seguire    modifiche correlate Aggiungi nuova discussione   Segnala discussione esterna

7 gennaio

Città metropolitane (esterna)

Questa è una discussione esterna (Che significa?) Sintesi: BREVE DESCRIZIONE (facoltativa). La discussione prosegue in «Discussioni progetto:Amministrazioni#Città Metropolitane». Segnalazione di Caarl 95.

Sommario delle modifiche

Esempi magistrali di uso del campo oggetto da parte di utenti non registrati da cui tutti noi dovremmo prendere esempio: [1], [2], [3]. --Ricordisamoa 12:47, 7 gen 2015 (CET)

Ehm, bravi indubbiamente, ma non ho capito lo scopo della discussione qui al bar. --Syrio posso aiutare? 13:27, 7 gen 2015 (CET)

Compilare il sommario delle modifiche, anche uno minimo, come sto facendo adesso e avresti potuto fare anche tu. --Ricordisamoa 14:46, 7 gen 2015 (CET)

Ma infatti quando è necessario lo compilo; o stai dicendo che per questi miei interventi nella discussioni dovrei scrivere" nell'oggetto, che ne so, "intervengo nella discussione"? E a che pro? È autoevidente! :| --Syrio posso aiutare? 15:29, 7 gen 2015 (CET)

(confl.)Bene l'invito a usare l'oggetto, ma non serve scrivere un poema per ogni virgola, ed evitiamo di farne una crociata. --Jaqen [...] 15:31, 7 gen 2015 (CET)

Qui ho esagerato, ma nelle voci è impossibile trovare una particolare modifica se sono tutte "anonime". --Ricordisamoa 17:14, 7 gen 2015 (CET)

Tutto sta nella libertà di disporre del proprio tempo su wiki nella maniera che più ci dà soddisfazione. --Sailko 17:48, 7 gen 2015 (CET)

In realtà il semplice uso del campo oggetto farebbe risparmiare un gran tempo, non dico se fatto dagli IP (che ultimamente usano oggetti fittizi per coprire vandalismi), ma dagli utenti si, soprattutto in caso di morifiche molto estese/rollback che a prima e anche a seconda vista.sono incomprensibili a tutti fuorché all'autore della modifica.— Questo commento senza la firma utente è stato inserito da 151.67.199.133 (discussioni · contributi) 19:35, 7 gen 2015‎ (CET).

Rimango del mio avviso che:

1) sia utile fissare un limite minimo di uso del campo oggetto sotto il quale è sconsigliato dare il flag di autoverificato (per chi interviene molto extra-ns0 come me difficilmente sale sopra il 60%, ma almeno un 50% globale sarebbe il caso)

2) avremmo dovuto far girare il bot che Ricordisamoa aveva pronto da due anni che informa chi fa almeno 5 modifiche di fila (o come ci pare, anche 3 modifiche di fila sulla stessa pagina) senza campo oggetto compilato con un messaggio in talk di usarlo. Alcuni di noi li mettono a mano, ma che senso ha quando la segnalazione la può fare un bot? ricordo che il boto era stato pensato per agire SOLO su utenti con più di tot contributi, non era intenzione forzare i nuovi utenti a imparare subito, solo ricordare quelli più anziani quando compilare il campo sia essenziale per permettere a altri di orientarsi nella cronologia.--Alexmar983 (msg) 22:12, 7 gen 2015 (CET)

secondo me forse andava richiamata da Aiuto:Oggetto questa discussione--Alexmar983 (msg) 22:15, 7 gen 2015 (CET)

Ci sono delle wiki, adesso non ricordo quali, che non puoi salvare direttamente ma prima sei obbligato a vedere un anteprima, si potrebbe impostare un filtro che se salvi semza oggetto prima ti da un warning (sei sicuro?) e poi se confermi mette un etichetta ("modifica senza oggetto"). Magari più che gli autoconvalidati direi di escludere gli autoverificati.--151.67.221.222 (msg) 00:33, 8 gen 2015 (CET)

Se mi mettessi a scrivere 40 parole di campo oggetto per ogni edit che faccio, potrei fare il compilatore di campi oggetto per professione. Se la WMF prevede ruoli remunerati di questo genere, potrei farci un pensierino; altrimenti passo e mi tengo i miei "fix template S" e "fix attività Bio". --Horcrux_九十二 00:33, 8 gen 2015 (CET)

ma infatti pure io dovessi scirvere di più mi sparerei. Già adesso "fix wlink" mi sembra eloquente, a volte capita ci scriva quale ma per una semplice modifica di pochi byte... anche "-S", "-F" lo giusifico un po' nel dettaglio... ma "-O"? e "+F" basta il commento nell'F. Insomma sono pur sempre cronologie, scrutate al 99% da utenti esperti che sanno capire queste sigle,nessuno si è mai lamentato.

Per l'avviso al salvataggio credo che VE (se non erro) c'ha qualcosa di simile. Io avevo suggerito anche di mettere un sommario automatico su VE, tipo "questi sono i tuo cambi: template X, immagini Y", da confermare con OK. E inoltre di spiegare meglio quale opzioni del browser impostare per avere l'opzione "menù a scorrimento" che suggerisca l'oggetto dalla crono dei precedenti edit. Possibilità non invasive di stimolare l'uso del campo oggetto ci sono, e si badi che per me se fai 2 modifiche di fila e solo una metti l'ogetto già mi basta e mi avanza... una volta che tutti avranno inziiato a mettere abbastanza oggetti, poi ragioneremo se è il caso di renderli meno stringati...--Alexmar983 (msg) 10:01, 8 gen 2015 (CET)

(rientro) Buon senso & intelligenza, una coppia magnifica. Per questo sono dell'idea che il campo oggetto sia più che utile e non solo a chi fa patrolling o retropatrolling; qualcuno, anche non veterano, potrebbe avere il desiderio o la necessità impellente di capire come (e quindi perché) una data voce sia giunta alla versione attuale. Per mille motivi: valutare l'attendibilità della versione stessa guardandola in itinere, comprendere il modo di procedere dell'utente o degli utenti, ecc. Anche questo è impegnare il proprio tempo su Wiki nel modo in cui si desidera. Ma bisogna pure considerare che è difficile che la cronologia sia consultata da qualcuno di diverso da un wikipediano che abbia intenzione di verificare quanto sopra. Ragione per cui, siccome parallelamente al ns-0 da un po' si sta cercando di razionalizzare in generale tutto l'ambiente, sono convinto che i campi oggetto riportati all'inizio della discussione siano tipici più di perfezionisti (nulla contro, anzi) o di niubbi piuttosto che di utenti con un minimo di anzianità e di wiki-minded. Qui, alla fine, non siamo in troppi e ci capiamo tutti attraverso pochi termini di base fondamentali. Se dico "ns-0", "fix", "wlink", "+ABC...Z", "copyviol", "vandalismo" e via così capite tutti cosa vi sto segnalando. Ergo sarei per il modello del campo oggetto razionale: "Ho sistemato un collegamento ipertestuale in quanto quello precedente rimandava, forse involontariamente, a una voce inesistente colorata di rosso" --> "fix typo wlink"; "Elimino testo poco attinente e dal tono scanzonato tale per cui sospetto si tratti di una presa in giro" --> "- vandalismo"/"- test". Tanto più che a volte capita che le edit war principino a causa dell'uso eccessivo o poco saggio dell'oggetto. Vale il principio che dovrebbe valere sempre: chi meno parla meno sbaglia (e meno presta il fianco alle interpretazioni altrui). --37.117.121.218 (msg) 20:53, 8 gen 2015 (CET)

(confl.) questa non c'avevo pensato, ma è vero che in certi casi chi meno parla meno sbaglia. Venivo epr aggiungeren un'altra di motivazioni "pro-sintesi": se ricerco una crono per capire chi ha fatto cosa, se ognuno mi scrivesse un oggetto lungo io avrei decisamente più problemi. Se cercate la rimozione non motivata dell'avviso E, non è meglio trovare il sintetico "+E" a botta sicura che sapete che la rimozione è stata fatta dopo quel punto? e il "+wlink" davanti a una modifica di 4 byte di un utente che conoscete non vi dice subito cosa è successo senza dover perdere mezzo secondo a leggere che link esatto è stato inserito? Insomma a me per esperienza in passato sarebbero serviti non oggetti più strutturati, ma in molti casi solo che si fossero più oggetti qua e là.--Alexmar983 (msg) 21:21, 8 gen 2015 (CET)

Ricordiamoci soprattutto di controllare i contenuti delle modifiche dichiarate, perché non è tutto oro quel che... (e simili "furberie" sono più frequenti di quanto non si pensi). --Pracchia 78 (scrivimi) 21:18, 8 gen 2015 (CET)

in merito per me sarebbe utile se si potesse, almeno alcune cat di utenti tipo AV o amministratori (e rollbacker), correggere un oggetto fraudolento a posteriori segnalandolo come tale...--Alexmar983 (msg) 21:24, 8 gen 2015 (CET)

Una serie di incontri per Wikimania Esino Lario

Wikimania Esino Lario

L'italia ospiterà Wikimania – il convegno di Wikimedia – nel 2016 a Esino Lario, in Provincia di Lecco sopra il Lago di Como. Abbiamo pensato che il modo più efficace per lavorare al progetto sia un incontro al mese, e ogni mese ci focalizzeremo su una questione specifica. Due incontri sono già in programma:

• Wikimania Esino Lario - gennaio 2015. Presentazione di Wikimania Esino Lario e restituzione delle informazioni sull'evento alla comunità di Esino Lario. Occasione anche per visitare Esino. Esino Lario (Provincia di Lecco), domenica 18 gennaio 2015
• Wikimania Esino Lario - febbraio 2015. Struttura e obiettivi per i prossimi 2 anni di lavoro, Sesto San Giovanni (Milano), domenica 1 febbraio 2015

I prossimi incontri discuteranno di alloggio, vitto, connettività, trasporti, programma, sicurezza, escursioni ed eventi a latere, registrazioni, borse di studio e visti, documentazione, volontari... Ovviamente l'obiettivo è in ogni questione inserire un po' di sapere libero (foto su Wikimedia Commons, dati georeferenziati su OpenStreetMap, notizie turistiche su Wikivoyage e patrimonio e altre informazioni enciclopediche su Wikipedia. Potete trovate aggiornamenti su quello che succede anche su twitter (in inglese) e facebook (in italiano).

Niente ci vieta di organizzare gli incontro dove vogliamo e ci è più comodo. Non esitate a proporre sedi per gli incontri per la preparazione di Wikimania qui o nella pagina dei raduni. È la nostra Wikimania, a giugno 2016 sarà a Esino Lario ma il resto del tempo può andarsene in giro per l'Italia e la Svizzera, dove più ci piace.
--iopensa (msg) 14:06, 7 gen 2015 (CET)

Davvero complimenti!--Pạtạfisik 13:24, 12 gen 2015 (CET)

Qui elenco degli incontri (ovviamente in bozza ma dà un'idea delle date) Wikimania Esino Lario incontra. --iopensa (msg) 11:06, 29 gen 2015 (CET)

I sinottici devono avere larghezza fissa?

Utilizzando monitor di dimensioni differenti e pc con risoluzioni molto diverse tra loro ho avuto modo di notare la scomodità di alcuni sinottici di largo uso che non sempre "scalano" adattandosi alle varie risoluzioni.

In particolare, andando a leggere il sorgente abbiamo:

• {{Squadra di calcio}}: larghezza fissa pari a 307 pixel
• {{Sportivo}}: larghezza pari a 25 em (soluzione liquida)
• {{Edizione di competizione sportiva}}: larghezza fissa pari a 300 pixel
• {{Divisione amministrativa}}: nessuna larghezza impostata
• {{Film}}: larghezza fissa pari a 300 pixel

Nel penultimo caso tutto è rimandato al css dove la dimensione è fissata a 288 pixel. Non so se si è mai parlato in passato della cosa, ma la soluzione più logica sarebbe quella di avere le dimensioni impostate in percentuale, così che si adattano alle dimensioni dei computer in cui sono ospitate; forse sarebbe anche il caso di avere dimensioni identiche, per una migliore resa visiva e omogeneità, almeno laddove possibile, il che significa non specificare le larghezze nei template, a meno che non sia strettamente necessario. --Cpaolo79 (msg) 20:10, 7 gen 2015 (CET)

Concordo, poi quando abbiamo più infobox sovrapposti di larghezza diversa è sgradevole aldilà del tipo di monitor. [scusate ma da mobile non trovo il tasto per firmare] — Questo commento senza la firma utente è stato inserito da 151.67.199.133 (discussioni · contributi) 20:30, 7 gen 2015 (CET).

dunque per i navbox fondo pagina credo di default vi sia la larghezza di tutta la pagina. Fin qui ok, non credo ci siano eccezioni. Per gli infobox laterali in effetti uno standard di larghezza potrebbe rivelarsi sensato, ma non certo urgente. Diciamo che potremmo imparare qualcosa di interessante a livello tencico disuctendone, vedere se la cosa è omogeneizzabile, poi direi abbozzare un'idea finale, botolare un avviso a tutti i progetti per vedere controindicazioni (ne approfittiamo anche per un bel censimento con rimozione di template obsoleti) e infine se non si trova consenso votarci pure. La vedo piuttosto lunga e di impatto pratico limitato. Mi ricordo che mesi fa "impazzì" il template di divisione amministrativa proprio nella larghezza, era un problema di codice a monte che non ho mai capito, ma la presenza di un collegamento esterno faceva sballare proprio quell'infobox che diventava enorme! Una larghezza fissa potrebbe evitare tutto questo?--Alexmar983 (msg) 22:24, 7 gen 2015 (CET)

(f.c.) [@ Alexmar983] chiarisco: il punto è che utilizzare una larghezza in pixel è sbagliato perché la resa è completamente differente per schermi di risoluzioni differenti: noi spaziamo da 1024 a oltre 2000 pixel di risoluzione orizzontale il che significa che la resa è totalmente diversa: l'idea sarebbe quella di utilizzare dimensioni in percentuale (35%?) che scalano al variare delle risoluzioni, ma anche dei ridimensionamenti delle finestre. --Cpaolo79 (msg) 08:17, 8 gen 2015 (CET)

PS: ho aggiunto il template film.

in css dovrebbe (con una corretta gestione dell'overflow orizzontale, che però è deprecato e deprecherei qui), in tabella proprio no: se un testo ^elemento è largo (come una lunga URL, ad esempio), la tabella si allarga per contenerlo.

credo necessario affrontare l'argomento dell'uniformazione, magari cogliendo questo ottimo spunto di Cpaolo: non ha alcun senso (tantomeno grafico) che i box siano incolonnati e sporgano uno di 10px, l'altro di -20, uno con un margin e l'altro senza, uno con div e l'altro in tabella (e uno con font 18px e l'altro 15). E' essenzialmente un gran disordine difficile da gestire e che poi ci porta problemi di leggibilità. Oggi si deve dividere la questione fra sito base e sito mobile, e abbiamo da far fronte a davvero tutte le possibili risoluzioni, forse è meglio individuare la formula-tipo universale e poi costringere tutti i box a uniformarvisi, imho è venuto il tempo di farlo :-) -- g · ℵ (msg) 00:17, 8 gen 2015 (CET)

Come Gianfranco, sono dell'idea che sia venuta l'ora di uniformare la larghezza degli infobox, tenendo conto che ogni schermo ha esigenze differenti. --Daniele Pugliesi (msg) 04:11, 8 gen 2015 (CET)

Questa discussione, secondo me, andrebbe spostata in Discussioni progetto:Coordinamento/Template.--Mauro Tozzi (msg) 08:43, 8 gen 2015 (CET)

Appoggio l'iniziativa. --Retaggio (msg) 12:22, 8 gen 2015 (CET)

Non so se la dimensione in % farebbe un bell'effetto, conviene fare un test con un template di uso comune e vedere quante lamentele arrivano... Suggerisco di provare con il template:Film dato che non vedo un particolare motivo per forzarlo a 300px. Va detto che se è presente l'immagine, quella comunque impone una larghezza minima --Bultro (m) 12:48, 8 gen 2015 (CET)

opzioni regolabili (% o larghezza) sarebbero possibili? E intendo non solo come utenze ma come setting del browser? Questo renderebbe meno "dolorosa" una scelta generale di default.--Alexmar983 (msg) 12:58, 8 gen 2015 (CET)

In alcuni infobox la loro larghezza dipende dall'immagine inserita; per esempio nel {{tassobox}} la larghezza dell'immagine inserita deve essere compresa tra 200px e 250px.--R5b43 (msg) 15:37, 8 gen 2015 (CET)

• [@ R5b43] non è esattamente così: nel codice è indicata la misura di 230px, quindi se è presente un'immagine più piccola, la larghezza della tabella riamne di 230px, altrimenti si allarga a 250px massimo.

La mia proposta è: a) cambiare il css in modo che la classe sinottico (non ho idea di come sia possibile tecnicamente) riporti un valore di default in percentuale; b) stabilire delle regole comuni (dimensioni minima, massima, assenza di valori in pixel) per tutti i sinottici.

Concordo con [@ Mauro Tozzi]: sarebbe stato più giusto aprire la discussione nel progetto di coordinamento dei template; non so perché, ma non mi era venuto in mente. --Cpaolo79 (msg) 17:34, 9 gen 2015 (CET)

(magari dopo ci cambusiamo) una domanda, però, generale un momento prima di quelle di dettaglio: se siamo d'accordo a uniformare tutti tpl, li convertiamo tutti in css o tutti in tabella? -- g · ℵ (msg) 21:33, 9 gen 2015 (CET)

PS: non perdiamoci per strada l'osservazione di Alexmar sulla possibilità di personalizzazione dei settaggi (per la quale credo basti il cookie, in analogia con il settaggio larghezza thumb) -- g · ℵ (msg) 21:37, 9 gen 2015 (CET)

i sinottici sono già tabelle e hanno già le loro classi css. se ne può regolare la larghezza in percentuale (dipende dalla larghezza dello schermo), in emme (dipende dalle impostazioni del browser), in px (inutilmente rigido) oppure si può lasciare libera. in tal caso aggiungendoci un'immagine "frameless" piuttosto che con dimensione specificata, la larghezza si adatterà alle preferenze degli utenti. --ppong (msg) 16:59, 10 gen 2015 (CET)

Proprio libera del tutto no, sennò quando una casella contiene una frase un po' lunga la tabella si mangia tutto lo schermo... Come abbiamo detto, le immagini possono forzare solo la larghezza minima, e comunque non c'è sempre un'immagine --Bultro (m) 18:04, 11 gen 2015 (CET)

Ricordo una simile discussione quando [@ EH101] propose un'evoluzione del sinottico usato per gli aeromobili; ricordo che la discussione fu accesa (se non ricordo male perché introduceva "formattazioni" tipiche di en.wiki e colorazioni automatiche del sinottico in base ad un parametro) ma alla fine la cosa passò ricordando al progetto aviazione quali erano i limiti da non superare. Se serve provo a recuperare la discussione che può servire da base per non ripetere lo stesso iter, e mi sono permesso di pingare EH101 perché lui, in quanto promotore, spero si ricordi meglio dell'evoluzione del problema (e dove trovarla nel mare magnum deiie discussioni archiviate).--Threecharlie (msg) 09:20, 13 gen 2015 (CET)

Fondamentalmente si confrontavano la situazione attuale (ottimamente riassunta da Bultro qui sopra), contro chi invece proponeva 300px senza se e senza ma. Costoro probabilmente avevano in mente un tipo di standardizzazione "di forza" che faceva leva sulla larghezza dell'immagine, eventualmente da correggere a 300px "a mano". C'era anche chi proponeva una larghezza libera sempre e gestibile con parametro, ma evidentemente non teneva conto delle controindicazioni. Aiuta il dibattito l'esempio SC 2500, dove essendo l'immagine nell'infobox molto stretta, ma anche molto lunga se non si sta attenti con le formattazioni automatiche, si hanno risultati strani. Detto ciò, se si trova una soluzione per tutto, ben venga. --EH¹⁰¹{posta} 11:06, 13 gen 2015 (CET)