Wikisource:Bar/Archivio/2009.09

Indice
Fine pagina

Strategic planning / pianificazione strategica

Non so se abbiate letto del processo di pianificazione strategica che vuole produrre dei suggerimenti per i prossimi cinque anni di sviluppo del movimento Wikimedia. Il tutto parte colle proposte della comunità, che saranno raccolte fino a fine mese. Purtroppo non ci sono molte proposte per Wikisource, che se le meriterebbe eccome! Ho provato ad alzare un po' l'asticella, per usare un eufemismo (a proposito di ambizione): mi piacerebbe che partecipaste anche voi (magari con altre proposte piú semplici, anche :-D): Make Wikisource scale. --Nemo 04:02, 3 set 2009 (CEST)

Usiamo questo spazio per elencare i nostri contributi! Il mio è stato un tantinello audace e generale. Rivoluzionare il markup wiki, rendendolo "well formed" secondo i principi dell'xml ossia: fare in modo che ogni tag di apertura di qualcosa sia collegato chiaramente e univocamente a un tag di chiusura, semplificando la vita ai poverelli che devono cercare di metterci mano con script vari. Esempio: ODIO i due tag ''' e '' per il grassetto e il corsivo, perchè non sono "well formed" e chi ha provato a scrivere un programma per trasformare gli apostrofi dattilografici in tipografici lo sa bene. L'inclusione di pezzi di testo dentro i template, cosa che viola il "principio di separazione" fra testo e formattazione, è un esempio più sottile ma in sostanza ugualmente dannoso. To_build_a_well_formed_wiki_markup_language--Alex brollo (disc.) 09:08, 3 set 2009 (CEST)

Novità per i bottolatori

Cominciano i "ritorni" dal mio viaggio in ekopedia. Funziona un propotipo di script molto semplice, che espande e rende disponibile a chiunque abbia pywikipedia di accedere alla funzione "bot interattivo". Ne parlo in dettaglio nel BarBot. Ripeto: MOLTO semplice, non le cose che facevo "prima". :-) --Alex brollo (disc.) 09:12, 3 set 2009 (CEST)

Complimenti!

Signore e signori, siamo proprio un bel gruppo! (Ogni giorno, mi diverto tantissimo...) Andiamo avanti così! :D --Xavier121 23:16, 10 set 2009 (CEST)

:-D Torredibabele (disc.) 11:42, 12 set 2009 (CEST)

Boldaggine: ai limiti "dei seminati"

Sto facendo un audace e iconoclastico esperimento nel cuore del meccanismo del SAL.

Voi sapete che la gestione del SAL è la parte più complessa del software "aggiuntivo" di it.source, il suo fiore all'occhiello. Oltre alla comparsa del simbolino nella pagina dove il SAL è registrato, lo stesso simbolino appare nella pagina di discussione, e fin qui basta javascript, ma anche accanto al link a una pagina testuale, se questa viene richiamata da Template:Testo, e questo richiede AJAX, e un complesso ed esotericissimo scambio di informazioni con il server. Alla portata, suppongo, di due o tre dei sourciani attivi, per capirlo fino in fondo. L'idea era di far comparire il simbolino anche accanto al link [pagina] delle transclusioni, ma questa cosa è rimasta un'incompiuta.

Bene, ho ricostruito tutto (comprese due modifiche di Template:Testo e Template:Pagina) in modo che lo stesso risultato, cambiando ovviamente il "segnale del SAL" nella pagina relativa, sia perfettamente funzionante senza javascript e senza AJAX, indovinerete con che strumento: con la mia amatissima transclusione selettiva. Il codice è estremamente semplice (si fa per dire: per chi di destreggia nei template e nella transclusione selettiva), la cosa è straordinariamente lineare. E anche vicino al link [pagina] dei testi transclusi compare il famoso simbolino.

Ora, io immagino che una tale rivoluzione richieda settimane, forse mesi di riflessione e di test prima di cominciare a ipotizzare di applicarla, però vi chiedo uno sforzo, quello di analizzarla criticamente e di commentarla. Nota: poichè il meccanismo è completamente diverso da quello attualmente applicato, è perfettamente compatibile con il precedente: le due cose possono tranquillamente convivere, ma occorre "sincronizzare" i due segnali e la convivenza ha senso solo in una fase di test. Ovviamente i radio button NON gestiscono il nuovo segnale, che va apposto e aggiornato, per le prove, a mano.

A questo punto, fra crosslink e derivati e questa ultima cosa, penso che sia meglio che mi prenda una pausa dalla creatività e mi dedichi a Zibaldone, il cui volume V (oltre al II, II, e IV) è quasi pronto per la rilettura. :-) --Alex brollo (disc.) 16:22, 13 set 2009 (CEST)

Mi correggo: Ziba V è pronto per la rilettura. festeggio aggiungendo un tassello a quanto detto sopra: riguarda la questione argomenti (Aubrey quando ci sei batti un colpo). Disporre del dato "qualità" liberamente utilizzabile dovunque implica la possibilità di estrarre l'argomento dal tl qualità: un ipotetico Template:Argomento può benissimo accedere al dato e generare le giuste categorie, stando dovunque. Visto che sono in periodo creativo, scriverò questo template per prova, e ci aggiungerò una chicca: il fatto di gestire uno o più argomenti pur ricevendo un unico parametro. Restituirà, per ciascuno degli argomenti, le categorie SAL corrispondenti con l'incrocio argomento + SAL. Attendo feedback dai più coraggiosi di voi... --Alex brollo (disc.) 08:16, 14 set 2009 (CEST)

