Discussioni progetto:Geografia/Archivio 10

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

Standard nomi dei laghi

Salve. Che voi sappiate, ci sono standard di nomi dei laghi? Ad esempio, lago Xxxxxxx, piuttosto che Xxxxxxx (lago), o soloXxxxxxxx. Grazie, --Azz... 13:08, 30 giu 2010 (CEST)

Non penso esista uno standard... tuttavia, visto che l'uso prevalente, sia in italiano che su it.wiki, è quello di indicare "Lago xxx", "Bacino xxx", "Lago di xxx", direi di mantenere questo stile (aggiungendo però per "Lago/Bacino xxx" un redirect o disambigua dal nome senza Lago/Bacino). -- Basilicofresco (msg) 16:30, 30 giu 2010 (CEST)
Mi correggo, ecco qui lo standard: Progetto:Geografia/Convenzioni#Laghi. -- Basilicofresco (msg) 09:33, 7 lug 2010 (CEST)
Grazie doc. --Azz... 10:14, 7 lug 2010 (CEST)

Dialetti

Da un un po' c'è un IP che sta sostitunedo in tutte le voci di comuni lombardi il link sul nome in dialetto da lingua lombarda a dialetto lombardo occidentale. Pochi giorni fa un altro stava sostituendo lingua veneta in padovano o vicentino o simili nelle voci di comuni veneti (esempio, IP con range simile). E' corretto tutto ciò? Nelle voci venete avevo fatto qualche rollback finché l'IP non è cambiato. (c'è un altro progetto dove potevo segnalare la cosa?) --Amarvudol(msg) 20:28, 30 giu 2010 (CEST)

Ho notato anche io, ma non mi sembra niente di improprio. --Azz... 21:47, 30 giu 2010 (CEST)

Avviso cancellazione

La pagina «Beit HaShalom», 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)

--Mauro Tozzi (msg) 13:44, 4 lug 2010 (CEST)

Bozza Portale:Madagascar

Ho realizzato una bozza di Portale:Madagascar che sottopongo alla vostra attenzione. Gli utenti interessati allo ulteriore sviluppo del Portale (e delle voci connesse) sono invitati a discuterneal bar del Progetto:Africa --ESCULAPIO @msg 22:20, 4 lug 2010 (CEST)

Infobox lago

Perchè non sostituiamo nell'Infobox lago la dicitura emissari principali con emissario dato che da un lago praticamente sempre esce un solo fiume. Grazie. Pifoyde (msg) 20:35, 5 lug 2010 (CEST)

Boh, va bene. Approfitto per chiedere una cosa. Ho visto i test del template {{infobox fiume}}, e ho notato che sostituisce le virgole coi punti e viceversa (quasi come se si trattasse di un tipo dati numerico all'anglosassone). Non si può impostare un formato testuale per le stringhe inserite, al posto di uno numerico? --Azz... 20:38, 5 lug 2010 (CEST)

Vaglio Cerreto Sannita

Segnalo che per la voce Cerreto Sannita è iniziata la procedura di vaglio. Si accettano suggerimenti.. saluti! --Adam91 02:25, 8 lug 2010 (CEST)

Would you help me?

copincollo: Helios 21:35, 19 lug 2010 (CEST)


I'm korean wikipedian. (I looked Wikipedia:Burocrati to you.)

I ask sb for help Discussioni Wikipedia:Ambasciata.

But, someone no answer to me.

I need to your ability.

Because, never, this isn't to my ability.

Please, would you help me?

Thank you.--Idh0854 (msg) 13:55, 16 lug 2010 (CEST)

Segnalo

Segnalo questa mia richiesta di info, tnx.--Amarvudol (msg) 15:35, 23 lug 2010 (CEST)

Vaglio Valpolicella

Ciao a tutti, ho appena fatto una richiesta di vaglio per la voce Valpolicella, attendo consigli per poterla migliorare! Grazie a tutti.--Adert (msg) 23:44, 23 lug 2010 (CEST)

Nomenclatura Comuni Lettonia (e altri)

Premessa:Alcuni stati hanno ridotto notevolmente il numero dei loro comuni, facendo si che la loro superfice è oggi nell'ordine delle centinaia di kmq (in diversi casi più di 1000 kmq) in pratica come una nostra piccola provincia.

In questo contesto, la località principale (che da il nome al comune) è una piccola percentuale dell'intero comune con aspetti fisici ed economici spesso completamente diversi. La mia idea (per la Lettonia e la Bulgaria) è quella di creare una pagina per l'intero comune e una pagina per la località principale, sulla falsariga di quello che qui l'utente Remulazz ha già fatto per la Svezia. Questo sistema è inoltre già in uso nelle wiki locali e anche en.wiki e ru.wiki, che in questo campo sono più avanti di tutte, vanno in questa direzione. Naturalmente il tutto corredato di fonti, che in questi casi specifici non mancano. Aspetto consigli e valutazioni. Ciao a tutti RaMatteo 11:47, 25 lug 2010 (CEST)

Favorevole all'organizzazione dei contenuti come indicato da Ramatteo. Una pagina per il Comune di Xxxxxx (oppure per Xxxxxx (comune)) e un'altra per il capoluogo Xxxxxx. --Azz... 12:03, 25 lug 2010 (CEST)
In linea di massima sono favorevole ad una organizzazione di questo tipo, però per uniformità teniamo presente che ci sono alcuni casi analoghi in cui non è stato fatto così, in particolare Montenegro (vedi Cettigne) e Slovenia (vedi Novo Mesto), dove voce del comune e voce del centro principale coincidono. Insomma, dovremmo definire bene in quali casi applicare una modalità e in quali l'altra. Personalmente, a senso (e date le dimensioni e il numero dei comuni), modificherei il Montenegro e lascerei così la Slovenia.--Retaggio (msg) 11:10, 26 lug 2010 (CEST)
@Retaggio Al momento sto valutando la situazione di Lettonia e Bulgaria che meritano (a mio parere) uno sdoppiamento stile comuni della Svezia. Per altre eventuali situazioni bisognerebbe vedere anche se ci sono fonti precise, ad occhio escluderei comunque la SloveniaRaMatteo 11:19, 26 lug 2010 (CEST)
In effetti, dei due casi che ho proposto, i dubbi maggiori li ho proprio sul Montenegro. --Retaggio(msg) 11:47, 26 lug 2010 (CEST)

Isole greche

Categoria:Isole della Grecia: sovraffollata e con un altro problema --> vedo molte isole per cui adottiamo il nome greco quando ci sarebbe l'italiano... --Pequod76(talk)04:10, 27 lug 2010 (CEST)

Sovraffollata? 76 voci. Per il nome, non saprei. --Azz... 12:32, 27 lug 2010 (CEST)
Mi spiego meglio: esistono diverse Cicladi categorizzate come isole greche quando invece c'è la cat cicladi; altre presentano entrambe le cat (la più grande è dunque ridondante). --Pequod76(talk) 12:57, 27 lug 2010 (CEST)
Non si possono cancellare le sottocategorie? --Azz... 14:21, 27 lug 2010 (CEST)
No, in genere si eliminano dalle voci le cat superiori quando ridondanti --Retaggio(msg) 14:23, 27 lug 2010 (CEST)
Beh, ma quante voci hanno le sottocat? --Azz... 14:24, 27 lug 2010 (CEST)
No ho sbagliato. Sono ben fornite. Beh, allora facciamo come dici tu. --Azz... 14:25, 27 lug 2010 (CEST)
(conflittato) Sto appunto cominciando a guardarle (esempio) --Retaggio(msg) 14:25, 27 lug 2010 (CEST)

✔ Fatto Ora sono solo 17, essenzialmente isole al largo del Peloponneso o di Creta. Rimangono da controllare i titoli delle voci.--Retaggio (msg) 15:18, 27 lug 2010 (CEST)

Bisogna poi capire se le voci parlano effettivamente del capoluogo dell'isola o dell'isola e categorizzare di conseguenza. Vedi infattiCitno. La cosa si sistemerà - immagino - ampliando le voci. --Pequod76(talk) 21:57, 27 lug 2010 (CEST)

Template divisioni amministrative russe

Salve. Nelle voci delle unità amministrative della grande madre Russia (es.) c'è uno strano template che non conosco e che, fra l'altro, ha un nome sbagliato ({{Repubblica_Russa}}). C'è qualche motivo storico-politico perchè sia quello e non il nostro template {{territorio}}? Spasibo i do svidanija. --Azz... 14:27, 27 lug 2010 (CEST)

Comuni statunitensi

Scusate se rompo. Stavo iniziando a metter mano a un po' di comuni statunitensi, ma è sorto ancora il problema di come definirli a seconda del loro status. Se ne discute qui. Vi chiederei un parere per giungere a una decisione definitiva. Grazie. --Amarvudol (msg) 09:35, 28 lug 2010 (CEST)

Disambigue russe

Segnalo questo post che ho aperto al progetto Russia.--Azz... 13:08, 30 lug 2010 (CEST)

MOnitoraggio della voce Lago Moro

Salve a tutti, molti mesi fa la voce Lago Moro è stata valutata dal progetto. Ultimamente ci ho lavorato, soprattutto per quanto riguarda le note. Gradirei se qualcuno volesse effettuare di nuovo il monitoraggio. Grazie.--Chessstoria (le s sono 3)(Dica Duca) 17:21, 4 ago 2010 (CEST)

Standard di nomenclatura

Gironzolando tra le voci relative all'isola di Brač ho notato una certa disomogeneità nei criteri adottati per la nomenclatura: per alcune delle località (p.es. San Pietro della Brazza - in croato Supetar, e Vallo della Brazza - Bol), viene adottata la antica denominazione italiana, mentre per altre (p.es. Škrip e Splitska) si utilizza la attuale denominazione croata. Non sarebbe il caso di avere una maggiore uniformità? Quale è lo standard adottato dal progetto geografia in questi casi? Faccio notare che anche le guide in italiano adottano ormai le denominazioni croate. --ESCULAPIO @msg 00:11, 8 ago 2010 (CEST)

Se ne parla al progetto Venezia Giulia. --Crisarco (msg) 19:19, 19 ago 2010 (CEST) La denominazione italiana viene usata soltanto quanto è un esonimo risalente (e non una creazione novecentesca). Nel caso di San Pietro si tratta di un esonimo di una località con comunità italiana. Le carte austriache [Category:3rd Military Mapping Survey of Austria-Hungary qui] riportano appunto, a distanza di pochi chilometri, San Pietro e Skrip. --Crisarco (msg) 19:37, 19 ago 2010 (CEST)

Cancellazione

La pagina «Area metropolitana di Pescara-Chieti», 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)

--Markos90 15:08, 13 ago 2010 (CEST)

Cina

Faccio notare come la nomenclatura delle voci segua posizioni non neutrali. Specificamente, la voce su Taiwan è stata nominata "Repubblica di Cina (Taiwan)", con una disambiguazione non necessaria e con rottura del criterio adottato per gli stati del nome più comune. "Repubblica di Cina" rinvia allo stato isolano, mentre in "Cina" (Repubblica Popolare) è stata inserita una nota disambigua che rimanda alla "Repubblica di Cina" di cui sopra. --Crisarco (msg) 19:19, 19 ago 2010 (CEST)

trasciando per un attiamo la regola del nome piu' diffuso in lingua italiana, dal punto di vista prettamente giuridico politico:

  • la repubblica di cina e' lo stato che si estente sul territorio della cina continentale e sull'isola di taiwan. Attualmente ha una giurisdizione di fatto solo sull'isola di taiwan e su alcune isolette del canale che separa taiwan dal continente. ha capitale nanchino, ma la capitale di fatto e' taipei
  • la repubblica popolare cinese e' lo stato che si estende sul territorio della cina continentale e sull'isola di taiwan. Attualmente ha giurisdizione di fatto solo sul territorio della cina continentale. ha capitale pechino

Dal punto di vista strettamente politico-giuridico quindi entrambe sono "cina". e non e' una cosa da poco, proprio per questo motivo uno stato che riconosce la repubblica di cina non puo' riconoscere la repubblica popolare cinese, e vice versa. dal punto di vista, ripeto, politico giuridico dovrebbe dunque essere:

  • repubblica di cina -> l'attuale voce su "repubblica di cina (taiwan)"
  • repubblica popolare cinese -> l'attuale voce su "cina"
  • cina -> disambigua tra le precedenti

Dal mio punto di vista, possiamo metter cina come redirect a repubblica popolare cinese con una nota disambigua che manda a repubblica di cina (tale soluzione pero' non risolve il POV di associare il termine "cina" alla repubblica popolare cinese). Ma lo stato con capitale nanchino non puo' esser chiamato "repubblica di cina (taiwan)"--Hal8999 (msg) 20:23, 19 ago 2010 (CEST)

per dirla tutta, lo stesso Portale:Cina ha dei problemi di pov...--Hal8999 (msg) 20:26, 19 ago 2010 (CEST)

Secondo i nostri criteri IMHO: Repubblica di Cina -> disambigua (entrambe sono repubbliche, una è "popolare") Cina -> voce sullo stato continentale, con nota disambigua a quello isolano (la maggior parte degli utenti identifica come "Cina" quella continentale ed è così pure nel linguaggio comune) Taiwan -> voce sulla repubblica di Cina (stato isolano)--Crisarco (msg) 14:07, 20 ago 2010 (CEST)

Concordo con quest'ultima proposta --Bultro (m) 14:10, 20 ago 2010 (CEST)
il problema di dare alla voce dello stato isolano il nome Taiwan è che.... lo stato non si chiama così!--Hal8999(msg) 14:23, 20 ago 2010 (CEST)
invito a guardar casi (più o meno) simili: Congo (anche se non c'è una disputa territoriale) o Macedonia(anche se non si tratta di dubbio tra due stati sovrani.--Hal8999 (msg) 14:28, 20 ago 2010 (CEST)
  • Nel caso di "Congo" comunemente con tal nome ci si riferisce tanto all'uno quanto all'altro stato;
  • Nel caso di "Macedonia" il significato relativo allo stato non è prevalente anche per l'importanza del nome storico;
  • Nel caso di "Taiwan" questo è il nome con cui generalmente e più comunemente ci si riferisce alla "Repubblica di Cina". Vero che non c'è cenno all'isola nel nome ufficiale dello stato, ma a ben vedere nemmeno i nomi ufficiali delle "due Coree" accennano alla collocazione geografica, eppure abbiamo Corea del Sud e Corea del Nord. --Crisarco (msg) 14:53, 20 ago 2010 (CEST)
sì, in entrambi i nomi compare il nome "corea". E chiamare la repubblica di cina come taiwan è proprio sbagliato (oltre che pov).--Hal8999 (msg) 16:03, 20 ago 2010 (CEST)
Non meno pov di chiamare Corea del Nord uno stato che non ritiene di essere "settentrionale". --Crisarco (msg) 16:07, 20 ago 2010 (CEST)
"comunemente nota come Taiwan", lo dice la voce stessa, mai visto poi "made in Taiwan"? come titolo di voce wikipediana va più che bene per le nostre convenzioni, sarà poi l'incipit a specificare il nome ufficiale --Bultro (m) 16:16, 20 ago 2010 (CEST)
(conflittato)almeno c'è il nome corea. cosa che in "taiwan" non c'è. al mondo ci sono 23 stati che chiamano la repubblica di cina come "cina" e lo stato è stato membro del consiglio di sicurezza onu con il nome "cina" sino al 1971. Oltre 160 stati chiamano invece la repubblica popolare cinese come "cina". come nota di costume, se si chiama la repubblica di cina come taiwan se la prendono di più "i cinesi di pechino" di "quelli di taipei" dato che si viola il principio dell'"una sola cina" risconoscendo implicitamente la sovranità di taipei sulla sola isola di formosa. A questo si aggiunge il già citato fatto che taiwan è sbagliato.--Hal8999 (msg) 16:18, 20 ago 2010 (CEST)

Valle dell'Indo

Questa voce merita una pagina a parte essendo un argomento geografico e non storico quale è Civiltà della valle dell'Indo.Pifoyde (msg) 23:19, 20 ago 2010 (CEST)

Avviso cancellazione

La pagina «Ruère», 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)

--Mauro Tozzi (msg) 08:56, 29 ago 2010 (CEST)

Avviso cancellazione

La pagina «Kralja Milana», 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)

-- T137 (varie ed eventuali - @) 15:22, 29 ago 2010 (CEST)

Categorizzazione dei fiumi per bacino

Ciao a tutti, un'idea che mi balena da molto tempo è quella di aggiungere, nella categorizzazione dei fiumi, una categorizzazione per bacino oltre a quella già esistente per stato. Questa categorizzazione è già presente su altre wiki (ad esempio quella in inglese). Innanzitutto, può interessare? Seconda cosa, come definiamo le convenzioni di nomenclatura? Ad esempio: per i mari, Tributari del Mediterraneo / Bacini idrografici del Mediterraneo / Fiumi tributari del Mar Mediterraneo / ... e per i fiumi (che poi saranno sottocategorie), Bacino del Po / Fiumi del bacino del Po / ... Idee? Cruccone (msg) 10:03, 30 ago 2010 (CEST)

