Questa pagina è un archivio di passate discussioni.
Per favore non modificare il testo in questa pagina. Se desideri avviare una nuova discussione o riprenderne una precedente già archiviata, è necessario farlo nella pagina di discussione corrente.
Qualche discussione (più o meno lunga) c'è giàstata, ma preferisco riassumere tutto e cercare qualche consenso in più qui. Come forse avrete capito, parliamo del campo |immagine = che in alcuni template richiede il markup completo (eg. {{Film}}), in altri solo il nome del file (eg. {{Bio}}). Sarebbe cosa buona giusta uniformarli tutti, in un verso o in un altro, così da evitare perdite di tempo e, se vogliamo, di pazienza. Nella prima discussione linkata, si era parlato di portare il tutto ad un markup ridotto, ovvero il nome immagine in un parametro, la didascalia in un altro, la dimensione immagine in un altro e l'eventuale testo alternativo in un altro ancora. Ora, se un parametro immagine e un didascalia ci possono (devono) stare, forse uno aggiuntivo per la dimensione e per l'alt è un po' troppo. Si tratta quindi di vedere bene quale è più comodo/ci conviene e decidere. Chiedo dunque: avete idee? Suggerimenti? --Gnumarcoo17:14, 1 ott 2010 (CEST)
Avevo proposto una RfC estremamente simile per standardizzare i template del progetto guerra (vedi qui). A titolo di curiosità, riferisco che c'era un chiaro consenso per l'abolizione delle parentesi quadre per il campo |immagine = e di conseguenza andavano creati campi per la gestione delle immagini particolari e così via. Non ho implementato la riforma, perchè è un grosso problema tutta la quantità di voci preesistenti. Indipendentemente da quale standard dovesse vincere, come pensi si possano modificare decine e decine di migliaia di voci, per togliere o mettere le parentesi quadre ? Non ho trovato una istruzione parser in grado di gestire "if parentesi quadre then toglile e prendi solo la prima parte con il nome file". --EH101{posta} 17:50, 1 ott 2010 (CEST)
Favorevole ad uniformare con file.jpg
Tecnicamente, non si può fare che il parametro accetti entrambe le modalità, in attesa che si tutte le voci si uniformino? --Azrael17:54, 1 ott 2010 (CEST)
eviterei di forzare tutti i template ad usare obbligatoriamente l'estensione ".jpg", non solo per problemi nel caso dovessero esistere file ".JPG", ma anche perché alcune tabelle potrebbero richiedere png (per la trasparenza) o svg (penso ad esempio alle formule chimiche). --valepert19:15, 1 ott 2010 (CEST)
Sono di fretta, ma ne approfitto per dire che ovviamente il formato andrà incluso nel nome che l'utente inserisce, non se ne parla nemmeno di fissarlo in .jpg. In fatto a doppia compatibilità, ci sto lavorando, ma sembrano esserci dei problemi tecnici (le funzioni Parser che il MW propone ad oggi, non danno molta libertà)... quindi forse dovremo farne a meno. --Gnumarcoo19:18, 1 ott 2010 (CEST)
mmmm. Vedo che i template di manipolazione delle stringhe, necessari per "sanare" i template esistenti e che usano le parentesi quadre per le immagini, sono definiti gravosi per i server e deprecati. Non vedo altro modo per i template esistenti. Si può solo raccomandare di stare attenti con i nuovi, ma i vecchi, se sono molto diffusi, sono fuori questione temo. --EH101{posta} 20:33, 1 ott 2010 (CEST)
(torno a sinistra) Favorevole, come ho già detto più volte. Io direi che lo standard dovrebbe prevedere semplicemente due parametri:
uno per il nome del file (espresso nel formato Nome del file.estensione)
uno per la didascalia, da utilizzare anche come testo alternativo
Questo perché 1) creare un parametro a parte per il testo alternativo mi sembra decisamente eccessivo quando si potrebbe utilizzare la didascalia (tra l'altro mi pare ci siano già dei template che lavorano in questo modo), e 2) creare un parametro per la dimensione dell'immagine oltre a non essere necessario è anche poco pratico: si può infatti utilizzare il dimensionamento automatico che offre Mediawiki (es.: con la sintassi [[File:Paesino sperduto.jpg|250x300px]] l'immagine "Paesino sperduto.jpg" apparirà sempre non più larga di 250 pixel e non più alta di 300, a prescindere dal fatto che "Paesino sperduto.jpg" sia un'immagine alta e stretta o bassa e larga; quindi è un sistema che non crea nessun problema in nessun caso). La "doppia compatibilità" tra la forma con le parentesi e quella senza non mi sembra una strada percorribile, purtroppo: credo che sarà necessario usare i bot. --Una giornata uggiosa '94 · E poi, di che parliamo?21:45, 1 ott 2010 (CEST)
Il resize l'avevo tenuto da conto nel caso in cui servisse... ovvio non sempre serve, anzi, contrario. I bot sono da muovere in ogni caso, tuttavia prima che partiamo vi chiederei - da parte mia - ancora qualche giorno: vorrei esser sicuro che non sia percorribile la strada per la compatibilità dei due modi (mi scoccia, seppur per poco, troncare le immagini nelle voci). --Gnumarcoo22:16, 1 ott 2010 (CEST)
La cosa piú importante da fare è a mio avviso evitare che sia possibile modificare le dimensioni dell'immagine, che va stabilita direttamente dal template, o per meglio dire non stabilita affatto, lasciando le dimensioni predefinite o scelte dall'utente nelle preferenze come da linea guida Aiuto:Markup immagini#Miniature. È insopportabile tutta questa differenza fra tabelle, tutte con immagini a dimensioni diverse. --Nemo11:01, 3 ott 2010 (CEST)
Come detto da EH101, le manipolazioni delle stringhe sono particolarmente pesanti per cui opterei per l'opzione:
si costruisce una sandbox del tmp che si vuole aggiornare e la si mette a punto con la versione nuova (pronta all'utilizzo);
si fa passare un bot che, mentre sostituisce, cambia il template con la sua sandbox;
terminate le sostituzioni, si copia la sandbox alla pagina tmp principale;
si fa ripassare il bot a cambiare i template nelle varie pagine (da sandbox a pagina principale).
Il giochetto è un po' macchinoso, ma non c'è altro modo, se non mi sfugge qualcosa. A ripensarci meglio, è bene integrare la dimensione dell'immagine direttamente nel template, mentre per il testo alternativo direi che si può farne a meno (c'è la didascalia). Tutti d'accordo? --Gnumarcoo11:15, 3 ott 2010 (CEST)
Secondo me il doppio passaggio del bot se possibile sarebbe bene evitarlo. Per ciascun template da aggiornare io implementerei temporaneamente il riconoscimento della doppia sintassi. Una volta passato il bot si rimodifica il template per togliere la doppia compatibilità. Per implementare la doppia sintassi ifexist non va bene perché se il file è su commons non viene visto, quindi opterei per qualcosa tipo:
Ovvero se il valore del parametro immagine inizia con "[" scrivi direttamente il valore, altrimenti considera il valore del parametro come un nomefile.ext. Notare che {{Str left}} è indicato come "inexpensive". -- Basilicofresco (msg) 12:54, 3 ott 2010 (CEST)
per quanto tardivo nel dire la mia, se serve un ulteriore consenso alla possibilità di uniformare e togliere le parentesi quadre, benché lo abbia scritto anche nel progetto Guerra, ci sono anche io. :-)--threecharlie (msg) 13:06, 3 ott 2010 (CEST)
Avevo provato quella stringa milioni di volte... ma non mi partiva. Ora va. *mi mangio le mani*. Se siamo d'accordo, applico subito l'aggiornamento temporaneo e faccio partire il bot per la sostituzione. --Gnumarcoo18:10, 3 ott 2010 (CEST)
Il bot è partito, ormai. In ogni caso non trovo le modifiche da passare tramite bot come hai detto... potresti darmi una delucidata? ;) --Gnumarcoo21:06, 3 ott 2010 (CEST)
Il template è stato (direi) sicuramente copiato da qui, ma chi l'ha importato sembra non aver dato peso ad una traduzione completa. Posso tranquillamente sistemare se si crede che sia il caso. --Gnumarcoo17:56, 3 ott 2010 (CEST)
Il template è stato lasciato in inglese "per permettere una agevole importazione delle informazioni contenute nell'originale template:protein contenuto in numerose voci di en.wiki.". Anzichè tradurre i parametri proporrei invece di creare il template italiano e trasformare questo in un template di compatibilità con il relativo avviso (come fatto ad esempio per il {{cita web}} e similari) --Number55★(dopo il 54, prima del 56)18:09, 3 ott 2010 (CEST)
Ma perchè dobbiamo creare un template a parte? Facciamo coesistere gli stessi parametri sia in italiano che in inglese nello stesso template! Ovvio non vanno usati entrambi assieme... --Gnumarcoo18:13, 3 ott 2010 (CEST)
Non ci sono policy e convenzioni, che io sappia.
Il template di compatibilità ha il vantaggio di semplificare il codice del template "vero" e lasciarlo in pace se cambia qualcosa nella wiki straniera.
Far coesistere le due lingue (l'abbiamo fatto ad es. in template:Moneta) ha il vantaggio che c'è una pagina in meno da mantenere.
Non saprei cosa consigliare in generale; probabilmente meglio la prima quando è un template molto generico e molto usato (tipo appunto il Cita web) e la seconda altrimenti --Bultro (m) 15:17, 4 ott 2010 (CEST)
+1 per Gnumarcoo: molto più semplice un {{{NomeItaliano|{{{NomeInglese}}}}}} piuttosto che un doppione inutile di template. --★ → Airon 9012:25, 9 ott 2010 (CEST)
Template Iran
Ciao, volevo segnalare che i template in questa categoria sono di dimensioni abnormi e quindi sarebbe meglio renderli "cassettabili". Mi rivolgo qui perché, pur immaginando che il lavoro sia facile, temo di fare casini prendendo spunto da altri template. Grazie, --Mr buick (msg) 23:05, 3 ott 2010 (CEST)
argomento in A e P
A e P si comportano diversamente con il campo argomento (in ordine alla categorizzazione della pagina), l'ho notato qui con "musicisti". Dando una velocissima occhiata al codice il primo usa Template:Argomenti avviso mentre il secondo no, che senso ha?--Shivanarayana (msg) 16:28, 4 ott 2010 (CEST)
Bultro sta aggiornando i vari template di servizio inserendo il {{Argomenti avviso}} per il doppio argomento (non-casesensitive) di cui si era parlato tempo fa. Alcuni template lo supportano, altri verranno aggiornati a breve. --Gnumarcoo16:53, 5 ott 2010 (CEST)
Proposta nuovo template
Frequentando le voci relative alle squadre della NFL, ho notato che alcuni dei template relativi agli stemmini delle squadre stesse riportavano dei colori "approssimativi", quando non addirittura errati. Volendoli correggere mi sono reso conto che facevano riferimento a delle immagini ed aggiornarli avrebbe voluto dire creare nuove immagini, caricarle e linkarle; inoltre si sarebbe dovuto cancellare le vecchie immagini, il tutto con una discreta perdita di tempo. Ho pensato perciò ad un template generico per creare gli stemmini in oggetto ed ho realizzato questo template che consente di generare delle bandierine a strisce verticali (fino ad un massimo di 5) di dimensione decisa dall'utente, alte come una riga di testo e con i colori totalmente parametrizzati secondo i soliti codici. Alcuni casi d'uso sono disponibili qui. L'uso di questo template permetterebbe di svincolarsi dalle immagini e sarebbe perciò più flessibile e facilmente modificabile. Secondo voi vale la pena di "ufficializzalo" o vedete controindicazioni? --Basilero(se hai qualcosa da dirmi...)10:39, 7 ott 2010 (CEST)
Uhm si... non mi sembrano esserci controindicazioni. Solo non capisco perché il bordercolor colorato (esempio): la bandierina sembra più grande da una parte e più piccola dall'altra; farlo bianco (o di qualsiasi altro colore che non conflitti con quelli presenti nel simboletto) non sarebbe più opportuno? --Gnumarcoo12:39, 7 ott 2010 (CEST)
P.s.: Probabilmente l'unica controindicazione è data dal fatto che questo tipo di modifica è una ovvia retrocessione grafica. :/ --Gnumarcoo12:56, 7 ott 2010 (CEST)
Ho dovuto rendere visibile il border perché altrimenti le sezioni bianche risulterebbero invisibili. Il fatto che il risultato sembri più grande da un lato credo sia imputabile ad un effetto ottico che fa sembrare le parti chiare più grandi di quelle scure. Comunque per la resa grafica posso provare a lavorarci sopra ancora un po'. --Basilero(se hai qualcosa da dirmi...)13:34, 7 ott 2010 (CEST)
Uh? Se il bordo ha lo stesso colore di una striscia, la bandierina sembra più grande... in questo caso penso che la logica non lasci spazio ad effetti ottici. :D A parte gli scherzi, non voglio dire che il bordo non vada messo, ma si può fare in modo di scegliere un colore che non dia questo tipo di risultato. Lo dico non per capriccio, ma perché veramente mi sembra una storpiatura (che, se si dovesse tenere così, non sarebbe più vantaggiosa del cambio da immagine a testo). --Gnumarcoo13:54, 7 ott 2010 (CEST)
a me personalmente graficamente pare inferiore come resa rispetto alle immagini. Inoltre penso che per un utente sia più difficile usare un template del genere rispetto a un'immagine, e che usare un meta-template (cioè un template dentro un template) sia da evitare ove possibile. Infine, penso sia da discuterne a livello di progetti sportivi, visto che sono quelli che coordinano le voci in cui sono usati questi stemmini. --Superchilum(scrivimi)14:42, 7 ott 2010 (CEST)
Non nego la resa grafica minore, ma sottolineo la maggiore accuratezza nei colori: non credo sia preferibile avere degli stemmini molto belli, ma con colori sbagliati. Riguardo alla semplicità d'uso non sono d'accordo: l'uso del nuovo template comporta solo di andarsi a cercare i codici dei colori corretti, la procedura per creare, caricare e linkare una immagine nuova mi sembra più complicata. Inoltre aggiunte e modifiche sarebbero molto più facili ed immediate. Sottolineo comunque che non intendevo lanciare una campagne di sostituzione di tutte le immagini degli stemmini, ma solo di quelle per cui si avrebbe un vantaggio effettivo e per questo fornire uno strumento supplementare. Ho segnalato la discussione al progetto sport. --Basilero(se hai qualcosa da dirmi...)15:42, 7 ott 2010 (CEST)
@Superchilum: sono d'accordo con te sulla resa grafica... ed è la cosa che più mi puzza. Però bisogna ammettere che con un template di quel tipo è tutto più comodo (se un utente non sa modificare l'esadecimale di un colore, probabilmente non sa nemmeno creare/modificare un'immagine stemmino, caricarla e applicarla correttamente). --Gnumarcoo17:45, 7 ott 2010 (CEST)
Brevemente: 1) i template li ho creati io, partendo dal tentativo fatto da un altro utente; 2) se i colori sono sbagliati, si possono liberamente modificare le immagini (che non sono originariamente fatte da me, essendomi basato sui colori indicati dall'utente che creò per primo quei file... .bmp!) o addirittura rifare in vettoriale: 3) non mi sembra una buona idea sostituire un file di Commons con una serie di codici esadecimali difficili da comprendere ed imporre così uno standard che non ha eguali, né precedenti. -- Sannita - L'admin (a piede) libero00:10, 8 ott 2010 (CEST)
Ogni tanto carico qualche bandiera su Commons, rigorosamente a strisce, perché non sono in grado di fare meglio: mi spiace dirlo, ma anche con poche conoscenze tecniche si riesce facilmente ad ottenere immagini dalla resa grafica migliore di quello che si ottiene con il template in questione, almeno a prima vista. Quindi rimango favorevole alle vecchie immagini di commons. Se per l'utente medio sono troppo complicate, esiste sempre il Progetto:Laboratorio grafico. Detto questo, in base a cosa si stabilisce quando e se i colori sono approssimativi/sbagliati? --Mr buick (msg) 01:53, 8 ott 2010 (CEST)
Non c'azzecca molto ma personalmente rimuoverei completamente le immagini da tutti questi template stemmini; certo sarei meno contrario - non che le img mi tornerebbero molto utili - in caso di serio impegno da parte di qualcuno per la trasformazione delle stesse in file .svg. Condivisibile il rilievo 3 di Sannita, nonché quello del 'chilum, ma andrei in un'altra direzione ;-) --Osк17:43, 8 ott 2010 (CEST)
Visto che non c'è consenso desisto dalla proposta. Rispondo solo a Mr Buick riguardo alla "correttezza" dei colori che mi ero basato, nello specifico, sulle informazioni raccolte dai siti ufficiali delle squadre NFL, mentre nelle voci erano usate delle generiche immagini tipo questa. --Basilero(se hai qualcosa da dirmi...)08:43, 12 ott 2010 (CEST)
Il mio rilievo era fatto perché sono d'accordo con Osk sul fatto che le immagini in quei template dovrebbero essere eliminate perché sono sempre senza fonte e comunque di dubbio risultato visivo. Però la cosa, ossia la mancanza di fonti, è sempre bellamente ignorata... --Mr buick (msg) 16:15, 14 ott 2010 (CEST)
Credo ci sia un "problema" con il template {{Comuni dello stato di San Paolo}}: è enorme e non è molto bello in fondo alle varie voci (si veda per esempio Bálsamo, dove la voce è di 2 righe e il template è 10 volte più grande). Credo sia il caso di metterlo in un cassetto, ma non sapendo bene come si faccia, lo chiedo qui. -- Yiyi(Scrivimi...)10:08, 9 ott 2010 (CEST)
Questo genere di template (ampiamente utilizzati nelle voci geografiche) mi ha sempre lasciato perplesso. Esistono le categorie e le voci con le liste di comuni (nel caso in questione, anche molto ben fatta): perché appesantire le voci con questo listoni? — Questo commento senza la firma utente è stato inserito da Delahay (discussioni · contributi) 12:38, 9 ott 2010 (CEST).
Apparte il fatto che un blocco di nomi così lascia il tempo che trova, il template è una porcheria bella e buona. Provvedo, intanto, a incassettarlo, poi discutiamo se è necessario o no. -.-" --Gnumarcoo14:48, 9 ott 2010 (CEST)
La pagina «Template:Comuni dello stato di San Paolo», il cui argomento rientra nell'area tematica di questo progetto, è stata proposta per la cancellazione. Dato l'ambito specifico, è benvenuta la partecipazione degli utenti del progetto alla discussione. (Se la pagina fosse già stata cancellata per errore, ci si può rivolgere agli amministratori chiedendone il ripristino)
Spesso capito tra template o infobox che potrebbero tranquillamente essere trasformati in WP:template sinottici (il primo che mi viene in mente è ad esempio {{Birra}}). Mi chiedo quindi, visto che se non sbaglio c'era stata una discussione in merito, è lecito che mi metta a modificare tali template con il metatemplate {{Infobox}} o è meglio lasciarli come stanno? --Number55★(dopo il 54, prima del 56)14:37, 13 ott 2010 (CEST)
Per carità. Non c'è consenso a scegliere univocamente tra le due possibili soluzioni. Esistono infatti due agguerriti partiti: uno che sostiene l'uso di {{Infobox}}, l'altro che lo aborre e spinge per l'uso delle classi specifiche. Entrambi gli schieramenti hanno validi motivi a sostegno o a detrimento altrui, per cui si deve vedere caso per caso il consenso e non si può applicare una regola unica e automatica. L'ultimo confronto si è esaurito con un sostanziale pareggio e i template si stanno naturalmente dividendo tra i due tipi. --EH101{posta} 16:25, 13 ott 2010 (CEST)
Intanto chiariamo: Birra è un template sinottico, non sono i ritocchi estetici a fare un sinottico, ma il suo scopo... Comunque la cosa certa è che tutti i sinottici dovrebbero usare le stesse classi CSS ("sinottico", "sinottico_testata", "sinottico_piede", "sinottico_divisione"). Applicarle a mano o attraverso il sottotemplate è indifferente, sul risultato finale --Bultro (m) 12:42, 14 ott 2010 (CEST)
Pardon, mi sono espresso male. In effetti intendevo proprio una modifica estetica. Birra, hai ragione, è già un template sinottico. Quello che intendo io infatti è adattarlo ad altri template che usano il meta {{Infobox}}, ma unicamente a livello di css. Però alla fine non ho capito. Bultro, dici che tutti i sinottici dovrebbero avere le stesse impostazioni css, e dici che è cosa certa. EH101, dici che non c'è consenso sulle modifiche. Quindi, è giusto usare gli stessi css ma non il metatemplate {{Infobox}} per costruirli? o ho proprio capito male e basta? :) --Number55★(dopo il 54, prima del 56)13:09, 14 ott 2010 (CEST)
{{Infobox}} utilizza e fa utilizzare quando richiamato, le classi CSS "sinottico", quindi la forma di quanto raccomandato è rispettata. Al momento, l'unico consenso è nella direzione di usare queste classi, ma non è obbligatorio se usarle direttamente o attraverso {{Infobox}}. In altre parole, Infobox non è ancora stato cancellato e si può usare, ma non esiste nessuna regola che decida automaticamente di farlo a tappeto o che lo abbia messo fuorilegge. Va valutato caso per caso e secondo opportunità. Volendo essere meno generico, direi che se un infobox non usa le classi sinottico, può essere sostituito da una versione che si appoggia a Infobox dando un semplice avviso nella talk. Se un template già usa le classi sinottico in modo diretto, prima di sostituirlo con un codice che si appoggia a infobox, consiglio vivamente e credo sia il caso di verificare meglio che ci sia consenso alla riscrittura del codice. --EH101{posta} 14:07, 14 ott 2010 (CEST)
Non è proprio indifferente come dice Bultro: {{Infobox}} usa la classe sinottico, ma alle regole impostate dalla classe aggiunge anche delle regole CSS, che in alcuni casi sovrascrivono quelle impostate dalla classe. Non ho preferenze sull'usare direttamente le classi o il metatemplate {{Infobox}}, ma quest ultimo dovrebbe essere modificato in modo da non aggiungere o modificare niente alle regole impostate su MediaWiki:Common.css per i template sinottici. --Una giornata uggiosa '94 · E poi, di che parliamo?14:50, 14 ott 2010 (CEST)
Interessante. Dove è stato stabilito che i template devono avere solo ed esclusivamente le impostazioni delle classi CSS ? Sarebbe un avvitamento burocratico e questo tipo di regole imposte, ho fatto già notare a suo tempo, non è possibile accettarle per definizione che le si condividano o meno. Se è il link che penso io, troverai il mio e altri pareri contrari e non si possono cancellare con un colpo di spugna, perchè è solo passato un po' di tempo. Ho partecipato a messe a punto di infobox dove il consenso si è stabilizzato su alcune personalizzazioni (anche che a me non piacevano). Chi le può impedire ? Esistono dei casi particolari e complessi dove cambiare in parte allineamento, dimensione, colori era indispensabile e funzionale per consentire la leggibilità. Del resto come si può pensare che una norma decisa qui (?) valga dalle galassie alle particelle subatomiche? A mio vedere, si può solo consigliare "il template unico" (redatto da chi poi ?), ma non si può imporre, nè impedire che infobox consenta personalizzazioni, magari con moderazione e quando ritenuto opportuno o proprio indispensabile. --EH101{posta} 15:22, 14 ott 2010 (CEST) come vedi Number55 hai ristuzzicato un bel vespaio :-DD
Non mi riferivo al fatto che {{Infobox}} ha dei parametri che consentono di inserire regole CSS aggiuntive, ma al fatto che anche quando questi parametri non vengono utilizzati il meta-template genera un infobox che non presenta le stesse regole CSS della classe sinottico "pura". Insomma, intendo che utilizzando direttamente la classe "sinottico" senza aggiungere altre regole CSS, e utilizzando {{Infobox}} senza utilizzare i parametri per la personalizzazione si dovrebbe ottenere la stessa cosa, mentre non è così (poi se si decide di personalizzare è un'altro conto). Il problema è che il codice di {{Infobox}} specifica già di default delle regole CSS che si sovrappongono a quelle della classe sinottico: ad esempio già nella prima riga:
ci sono delle regole assolutamente ridondanti (float, clear, margin-left, border) perché identiche a quelle che gli attribuisce già la classe sinottico, mentre width, margin-bottom, font-size, text-align e line-height impostano valori diversi da quelli impostati dalla classe, e quindi i valori della classe vengono "sovrascritti". Io dico che di default il template dovrebbe utilizzare le regole specificate in MediaWiki:Common.css; poi se si utilizza il parametro per la personalizzazione amen. --Una giornata uggiosa '94 · E poi, di che parliamo?17:48, 14 ott 2010 (CEST)
Messa così va benissimo. È pur vero che quando uno vede un infobox come quello qui, con tanto di avviso in alto, sito web in ultima riga e formato libero, viene voglia di rendere tutto obbligatorio e strettamente vincolante, ma un po' di tolleranza forse va applicata. Ma l'avviso a inizio infobox è proprio necessario con quei template ? --EH101{posta} 18:16, 14 ott 2010 (CEST)
Non e' il caso di far si che {{L}} possa categorizzare per argomento le voci in cui viene posto? Mi sembra una informazione ben piu' utile della sola data che oggi richiede. --BramfabDiscorriamo12:13, 15 ott 2010 (CEST)
Favorevole ma possiamo almeno in questo caso far muovere un bot per creare categorie di lavoro sporco per gli argomenti fondamentali? --Pequod76(talk)16:06, 15 ott 2010 (CEST)
Sarebbe interessante, a tal proposito, creare una lista di argomenti standard per tutti i template. Più che interessante, è forse prioritario, se vogliamo organizzarci al meglio. Un'idea che mi viene in mente esattamente in questo momento potrebbe esser quella del tipo: un argomento per ogni progetto esistente... che ne dite? Forse sarebbe un po' generale, in certi casi, ma così eviteremmo argomenti assurdi e troppo specifici. --Gnumarcoo17:00, 15 ott 2010 (CEST)
@Gnumarcoo: ottima idea quella degli argomenti standard. Forse i soli progetti danno una lista troppo ristretta, ma è un buon inizio. gvnnscrivimi!17:05, 15 ott 2010 (CEST)
Preferisco una lista ristretta ma corposa a categorie assurde che contengono, se va bene, una-due pagine. ;) --Gnumarcoo17:07, 15 ott 2010 (CEST)
Semplicemente impossibile: se decidiamo che, come ha ripetuto esattamente Azrael: 1 progetto ←→ 1 argomento, ogni categoria nuova senza rispettivo progetto, verrà troncata quasi fosse un vandalismo. Si tratta solo di discutere se ci va bene o no. :) --Gnumarcoo17:20, 15 ott 2010 (CEST)
Favorevole; per gli argomenti, in teoria dovrebbe proprio essere almeno 1argomento=1progetto, appunto perché lo stub di quell'argomento dovrebbe poi essere monitorato da relativo progetto. --Azrael17:08, 15 ott 2010 (CEST)
favorevole, ma la questione di 1 progetto = 1 argomento non vale per tutti. Categorie come stub sono troppo affollate, altre lo sono molto meno. --Superchilum(scrivimi)17:31, 15 ott 2010 (CEST)
Sì, era inteso come minimo 1progetto=1argomento (un progetto poi si occupa di suddividerli ulteriormente). --Azrael17:46, 15 ott 2010 (CEST)
Lasciando proseguire in questa sede la discussione su {{L}}, pregherei chi è interessato alla questione delle categorie di servizio, a dirottarsi qui. --Pequod76(talk)17:32, 15 ott 2010 (CEST)
Favorevole alla categorizzazione per il localismo, sfavorevole all'automatismo 1 progetto=1argomento: dipende dal progetto. Alcune categorie come Categoria:Voci mancanti di fonti - calcio sarebbero sovraffollate, in altri casi servono categorie non collegate ad alcun e quasi vuote, ma utili ad organizzare la struttura delle categorie di lavoro sporco. --Mr buick (msg) 23:03, 15 ott 2010 (CEST)
Ho due sotto-pagine, doppioni di pagine già esistenti su cui sto lavorando. Entrambe avevano il tmp S, eraditato alla pagina nel ns-0 e sono apparse tra gli stub, non ostante siano pagine utente. Nel caso specifico la categoria era numismatica, ma basta guardare nelle categoria citata da Una giornata, per vedere che dentro c'è di tutto e di più. --Carlo M. (dillo a zi' Carlo) 17:30, 21 ott 2010 (CEST)
Occhielli dei progetti nella descrizione dei template
Vedendo che nel template:Bio è presente l'occhiello del progetto:biografie, ho pensato che si potrebbe inserire analogamente (a mano o tramite bot) un occhiello al progetto responsabile delle linee guida del template in questione in tutte le pagine di descrizione dei template che sono di competenza di un singolo progetto. Ad esempio ho inserito l'occhiello del Progetto:Chimica nel template:Composto chimico e nella Categoria:Template sinottici - Chimica e nei suoi template. Se siete d'accordo, potrei procedere nella stessa maniera inserendo tramite bot gli occhielli dei progetti nelle altre pagine di descrizione dei template (sinottici, di navigazione, ecc.) che afferiscono a singoli progetti o a pochi progetti (vedi ad esempio template:Materiale) e nelle loro relative categorie. --Aushulz (msg) 01:35, 21 ott 2010 (CEST)
Favorevole A mio avviso, il namespace tempalte raccoglie pagine di servizio e non di consultazione. In altre parole, si tratta di URL rivolti agli utenti e non ai semplici consultatori dell'enciclopedia. --EH101{posta} 01:56, 21 ott 2010 (CEST)
Favorevole Ma proprio perché sono pagine rivolte ai contributori (e neppure ai più novelli) trovo che il link reiterato al progetto:template sia un tantino pleonastico. Per la stessa ragione per cui grassettare tutto significa non evidenziare niente. Sappiamo tutti dov'è il bartemplate e se uno non lo sa evidentemente non ne ha tutto questo bisogno. Ma anche metterlo non è certo un dramma... --Pequod76(talk)03:16, 21 ott 2010 (CEST)
Creare template non e' il mio forte, altrimenti l'avrei già creata, per cui chiedo se qualcuno è in grado di creare una template multilinguistica sulla traccia di questa template inglese en:Template:Expand_Italian? Come avviso suggerisco: Questa voce puo' essere ampliata incorporando brani tradotti dalla corrispondete voce in lingua xyzxyz. --BramfabDiscorriamo17:53, 26 ott 2010 (CEST)
Ricordo che il {{T}} ingloba già al suo interno il parametro lingua. Possiamo, se mai, discutere su come modificare il testo di quel template: crearne uno nuovo mi pare - così a primo impatto - un po' eccessivo. --Gnumarcoo18:21, 26 ott 2010 (CEST)
@Gnumarco: il template che indichi serve per un altro scopo: indicare che la voce e' in corso di traduzione! Quello richiesto viceversa e' un template per avvisare che la voce e' scarsa e indica dove andare a trovare materiale per ampliarla e migliorarla. --BramfabDiscorriamo18:34, 26 ott 2010 (CEST)
E' un generico suggerimento, che dovrebbe stare nella pagina di discussione. Non esageriamo, non è un avviso di lavoro sporco --Bultro (m) 21:44, 26 ott 2010 (CEST)
Secondo me è da creare, però ne va regolamentato l'uso. Si può pensare di consentirne l'utilizzo solo in contemporanea agli avvisi di "Richiesta di controllo", "Dubbio di enciclopedicità" e finanche "Cancellazione in corso", proibendone l'uso solitario, se tanto sembra inadatto in altre condizioni. A mio avviso, ne consentirei l'uso anche in presenza di Stub e Controlcopy, ma parliamone. --EH101{posta} 10:59, 27 ott 2010 (CEST)
Mi pare che non si sia compreso lo spirito della template richiesta, o almeno come viene inteso nella wiki inglese, per migliorare la qualità delle voci. Segnalo la richiesta al bar.--BramfabDiscorriamo18:14, 27 ott 2010 (CEST)
Mah, sono perplesso anch'io, in alcuni argomenti il 99% delle voci puo' essere migliorato traducendo da en.wiki. Bisogna comunque fare attenzione a invogliare le traduzioni: se il traduttore non conosce sufficientemente bene l'argomento la voce si riempie inevitabilmente di erroracci.--Sandro (bt) 18:42, 27 ott 2010 (CEST)
Io sarei per modificare il template {{T}} in modo che vi sia un rimando alla pagina della wikipedia in un altra lingua più completa da cui attingere. Ad esempio modificando la frase "Puoi contribuire terminando la traduzione o usando altre fonti." in "Puoi contribuire terminando la traduzione da [[LINGUA:VOCE|VOCE]] o usando altre fonti." --Number55★(dopo il 54, prima del 56)19:16, 27 ott 2010 (CEST)
Contrarissimo a qualsiasi template che suggerisca di tradurre da altre wiki, finora non ho mai visto arrivare niente di buono da questi tipi di suggerimento (del resto io sono, da sempre, anche contrario al Template:T) :-( --Pil56 (msg) 19:40, 27 ott 2010 (CEST)
Anche me piace poco il {{t}} e piacerebbe poco un nuovo template.
Forse il suggerimento esplicito di fonti e/o altre wikipedie si puo' inserire come parametro opzionale nei (IMHO belli) template {{...}} e {{S sezione}}? Ad esempio il primo potrebbe diventare cosi':
Questa sezione è ancora vuota. Aiutaci a scriverla! Fonte consigliata: [1]; traduzione consigliata dalla lingua inglese.
Concordo con le perplessità di Sandro e Pil. L'invito alla traduzione può andar bene per voci su argomenti che si prestano al linguaggio comune, ma quando si entra in argomenti specifici che fanno uso di linguaggi tecnici la traduzione è deleteria se fatta da chi non conosce l'argomento. In questi casi è opportuno che a fare la traduzione sia chi conosce l'argomento, ma lo stesso può benissimo ampliare la voce senza ricorrere ad una traduzione (o vi ricorrerà se lo ritiene opportuno). Sistemare una voce tradotta male richiede parecchio lavoro e potrebbe essere disincentivante, con il rischio di tenerla in stato pietoso per chissà quanto tempo. Meglio un dignitoso stub allora --Furriadroxiu (msg) 20:06, 28 ott 2010 (CEST)
Sono relativamente abituato a tradurre da altre wikip e reputo che, facendo le cose responsabilmente, si possano ottenere ottimi risultati. Un invito generico, come se possa essere in se stessa una soluzione, non vedo come possa essere una soluzione. Chiedo in tutta buona fede a Bramfab quale sia la prospettiva che sfugge. Quoto Furriadroxiu per quel che riguarda i linguaggi tecnici. --Pequod76(talk)22:30, 28 ott 2010 (CEST)
Ciao a tutti, stavo pensando di fare un template per poter utilizzare in modo un pò più comodo le pagine offerte da normattiva.it visto che non si può fare copia incolla del link ma bisogna costruirsi l'url a mano. Questo perché nell'enciclopedia ci sono parecchi link a leggi che risiedono su siti commerciali e forse non aggiornati e visto che abbiamo una fonte ufficiale pensavo si potesse utilizzare quella. Ho cominciato a costruire questo template Utente:ZioNicco/Sandbox e il relativo utilizzo Utente:ZioNicco/Sandbox1 però ho difficoltà in quanto devo utilizzare il carattere ; che mi converte in grassetto al posto di essere preso tale e quale. Qualcuno sa come risolvere? Grazie. --ZioNicco (msg) 14:25, 28 ott 2010 (CEST)
(fc): E dire che non capivo perché cacchio erano spuntate fuori tre righe in più dopo che ho modificato in tmp: scoprii dopo che ti presi in contropiede. LoL ;) --Gnumarcoo17:38, 28 ott 2010 (CEST)
Altra cosa: piuttosto che inserire a mano la data "al contrario", suggerirei di prevedere nel template i tre campi distinti per giorno, mese ed anno. gvnnscrivimi!17:06, 28 ott 2010 (CEST)
Come sapete, il template "Da aggiornare" si basa su dati temporali come mesi e anni. Secondo me sarebbe più utile in certe situazioni, come per esempio per le classifiche settimanali recentemente approvate dal progetto musica, il parametro del "giorno", in cui sarebbe da aggiornare la voce. Che ne pensate? --Mats 90 (msg) 22:16, 2 nov 2010 (CET)
Segnalo anche qui, visto che mi sembra il luogo adatto, questa proposta. Sostanzialmente si tratterebbe della riscrittura del template in chiave semplificativa (nella fase della compilazione, almeno!), così come si sta facendo per il Template:Comune. Saluti, --Fabio (msg) 20:04, 8 nov 2010 (CET)
Ho iniziato a sbozzarla e ho tolto quei link. Nella pagina non si fa altro che parlare delle difficoltà dei template e quindi non complichiamo ulteriormente le cose.--Pierpao.lo (listening) 02:12, 11 nov 2010 (CET)
Mah, con questa forma cubica mi sembra inadatto sia a stare in fondo che di lato. Credo sarebbe meglio se si allungasse verticalmente o orizzontalmente. --Pequod76(talk)13:35, 11 nov 2010 (CET)
+1 su Pequod: ora come ora lo metterei in fondo, ma è assai necessario ridimensionarlo come si deve --Gnumarcoo14:12, 11 nov 2010 (CET)
Lui intendeva che è la proiezione sul piano cartesiano di un cubo :) Comunque effettivamente va spostato a destra e ristretto un po' ihmo.--Pierpao.lo (listening) 15:08, 11 nov 2010 (CET)
Aggiornamenti? Mi fai un quadro della cosa e del perché la proposta (che non conosco) dovrebbe risultare risolutiva? Grazie. :) --Pequod76(talk)18:57, 16 nov 2010 (CET)
Per quanto riguarda il primo punto, per esser possibile è possibile, ma il codice risulterebbe un po' troppo croccoloso per i miei gusti. :/ --Gnumarcoo20:44, 16 nov 2010 (CET)
E sul secondo punto? Facendo ricerche per altre ragioni, ho avuto casini per via di un testo cassettato qui. L'indice viene prodotto ma non linka. --Pequod76(talk)16:38, 19 nov 2010 (CET)
Vi segnalo un interessante discussione che si sta sviluppando qui alla quale sarebbe interessante partecipare... (io a suo tempo avevo già votato a favore) Gvf14:59, 19 nov 2010 (CET)
A giudicare dagli ultimi interventi che ho letto mi sembra che il nocciolo del discorso sia stabilire chi decide che funzionalità debbano essere implementate. Mi sembra che in tale decisione la comunità non venga presa molto in considerazione... Gvf11:31, 21 nov 2010 (CET)
Non so se ne avete già discusso (in tal caso mi scuso) sulla questione di rendere orizzontali tutti i navbox (template di navigazione) e verticali tutti gli infobox (template sinottici). Ho aperto questa discussione al progetto:guerra, ma penso che sia necessario stabilire a proposito linee guida generali, valide per ogni progetto, quindi è meglio parlarne qui.
La mia proposta nasce dal fatto che i navbox, quando sono verticali, occupano la parte alta della pagina, e in presenza di infobox (che sono posti necessariamente in alto) rendono la pagina molto confusa e poco leggibile e difficile da gestire dal punto di vista grafico (togliendo spazio a eventuali immagini, che scorrono in basso rispetto a dove dovrebbero stare). Inoltre i navbox corrispondono in pratica ad una raccolta di "voci correlate", per cui sarebbe più logico posizionarli più in basso anche da questo punto di vista. Che ne dite? --Aushulz (msg) 15:02, 21 nov 2010 (CET)
sono moolto d'accordo sul fatto che i navbox (template di navigazione) debbano essere necessariamente orizzontali (e a fondo pagina) --umbertobasilica15:06, 21 nov 2010 (CET)
Favorevole anch'io ad una definizione della cosa, da linkare opportunamente nelle linee guida in modo da rendere la cosa adeguatamente vistosa. --Pequod76(talk)17:22, 21 nov 2010 (CET)
Alcuni navbox verticali sono belli e non danno fastidio, ma in effetti mi sembra una buona regola, quindi non mi oppongo. --95.232.152.85 (msg) 17:38, 21 nov 2010 (CET) Phyrexian sloggato
Cose già discusse e che si sapevano di già.. il problema è che a volte sono le soluzioni alternative a mancare. per me va bene, purché nel passaggio da verticale a orizzontale nn si perdano info. --OPVSSAILCI21:37, 21 nov 2010 (CET)
Favorevole, naturalmente non va eliminato nulla ma solo convertito. Sarebbe utile un censimento dei TdN verticali esistenti --Bultro (m) 23:37, 21 nov 2010 (CET)
Favorevole anchio, pensavo ci fosse già una linea guida che lo stabilisse. I navbox sono comunque troppi, nell'orizzontalizzarli bisognerebbe anche eliminare i molti che non servono o possono essere integrati. ^musaz † 23:56, 21 nov 2010 (CET)
@Pequod: non ne ho idea, ma penso di no, in quanto in alcuni casi non è molto comodo. Vedi ad esempio Template:Box successione.
@Bultro: concordo sul censimento. Accanto a ciascun template potremmo annotare se va convertito, cancellato, integrato, scorporato, ecc. --Aushulz (msg) 09:24, 22 nov 2010 (CET)
Beh ma il Box successione è un sinottico.. Cmq, come andrebbe fatto per i sinottici, sarebbe necessaria una uniformazione della classe usata dal template: attualmente succede che la creatività ha generato i navbox più improbabili, che spesso sono inguardabili. Per il censimento penso che un elenco offline sarebbe fattibile. ^musaz † 11:00, 22 nov 2010 (CET)
il Box successione è di navigazione (anche se in effetti ha qualcosa in comune con i sinottici) --Bultro (m) 12:54, 22 nov 2010 (CET)
Ora che abbiamo la lista, possiamo orizzontalizzare tutti i template di navigazione; mi pare infatti che ci sia il consenso a farlo. --Aushulz (msg) 17:04, 26 nov 2010 (CET)
Mi spiace, ma personalmente, pur astenendomi nel merito, non trovo perfetta nel metodo la decisione. Suggerisco, prima di modificare quasi 700 template relativi a ogni aspetto dello scibile umano, come minimo un passaggio al bar generale. Non posso credere che tutti e 700 siano sbagliati, inutili, privi di consenso maggiore di quello espresso qui e da cambiare "a tappeto". Ne vedo una marea di sport e storia, per esempio e personalmente passo ad avvisare i progetti interessati di questo convenuto qui. Se ci sarà opposizione, vi prego di tenerne conto. Se al contrario arriveranno entusiastiche adesioni da ogni dove, il lavoro sarà più rapido e semplice. Rimarco che nessuna Wikipedia del mondo ha dato il bando integrale ai template navbox verticali, per cui, davanti a una idea così nuova e originale, quantomeno informerei il più possibile tutti, non fosse altro per far capire quanto siamo stati saggi noi di it.wiki, spesso più avanti degli altri nei tempi e nelle idee sui template. --EH101{posta} 17:01, 29 nov 2010 (CET)
Però nessuno mi sembra abbia considerato il fatto che molte voci (almeno quelle del progetto:Guerra, Marina e Aviazione) non possiedono tutte un infobox o altro che va a cozzare con altri tmp verticali...forse, invece di tagliare categoricamente senza avvisare i progetti come Guerra che fa largo uso di template di vario genere, sarebbe una possibilità anche quella di rendere sia verticali che orizzontali alcuni template...e a seconda utilizzarli al meglio...E mi sembra anche troppo superficiale questa crociata contro i tmp verticali...in tutte le altre wiki esistono e noi le mettiamo al bando? mi suona strano...Mi sembra che sia stata presa una decisione tra un pò pochi utenti...sarebbe utile qualche altro parere...--Riottoso?19:19, 29 nov 2010 (CET)
@Riotforlife:nessuna linea guida è stata ancora scritta e quindi nulla è "già definito". Se un numero di utenti si trova d'accordo su di una impostazione, mica è una cosa negativa, anzi: tutt'altro. Sta a chi non è d'accordo argomentare e verificare quanto consenso esiste sulla tesi differente ed è quello che si vedrà nei prossimi giorni rapidamente. Di mio, vorrei provare a far riflettere tutti circa il fatto che tra "divieto assoluto" e "libertà totale" esiste tutta una gamma intermedia "a scalare" tra cui scegliere e che grossomodo è: deprecato, consentito eccezionalmente, tollerato, sconsigliato, possibile, e consentito. Magari una di queste sfumature incontra il massimo del consenso. --EH101{posta} 22:11, 29 nov 2010 (CET)
Si è vero, ma il consenso ottenuto tra 4 o 5 utenti per un'argomento così vasto non mi sembra sufficiente...qua si parla di 700 template che da un giorno all'altro vogliono essere vietati dopo una discussione abbastanza breve e senza aver interpellato nessuno (mi sembra così, se ho sbagliato mi scuso)...comunque EH ha ragione, tra i due estremi ci sono parecchie sfumature, quelle vanno valutate, non tutte le voci e non tutti i template sono uguali o trattato gli stessi argomenti...--Riottoso?10:43, 30 nov 2010 (CET)
Se possibile mi aggiungo a Riot, fra i contrari all'abolizione, e se possibile vi sottopongo una verifica sul fatto che il consenso non sia un po' risicato, e poco rappresentativo. Io stesso mi sono accorto solo ora della discussione (e non sono diciamo così inattivo). --Theirrulesyourrules23:42, 6 dic 2010 (CET)
Naturalmente la cosa è in discussione. Una soluzione adeguata mi sembra quella caso per caso, con la possibilità di creare due versioni per i casi "aperti". Insomma, nessuno strappo al consenso: chi avanza proposte non può patire del disinteresse altrui, dato che di link al bar ce ne sono stati diversi. Ad ogni modo, che la discussione segua serenamente. Il metodo che adotterei è quello di seguire appunto l'elenco fornito e di discutere caso per caso o rimarremo nel campo del teorico-fuffa. :) --Pequod76(talk)17:22, 10 dic 2010 (CET)
Questa corretta definizione ovviamente è cosa diversa rispetto al concetto di orizzontale e verticale. Noi siamo abituati a vedere solo infobox verticali e a inizio pagina, ma ce ne è uno celebre di infobox orizzontale e non a centro pagina utilizzato sulla en.wiki. Si tratta delle informazioni per gli aeromobili e l'effetto lo si può vedere in tutte le voci di aerei come per esempio in questo paragrafo. Sempre a titolo di cronaca, riporto che questo tipo specifico di infobox, è stato sempre scartato dal progetto aviazione, malgrado diversi tentativi di adottarlo negli anni. Gli infobox orizzontali non li abbiamo mai importati, quindi, ma di navbox verticali sì e siamo qui a parlarne. --EH101{posta} 17:38, 11 dic 2010 (CET)