Implementato e montato per prova sulla povera pagina {{Testo/Sandbox|Pagina:Fiaschi.djvu/1}} che sta facendo da cavia. Che dire? Funziona. E non è stato nemmeno difficile, come vedete dal tempo trascorso dal precedente edit ad adesso... :-) --Alex brollo (disc.) 08:35, 14 set 2009 (CEST)

Batto il proverbiale colpo. L'idea del template con plurimi argomenti mi piace, mi sembra che funzioni e sia abbastanza semplice. L'unica cosa che cambierei sarebbe mettere "|" al posto degli "/", per un discorso di omogeneità con tutti gli altri template. In questo modo, fra l'altro, ci avviciniamo ad una categorizzazione a tag, e per gli argomenti potrebbe andare bene (in teoria c'è una estensione apposita che lascia applicare le tag alle pagine, ma lì la questione si fa più seria).

Per quel che riguarda il SAL, tentiamo. Se il risultato è buono non vedo perchè cambiare sistema (anche se bisogna capire quanto la migrazione da un sistema all'altro sia dolorosa...). Spero di essere stato utile ;-) Aubrey McFato 11:38, 14 set 2009 (CEST)

Stavo pensando ad una cosa. Adesso come adesso, il template Qualità ha dentro il discorso anche dell'argomento, e struttura tutto in categorie incrociate fra le due, create ad hoc. Come si è capito da tempo, questa situazione a me non piace, non la trovo giusta teoricamente. Delle due l'una: o stacchiamo le due cose, lavorando su un template argomento e uno qualità, e li uniamo in una maniera che generi una struttura più efficace. Potremmo creare delle richieste a delle categorie (Testi di entomologia al 75%) oppure cerchiamo scappatoie che Alex aveva a suo tempo già esplorato. Comunque dobbiamo prendere una decisione. Aubrey McFato 12:01, 14 set 2009 (CEST)

Grazie Aubrey. Nota tecnica: non possiamo usare il carattere | per il trucco di passare valori multipli in un unico parametro, perchè tale segno separa appunto i parametri; inoltre, il giochetto ricorre alle caratteristiche ti #titleparts, che riconosce come separatore il solo carattere /. Nasce infatti - come dice il suo nome - per segmentare i titoli in parti. In generale: la questione Argomenti mi sta molto a cuore, ma è un piccolo particolare della questione SAL complessiva. Le conseguenze della mia proposta - se resisterà all'analisi critica impietosa - sono enormi, simili a quelle della precedente "rivoluzione del SAL" avvenuta poco prima che arrivassi qui. Io non la spingo affatto: mi basta sapere che, se servirà, esiste un'alternativa. --Alex brollo (disc.) 13:17, 14 set 2009 (CEST)

Update da ThomasV

Thomasv mi ha comunicato che sulla prossima versione del software wiki ci sono novità, fra cui un nuovo metodo di registrazione della qualità " similar but better :-) " a quello che ho sperimentato. Fine esperimenti, anvanti con Ziba. :-) --Alex brollo (disc.) 14:26, 16 set 2009 (CEST)

Progetto Diritto: discussione

A chi ne capisce qualcosa, segnalo che nel bar del progetto Diritto c'è una discussione aperta sulla sostituzione del vecchio template Diritto con il (relativamente) nuovo Template:Intestazione diritto, su oltre 500 pagine. Non è questione facile. Si tratta di dare delle buone "dritte" al mio bot, poi il lavoraccio "manuale" lo farà lui. Quindi.. c'è solo bisogno di un lavoro "di concetto" da parte di utenti per cui il diritto non sia arabo. --Alex brollo (disc.) 16:19, 15 set 2009 (CEST)

Google e i libri on demand

La novità del giorno è l'uscita alla grande di Google nel settore dei libri on demand. Repubblica Qualche riflessione?--Mizar (ζ Ursae Maioris) (disc.) 20:24, 18 set 2009 (CEST)

Sarei proprio curioso di vedere come l'"Espresso Book Machine", a partire da un file (.djvu o .jpg, sia in grado di stampare e rilegare un libro in formato tascabile, con tanto di copertina a colori, "nel tempo necessario a preparare un caffè espresso. M'interrogo soprattutto sulla qualità. Esiste al mondo un programma capace di fare quello che facciamo noi amanuenasi digitali? Le trascrizioni di google sono di bassissima qualità, le rarità caricate su altri progetti non è che siano tantissime, mi chiedo chi, in mezzo alla fascia di mercato (popolare, vasto di cultura medio-bassa), possa scaricarsi i commentari in latino ecclesiastico di aristotele! Me li vedo già al Melbook store di Termini a Roma questi lettori dal sapere totale che si mettono a cercare titoli di 5-6-7 secoli fa. :D --Xavier121 11:03, 19 set 2009 (CEST)

