Discussioni progetto:Coordinamento/Template/Archivio/32

Da Wikipedia, l'enciclopedia libera.
Vai alla navigazione Vai alla ricerca

Segnalo la creazione di un template per facilitarne la citazione: potete intervenire se avete osservazioni sulla sua sintassi; poi si procederà alla sua implementazione nelle voci. Grazie, --Epìdosis 19:58, 3 mag 2015 (CEST)

Template:Cancellazione nel namespace 11

A seguito di questa segnalazione mi sono accorto che il template in oggetto non funziona correttamente nel namespace 11. In pratica, invece di generare l'avviso per informare gli utenti della cancellazione in corso come in qualsiasi altro namespace "discussioni", esegue quello riservato alle voci in cancellazione, provocando l'erronea categorizzazione della pagina nella Categoria:Procedure di cancellazione incompiute. Momentaneamente ho risolto il problema inibendo il template con i tag <nowiki>[1][2][3], ma qualcuno riesce a correggere il problema di fondo?

PS: le 3 pagine che ho corretto erano le uniche presenze del template in quel namespace (vedi ora). --Fullerene (msg) 16:47, 13 mag 2015 (CEST)

Mi pare che non ci sia nessun errore: il template o va messo nella pagina proposta per la cancellazione o può essere usato come avviso solo in Discussioni utente o Discussioni progetto. Tuttavia {{Cancellazione|Template:Calcio Messina FC (1900)}} propone la cancellazione del template calcio messina FC trovandosi in Discussioni template:Calcio Messina FC (1900). Il template controlla quindi Wikipedia:Pagine da cancellare/{{FULLPAGENAME}} (che sarebbe Discussioni template:Calcio Messina FC (1900)) per vedere se la cancellazione è stata effettivamente fatta o meno, ma non la trova perché la voce giusta è Wikipedia:Pagine da cancellare/Template:Calcio Messina FC (1900). Lo stesso vale per gli altri due casi.--Sakretsu (炸裂) 19:43, 13 mag 2015 (CEST)
Provando a ricostruire la storia del problema segnalato da Fullerene, il problema è iniziato quando un utente ([@ Erik1991]) l'8 maggio ha spostato (cambusato) una discussione del 2011 che era un avviso di cancellazione da Discussioni_progetto:Sport/Calcio (namespace 103 gestito dal template Cancellazione) a Discussioni_template:Calcio_Messina_FC_(1900) (namespace 11 non gestito). Come ha detto Sakretsu i namespace dove funziona l'avviso sono solo Discussioni utente o Discussioni progetto. Direi che è meglio non spostare (cambusare) le segnalazioni di avviso cancellazione. Cioè si può anche modificare il template Cancellazione per gestire la situazione, ma al di là dei problemi tecnici (risolvibili) mi viene da dire che una segnalazione di cancellazione a un progetto non vada spostata. --Rotpunkt (msg) 20:31, 13 mag 2015 (CEST)
Sono d'accordo con te, l'avviso dovrebbe rimanere nella voce (o in un eventuale archivio) del progetto. D'altronde lo scopo era quello di avvisarne i membri. Per quanto riguarda il template, non credo che sia necessaria una modifica.--Sakretsu (炸裂) 20:56, 13 mag 2015 (CEST)
Effettivamente non c'avevo pensato, il template come avviso agli utenti dovrebbe essere presente solo nei namespace "discussioni utente" e "discussioni progetto", dunque non erano corrette le cambuse. In ogni caso l'errore l'ho corretto con i tag <nowiki>, quindi a posto così. Grazie! --Fullerene (msg) 15:36, 14 mag 2015 (CEST)

Nuovo modulo

Segnalo discussione su nuovo modulo per {{Età wikipediana}}. Ciao. --Rotpunkt (msg) 21:23, 15 mag 2015 (CEST)

Ho terminato la scrittura e test del nuovo Modulo:Data corredandolo di più test possibili (vedere qui). Per ora l'ho utilizzato per semplicare il template {{Età wikipediana}} (vedi diff) e il template {{Tempo trascorso}} (vedi diff, a cui si aggiunge il complicato sottotemplate Template:Tempo trascorso/core che ora può essere cancellato). Ci sono sicuramente altri template in Categoria:Template cronologici che potranno essere semplificati col modulo. Se desideraste qualche altra funzione utile da mettere nel modulo (per ora solo due) fatemelo sapere. --Rotpunkt (msg) 17:25, 21 mag 2015 (CEST)

Template episodio anime

Segnalo questa mia richiesta, qualcuno può aiutarmi? --Phyrexian ɸ 23:29, 19 mag 2015 (CEST)

Ripresa dei moduli Nazioni, Bandiera e Nazionale

Ciao, stamattina ho riportato nel namespace template (e aggiornato) tre moduli che avevo scritto a fine ottobre/inizio novembre 2013, e per i quali avevamo già discusso qui. Sempre nel 2013, pochi giorni dopo mi ero messo a fare anche il modulo per gli stemmini delle squadre sportive e pochi giorni dopo ancora venne annunciato che sarebbe stata data priorità allo sviluppo dell'accesso arbitrario. In quel momento allora mi sembrò la scelta più logica demandare il più possibile a Wikidata, utilizzando i dati là presenti, e abbandonai sia questi moduli che quelli degli stemmini.