Fiumi del bacino sarebbe a dire gli affluenti? Non è meglio "affluenti del Po"? --Bultro (m) 20:16, 30 ago 2010 (CEST)
Beh, il Po non è un affluente del Po, e in più ci sono i subaffluenti. Eventualmente con Bacino del Po si potrebbero inserire anche i laghi. "Bacino del Po" poi potrebbe avere come sottocategorie "Bacino dell'Adda", "Bacino del Ticino", etc. --Cruccone(msg) 20:58, 30 ago 2010 (CEST)

Cancellazione

La pagina «Area metropolitana di Campobasso», 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)

--Markos90 21:55, 6 set 2010 (CEST)

La pagina «Area metropolitana di Caserta», 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)

--Markos90 21:59, 6 set 2010 (CEST)

Segnalazione problema su comuni spagnoli

Segnalazione di un problema in Discussioni_progetto:Spagna#Due_cose_strane_sui_comuni_andalusi. Grazie. --Retaggio(msg) 23:09, 9 set 2010 (CEST)

Popolazione del centro urbano e popolazione del comune

Pensavo che sarebbe opportuno, nel template "città" e nel template "comune", aggiungere un secondo campo "popolazione" in modo da poter indicare separatamente sia il numero di abitanti del centro urbano sia quelli dell'intero comune. Oltre ad avere una interessante informazione in più, soprattutto si eviterebbero equivoci da parte del lettore visto che non è chiaro se la cifra riportata nel quadro sinottico si riferisce alla popolazione della città o a quella del comune. A me personalmente viene automatico associare ad una località la sua popolazione (esclusa quindi quella rurale e delle frazioni) e così certamente capita a diversi lettori, a maggior ragione nelle pagine di wiki dove il soggetto non è mai il comune ma la città; tanto è vero che "coordinate", "cap", "altitudine" e persino "panorama" ad essa si riferiscono e non alla sua giurisdizione. Avere quindi (ove possibile s'intende) una voce "Popolazione del centro urbano" ed un'altra "Popolazione del comune" certamente fugherebbe ogni dubbio. --Discanto  ????? 02:30, 13 set 2010 (CEST)

Se ne parla da tempo, è in elaborazione un nuovo template che dovrebbe prevedere il doppio campo. --Crisarco(msg) 18:08, 13 set 2010 (CEST)

Comuni della Lettonia

Riporto qui una discussione aperta anche su Progetto:Amministrazioni.

Sto tentando di scrivere gli articoli sui comuni della Lettonia. L'utente:Gleb Borisov mi scrive:

I think, even if the articles about a municipality and its centre are merged, it would be better to add interwikis of the articles about municipalities, not their centres. Furthermore, in leads of the articles it's said that article's subject is a municipality (comune). So, IMHO, interwikis like en:Ilūkste should be changed to en:Ilūkste municipality.

In it.wiki siamo soliti creare un'unica voce che accorpa le informazioni di comune e centro capoluogo, senza creare doppioni. Ciò non sempre avviene nelle altre wiki, che talvolta prevedono due distinte voci. In sostanza, gli interwiki alle voci sui comuni devono lincare la voce del centro capoluogo o quella del comune?

Tecnicamente avrebbe più senso la seconda, ma è anche vero che non creiamo voci del tipo Comune di Zilupe, ma bensì Zilupe, e nel testo della voce non scriviamo città (o paese) ma comune per convenzione interna (ad es. si vedano discussioni su comuni degli Stati Uniti d'America).

Sicuramente mi sbaglierò, ma indicherei il link alla città capoluogo, più che all'entità territoriale (municipality).--Zavijavah (msg) 19:58, 16 set 2010 (CEST)

Si vedano gli interwiki per i comuni sloveni, dove c'è una situazione simile. Tecnicamente andrebbe linkata la voce generale, ma praticamente è più "comoda" quella sul capoluogo comunale. La scelta di en.wiki riflette quella delle wiki di madre lingua, spesso dettagliatissime sugli "affari interni" ma povere su quelli globali. Noi cerchiamo di mantenere un punto d'equilibrio. Certo, dare seguito alla discussione della sezione appena sopra risolverebbe molti problemi. --Crisarco (msg) 22:04, 16 set 2010 (CEST)

La nostra voce è sul comune, quindi interwiki al comune. Cruccone (msg) 19:01, 17 set 2010 (CEST)

Comuni della Papua Nuova Guinea

Ho creato l'elenco delle "aree di governo locale" (simili ai nostri comuni) della Papua Nuova Guinea. Pensavo di creare le voci ma avevo il dilemma se fare una voce della città capoluogo o una voce dell'unità amministrativa (per esempio "Lae" o Lae Urban"?). Per ora ho laciato la situazione immutata ma creando, solo per le principali città, come redirect gli enti amministartivi. Potete darmi un parere/suggerimento? Grazie. Geofix zacca ka! 21:06, 17 set 2010 (CEST)

Template:Stato

Segnalo che ho posto alcune questioni qua. Grazie. --Er Cicero 10:35, 18 set 2010 (CEST)

Cancellazione

La pagina «Conurbazione Modena-Bologna», 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)

--Markos90 20:06, 24 set 2010 (CEST)

La pagina «Area metropolitana di Padova», 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)

--Markos90 20:50, 24 set 2010 (CEST)

Disambigue

Salve. Segnalo questa discussione al progetto Russia.--Azz... 20:49, 24 set 2010 (CEST)

Avviso di cancellazione

La pagina «Torrente Dragone», 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)

--Mauro Tozzi (msg) 15:30, 26 set 2010 (CEST)

Alluvione del Pakistan

Ci sarebbe da ampliare la voce alluvione del Pakistan (2010) che attualmente è meno di un abbozzo. Qui c'è qualcuno interessato? -- Yiyi (Scrivimi...) 23:04, 29 set 2010 (CEST)

Categorie messicane

Salve! Abbiamo:

Come disambigua non mi sembra il massimo. Un niubbo non capirebbe certamente la seconda. Proporrei di lasciare intonsa la prima (mi pare che un vostro standard sia di evitare gli aggettivi, il che mi sembra giusto) e di rinominare la 2a: "Città del Messico (DF)". DF (de-efe) è il modo in cui i messicani indicano la capitale, in quanto essa è amministrata a livello federale. Immagino sia anche possibile inserire una nota disambigua per coloro che consultano wikip attraverso le categorie. --Pequod76(talk) 22:43, 5 ott 2010 (CEST)

Cioè "DF" ti sembra più chiaro di "città" per un niubbo? Mah... La nota disambigua c'è già --Bultro (m) 18:02, 6 ott 2010 (CEST)
Sì, mi sembra più chiara perché quanto meno da niubbo non la capisco e mi suscita un dubbio, mi pone una domanda. Invece (città) sembra una bizzarra ripetizione, apparentemente appartenente al nostro modo di categorizzare. Magari si potrebbe pensare a qcsa di più intellegibile, come Categoria:Città del Messico (capitale). --Pequod76(talk) 03:14, 7 ott 2010 (CEST)
Sono abbastanza d'accordo con Bultro: c'è sia la nota disambigua che un incipit che li distingue chiaramente; il niubbo dovrebbe anche non leggere per non identificare correttamente la categoria. D'altro canto il nome da te proposto è più conforme all'attuale incipit ("La categoria raccoglie le voci riguardanti la città-distretto federale di Città del Messico, capitale del Messico."), ma la rende difforme da altri casi simili, ad es. Categoria:Brema (città). Insomma ci sono pro e contro. --Mr buick (msg) 10:19, 7 ott 2010 (CEST)

Richiesta di disambiguazione

Mi sembra pazzesco che digitando Pacifico si vada direttamente alla pagina del cantautore senza nemmeno una pagina di disambigua prima. Spero qualcuno possa fare qualcosa. 12:22, 7 ott 2010 (CEST)

Ha risolto Etruko25, ma potevi farlo anche tu! ;) --Pequod76(talk) 15:44, 7 ott 2010 (CEST)

Problemi con le mappe di localizzazione

Sia in questo caso che in quest'altro non compaiono le mappe di localizzazione corretta. È possibile rimediare in qualche modo?--Carnby (msg) 17:33, 7 ott 2010 (CEST)

Per quanto riguarda il Monte Waialeale, il problema è che la mappa degli Stati Uniti non comprende Alaska e Hawaii (anche le montagne dell'Alaska hanno lo stesso problema). Bisogna agire a livello di template, non mi sembra banale. Per quanto riguarda le Curili, la mappa che compare è quella nel parametro Mappa=, in questo caso chiama quella di tutta la Russia - il template non mette il pallino.--Cruccone (msg) 13:34, 8 ott 2010 (CEST)
... e in più le mappe delle nazioni circumpolari hanno grossi problemi di georeferenziazione. La discussione di approfondimento è ovviamenteDiscussioni_template:Mappa_di_localizzazione dove sto segnalando questo e altri problemi. La soluzione è realizzare nuove mappe parziali come File:Italy location map 2.svg che ho cominciato a preparare come primo esempio. Andranno create mappe per le isole e dipendenze e ce ne stiamo occupando al collegato Progetto:Geografia/Isole. Poi bisognerà modificare i template (come per esempio mi sto predisponendo a fare per {{infobox isola}}) affinchè possano utilizzare le "sottomappe" come sfondo per la localizzazione automatica, al posto di quelle degli stati centrali. Nello stesso tempo, va messo mano al template {{Mappa di localizzazione}}, perchè recepisca le varianti già adottate nelle Wikipedia più evolute e in grado di gestire regioni circumpolari geografiche come il Canada e la Russia. Quest'ultima attività è la più complessa per me, in quanto il template è bloccato e devo passare per la richiesta di sblocco. Poichè si tratta di isole, se volete ci trasferiamo al sottoprogetto apposito e insieme potremo mettere a punto sia il template infobox isola, che quelli che sulle isole vanno a individuare luoghi o elementi. --EH101{posta} 13:51, 8 ott 2010 (CEST)

Nomi dei template bandierine regionali italiane

Attualmente i template della Categoria:Template bandierine regionali italiane sono costruiti secondo dei codici non uniformi allo standard ISO 3166-2:IT. Non andrebbero spostati allo standard? Per esempio il template {{IT-ABR}} relativo all'Abruzzo non dovrebbe essere {{IT-65}}? Franco56 - (se vuoi, rispondi) 14:12, 9 ott 2010 (CEST)

Al momento non è possibile perché altri template sinottici (es. Template:Frazione) usano la sigla di 3 lettere per richiamare la bandierina: tu inserisci regione=ABR e lui richiama IT-ABR. Ad ogni modo, quale sarebbe il vantaggio? Le sigle sono più comprensibili e comunque non appaiono al lettore, i nomi dei template sono solo per nostra comodità, non c'è motivo di seguire uno standard--Bultro (m) 13:04, 11 ott 2010 (CEST)
Il problema mi è nato dal template {{montagna}} che nelle istruzioni prima delle mie integrazioni qui inviava, per poter inserire i template bandierine delle regioni italiane ad una pagina che non ne contiene più un elenco. Anche la Categoria:Template bandierine regionali italiane manda ad un elenco che non c'è. E cercando l'elenco non l'ho trovato. Successivamente ho visto tutte le nazioni per cui sono già stati creati i template bandierine delle suddivisioni amministrative, li ho messi in un'unica categoria ed ho visto che alcune seguono l'ISO 3166-2 ed altre no. Forse occorre maggiore uniformità? Forse è sufficiente mettere l'elenco nella rispettiva categoria come ho fatto perquesta? Franco56 - (se vuoi, rispondi)21:58, 11 ott 2010 (CEST)
Per il momento ho aggiunto una legenda alla Categoria:Template bandierine regionali italiane che aiuta per l'inserimento della bandierina regionale nei vari template la cui pagina di spiegazioni punta alla categoria, come per esempio il template {{montagna}}.Franco56 - (se vuoi, rispondi) 23:02, 11 ott 2010 (CEST)
Le sigle di tre lettere vengono da qualche fonte ufficiale o sono state inventate da noi? Quello che si può fare è creare i template con i codici ISO come redirect ai codici a tre lettere (o viceversa). Sinceramente i numeri dell'ISO sono assolutamente antiintuitivi, a differenza dei codici a tre lettere per cui passare solo a quelli ISO non mi sembra una grande idea. Cruccone (msg) 19:14, 18 ott 2010 (CEST)

Appello per uno scambio di idee sui sottoprogetti

Salve! C'è una proposta di riforma dei progetti in corso qui. In sintesi, si sta cercando di ripensare l'organizzazione dei progetti, partendo da una distinzione di fondo (progetti dedicati al servizio, in primis il progetto:coordinamento) e progetti destinati al ns0. Penso siate al corrente del fatto che diversi tentativi di cancellazione di progetti in qualche modo inattivi sia stata sentita come uno strappo da diversi utenti che hanno sentito il bisogno di coordinarsi attraverso un progetto. Una bozza di idea è quella di lasciare una talk a chi effettivamente necessita solo di una talk, senza che ad essa corrisponda una pagina progetto che viene spesso riempita surrettiziamente. Lo schema finirebbe per essere: il progetto x, i suoi vari sottoprogetti, sviluppati se effettivamente hanno del materiale di gestione delle informazioni da offrire, vari sottobar per chi in effetti ha bisogno di un coordinamento solo come punto di incontro occasionale per discutere di singoli casi relativi al ns0. Chi invece necessita di un coordinamento solo ai fini della creazione e manutenzione di un portale sarebbe bene usasse la talk del portale. L'invito presente tiene conto del fatto che solo attraverso l'esperienza diretta di chi vive i progetti come luoghi di coordinamento si può rivedere compiutamente la policy relativa (wp:progetto) che, allo stato, mescola un po' i piani. Accorrete e fateci conoscere le vostre impressioni ed esperienze, in modo da seppellire l'ascia che separa i fan dei progetti dai detrattori dell'iperproliferazione e trovare un punto di incontro che renda i progetti davvero funzionali.

Si è pensato di proporre inizialmente la cosa ai vari membri dei progetti geografici. Se non ve la sentite di leggere tutta la conversazione che è seguita alla proposta, non esitate e fare domande. Guardate i miei edit vicini al presente: se notate che sottoprogetti di geografia che sapete attivi non sono stati avvertiti, linkate, se vi va, la discussione. --Pequod76(talk) 01:42, 12 ott 2010 (CEST)

Segnalazione

Segnalo Wikipedia:Bar/Discussioni/Template Micronazione --EH101{posta} 22:36, 21 ott 2010 (CEST)

Io sposterei a Regioni d'Italia. Se invece è così per una ragione di convenzioni di progetto, si potrebbe risolvere con {{titolo errato}}? --Pequod76(talk) 01:28, 24 ott 2010 (CEST)

Per me si può spostare. Abbiamo Comuni d'Italia, Storia d'Italia, Re d'Italia... --Bultro (m) 16:22, 25 ott 2010 (CEST)
Segnalo questa discussione. Penso sia l'ultima sull'argomento, in caso si può ripartire da qua. Comunque c'è un bel caos: Regioni d'Italia è redirect a regioni dell'Italia, mentre Discussione:Regioni dell'Italia è redirect a Discussione:Regioni d'Italia. --Mr buick (msg) 17:07, 25 ott 2010 (CEST)

Cat di servizio mensili create da un bot

Vi invito a dare uno sguardo a questa discussione. Quali sono gli argomenti che il vostro progetto troverebbe comodo avere in automatico in cat di servizio? La proposta è far lavorare dei BOT per le cat di servizio dei template W, F, S, C (e forse anche Controlcopy) per alcuni macro argomenti: sia cat mensili, che cat che ancora mancano (da creare una volta per tutte).. --Pequod76(talk) 01:36, 24 ott 2010 (CEST)

Template Bandiere Grecia

Ciao, da un po di tempo mi occupo di tenere in ordine queste pagine, e quindi, ho notato la creazione del sottotemplate Template:Naz/GRC 1822-1978. Ho notato una certa confusione; abbiamo infatti tre diverse bandiere (, , con un blu più scuro) ma, così almeno risulta da questa discussione, la bandiera ufficiale della Grecia è rimasta sempre la seconda (ipotesi supportata anche in en:List of Greek flags, dove, ad un certo momento, si dice che l'attuale bandiera era usata all'estero). L'unica eccezione riguarderebbe proprio il periodo 1970-1975 in cui venne adottata la terza. Ora, dato che la discussione ai tempi non ebbe molto seguito, vorrei riproporre il quesito perché

Insomma, non c'è nulla che punta a Regno di Grecia (che fra l'altro dovrebbe avere questa bandiera ), tre diverse bandierine (di cui una forse sbagliata, perché solo insegna navale), e 5 diversi raggruppamenti di date (1822-1969, 1822-1970, 1828-1978, 1970-1975 e 1975-1978) oltre a quello senza data.

C'è qualcuno in grado di dare ordine a questo guazzabuglio? --Mr buick (msg) 16:10, 24 ott 2010 (CEST)

Ciao a tutti, ho creato questa nuova macrocategoria per categorizzare i fiumi per bacino. Come esempio, ho creato l'albero delle categorie per arrivare al Torrente Artanavaz. Ho saltato la categoria intermedia tra questo torrente e la Dora Baltea perché il Buthier ha pochi affluenti, ma si potrebbe mettere. Prima di procedere oltre, vorrei pareri sull'utilità di questo sistema di categorizzazione, suggerimenti su come migliorarlo e sul nome da dare alle categorie, e come relazionarlo con le categorie dei fiumi (Categoria:Fiumi del bacino del Posottocategoria di Categoria:Po o viceversa?). Grazie --Cruccone (msg) 13:49, 29 ott 2010 (CEST)