IMHO l'intento principale dell'operazione non sono gli attuali libri antichi, la cui resa cartacea è sicuramente di qualità inferiore alle richieste di chi li cerca, quanto piuttosto in un prossimo futuro quelle pubblicazioni o parziali o con licenza libera che si affideranno a Google per una pubblicizzazione e diffusione globale e capillare allo stesso tempo. Mi chiedo il prezzo da pagare in cambio di questa operazione (presenza di spot pubblicitari Adsense all'interno dei libri stampati sarebbe il minimo). Credo che l'offerta di Wikisource abbia ancora una sua buona ragion d'essere.

Tra l'altro anche questa notizia merita attenzione. -εΔω 12:03, 19 set 2009 (CEST)

A mio avviso, proprio perchè nella nostra piccola nicchia potremmo fornire un servizio qualitativamente migliore di quello fornito dal gigante Google potremmo studiare forme e modi--Mizar (ζ Ursae Maioris) (disc.) 14:40, 19 set 2009 (CEST)

Prematuro e non di nostra stretta competenza. Dovrebbe nascere un progetto wikimedia che sviluppi un programma per la pubblicazione dei testi di books, source e pedia. Per source dovrebbero esistere dei parametri che rispettino carettere tipografico, impaginazione, fregi ecc. dei formati originali. Qualcosa è nato ma è ancora molto lontano da un risultato soddisfacente. --Xavier121 14:51, 19 set 2009 (CEST)

A dire il vero io qui ci lavoro per divertimento. Un po' faticoso come divertimento, ma sempre meglio della Settimana Enigmistica. Si affaccia una generazione di "anziani digitali": chissà se fra poco proprio in questo immenso patrimonio umano non si possa trovare qualcuno che si diverta come me. Se tutto va bene (ossia: se ci arrivo), mi offro come cavia...

Il massimo che Google potrà fare sono immagini digitalizzate e scannerizzazioni utilizzabili soprattutto a fine di ricerca di parole chiave. Hai voglia prima che i programmi di scannerizzazione producano testi decenti. Quello che mi preoccupa un po' - da ambientalista latouchiano e pessimista - è se la società del futuro, la società sostenibile di cui non c'è ancora alcuna avvisaglia e che nessuno si sogna di progettare, avrà la complessità sufficiente per essere ancora digitale. --Alex brollo (disc.) 19:00, 19 set 2009 (CEST)

Gurgle! (cit. da Topolino) Che ci fa un povero, misero, miserrimo capostazione come me in mezzo a cotanto senno?--Silvio Gallio (disc.) 21:38, 19 set 2009 (CEST)

@XavierWikimedia non è poi così lontana da poter avanzare una proposta comune. In Germania, se non sbaglio, c'erano stati tentativi abbastanza avanzati, che potremmo qui riprendere. P.S. Un settore, poi, in cui potremmo fare qualcosa all'avanguardia è proprio quello segnalato dal nostro capostazione: I testi dell'ottocento sulle costruzioni ferroviarie potrebbero coesistere con la raccolta delle voci di wikipedia sui mezzi di trazione che ha una ricchezza non seconda a nessuna opera già edita.--Mizar (ζ Ursae Maioris) (disc.) 15:04, 20 set 2009 (CEST)

Dopo aver precisato che io sono capostazione senza virgolette (mi guadagno la bistecca in questo stanzone [1]), pongo una domanda. Qualche mese fa, in questo bar, si è verificato un certo scambio di opinioni sull'opportunità di inserire una bibliografia -il più completa possibile- nelle pagine autore, quale "servizio" per gli utenti esterni. Le risposte -negative- erano basate sul concetto similitudinico "mettiamo solo le schede di quello che abbiamo perché siamo una biblioteca". Adesso vogliamo diventare una casa editrice? Oppure serpeggia una certa tendenza a una leggera forma di schizofrenia? Salut!--Silvio Gallio (disc.) 14:41, 22 set 2009 (CEST)

Quando non sei niente, puoi essere tutto! :D --Xavier121 15:06, 22 set 2009 (CEST)

<rientro> Silvio Gallio, con una simpatica battuta, vede una leggera forma di schizofrenia nel fatto di proporre a noi che siamo una biblioteca digitale compiti che sono tipici di una casa editrice.
Spendo i miei due centesimi sull'argomento.
Prima era chiaro che c'era:
1) un luogo dove erano conservati i libri che si chiamava biblioteca, 2) un luogo dove i libri erano venduti, che si chiamava libreria 3) un luogo dove si stampavano i libri che si chiamava tipografia
Trasportati nel mondo virtuale i tre luoghi possono rimanere rigidamente separati o avere alcune commistioni. Qui si dice che Google Books partita come biblioteca digitale, e che, come ci ha ricordato Edo sta assorbendo persino la più orgogliosa iniziativa alternativa, quella nata intorno alla Biblioteca Nazionale di Parigi, ha scombussolato tutte le regole del gioco buttandosi sulla stampa on demand. Non necessariamente dobbiamo seguirne l'esempio, ma al bar insieme con l'aperitivo, mi sembra lecito discuterne liberamente.--Mizar (ζ Ursae Maioris) (disc.) 08:15, 23 set 2009 (CEST)