L'accesso arbitrario fu invece poi rimandato di volta in volta e si è arrivati ora a questi giorni. Dove si scopre però che c'è il limite di 500 accessi a item per pagina, cosa che le bandiere, unite ad altri template che utilizzano dati sotto Naz/* sforerranno in alcune pagine. Inoltre alcuni dati relativi alle nazioni che usiamo non sono pronti a finire su Wikidata e la cosa andrà per le lunghe.

Valuterei quindi l'attivazione di questo modulo che permette di unire tutte le le 844 sottopagine di Categoria:Template Naz e le 290 della Categoria:Template AggNaz in un solo modulo. Inoltre così facendo se in futuro si potrà sfruttare Wikidata, il modulo fungerà da tramite verso di esso in modo trasparente. Lo possiamo quindi vedere comunque come una facilitazione nel caso di passaggio a Wikidata, e un'occasione per unire le informazioni Naz e AggNaz.

Ci sono poi gli altri due moduli Bandiera e Nazionale. Questi semplicemente reimplementano in Lua una serie di template, usando il nuovo modulo Nazioni. Per questi la loro attivazione è completamente trasparente, ossia per chi usa quei template non cambierà nulla, semplicemente i template andranno a cercare le informazioni nella nuova tabella Lua Modulo:Nazioni/Nazioni (richiederà un aggiornamento) invece del migliaio di pagine divise attuale.

Nota: alla pagina Template:Nazioni/report, per comodità di lettura, viene generato un report tabellare dai dati presenti in Modulo:Nazioni/Nazioni.

Metto qui di seguito una tabella per riassumere le funzionalità dei nuovi tre moduli.

Modulo Template che implementa attualmente Descrizione Pagina dei test
Modulo:Nazioni Unifica in una sola pagina le 844 sottopagine di Categoria:Template Naz e le 290 della Categoria:Template AggNaz, fornendo l'accesso a queste informazioni a qualunque template o altro modulo. Discussioni modulo:Nazioni/test
Modulo:Bandiera Reimplementazione dei template {{Bandiera}} e {{Band dip}} in Lua e usando direttamente il modulo Nazioni. Discussioni modulo:Bandiera/test
Modulo:Nazionale Reimplementazione in Lua, in un solo modulo, di cinque template {{Naz}}, {{NazBD}}, {{NazBA}}, {{NazNB}} e {{NazU}} unificandone le funzionalità comuni e usando direttamente il modulo Nazioni. Discussioni modulo:Nazionale/test

--Rotpunkt (msg) 14:45, 22 mag 2015 (CEST)

Ho due domandine stupide stupide:
  1. Template:Nazioni/report/man, in questo momento è nella Categoria:Pagine con link a file inesistenti perchè un paio di bandierine sono state cancellate da commons (a memoria ricordo quella di Rijeka). In casi come questi, anche per il futuro, dove e cosa bisogna andare a correggere per togliere gli errori?
  2. Con queste modifiche, nell'uso da parte degli utenti nelle voci e nei template, ci sono modifiche nell'uso del Template:Naz e in quelli più o meno collegati come Template:ITA? --Pil56 (msg) 15:31, 22 mag 2015 (CEST)
Rispondo: (1) Come scritto sopra l'unione delle 844 sottopagine di Categoria:Template Naz e le 290 della Categoria:Template AggNaz è proprio Modulo:Nazioni/Nazioni, che avevo creato a novembre 2013. Ci saranno da aggiornare dei campi, cambiati nel frattempo. (2) non cambia nulla nell'uso dei template da parte degli utenti, cambia esclusivamente come sono fatti i template al loro interno (scrivevo sopra "ossia per chi usa quei template non cambierà nulla"). --Rotpunkt (msg) 15:41, 22 mag 2015 (CEST)
  1. 1- ok
  2. 2- se io leggessi con un po' più di calma, eviterei le brutte figure :-) --Pil56 (msg) 15:52, 22 mag 2015 (CEST)
@Pil56 Ho corretto quegli errori sulle immagini (ci saranno probabilmente altri aggiornamenti da fare). Tornando a prima, la modifica non cambia nulla per gli utenti, serve più che altro a unificare le informazioni sugli stati che abbiamo un po' sparse e disordinate tra Categoria:Template Naz e Categoria:Template AggNaz, e potervi poi accedere in modo unificato (tramite {{Nazioni}}), sia da altri template che da moduli. --Rotpunkt (msg) 16:02, 22 mag 2015 (CEST)

D'accordo con l'operazione - in effetti stavo pensando di proportelo in talk di riprendere in mano questi moduli, visto il limite dell'accesso arbitrario ai dati di wikidata.--Moroboshi scrivimi 16:51, 22 mag 2015 (CEST)

Qualche dubbio sul fare un paginone unico con tutti i dati. Vedere i dati di Aruba vicino a quelli di Aden non ci serve a niente, mentre avere una sottopagina dedicata a ogni nazione ha la sua comodità, sia per la modifica che per la visualizzazione. Non si potrebbe, anche con il modulo, mantenere una divisione in sottopagine, come per il Mappa di localizzazione? Le sottopagine inoltre possono essere categorizzate (es. raggruppare stati attuali, stati passati, regioni), ed è facile creare sinonimi attraverso i redirect. Attenzione poi che molti template (ricerca approssimativa), oltre a quelli sopra citati, fanno un accesso diretto alle sottopagine. --Bultro (m) 17:20, 22 mag 2015 (CEST)
Il mio punto di vista è che posso capire la divisione 1 nazione 1 pagina se ci fosse una continua modifica di questi dati (si può anche fare qualche ricerca per vedere cosa è stato modificato nell'ultimo anno), perché evita conflitti di modifica tra utenti e diminuisce la possibilità di fare errori. Ma se questi dati sono praticamente consolidati e cambiano raramente, i vantaggi di avere un'unica pagina sono ben superiori.
Avere un'unica pagina permette di avere tutti i dati sott'occhio e fare rapidamente ogni tipo di analisi (se ho 1000 pagine invece le devo scaricare sul computer ogni volta tutte e 1000) e vedere per dire se un campo è praticamente inutilizzato ed è meglio rimuoverlo, se ne posso accorpare, se è il caso di aggiungerne uno, rinominarlo, ... Quando poi si arriva alla modifica non c'è di nuovo paragone: decido di cambiare il nome a un campo della tabella in cinque secondi faccio un replace e salvo, se ho 1000 file ci vuole minimo un'ora col bot per fare 1 sola modifica. Non parliamo poi se appena finita decido di correggere un ritorno a capo o altro, lascio perdere.
Riguardo alla "visualizzazione", in Template:Naz/ABW l'unica cosa che c'è da vedere è la bandiera, non la trovo una cosa fondamentale, in Template:Nazioni/report ci sono tutte, un po' più piccole, ma basta cliccarci sopra.
Riguardo ai redirect, c'era già nella vecchia discussione, mi sono forse dimenticato di aggiungerlo, adesso sono gestiti anche qui da una sola pagina (Modulo:Nazioni/Alias) in cui si ha sotto controllo tutte le redirezioni.
Riguardo all'utilizzo di Naz nei template, quelli sono proprio casi in cui è da utilizzare il nuovo template {{Nazioni}}, li aggiornerei contestualmente all'attivazione del modulo.
Un compromesso potrebbe essere, cominciamo con la pagina unica, aggiungendo comunque al modulo la possibilità di funzionare su pagine separate. Se poi strada facendo non ci si trovasse bene si può sempre passare al sistema a più pagine. --Rotpunkt (msg) 18:39, 22 mag 2015 (CEST)
Ho aggiornato Modulo:Nazioni/Nazioni a oggi e ridotta la lunghezza dei nomi dei campi. Ora la pagina è 113969 byte (su en.wiki en:Module:Convert/data è 187224 bytes, ed è usata in 722580 voci). --Rotpunkt (msg) 10:56, 24 mag 2015 (CEST)
ho visto che hai inserito per le API il parametro "parentOnly = true", ma potrebbe essere utile, via bot o meno, utilizzare questi moduli con il subst, e non sono sicuro che funzioni passando da un template. --ppong (msg) 11:21, 24 mag 2015 (CEST)
+1 per un template/modulo unico, come recentemente ho proposto (e successivamente attuato) l'unificazione delle sottopagine del Calciopalm e dei template sulle icone. È tutto più semplice da modificare e tenere sott'occhio, e non vedo controindicazioni. --Horcrux九十二 11:36, 24 mag 2015 (CEST)

──────────────────────────────────────────────────────────────────────────────────────────────────── @ppong, in realtà non mi risulta, se scrivi in una tua sandbox:

* {{subst:Nazioni|ITA|band}}
* {{subst:Bandiera/Sandbox|ITA}}
* {{subst:Band dip/Sandbox|ABW|nome}}
* {{subst:Naz/Sandbox|AL|ITA}}
* {{subst:NazBD/Sandbox|AL|ITA}}
* {{subst:NazBA/Sandbox|AL|ITA}}
* {{subst:NazNB/Sandbox|AL|ITA}}
* {{subst:NazU/Sandbox|CA|ITA||21}}

e salvi, tutti i template vengono substati correttamente (la nuova implementazione è nella versione "/Sandbox", a parte Nazioni per il quale anche il template è nuovo). PS avevo dimenticato il safesubst solo per {{Band dip/Sandbox}} ma l'ho aggiunto adesso. --Rotpunkt (msg) 11:47, 24 mag 2015 (CEST)

Ho bisogno di un parere su come mi devo comportare per l'unione tra Naz e AggNaz. La situazione attuale è la seguente:
  • il Template:AggNaz ha:
    • 292 sottopagine +
    • 477 redirect a queste sottopagine
  • il Template:Naz ha:
    • 857 sottopagine +
    • 1201 redirect a queste sottopagine
Attualmente ho creato Modulo:Nazioni/Nazioni facendo l'unione delle sottopagine di AggNaz e di Naz (ma senza tenere conto dei redirect). Quello che vi chiedo è:
  1. come mi devo comportare nei confronti dei redirect? Per esempio esiste la pagina Template:AggNaz/Abcasia, mentre Template:Naz/Abcasia è un redirect. Oppure può succedere il contrario, esiste la pagina Template:Naz/BGR 1946-1967, invece Template:AggNaz/BGR 1946-1967 è un redirect. Cerco di fare un elenco di queste situazioni. In questi casi chi va unito a cosa?
  2. sia le pagine di AggNaz che di Naz hanno un valore per lo stato ("st"). Cosa si fa se differisce? Per esempio per Template:AggNaz/USA è "Stati Uniti d'America", per Template:Naz/USA è "Stati Uniti".
--Rotpunkt (msg) 18:29, 24 mag 2015 (CEST)
ottimo che siano substabili; ho visto il codice, dove l'hai imparato quel trucco col safesubst? per le discrepanze che dici l'unica e fare volta volta come sembra meglio, per il nome decidi pure tu un criterio, tanto sarebbe comunque arbitrario; per BGR 1946-1967, se ha anche solo un campo diverso da BGR allora vanno lasciati due elementi separati, c'è poco da fare, a meno che... forse si potrebbe creare delle sotto-tabelle per le varianti di ogni nazione legate a certi periodi... per gli stati uniti tra le due preferirei la versione estesa, è più precisa. --ppong (msg) 22:40, 24 mag 2015 (CEST)
Il codice principale dev'essere l'ISO, se non esiste si può usare CIO o FIFA, se non esistono neanche questi si usa il nome; non vanno inventati codici. Il manuale di AggNaz lo dice chiaramente, il Naz meno chiaramente ma si è sempre fatto così.
Se il valore per lo stato differisce è perché in genere AggNaz è usato per le categorie automatiche (e allora siamo precisi), Naz per le bandierine (che vanno dentro tabelle ed elenchi, e si predilige la brevità). Forse è il caso di valutare quanti e quali differiscono, e se vale la pena di creare due dati "stato" e "stato esteso"--Bultro (m) 01:21, 25 mag 2015 (CEST)
Vi ricordo che esiste Template:Bandiera/Man/Codici. Forse è un po' incompleto perché non lo seguo da un po', ma lì ci sono tutti i confronti fra ISO, Altri codici (CIO, FIFA), Italiano e Altre lingue. --Mr buick (msg) 10:39, 25 mag 2015 (CEST)
[@ Mr buick, Bultro] Grazie per il link. Ho fatto un po' di analisi della situazione attuale a Utente:Rotpunkt/Nazioni/Elenchi, abbozzando una procedura di su come fare questa unione tra Naz e AggNaz. Potreste dare una occhiata? Questo vale anche per gli altri partecipanti alla discussione ovviamente. Modificate liberamente la pagina, siete più esperti di me su questi codici nazione. Bisogna inventarsi un processo per arrivare a dei Modulo:Nazioni/Nazioni e Modulo:Nazioni/Alias consistenti. Non so se è meglio analizzare tutti i codici adesso e poi fare una unica unione, oppure inserire prima quelli sicuri e poi successivamente a mano quelli da analizzare caso per caso. Qualunque confronto aggiuntivo vi serva (ho usato il sottolineato ma posso evidenziare i codici come meglio credete, esempio posso colorare quelli ISO, ...) ditemi pure. --Rotpunkt (msg) 13:24, 25 mag 2015 (CEST)
Temo sia inevitabile controllare caso per caso. Penso che convenga allineare AggNaz a Naz, e farlo prima, finché sono ancora sottopagine. Con la perdita delle sottopagine non si potrà più nemmeno usare il PuntanoQui per verificare quali pagine usano un certo codice? Brutta cosa... --Bultro (m) 23:45, 25 mag 2015 (CEST)
Ma "brutta cosa" de che? --Rotpunkt (msg) 02:11, 26 mag 2015 (CEST)

Modifica a {{Cancella subito}}

Segnalo. --Dry Martini confidati col barista 00:17, 24 mag 2015 (CEST)

Parametro filetype in Template:Divisa Calcio

Ciao a tutti, non si potrebbe inserire il parametro |filetype= nel template {{Divisa Calcio}} (come per altro è già presente in en.wiki o in es.wiki) in modo da potere utilizzare nel template anche pattern in .svg?--VALLATA 7-146 (parliamone!) 07:53, 26 mag 2015 (CEST)

✔ Fatto.--Moroboshi scrivimi 09:26, 26 mag 2015 (CEST)

Parentesi quadre nel {{nd}}

Segnalo --Horcrux九十二 13:03, 26 mag 2015 (CEST)

Box successione multiplo

Segnalo Discussioni template:Box successione#Caselle comuni--Bultro (m) 17:13, 26 mag 2015 (CEST)

Template area protetta

Segnalo questa discussione che potrebbe essere interessante per i progetto: https://it.wikipedia.org/wiki/Discussioni_template:Area_protetta#Importazione_automatica_da_Wikidata:_classificazione_internazionale_IUCN --Paolobon140 (msg) 14:42, 28 mag 2015 (CEST)

Cassettamento template di navigazione

cb La discussione prosegue nella pagina Wikipedia:Malfunzionamenti#Cassettamento_template_di_navigazione.
– Il cambusiere --Fringioα†Ω 13:57, 31 mag 2015 (CEST)

Singolo promozionale

Segnalo discussione.--Fringioα†Ω 20:05, 29 mag 2015 (CEST)

Template {{Arabo}}, {{Farsi}} e {{Curdo}}

Salve a tutti. Vorrei chiedere un aiuto per risolvere la questione che da qualche tempo affligge il Template in arabo ...? (e gli altri Template suelencati). Mentre prima essi funzionavano benissimo, da qualche tempo (settimana, mese?... non ricordo) il risultato prodotto è esteticamente orripilante. Non più il bel carattere naskhi (che è il più diffuso nel mondo arabografo), ma un pressoché inguardabile carattere adatto più che altro a una macchina per scrivere. Insomma, come se il font Times New Roman nelle lingue neolatine diventasse chissà perché uno squallido Courier o Pica.
Per avere il buon risultato visivo precedente, sono costretto a digitare lo scocciante [[Lingua araba|Arabo]] <big>parole</big>.
C'è modo di far lavorare decentemente il Template, sì da produrre lo stesso risultato ottenibile col comando [[Lingua araba|Arabo]] <big>parole arabe</big>?
Che poi, riflettendo, si potrebbe evitare il <big>parolearabe</big> semplicemente forzando le parole arabe a diventare con un un corpo maggiore rispetto a quello che si propone nel box sottostante l'area di lavoro, dove sono attivabili gli alfabeti estesi, stranieri e specialistici.
Help me, please!--Cloj 21:28, 1 giu 2015 (CEST)

Ti riferisci a questa differenza: مليلية (class="arabo") / مليلية (class="arabo" + lang="ar")? Se è così, allora la causa è una modifica risalente a quasi un anno fa.--Sakretsu (炸裂) 22:54, 1 giu 2015 (CEST)
Esatto. Caspita! Quasi un anno di simili brutture!
Non si può far niente? --Cloj 23:06, 1 giu 2015 (CEST)
Per caso usi Firefox? Il parametro lang riferisce al browser di quale lingua si tratti, di conseguenza Internet Explorer ad esempio continua a vedere il testo in maniera uguale, mentre Firefox cambia carattere. Non è un errore, è solo una questione di browser.---Sakretsu (炸裂) 23:48, 1 giu 2015 (CEST)
Ma non si potrebbe forzare la visualizzazione di una certa famiglia di font rispetto ad un altra?--Fringioα†Ω 23:59, 1 giu 2015 (CEST)
Si potrebbe aggiungere alla classe arabo. In effetti l'anomalia su Firefox sembra essere causata proprio dal sans-serif usato di default da Wikipedia: se si imposta serif si ha il normale مليلية.--Sakretsu (炸裂) 00:28, 2 giu 2015 (CEST)
Se ho capito bene, bisogna agire in MediaWiki:Common.css imponendo il "sans serif" nello stile della classe "arabo" (e "farsi" e "curdo"). Tra l'altro il font è già ingrandito e portato al 140% della dimensione normale, così come desiderato da Cloj . Occorre ingrandirlo ancora? [@ Bultro], cosa ne pensi? --Lepido (msg) 07:33, 2 giu 2015 (CEST)

(rientro) Vi sono grato. Credo che abbiate individuato il problema, anche se io non saprei mettere le mani per risolverlo.
Sì, in effetti uso Firefox. Vuol dire che lo abbandonerò fintanto che non si possa risolvere anche per questo browser il problema. Ed è vero che il carattere, da me richiesto a suoi tempo al caro cireneo Utente:gvf, era un po' grandicello (colpa mia). Forse dal 140% basterebbe diminuirlo al 120% Ancora grazie. Siete tutti gentilissimi. --Cloj 11:31, 2 giu 2015 (CEST)

[@ Lepido] Sì, con l'unica differenza che il problema sembra essere proprio il sans-serif, che su Firefox con lang impostato su "ar" provoca questo strano effetto. Nel mio messaggio precedente ho semplicemente forzato un altro font (il serif) e il carattere è tornato normale. Di conseguenza basta aggiungere font-family:serif; alla classe arabo/farsi/curdo nel css e la situazione dovrebbe tornare ad essere uguale su tutti i browser. Per quanto riguarda la %, io la lascerei così com'è, dato che mi pare sia necessaria ad esempio su Chrome, dove il carattere è molto piccolo.--Sakretsu (炸裂) 12:34, 2 giu 2015 (CEST)
OK. Per come fare, per me è però arabo :-) --Cloj 12:41, 2 giu 2015 (CEST)
io con chrome visualizzo la prima scritta in arial (serif cufico piuttosto stretto) e la seconda in Segoe UI (sans naskhi similmente stretto), su IE vedo entrambi in arial. siccome aggiungere classi generiche non mi sembra una buona idea (l'arial sarebbe un sans in caratteri latini, e il Segoe un serif!) propongo di impostare il font-family a una serie di famiglie di caratteri precise. per il primo posto propongo il tahoma, che è un sans naskhi più largo dei precedenti; non ne conosco altri, ma il Segoe lo metterei dopo.
l'avevo scritto in un'altra discussione, ma già che ci sono lo ripeto: io diminuirei al 120% la dimensione delle scritte arabe. --ppong (msg) 17:04, 2 giu 2015 (CEST)
Andato ora su Chrome. La scritta araba appare orrendamente identica a quella che mi dà Firefox, con in più il difetto che, se provo a sostituire il Template col mio escamotage, la scritta appare piccola e, per portarla al livello dovuto, sono costretto a mettere un doppio <big><big></big></big>. --Cloj 17:57, 2 giu 2015 (CEST)
Orrendo! Con Explorer mi dà la scritta come deve essere. Ma io non amo questo browser. Mi devo rassegnare? --Cloj 18:04, 2 giu 2015 (CEST)
Il problema è che a quanto pare non siete tutti d'accordo sulla stessa famiglia di font da usare. Il risultato di Firefox sarebbe proprio il Tahoma citato da ppong (o almeno ho fatto una prova e le due versioni mi appaiono identiche). A questo punto Cloj ti scrivo in talk, così da suggerirti un metodo per visualizzare il font che vuoi tu su qualsiasi browser.--Sakretsu (炸裂) 18:31, 2 giu 2015 (CEST)
Mi sembra proprio che tu abbia risolto la mia angosciante situazione. Grazie davvero. Ma un grazie a tutti per questa dimostrazione della bontà del "sapere diffuso" che caratterizza il nostro Progetto. Shukran giazīlan (grazie molte). --Cloj 19:02, 2 giu 2015 (CEST)
Il grande Utente:gvf ha risolto per tutti i browser la questione. Il mio ringraziamento anche a lui, ovviamente. Anche perché gli rompo spesso gli zebedei per l'arabo e lui ancora non mi ci ha mandato. Sono commosso e giulivo. Alf shukran (Grazie mille).--Cloj 20:00, 2 giu 2015 (CEST)

──────────────────────────────────────────────────────────────────────────────────────────────────── non sono d'accordo con la soluzione attuata, infatti se si voleva il tahoma, bisognava impostare il tahoma, e non il generico "serif", che come soluzione è anti-logica (il tahoma non ha grazie, i caratteri arabi arial sì) e inefficiente: io su IE adesso mi vedo comparire i caratteri arabi in times new roman, che è un serif cufico come l'arial. insomma le possibili soluzioni logiche erano e sono due:

  • lasciare scoperta la proprietà e lasciare che ogni utente la visualizzasse a seconda del browser (firefox dovrebbe avere un sistema di personalizzazione avanzato, più o meno efficiente, e poi ci sono i css utente)
  • impostare una famiglia di caratteri precisa, in questo casa il tahoma, se ho capito quello che Cloj aveva in mente. --ppong (msg) 21:02, 2 giu 2015 (CEST)

(rientro) A me il naskhi va benone, ma non so a quale font bisogna riferirsi. L'importante è che il risultato sia proprio come questo: .--Cloj 21:26, 2 giu 2015 (CEST)

No ppong, se ho capito bene quello che non si voleva era proprio il tahoma, che fa apparire il testo così مليلية. Tra l'altro a me su Internet Explorer non è cambiato nulla: sia prima che dopo la modifica il risultato è rimasto questo (ossia quello voluto da Cloj, che ora è presente anche su Firefox). Poi onestamente, non intendendomene di arabo, non so quale carattere sia il migliore, quindi vi sto solo riferendo la situazione almeno così come mi appare su questi due browser.--Sakretsu (炸裂) 21:53, 2 giu 2015 (CEST)
Cloj, il problema è che bisogna considerare che usiamo un mezzo elettronico e i font digitali non è che corrispondano proprio alla tradizione calligrafica araba, anche se la seguono. dovremmo guardare alla condizione dei font. ecco quelli che conosco disponibili su windows:
  • tahoma: مليلية ﻭﺍﻟﻲ ﺍلاﻣﺮ
  • segoe UI: مليلية ﻭﺍﻟﻲ ﺍلاﻣﺮ
  • arial=times new roman: مليلية ﻭﺍﻟﻲ ﺍلاﻣﺮ[nota 1]
ho trovato questo articolo che mostra i font di google early access, così puoi farti un'idea più ampia dello stato dell'arte[nota 2]. ho trovato interessante anche questo articolo. ripeto che impostare globalmente una famiglia di caratteri generica come "serif" sarebbe un errore nel nostro caso e faccio notare che così come corre una grande differenza tra alfabeto latino manoscritto e stampato, così vale imo la pena anche per l'arabo privilegiare su wikipedia la leggibilità sugli schermi piuttosto che l'eleganza calligrafica. --ppong (msg) 11:49, 3 giu 2015 (CEST)
Del primo esempio trovo migliore esteticamente il font amiri serif.
Guarda comunque che il naskhi è usato da quasi tutte le case editrici e dall'editoria più diffusa (giornali e riviste). Non ho detto il diwani o il riga'i, davvero troppo "arabescheggianti". Il naskhi è elegante ed è il più leggibile. Tutti i font diciamo così "senza grazie", sono orridi agli occhi di ogni arabografo.
Non saprei cosa scegliere. Forse mi aiuterebbe un esempio in arabo meno dominato da caratteri a sviluppo verticale e del tutto orizzontale. Proverei in arabo ﻭﺍﻟﻲ ﺍلاﻣﺮ?.
Piuttosto, perché gli anglofoni wikipediani hanno per il persiano il nastaliq, che è il loro stile calligrafico nettamente dominante e caratterizzante la cultura persiana, e noi no? Siamo i fratelli più scemi? :-D. Ciao. --Cloj 12:44, 3 giu 2015 (CEST)
Ma il fatto che questi font siano per natura troppo piccoli e debbano essere ingranditi è un problema di Mediawiki o è diffuso? sembra un'assurdità che per leggere normalmente ci voglia una forzatura.
In ogni caso, non converrebbe vedere come si comportano ar.wiki e fa.wiki? --Bultro (m) 13:04, 3 giu 2015 (CEST)
diffuso e fisiologico, non chiedermi perché. ar.wiki usa l'arial per le intestazioni e non specifica famiglie di caratteri per il corpo del testo, fa.wiki ha queste specifiche per tutto il testo: «font-family: Tahoma,'Iranian Serif','Noto Kufi Arabic','Droid Arabic Naskh','Iranian Sans','DejaVu Sans',serif;[nota 3]» non proprio coerentissime tra loroQuesto commento senza la firma utente è stato inserito da Ppong.it (discussioni · contributi) 13:16, 3 giu 2015 (CEST).
a proposito di cio che diceva Cloj: su en.wiki ci sono i template Script/Nastaliq e Script/Arabic che assegnano al testo una famiglia di caratteri da serie piuttosto diverse (e più coerenti) da quella usata da fa.wiki; quella per l'arabo è «font-family:Scheherazade,Lateef,Arial,'Arabic Transparent','Droid Arabic Naskh',Amiri,'Microsoft Sans Serif','Segoe UI','Sakkal Majalla','Microsoft Uighur','Arabic Typesetting',sans-serif,serif;» per il nasta'liq dipende. va detto comunque che il template equivalenti ai nostri {{arabo}} e {{farsi}} non hanno queste proprietà, non so perché. un'altra cosa è che io, non avendo sul mio pc nessun font nasta'liq, vedo questo testo di en.wiki in arial e basta.
a questo punto comunque mi imposto le mie preferenze tramite css e me ne lavo le mani. --ppong (msg) 16:09, 3 giu 2015 (CEST)
Mi sbilancio a pensare che questa segnalazione sia collegata a questo argomento :-) --Pil56 (msg) 10:44, 4 giu 2015 (CEST)

  1. ^ seconda parte del testo (a sinistra) aggiunta in seguito a richiesta
  2. ^ per errore il lateef è mostrato uguale al droid naskh, mentre sarebbe più simile al sherazade.
  3. ^ la prima famiglia di caratteri disponibile viene utilizzata, perciò il tahoma è quello che compare a tutti o quasi.

Template bio: "è stato" etc

cb La discussione prosegue nella pagina Discussioni progetto:Biografie/Varie#Template_bio:_.22.C3.A8_stato.22_etc.
– Il cambusiere --Rotpunkt (msg) 13:03, 3 giu 2015 (CEST)

Subst

Nell'accingermi ad aggiungere dei nuovi pulsanti della toolbar per le PDC come richiesto mi sono accorto che ad alcuni template {{Tenere}}, {{Cancellare}}, {{Commento}}, {{Cancellare subito}}, {{Favorevole}}, {{Favorevole se}}, {{Neutrale}} nell'agosto 2014 Horcrux92 aggiunse nella sintassi l'utilizzo del subst (forse per uniformità con alcuni di quelli nella lista che lo avevano già). Ora, premettendo che il subst, a parte più che rarissime eccezioni, non si usa per ragioni di performance, qui l'unico senso che trovo potrebbe essere per evidenziare meglio un cambio fraudolento di voto? Mi sembra strano, perché anche con il subst basta poi cambiare il wikitesto. Personalmente non ho mai visto usare il subst con quei template, anche se qualcuno l'avrà magari fatto. Se nessuno vede controindicazioni passerò a rimuovere dai manuali quel subst. --Rotpunkt (msg) 09:28, 5 giu 2015 (CEST)

Io ho sempre (o quasi) substato ogni template del genere e non mi ero mai chiesto perché il man indichi di far così, lo facevo e basta. Alcuni hanno tale sintassi suggerita da anni. --Umberto NURS (msg) 09:48, 5 giu 2015 (CEST)
Diciamo che ora potrai dire di *non* farlo a ragion veduta :) Mi sono già trovato in altre occasioni a spiegare quando è corretto usare il subst e quando no, l'ultima qui, se volessi leggerla per non ripeterlo. --Rotpunkt (msg) 10:09, 5 giu 2015 (CEST)
Come Umberto NURS, mi adeguai semplicemente all'utilizzo generale di quei template (lo stesso vale per {{fatto}} e {{non fatto}}). L'unica differenza, a parte le performance -di cui non dovrebbe importarci-, è che la trasclusione permette di aggiornare in massa inserendo immagini migliori o aggiornando il nome delle immagini. A me personalmente non cambia nulla, hai carta bianca. Lascerei comunque la possibilità (anche se non la regola) di substare, inserendo dei "safesubst:" quando vengono usate funzioni parser, moduli o magic word. --Horcrux九十二 12:39, 5 giu 2015 (CEST)
@Horcrux grazie. Certamente, agisco solo sui manuali non sui template. --Rotpunkt (msg) 13:26, 5 giu 2015 (CEST)

Parametro "Titolo alfabetico" in {{Fumetto e animazione}}

Segnalo discussione.-- Fringioα†Ω 14:59, 7 giu 2015 (CEST)

Problema parametro url

Nel {{LSJ}} il parametro url, che un tempo restituiva un link, ora non funziona più (es. Propilei): che cosa c'è che non va? Grazie, --Epìdosis 10:34, 8 giu 2015 (CEST)

[@ Epìdosis] credo dipendesse solo dal fatto che con questo edit avevi scritto {{#if:{{{2|}}} invece di {{#if:{{{url|}}}, facendo una prova era sfuggito anche a me. --Rotpunkt (msg) 10:57, 8 giu 2015 (CEST)
Aggiungo che non è corretto aver chiamato quel parametro "url": non è un URL, è un codice che va a creare l'URL. In en.wiki (en:Template:LSJ) lo chiamano "beta code" perché (non me ne intendo) pare essere il en:Beta Code. Se è così allora sarebbe da rinominare url in beta_code (se invece può rappresentare anche altro rinominarlo "id", "codice", "entry" o simili). --Rotpunkt (msg) 11:18, 8 giu 2015 (CEST)
[@ Rotpunkt] In teoria sarebbe corretto "beta_code", ma preferirei un breve "id" perché sarebbe più veloce da inserire: per me, se riesci a sostituire via bot tutti gli "url" con "id", puoi procedere col cambio di nome, più che giusto. --Epìdosis 14:06, 8 giu 2015 (CEST)
[@ Epìdosis] Fatto. Ho anche trovato un template nella voce Arconte (nella bibliografia) senza parametro url. Se puoi, dagli un'occhiata.--Sakretsu (炸裂) 14:44, 8 giu 2015 (CEST)

Template Box Wikidata

Segnalo discussione. --Rotpunkt (msg) 13:50, 8 giu 2015 (CEST)

Template di blocco infinito: ne regoliamo meglio l'uso?

Attualmente, nel caso di blocco infinito degli utenti, è previsto che nella pagina utente e/o nella talk dell'utenza bloccata vengano inseriti gli appositi template ({{BloccoInfinito}}, {{NUI}}). Nel caso in cui pagina utente e/o talk fossero ancora completamente vuote, questo implica crearle ex-novo. Tuttavia, ci sono dei casi in cui sarebbe opportuno invece non creare ad hoc queste pagine, ad esempio nel caso di utenti con un nome direttamente offensivo nei confronti di persone, gruppi di persone, altri utenti Wiki, religioni, aziende, squadre eccetera, oppure nel caso di utenze sockpuppet. Vero che dovrebbe bastare WP:BUON SENSO, ma, senza formalizzare il tutto come linea guida, se ci mettessimo d'accordo su un uso "coordinato" di tali template? Una possibile proposta di partenza potrebbe essere questa:

  1. Nel caso di utenze con NUI pesantemente offensivo, si cancellano e proteggono talk e user page, senza mettere alcun template.
  2. Nel caso di utenze sockmaster, invece del {{BloccoInfinito}}, usare {{Sockpuppet bloccato}}, inserendolo sia nella talk che in user page.
  3. In tutti gli altri casi, inserire il solo {{BloccoInfinito}} nella talk. Per quanto riguarda la user page, proporrei di inserirlo solo se questa non è già completamente vuota (se fosse vuota ma "creata", perché ad esempio svuotata, a quel punto meglio cancellarla).

Chiaramente, eventuali tool automatici (es. il tool specifico di CU per il blocco multiplo) andrebbero aggiustati di conseguenza (per esempio, consentendo il blocco senza però obbligare a scrivere qualcosa in talk+user page). Pareri? --L736El'adminalcolico 15:31, 8 giu 2015 (CEST)

Sì, per me va bene; per la 2, di solito metto il bloccoinfinito nella talk e il sockpuppetbloccato nella PU. --Euphydryas (msg) 16:03, 8 giu 2015 (CEST)
Oltre a regolarne l'uso "in negativo" (quando non usarlo), bisognerebbe regolarne l'uso anche "in positivo" (cioè quando usarlo e soprattutto come).
Quasi sempre (se non sempre) l'ho visto usato sostituendo totalmente le pagine, quindi cancellando totalmente l'eventuale contenuto della pagina. Ma, a differenza dell'utilità e del senso di mettere un avviso che capisco (per far capire agli altri utenti che è impossibile ad es. scrivere a quell'utente e perché), perché mai si dovrebbe svuotarle? Così si cancellano anche le eventuali parti relative ai contributi utili, non solo ma anche messaggi relativi a questioni problematiche (tra cui il problema che ha portato al blocco) potrebbero essere utili. Così come si fa ora (a proposito, dov'era stato deciso e come?) sembra una damnatio memoriae (già ora ci sono non pochi utenti che sostengono che "tutti i contributi degli utenti bloccati vanno rollbackati", magari non come loro parere personale ma sostenendo anche che sia già previsto così, cosa che per fortuna non è!).
Ovviamente possono esserci casi particolari, ad esempio una pagina con solo un messaggio d'insulti va cancellata prima dell'inserimento di questo template di avviso. (Ma questo è già previsto non solo implicitamente da WP:BUON SENSO ma anche esplicitamente da WP:IMMEDIATA). --5.170.69.178 (msg) 16:33, 8 giu 2015 (CEST)
(f.c.)Wikipedia:Politiche_di_messa_al_bando_degli_utenti#Rollback --Bramfab Discorriamo 00:02, 9 giu 2015 (CEST)
@IP: Di solito (se non sempre) le pagine si svuotano quando contengono solo avvisi di servizio. Se invece le pagine contengono discussioni utili, si inserisce {{blocco|motivazione|infinito}} in fondo, come semplice messaggio. --Horcrux九十二 16:46, 8 giu 2015 (CEST)
Gentile IP (ci conosciamo già?), le talk degli infinitati si svuotano, non si cancellano, e nel caso fosse necessario leggere ancora qualcosa si può ritrovare semplicemente in cronologia: quindi, di cosa parli? E riguardo agli edit degli infinitati da rollbackare, ti consiglio di (ri?)leggere le linee guida. --Euphydryas (msg) 16:54, 8 giu 2015 (CEST)
In linea di principio sono d'accordo con la proposta di L736E. In realtà fin qui però quando la talk non è ancora stata creata (perché l'utente ha iniziato a vandalizzare a raffica prima dell'arrivo del Benvebot o per altri motivi) in genere non ho ritenuto opportuno crearla con {{bloccoInfinito}}. In quei casi mi limito a proteggere--Formica rufa 09:04, 9 giu 2015 (CEST)
Euphydryas (può anche essere che ci "conosciamo" già, non ricordo): Questa discussione ha nel suo titolo "ne regoliamo meglio l'uso" e in Template:BloccoInfinito/man non trovo alcun accenno al che si possa (o perfino debba) svuotarle (che è pur sempre una cancellazione, se ad esempio rimuovo una sezione non enciclopedica da una voce posso dire del tutto correttamente, anche se recuperabile dalla cronologia, di averla cancellata. O anche quando un utente si toglie un avviso che ha ricevuto in pagina di discussione gli si dice "Non cancellare gli avvisi". Quindi non vedo perché mi si debba rispondere con toni del tipo <<quindi, di cosa parli?>> che sarebbero scortesi comunque anche se avessi sbagliato e detto involontariamente uno strafalcione), pertanto proponevo di chiarire meglio le istruzioni, ovviamente prima discutendo e scegliendo cosa sia meglio fare. Pensavo si capisse da <<bisognerebbe regolarne l'uso anche "in positivo" (cioè quando usarlo e soprattutto come)>>.
Se si tratta effettivamente, mi sa che non avevo mai guardato, di uno svuotamento e non di una cancellazione irreversibile (per un utente medio senza diritti particolari di amministratore) effettivamente hai ragione che si può vedere in cronologia.
Ma non capisco proprio che ragione tu abbia (discutiamone, come ho appena scritto) a definirlo "semplicemente". Semplice sarebbe leggere direttamente nella pagina, come avviene per gli utenti non bloccati. Per guardare nella cronologia, oltre a richiedere più tempo e di scaricare più pagine, richiede che l'utente che legge si accorga che esiste un contenuto in cronologia che è stato svuotato, e per far ciò deve prima venirgli in mente che possa essere così (cosa non così facile, perché tale svuotamento non è per nulla standard per le pagine di discussioni, i cui contenuti si archiviano, non si cancellano/svuotano), e prendersi la briga di andare a guardare in cronologia se ci siano delle altre versioni visibili. Come ho appena scritto mi sa che io non ho mai guardato. Ok, non sarà una cosa complicatissima come una scalare una vetta a mani nude, ma tutto questo "semplicemente" non lo vedo.
Tutto questo a fronte di nessuna motivazione o vantaggio di svuotare/cancellare (tranne, come avevo specificato, i casi in cui un motivo ci fosse, ad esempio una pagina con solo un messaggio d'insulti). --5.170.61.78 (msg) 23:29, 10 giu 2015 (CEST)
d'accordo in tutto con l'IP. --ppong (msg) 12:58, 11 giu 2015 (CEST)

──────────────────────────────────────────────────────────────────────────────────────────────────── Caro IP, ma hai presente il testo del template {{BloccoInfinito}}? Te lo riporto qua sotto, e capirai da dove salta fuore il discorso dello "svuotamento":

Questo spiega il discorso dello "svuotamento": agli utenti bloccati infinito, per prassi (ma se non ricordo male, fino a non molto fa era pur scritto esplicitamente da qualche parte) si svuota la talk e la user page, salvando la cronologia. Quindi, tutto il tuo discorso lascia un po' il tempo che trova e fa solo divagare dal tema del thread (regolare l'uso del template in modo da non abusarne). Cerchiamo di restare in-topic per favore. Grazie. --L736El'adminalcolico 09:34, 12 giu 2015 (CEST)

lo riporta, sì, ma non è che lo spiega, assolutamente. --ppong (msg) 16:41, 12 giu 2015 (CEST)
Concordo in tutto con la proposta di [@ L736E]. --Fullerene (msg) 00:11, 16 giu 2015 (CEST)

Pagine lente e possibili conversioni a Lua

Da un paio di giorni, i sistemisti WMF stanno pubblicando alcuni dati (che esistono da anni) sulle pagine lente a caricarsi, cioè dove il parser di MediaWiki impiega vari secondi a produrre l'HTML. Le pagine lente sono frustranti specialmente per gli utenti registrati e per chi fa anteprima prima di salvare una modifica. La situazione è migliorata molto grazie alla conversione a moduli Lua, ma magari la lista serve a identificare qualcos'altro che vale la pena di fare. Esempio di ieri: Arrens-Marsous impiega 22,31 secondi. --Nemo 15:45, 8 giu 2015 (CEST)

[@ Nemo bis] Qualcosa non mi torna con Arrens-Marsous: già a occhio la pagina non sembra particolarmente pesante, e andando infatti a vedere il report nel sorgente HTML si trova mezzo secondo, non 22. Anche l'Anteprima la si ottiene immediatamente. Quindi sarebbero dati sì utili, ma non capisco i 22,31 secondi da dove nascono. Un problema del server in quel momento? --Rotpunkt (msg) 15:56, 8 giu 2015 (CEST)
Mi si apre alla stessa velocita' di simili pagine.--Bramfab Discorriamo 11:25, 9 giu 2015 (CEST)
[@ Bramfab] Quei dati non erano relativi all'"apertura" delle pagine. Come ben saprai la trasformazione wikitesto => HTML non avviene ogni volta che carichi una pagina, ma solo quando la salvi o esegui l'anteprima (o quando cambia uno dei template inclusi, ma in questo caso attraverso una coda di lavoro, o se lo forzi con action=purge) e quei tempi sono appunto relativi al passaggio wikitesto => HTML non all'apertura di una pagina. Il tempo di caricamento di una pagina dipende invece da altri fattori, non misurabili lato server, perché relativi al client (velocità del computer, tipo di browser, banda, ... ). --Rotpunkt (msg) 11:42, 9 giu 2015 (CEST)
In ogni caso apertura, anteprima, salvataggio sempre nella media.--Bramfab Discorriamo 11:55, 9 giu 2015 (CEST)
a parte qualche comune francese messo in mezzo evidentemente per un temporaneo problema dei server, le voci più lente sono quelle di sport e di matematica e fisica. da tradurre in lua ci sarebbero le varie bandierine e naz, (se ne sta occupando Rotpunkt) oltre che RisF1 e RisMoto. per le voci di matematica e fisica la responsabilità evidentemente è delle formule in tex. --ppong (msg) 12:58, 11 giu 2015 (CEST)
Non so se aiuterebbe i server, ma certamente aiuterebbe gli utenti anche realizzare in Lua i Categoria:Template torneo. Invece di quella giungla di template sarebbe bello avere una funzione unica dove si decide con parametri la profondità del torneo, il numero di gare, la presenza di finalina ecc. --Bultro (m) 00:43, 12 giu 2015 (CEST)
ho iniziato a lavorare su una conversione in lua di RisF1 e RisMoto. --ppong (msg) 02:16, 13 giu 2015 (CEST)

Traduzione parametri

Segnalo discussione.-- Fringioα†Ω 19:18, 14 giu 2015 (CEST)

Template per i manuali

In en.wiki hanno due template en:Template:Lua e en:Template:Uses Wikidata (quest'ultimo più recente), per indicare su quali moduli Lua e su quali proprietà Wikidata è basato il template. Esempio di manuale con entrambi: en:Template:Infobox bone. Il template:Lua è inoltre presente in altre cinquanta wiki, con lo stesso aspetto o diverso.

Mi sembra che sarebbero comodissimi anche da noi: il primo en:Template:Lua per uniformare in tutti i manuali l'informazione "Questo template è basato sul modulo ..." (ora invece è scritta un po' ovunque, nell'incipit, in una sezione o nelle voci correlate), il secondo, en: Template:Uses Wikidata, per uniformare l'informazione delle proprità Wikidata usate (in questo caso avevo preso l'abitudine di creare una sezione "Wikidata" ma con questo template sarebbe più chiaro e evidente). L'inserimento dei template categorizzerebbe inoltre i template in Categoria:Template che usano dati di Wikidata e in una nuova Categoria:Template basati su moduli Lua di cui c'è bisogno, senza doverle inserire a mano.

Riguardo all'aspetto del template vanno bene come in en.wiki, laterali, o è meglio averli orizzontali come per il {{Template complesso}}? Ho fatto una prova in due sandbox (solo per l'aspetto grafico, non ho ancora scritto i template):

Ovviamente poi li implementerò in modo più semplice che in en.wiki, dove sono basati su template e moduli che non esistono da noi. --Rotpunkt (msg) 09:02, 16 giu 2015 (CEST)

mi sembrano info utilissime e trovo più appropriata la versione con i box sulla destra, per non appesantire troppo l'inizio. --Superchilum(scrivimi) 09:20, 16 giu 2015 (CEST)
Non sarebbe male IMHO studiare una maniera per snellire e (magari) accorpare questi template - alla fine sono indirizzati all'utente "avanzato" che comunque sa come muoversi - ma portano via un sacco di spazio all'inizio del manuale che spiega come usare il template, che è quello che serve alla maggior parte degli utenti che visitano la pagina (ovviamente nell'ipotesi ottimistica dell'utente che effettivamente consulti il manuale del template ). A me (e a chi manipola abitualmente i template) il messaggio " Questo template ha un codice sorgente piuttosto complesso.....eccc..." che si porta via cinque/sei righe dalla testata della voce serve a poco perchè tanto lo so già, all'utente occasionale non serve perchè tanto non ha intezione di modificarlo (e anche se lo volesse probabilmente il template è protetto). E con l'aggiunta dei messaggi per wikidat/Lua si allungherebbbe ancora di più lo spazio preso. Non sarebbe il caso di compattare magari in un'unica riga il messaggio "Questo è un template complesso" con il resto delle spiegazioni cassettato (e modificarlo in modo che informazioni aggiuntive come Lua/Wikidata siano incluse? Per esempio visualizzando solo il fatto che include moduli Lua, ma il dettaglio dei moduli inclusi cassettato)? --Moroboshi scrivimi 10:18, 16 giu 2015 (CEST)
@Moroboshi D'accordissimo sullo snellire il {{Template complesso}}. Inoltre lo rimuoverei dai template che si basano esclusivamente su un modulo. Esempio lo rimuoverei dal template {{Bio}} che è una sola riga {{#invoke:Bio|bio}}, utilizzandolo invece dove, come dice la descrizione, c'è una complessità dovuta a funzioni parser. Riguardo a cassettare, non sono sicurissimo, in realtà a me capita spessissimo di voler raggiungere la pagina di un modulo per modificarlo, passando per il template, e sarebbe bello che il link fosse evidente. Riguardo ad accorpare sì, si potrebbe, tuttavia fare troppe cose insieme non so se è una buona idea, inoltre lasciarli separati è un po' più flessibile. Come vedresti il fatto di (1) rimpicciolire il {{Template complesso}}e rimuoverlo dove non necessario (2) inserire i nuovi template per Lua e Wikidata lateralmente (alla fine i template che avranno questi due nuovi template sono un piccolo sottoinsieme) (3) passato qualche mese di tempo di assestamento e sperimentazione per vedere come va, pensare a una unificazione? Comunque se vuoi fare una prova di aspetto grafico con tutto incluso vediamola pure. --Rotpunkt (msg) 10:40, 16 giu 2015 (CEST)
Per quanto riguarda Wikidata sarebbe più utile assegnare a {{Parametro}} un colore o altra simbologia che indica direttamente che il tal parametro ha la lettura automatica da Wikidata.
Il resto fa parte della realizzazione interna del template ed è una cosa che non ha importanza per l'utilizzatore semplice (anzi lo può "spaventare"...), perciò io metterei il tutto in basso, in fondo al manuale, magari in una sezione con un titolo standard (da stabilire) --Bultro (m) 13:04, 16 giu 2015 (CEST)
In basso è l'ultimo posto dove li metterei. Sono al contrario importanti per l'utilizzatore (come l'"utilissimi" per Superchilum), non c'è niente da nascondere. In tutte le altre wiki il template Lua è infatti in alto, comprese quelle che lo rendono orizzontale (vedi fr:Modèle:Coord, es: Plantilla:Cita libro, ru:Template:coord). --Rotpunkt (msg) 13:17, 16 giu 2015 (CEST)
Spiegami cosa glie ne frega, a uno che deve mettere il Bio in una voce, di sapere se è fatto con un modulo o con gli #if --Bultro (m) 13:51, 16 giu 2015 (CEST)
Io concordo con Rotpunkt, non devono prendere eccessivo spazio (vedi precedente intervento), ma servono comunque a colpo d'occhio a vedere su cosa è basata come dipendenze un template senza dover aprire il codice. @Rotpunkt, stasera provo a fare qualche test di stile riguardo al solo {{Template complesso}}.--Moroboshi scrivimi 13:55, 16 giu 2015 (CEST)

Icona evento sportivo

Ciao, volevo aggiungere l'icona dei giochi europei nel template {{Icona evento sportivo}} ma quando la aggiungo viene gigante, e non capisco come mai....ho annullato la modifica, si può vedere nella cronologia, con data di oggi --☤ GAMBO ➐ ☤...problemi? ✍ 11:50, 16 giu 2015 (CEST)

[@ Gambo7] L'ultima versione prima che ti annullassi era corretta, probabilmente non avevi aggiornato la cache nella pagina dove stavi testando. Comunque c'è sempre Template:Icona evento sportivo/Sandbox per fare le prove. La creo con la tua ultima versione. Forse è anche un template da proteggere (e da documentare). --Rotpunkt (msg) 12:14, 16 giu 2015 (CEST)
Ecco: {{icona evento sportivo/Sandbox|Giochi europei}} =>
--Rotpunkt (msg) 12:19, 16 giu 2015 (CEST)
Grazie...
Avevo aggiornato la cache e testato su varie voci ma mi veniva sempre gigante.... Come mai alla fine spunta quel {{!}} da solo?! --☤ GAMBO ➐ ☤...problemi? ✍ 18:04, 16 giu 2015 (CEST)
Prego. Non ho solo capito a quale {{!}} ti riferisci che spunta da solo. Nel template o quando lo usi il template? --Rotpunkt (msg) 21:49, 16 giu 2015 (CEST)
A questo, io non lo avevo messo ma quando ho salvato è spuntato da solo. --☤ GAMBO ➐ ☤...problemi? ✍ 18:29, 17 giu 2015 (CEST)

Eliminare parametro da {{references}}

Segnalo discussione.-- Fringio – α†Ω 16:33, 25 giu 2015 (CEST)

Template Osservatorio

Ciao, mentre mi stavo occupando di coordinate nei template e loro lettura da Wikidata, sul template Osservatorio, usato in sole 53 voci, dove avrei anche reso minuscoli i parametri per uniformità, è intervenuto Bultro con questa frase: << Evitiamo di fare cambi maiuscolo/minuscolo finché non si decide ufficialmente uno standard. Magari come numero di template prevale il minuscolo, ma il maiuscolo è usato ad esempio dal Bio e dal Divisione amministrativa che sono tra i più diffusi in ns0 >>. Vedi discussione a Discussioni_template:Osservatorio.

Ora premesso che:

con queste premesse, mi chiedo se c'è qualcun altro contrario al fatto che renda minuscoli i parametri del template Osservatorio, usato in sole 53 voci!, per uniformarli tra loro (Nome maiuscolo, ma poi telescopio1_nome minuscolo) e al collegato {{Telescopio}}. --Rotpunkt (msg) 09:27, 26 giu 2015 (CEST)

In generale a favore per uso delle minuscole per i nomi di parametri. I vari CamelCame o Primamaiuscola, imho portano più a confusione per il ricordarsi quando usare uno o l'altro.--Moroboshi scrivimi 09:59, 26 giu 2015 (CEST)
Se dobbiamo decidere uno standard, io propenderei per l'iniziale minuscola e per gli spazi tra le parole (ricordiamoci che esistono anche template come {{Film}} che presentano parametri del tipo "titolooriginale").--Sakretsu (炸裂) 13:08, 26 giu 2015 (CEST)
due parole sulla questione standard parametri:
  • è una questione che abbiamo rimandato a lungo ma imo vale la pena di affrontare, sia per quanto riguarda le maiuscole, sia per le spaziature, sia per le abbreviazioni
  • "minuscolizzare" un template non è certo grave, ma metti che qualcuno la veda diversamente da te: potrebbe maiuscolizzare un altro template e vai di tela di penelope. quando Moroboshi aggiornò i template di citazione dovette fermare il lavoro fintanto che non si fece il sondaggio sullo stile.
quindi secondo me per questa faccenda la prima cosa da fare sarebbe stabilire lo standard. --ppong (msg) 13:22, 26 giu 2015 (CEST)
@Sakretsu, io mi uniformerei alla minuscola iniziale e agli underscore per due motivi: (1) la maggior parte dei template è già così sia da noi che su en.wiki mi sembra, e (2) dal punto di vista teorico sono variabili, e in quanto tali si scrivono con l'iniziale minuscola (e senza spazi). Infatti nell'ambito dei template engine sono solitamente scritte con l'iniziale minuscola, prendo ad esempio il Python, ma ne cercherò altri: vedi gli esempi qui o nello specifico per Django qui. --Rotpunkt (msg) 13:31, 26 giu 2015 (CEST)
Altri esempi da Apache Velocity (qui) dove scrive << where the template we used, testtemplate.vm, is: Hi! This $name from the $project project. >> e Cheeta (qui). --Rotpunkt (msg) 13:52, 26 giu 2015 (CEST)
@Ppong e agli altri: io comunque non ne farei una guerra di religione. Si può mettere in Aiuto:Template che è preferibile per esempio scriverli con l'iniziale minuscola ma se un nuovo utente ignaro di questo creasse un template nuovo con le iniziali maiuscole non è che sarebbe un dramma. I principali template sinottici per ogni argomento praticamente esistono già, addirittura sarebbe da accorparli per ridurli. Inoltre il rischio che qualcuno si metta sistematicamente a trasformare tutti i parametri in maiuscolo o minuscolo mi sembra abbastanza remoto, è un lavoraccio che personalmente non ho mai visto fare. L'ho proposto giusto per Osservatorio perché aveva parametri maiuscoli e minuscoli e perché c'erano poche voci. --Rotpunkt (msg) 14:08, 26 giu 2015 (CEST)
Come ppong. Sull'iniziale non ho preferenze, ma come separatore meglio gli spazi --Bultro (m) 00:13, 27 giu 2015 (CEST)
Io solitamente non entro in merito a queste discussioni ma avendo tutto il giorno a che fare con i template nel scegliere i parametri ammetto che non creerebbe troppa differenza dare un iniziale maiuscola o minuscola ma IMO faccio meno confusione se fossero tutti senza spazi e in minuscolo in caso di più parole (es. "titolooriginale"). --Torque (scrivimi!) 12:32, 30 giu 2015 (CEST)
Grazie Torque per la aver espresso la tua esperienza, riassumendo direi che riguardo a maiuscole/minuscole dei parametri c'è una convergenza nel dire che si può indicare in Aiuto:Template (con una espressione come "è preferibile") di usare i nomi dei parametri con tutte le lettere in minuscolo (senza iniziale maiuscola e CamelCase). Riguardo agli spazi ci sono pareri contrapposti e c'è probabilmente troppa varietà nei template (ci sono quelli che non li usano mai, chi usa l'underscore, chi usa gli spazi), su questo punto si potrebbe quindi lasciare libertà senza dare indicazioni. --Rotpunkt (msg) 13:05, 30 giu 2015 (CEST)
Favorevole a consigliare le minuscole, è un inizio. per gli spazi effettivamente servirebbe un grosso lavoro di uniformazione, quindi prima sarà meglio avere le idee davvero chiare. già che ci sono però dirò che "titolooriginale" sembra forse un errore; capita mai che un nuovo utente inserisca uno spazio pensando di correggerlo? --ppong (msg) 13:17, 3 lug 2015 (CEST)
Favorevole ad inserire in Aiuto:Template" il consiglio di usare le minuscole per la prima lettera dei parametri. Per dividere invece più parole io preferisco lo spazio, standard usato in tutte le lingue del mondo e che permette di poter leggere il tutto senza problemi (al contrario dei nomi parametri scritti tutti attaccati). -- Gi87 (msg) 14:03, 3 lug 2015 (CEST)

Template strano

Ciao a tutti, segnalo questo: Template:Utente grc

Non so se considerarlo un test e quindi cancellarlo oppure se aspettare che magari il nuovo utente che lo ha creato lo completi. Mi affido a chi è più espero. --Torque (scrivimi!) 00:45, 30 giu 2015 (CEST)

Dal contenuto deduco che sia una semplice prova. Template da cancellare e utente da reindirizzare verso la propria sandbox.--Sakretsu (炸裂) 01:16, 30 giu 2015 (CEST)

Template pie chart che non funziona

cb La discussione prosegue nella pagina Discussioni template:Pie chart#Template_pie_chart_che_non_funziona.
– Il cambusiere --ppong (msg) 14:23, 15 ago 2015 (CEST)