Mi pare una categorizzazione interessante. Metterei la Categoria:Fiumi del bacino del Po come sottocategoria di Categoria:Po e non viceversa (ho corretto in proposito). Una piccola descrizione all'inizio di ogni categoria come ho fatto per questa penso che non guasterebbe. Per il resto mi pare che possa andare bene. Franco56 - (se vuoi, rispondi) 17:21, 29 ott 2010 (CEST)
Un'altra cosa, ma non so se sbaglio. Non metterei la Dora Baltea nella Categoria:Fiumi del bacino della Dora Baltea ma nella categoria superiore: Categoria:Fiumi del bacino del Po. Il richiamo alla Dora Baltea nella categoria lo lascio nel titolo. Ho provato a modificare le categorie in questo senso. Franco56 - (se vuoi, rispondi) 17:36, 29 ott 2010 (CEST)
Ho provato ad andare un po' avanti con la categorizzazione. Franco56 - (se vuoi, rispondi) 18:00, 29 ott 2010 (CEST)
Sì, è una soluzione possibile, anche se se parliamo di bacino idrografico il fiume stesso ne fa parte (nei fiumi del bacino della Dora Baltea mi aspetto di trovarcela). Forse avrebbe più senso rinominare le categorie in "Affluenti della Dora Baltea" (ma poi i subaffluenti non ne fanno parte in senso stretto) o in "Fiumi tributari della Dora Baltea" (è brutto ma corretto). Per quanto riguarda la categoria Po/Fiumi del bacino del Po, nelle altre wiki maggiori (en), fr, de,pl) il bacino (o gli affluenti) sono nella categoria del fiume, e se parliamo di affluenti la soluzione è perfettamente logica. Per quanto riguarda il Po, categorizzarei la categoria piuttosto che la voce. Fondamentalmente, questi sono i dubbi che è meglio risolvere prima di categorizzare migliaia di fiumi, per non dover rifare il lavoro mille volte. --Cruccone(msg) 18:05, 29 ott 2010 (CEST)
Quasi quasi sarei per rinominare le categorie in "Affluenti del ..." (intendendo, e specificandolo nel titolo, che si parla di affluenti e sub-affluenti. Se questo è proprio del tutto scorretto allora andrei per la dicitura "Tributari della Dora Baltea" anche se è brutto). La wiki inglese distingue tra bacino (en:Danube basin) e tributari (en:Tributaries of the Danube). Per coerenza dovremmo fare le categorie "Affluenti (o tributari) del ..." e "Bacino del ..." e non come adesso "fiumi del bacino del ..." che è un miscuglio tra i due.Franco56 - (se vuoi, rispondi) 18:45, 29 ott 2010 (CEST)
"Bacino del" comprenderebbe anche i laghi, il che non è necessariamente un male. Anch'io rinominerei le categorie. Curiosamente, secondo la nostra voce, affluente e tributario sono sinonimi, per cui tanto vale usare "affluenti" che almeno è un termine più chiaro. Poi, mi resta il dubbio sui fiumi che sfociano in bacini interni (Mar Morto, Mar Caspio), come categorizziamo Categoria:Fiumi tributari del Mar Caspio? Direttamente in Categoria:Fiumi per oceano o creiamo una categoria intermedia Categoria:Fiumi tributari di bacini interni? Cruccone (msg) 19:20, 29 ott 2010 (CEST)
Rinominare in "Affluenti del ..." avrebbe il vantaggio di poter comprendere anche i torrenti. L'attuale categorizzazione "fiumi del bacino del ..." stride quando nella categoria si inseriscono dei torrenti. Su discorso del mar Caspio sarei per creare la categoria intermedia. Franco56 - (se vuoi, rispondi) 08:48, 30 ott 2010 (CEST)

Mi sembra perfetto. Faccio un piccolo riassunto della struttura attuale:

  • Categoria:Fiumi tributari del mare Xyz: contiene le voci sui fiumi che sfociano in quel mare e le categorie sui loro affluenti
  • Categoria:Affluenti del Yzx: contiene le voci sugli affluenti e le categorie sugli affluenti degli affluenti

Le cose IMHO dovrebbero essere leggermente diverse nel caso in cui il fiume Zxy ha la sua categoria: IMHO la voce andrebbe categorizzatasolo in Categoria:Zxy. Categoria Zxy dovrebbe essere sottocategoria di Categoria:Fiumi tributari del mare Xyz (se lo Zxy sfocia nel mare Xyz) o di Categoria:Affluenti del Yzx (se è affluente dello Yzx). Categoria:Affluenti del Zxy è sottocategoria di Categoria:Zxy. A mo' di esempio, l'albero delle categorie per il Terdoppio (affluente del Ticino) dovrebbe essere: Terdoppio<-Categoria:Affluenti del Ticino<-Categoria:Ticino<-Categoria:Affluenti del Po<-Categoria:Po<-Categoria:Fiumi tributari del Mare Adriatico<-etc. Ha senso come principio? Cruccone (msg) 09:44, 30 ott 2010 (CEST)

Nel caso di fiumi con meno di N affluenti (per esempio N=3), eviterei di creare la categoria sugli affluenti e metterei gli affluenti nella stessa categoria del fiume in cui sfociano. In pratica: se l'Aaa è l'unico affluente del Bbb, che a sua volta è affluente del Ccc, sia Aaa che Bbb andrebbero in Categoria:Affluenti del Ccc. Cruccone (msg) 09:49, 30 ott 2010 (CEST)
Concordo in pieno sul riassunto proposto. Franco56 - (se vuoi, rispondi) 09:52, 30 ott 2010 (CEST)

Il nome della madre, "Fiumi per oceano", non mi sembra tanto corretto. Dovrebbe essere "Fiumi per foce", "Fiumi per bacino" o qualcosa del genere. Tra l'altro risolverebbe il problema dei laghi --Bultro (m) 14:30, 30 ott 2010 (CEST)

Sempre in questo ambito ho iniziato la Categoria:Affluenti. A mio parere, servirebbe (conoscendo il nome del fiume) per cercare se sono categorizzati i suoi affluenti.Siccome, in prospettiva, potrebbe diventare molto grande vi ho inserito il template {{Indice categoria}}.Franco56 - (se vuoi, rispondi) 13:48, 31 ott 2010 (CET)

Ho letto e concordo, ma non mi è chiara una cosa: nel caso dei Fiumi Uniti che sfociano nel mar Adriatico ed ha solo due affluenti (Ronco e Montone) che si fa? Vanno tutti e tre in Categoria:Fiumi tributari del Mare Adriatico? Oppure fa eccezione alla regola del N<=3? --Mr buick (msg) 12:46, 1 nov 2010 (CET)
Bisognerebbe cercare di rendere più chiara la situazione dei fiumi con solo 1 o 2 affluenti. Per esempio,qui abbiamo il caso di un subaffluente. Poiché il Soligo non ha altri affluenti, il suo affluente è categorizzato come affluente del Piave, ma in realtà è un subaffluente. Soluzioni possibili che vedo (se ce ne sono altre aggiungetele):
  1. Si creano sempre le categorie "Affluenti del Xyz", anche se il numero di elementi rimarrà minore di N (1 o 2 in pratica)
  2. Si torna al vecchio nome, eventualmente qualcosa come "Corsi d'acqua del bacino del Xyz", che però è un titolo molto macchinoso (o rinominiamo in "Bacino del Xyz", e non mettiamo solo i fiumi)
  3. Si mette un cappello introduttivo alle categorie sugli affluenti, in modo tale da spiegare perché nella categoria degli affluenti ci siano anche alcuni subaffluenti (qualcosa di simile ai tedeschi, che però hanno una filosofia leggermente diversa)

Cruccone (msg) 15:50, 2 nov 2010 (CET)