Giusto per non essere S-compreso; a me va benissimo la contaminazione. Altri preferiscono l'algida distanza. Epperò una regola o una visione dell'identità dovrebbero essere decise e valide molto sempre. O la torre d'avorio ('presente "Un cantico per Leibowitz"?) oppure il servizio pubblico. Certo che lasciarsi contaminare è pericoloso. Potrebbero nascere nuove idee! Salut!--Silvio Gallio (disc.) 22:02, 23 set 2009 (CEST)

Ho anch'io il dubbio che chiudersi in un concetto di biblioteca digitale che non corrisponde più al comune sentire del concetto di biblioteca digitale presenti più pericoli che vantaggi. Certo, ogni contaminazione è rischiosa, ma a mio avviso, la novità del nostro discorso sta nell'introdurre il concetto di copyleft, congiunto con un certo rigore sul prodotto libro. Per il resto, credo, che se il mondo sta cambiando a velocità folle, anche noi dobbiamo imparare a vivere con le nostre idee, ma dentro il cambiamento. e, sempre a mio avviso, la mossa di Google Books e della sua ormai alleata Biblioteca nazionale di Parigi, spazza di colpo tutto il vecchio modo di pensare alle biblioteche digitali. Un possibile scenario futuro vede un monopolista sia sia per i testi di Pubblico dominio che su quelli sotto copyright e, sempre a mio avviso non è la risposta migliore il chiudersi in torri d'avorio--Mizar (ζ Ursae Maioris) (disc.) 07:50, 24 set 2009 (CEST)

Allora credo proprio sia il caso di interrogarsi su cosa sia una biblioteca digitale. Se il comune sentire si identifica con le scelte commerciali di Google, siamo lontani dal mio sentire che invece crede nel prodotto infinito. Io miro al libro globale, alla celebrazione dell'ipertestualità di Aubrey, alla cultura totale, fruibile da qualsiasi angolo della terra con un semplice click. Dove starebbe la novità del prodotto libro? Sembra tanto l'esaltazione della vettura veloccissima e prestante con centinaia di cavalli sotto il cofano: ma sempre di un motore a scoppio parliamo, inventato secoli fa. Muoversi nella produzione di un oggetto non è inconcepibile a priori, ma non credo che la filosofia del monopolio Google del libro on demand riguardi la nostra biblioteca. Personalmente potrei essere interessato alla riproduzione di un libro del '500, ma non alla mercificazione seriale di un qualsiasi testo. Cerchiamo poi di capire quali esigenze sono da soddisfare. Noi ci occupiamo principalmente di testi antichi, che potrebbero avere un mercato ben definito di richiesta on demand, forse la letteratura antologizzata, la giurisprudenza e la matematica guadagnerebbero qualcosa da un prodotto finito, con prezzi contenuti, ma sembra già possibile realizzare questi lavori; forse si potrebbe pubblicizzare di più la cosa, perfezionando il rimando diretto alla stamperia di wikimedia (con un'icona sul frontespizio). Qualcuno si potrebbe occupare del confezionamento (layout) di questi testi già presenti, con un progetto dedicato (un po' più visibile) per esempio: stampa la Costituzione Italiana, stampa i Promessi sposi, stampa l'Eneide e così via (già le tesi, formalmente studiate nell'impaginazione, potrebbero figuare ai primi posti di questo elenco ecc.) Nessuna torre d'avorio, ma il nostro progetto è molto più ambizioso di quello di Google... semplice riflessione: chi investe miliardi in un prodotto finito non si mette a perfezionare uno strumento virtuale come l'ipertestualità, la trascrizione totale, si farebbe concorrenza da solo... o forse stanno già pensando all'e-book by Google? --Xavier121 11:14, 24 set 2009 (CEST)

Arrivo un po' tardi, ma ho letto con interesse.

La questione è davvero attuale, Google si sta muovendo con tutto il suo peso, io ho anche provato (con scarso successo) a scriverci qualcosa sopra... Il progetto Google Books, per ora ci piace assai, in quanto Wikisourciani. Come ben sappiamo, le loro trascrizioni fanno schifo, si sono comprati http://reCAPTCHA.net ma non gli basterà, hanno bisogno di human computing (cioè occhi e dita umane) e chissà dove lo andranno a prendere. Credo che in ogni caso, per il nostro campo, quello dei libri PD, ogni innovazione, da parte loro o di IA o anche Microsoft, ci farà del bene.

E' vero, noi siamo una biblioteca digitale, ma non solo: più studio e più mi rendo conto che noi siamo diversi, inclassificabili, mutanti nell'arco di un paio di mesi. Con i pro e i contro del caso.

Il fatto è che noi non sappiamo cosa siamo, e forse mai lo sapremo, e va bene così.

Wikisource è quello che noi vogliamo che sia.

@Mizar Io non ho nulla contro i libri on-demand, mi farebbe molto molto piacere la gente li prendesse da noi... Ma qualcuno ci dovrebbe stare dietro. I libri andrebbero correttamente formattati, andrebbero creati i pdf e andrebbero pubblicizzati.

Se uno tiene ad un progetto ci sta dietro, altrimenti sono un po' parole al vento. E lo dice uno che da Wikisource è praticamente assente da un paio di mesi. (scusate ragazzi, ma le BD occupano 8 ore della mia giornate, ho anche voglia di pensare ad altro ;-)

@Silvio Se ti interessano ancora le bibliografie, hai la mia personalissima benedizione. Ancora meglio se come fece Xavier metti un link, se esiste, al documento online ed inviti all'inserimento su Wikisource.

@Xavier Se andiamo avanti come stiamo andando, Google non ci fa paura. UN progetto come lo Zibaldone varrebbe da solo l'esistenza di Wikisource. Abbiamo tante cose che non vanno, il mio cruccio maggiore per ora rimane capire perchè siamo in così pochi: non scaliamo mai, siamo aumentati in questi anni ma di poco, molto poco, e non capisco perchè. Forse sbagliamo approccio, forse siamo troppo complicati, forse i matti digitali che trascrivono sono solo in LIberLiber e Gutemberg, forse le nostre pagine Aiuto fanno schifo, forse tutto questo o niente di questo. Continuo a pensare che se fossimo un decina in più le cose sarebbero molto diverse qui. --Aubrey McFato 22:49, 24 set 2009 (CEST)

Un BarCamp a Milano su Biblioteche digitali& C. e stampa on demand

Per chi ha la curiosità intellettuale di approfondire l'argomento segnalo che a Milano il 9 ottobre presso lo IED, via Sciesa 4, vi è un BarCamp con la presenza di docenti universitari, editori digitali ecc. L'iscrizione è gratuita. La parte delle nuove forme di diritto d'autore, compreso il copyleft saranno coordinate da Simone Aliprandi che collabora a molti progetti wikimedia.--Mizar (ζ Ursae Maioris) (disc.) 08:15, 23 set 2009 (CEST)

Non credo di poter esserci, ma ci farò un pensierino. --Aubrey McFato 22:33, 24 set 2009 (CEST)

Qualità delle pagine Pagina

Qualcosa è cambiato nella gestione della Qualità delle pagine Pagina, e il nostro box Qualità in testa alla pagina non funziona più: è rimpiazzato da una scritta in inglese che esprime il signigicato del SAL "secondo en.source". Bisognerà rivedere le routine js che gestiscono la cosa! Chi avvisiamo?

V.Pagina:Zibaldone di pensieri VI.djvu/247 (nuovo sistema) e cnfr. con Pagina:Zibaldone di pensieri VI.djvu/100 (vecchio sistema). Ovviamente devo spiegare bene la cosa ad Alebot, il "vecchio" sistema di creazione delle pagine via bot crea problemi ("doppia qualità"). Penso che si tratti di dell'applicazione di quella "novità" a cui accennava ThomasV e che avevo riferito qui pochi giorni fa. --Alex brollo (disc.) 07:11, 25 set 2009 (CEST)

"Tecnicamente" si tratta di un tag xml nuovo di zecca; il vecchio codice era:

<noinclude>{{PageQuality|2|Alebot}}<div class="pagetext">


</noinclude>

mentre il nuovo codice è:

<noinclude><pagequality level="1" user="Alebot" /><div class="pagetext">


</noinclude>

--Alex brollo (disc.) 07:35, 25 set 2009 (CEST)

I am not sure to understand the question in italian, but here's my answer:

the messages displayed have to be setup in Mediawiki:Proofreadpage_quality0_message to Mediawiki:Proofreadpage_quality4_message

if you create a page by bot, just put the raw text and the pagequality tag will be added

ThomasV (disc.) 08:39, 25 set 2009 (CEST)

also, please use the same numbers as the other subdomains; 1 means not corrected, 2 means that there is a problem with the page. you do not want to start a page at level 2. ThomasV (disc.) 08:43, 25 set 2009 (CEST)

Thanks Thomas, here we use levels, but the meaning is different form the original one. Our issue is how to use the new tag and the related informations. About my bot, I'll test and "try and learn". ;-) --Alex brollo (disc.) 09:43, 25 set 2009 (CEST)

Ragazzi abbiamo un problema.... innanzitutto, un problema di comunicazione. Chi trova documentazione sul nuovo tag <pagequality> la condivida! :-( --Alex brollo (disc.) 12:38, 25 set 2009 (CEST)

Primo link a documentazione cambiamenti

Eccolo: aggiornamenti 24.09.09. A una prima lettura non ho capito una cippa. Quello che ho capito è che sarebbe stato bello saperlo un po' prima. --Alex brollo (disc.) 13:59, 25 set 2009 (CEST)

Ma noi dobbiamo per forza seguire la loro strada? Il nostro sistema funzionava bene... --Aubrey McFato 15:02, 25 set 2009 (CEST)

Aspettiamo di capire bene come la cosa funziona; penso che poi non sarà difficile convertire il nuovo "segnale" nel nostro sistema, pari pari. Ma toccherà rimettere mano al js di Common.js. Francamente, il sistema che avevo ideato (crosslink + qualità mediante section, completamente "semantizzato" e utilizzabile in modo del tutto libero) mi sembra a prima vista molto migliore... ma può darsi che sia affetto dalla "sindrome dello scarafone". ;-) --Alex brollo (disc.) 15:48, 25 set 2009 (CEST)

Aubrey, o un altro admin: la prma cosa che farei sarebbe sproteggere le pagine da Mediawiki:Proofreadpage_quality0_message a Mediawiki:Proofreadpage_quality4_message, per modificarle in modo che generino esattamente il boxino SAL a cui siamo abituati. ;-) --Alex brollo (disc.) 15:54, 25 set 2009 (CEST)

Non si riesce, mi da errore interno. --Aubrey McFato 11:42, 27 set 2009 (CEST)

Secondo link a documentazione cambiamenti :-(

Eccolo qui: http://wikisource.org/wiki/Wikisource:ProofreadPage#The_.3Cpages.2F.3E_command

Un bell'esempio delle nuove possibilità in ns0: http://fr.wikisource.org/wiki/La_Petite_Dorrit_-_Tome_2_-_Chapitre_5

--Alex brollo (disc.) 16:28, 25 set 2009 (CEST)

A Piacenza si è parlato di Wikisource

Nell'ambito del Festival del diritto a Piacenza, una sessione, svolta al salone d'Onore di Palazzo Rota Pisaroni è stata coordinata da Fiorello Cortiana, per tanti anni uno dei parlamentari più attenti alle esigenze del mondo web. Relatori: i Professori Juan Carlos De Martin del Politecnico di Torino e Paolo Ferri della Bicocca di Milano e l'avv Pancini della Google Italia. I due professori sono noti per la stima da loro espressa nei confronti di wikipedia. Per me è invece stata una piacevole sorpresa il discorso dell'uomo-Google che cerca di instaurare un dialogo con il mondo del Web 2.0 per affrontare la controversia che la oppone all'Associazione Italiana degli Editori e ancor di più mi sono meravigliato che gli esponenti di Condividi la Conoscenza hanno mostrato di voler gradire queste aperture. Nel dopo incontro ufficiale l'avv. Pancini ha avuto parole di apprezzamento per Wikisource. Io non ho nascosto che almeno in partenza le nostre relative posizioni dovrebbero essere come quelle tra il diavolo e l'acquasanta, (il pericolo che Google possa abusare della sua posizione dominante nel mondo delle biblioteche digitali è vivo e reale) Ma forse ha ragione Cortiana di aver compiuto una scelta inaspettata e aver così imbarcato questo inatteso compagno di viaggio per aiutare nella difficile strada di condividere la conoscenza. Il dubbio è che sia una ingenuità, come dice la celebre favola, fare società con il leone che in ogni momento può mangiare tutti gli altri animali suoi compagni. Per ora non esprimo commenti: ho fatto solo la cronaca di una mattinata piacentina.--Mizar (ζ Ursae Maioris) (disc.) 00:04, 27 set 2009 (CEST)

Pagina principale

Cari amici,

ieri ho fatto delle prove sul sidebar inserendo collegamenti diretti ai portali. Come potete facilmente notare, non è bella una scheda così lunga sulla sinistra. A tal proposito ho pensato che potremmo rinnovare la tabella libreria, ridimensionandola e accostarle un tabella portali (e progetto). Cosa ne pensate? --Xavier121 10:25, 27 set 2009 (CEST)

Sidebar

Cari amici,

avrete notato il cambiamento della casella sinistra "navigazione", quella che in gergo tecnico si chiama la sidebar: si sono aggiunti i link ai portali. Siccome questa zona del sito è estremamente delicata in quanto è alla base della navigazione per tutto il sito (e siccome non sono contento dello stato attuale dei link), proporrei una discussione per ottimizzare tale luogo.

Le mie idee sono le seguenti:

• Tra tutti i link ai portali, visto che nel tempo questi potrebbero proliferare assai più di adesso, privilegerei il link al metaportale Portale:Portali, il vero smistamento a tutti gli altri portali senza implicare privilegi o selezioni e attualmente trascurato.
  • A me i link a portale:Autori e Portale:Testi, per la loro caratteristica di portali generali piacciono e li terrei comunque nella sidebar, ma dato che probabilmente è la loro presenza ad aver originato l'aggiunta degli altri portali mi rimetto al consenso della comunità per mantenerli: le scelte dunque sarebbero
  1. come ora, con link a cinque portali (e in futuro?)
  2. con link al solo Portale:Portali
  3. con link a tre portali: Portale:Autori, Portale:Testi e Portale:Portali
• Un'altra idea che mi gira per la testa è che l'aggiunta della casella "crea un libro" ha spostato ulteriormente in basso la casella "strumenti": pur avendo una discreta risoluzione di schermo (1440*900) ogni volta che devo usare gli strumenti (cioè continuamente) devo far scorrere in basso la schermata, con conseguente esponenziale perdita di tempo. Evidentemente l'allungamento della sidebar pegiora ulterioremente tale situazione. - εΔω 10:33, 27 set 2009 (CEST)

Come accennavo sopra, credo sia arrivato il momento di ridisegnare anche la copertina del nostro progetto, la tabella della libreria non è il massimo, aggiungendo un po' di grafica con i portali sarebbe meglio, sulla colonna di sinistra lascerei solo Portale:Portali o semplicemente Vai ai portali o Portali tematici ecc. --Xavier121 10:42, 27 set 2009 (CEST)

Non riescoa mettermi nei panni di un lettore, ma vi dico le mie impressioni di nuovo arrivato, che cercava libri e autori specifici: l'unica cosa che mi interessava era una buona funzione ricerca. Ci ho messo mesi e mesi a capire cos'è un portale e cos'è un progetto. Tuttora mi interessa (personalmente) pochissimo... secondo me, tutto dovrebbe essere polarizzato sulla funzione ricerca. E quindi la porterei molto, molto in alto. Quanto all'elenco dei portali: ovviamente, la mia idea è di eliminarli dalla barra di navigazione. E diffiderei chiunque a mettere un link che si chiami Portale:Portali che è esoterico al cubo. Elimiterei volentieri anche le "pagine a caso" sostituendole, eventualmente, con link a pagine in cui ci siano elenchi a pagine selezionate. --Alex brollo (disc.) 13:03, 27 set 2009 (CEST)

Io do ragione ad Alex, e questa volta con più cognizione di causa datami dai miei studi: tutti i prof et similia avuti mi confermano (basati sui dati e sulle abitudini degli utenti di tutto il modno) che l'era del browsing, per ora è finita.

Volenti o nolenti tutti hanno in testa Google, una funzione ricerca in cui piazzano parole e da cui vogliono la risposta giusta. Che siano aspettative giuste non lo so, ma la siutazione è così, pensate a Yahoo vs Google.... Nella homepage che dobbiamo caricare da anni la funzione ricerca è molto più visibile, ma come al solito siamo rimasti indietro perchè nessuno di noi, me in primissimis, si prende la briga di occuparsi della questione... Aubrey McFato 20:39, 27 set 2009 (CEST),

Se caricate beta trovate la funzione ricerca in alto a destra, posizione ideale. Eliminiamo i portali dalla sidebar e sistemiamo in modo razionale (spazio più contenuto) la scheda libreria. Se l'idea di avere una scheda che contenga le icone con i rispettivi portali non piace, perché non pensiamo a degli spazi costruiti sull'esempio degli inviti alla lettura dei portali, da inserire nella pagina principale? Tipo testo della settimana? Quella finestra che avevavamo pensato per pedia non la possiamo recuperare per noi... insomma una pagina principale un po' simile (non identica) ai portali tematici... --Xavier121 21:32, 27 set 2009 (CEST)

Ridimensionati i portali, adesso si potrebbe rivedere l'odiosa tripletta autore, testo, aiuto a caso. Pareri. --Xavier121 21:58, 27 set 2009 (CEST)

A me piace molto la pagina principale dei nostri colleghi portoghesi :D --Xavier121 23:10, 27 set 2009 (CEST)

Posso provare a immaginare un qualche trucco per linkare nei pulsanti "a caso" una lista di autori selezionati (autori "veri" con opere su Source, se possibile con SAL alto) e di opere selezionate (con SAL alto). L'aiuto a caso mi sembra che non serva a molto, lo eliminerei senza rimpianto. --Alex brollo (disc.) 11:55, 28 set 2009 (CEST)

Nuova skin: no ostriches allowed!

Chi di voi ha cominciato a provare la beta della nuova skin? Faccio notare che il futuro è lì, e ignorarla non potrà che creare sgradite sorprese quando essa sarà implementata con o senza il nostro assenso. Ovviamente potremo optare tramite le preferenze per tenerci la skin monobook, ma sarà una scelta del singolo utente, non della comunità, inoltre tutte le modifiche estetiche e la geografia delle pagine non saranno più basate su monobook, ma su questa nuova skin. Meditiamo gente, meditiamo. - εΔω 10:33, 27 set 2009 (CEST)

Faticosa da usare, con le pagine proofread... mancano tutti i comodissimi pulsanti aggiuntivi. Però la ricerca in alto, in completa evidenza, è una grande idea. --Alex brollo (disc.) 22:44, 27 set 2009 (CEST)

Usandola vanno a farsi benedire tutte le "tendine" di iPork... che sono un aiuto fondamentale per tanti tanti aspetti del nostro lavoro sporco-. C'è qualche anima pia amante del Javascript che possa esaminare il loro codice? - εΔω 22:58, 27 set 2009 (CEST)

Non ho capito se, con la nuova skin, le tendine funzionano se settate come opzioni personali. Fosse così, saremmo quasi a posto. --Aubrey McFato 11:50, 28 set 2009 (CEST)

Sembra proprio di no. Qualcuno sa cosa dicono su Pedia? --Aubrey McFato 11:53, 28 set 2009 (CEST)

Proverò a dare un'occhiata... ma non sperate in grandi cose, ci capisco assai poco. Giusto qualche iniziale barlume. --Alex brollo (disc.) 12:02, 28 set 2009 (CEST)

Siccome la beta è un progetto ampio e trasversale, immagino che ci siano centinaia, forse migliaia di utenti espertissimi che si stanno ponendo esattamente questo problema in questo momento e che stanno producendo ottimo js. Il problema è pescarli (la recente rivoluzione della Proofread extension mi ha fatto constatare come la comunicazione è un bel problema, nell'orrendo intrico del progetto wiki...). Siccome frequento irc con lo stesso entusiasmo con cui frequento lo studio di Karmen (la mia eccellente dentista), se qualcuno più "portato" prova a indagare... --Alex brollo (disc.) 06:51, 29 set 2009 (CEST)

Aggiungo: forse - nella filosofia "Usability" - piuttosto che concentrarsi su una skin che sia ideale sia per il lettore, che per il contributore occasionale e per il contributore "pesante" - sarebbe opportuno orientarsi a skin differenziate, ciascuna ideale per i vari tipi di utente. Questo consentirebbe di riservare lo skin monobook per gli utenti molto attivi, di conservare e sviluppare i tool js avanzati su una sola skin "tradizionale", che sarà comunque mantenuta a lungo, penso, perchè vi si appoggiano molti script pywikipedia. --Alex brollo (disc.) 08:50, 30 set 2009 (CEST)

Notizie certe mi confermano che il problema è serio. Le funzioni avanzate fatte con il monobook sono incompatibili con la nuova skin, e la comunità si trova in difficoltà serie, non sembra si stiano attivando più di tanto. Intanto posso solo dare questo link: http://it.wikipedia.org/wiki/Progetto:Coordinamento/Usabilit%C3%A0 . --Aubrey McFato 11:03, 30 set 2009 (CEST)

Una buona notizia almeno provo a darla: i popup mi funzionano. Per me sono un aiuto enorme. - εΔω 14:27, 30 set 2009 (CEST)

Ripropongo in modo più esplicito la domanda: voi pensate che la vecchia skin base monobook sarà eliminata? A me pare che nel link di Aubrey sia scritto chiaramente che chi vuole potrà mantenere la skin vecchia. In questo caso, gli sforzi per adattare i tools avanzati alla nuova skin non avrebbero una gran prorità. Gli "appassionati dell'aspetto grafico" avrebbero il fastidio di dover controllare ogni tanto la nuova skin, tutto qui. Gli "appassionati dei contenuti" potrebbero (quasi) ignorarla. --Alex brollo (disc.) 16:11, 30 set 2009 (CEST)

Ribadisco quanto scritto di sopra: la skin monobook rimarrà come opzione del singolo ma è destinata ad essere abbandonata su grande scala, un po' come accade per i sistemi operativi o per certi software: nulla impedisce di continuare ad usare la vecchia skin, ma se gli sviluppatori si concentreranno su soluzioni, espansioni, grafica e altre idee implicanti la nuova skin e incuranti della vecchia, chi usa la vecchia si troverà in breve assai scomodo e inascoltato. Fate un esperimento: provate a girare per un qualunque sito WMI usando una skin vecchio stile o di infimo uso come myskin, chick o Classic e capirai ciò che intendo esprimere. Siamo nel mezzo di una transizione e ignorarlo non può che danneggiarci.

Un esempio: avete notato il ragruppamento dei tasti freccia nel namespace pagina? È scomodissimo! Per poter modificare tale comportamento almeno localmente occorre cominciare a chiedere o informarsi ora, piuttosto che continuare a usare Monobook e poi sentirci dire tra un anno che nessuno si era lamentato di questo... - εΔω 16:56, 30 set 2009 (CEST)

Facile profeta

Argh! provate a modificare una pagina qualunque: noterete che la toolbar della finestra di modifica è cambiata nella skin monobook? Non sarebbe questo gran male se non fosse che anche passando da Vector a Monobook le tendine di iPork non funzionano più!

ieri ho contattato ThomasV per comunicargli il problema delle freccine di navigazione nel namespace pagina con la skin vector... mi rispose che conosceva il problema, ma che lo stato di sviluppo della skin è ancora parziale, e che adottare soluzioni ora sarebbe dannoso in quanto l'interfaccia potrebbe ancora cambiare notevolmente. Questo mi impedisce di chiamare in causa iPork per chiedergli di dare un'occhiata ai suoi javascript. Intanto però una parte della nuova skin è entrata (a gamba tesa) nella nostra pratica quotidiana. No comment (commentate voi). - εΔω 19:18, 1 ott 2009 (CEST)

Wiki è un magnifico esempio di sistema complesso adattativo, che funziona solo restando all'orlo del caos. La cosa ha i suoi inconvenienti... ma anche il suo fascino. Ci adatteremo. ;-) --Alex brollo (disc.) 23:34, 3 ott 2009 (CEST)

Oggi ho contattato ThomasV: l'update globale della estensione Proofread eliminerà un fastidioso bug (gli "a capo finali" inseriti a forza in fase di salvataggio)

Ho infine scoperto la soluzione al bug descritto ad inizio sezione: se si è passati alla skin Vector, una volta rientrati nella skin monobook rimane la toolbox vector (con grave disagio quando si edita nel namespace pagina e disattivazione delle tendine di iPork). Ebbene, andando nelle preferenze si scopre che in Preferenze-->Casella di modifica-->Experimental Features una checkbox mantiene abilitata la "advanced toolbox" della skin vector. Deflaggando tale checkbox la toolbar ritorna quella a noi usuale e le tendine di iPork tornano a funzionare. whew!- εΔω 17:42, 7 ott 2009 (CEST)