Tra le tre soluzioni proposte escluderei la seconda. Tra la prima e la terza, che non mi sembrano del tutto alternative (se si crea una categoria con uno o due elementi non c'è nulla di male), propenderei per la terza (già adesso stiamo scrivendo nelle categorie "Affluenti del Xyz" una frase del genere: "Categoria che raccoglie voci circa i fiumi e torrenti del bacino del Xyz" in pratica eventuali subaffluenti). Se si opta per la terza sarà sufficiente mettere un cappello introduttivo nella Categoria:Affluenti e magari da qualche altra parte.Franco56 - (se vuoi, rispondi) 16:34, 2 nov 2010 (CET)
Ho visto solo adesso l'annullamento linkato qui. Certo chi si trova al fondo della pagina "affluente di Xyz" e questo non è vero non può sapere subito che con affluenti si intendono anche i sub-affluenti (anche se lo scriviamo come cappello delle categorie). La prima soluzione diventa allora più convincente. Vi è poi sempre anche la soluzione di non categorizzarlo proprio in attesa che trovi qualche suo "compagno" e per cui resti "degno" della categorizzazione (nello specifico il Lierza aspetta la voce su qualche altro ruscelletto affluente del Soligo (fiume) prima di essere categorizzato come "affluente del Soligo"). Franco56 - (se vuoi, rispondi) 16:48, 2 nov 2010 (CET)
Per me la prima si può fare, tecnicamente è la più precisa (la terza ha il difetto, come dici tu, di essere poco visibile).--Cruccone (msg) 20:01, 2 nov 2010 (CET)
Anche a me sembra che la prima sia fattibile, anche perché penso che sia una eventualità non così comune e quindi non ci troverebbe ad avere n-mila categorie con 1/2 elementi. E soprattutto è molto più chiara della terza che è abbastanza macchinosa. Non mi esprimo sulla seconda che, a dire il vero, non mi pare così malaccio: perché l'avevate scartata? --Mr buick (msg) 21:23, 2 nov 2010 (CET)

Scusate, mi accorgo solo ora della discussione. OK su tutto, ho però un dubbio: perché la cat madre è Categoria:Fiumi per oceano e non "fiumi per mare"? In particolare, il mediterraneo fa parte dell'Oceano Atlantico? Certo ci sono mari per cui è facile trovare l'appartenenza ad un oceano (tipo ad es. il Mare del Nord), ma il Mediterraneo non l'ho mai visto categorizzato come parte dell'atlantico. Siete sicuri di questa classificazione? --Retaggio (msg) 11:08, 4 nov 2010 (CET)

Idem sul Mediterraneo. Vedi mia proposta poco sopra per il nome --Bultro (m) 13:09, 4 nov 2010 (CET)
Secondo me ha senso sia utilizzare come categoria madre "Fiume per oceano" e sia "fiume per mare". Se scelgo la categorizzazione "fiume per oceano" leggo nella voce mare l'attribuzione di ogni singolo mare al rispettivo oceano e quindi il Mediterraneo è parte dell'Oceano Atlantico. Eventualmente resta da discutere quanti oceani considero (3 (Atlantico, Pacifico ed Indiano), 4 con in aggiunta il Mare glaciale artico oppure 5 con l'aggiunta dei mari antartici); attualmente si sono considerati tre oceani ed il Mare glaciale artico. Se d'altra parte scelgo come categoria madre "fiume per mare" esprimo il fatto che "quando il fiume è giunto al mare là si ferma". Secondo il mio modesto parere io preferei la prima. Franco56 - (se vuoi, rispondi) 18:50, 4 nov 2010 (CET)
Per quanto riguarda il Mediterraneo, nelle nostre voci si può trovare sia che fa parte dell'Atlantico (per esempio è scritto in maniera implicita in Oceano) che non ne fa parte (Mar Mediterraneo) o una versione ibrida (vedi Oceano Atlantico). Considerato il dubbio, promuoverlo alla categoria madre mi sembra la soluzione migliore, perché è più facile trovarselo lì anche se non te lo aspetti che non trovarlo aspettandolo. Piuttosto, esiste una convenzione su quando usare "Mare" e quando "Mar"? Sul nome, "Fiumi per oceano" al momento di crearla mi sembrava più appropriata di "Fiumi per bacino" (perché la vedevo più come bacino del Po, del Reno che dell'Atlantico, del Pacifico), ma già per esempio i bacini endoreici stride. "Fiumi per massa d'acqua in cui sfociano" è corretto ma inutilmente barocco (in realtà poi ci sono fiumi che sfociano in terra). Cruccone (msg) 12:25, 5 nov 2010 (CET)
Classificando tutte le masse d'acqua della terra in oceani "non si può dire" che questo o quell'altro mare vi sta fuori (a parte quelli senza sbocco sugli oceani). Si parlerà invece di mari marginali e mari mediterranei ma sempre attribuibili ad un determinato oceano. Dal punto di vista concettuale mi sembra che si possa dire che il Mar Mediterraneo appartiene all'Oceano Atlantico (altrimenti a chi apparterrebbe?). Franco56 - (se vuoi, rispondi) 14:39, 5 nov 2010 (CET)

(rientro) Ora però la categorizzazione è sbagliata perché i sub affluenti sono categorizzati sia nella cat "Affluenti di XXX" che nella generica cat "Affluenti" (si veda ad es. Categoria:Affluenti della Romanche). Dovrebbero stare solo in quella più specifica.--Mr buick (msg) 10:20, 9 nov 2010 (CET)

La generica categoria "Affluenti" l'ho iniziata pensando che possa servire, conoscendo il nome del fiume, a cercare i suoi eventuali affluenti. Non so se mi sono spiegato. Qualcosa su questo avevo già scritto prima in questa stessa discussione. Franco56 -(se vuoi, rispondi) 18:48, 9 nov 2010 (CET)
È che in generale non amo molto le eccezioni alle regole (di solito, se necessarie vuol dire che le regole non sono state pensate bene) e questa che proponi è un'eccezione alle regole di categorizzazione; comunque, onestamente, non la vedo così necessaria: conoscendo il nome del fiume (ad es. Romanche) si va dalla pagina alla categoria in cui questa è inserita (ad es. Categoria:Affluenti del Drac) e qui eventualmente si trova la categoria degli affluenti del nostro fiume (ad es. Categoria:Affluenti della Romanche). Semplice, no? Del resto dubito che qualcuno inizi la ricerca proprio a partire da Categoria:Affluenti, perché penso che il normale processo di navigazione delle categorie sia quello che ho descritto sopra. Beninteso, non ho nulla in contrario a tenere Categoria:Affluenti del Rodano in Categoria:Affluenti, ma immagino che con soli certi fiumi perda l'utilità che avevi pensato per questa categoria.--Mr buick (msg) 10:08, 10 nov 2010 (CET)
Cose simili succedono per esempio: la Categoria:Montagne d'Italia è inserita nella Categoria:Montagne dell'Europa e nellaCategoria:Montagne per nazione. Sono due strade diverse che arrivano poi alla categoria madre Categoria:Montagne. Nel nostro caso una strada è quella che dal singolo affluente si passa tramite il fiume, poi il mare e poi l'oceano per arrivare alla categoria madreCategoria:Fiumi e l'altra è quella che partendo dall'affluente si passa tramite il nome del fiume e si arriva sempre alla stessa categoria madre. Certamente convengo con te che occorre rispettare la regola che la voce (o la categoria) non va messa nella categoria più generica e più specifica contemporaneamente; qui è rispettata perché si tratta di due percorsi paralleli. Altro discorso è se la categorizzazione da me iniziata abbia una certa utilità oppure no: a me sambrava che avesse una certa utilità. Spero di essermi spiegato meglio.Franco56 - (se vuoi, rispondi) 17:35, 10 nov 2010 (CET)
Semplicemente no, non è rispettata, perché Categoria:Affluenti della Romanche è sia in Categoria:Affluenti che inCategoria:Affluenti del Drac, anch'essa in Categoria:Affluenti; dovrebbe essere solo in Categoria:Affluenti del Drac--Mr buick (msg) 00:49, 11 nov 2010 (CET)
Una possibilità sarebbe metterci solo le categorie dei fiumi che sfociano nel mare (o bacino endoreico). Si evita il problema di categorie madri e figlie che sono sorelle, però il criterio di inclusione è di per sè arbitrario (e IMHO questo è un problema più grande).--Cruccone (msg) 09:55, 12 nov 2010 (CET)

Localismi nei capoluoghi di provincia italiani

Siamo it.wiki. I localismi che produciamo sono soprattutto relativi alle nostre località. Perché non cercare di revisionare insieme i nostri117 capoluoghi di provincia, in modo da arrivare ad un punto di ripristino? L'invito lo concretizzo con un bel cassettato, da strikkare via via che qcno revisiona le voci e le purga eventualmente. Occhio ai collegamenti esterni. --Pequod76(talk)02:05, 30 ott 2010 (CEST)

volendo esiste la parola "barrare" in italiano...--Bultro (m) 14:14, 30 ott 2010 (CEST)
[fuori crono] No, fuori dai ns in cui sta brutto, mi riservo di sfogare tutto il turpiloquio possibile. :P--Pequod76(talk) 20:47, 30 ott 2010 (CEST)
Partendo dai collegamenti esterni ridurrei il possibile, guardando Messina suggerirei (come nel caso di Roma) l'utilizzo delTemplate:Dmoz e l'eliminare quasi il tutto.--AnjaManix (msg) 16:07, 30 ott 2010 (CEST)
per esser meno provinciali andrebbe spostata, sul modello di Massa (Italia) e Potenza (Italia), Olbia ad Olbia (Italia), visto che ce ne sono parecchie altre Olbia (disambigua), poi Ragusa, visto l'esistenza di Ragusa (Croazia) e forse ancheAlessandria. 178.66.145.80 (msg) 23:02, 5 nov 2010 (CET)
IMHO no. Massa e Potenza vanno disambiguate perché in conflitto con la roba che si misura in kg e quella che si misura in W. Il nome della città di Olbia mi sembra il prevalente in italiano (non è un problema di localismo, ma di lingua) e Ragusa pure lei vince anche se di misura su Dubrovnik (giusto IMHO titolare la voce in italiano, ma la prevalenza è della città siciliana anche qui per diffusione linguistica). Per tornare IT, io darei una sfoltita alle sezioni "Personalità legate a..." che mi sembrano, nonostante le millemila discussioni, ancora sovraffollate di personalità irrilevanti in molte città. --Amarvudol (msg) 12:18, 9 nov 2010 (CET)
Dunque, per Olbia mi sembra palese che la città sia il significato prevalente (come per Roma tanto per capirci). Per quanto riguarda Alessandria, c'è da dire che mentre in italiano chiamiamo l'altra Alessandria d'Egitto (rispetto agli altri significati non vedo grossi dubbi su quale sia prevalente) per non fare confusione (per cui Alessandria e basta è la piemontese, a meno che non si parli di biblioteche), in quasi tutte le altre lingue è Alessandria e basta, per cui il significato prevalente sarebbe quello (in francese lo è, in altre lingue la "nostra" non la traducono). Su Ragusa non è così palese IMHO che l'italiana è prevalente rispetto alla croata, per lo meno non in modo netto (il numero di abitanti è confrontabile, Dubrovnik è relativamente vicina all'Italia e ha interagito molto, soprattutto con la Repubblica di Venezia, e le due città sono entrambe patrimonio dell'UNESCO). In sintesi secondo me: Olbia la lascerei com'è, Ragusa disambiguerei e Alessandria ci penserei. Cruccone (msg) 19:56, 18 nov 2010 (CET)

per favore, qualcuno può vedere che è successo alla voce? Una parte di testo era stata messa sopra, poi correttamente era stata tolta e per sbaglio l'avevo rimessa, insomma non si capisce più niente! Grazie mille! 93.33.6.55 (msg) 09:15, 1 nov 2010 (CET)

Tranquillo, come vedi da qua ora è tutto sistemato.--AnjaManix (msg) 11:43, 1 nov 2010 (CET)

Spam viacolvento

Potreste controllare/annullare gli edit di questo IP, e valutare l'importanza dei link, se possono essere considerate risorse (mah) oppure spam? Grazie mille. --Azrael 11:59, 7 nov 2010 (CET)

Vaglio Cesena

Segnalo che per la voce Cesena è iniziata la procedura di vaglio. Si accettano suggerimenti. Uomodis08 (msg) 20:57, 8 nov 2010 (CET)

Lago Malawi

Dato che Lago Malawi è una dizione comune, di più del semplice Malawi, che ne dite di spostare la voce Malawi (lago) a lago Malawi o lago Niassa, o qualsiasi altro titolo più bello da vedersi? Grazie, --82.60.119.235(msg) 14:13, 12 nov 2010 (CET)

Chiedo lo spostamento del nome ad un amministratore. Franco56 - (se vuoi, rispondi)19:09, 15 nov 2010 (CET)

Nizza Marittima

per un equivoco in una voce c'è scritto che una persona anzichè essere nata a Nizza Marittima è nata a Nizza Monferrato: c'è qualche fonte che attesti che questa Nizza Marittima adesso è nota semplicemente come Nizza? 93.33.8.87 (msg) 21:50, 14 nov 2010 (CET)

Un'ottima fonte dell'epoca è il Dizionario Geografico Storico-Statistico-Commerciale degli Stati di S. M. il Re di Sardegna, vol. XI, Torino 1843, voce "Nizza" (pagg. 656 ss.) e in particolare la 809 in cui si spiega che a questa città si diede l'aggiunto Marittima per indicare la sua giacitura sul Mediterraneo, ed anche per distinguerla dall'altra Nizza del Monferrato. Leggendo la voce risulta chiaro che si tratta dell'odierna Nizza.--Wiskandar (msg) 19:05, 15 nov 2010 (CET)
grazie mille davvero!! 93.33.4.79 (msg) 21:03, 15 nov 2010 (CET)

Toponimi in italiano

Segnalo la discussione in corso qui sull'eventualità di modificare le convenzioni sui titoli delle voci con toponimo italiano. --Crisarco (msg) 13:32, 25 nov 2010 (CET)

vaglio parco

Segnalo l'apertura di un vaglio per la voce Parco nazionale della Sila --ESCULAPIO @msg 15:55, 2 dic 2010 (CET)

Vaglio Catanzaro

Segnalo l'apertura del vaglio della voce Catanzaro. --Beppeveltri (msg) 10:57, 7 dic 2010 (CET)

Categoria Fiumi d'Italia

Volendo sistemare un po' la Categoria:Fiumi d'Italia mi sono trovato con questa problematica. La dicitura all'inizio della categoria diceCategoria che raccoglie voci riguardanti i corsi d'acqua (fiumi e torrenti) dell'Italia. Nelle varie regioni vi sono comportamenti diversi: o la categoria Fiumi del xxx (regione) raccoglie tutti i corsi d'acqua di quella regione oppure vien ulteriormente categorizzata in Corsi d'acqua del xxx. Io sarei per raccogliere nella categoria Fiumi del xxx i fiumi ed i torrenti di quella determinata regione. Cosa se ne pensa? Franco56 - (se vuoi, rispondi) 18:14, 9 dic 2010 (CET)

Direi di si, possiamo fare a meno delle "corsi d'acqua..." e mettere tutto in "fiumi...", se è questo che intendevi--Bultro(m) 21:07, 9 dic 2010 (CET)
Era questo che intendevo. Se non si adottasse questa soluzione (ovvero di mettere tutti i corsi d'acqua come torrenti e fiumare nella categoria fiumi) il problema poi si presenterebbe anche per tutte le altre nazioni.Franco56 - (se vuoi, rispondi) 21:23, 9 dic 2010 (CET)
Domanda da uno che vive nel territorio confinato tra Adige e Po, pieno di corsi d'acqua che vanno dal canale di scolo di un terreno agricolo ai vari canali di sempre maggiore portata tra naturali, artificiali e misti ai quali si è dato un nome proprio a seconda della loro importanza storico-culturale o di portata minima, non è eccessivo riunire un Adige, un Adigetto, un Canalbianco ed unRezzinella (l'ultimo per fortuna non c'è anche se ha una certa sua importanza storica locale...)?--Threecharlie(msg) 21:42, 10 dic 2010 (CET)
Non c'è neanche il Canalbianco, è un redirect. Per i canali artificiali c'è categoria:Canali artificiali; ma tra quelli naturali, come fai a distinguere in modo oggettivo fiumi da non-fiumi? quale sarebbe il criterio di demarcazione? --Bultro(m) 15:37, 11 dic 2010 (CET)
Sì, è un redirect perché attualmente è considerato un unico canale navigabile ma è come se fosse uno immissario dell'altro (è solo una questione di prospettiva) ed in ogni caso è un misto di fiumi naturali e canali artificiali, ed anche qui il limite è abbastanza POV in quanto magari nasco no naturali ma poi l'intervento dell'uomo è massiccio. IMHO bisognerebbe trovare qualcuno che lavori nel campo, un ingegnere idraulico ad esempio, e/o un testo che dia una collocazione "ingegneristica" più che geografica ad un dato fiume-canale border line. Se permetto provo a linkare la discussione ad uno degli estensori della voce dato che mi sembra particolarmente attivo nel settore. :-)--Threecharlie (msg) 15:48, 12 dic 2010 (CET)
Eccomi :) Presente in quanto appassionato sia dei fiumi della provincia di Rovigo sia di categorizzazioni, ma non in quanto ingegnere idraulico (in quanto non lo sono). Diciamo che, allo stato attuale della categorizzazione, ci troviamo (semplificando al massimo) di fronte al seguente dilemma: le categorie le chiamiamo tutte "Fiumi di/del/della ..." o le chiamiamo tutte "Corsi d'acqua di/del/della ..."? È chiaro che la scelta "Fiumi di/del/della ..." è la scelta più semplice, dato che si tratta di "rinominare" solamente tre o quattro categorie; d'altro canto è altrettanto chiaro che la scelta "Corsi d'acqua di/del/della ..." è quella semanticamente più precisa. Mi trovo d'accordo con Bultro che non ha senso tenere separati i fiumi dai "corsi d'acqua che non sono fiumi", quindi per quanto mi riguarda non trovo nulla di male a trovare nella stessa categoria il Po e il Rezzinella (anche se io avrei nominato il Ceresolo e, perché no?, la Polesella importantissima anche questa dal punto di vista storico). Dato che sono un appassionato contributore delWikizionario e dunque un appassionato di lessico, ovviamente la mia scelta va a "corso d'acqua", non tanto per l'idrografia della mia provincia natale ma per la definizione stessa di fiume, ossia "corso d'acqua che scorre prevalentemente in pianura": questo paradossalmente include nella definizione di fiume il Rezzinella ma altrettanto paradossalmente esclude l'Isarco. Poi se si decide che non c'è differenza tra fiume e torrente allora teniamo il nome "Fiume", se invece si decide che sono due cose diverse allora voto per "Corso d'acqua".--Achillu (msg) 09:39, 13 dic 2010 (CET)

Categorizzazione dei tmp di navigazione

Segnalo. --Pequod76(talk) 01:18, 10 dic 2010 (CET)

Evoluzione del template {{mappa di localizzazione}}

Mappa di localizzazione: Canada
Ottawa
Ottawa
Posizione di Ottawa utilizzando {{Mappa di localizzazione}} e una nuova proiezione non ortografica importata in {{Mappa di localizzazione/CAN}}

Da tempo mi sto occupando della evoluzione del template di it.wiki, per ora terribilmente in ritardo rispetto agli omologhi russi e tedeschi, recepiti dagli angolofoni di en.wiki, per una volta non leader di una questione tecnica. Ho preparato nella Discussioni template:Mappa di localizzazione#Richiesta di sblocco - adottiamo la sintassi compatibile con le mappe non equirettangolari una richiesta di sblocco del template attuale e sostituzione del codice con quello che ho tradotto nella {{Mappa di localizzazione/Sandbox}}. Ovviamente si può sperimentare il funzionamento del nuovo codice del template, che ci aprirà le porte all'utilizzo di carte non solo in proiezione ortografica (detta anche equirettangolare - vedi en:Equirectangular projection). Il problema è particolarmente sentito nelle regioni circumpolari, dove adesso siamo costretti a usare carte come ->questa<-, mentre con il nuovo codice potremo usare carte come ->questa<-. Ricordo che sono sempre di più gli infobox in grado di generare automaticamente carte di localizzazione, appoggiandosi al template di cui parliamo. Io per esempio ho attivato la funzione in molti template e sarei pronto per il template {{Infobox isola}} --EH101{posta} 10:54, 10 dic 2010 (CET)

Con i template ci capisco molto poco. Ma se si possono usare cartine non distorte certamente è molto meglio. Franco56- (se vuoi, rispondi) 18:27, 10 dic 2010 (CET)
Certo che si potranno usare. Di fianco ecco Ottawa. Fate il paragone con la cartina attuale nella voce Ottawa. Purtroppo è tutto bloccato e serve il consenso per fare sbloccare i template attuali. --EH101{posta} 19:25, 10 dic 2010 (CET)
Per quanto vale il mio consenso, sono pronto a darlo anche subito. Franco56 - (se vuoi, rispondi) 21:29, 10 dic 2010 (CET)
✔ Fatto Adesso possiamo cominciare a utilizzare le mappe non necessariamente equirettangolari. La mappa di destra qui, adesso è ottenuta con il template "ordinario" --EH101{posta} 22:28, 10 dic 2010 (CET)

Territorio

Visto che nessuno mi dà segni di vita, sgnalo qui questa richiesta che ho fatto. Grazie,--Azz... 15:54, 12 dic 2010 (CET)

Vaglio Anfiteatro morenico di Ivrea

Segnalo l'apertura di un vaglio sulla voce Anfiteatro morenico di Ivrea. --F Ceragioli (msg) 18:36, 12 dic 2010 (CET)

Potenziamento template infobox geografici

Riprendo qui quanto iniziato in varie talk. Grazie all'esperienza che ho maturato con il template {{infobox isola}} messo a punto nelsottoprogetto isole, posso adesso "migrare" quanto fatto a altri template geografici, portandoli a una versione "della seconda generazione". Prendendo visione del template per isole e arcipelaghi, potete notare alcuni potenziamenti rispetto ai template infobox della prima generazione:

  1. La grafica è allineata agli standard consigliati nella linea guida "Wikipedia:template sinottici". Per i più addentro alla materia, specifico che infobox isola utilizza una delle due soluzioni possibili, cioè si appoggia al metatemplate {{infobox}} che consente una standardizzazione grafica con tutti gli altri template sinottici e semplicità nella manutenzione.
  2. Inserendo le coordinate del luogo geografico e il codice ISO della nazione, appare automaticamente la cosiddetta "mappa di localizzazione". È comunque possibile indicare una mappa alternativa di sfondo, scegliendo tra un elenco. A differenza di quanto avveniva in passato, è possibile utilizzare adesso mappe non necessariamente in proiezione ortografica, a tutto vantaggio della leggibilità. Sono in corso sperimentazioni per l'adozione delle mappe polari per le regioni artiche.
  3. Inserendo il codice ISO della nazione, automaticamente il template infobox isola si predispone per la compilazione delle suddivisioni amministrative giuste. Facendo un esempio, scegliendo ITA, per Italia, il template si predispone per l'indicazione di regione e provincia italiana, riportando i link corretti alle voci che descrivono la struttura amministrativa italiana. Per esempio, si veda Isola di Montecristo dove la definizione delle voci di elenco Regione e Comune, con i rispettivi link, sono automatiche. Comune e il suo link (divisione amministrativa di terzo livello) devono essere inseriti ancora manualmente (oltre ai valori in questo caso Toscana, Livorno e Portoferraio), ma si potrebbe automatizzare anche il terzo livello.
  4. Se nel template non vengono citate delle fonti nel parametro "ref", automaticamente appare l'avviso "senza fonte" e la voce viene inserita in una categoria di servizio "voci con il template infobox isola senza fonti".
  5. Se l'infobox non ha l'immagine, la voce viene inserita automaticamente in una categoria di servizio "voci con il template infobox isola senza immagini".

È da tenere presente, che, una volta messo a punto un template infobox "della seconda generazione", è possibile sostituirlo in tutte le voci dove è presente il vecchio, grazie a un bot messo a punto da Gnumarcoo, il quale chiede però, venga prima concordata e messa a punto una tabella di conversione come quella presente in Utente:Gnumarcoo/SandboxAA. Un tempo, questa attività di sostituzione si effettuava manualmente, voce per voce, adesso grazie a Gnumarcoo e al suo bot, si sono già effettuate sostituzioni di massa come visibilein questa discussione. Resta quindi da impostare e concordare a livello generale cosa fare per template geografici che si vogliono potenziare, confidando che gli aspetti "tecnici" verranno messi a posto una volta delineata la fase di "progettazione" del template. Ovviamente serve un consenso per modificare quanto già esiste o creare nuovi template. --EH101{posta}14:43, 13 dic 2010 (CET)

I lavori per un sostanzioso rinnovo stanno andando avanti già da un pezzo in discussioni template:Comune --Bultro(m) 17:44, 13 dic 2010 (CET)
Una complicazione specifica la vedo con gli infobox geografici che possono coinvolgere due o più nazione come quello riguardante i fiumi oppure le montagne. E le complicazioni sono, per esempio: a che titolo si preferisce una nazione oppure l'altra per esempio nella mappa di localizzazione? Come si fa con le suddivisioni amministrative quando possono avere nomi diversi nelle varie nazioni coinvolte? Nell'{{infobox fiume}} l'hanno risolto come si può vedere dal templater stesso anche se lì non è prevista la mappa di localizzazione. Nell'aggiornamento del template {{montagna}} la cosa è tutta da studiare.Franco56 - (se vuoi, rispondi) 00:11, 14 dic 2010 (CET)
@Franco56: I francesi hanno risolto questo "problema" da un pezzo. La loro architettura per le "mappe di localizzazione" è totalmente diversa dal resto del mondo. Loro hanno una gigantesca mappa del mondo e sono in grado di ritagliare volta per volta la regione che gli interessa, prescindendo dai confini nazionali. Nel nostro caso, possiamo realizzare una soluzione "ibrida". Per i fiumi e montagne ben rappresentati dalla carta di una sola nazione, usiamo quella, per altri casi, possiamo impostare carte specifiche di regioni geografiche come Balcani, Europa orientale, Africa del sud, Oceania e così via. Anche in questo i francesi sono avanti, in quanto hanno messo a punto tutta una serie di istruzioni su come creare una mappa di localizzazione, con tanto di link a una utility on-line per individuare le coordinate dei quattro vertici di una mappa qualsiasi, operazione indispensabile per creare le mappe di localizzazione dove appoggiarci.
Operativamente, va fatta una lista di mappe non nazionali che servono e vanno create. Il template geografico deve avere un parametro per cui, se specificata una di queste mappe "speciali", ha la precedenza sulla nazione. Un esempio classico di quanto dico è {{Mappa di localizzazione/Alpi}}. Al momento, il template montagna, sa riconoscere solo montagne delle Alpi e aggiunge in automatico sotto alla mappa di localizzazione dell'Italia (?) una mappa dedicata. L'effetto è visibile in Gran Paradiso, per esempio, ma è tutto "fatto su misura" solo per le Alpi.
@Bultro:{{Comune}}, da quanto vedo, sta andando avanti per gli aspetti antropici, come è giusto che sia, e non mi sembra abbia fatto passi avanti nella direzione delle mappe. Sannita nella discussione che citi scrive testualmente Sulla mappa, mi sembra che il campo ci sia già, quindi one problem down, many others to go. Comunque, metto un link a questa discussione "prevalentemente geografica", caso mai ci fosse qualcosa che serve o si può derivare da questi lavori in quel template specifico e tutto sommato, già molto sviluppato, diffuso e credo meno abbisognevole di miglioramenti urgenti su scala mondiale. --EH101{posta} 10:02, 14 dic 2010 (CET)
Per dare una idea del fattibile, se il template montagna lo permettesse, basterebbe fargli puntare mappe di localizzazione comequesta per il Caucaso, o questa per i Carpazi, superando la limitazione attuale che gli fa "vedere" solo nazioni o Alpi. Meglio ancora, sarebbe dare la possibilità ai template geografici di puntare alle mappe fisiche e non quelle politiche. Per dare una idea, sto aggiornando le nostre mappe, affiancando laddove si può, a ognuno la versione fisica. Esempio {{Mappa_di_localizzazione/BRA}} dove al di sotto della mappa politica, adesso viene indicata la mappa fisica selezionabile ... se solo il template lo permettesse. Io sto indicando le evoluzioni possibili, ma per implementarle tutte, alcune, o in parte, serve il consenso. --EH101{posta} 14:56, 14 dic 2010 (CET)

[rientro] D'accordo per la riforma dei template geografici e l'eliminazione progressiva dei vecchi Geobox, ma non capisco perché usare{{Infobox}}. Non c'è consenso sull'uso del metatemplate rispetto alla classe - e nemmeno viceversa, tanto per dare l'idea di quanto è complessa la situazione.

Quanto alla mappa, intendevo dire che la nuova versione di {{Comune}} avrà, in aggiunta alla mappa automatica di localizzazione col pallino, anche un campo con una seconda mappa che potrà essere aggiunta successivamente da un qualsiasi altro utente. --Sannita - L'admin (a piede) libero 16:38, 14 dic 2010 (CET)

(@EH101: Non ho visto degli esempi dove i francesi usino questa mega mappa di cui ne prendono via via un pezzo; me ne puoi indicare qualche esempio?) Ho visto che i francesi nel loro infobox riguardante le montagne per i casi in cui la montagna è sul confine nel templano lasciano la possibilità di scegliere la cartina dell'uno o dell'altro paese (vedi per esempio Mont Blanc) anche se non hanno risolto del tutto la situazione quando la montagna è in un posto di triplice frontiera (cfr Mont Roraima dove è possibile vedere la cartina del Venezuela e della Guyana e non del Brasile). Hanno invece risolto bene il problema delle suddivisioni amministrative come si può vedere dagli stessi esempi. Franco56 - (se vuoi, rispondi) 17:39, 14 dic 2010 (CET)

@Sannita. Ciao, rieccoci qua. Non c'è notoriamente una linea guida che obblighi all'uso delle classi o di {{infobox}}. Un vecchio aforisma di Bismarck dice che chi ama i trattati di pace e le salsicce, non dovrebbe mai fare troppe domande sul modo con i quali entrambi vengono realizzati. Non ne farei un problema anche nel nostro caso. Io in sandbox potrei presentare un template fatto con un codice X, chi valuta il fatto che il template sia più potente dell'attuale, prescinde da come ho scritto il codice wiki della proposta. Un giorno, o un mese, o un anno dopo, chi arriva dopo di me potrebbe presentare un template fatto con codice Y. Sarà allora da decidere se la nuova proposta è più performante. Se chi ha fatto il template con il codice Y, ha dovuto ricominciare tutto da capo, è una sua scelta. Io per il codice X che proporrò, ricomincio tutto da capo senza fare una piega e il fatto che {{infobox}} sia molto più potente, facile da usare, correggere e manutenere di altre tecniche è la ragione. A chi piacciono le "classi", auguro buona fortuna: l'importante è che la complessità del codice, non costringa ad avere template limitati nelle prestazioni a causa del mal di testa, o della quantità di tempo necessaria per chi vuole sviluppare funzioni complesse e innovative come quelle di cui stiamo parlando. Io rimarraei per ora sul "cosa", stabilito ciò, il "come" ognuno potrà proporlo in apposite pagine di prova, prendendosi i suoi tempi e profondendo lo sforzo che vuole spendere. Chi valuta il risultato finale, sceglierà liberamente cosa approvare, anche cambiando idea ogni mese, se serve, in un continuo miglioramento delle "funzionalità" di questi template, che al momento (oggi 14 dicembre 2010), non brillano certo per potenza. Fino a l'altro ieri, avevamo il Canada e la Russia in proiezione ortogonale e non dovremmo dimenticarcelo. Quando le procedure e gli standard diventano un ostacolo allo sviluppo e non un incentivo, su Wikipedia li chiamiamo avvitamenti burocratici e ben sappiamo che bisogna ignorarli. --EH101{posta} 18:46, 14 dic 2010 (CET)
@Franco56. I francesi in pagine come questa fanno capire come sono avanti. Inquesta guida spiegano come ottenere cartedécoupée - ritagliate, in questa il loro approccio alla geolocalizzazione. Ciò non vuol dire che tutti i loro template sono potentissimi, pieni di funzioni e sopratutto da copiare a mani basse, quale che sia la parte del mondo, ma di certo seguire i loro tutorial consente a un "cartografo" di preparare cartine al confine tra nazioni, come quella tra Venezuela, Guyana e Brasile che indicavi, a patto di fare una semplice richiesta. Come dicevo più sopra, possiamo organizzarci con richieste di mappe, appoggiandoci al nostrolaboratorio grafico per la gestione dei lavori, ma prima dobbiamo avere template in grado di utilizzare quanto prodotto. Ovviamente mi candido a rispondere presso il laboratorio grafico per la messa a punto delle cartine quando saremo pronti a usarle. --EH101{posta} 18:46, 14 dic 2010 (CET)
Io ho espresso la mia opinione. Non ho detto che mi opporrò fino alla morte, ho detto che non c'è consenso e che le opinioni su performanza e robe simili del template sono tue, e non sono condivise (da me e da altri, punto). Per il resto, sono d'accordissimo a rivedere i template in modo tale da migliorare la grafica e l'usabilità, sono d'accordissimo ad inserire una seconda mappa che si abbini a quella di localizzazione (quella col puntino, per intenderci), sono d'accordissimo su tutto, tranne che sull'uso di Infobox. Tutto qui. Non vorrei che scambiassi per avvitamento burocratico una mia opinione. -- Sannita - L'admin (a piede) libero 20:48, 14 dic 2010 (CET)
Quoto Sannita: Sono contrario all'uso del metatemplate e non mi sembra che il suo utilizzo porti vantaggi. Gvf21:15, 14 dic 2010 (CET)
Un'altra cosetta su sui non c'era consenso è il parametro "ref", men che meno se obbligatorio, ci sono altri modi di citare le fonti--Bultro (m) 23:10, 14 dic 2010 (CET)
Va bene, c'è il rischio di troppi fraintendimenti e davanti a tre (3) amministratori faccio meglio a non commentare per non peggiorare ulteriormente le cose, quando invece il mio è un desiderio di "fare". Io ho delle mie idee, che spero mi consentirete di avere: vi prego di non interpretarle e di non farmi dire cose che non dico. Io non scambio, non ipotizzo, non attribuisco opinioni altrui: per favore fate lo stesso con quanto ho detto finora. Non commenterò più.
Passando all'operativo, provo a semplificare la cosa e a renderla pratica e diretta: In questa Template:Montagna/Sandbox c'è la nuova proposta di template montagna (per iniziare) che adotta molte più soluzioni dell'attuale. Chiedo ai partecipanti a questo progetto di:
  • esprimersi sull'adozione della bozza di template: se contrari, propongano contestualmente un nuovo template di caratteristiche uguali o migliori, o spieghino perchè l'attuale "vecchio" è migliore della proposta. Nulla vieta che domani, tra un giorno o un anno, venga fatta una altra proposta migliorativa con un template diverso e ci esprimeremo nuovamente. Della faccenda metatemplate, al progetto geografia, non ne farei menzione, come causa sufficiente per il respingimento di un template più potente di uno esistente, per di più in assenza di una controproposta. Ovviamente, dopo aver accettato il template, sono benvenute richieste di implementazioni, varianti e rettifiche. Per esempio, se il ref non piace, stante la minima partecipazione a questo dibattito, bastano due pareri contrari al mio, per farlo togliere in un baleno.--EH101{posta} 00:41, 15 dic 2010 (CET)
Ho visto le due applicazioni fatte della bozza di infobox montagne sul monte Bianco e sull'Aconcagua. Mi pare un buon passo avanti. Alcune osservazioni: quando vi sono due nazioni occorrerebbe poter distinguere tra suddivisioni amministrative della prima nazione e della seconda nazione (eventualmente tre o quattro nei pochi casi che si presentano - ad esempio Roraima (monte) - nel caso in esempio tra le regioni italiane e le regioni francesi, tra le provincie italiane e i dipartimenti francesi). Per quanto riguarda la cartina di geolocalizzazione mi sembra una buona soluzione quella di poter scegliere tra una cartina nazionale (quando il monte è completamente in quella nazione) oppure tra una cartina diversa quando è sul confine così da non privilegiare una nazione oppure l'altra oppure per pezzi nazionali staccati (esempio l'Alaska e la Groenlandia - mi piacerebbe vedere un esempio su queste montagne). Il ref nel template non mi piace, lo toglierei. Ultimo: i parametri SOIUSA del template vanno sistemati. Mi sorge poi la domanda se sia utile poter inserire altri parametri come la prominenza della montagna, il suo isolamento topografico e la vetta principale (come ho visto sugli analoghi template in lingua tedesca ed inglese). Franco56 - (se vuoi, rispondi) 07:59, 15 dic 2010 (CET)
Mi limito a quotare Franco56, dal momento che l'altra critica riguarda l'impossibilità di mettere il noinclude al template - e dal momento che il problema discende dall'utilizzo di {{Infobox}}... -- Sannita - L'admin (a piede) libero 12:50, 15 dic 2010 (CET)
Partiamo dal fondo: ✔ Fatto tolto "ref". Nessun problema, può valere la pena aggiungere che il sistema era l'unico in grado di indicare in automatico l'assenza di fonti per i dati e addirittura inseriva automaticamente la voce in una categoria di servizio con l'indicazione della assenza di fonti. Wikipedia vorrebbe che prima ancora di scrivere che il Monte Bianco è alto 4.810,45, ci si ponga il problema di dare evidenza di dove abbiamo trovato questo dato e con precisione. So bene che esiste il sistema delle note a piè di pagina, ma so anche che non esiste nessun sistema per avvisare in automatico che non ci sono, e dati così meticolosi non hanno nella stragrande maggioranza dei casi reali, nessuna fonte di riferimento citata. Nessun problema comunque.
Quando vi sono due (o più) nazioni, il campo automatico si disabilita e lascia al compilatore il compito di riportare, se vuole, il link alla voce delle regioni, province, ecc. appropriate. Se il compilatore non scrive niente, in automatico adesso appare Regioni, Province, ecc, generico. Naturalmente posso implementare il codice per automatizzare il caso di due o finanche più stati, ma, vista la complicazione del codice, volevo aspettare di capire l'accoglienza generale al template.
Per quanto riguarda le mappe automatiche posso ulteriormente implementare la seguente sequenza:
  • C'è una mappa indicata ? (es. regione montana come i Carpazi o Alaska al posto di USA) mostra la mappa indicata
  • Non c'è indicazione ? Controlla se al codice dello stato è associata una mappa fisica e usala in automatico
  • Non c'è mappa fisica? Controlla se al codice dello stato è associata una mappa politica e usala in automatico
  • Se non ci sono mappe automatiche, passa oltre.
I parametri prominenza, isolamento e vetta sono facilmente inseribili. Basta indicare dove (primo o dopo quale degli altri parametri)
Anche il controverso SOIUSA si può facilmente modificare. Se leggete la wiki tedesca, scoprirete che la teoria abilmente presentata nelle varie lingue, sembra da uno stesso team (beati loro a essere così poliglotti), in Germania non è così quotata come i vuol far credere. Non sapevo la faccenda del SOIUSA (ero fermo a "ma con gran pena le tira giù" il mnemonico per ricordare le Alpi), ma per quello che capisco di tedesco, sembra che il lavoro SOIUSA sia prevalentemente italo-francese.
Creerò comunque esempi nel manuale della sandbox.
@Sannita: non ho capito quale delle critiche di Franco56 secondo te va risolta con un noinclude. Non ho visto nulla di quanto suggerisce di non realizzabile. infobox fornisce l'impianto di base per i template complessi, ma quando si chiedono funzioni complicatissime, con controlli e ipotesi multiple, solo per quella riga si utilizza il codice ordinario e l'html se si esagera con le richieste. Alla fine la cosa si risolve in due o tre campi particolarissimi per template e amen. Tutto il resto si aggiunge, toglie o cambia in modo semplicissimo. Tutto già fatto, anche in passato. --EH101{posta} 14:22, 15 dic 2010 (CET)

✔ Fatto Esempio di funzionamento con mappa diversa da quella nazionale: vedi esempio in manuale in bozza per Vulcano in Alaska. Si paragoni con l'attuale voce Vulcano Amukta. Con l'occasione segnalo che la mappa dell'Alaska è una delle nuove mappe con algoritmo di correzione per la compensazione della proiezione. Notate come il vulcano centra esattamente l'isola delle Aleutine nella mappa, a conferma della validità dell'algoritmo e della trasposizione da noi su it.wiki.

Visti i problemi e le limitazioni del template attuale, come per questo caso in Alaska, io penso dovremmo passare subito al nuovo template. La progressiva ulteriore implementazione di soluzioni al momento neanche ipotizzate dal template attuale, la si potrà continuare tranquillamente nei prossimi giorni, anzi, proprio con la sostituzione del vecchio template con il nuovo, si evidenzieranno alcune ulteriori casistiche da gestire. Come già fatto molte volte in casi simili, per rendere il passaggio il più "indolore possibile", verrebbe creato un nuovo template{{infobox montagna}}, mentre l'attuale non viene cancellato o sovrascritto, ma trasformato in redirect al nuovo. Dopo un tempo adeguato e quando il bot sarà pronto, il bot sostituirà da vecchio template a nuovo in tutte le voci.--EH101{posta} 16:24, 15 dic 2010 (CET)

Calma, il template è stato lì per anni, adesso possiamo aspettare qualche giorno per rifinirlo... Quello che correggerei:
  • non c'è motivo di usare le classi inglesi tipo "toccolours vcard", abbiamo le nostre di default
  • toglierei i campi nota/notafinale. a quanto ricordo, i campi per inserire "varie ed eventuali" sono stati sempre evitati
  • come nome lascerei il più semplice Montagna (su questo sarebbe ora di decidere una regola generale) --Bultro(m) 16:51, 15 dic 2010 (CET)
Non concordo. Se un template ha limitazioni, lo si sostituisce. Se si hanno obiezioni, le si fanno. Chiedere tempo per sviluppare ancora, personalmente non la trovo una obiezioni sufficiente a motivare un rollback per esempio. Non ho mai visto un rollback a una voce piena di errori di ortografia con la motivazione "aspettate, la voce è stata così per anni, ho in preparazione un trattato, non correggete nel frattempo che lo finisco, diciamo i prossimi tre mesi". Le correzioni, ampliamenti, finanche la riscrittura totale o la cancellazione, può avvenire tranquillamente con il template già attivo.
toccolours vcard non va bene ? Nessun problema. Quale devo mettere ? È cosa di un attimo. Per mia curiosità, chi ha deciso le classi di default di it.wiki, come, dove e in che modo ?
Montagna vs Infobox montagna. Il vantaggio di non sovrascrivere il "vecchio template" è quello di consentire una transizione più semplice tra "prima e dopo". Template montagna, poi, è il nome di un template navbox che se volete preparo con il link a voci come cresta, vetta, sella, crinale ecc. per consentire la navigazione tra i termini che descrivono una montagna.
Nota e nota finale, se non ci sono favorevoli al mantenimento li tolgo in un attimo. Non ho nozione di una discussione e successivo concordamento per l'abolizione di campi del genere. Al contrario, mi sembra di ricordare template (con i quali non ho mai avuto niente a che fare ovviamente) che li hanno. Se non servono, togliamo. Si potranno rimettere se serviranno. Rimarco che avere una funzione facoltativa è un di più: toglierla non capisco che vantaggio porti. --EH101{posta} 17:35, 15 dic 2010 (CET)

Come anticipato, ecco di seguito quanto promesso:

Secondo me, questo tipo di template va chiamato montagna, mentre gli infobox vanno divisi anche nel nome da questi template di navigazione per voci. Quando avremo sostituito tutti gli infobox con i nuovi, potremo ridare a "montagna" lo scopo che ritengo debba avere.--EH101{posta} 20:04, 15 dic 2010 (CET)

Di solito l'avremmo chiamato Montagne, comunque nel caso specifico c'è già il portale:montagna --Bultro(m) 21:26, 15 dic 2010 (CET)
Allora già che ci siamo diciamo un'altra cosa: poichè il template nasce per gestire anche i vulcani, altopiani, colline e, perchè no, pure alture sottomarine, io lo chiamerei "infobox rilievo". Resta tutto da stabilire se vogliamo gestire con questo template anche le catene montuose e se sì, che tipo di informazioni vogliamo mettere. --EH101{posta} 21:57, 15 dic 2010 (CET)
Ho apprezzato molto il lavoro fatto fin qui da EH101. Preciserei che attualmente il template gestisce montagne, vulcani, colline e, forse, alture sottomarine (non mi pare di aver visto utilizzi per altopiani - escluderei l'utilizzo per catene montuose perché vi sono altri tipi di parametri ed informazioni).

Un discorso particolare vorrei farlo circa la SOIUSA: a seguito di varie discussioni (per esempioquesta) si è adottato nella vikipedia in lingua italiana come classificazione ufficiale delleAlpi la SOIUSA e di implementare il template montagna con la classificazione SOIUSA delle stesse. La SOIUSA ha il vantaggio rispetto alle altre (Partizione delle Alpi, AVE, ecc) di non essere vecchia come la Partizione, di non essere solo parziale come l'AVE, di non essere locale come lo sono le varie classificazioni francesi, svizzere, italiane, ecc. La SOIUSA ha inoltre fatto un grande sforzo di armonizzazione tra le varie classificazioni. Secondo me su questo aspetto specifico, siamo più avanti delle altre wikipedie. Per contro è pur vero che la SOIUSA è ancora molto italiana e non è ancora universalmente riconosciuta. L'inserimento della classificazione SOIUSA nel template è una grande peculiarità della nostra wikipedia che conserverei nel nuovo template che andiamo a costruire. La bozza che intanto ho visto (preparata da EH101) anche se i vari parametri SOIUSA mi sembrano scritti nell'ordine giuto non vengono resi in forma completa e nell'ordine previsto secondo quanto descritto nella voce codice della SOIUSA dove viene anche riportato il template {{SOIUSA}}. Franco56 - (se vuoi, rispondi) 00:04, 16 dic 2010 (CET)

  • ✔ Fatto Ecco che cos'era ! Risolto. Nell'esempio del Monte Bianco nel manuale in bozza si può vedere il funzionamento. Adesso funziona e a questo punto direi di tenerci pure il SOIUSA. Il template specifico che ottimamente ci ha indicato Franco56, però, propongo di abolirlo, in quanto chi vuole mettere i dati, utilizzi direttamente Infobox rilievo, al limite senza le altre informazioni sulla montagna. La grafica sarà identica a quella del SOIUSA "solitario", ma tutto sarà predisposto all'espansione, magari a cura di qualcun altro. Se non ci sono contrari, inizio con l'apporre nel template {{SOIUSA}} l'avviso "unire" e inizio le pratiche di orfanizzazione e quant'altro, che precederanno la richiesta di cancellazione. --EH101{posta} 08:30, 16 dic 2010 (CET)
  • ✔ Fatto Ulteriormente potenziata la funzione delle mappe di localizzazione. Al momento, la logica di funzionamento è la seguente:
    • Se indicato |Nomemappa = ha la precedenza, altrimenti se esiste una mappa associata a |Codice paese = il template tenta di usare quella. Se le due condizioni non sono verificate, non appare nessuna mappa, quali che siano le coordinate indicate
    • Si possono usare sia le coordinate in formato gradi, primi, secondi, NS che lat e long in formato decimale. Rispettivamente, se manca |Longprimi= o |Long= (dimenticanza o completa assenza di coordinate), non appare nessuna mappa.

Ripeto la mia valutazione secondo la quale già adesso la bozza in sandbox è meglio dell'attuale template e funziona. Ulteriori potenziamenti o varianti sarebbero solo "ad aggiungere" e possono benissimo essere fatti nei prossimi tempi, senza con ciò impedire l'inizio della fase di transizione al nuovo template.
Al momento sono presenti tre proposte per il nome al "nuovo template" Montagna, Infobox montagna, Infobox rilievo. Personalmente trovo più valida quest'ultima denominazione. Stabilita questa definizione, non riesco a vedere motivi per non iniziare a usare il nuovo template, fermo restando che sviluppi e potenziamenti ulteriori seguiranno. --EH101{posta} 11:11, 16 dic 2010 (CET)

Tendenzialmente, sono favorevole a nomi contenenti "Infobox" nel titolo. Io sarei per elevarlo a linea guida, stile fr.wiki, magari in una discussione che adotti proprio le linee guida su come si devono fare gli infobox che hanno i cuginetti - e non è detto che il fantascientifico giorno in cui non avrò robe da fare non lo proponga.
Back on topic: attendere non è un segno di sfiducia o un tentativo di eliminare il metatemplate, ma piuttosto una scelta razionale. Visto che stiamo discutendo, meglio fare tutte le modifiche ora, anziché intervenire ad ondate successive.
Sulle classi: sarebbe meglio utilizzare le classi standard che abbiamo noi, per motivi puramente grafici e di standardizzazione fra tutti i template.
Nota e nota finale: sarebbe meglio toglierli. Esiste la sezione "Note" apposta all'interno della voce, tenerne un'altra all'interno del template è qualcosa che non ho mai condiviso nemmeno per {{Stato}}.
Spero di non aver dimenticato qualcosa. -- Sannita - L'admin (a piede) libero 11:50, 16 dic 2010 (CET)
Sì, c'era una cosa che avevo dimenticato: non mi piace - gusto personale - l'uso di <code> nel manuale per gli esempi. Io di solito utilizzo <pre>. Vedi ad esempio Template:Provincia canadese/man o Template:Federazione sportiva/man. --Sannita - L'admin (a piede) libero 11:53, 16 dic 2010 (CET)

Ho visto la sistemazione della bozza di template per quanto riguarda i dati SOIUSA (bene). Il template {{SOIUSA}} era stato lasciato per poterlo utilizzare da solo (infatto il template {{montagna}} se non completo almeno nei parametri obbligatori dà errore). Mi piacerebbe anche la sistemazione delle suddivisioni amministrative per le montagne sul confine (ad esempio per la bozza realtiva al monte Bianco mi piacerebbe vedere in fianco alle suddivisioni amministrative qualcosa di più preciso come si vede nella wiki in lingua francese fr:Mont Blanc - come altro esempio Punta Gnifetti come si vede in fr:Pointe Gnifetti). Per quanto riguarda il nome, tra quelli proposti sarei per infobox rilievo (visto che può essere usato anche per colline ed altro che tecnicamente non sono montagne). Toglierei anch'io i paramtri nota e nota finale. Infine se, come si afferma, è poi facile correggerlo ed implementare nuovi parametri allora sarei per dargli ilvia presto fino a che il ferro è caldo. Franco56 - (se vuoi, rispondi) 16:48, 16 dic 2010 (CET)

Ti riporto le mie considerazioni sul template da te proposto:
  • Per i sinottici mi va bene l'uso del prefisso infobox anche se sarebbe più corretto usare sinottico.
  • Ritengo molto più semplice ed efficace l'uso delle sole coordinate in decimale (come parametro): per mettono di evitare un mucchio di parametri (si usano due parametri anziché otto), di errori e sono facilmente gestibili con un codice molto più semplice.
  • Sono assolutamente contrario all'uso di classi diverse da quelle "standard" per i template sinottici già presenti nel nostro progetto ed ancor più a stili "in-line" quando sono presenti le classi in quanto eliminano l'uniformità per cui sono state scritte le classi e bloccano la possibilità di personalizzazione che le classi introducono.
  • Mi sfugge la necessita di controllare la presenza della bandiera del paese dato il codice ISO: dovrebbero esserci tutte per definizione oltretutto se manca ti limiti ad ignorare il parametro senza dare nessun tipo di errore. Che vantaggio poi da l'uso del template{{Bandiera}} rispetto all'uso dei template della categoria:Template bandierine nazionali tipo {{ITA}}?
  • Sei livelli di suddivisione amministrativa? e dove esistono? Perché tornare a mettere su ogni voce i nomi delle suddivisioni quando è stato creato il template {{DivAmm}} proprio per averli standardizzati? Perché poi mettere di default regioni/province e comuni? Non mi sembra siano assolutamente degli standard di divisione amministrativa a livello internazionale. Il miglioramento sarebbe IMHO usare solo{{DivAmm}} studiando una soluzione per gestire i casi di oggetti con più nazioni.
  • Il link all'unità di misura dell'altezza non dovrebbe essere a metri sul livello del mare come sull'attuale template, perché spostarlo nell'etichetta?
  • L'attuale template se metti coordinate fuori mappa se ne accorge e te lo segnala. Perché hai tolto tale funzionalità?
  • A parte quanto scritto sopra e all'uso del metatemplate (su cui mi sono pronunciato) che altre innovazioni avresti introdotto tali da richiedere la riscrittura e sostituzione del template attuale? Confrontando il monte bianco attuale con quello del tuo esempio non vedo queste grandi innovazioni, tutt'al più un peggioramento. Fra l'altro la suddivisione fra la due colonne dell'attuale template mi sembra migliore.
Insomma miglioramenti possibili ce ne sono, ma non mi sembra che la tua soluzione ne introduca molti... Gvf 17:21, 16 dic 2010 (CET)
P.S.: relativamente al vulcano riportato nell'esempio: è vero che su quella cartina viene riportato in posizione corretta, quello che non viene detto e a cosa si riferisce la cartina: mi spiego bello vedere un puntino nella giusta posizione ma se non sai a cosa si riferisce la cartina è poco utile. Nella soluzione con le cartine politiche almeno si sa che fa riferimento alla nazione, ovviamente c'è il problema di quando ci sono due nazioni. Usare una piantina di "qualcos'altro" non mi sembra dia molte informazioni.
@Gvf se permetti una mia opinione ok, posso anche capire che una mappa politica dovrebbe essere a prova di ignorante ma dato che si sta parlando di geografia fisica e non politica (e da ignorante credo sia differente l'ubicazione di una città da quella di un vulcano) in una realtà che ha oramai navigatori anche integrati nel cellulare credo che questa ignoranza sia più da attribuire a chi non vuole che a chi non possa capire e sinceramente a me la soluzione di EH101 piace. L'esperienza portata poi nel progetto dall'uso del template infobox è concreta e, a me che dichiaro nuovamente la mia ignoranza, forse mi muoverei meglio con quel tipo di template ma ammetto che basta imparare con adeguato manualetto di istruzioni e tutto si dovrebbe risolvere.--Threecharlie (msg) 21:14, 16 dic 2010 (CET)
@a tutti: tra le cose che ho letto non mi spiego ad esempio perché mai sia da preferire (o sia da utilizzare solamente) il template con le coordinate non separate in gradi, primi e secondi che, sempre per la mia ignoranza, ma danno un'idea più affine alle coordinate che non una cifra con la virgola.--Threecharlie (msg) 21:14, 16 dic 2010 (CET)
Rispondo a Gvf e chiudo fin quando non ci sarà consenso al proseguimento delle attività, che come sono ora ritengo bloccate.
  • "Ritengo molto più semplice ed efficace l'uso delle sole coordinate in decimale per mettono di evitare un mucchio di parametri (si usano due parametri anziché otto)" - non è chiaro dal manuale. Le coordinate in gradi minuti o secondi sono una funzione in più, non obbligatoria. Se si vogliono usare le cordinate in decimale, si usano quelle, altrimenti si usano le altre, non tutte e due. Le funzioni facoltative sono facoltative: usare otto parametri per le coordinate non ha nessun senso. È da notare che lo stesso "problema" identico ci sarebbe per il template coordinate, che infatti accetta vari tipi (non contemporaneamente). Chi va a chiedere anche a quello di usare solo le coordinate decimali ? Mia sintesi: miglioramento visto come complicazione e rifiutato.
  • "Sono assolutamente contrario all'uso di classi diverse da quelle "standard"" - terzo accenno a classi standard. Nessun riferimento a quali siano, dove sia stato deciso che sono standard e come posso fare a usarle. Sintesi: miglioramento rifiutato per non aderenza a "standard" enunciato ma non spiegato, malgrado reiterate richieste.
  • "Mi sfugge la necessita di controllare la presenza della bandiera del paese dato il codice ISO: dovrebbero esserci tutte ..." - Mia sintesi: miglioramento visto come complicazione e rifiutato basandosi sul "dovrebbero esserci tutte"
  • "Che vantaggio poi da l'uso del template {{Bandiera}}..." - Se è inutile, perchè non ne è stata proposta la cancellazione. Se non è inutile, cosa vuole dire questa obiezione. Se sono la stessa cosa, perchè farne una questione ? Mia sintesi:boh ?
  • "Sei livelli di suddivisione amministrativa? e dove esistono? - due nazioni con tre livelli ognuna, tutte totalmente personalizzabili. Secondo una teoria (fino a quattro paesi confinanti per una montagna) in teoria ne servirebbero 12. Ad ogni modo è un altro ... miglioramento visto come complicazione e rifiutato (mia sintesi)
  • "Perché tornare a mettere su ogni voce i nomi delle suddivisioni quando è stato creato il template {{DivAmm}} proprio per averli standardizzati?" - Perchè non tutto il mondo è stato coperto. Notare che se il campo non è compilato, automaticamente scatta il template citato. Non è obbligatorio compilarlo. Secondo me è un altro miglioramento visto come complicazione e rifiutato (mia sintesi)
  • "Perché poi mettere di default regioni/province e comuni?" - Perchè sono meglio di niente se nessuno scrive nulla e il template DivAmm non funziona. Ah già, DivAmm funziona: delle due l'una: o funziona e quindi regioni e province non apparirà mai, o non funzione e quindi la riga di sopra ... insomma, si faccia pace. Comunque è una funzione supplementare, un'altra che è un miglioramento visto come complicazione e rifutata (mia sintesi)
  • "Il link all'unità di misura dell'altezza...". Che problema c'è: possiamo spostarlo in un attimo
  • "L'attuale template se metti coordinate fuori mappa se ne accorge ...". L'attuale proposta, da la possibilità di risolvere il problema non di avere pagine con la scritta. Se è meglio la scritta della mappa che risolve, siamo in presenza di un altro potenziale miglioramento visto come peggioramento e rifiutato (mia sintesi)
  • "che altre innovazioni avresti introdotto tali da richiedere la riscrittura e sostituzione del template attuale?". Secondo me era più semplice dire che il template attuale è buono così e va lasciato così. È una opinione sintetica comprensibile e come quelle di tutti rispettabile (ci mancherebbe). Fin quando sarà la maggioranza a pensarla così, il template rimarrà così.
  • "Confrontando il monte bianco attuale con quello del tuo esempio non vedo queste grandi innovazioni, tutt'al più un peggioramento.". Ok chiaro ! Ho capito.
  • "...i template sinottici già presenti nel nostro progetto... ". No, il "nostro" non l'ho capito. forse volevi scrivere in questo progetto. Nostro è un altra cosa.
Concludendo: due favorevoli, un contrario, Sannita ago della bilancia e attesa altri pronunciamenti. Mi è già successo che con un contrario e sei favorevoli, siamo stati costretti a fare quello che diceva il contrario. Wiki non è una democrazia della maggioranza. Chi mette un veto lo fa secondo quanto ritiene giusto e i pareri si "pesano" e non si "contano". Sono sereno e ho provato a fare qualcosa per questo progetto, non è piaciuta: fa niente. È utile però provare a migliorare la situazione e poi comunque penso che sia stato, finchè è durato, una discussione utile. Il testo rimarrà qui per anni e anni e potremo "saccheggiarlo" dall'una e dall'altra parte in tante occasioni. Il vulcano in Alaska ? Beh, c'è su altre wiki, dove evidentemente hanno template peggiori, ma vuoi mettere le nostre classi ?--EH101{posta} 18:40, 16 dic 2010 (CET) (ma quali ?)

Aggiornamento.
Per curiosità, ho raccolto la sfida e malgrado nessuno me lo voglia dire, ho cercato cosa sia considerabile una classe standard, chi l'ha decisa, quando e in base a quale discussione. Credo di avere capito cosa sia successo, e rileggendo l'ultima frase di sopra, mi sono reso conto di quanto sia stata pericolosa per me. Leggendo questo ->diff<- ho scoperto che il 22 agosto 2007 fu modificato il common.css di Wikipedia in italiano inserendo delle classi per i navbox. Chiunque sia stato (nel diff il nome si legge e lì ho cominciato a preoccuparmi) ha fatto bene, qualcuno doveva pur fondare questa Wikipedia (inchino deferente di chi non vuole essere decapitato, ma che comunque porge la testa). Francamente non sapevo chi, come e quando era successa questa cosa, adesso lo so. Basterebbe adesso trovare dove è stato deciso che sono le classi da usare e tutto si completerà e possiamo pure chiudere la questione rapidamente. C'è questa discussione da qualche parte ? Purtroppo nel diff non c'è riferimento, mentre nella pagina di discussione del commons.css io ho trovato solo un messaggio ->questo<- ai pochi presenti (era il 2007) nel quale chi ha aggiunto la classe scrive che ha aggiunto una classe per i sinottici. (nuova distensione per terra a pelle di leopardo per evitare la fine del suddetto animale, feroce ma morto, ucciso dal cacciatore silenzioso, ma armato) Non ha apparentemente ricevuto nessun commento. Direi che, se fosse così, come consenso siamo a "1". Messa così, basterebbero due persone per cambiare tutto, ma siccome non credo possa essere una cosa così, quanto prima magari ci sarà qualche dato in più per capire quanto consenso ha questo concetto di "standard".

Questo comunque è il progetto geografia. Nel frattempo, ho applicato comunque, disciplinatamente, queste modifiche stilistiche al template in bozza, anzi ho preso il "monte di paragone" Monte Bianco e ho velocemente modificato la bozza per imitarne le caratteristiche. Perchè no.

In questa sandbox ho messo fianco a fianco il vecchio template copiaincollato da Monte Bianco e la bozza nuova. Sinistra vecchio - destra bozza nuova. Dove sono le differenze ora ? Ci sono naturalmente: quali sono talmente importanti da dover modificare ? Ditelo e corro a farlo. Ormai è un esercizio fine a se stesso, perchè la bozza non passerà, però potrebbe comunque essere interessante riflettere su alcuni aspetti e io intanto scopro cose che non sapevo. Davvero.

Subito sotto al Monte Bianco (non in Liguria) però, c'è il Vulcano Amukta. Sinistra vecchio - destra bozza nuovo. A parte che l'Alaska è uno stato federato e non una regione come dice il vecchio template, a me sembra di scorgere un'altra differenza per come sono adesso le cose. Attenzione, per rendere la competizione alla pari, magari il template "vecchio" non è stato compilato al massimo delle sue possibilità: chiunque voglia farlo, ne ha facoltà ovviamente.

Per concludere, io lascerei fianco a fianco questi 4 esempi. Anche chi non conosce la programmazione, potrà dire "un po' più blu, un po' più alto, la mappa prima, lo spazio dopo, ecc. Alla fine, io penso che il risultato sarà comunque un miglioramento. Magari per il vecchio template: perchè no. --EH101{posta} 22:29, 16 dic 2010 (CET)

Non intendo prendere parte alla discussione, né risultare determinante in alcunché, soprattutto dal momento che sono costretto a prendere atto del tuo atteggiamento vittimista. Gvf non è il Vangelo fatto amministratore, ma è una persona che a livello tecnico ne capisce. E trovo francamente infantile rimarcare, volta dopo volta, il fatto che chi ti si oppone sia un amministratore, in modo tale da passare come la povera vittima che vuole fare, ma che viene limitato nei suoi movimenti dalla cricca brutta e cattiva.
Sei un utente che lavora, che si fa un culo così per questo progetto e che ha saputo, in collaborazione con altri utenti, risistemare una parte non indifferente delle nostre voci. Te lo chiedo per l'ultima volta, in maniera gentile: smettila con questa infantile, insopportabile, inutile contrapposizione "io povero utente, voi amministratori cattivi". Non rende giustizia della tua bravura, della tua preparazione, della tua intelligenza.
E sia ben chiaro che non ti sto blandendo. Lo penso davvero, anche se so, purtroppo, come io vengo considerato "dalle tue parti". --Sannita - L'admin (a piede) libero 01:08, 17 dic 2010 (CET)
Ti ringrazio per l'apprezzamento e ricambio (e lo sai che sono sincero nei tuoi riguardi e da lungo tempo). Purtroppo, presenti esclusi, penso che alcuni si siano dimenticati cosa sia la condizione di utente: troppi anni con tutte le funzioni di amministratore, le funzioni supplementari, lo sblocco delle pagine tecniche di servizio quando serve, gli accessi esclusivi, i canali di comunicazione riservati, collegarsi e non trovarsi bloccati "scusa era un IP dinamico", non vedersi rispondere "scusa parlo solo con un amministratore", e sopratutto non venire assaliti da un amministratore niubbo che non ha capito una regola che poi bisogna pure linkargli e spiegargli, sono cose per alcuni talmente del passato, da non ricordarsele. Alcuni admin (nessuno dei presenti eh) sono stati utenti solo pochi mesi, e adesso sono da anni a spiegare ad altri non solo come si devono comportare, ma anche come si devono sentire.
Per fortuna, sono sicuro che in questo caso, anche se ci sarà una maggioranza solo di utenti che motivatamente e graficamente con dettagli, citazioni, diff, esempi, manuali, note, codici, analisi puntuali, tabelle fianco a fianco, revisioni in tempo reale, citazioni da tre wikipedia straniere, ecc. vota a favore della nuova bozza, il fatto che alcuni amministratori sono stati inizialmente contrari, non impedirà che la bozza passi. Queste cose non succedono mai e ci vediamo qui tra qualche mese e sono sicuro che sarà così. Un utente da un certo numero di anni e con le ferite di mille battaglie perse come queste, ormai si fa una idea di come possono andare a finire certe cose e assume il "gioioso pessimismo" di chi costruisce un castello di carte: più è alto e complesso, prima cade. Si scrollano le spalle, come già fatto tante altre volte, e si passa serenamente a farne un altro, destinato alla stessa sorte, se troppo ambizioso. L'ironia (mai mirata alle persone, ma alle situazioni) su come si sono risolti molti di questi casi in passato, è oggettivamente l'unica cosa possibile. È ben poca cosa, permettetela. Saluti e grazie.
Comunque il quesito su quale template ->in questa sandbox<- funzioni meglio e perchè, direi che resta in piedi.--EH101{posta} 03:24, 17 dic 2010 (CET)
Certamente non sono esperto di template e di rapporti con gli amministratori ma mi dispiace vedere queste scaramucce che rischiano di rallentare il tutto.
Venenendo all'ultimo esempio (->in questa sandbox<-), da profano di classi (io conosco solo quelle scolastiche) e delle altre diavolerie dei template, direi che approvo la soluzione proposta da EH101. La approverei in forma più decisa se EH101 implementa la doppia dicitura delle suddivisioni amministrative per montagne sul confine (nell' esempio, regioni francesi e dipartimenti per la Francia e regioni e provincie per l'Italia sullo stile dei francesi fr:Mont Blanc). Franco56 - (se vuoi, rispondi) 07:49, 17 dic 2010 (CET)
Le schermaglie verbali sono parte della vita di Wikipedia e ne sono in qualche misura il sale. L'importante è avere sempre in mente che si dibatte e discute, anche animatamente, ma tutti siamo puntati al miglioramento del progetto. Questo, per "vecchi" frequentatori come me e altri intervenuti in questa pagina è un fatto scontato e poichè ci frequentiamo in queste pagine da tempo, talvolta d'accordo, talvolta in disaccordo, talvolta in sintonia, talvolta in contrasto, tutto rimane tra confini della discussione puntuale.
Tornando al "cantiere", questa è la sede dove protestare, borbottare, pungolare e ovviamente proporre modifiche varianti e funzioni. Questa della doppia (anche tripla o quadrupla ?) dicitura delle province non è difficile da fare. Prima però proviamo a progettarla insieme, viste le perplessità già espresse quando ci sono funzioni (facoltative) molto potenti, ma che possono essere viste come una complicazione. Se ben capisco, potremmo affiancare ai campi |Codice paese = |Codice paese2 = ecc. dei campi |Suddivisione su cui dobbiamo metterci d'accordo. I casi che vogliamo adesso approfondire sono quelli in cui ci sono 2, 3 o 4 paesi (4 ?):
Caso 1: di tutti e 4 i paesi, esiste preimpostata la struttura equivalente a regione, provincia, comune italiani (RPC nel seguito). Chi compila i template riempie fino a 6 campi nel caso di due paesi (3 x 2), 9 per tre paesi, 12 per il caso di quattro stati.
Caso 2: di nessuno dei paesi esiste la struttura RPC preimpostata da qualche parte in Wikipedia. Chi compila i campi, allora deve avere la possibilità di compilare, oltre ai 6,9,12 campi, altri 6,9,12 campi per i nomi come contee, stati federati, ecc. cioè la struttura RPC dei paesi. Se chi compila, non ha voglia o conosce la struttura esatta, deve apparire a default comunque regione, provincia, comune.
Caso 3: situazione intermedia tra 1 e 2.
Potenzialmente, abbiamo 12+12 campi. Nessun problema a farli, ma come li chiamiamo ? Io suggerisco poi, visto che la potenza può disorientare, di pensare subito a dividere nel manuale in due parti, come si fa in questo caso: la prima dal titolo "uso semplificato", con spiegazione e esempio semplice. Di seguito una versione "sintassi completa", con tutte le idee e potenzialità che vi vengono in mente. L'idea è che questa seconda parte sia dedicata a utenti più esperti e intenzionati a gestire i casi più complessi.
Sintesi: come chiamiamo i 24 campi (se servono) e va bene il manuale sdoppiato ?--EH101{posta} 11:07, 17 dic 2010 (CET)
A proposito, io sarei in grado di clonare facilmente la grafica del template francese di fr:Mont_Blanc, ma è "mostruosamente" lontano dalle classi supposte standard, mi sfugge ancora in base a quale divieto. L'esempio del Mont Blanc francese è un ottimo esempio di cosa vuol dire "classe": quelle "cose" che fanno venire le scritte, i colori e gli spazi tra le righe, così diverse tra un template e un altro. Le "classi" usate dal template francofono, sono diverse da quelle per alcuni da usare obbligatoriamente su it.wiki. Tecnicamente, passare dalle une alle altre è abbastanza facile, e potrei fare una terza colonna nella sandbox per dimostrarlo. Il consenso, però, è tutto da capire.--EH101{posta} 11:24, 17 dic 2010 (CET)
Non so se sia possibile non impazzire con tutti questi campi. Intanto escluderei che ci siano rilievi su quadruplici frontiere (vedien:quadripoint dalla quale ragionevolmente si esclude); secondo, è vero che la struttura RPC non è impostata per tutte le nazioni, ma ormai sono poche quelle che non c'è l'hanno e se si incontra una nazione che non c'è l'ha basta farla sul momento (l'altro giorno l'ho fatta par la Guinea Bissau {{DivAmm/GNB}}) per cui penso sia sufficiente quella direi automatica. Spero di essermi spiegato.Franco56 - (se vuoi, rispondi) 12:27, 17 dic 2010 (CET)
Chiarissimo. Allora escludiamo il caso quadripoint e ipotizziamo che ci siano sempre le strutture amministrative nazionali pronte. Io lascerei comunque il generico RPC pronto a scattare in caso di anomalia. Secondo me, dovremmo lasciare (magari tra le funzioni nel manuale esteso), la possibilità di modificare a mano il campo RPC per ogni evenienza, ma anche no. Invece possiamo definitavemente tagliare, se d'accordo, il numero di livelli amministrativi. Facciamo solo 3 ? Se decidiamo di incentivare all'uso di "br" nella stessa riga, allora bastano tre campi. Potremmo invece incentivare all'uso di campi diversi e allora sarebbero 9 massimo.--EH101{posta} 12:52, 17 dic 2010 (CET)
ok per il generico RPC. La possibilità di modificare a mano il campo RPC la toglierei (se sbagliato si va a correggere il template apposito). I livelli amministrativi sono sufficienti tre. Ok per l'uso del "br" (24 sarebbe stato un numero impossibile sia per il codice che per la compilazione - tre mi sembra ragionevole). Non mi resta che augurarti buon lavoro (perché con il codice del template non so proprio masticare nulla). Franco56 - (se vuoi, rispondi) 13:27, 17 dic 2010 (CET)
Rispetto alla cartina di localizzazione (e riprendendo un'osservazione di Gvf) forse sarebbe bello prevedere un campo nota in cui si può scrivere per esempio: localizzazione nella cartina della nazione xyz; localizzazione nella cartina delle Alpi: localizzazione nella cartina dell'Alaska (per riprendere alcuni esempi). Non so sia possibile magari automatizzare tale scritta (e questo sarebbe certamente meglio). Franco56 - (se vuoi, rispondi) 13:43, 17 dic 2010 (CET)

(torno a capo + conflittato)

  • Coordinate: dal tuo manuale e dall'esempio di template non vedo una funzionalità in più: vedo che hai sostituito due parametri che permettevano di inserire le coordinate decimali con 8 parametri per inserire le coordinate in gradi, minuti, secondi e punto cardinale. Mi sembra che sia una inutile complicazione del codice e del numero di parametri, non per niente i servizi web che mostrano mappe come google map usano le coordinate decimali. Attenzione la mia idea è usarle solo come parametro: la visualizzazione sarà fatta di default con gradi minuti e secondi (e possibilmente personalizzabile e selezionalibele per chi desiderasse il più compatto formato decimale).
  • Classi: le classi "standard" sono quelle presenti in common.css visualizzabile da tutti gli utenti e che dovrebbe essere facilmente interpretato da chi si ritiene in grado di scrivere template utilizzando le classi e sono tutte quelle che iniziano per "sinottico". Sono frutto di lunghe discussioni (purtroppo svoltesi principalmente in chat) con altri utenti alcuni anni fa. Non mi risulta esista una documentazione ufficiale relativa. Ti posso solo linkare una mia vecchia pagina di appunti: Utente:Gvf/Template sinottici con uso delle classi che in mancanza di meglio potrebbe essere migliorata e spostata in una posizione più "ufficiale".
  • Bandiere: Visto come la prendi ti tolgo il condizionale: devono esserci tutte. E se ti accorgi che una manca la aggiungi, non fai un test per vedere se c'è e se manca ignori il parametro: quello è un sistema per nascondere la spazzatura sotto il tappeto non per migliorare il progetto.
  • Divisioni amministrative: La struttura da te proposta non è assolutamente spiegata nel manuale del template e porta, a mio avviso, a un gran casino in quanto ogni utente farebbe di testa proprio usando le in maniera diversa. Visto che uno dei motivi per utilizzare i template è quello di cercare una certa standardizzazione stilistica sarebbe opportuno utilizzare soluzioni che la favoriscano al posta di quelle che tendenzialmente portano caos. Per le divisioni amministrative esistono i template {{DivAmm}} che le definiscono per un gran numero di stati. Se vogliamo migliorare il progetto quando ci si trova in una situazione in cui manca la definizione la si aggiunge in maniera che sia disponibile per tutti (con Divamm) e non in una singola voce (mettendola come parametro del template). Nel caso di oggetti multi-nazionali probabilmente non è il caso di avere 4 livelli amministrativi per ogni stato (in Italia si arriverebbe all'elenco delle frazioni comunali) Nel caso delle montagne a mio avviso sul template basterebbero i primi due livelli nella tabella sinottica citando i comuni nel testo della voce se questo sia di qualche rilevanza.
  • Coordinate fuori mappa: permette di cambiare la mappa ma non di controllare che le coordinate siano all'interno della stessa: vedo che non ti è mai capitato di trovare voci col puntino perso in mezzo al testo per un errore di chi le aveva inserite. A me si. Nel caso del vulcano del tuo esempio hai supplito ad una carenza della mappa degli Stati uniti (che non ricopre tutta l'estensione degli stessi) usando una mappa di un singola stato federale senza indicare quale esso sia. Mi sembra sia una soluzione adatta a chi le cose già le conosce e non a chi le ignora e si rivolge ad un enciclopedia per imparare.
  • Il nostro progetto si riferiva a Wikipedia in italiano.

Ribadisco sono assolutamente a favore dei miglioramenti, non gradisco però il tentativo di imporre delle scelte non condivise mascherandolo come introduzione di innovazioni (che poi tanto innovazioni non sono).

Visto che non lo hai voluto fare tu provo a sintetizzare io i miglioramenti da apportare al template:

  • Gestione delle divisioni amministrative corrette relative allo stato. Gestione delle stesse nel caso di più stati interessati (oggetti di grandi dimensioni possono interessare anche più di 4 stati per esempio i laghi)
  • Gestione degli oggetti fuori mappa e delle mappe fisiche (gestite per esempio dal template montagna).

Spero di aver chiarito la mia posizione e di poter proseguire la discussione senza vittimismi per trovare una soluzione condivisa.Gvf 14:00, 17 dic 2010 (CET)

@Gvf. Scusami, non condivido in nulla quanto dici. Non condivido il merito, il dettaglio, il modo di rivolgersi, il metodo usato per stabilire uno standard, la analisi. Nulla. È un problema ? Spero proprio di no. Non trovo ci sia modo di dialogare se ti spiego la questione delle coordinate e mi rispondi ... che hai sostituito due parametri che permettevano di inserire le coordinate decimali con 8 parametri per inserire le coordinate in gradi... . Le coordinate in gradi a 8 parametri ? Ma che è, l'iperspazio ? Posso andare avanti così per ogni linea di quanto mi hai scritto, ma ci deve essere un difetto di comunicazione del quale sono responsabile e comincio seriamente a preoccuparmi. Ricevere un apprezzamento come "non gradisco il tentativo di imporre delle scelte non condivise mascherandolo come introduzione di innovazioni", vuol dire aver cominciato a superare una soglia. A me sembra una accusa diretta e chiara di comportamento scorretto e di scorrettezza abbastanza grave: se do l'impressione di essere così scorretto, mi devo preoccupare seriamente. "Imporre" ? Ma cosa posso imporre io ? Ma chi sono ? Sto scrivendo pagine e pagine di spiegazioni, corro a togliere qualsiasi cosa solo lontanamento non piaccia e poi io "impongo" ? Ma che cosa esce da quello che scrivo ? Il contrario ? Essere redarguito in modo così diretto e grave, non è assolutamente igienico per me. Visto come la prendi ti tolgo il condizionale: Ecco, visto come la prendi tu, tu mi togli in condizionale e io mi tolgo proprio di torno, mi sa che è molto meglio per me. Visto che non lo hai voluto fare tu provo a sintetizzare io i miglioramenti da apportare al template:: è un altro rimprovero grave che mi viene mosso e quindi la mia preoccupazione per l'accusa aumenta di conseguenza. C'è una pagina di sintesi e analisi che ho scritto qui sopra, ma non serve a nulla. "non ho voluto": ecco il mio problema, non quello che faccio, ma le mie intenzioni. Siamo in presenza di un giudizio alle intenzioni, una valutazione complessiva di una utenza e un amministratore può far scattare azioni successive se continuano le azioni, direttamente e senza altre consultazioni: è il regolamento. Ho ricevuto la spiegazione dello standard deciso in IRC e ho ancora i brividi.
Arrivederci. Io un guaio per un template non lo voglio passare. La sandbox è lì, qui sopra ci sono pagine di analisi, chi vuole continuare continui. Auguri, mi tolgo di torno, cosa che avrei dovuto fare da subito. Ma scherziamo ? Ci sono utenti che hanno passato guai grossi per molto meno. --EH101{posta} 22:31, 17 dic 2010 (CET)
Giusto per capire... la mia opinione ha qualche peso o qualcuno ritiene che sono passato a scrivere le mie perplessità perché non avevo di meglio da fare in Ns0? Per quel che mi riguarda, da profano, le proposte di EH101 mi sembrano, anzi sono graficamente migliori delle attuali e questo mi sembra un fatto contestabile fin che si vuole ma che in questo contesto si sia consci che io la penso così. Se poi si ritiene che una innovazione non sia da considerare perché, questo leggo, da sempre ci sono queste regole e queste rimangono mah... permettetemi di esprimere anche qui dei dubbi e non vorrei che il problema non siano i cambiamenti ma chi li propone. Trovo sinceramente eccessiva la rigidità di Gvf che, pur essendo amministratore, non ha più diritti a preservare uno schema di quanto non ne abbia chiunque, e chiunque ha ragione di proporre dei miglioramenti per WP. Io mi trovo meglio a considerare le coordinate geografiche per gradi, primi e secondi, sono in errore? Io vedo un concreto miglioramento alla grafica dell'esempio portato in sandbox, mi sbaglio? Evidentemente, da profano, non posso comprendere le ragioni che impongono di fatto uno standard ma mi piacerebbe poter capire invece che leggere che "non si fa così ma si fa colà, punto!", magari alla fine mi convincete :-)--Threecharlie (msg) 23:03, 17 dic 2010 (CET)

@EH101: Il fatto che tu non sia d'accordo con le mie idee relativamente a questo template mi è chiaro, mi era già chiaro. Sul fatto di dialogare non mi sembra che i tui interventi siano un esempio da seguire: alle mie osservazioni hai risposto con una serie di "quote" indicando le mie spiegazioni come una volontà di rifiutare il tuo lavoro e l'"innovazione" che esso portava. Mi sembrava di essere stato abbastanza esplicito sull'indicare che ci sono ampi margini di miglioramento sull'attuale template ma che a mio avviso la strada da te proposta non andava bene. Le tue ampie spiegazioni non le vedo sul manuale del template che proponi che lascia l'utenza senza una guida precisa proprio sul punto in cui la nuova versione dovrebbe principalmente "innovare". Relativamente allo sfotto sulle coordinate iperspaziali ti faccio uno schemino che forse ti sarà più chiaro:

Attuale template:

|latitudine_d = 
|longitudine_d = 

Template da te proposto:

|LatGradi = 
|LatPrimi = 
|LatSecondi = 
|LatNS = 
|LongGradi = 
|LongPrimi = 
|LongSecondi = 
|LongEW = 

Ti è chiara ora la differenza sul numero di parametri utilizzati per inserire gli stessi dati?

Relativamente alle discussioni (non decisioni) fatte in IRC che tanto ti fanno rabbrividire ti sconvolgerò ancora di più: pensa che in altri casi si è discusso anche di persona ai raduni e non abbiamo fatto neppure il verbale relativo! Cose che capitano. Se le discussioni fossero fatte sparpagliate nelle pagine di discussione in giro per wikipedia sarebbero parimenti irreperibili. E spesso non possono essere nelle pagine di un progetto per il semplice fatto di essere antecedenti alla creazione del progetto. Mi dispiace ma in questo caso devi fidarti della parola di chi te le riporta, in futuro vedremo di migliorare.

Mi dispiace che il mio tentativo di indicare quelli che secondo me sono degli errori da evitare venga tacciato come una strenua difesa dell'esistente grazie a miei ipotetici "poteri di amministratore": trova un solo caso in cui possa essere accusato di un comportamento simile e ti garantisco le mie dimissioni immediate. Così almeno potrò esprimere le mie opinioni senza essere accusato di intimidire il mio interlocutore.

@Threecharlie: Mi risulta che uno dei pilastri di wikipedia sia che le opinioni di chiunque valgono nella stessa maniera. Permettimi di esprimere anche le mie: differenze grafiche fra le due versioni quali sarebbero? Di base usano entrambe le classi sinottico con l'aggiunta nel caso di quello in sandbox di un po' di stili in-line che sarebbero da evitare per quanto detto sopra (se migliorative le modifiche andrebbero applicate alla classe non ad un singolo template). Relativamente alle coordinate: mi sembra di aver già spiegato il motivo per cui ci sono dei vantaggi ad usare le coordinate decimali fermo restando che la visualizzazione resta "tradizionale". Ma lo ripeto: l'uso delle coordinate in gradi, minuti e secondi come parametri in un template richiede: un numero molto superiore di parametri, rende molto più complessi alcuni altrimenti semplici controlli, appesantisce notevolmente il codice del template (ancor di più nei casi in cui si sono utilizzati entrambi i formati. Quando si inseriscono i dati fare la conversione richiede un attimo (volendo c'è addirittura un template da substare per farlo) e mi sembra sia una fatica che vale la pena fare visti i vantaggi che da. Questa è la mia opinione, e ha delle motivazioni più volte ribadite. Mi piacerebbe che la scelta opposta fosse anch'essa motivata. Riguarda alla mia "rigidità" immagino riguardi il fatto che nei miei interventi precedenti ho ribadito le miei idee cercando di spiegarle e di portare motivazioni a loro favore, ribadendole quando non ne è stata portata contro nessuna. Beh se si riferisce a questo non so cosa farci: sarò ormai vecchio, ma per farmi cambiare idea devi convincermi che la nuova è migliore portando argomenti a favore, non facendo la vittima. Relativamente agli standard l'unico motivo per cercare di adottarli è appunto cercare di standardizzare qualcosa: in genere per cercare di avere una certa uniformità in voci scritte da un infinità di persone. E non sono immutabili, ma vanno discussi e cambiati non aggirati altrimenti torniamo indietro anziché andare avanti. Nel caso dello standard qui citato ovvero l'uso delle classi sui template sinottici è qualcosa che è partito parecchi anni fa da un gruppo di utenti per cercare di rendere un po' più omogenei i template sinottici cercando al tempo stesso di avere un'altro risultato positivo ovvero separare (un po') la formattazione del testo dal testo stesso come sarebbe buona norma. Hanno inoltre il vantaggio di permettere una volta che vengano adottate in maniera estesa di personalizzare l'aspetto intervenendo sugli accessori o sul proprio file .css (monobook, vector o altro a seconda delle scelte).

@all: Relativamente alle mappe alternative vorrei evidenziare che l'attuale template visualizza già la mappa della catena montuosa se questa è stata inserita nelle mappe di localizzazione disponibili usando {{Montagna/MappeCatene}} che attualmente contiene solo il riferimento alle Alpi.

Per quanto riguarda le divisioni amministrative ho dato un occhiata ad un campione di una cinquantina di montagne e vedo una discreta difficoltà ad indicare in maniera chiara vari livelli amministrativi. Anche in un caso abbastanza semplice di un monte a cavallo fra due paesi ci troviamo con almeno sei righe di divisioni amministrative che mi sembra facciano facilmente confusione più che informare. Non parliamo poi di casi più complessi. Come le organizzereste?

Gvf 01:04, 18 dic 2010 (CET)

Ancora ? Ma non è questo che hai ingiunto prima ! Ho già detto che me ne vado, dopo che mi hai tolto i condizionali, processata la volontà, accusato di scorrettezza e tacciato di fare un tentativo di imporre delle scelte non condivise mascherandolo come introduzione di innovazioni. Io mi impongo ? Me le hai dette di tutti i colori e adesso vuoi anche l'ultima parola con una domanda "come le organizzereste ?". Pure lo schemino poi. Io non capisco: vedo una continua oscillazione tra tutto e il contrario di tutto, salvo poi finire "non c'è innovazione". Quando c'è da controllare se c'è una bandierina, no, non va controllata. Se si sbagliano le coordinate, sì, vanno controllate. Se bisogna mettere una cartina fisica, no, perchè non si vedono i confini, ma le Alpi fisiche sì, perchè c'è la funzione nel template attuale (solo per le Alpi). Quando c'è da analizzare il codice, vengono fatti studi di dettaglio sulle classi. Se c'è da indicare una disfunzione, allora viene riportato il manuale in bozza. Il template nasce con l'intento di utilizzare "anche" gradi primi e secondi, non solo è così e si vede dal codice per la mappa di localizzazione, ma l'ho anche scritto e spiegato chiaramente . Eppure la risposta diretta che ho datoqui a inizio della mia replica di quel giorno è chiara e esplicita. Niente. Non serve a niente.
Se vuoi un caso di "strenua difesa dell'esistente grazie a ipotetici "poteri di amministratore"" rileggitiil tuo penultimo post e vedi un po' se è modo di rivolgersi ad un interlocutore semplice utente, accusandolo di ogni cosa, non ascoltando quanto ha da dire, valutandolo in quel modo e poi avendo la possibilità di scegliere se cliccare su "salva il testo" o "blocca l'utente" a fine intervento. Ma lo sai quanti vengono bloccati, salvo poi "beh forse X è stato un po' troppo frettoloso" ? Sai che consolazione per chi viene bloccato, stabilire che il bloccatore se la era presa un "po' troppo" ? Ricevere una serie di accuse come quelle, non è mica igienico per nessuno, sai ? Vai nella talk di un amministratore o al bar, usa quel tono per parlare con un amministratore, non firmarti, blocca le attività di un qualcosa e fammi sapere quanto duri.
Ho detto che me ne vado. Non posso continuare a ricevere accuse così da un amministratore, perchè non posso difendermi. Lasciami almeno l'ultima parola e non insistere. Hai vinto e sbaragliato il campo. Gli standard sui template decisi su IRC e adesso sappiamo nei raduni (sempre meglio) non sono in grado di gestirli, anzi devo pure fare una fatica tremenda a cercarli, visto che neanche mi vengono detti quando li chiedo. La sandbox resta lì (finchè qualcuno con il tasto cancella non ci penserà) e continui qualcun qualcun altro che non vuole fare il tentativo di imporre delle scelte non condivise mascherandolo come introduzione di innovazioni. Visto che impongo e mi maschero, getto la maschera: mi sono spaventato abbastanza e me ne vado, se non mi continuano a tirare in ballo. Fammene andare e stop. Ognuno per la sua strada. Vittoria completa, per abbandono. --EH101{posta}14:12, 18 dic 2010 (CET)

Vedendoli a fianco in effetti miglioramenti grafici non vedo nemmeno io. Comunque, se non piacciono le classi di it.wiki, si proponga di modificare quelle, poco importa come sono nate; l'importante è avere uno standard.
Riguardo alle coordinate, non potremmo supportare entrambi i metodi? D'altronde anche Template:Coord funziona così. Poi scusate ma io ho perso il filo, se qualcuno sa ricapitolare le altre modifiche proposte... --Bultro (m) 17:33, 18 dic 2010 (CET)

Provo a sintetizzare le modifiche proposte:

  • miglioramento delle cartine di localizzazione (per esempio le montagne dell'Alaska attualmente non sono localizzate sulla cartina degli USA- quando si ha una montagna sul confine viene scelta ad arbitrio una delle due cartine di localizzazione delle rispettive nazioni)
  • indicazione delle suddivisioni amministrative (nasce la complicazione quando la montagna si trova sul confine tra due o più nazioni)
  • indicazione di altri parametri tipo la prominenza topografica, l'isolamento topografico e la vetta principale.
  • forse altre dimenticate. Franco56 - (se vuoi, rispondi) 21:36, 18 dic 2010 (CET)
Sintetizzo anch'io quanto già detto
  • Per le suddivisioni amministrative il problema è decidere come organizzare la visualizzazione in maniera che non faccia una gran confusione quando ci sono più paesi e livelli di divisione.
  • Per le cartine c'è da considerare che se si usa una cartina diversa da quella del paese indicato è necessario indicarlo in qualche maniera (possibilmente in automatico) o forse scriverlo sempre.
  • per aggiungere altri parametri basta decidere cosa mettere e dove.
Aggiungo
  • forse sarebbe il caso di divedere i dati in sezioni
  • mappa di localizzazione e mappa di localizzazione con test sembrano avere dei problemi con le mappe a cavallo dei 180 gradi
  • le soluzioni da adottare dovrebbero andare bene in tutti i template geografici interessati (per esempio {{infobox Lago}} e {{infobox fiume}}
  • sarebbe interessante rendere omogenei i nomi dei parametri fra i template simili (p.e.: codice_paese nazione e stato in template diversi stesso significato)
@Bultro: si, si possono supportare entrambi i sistemi al costo di incasinare in maniera incredibile il codice: gran parte del caos del codice delle mappe di localizzazione (e a occhio di un bug) è per la conversione fra i sistemi di coordinate. Questo pregiudica leggibilità e manutenibilità del codice per dare una funzionalità a mio avviso marginale. Personalmente propenderei per avere il supporto delle sole coordinate decimali facendo le conversioni per la sola visualizzazione ed eventualmente al momento dell'inserimento con l'apposito template.Gvf 23:49, 20 dic 2010 (CET)
Ho dato un occhiata in giro per i vari progetto maggiori per vedere come trattano le divisioni amministrative. Per confronto ho guardato le voci di Everest e monte bianco. Solo en.wiki e fr.wiki oltre a noi mettono qualcosa sulle suddivisioni amministrative e in nessun caso mi sembra chge venga fuori una cosa chiara. Ne l'approccio di en.wiki che mette tutto di seguito al paese (e come si fa in caso di più soddivisioni di basso livello) ne quello francese che mette assieme tutte le label e le suddivisioni livello per livello (per capire a cosa si riferiscono bisogna vedere a cosa linkano. Bisognerebbe ideare qualcosa di meglio. Gvf 23:03, 21 dic 2010 (CET)
Leggibilità e manutenibilità non mi sembrano un problema visto che il Coord fa già tutto lui, basta rimbalzargli pari pari i parametri.
Riguardo alle divisioni amministrative seguirei questo ordine:
  • Stato
  • Regioni
  • Province
  • Stato2
  • Regioni2
  • Province2
Aggiungo che i francesi hanno dei parametri sui dati geologici che non sarebbero male --Bultro (m) 17:05, 23 dic 2010 (CET)
Anche Mappa di localizzazione fa tutto lui e proprio per il voler gestire entrambi i sistemi il codice è incasinato e buggato. Ho provato ad inserire una mappa dell'oceano pacifico (quindi a cavallo dei 180 gradi) e le coordinate decimali non vengono gestite correttamente.Gvf 22:26, 23 dic 2010 (CET)
PS inoltre bisogna raddoppiare i test per vedere se i parametri sono inseriti.

Valpolicella

Vi segnalo che è stato aperto un nuovo vaglio, vi invitiamo a partecipare. LoScaligero 17:46, 20 dic 2010 (CET)

Questa voce ha dei problemi. Potete verificare e risolvere. Grazie in anticipo. --Aleksander Sestak(msg) 19:10, 27 dic 2010 (CET)

Nelle coordinate bisogna usare il punto per i decimali, per motivi tecnici --Bultro (m) 19:48, 27 dic 2010 (CET)

Segnalo la mancanza della voce riferita a questa importante geografa. --79.27.43.19 (msg) 13:21, 28 dic 2010 (CET)