Wikisource:Bar/Archivio/2011.12

Archivio delle discussioni del mese di dicembre dell'anno 2011

Categoria: Archivio Bar 2011 Bar   Archivio    dicembre 2011 



Sequenza "furba" di tools Strumenti per la rilettura modifica

Sto verificando che sulle opere in prosa (soprattutto se è stato impostato il datiPagine; se non sapete cos'è, chiedete aiuto a uno qualsiasi degli utenti esperti) la sequenza più furba per fare le primissime modifiche di una pagina con OCR integrato nel djvu è:

  1. elimina riga 1 per eliminare "pattume" prima della prima riga di testo; tanti click quante sono le righe di pattume da eliminare
  2. aggiusta paragrafi, un solo click;
  3. POI postOCR cliccato per due volte consecutive (il prima "fa il lavoro" e crea RigaIntestazione, il secondo sposta RigaIntestazione nell'header)

L'errore da non fare è dare postOCR per primo, perchè poi non si possono più usare i due primi tool.

Ho sistemato i tre tool nell'ordine giusto, per aiutare a ricordare la sequenza "furba".

Nel caso delle opere in versi, le cose sono diverse, e avvio il cervello per renderle quanto più possibile uguali.--Alex brollo (disc.) 08:39, 4 dic 2011 (CET)[rispondi]

Ho in Utente:Alex brollo/vector.js una nuova versione di rimuoviPrimaRiga() che "rulla" quella di default; in effetti, adesso lo script indovina (non so ancora con che accuratezza, test in corso) se un testo è prosa oppure poesia, esaminando il solo testo della pagina, e se è poesia prima aggiunge un tag poem attorno all'intero testo, poi elimina la prima riga (salvando il tag poem). Così facendo, esclude i "danni da aggiustaParagrafi" e pure i danni da postOCR; in altri termini, quando lo script indovina, la sequenza elimina riga 1 - aggiusta paragrafi - postOCR è altrettanto sicura nei testi in prosa che in versi. Cerconsi coraggiosi volontari per stressare lo script. --Alex brollo (disc.) 13:17, 4 dic 2011 (CET)[rispondi]

Help (?) modifica

Aiutooo! :) A suo tempo avevo cominciato a giocare con un wiki libro. Me l'ero dimenticato e me l'ha ritrovato Guggol. Oggi ci ho girato un po' per rinfrescarmi il neurone. Ma!! Non riesco più a chiudere il "banner" in alto che adesso si apre in tutte le pagine. Quando clicco "Creatore di libri (disattiva)" mi viene detto "Il creatore di libri verrà disattivato e il libro a cui si sta lavorando sarà rimosso." Ma io voglio solo chiudere il banner mica rimuovere l'intero baraccone! Oppure il testo del "warning" è un po' incorrect e non succede niente? Ma se si? Nel (orribile) dubbio mi astengo ma quel banner è un po' in mezzo ai calli. :-( --Silvio Gallio (disc.) 17:12, 4 dic 2011 (CET)[rispondi]

Dimenticavo; cliccare su aiuto non mi ha portato molto lontano. Se no non scrivevo qui... :P Scappo e fuggo. Buon resto di domenica. Silvio Gallio (disc.) 17:15, 4 dic 2011 (CET)[rispondi]

Avviso Strumenti per la rilettura modifica

Dopo un tentativo (vedi messaggio precedente tagliato via) ho ideato un altro "trucco" forse più intuitivo.

Come aprite una nuova pagina, appena il testo OCR viene caricato parte un "postOCR automatico" creato da Candalua; la routine che tira a indovinare se il testo è prosa o poesia è inserita all'inizio di questo script. Se alla routine pare che il testo sia poesia, allora vi chiede conferma ponendovi la domanda: "E' un testo in versi?". Se confermate con un Enter, aggiunge un poem attorno al testo; se negate con Annulla, non lo appone. Potete comunque utilizzare il tool "elimina riga 1", se dopo il tag poem c'è una riga di pattume, il tag poem verrà salvato; e poi potete tranquillamente usare aggiusta paragrafi e postOCR senza devastazione degli acapo fissi del testo in versi.

Mi raccomando: datemi feedback! E fra l'altro, mi resta la insoddisfatta curiosità di sapere quanti fra voi utenti - escluso il drappello degli "utenti storici" - utilizzano il gadget Strumenti per la rilettura. --Alex brollo (disc.) 17:14, 5 dic 2011 (CET)[rispondi]

(a parte)Ti comunico Alex che ieri è passato un "progetto Usabilità" per Source, e quindi proveremo a cercare un esperto che venga da noi e ci insegni a mettere a posto tutti i nostri tool. Un mio feedback, per esempio, è che sarebbe meglio togliere il template RigaIntestazione da postOCR, perchè preferisco fare io un click in più che avere un utente non esperto che lascia dei template riga intestazione in giro senza saperlo... Inoltre, ripristinerei il tool delle virgolette, che era comodissimo. --Aubrey McFato 17:21, 5 dic 2011 (CET)[rispondi]
Ma esiste questo fantomatico utente non esperto che attiva il gadget Strumenti per la rilettura? E' questa la domanda che mi opprime.... :-( Se questo utente esiste, batta un colpo.
Aubrey... quale, precisamente, strumento per le virgolette? Quello che convertiva "" in “”? Oppure in “„ oppure in „“ oppure in «» oppure in ‘’.... quando mi son reso conto della varietà di possibilità mi sono un pochino demoralizzato. --Alex brollo (disc.) 17:36, 5 dic 2011 (CET)[rispondi]
Ho riattivato virgolette(), ma è ancora incompleto; mi tocca aggiungere un parametro virgolette:... in datiOpere in modo da registrare la "variante virgolette specifica per opera", e poi fare in modo che virgolette() legga il dato. --Alex brollo (disc.) 19:05, 5 dic 2011 (CET)[rispondi]
Dovrebbe essere ok; per attivare le "virgolette opera-specifiche" occorre aggiungere alle altre variabili di datiPagine un codice tipo:
'virgolette':'“„',
mettendo ovviamente le virgolette "giuste" per l'opera. Un esempio (che ho usato per i test) in MediaWiki:Variabili.js nei dati di Rivista di Scienza - Vol. II.djvu.--Alex brollo (disc.) 21:26, 5 dic 2011 (CET)[rispondi]
Perdonami, il tool che volevo intendere (pessima scelta di parole) era quello degli apostrofi: operazione che è terribile fare a mano, e che io faccio con postOCR, solitamente, ma ogni tanto mi smanaccia troppa roba (per es., mi mette un template intestazione che poi devo togliere). --Aubrey McFato 10:18, 9 dic 2011 (CET)[rispondi]
Ah. Quello. :-(
L'ho eliminato perchè, per quelle poche volte cha aggiunge un rigaIntestazione di troppo, la svuoto in un lampo e la metto vuota in header con un secondo click su postOCR, dove non dà alcun fastidio, anzi, e da là non si muove più. Io uso sempre postOCR per gli apostrofi. Comunque, lo riattiverò. --Alex brollo (disc.) 14:46, 9 dic 2011 (CET)[rispondi]

Portale Diritto modifica

Come forse avete visto ho preparato una bozza del suddetto portale. Credo che ci sia ancora molto da migliorare: proposte?--Erasmo Barresi (disc.) 18:42, 7 dic 2011 (CET)[rispondi]

Ti dirò che a me piace già molto e che non vedo granché da migliorare, ma forse sono stato troppo veloce nel guardare la bozza... Sicuramente occorrerà rendere dinamici i riquadri "di vetrina" come nella pagina principale ma questo si può fare tranquillamente. - εΔω 22:49, 8 dic 2011 (CET)[rispondi]

Problemi col SAL modifica

C'è qualche problema con le modifiche, non viene più aggiunto il SAL in fondo alla pagina (e causa problemi con gli a capo tra pagina e pagina). --Luigi62 (disc.) 19:40, 8 dic 2011 (CET)[rispondi]

Dovrei avere sistemato. Alex, stavo quasi per risponderti che purtroppo non ho tempo per seguire le tue novità, e invece mi hai fatto lavorare anche stavolta! :-) Mannagg'.... Candalùa (disc.) 20:23, 8 dic 2011 (CET)[rispondi]

Non puoi dire che faccio le cose a tua insaputa. Quando qualcosa si intoppa sai già di chi è lacolpa e dove mettere le mani. :-)
Beh, dovrei aver finito con Common.js, mi scuso del disagio e spero di portare a casa presto i frutti di questa fatica. --Alex brollo (disc.) 01:19, 9 dic 2011 (CET)[rispondi]

FILENO OLIVIERI modifica

Salve, sono utente Esmeralda. Ho molto apprezzato il contributo Errori e soluzioni, Italia Meridionale di Fileno Olivieri. E vorrei comunicare a quanti fossero interessati all'argomento di possedere un vecchio volume inerente La Questione Meridionale, non credo sia più in commercio. Grazie.

Progetto Phe modifica

Ho il piacere di dirvi che la primissima versione del "progetto Phe" funzia. Ma siccome so come son fatto, e quanto chiare sono le mie spiegazioni delle cose nuove e exotiche, vi risparmio le spiegazioni.... se son rose, fioriranno. :-) --Alex brollo (disc.) 01:31, 10 dic 2011 (CET)[rispondi]

L'esperimento è in corso su Indice:La pastorizia.djvu (pagina SAL 25%). --Alex brollo (disc.) 15:02, 10 dic 2011 (CET)[rispondi]
Phe ha preso atto del "progetto Phe" :-) ed è già venuto a dare un'occhiata a Indice:La pastorizia.djvu, pagine dalla 58 in poi. Siccome queste pagine contengono tutte i dati necessari al suo progetto, l'ho invitato a usarle per qualsiasi test. Io invece vado avanti con l'idea di "spingere" fin dove possibile sulla formattazione automatica. --Alex brollo (disc.) 20:56, 10 dic 2011 (CET)[rispondi]


  The Teamwork Barnstar
Ad Alex Brollo Xavier121 00:13, 11 December 2011 (UTC) (fichissima questa cosa di Commons! ...la possiamo importare anche qui da noi?)
Mi confondi, Xavier... :-)
Approfitto per nuntiare vobis un risultato a cui tenevo da molti mesi: il "progetto phe" ha partorito il primo riconoscimento automatico di formattazione di un testo centrato attraverso uno script js locale, basato sull'analisi delle coordinate della riga, ed ha quindi applicato automaticamente il template centrato a una riga centrata. Si aprono interessanti scenari. Le cose sono messe in modo che chiunque lo voglia fare può provare a inventare nuovi algoritmi di formattazione automatica, riga per riga; ma ne parleremo in bar tecnico perchè non è difficilissimo, ma nemmeno semplicissimo ;-) . --Alex brollo (disc.) 09:20, 12 dic 2011 (CET)[rispondi]

Demotivator modifica

 
Statistiche testi (proofread e non proofread) al 10 dicembre 2011

Bene. Vi ho lasciati sollazzare coi festeggiamenti per il 50millesimo testo (vedi #Motivational advertising!). Ora beccatevi la doccia fredda. I testi non sono così tanti. Sono "solo" 38.715. Contati uno per uno (non da me in persona, ma dal mio fido aiutante meccanico). Cifra che del resto corrisponde grossomodo con queste statistiche. E comunque, tanto per essere pignoli, vi ricordo che quelli non sono i testi bensì le pagine. Quindi i testi propriamente detti sono certamente molti di meno. Propongo quindi di togliere il contatore dalla pagina principale, visto che chiaramente non funziona. Niente in contrario a mostrare un qualche numeretto che comunichi al mondo a che punto siamo arrivati, ma cerchiamo per piacere di metterci d'accordo su che cos'è che stiamo mostrando e come va calcolata la cifra. Candalùa (disc.) 01:40, 11 dic 2011 (CET)[rispondi]

Vero, ma lo strano algoritmo di calcolo vale più per confronti interprogetto che come valore assoluto; un numero esatto, ma non confrontabile con quello di altri progetti, temo avrebbe un significato limitato. Forse sarebbe il caso di discutere il problema in lista wikisource, in modo da identificare un parametro comune.
Aggiungo a lato la rappresentazione del nostro "andamento testi", l'orrendo scalino verso il basso corrisponde alle due grandi falciature del vecchio Zibaldone e di Bibbia. :-(
Notate che i testi "rossicci" (non proofread) restano costanti, mentre gli azzurri (proofread) si incrementano con notevole regolarità; la pendenza, molto costante, indica la capacità di caricamento "fisiologica" attuale del complesso degli utenti. --Alex brollo (disc.) 08:11, 11 dic 2011 (CET)[rispondi]
Concordo. Se il contatore non funziona non ha senso tenerlo, ma sarebbe bene capire _cosa_ conta il contatore, per dare un senso ai numeri. Che in ogni caso sono importanti, ma solo fino ad un certo punto, visto che il nostro progetto è da tempo improntato alla qualità, anche se la quantità non guasta certo. --Accurimbono (disc) 16:29, 11 dic 2011 (CET)[rispondi]
Bah, a me il contatore non dispiace: so che è inaffidabile, ma finché serve per fare festa e fare i bulli o le competizioni con le altre source è un passatempo innocuo. Semmai sarebbe utile che i dati più "verisimili" siano calcolati e mantenuti da qualche parte oltre che in Speciale:Statistiche. Qualche amministratore vuole controllare in quale ordine mostrare i link posti in Speciale:Statistiche? - εΔω 19:25, 11 dic 2011 (CET)[rispondi]

I dati di Speciale:Statistiche, paragrafo "Statistiche sulla qualità", sono abbastanza affidabili. Abbastanza, perché sono comunque una sovrastima dovuta al fatto che le categorie contengono un mucchio di vecchi redirect come questo: se nessuno ha obiezioni, io quei redirect li cancellerei una buona volta, visto che sono in totale contrasto con l'architettura che abbiamo messo in piedi. Il totale della prima riga dà in questo momento 39425, che è un numero non troppo lontano dal vero, ed è quello che mostrerei io sulla pagina principale. Sarà anche un passatempo innocuo, ma millantare un 25% in più del reale non mi sembra troppo corretto da parte nostra. Poi se le altre wiki "imbrogliano" e ci bulleggiano, chisseneimporta; tanto noi lo sappiamo quali sono i numeri "veri". :-) Candalùa (disc.) 23:55, 11 dic 2011 (CET)[rispondi]

Concordo sui redirect e sul presentare in PP un dato reale. --Xavier121 00:10, 12 dic 2011 (CET)[rispondi]
Sta il fatto che il numero 50000 ecc. corrisponde alle pagine "good" (che sono tutte quelle "non stub" di un elenco definito di namespaces) calcolate con un algoritmo comune a tutti i progetti source e comparabile pure con analoghe statistiche di altri progetti; ha un certo valore, ma andrebbe definito per quello che è (di certo, non si tratta di "testi" ma di "pagine di contenuti"). Come tale potrebbe essere ancora evidenziato, con un rimando alla statistica globale che permette il confronto con altri progetti.
Quanto a statistiche più approfondite.... la mia opinione è che il tempo che abbiamo sarebbe da dedicare a incrementarle, tali statistiche, più che a calcolarle. :-D --Alex brollo (disc.) 09:28, 12 dic 2011 (CET)[rispondi]

chiamata alle armi modifica

Sto cercando di svuotare più possibile la vecchia Categoria:Testi SAL 100% (vi ricordo che i testi proofread, una volta riletti, vanno messi in Testi Edizioni Wikisource, e non in Testi SAL 100%, che è riservata ai testi riletti ma senza versione cartacea a fronte). Ci sono in essa diverse opere importanti che sarebbe bello avere in forma proofread. Tanto per dire tre mostri sacri: i Canti del Leopardi, i Sonetti del Foscolo, le Odi del Parini. Mi aiutare a trovare sui soliti siti una buona edizione per queste tre opere (o per altre che vedete lì dentro)? L'idea a lungo termine sarebbe, una volta svuotata la categoria SAL 100% da tutto ciò che può diventare proofread, di portare ad un più prudente 75% i pochi testi che saranno rimasti, ed eliminare la categoria; di modo da ritrovarsi con 4 livelli di qualità su ogni namespace, perfettamente coerenti tra loro (vedete la tabella qui con l'evidente anomalia dei 5 livelli per i Testi e 4 per Pagine e Indici). Candalùa (disc.) 23:55, 12 dic 2011 (CET)[rispondi]

Posso aiutarti con i Canti. --Xavier121 00:23, 13 dic 2011 (CET)[rispondi]
Sono molto d'accordo con Candalua, e dirò di più: una volta esauriti i testi SAL 100% possiamo sostituire la stelletta con il quadrato "SAL 100%" uniformando così completamente la grafica tra i namespace. - εΔω 00:51, 13 dic 2011 (CET)[rispondi]
Se posso essere d'aiuto... Purchè mi diate indicazioni molto precise di cosa debbo fare, e purchè non ci sia una scadenza temporale. --Lagrande (disc.) 07:41, 13 dic 2011 (CET)[rispondi]
Ricordatevi di me, e del mio fido FineReader 11. Appena trovate delle buone scansioni, mi prenoto per fare un ottimo OCR e preparare il djvu. Basta che mi diciate dove scaricare un pdf, un djvu, una collezione di immagini. --Alex brollo (disc.) 09:11, 13 dic 2011 (CET)[rispondi]
Se c'è da sparare... :) Mi accodo a Lagrande. Qualcuno di voi "mostri sacri" butti giù la lista, e man mano che il pezzo sarà scaricato da un utente ci si mette un simbolo (stike?) per evitare doppioni. Come sapete anch'io no ho molto tempo, ma una mano arriverà di certo. Bye!--Silvio Gallio (disc.) 09:21, 13 dic 2011 (CET)[rispondi]
* Canti di Leopardi: vasta scelta su IA: [1]; problema: scegliere l'edizione più prestigiosa e meglio scannerizzata.
  • Odi di Parini: questo mi pare buono, verifico che non ci siano falli e poi lo carico
    • La scansione è un disastro di pagine mancanti e doppie.... NON caricatela, vediamo se si può restaurare. Approfitto per raccomandare a tutti una verifica puntigliosa della sequenza pagine dei djvu da google e da IA prima del caricamento (dopo tutto diventa difficile!). Non fidatevi!
  • Sonetti del Foscolo: a voi la ricerca. Alex brollo (disc.) 09:35, 13 dic 2011 (CET)[rispondi]
Alex, se te la senti, si possono recuperare ottime edizioni da OPAL, qui Parini e qui Foscolo. :) --Xavier121 13:52, 13 dic 2011 (CET)[rispondi]


Note a margine


Da un pov scientifico l'edizione del Ranieri è sempre stata criticata per le numerose sviste e per il sospetto che non sia stata rispettata compiutamente la volontà dell'autore. Per la nostra biblioteca avrebbe un volore più che altro storico. Diverso il caso di quelle a colori, sempre su IA, una di Donati e l'altra di LEVI (la prima più scarna ed essenziale con poche note, la seconda preferibile per l'ampio apparato critico, le interessanti introduzioni alle poesie e una storia editoriale del testo completa ecc.), ma per entrambi c'è il sospetto di copyviol perché il Levi è morto nel 1951, mentre non trovo alcuna data per Donati. Io sto lavorando per ottenere l'edizione del Moroncini (la più autorevole), pubblicata per la prima volta a Biologna nel 1927, ma ristampata in una miscellanea delle opere complete di G. Leopardi nel 1978. Poiché il Moroncini è morto nel 1935, dovrebbe essere di pubblico dominio in entrambi i paesi perché testo pubblicato dopo il 1977 con autore morto da 70+1 anni (chiedo conferma ai fanatici del copyright). Questo sarebbe un bel colpo, visto che ci vogliamo mettere le mani. --Xavier121 13:31, 13 dic 2011 (CET)[rispondi]
Io invece non sono d'accordo per niente nè nel metodo (discussione di 5 minuti di una procedura utilizzata da anni) né nel merito: cosa vuol dire "di portare ad un più prudente 75% i pochi testi che saranno rimasti"? Se un testo senza djvu è stato riletto deve stare al 100%, se no al 75%, come da procedura, se li metti tutti al 75% allora non ha più senso nulla (Sennò vorrà dire che domattina qualcuno si sveglia e propone di portare tutto al 50%...).
I testi che stanno al 100% si trovano lì perchè qualcuno li ha riletti, e quel qualcuno lo si può trovare nella pagina di discussione nel template infotesto alla voce "rilettore".
Oppure si decide che i testi senza testo a fronte non possono stare al 100% e buona notte, basta esser chiari, anzi si potrebbe anche decidere che un testo senza DJVU va cancellato da wikisource. Però prima di fare questi cambiamenti radicali un minimo di discussione... e anzi io eviterei di ripetere le stesse discussioni periodicamente, sennò quà quelli come me che frequentano sporadicamente il progetto non ci capiscono più nulla, oltretutto che le pagine di aiuto non tengono certo il passo delle discussioni/rivoluzioni/cambiamenti. Scusate lo sfogo, ma io mio sono stufato di questo cambiamento continuo a cui è sottoposto il progetto, per cosa poi? Per aumentare la confusione e allontare i vecchi e nuovi contributori che non hanno il ritmo degli utenti più attivi come Candalua e Alex?
--Accurimbono (disc) 14:45, 13 dic 2011 (CET)[rispondi]
Mi pare che ne stiamo discutendo! :D Io sono per uniformare i NS quindi 4 icone e via ed. Wiki. ecc. Se si stabilisce la regola che nessun testo può arrivare al 100% senza scansione, va da sé che è retroattiva altrimenti si che si crea confusione!!! Tutti i testi sono riletti, anche quelli al 50% o 75%; non è che solo quelli a 100% sono PIU' riletti degli altri. Non vedo stravolgimenti ma solo aggiustamenti di tiro e coerenza: per me genera molta più confusione l'attuale sistema di salatura a due vie. --Xavier121 15:17, 13 dic 2011 (CET)[rispondi]
(conflittato) Calma. Prima di tutto qui nessuno ha ancora deciso niente, io ho solo detto quale sarebbe la mia idea a lungo termine. Prima di applicarla se ne può ovviamente discutere, come stiamo facendo. Il problema coi testi 100% è che non c'è assolutamente modo di essere sicuri che siano stati davvero riletti. Alcuni non hanno segnato il nome del rilettore, tanto per dire. Altri sono stati portati al 100% da utenti palesemente alle prime armi, che probabilmente non avevano ben chiaro il significato di 100%. Comunque l'intenzione mia sarebbe prima di rendere proofread più opere possibile, proprio per alzare in effetti la loro qualità portandole ad Edizioni Wikisource. La retrocessione al 75% sarebbe da fare solo per quelle poche opere per le quali non si trovasse proprio una scansione, che spero saranno alla fine poche decine, dunque una perdita che ritengo trascurabile a fronte di una maggiore chiarezza nell'indicazione della qualità e di una maggiore garanzia della stessa. Ci vorrà molto tempo per arrivare a ciò, quindi non è il caso di allarmarsi ora. Non stiamo ancora parlando di rinunciare del tutto ai testi non proofread, anzi non credo che a quello arriveremo mai... ma io in effetti comincerei col vietare di aggiungere nuovi testi alla categoria SAL 100%, cioè a considerare come rilettura valida solo quella fatta in modalità proofread (e in quanto tale facilmente riscontrabile). Candalùa (disc.) 15:28, 13 dic 2011 (CET)[rispondi]

Mi sembra che il dialogo si sia animato per bene e questo è un buon segno. Siccome però ritengo che una discussione di così ampio respiro richieda il suo tempo e la giusta ponderazione (Accurimbono ha correttamente fatto notare che stavamo partendo lancia in resta con fin troppa leggerezza) proporrei di spostare in Discussioni progetto:Qualità la discussione sul significato "filosofico" della proposta (il SAL Edizioni Wikisource aveva molta più importanza nell'era pre-proofread mentre oggi i rapporti con il SAL 100% sono perfettamente rovesciati: che conseguenze vogliamo trarne?); proporrei inoltre di aprire in Discussioni progetto:Trascrizioni una lista di opere SAL 100% di cui trovare buone edizioni digitalizzate, e concentrare in tale miniprogetto le dotte e importanti indicazioni di Xavier e di chi può dare indicazioni autorevoli ai scandagliatori di archivi online. Il risultato finale dovrebbe essere una presa di posizione condivisa sull'evoluzione del sistema attuale e una buona strada di lavoro per assegnare ai nostri mostri sacri delle valide versioni proofread. Che dite? - εΔω 15:43, 13 dic 2011 (CET)[rispondi]

Molto ignaviamente mi adeguo alla maggioranza, ditemi cosa devo o non devo fare. Se avete bisogno di qualcosa dal Gutenberg fatemi sapere. --Lagrande (disc.) 16:10, 13 dic 2011 (CET)[rispondi]
Ho iniziato a preparare una lista su Discussioni progetto:Trascrizioni. Chi se ne intende può iniziare ad aggiungere lì i link alle edizioni. Ovviamente vi raccomando fin d'ora di tenere la pagina in ordine :-), e se avete in mente un layout più leggibile modificate pure. Candalùa (disc.) 20:07, 13 dic 2011 (CET)[rispondi]
Ok, allora ne sto lontano. :-P
Scherzi a parte: ritengo molto importante la fonte OPAL, e vorrei "specializzarmi" su questi testi per vari motivi:
  1. le scansioni sono in genere molto buone, e sono assolutamente "fedeli" all'originale (scansioni originali a colori)
  2. le scansioni non sono mai state pubblicate altrove nè interpretate con OCR
  3. questi testi sono i più adatti per mettere alla prova FineReader 11, che è in grado di convertirli in djvu con strato OCR in un solo passaggio ("divisione" delle doppie pagine compresa).
Purtroppo, il tempo mi si è improvvisamente esaurito, e quindi aiuto per un aspetto: opera per opera, bisognerebbe confrontare fra di loro le varie versioni (Internet Archive, Gooogle, OPAL) e segnalarmi quelle opere OPAL che "vincono" lacompetizione con le altre. --Alex brollo (disc.) 20:21, 13 dic 2011 (CET)[rispondi]
Confermo: mi sono fatto un giretto per IA e per OPAL, e ho accertato che non sono la persona adatta per scegliere fra diverse edizioni. Chi mi conosce meglio sa che io di tutto avrei pensato di occuparmi, meno che di bibliologia e letteratura :-) ed infatti il mio interesse è in realtà un metainteresse. Lascio ad altri l'ingrato compito, mentre mi confermo disponibilissimo a fare la manovalanza. --Alex brollo (disc.) 22:36, 13 dic 2011 (CET)[rispondi]

(rientro a sx)Non mi sono ancora espresso ma vedo la cosa con grande favore. Ai tempi noi eravamo talmente avanti (:-P) da capire che la rilettura di un testo senza la fonte non aveva molto senso, in sè e per sè, e inventammo le Edizioni Wikisource. Il lavoro di conversione e semplificazione credo sia dunque necessario, anche perchè con Match and Split e altre divolerie brolliane secondo me possiamo migliorare di molto la situazione (già buona) delle nostre statistiche (numero di pagine corrette e pagine rilette, ratio fra pagine nude e con scan). Sui dubbi di Accurimbono: credo che se ci prendiamo un po' di tempo per scegliere le edizioni giuste (magari anche quelle già utilizzate), si faccia abbastanza in fretta a ripasasre tutto al 100%, e già avere tutto al 75% è un ottimo risultato. Aubrey McFato 09:51, 14 dic 2011 (CET)[rispondi]

E se ci organizzassiomo (elasticamente ma formalmente) in "gruppi specialistici"? Da questa discussione emerge, ad esempio, che alcuni di noi hanno le capacità e la passione per valutare e selezionare le fonti per qualità del testo; altri sono specializzati in diavolerie; altri sono attentissimi e capaci formattatori; altri sono vocati alla divulgazione. Non per precludere a nessuno alcuna attività, figuriamoci, ma solo per avere un "punto di riferimento". --Alex brollo (disc.) 10:07, 14 dic 2011 (CET)[rispondi]
Ragazzi, questa è la più bella discussione dell'anno, sento un fermento... :D --Xavier121 10:30, 14 dic 2011 (CET)[rispondi]
Io mi dichiaro attenta "revisora" e "rilettrice", poco addentro alle diavolerie, ma disponibile ad imparare tutto ... :) --Lagrande (disc.) 11:36, 14 dic 2011 (CET)[rispondi]
ma tu Lagrande, sai che razza di rivoluzione hai innestato, tanto tempo fa, con qualche accenno ai trucchi Gutemberg per aiutare gli utenti correggendo automaticamente gli "scannos" (che io per la prima volta ho sentito nominare da te)? Tutte le novità che trovi originano da quelle notizie! Quindi, anche "musa ispiratrice".... :-) --Alex brollo (disc.) 12:10, 14 dic 2011 (CET)[rispondi]

Alex, io posso anche averti fatto da musa, ma tutto il caos conseguente l'hai procurato tu ... --Lagrande (disc.) 16:30, 14 dic 2011 (CET)[rispondi]

Sempre per il discorso qualità: qualcuno mi dà una mano ad assegnare una qualità a questi testi che ne sono sprovvisti? Graaaazie! :-) Candalùa (disc.) 20:14, 14 dic 2011 (CET)[rispondi]

Ma anche la pagina principale? --Lagrande (disc.) 20:34, 14 dic 2011 (CET)[rispondi]
ovviamente no, solo i testi veri e propri :-) Candalùa (disc.) 21:12, 14 dic 2011 (CET)[rispondi]

...continua... modifica

Qui tutto si basa sulle nostre definizioni dei livelli SAL, e le pagine di aiuto risalenti ai tempi della clava non ci aiutano. Del resto non possiamo nemmeno aggiornarle senza una decisione comunitaria. La domanda è: un testo non proofread può passare al 100%? Qualcuno potrebbe ricordare ancora le domande che, da novizio, ho fatto in tal senso 5-6 mesi fa, senza sapere che il problema è reale. Vi dirò di più: nella pagina di aiuto (Aiuto:Edizioni Wikisource) c'è scritto che un testo EW deve essere stato riletto utilizzando la fonte cartacea; sulla base di questa definizione possediamo ora testi non proofread ma EW (v. lista cassettatta), e ciò non giova per niente. Direi di votare e argomentare.--Erasmo Barresi (disc.) 14:36, 15 dic 2011 (CET)[rispondi]

Lista ricavata incrociando Testi senza versione cartacea a fronte e Testi Edizioni Wikisource

Nessuna pagina soddisfa i criteri di selezione.

Un testo non proofread può passare al SAL 100%? modifica

  • No. Un testo deve essere non solo riletto ma anche rileggibile: chiunque deve poterne verificare l'aderenza alla fonte.--Erasmo Barresi (disc.) 14:36, 15 dic 2011 (CET)[rispondi]
  • Dipende. Io so per certo che alcuni testi a EW che abbiamo (es. le preghiere cristiane) sono stati riletti correttamente, e se passarli da EW a 100% non mi fa nè caldo nè freddo, il ripassarli al 75% mi appare un po' esagerato, tanto più che non abbiamo la possibilità di scansionare la fonte e averli in versione proofread. E questo secondo me è cruciale (la disponibilità, anche teorica, di versione proofread). Aubrey McFato 15:00, 15 dic 2011 (CET)[rispondi]
Ritengo molto improbabile che un testo PD sia stato pubblicato solo pochi anni fa e quindi su un libro (o altro) non scansionabile. Considera il Confesso: l'edizione indicata nell'infotesto risale al 1994, ma è una preghiera molto antica (originariamente in latino) quindi quasi certamente esiste una traduzione scansionabile in italiano, anche non uguale alla versione in uso attualmente. Chi cerca trova.--Erasmo Barresi (disc.) 14:39, 16 dic 2011 (CET)[rispondi]
  • Dipende. Sono anch'io possibilista, come Aubrey. Se c'è una fonte cartacea indicata nell'infotesto, e c'è segnato come rilettore un utente che abbia già dato buona prova di sè, credo che dovremmo continuare a fidarci. Ho dato comunque una rapida occhiata alla lista, e ho trovato parecchi testi che hanno segnato GoogleBooks come fonte, dunque molti si possono rendere proofread. Vale ciò che ho già detto per il SAL 100%: intanto cerchiamo di migrare sempre più testi verso il proofread; quando saranno rimasti solo una manciata di testi di cui proprio non si possono avere le scansioni, decideremo che farne. Per i nuovi testi invece propongo la seguente politica: « L'inserimento di nuovi testi non corredati da scansione a fronte è permesso anche se sconsigliato; in ogni caso tali testi non possono andare oltre il livello SAL 75%. » Candalùa (disc.) 23:41, 15 dic 2011 (CET)[rispondi]
Gestendo Wikisource credo che non si possa distinguere tra testi "vecchi" (inseriti prima dell'avvento dell'estensione ProofredPage) e "nuovi": qualsiasi decisione li deve riguardare entrambi. Di certo qualcuno per rileggere un testo ha impiegato molto tempo e fatica, e non gradirà veder vanificato il proprio lavoro; ma la definizione di "rilettura" è cambiata. Nel frattempo, cerchiamo senza dubbio di migrare sempre più testi al proofread (vedi).--Erasmo Barresi (disc.) 14:39, 16 dic 2011 (CET)[rispondi]
Forse non mi ero spiegato bene: per "vecchi" intendo tutti i testi presenti in questo momento (inseriti sia prima che dopo l'arrivo di ProofredPage); per nuovi quelli creati a partire da ora. I vecchi testi che sono arrivati a 100% o a EW andrebbero migrati per non vanificare la rilettura già fatta, i nuovi non dovrebbero essere riletti se non mediante ProofredPage (altrimenti le due liste continuerebbero a riempirsi man mano che le svuotiamo... :-) Candalùa (disc.) 15:09, 16 dic 2011 (CET)[rispondi]
L'utilità di testi max-75%? Semplicemente avere una biblioteca più vasta e completa possibile. Metti che uno voglia consultare tutti i testi di un dato autore: deve diventar matto a cercarli, perché alcuni sono qui da noi, altri su LiberLiber, altri su OPAL...? No, li può trovare tutti qui da noi; alcuni a Edizioni Wikisource quando è stato possibile, altri a 75% che è sempre meglio che niente. E poi non dimentichiamoci che uno dei nostri punti di forza, che le altre biblioteche digitali non danno, è la fitta rete di citazioni che costruiamo con AutoreCitato e TestoCitato: se noi ripubblichiamo un testo di LiberLiber, non stiamo semplicemente replicando il loro lavoro: gli stiamo dando un valore aggiunto legandolo intimamente agli altri testi della biblioteca. Candalùa (disc.) 15:47, 16 dic 2011 (CET)[rispondi]
  • No. Sono anch'io d'accordo: è giunto il momento di non accettare testi che non abbiano una fonte (immagine delle pagine originali) consultabile da ciascun rilettore. Se c'è una fonte consultabile da ciascun rilettore, vuol dire che la fonte dev'essere sul web e implicitamente è pubblica; se c'è sul web ed è pubblica, se ne può ricavare un djvu e ripubbicarlo su Commons. L'alternativa richiederebbe che anche il rilettore avesse accesso fisico al testo cartaceo originale per tutto il tempo necessario alla rilettura (cosa talmente improbabile, in un libro antico, da essere un'evenienza trascurabile). Resta il caso dei libri virtuali già pubblicati con licenza libera sul web ma ha senso ripubblicarli anche qui, se sono già pubblicati sul web? Mi sembra che IA, Google, OPAL ci diano già abbastanza opportunità di lavoro per i prossimi mille anni. --Alex brollo (disc.) 09:18, 16 dic 2011 (CET)[rispondi]
  • NO condizionato. - Narro, da piccola esperienza personale che però può essere (ed è già) patrimonio anche di altri:
    "In quel tempo, alcune persone avevano donato a Wikisource opere da loro scritte ma rese libere con tagliando. Quelle persone mantenevano il diritto sul testo ma avevano problemi sulle immagini e addirittura sull'impaginazione dei loro testi in quanto, essa impaginazione, non mera pagina stampata era, ma dotata di lavoro editoriale terziario. Ed allora quelle persone si rivolsero a Egli ed Egli disse: "Del tuo testo, per effetto della legge, puoi farne ciò più ti aggrada. Ma non pubblicherai immagini all'infuori di alcune. E soprattutto non pubblicherai le immagini che sono di mia proprietà nei secoli dei secoli". E allora quelle persone (fra cui -soprattutto- il sottoscritto) non ebbero le pagine prufridded e furono gettate là dove è pianto e stridore di freni ferroviari".
    Orbene, ricordi il poeta, sappia l'inclita e sia noto all'incolto che il No in neretto all'accettazione di testi non prufridabili porterà all'impossibilità di alcuni di offrire al popolo assetato l'acqua dello spirito.
    Augh, ho detto! Silvio Gallio (disc.) 15:31, 16 dic 2011 (CET)[rispondi]
La domanda non era: "i testi non proofread possono essere inseriti?" (anche se prima o poi discuteremo anche di quello), ma "possono passare al SAL 100%?".--Erasmo Barresi (disc.) 16:14, 17 dic 2011 (CET)[rispondi]

Stiamo diventando come i tedeschi :-)
Ci sono un paio di questioni correlate ma autonome in basso:

  • Questione 1: accettiamo d'ora in poi solo testi con scansione a fronte? E' una scelta importante.
  • Questione 2: un testo non proofread può raggiungere il 100%? Stavamo parlando di quello.

Ora, discutiamone così che andiamo bene. Io direi di sì alla questione 1 solo dopo aver analizzato tutti i pro e contro (e uno di questi è quello che dice Silvio: ci precludiamo un sacco di testi scientifici, di riviste ecc., in questo modo), e solo con un buon consenso della comunità (ma già c'è...) sul recupero del pregresso. Non è cosa da poco, e se diciamo una cosa dobbiamo cercare di usare il M&S (con buonsenso, altrimenti facciamo come altri progetti che buttano via dei buoni testi, magari riletti 4 volte fra Gutemberg e Wikisource, per brutte e scadenti versioni scansionate...). Aubrey McFato 15:37, 16 dic 2011 (CET)[rispondi]

Sentire la necessità di regolarizzare dei testi SAL 100% senza testo a fronte, è, per me, un segnale evidente di un lento ma progressivo cambio di atteggiamento e di metodo nei confronti della biblioteca. Contributori diversi, sia per esperienza che per qualità di lavoro sul progetto, trovano un sentiero comune, anche a distanza di tempo, dimostrando inequivocabilmente che dall'esterno la nostra piattaforma è vista come un sistema binario: una trascrizione è necessariamente accompagnata dalla sua immagine. Dal pov mediatico è quello che suggeriamo più o meno ogni mese su pedia, con la rilettura del momento: una bella immagine di copertina accompagna l'invito a collaborare con NOI. Si rafforza, in questo modo, la credibilità del progetto, granitica per l'oggettiva certezza della FONTE. La questione del grigiume in cui navigano molti testi, dove possiamo incontrare situazioni simili a quelle descritte da Silvio o da Aubrey, possono trovare accordo valutando nel merito ogni singolo caso. Non sarebbe la prima volta che adottiamo deroghe per inserire alcuni testi anomali, (vedere progetto TESI). Coerentemente con questo approccio, si può, di volta in volta, stabilire un ambito specifico in cui un responsabile del progetto gestisce questo tipo di testo senza scansione. Mi sembra, però, altrettanto doveroso applicare la regola generale in modo retroattivo e normalizzare gli attuali testi sal 100% senza fonte cartacea. A differenza di Candalua, ritengo, senza indugi, molto più importante la qualità del nostro SAL che la quantità dei testi fruibili. Una volta ci bastava il discorso dei link a tutto il pianeta trascrivibile, oggi siamo molto più interessati alla certezza di quei link e alla possibilità di far dialogare virtualemente testi reali e non ipotetici. Noi non siamo più quelli che linkano i pdf o i txt di liberliber tra loro, ma quelli che creano un filo indissolubile tra testi reali che si trovano a Toronto, New York, Parigi, Monaco o Torino ecc. Prefisco una biblioteca riconosciuta internazionalmente per questi indiscutibili valori. --Xavier121 13:13, 17 dic 2011 (CET)[rispondi]

Posso cortesemente dissentire?
Più che "tedeschi" stiamo diventando - peggio! - "Commonari"!

  • Non vedo nessun motivo per cui si debba accettare solo testi a fronte. Se la tanto amata fonte è ben segnalata (e di solito lo è - in "Discussione" - no?) il pignolo che voglia controllare la trova. Quasi altrettanto comoda. E se trova qualche discrepanza e non lo fa lui, saremo ben felici di intervenire. Altri progetti ben più famosi del nostro mettono il testo in rete senza nemmeno dirti dove lo hanno trovato. Nemmeno un link. Ti 'devi' fidare. Loro non si pongono il problema. Noi si. Ma arrivare all'ablazione dell'"apparato centrale" mi sembra in tantinello autolesionista; eccessivo.
  • Leggermente diverso il caso di un testo senza fonte o con fonte "irragiungibile". Qui, però, si potrebbe inserire un piccolo (piccolo) template di avviso come disclaimer sull'affidabilità. Qualcuno può percepirlo come una carenza (e in parte lo è) ma io lo giudicherei una forma di serietà: "Questo è quello che abbiamo, spiacenti di non poter - per ora- fare di più, sappiti regolare".
  • Ancora sono perplesso sul "significato" di 100% e di Edizone Wikisource. Non so se sia possibile ma vedrei bene una ridefinizione perché, parmi, si sta verificando un accavallamento. 0%, 25%, 75% mi vanno bene per opere in corso di lavorazione oppure terminate ma senza fonte. Il 100% lo assegnerei a opere rilette, non (ancora) proofread ma con fonte segnalata e velocemente raggiungibile (guggol, I.A. ecc), Stellina solo per il testo proofread, terminato e mummificato. Se poi scopriamo qualche altra maniera per farci del male possiamo aggiungere stelline. (es. due stelline per testo a fronte scansionato in 16 milioni di colori, tre stelline con testo a 16 Mio colori e tirato a cera d'api; quattro stelline per testo 16 Mio colori, cera e allegato pupazzetto in peluche).
  • Tutto raggiungibile per gradi senza rompersi il cuoio capelluto o farsi venire l'asma.
  • Il pregresso è, appunto, pregresso. Una volta fissato un obiettivo, con calma si cerca di raggiungerlo. È quello che, a mio modestissimo avviso, suggerisce Candalùa con questa chiacchierata. Silvio Gallio (disc.) 14:42, 17 dic 2011 (CET)[rispondi]
Quindi, tralasciando il pupazzetto in peluche (carina l'idea però), prima di rispondere alla domanda di questa sezione, dobbiamo ridefinire con esattezza i significati dei vari livelli di SAL, se ho capito bene, giusto Silvio? --Lagrande (disc.) 10:16, 18 dic 2011 (CET)[rispondi]
Probabilmente quanto ho scritto deriva da una mia mancanza di comprendonio. E tutta la faccenda SAL da un sovrapporsi di stratificazioni decisionali. Epperò trovo inusuale (anche se non mi ha fatto venire l'itterizia) vedere "ed. Wiki" per testi non proofread. Lo percepisco come un incrocicchiamento. Le mie modeste idee le ho scritte sopra. Poi se ci sono controindicazioni a livello software internazionale, beh... mi adeguo, as usual. Silvio Gallio (disc.) 10:52, 18 dic 2011 (CET) (P.S.) Già che ci sono. trovo piuttosto ridondante e irritante, per i testi proofread e stellinati, che rimanga il templatino con i reticoletti verdi in alto, sopra il testo. Capisco quando l'editing non è terminato; ma quando un testo è stato lavorato fino in fondo si potrebbe togliere, no? Questione di gusti, naturalmente. Silvio Gallio (disc.) 11:54, 18 dic 2011 (CET)[rispondi]

Nuovo prototipo di toolbar modifica

Guardate e giocate (è un prototipo, gli serve feedback). Ma la parte a destra mi pare piena di possibilità. Sono carichissimo. --Aubrey McFato 17:33, 14 dic 2011 (CET)[rispondi]

Sono sicura che la domanda è idiota, ma si possono mettere anche le faccine? --Lagrande (disc.) 17:49, 14 dic 2011 (CET)[rispondi]
WOW!!! Finalmente qualcuno ci ha pensato! Vedete anche http://www.mediawiki.org/wiki/Visual_editor Candalùa (disc.) 18:28, 14 dic 2011 (CET)[rispondi]
Tutto ciò è al contempo esaltante e preoccupante: da una parte l'interfaccia di modifica si avvicina a quelle già disponibili in Wordpress e altri forum, con un plus di immediatezza da programma di videoscrittura; dall'altra la domanda sulle "faccine" (dubito che nessuno abbia inventato uno script per aggiungerle alle attuali toolbar) mi dà da pensare che tale modernizzazione, allontanando l'interfaccia dalla seriosità dell'attuale impostazione concorrerà a far confondere i progetti Wikimedia con altri social networks e simili... teniamoci aggiornati senza perdere di vista la peculiarità dei nostri progetti. - εΔω 18:58, 14 dic 2011 (CET)[rispondi]
Non preoccuparti Edo, non intendo infarcire Aristofane di faccine ... pensavo solo a pagine di discussione, come questa appunto. Del resto, se è accettabile scrivere così ":)" che differenza fa? --Lagrande (disc.) 20:37, 14 dic 2011 (CET)[rispondi]
Molto buonissimo. Se riesce anche a bottonizzare i vari comandi wiki (magari con i "toggle a barra comandi wiki") lo faccio sposare con Alex. :P --Silvio Gallio (disc.) 21:21, 14 dic 2011 (CET)[rispondi]
Stupefacente. Però Silvio vede bene: l'interfaccia agevola le correzioni manuali, ma.... la confusione che faccio è proprio per ridurre le correzioni manuali al minimo necessario. Temo che l'implementazione delle correzioni automatiche venga resa molto più difficile; devo assolutamente capire se è vero o no... se questo sistema permetterà una implementazione sempliche di richiami a script vari, allora è un matrimonio che s'ha da fare.
do un'occhiatina a cosa ci sta dietro con una console js... --Alex brollo (disc.) 21:45, 14 dic 2011 (CET)[rispondi]
Lagrande, può darsi che questa volta mettano toolbar diverse per pagine diverse, per esempio potrebbero mettere le faccine nelle pagine di discussione. In realtà, potresti segnalarglielo, non mi pare una cattiva idea. Aubrey 23:47, 14 dic 2011 (CET)[rispondi]
L'organizzazione della pagina di prova è complicatuccia (e si vede dalla lentezza di risposta in edit). Il testo è suddiviso in una gerarchia di div inscatolate, l'ultimo livello è la singola riga di testo. Non ho assolutamente capito come da questa struttura si passa a un normale wikitesto (quello che viene spedito al server per la memorizzazione) nè come tale wikitesto sia fatto, nè se "resti in sottofondo" e se sia possibile modificarlo direttamente via js "vedendo" le modifiche nel testo trasformato editabile. Insomma non ci ho capito una mazza.... --Alex brollo (disc.) 09:49, 15 dic 2011 (CET)[rispondi]
Volevo solo ricordare che si parla comunque del giugno 2012 per una implementazione. Adesso vogliono solo feedback. diamoglieli, no? Aubrey McFato 10:57, 15 dic 2011 (CET)[rispondi]
Questo (http://www.mediawiki.org/wiki/Visual_editor/Software_design) spiega come funziona il "software". Credo anche io che sia piuttosto "fitto". Sicuramente questo nuovo editor farà arrivare nuovi utenti nelle Wiki e, altrettanto sicuramente, si potrà modificare il testo ancora più facilmente attraverso javascript e JQuery, perchè la struttura è piuttosto fitta di div annidati, ma proprio grazie al gran numero di div si potranno creare altrettanti "ganci" ai quali appendersi per far eseguire funzioni e automazioni. Causerà gravi problemi a tutti gli accorgimenti che finora abbiamo creato ma, credo, che se saremo in grado di adattarci potremo ricavarci delle cose molto interessanti. 79.10.177.14 16:35, 15 dic 2011 (CET) Scusate, ero sloggato, ma non me ne ero accorto... Samuele 16:39, 15 dic 2011 (CET)[rispondi]
Il mio dovere l'ho fatto, ho sollevato il problema dellì'implementazione di "contenitori di tool js semplici" e nominato (il lista mail) il RegexMenuFramework di Pathoschild come "oggetto" che sarebbe bello potesse essere implementato con la stessa facilità con cui abbiamo lavorato qui. Io sono la dimostrazione vivente che un principiante può fare delle cose utili, personalizzabili, senza fare una trafila burocratica per interpellare un esperto (vero)... se poi sul tutto vigila attentamente un Candalua con una bacchetta, meglio. --Alex brollo (disc.) 18:56, 15 dic 2011 (CET)[rispondi]

Trilemma djvu modifica

Chiarito che trilemma è un dilemma peggiorato (tre alternative...) e in attesa che si coaguli un gruppetto di "specialisti nella grafica djvu", ho trattato "Opere scelte di Ugo Foscolo", fonte OPAL, opera in due grossi volumi di oltre 400 pagine, e ho provato a realizzare diversi djvu:

  1. minimale, bianco e nero: circa 5 megabyte per volume, simile agli scan di Google
  2. multistrato compresso a colori: circa 15 megabyte e resa non eccellente
  3. monostrato, qualità "fotografica": a piena risoluzione, mostro di 60 megabyte; riducendo la risoluzione a 150 pixel, lieve deterioramento dell'immagine (per me accettabile) ma risultano comunque 30 megabyte.

La grandezza del file djvu, suppongo, si riflette (oltre che sull'occupazione di spazio su Commons) sulla lentezza di caricamento delle immagini in fase di edit. Quindi, è una qualità grafica che "si paga", oltre all'aumento del consumo di banda utilizzata (che costa) ecc. Per come sono fatto io, sceglierei senza esitazione la risoluzione minimale da 5 megabyte, ma la grafica non deve piacere solo a me: deve piacere a tutti e impatta, certamente, sull'"immagine" di wikisource.

Ultimo problema. FineReader non è molto efficiente nel costruire i file djvu, l'ideale sarebbe utilizzare "il meglio che c'è", ossia programmi dedicati per costruire un djvu ideale (eccellente come grafica e pure ben compresso), e poi "montargli dentro" lo strato testo prodotto da FineReader. Si può fare, ma il lavoro diventa in due passi invece che in un passo solo. Che fare? --Alex brollo (disc.) 09:44, 15 dic 2011 (CET)[rispondi]

Sul primo quesito: io direi la versione più pesante, ma migliore. Vero che la banda costa ecc., ma direi che source sota un decimilionesimo di quello che costa Wikipedia o Commons alla Foundation. Non mi fascerei la testa per un singolo file djvu. Per il secondo quesito, è a buon senso: se ritieni che valga la pena fare due passaggi, falli pure, ma credo che un minimo di approssimazione non ci faccia male se ci guadagnamo in velocità e soprattutto facilità: se tu Alex, che già sei l'unico operatore FR11, ti aggiungi del lavoro da solo secondo me non è una grande idea. Fai il djvu con FR e amen. --Aubrey McFato 11:02, 15 dic 2011 (CET)[rispondi]
Come disse Garibaldi: obbedisco. L'unico rischio è di violare qualche suggerimento o qualche linea guida wikisourciana sconosciuta facendo la figura dei "soliti italiani" (chi scorribanda in irc con agio, magari una cauta indagine potrebbe farla). Comunque l'idea dei "due passi" per me non è significativamente più pesante di quella "in un passo solo", purchè altri facciano il passo 1 (assemblamento di un eccellente djvu senza layer testo), quindi, chi ha piacere e sa farlo lo facci, poi mi passa il djvu e io faccio "il trapianto"), già sperimentato su alcuni lavori di Aubrei (Rivista di Scienza e Scentia). --Alex brollo (disc.) 14:45, 15 dic 2011 (CET)[rispondi]

BibliotecaItaliana modifica

http://www.bibliotecaitaliana.it/, che risultava inattivo da qualche mese, è di nuovo attivo con il seguente avviso:

 
«Biblioteca Italiana è in fase di aggiornamento e ristrutturazione.

La nuova versione del sito, modificata nell’architettura di insieme

e con un consistente incremento di dati, sarà consultabile a partire dal marzo 2012.»

Ora, da informatico mi sembra inconcepibile che per aggiornare e ristrutturare si debba per forza chiudere baracca per mesi e mesi, manco fosse una biblioteca fisica con i muratori che lavorano. Ma se non altro la buona notizia è che dovrebbero riaprire a breve, e con maggiori contenuti. Candalùa (disc.) 13:03, 15 dic 2011 (CET)[rispondi]

Guarda, lasciamo perdere: da quello che so io, la cosa è gestita veramente male (e da persone con non sanno bene come si fanno queste cose). Si spera che cambi completamente... --Aubrey McFato 13:50, 15 dic 2011 (CET)[rispondi]

Biblioteca chiude modifica

Come Wikimedia Italia, abbiamo deciso di dare una pulita e una congelata a Biblioteca. Stiamo cercando di trasferire i contenuti adatti su Wikilivres, progetto multilingue tenuto in Canada. C'è da decidere, come wikisourciani (Lagrande, Alex, parlo con voi) cosa fare di alcuni testi a cui abbiamo lavorato: leggere e commentate. --Aubrey McFato 23:08, 15 dic 2011 (CET)[rispondi]

Per me puoi ripulire Aubrey, ma bisogna sentire Alex, l'idea era sua. Mi ero completamente dimenticata di quel testo ... --Lagrande (disc.) 07:36, 16 dic 2011 (CET)[rispondi]
Il mio tempo per le traduzioni è "andato".... Se posso scaricherò e fine. --Alex brollo (disc.) 08:37, 16 dic 2011 (CET)[rispondi]

Ho trovato La pedagogia che è attualmente oscurato perché PD in Italia ma non in USA. Si può spostare a Wikilivres? Candalùa (disc.) 14:01, 18 dic 2011 (CET)[rispondi]

Dimissioni da amministratore modifica

Come anticipato qualche settimana fa, mi sono dimesso da amministratore.

Vorrei ringraziare la comunità per la fiducia accordatami nel lontano dicembre 2007 e chiedere a tutti scusa se in questi 4 anni il mio comportamento è stato in qualche occasione inadatto a quello di un amministratore, mi rimprovero qualche discussione troppo vivace e un'attività di syspop che avrei voluto più frequente.

Il mio interesse e il mio impegno nel progetto come semplice utente rimangono immutati e cercherò di contribuire al mio meglio, nei limiti del poco tempo disponibile. --Accurimbono (disc) 11:20, 16 dic 2011 (CET)[rispondi]

Mi spiace di perdere un "collega"; se sono dimissioni irrevocabili, non mi resta che ringraziarti del tuo lavoro (passato, presente... e futuro ;-) ). --Alex brollo (disc.) 11:59, 16 dic 2011 (CET)[rispondi]
Anche a me, spero però di poterti recuperare come semplice utente per lavorare un po' a questo testo. A presto, Curi! :) --Xavier121 13:11, 16 dic 2011 (CET)[rispondi]
Peccato, ma almeno non te ne vai, e questo è abbastanza. Per quel che mi riguarda, alla fine sono solo tastini :-) --Aubrey McFato 14:48, 16 dic 2011 (CET)[rispondi]
Mi associo al composto disappunto per la decisione, peraltro legittima e comprensibile. Siccome peraltro ti ho visto all'opera anche ultimamente con certosina puntigliosità sono certo che non mancherai di tenerci compagnia anche con i tuoi pareri franchi quanto basta per mettere in discussione quel che agli altri appare troppo scontato.
Infine non dispero che prima o poi ti torni la voglia o il tempo di aiutarci nell'ordinaria attività di sysop... intanto ti prenoto come rilettore per Antonio Abati.
A proposito di sysop... lancio un invito a tutti i sysop attivi a darmi una mano a fare piazza pulita di centinaia e centinaia di discussioni di pagine cancellate accumulatesi nel corso degli ultimi due anni. - εΔω 20:38, 16 dic 2011 (CET)[rispondi]
Grazie a tutti.
Le mie priorità personali sono completare le trascrizioni di Brandimarte e Cimarelli (che essendo completamente manuali, visto che l'OCR non funziona, si sono rivelate più impegnative del previsto).
Le mie priorità comunitarie sono l'aggiornamento continuo delle ricorrenze (in prima persona e attraverso la sensibilizzazione di altri utenti). Ovviamente compatibilmente con il poco tempo che ho a disposizione in questo periodo.
I miei pareri franchi continuerò a darli, ma mi rendo conto che nei sistemi Wiki chi più edita più comanda, quindi visto che non ho tempo non posso che incidere limitatamente sul progetto. --Accurimbono (disc) 15:13, 18 dic 2011 (CET)[rispondi]

Pagina principale modifica

Ho lanciato (entro fine anno, come promesso) il mio modello di pagina principale, che ho inserito nella talk della sandbox, da non intendere come talk: Discussioni utente:Erasmo Barresi/Sandbox: Pagina principale/Sandbox. Tre note, anzi quattro:

  • Sarebbe grandioso poter mettere "Benvenuti in" e "Wikisource" alla stessa altezza dal basso.
  • Ho messo "In evidenza" e "Ricorrenze" in un unico riquadro "Testi e autori", per non averne più di sette.
  • Tale riquadro non prevede uno switch tra alcuni testi scelti in un dato momento, perché così si corre il rischio che vi siano solo testi vecchi. Il testo sarà invece inserito con una cadenza regolare (10 giorni?), scegliendolo tra i più recenti e interessanti.
  • La spiegazione razionale dello stile "arcobaleno" della pagina è la seguente: nella colonna di sinistra si sono i colori primari; a ognuno di essi corrisponde nell'altra colonna il colore secondario che il primario non contribuisce a creare; il marrone del riquadro in basso li miscela tutti. Spero che i colori non dispiacciano a nessuno.

--Erasmo Barresi (disc.) 20:37, 18 dic 2011 (CET)[rispondi]

Mi piace; ma noto un contrasto cromatico fra il colore pastello del primo box principale e i colori accesi e vivi delle barre dei box secondari. Mi sembra che si mescolino due diversi stili. Se la logica (non intuitiva, quindi, secondo me, non essenziale) della scelta dei colori lo permettesse, ai due colori rosso e verde delle barre box in primo piano ci aggiungerei un bianco e ci sarebbero, a colpo d'occhio ma "come per caso", i colori della bandiera. --Alex brollo (disc.) 10:23, 19 dic 2011 (CET)[rispondi]
La pagina mi pare fatta bene, grazie per la fatica! mentre me la guardo per bene, segnalo che anche secondo me i colori sono, non brutti, ma troppo forti. Io li "pastellerei" un po', se possibile, dato che il contrasto è evidente. Inoltre, per la Wikiguida, nonostante così sia visibile a tutti, penso che una delle soluzioni migliori sia questa: un template (quello davvero un po' nascosto), ma che fa vedere la Guida in tutto il suo splendore. inoltre, per gli ultimi arrivi proverei a usare DynamicPageList (se non la usi già) --Aubrey McFato 11:13, 19 dic 2011 (CET)[rispondi]

Colori sostituiti:

  • green 008000 con seagreen 2e8b57
  • orange ffa500 con coral ff7f50
  • mediumorchid ba55d3 con plum dda0dd

@Alex: il bianco sarà già colore di sfondo (anzi sposto la prova in Pagina principale/Sandbox per vederla senza il colore di sfondo delle talk). Inoltre da quando conosco il progetto la bandiera è sempre stata in cima alla pagina.
@Aubrey: lo chiamiamo {{Videoguida}}? Ma a questo punto rimarrebbe un box disponibile: per cosa lo usiamo?--Erasmo Barresi (disc.) 17:29, 19 dic 2011 (CET)[rispondi]

I colori non sono un po'....(passatemi il termine)..brutti? Il verde va bene e anche altri, niente da ridire, ma il rosso acceso e il blu profondo, che rende illeggibile il nero, si possono cambiare? Probabilmente avevi già intenzione di cambiarli e questo ti offenderà, spero di no. Interpreta nel modo più clemente possibile la mia osservazione. Samuele 17:35, 19 dic 2011 (CET)[rispondi]

Condivido le perplessità sui colori, ho sperimentato personalmente, essendoci passato, che lo stile "Arlecchino" in genere appare molto bello a chi lo ha fatto... ma un pugno nell'occhio a tutti gli altri :-) Vedrei molto meglio uno stile simile all'attuale, con un colore di base e un colore secondario. Al limite io metterei in evidenza 1-2 box facendoli di un colore più acceso; il rosso e il verde può essere una buona idea, su pedia ci sono anche le tonalità precise precise. Però non darei per forza ad ogni box un colore diverso... Candalùa (disc.) 17:49, 19 dic 2011 (CET)[rispondi]

sarò brusco: lo schema dei colori proposto è a mio parere improponibile. Vada per la variazione, ma quanto scritto da Candalua è sacrosanto (lui non lo sa ma ritengo la pagina principale di vec.source "molto ardita", figuriamoci quella proposta qui sopra). Dato che sono a disposizione quattro template colore per bordi e sfondi, la mia idea sarebbe quella di giocare su viraggi coerenti verso colori simili (oggi sono i colori del logo che ruotano tra blu azzurro e grigio, magari domani potranno ruotare intorno ai colori del logo Wikimedia, o intorno a tinte pastello chiare). Ricordo che i colori hanno un loro impatto comunicativo, e che ogni combinazione dovrà prevedere la presenza di immagini e contenuti dai colori non sempre prevedibili. - εΔω 20:01, 19 dic 2011 (CET)[rispondi]

OK, non avevo previsto il pugno nell'occhio :-) Ma una proposta è una proposta, non può essere improponibile. E comunque ho cercato di essere... ehm... originale. A ricopiare il layout attuale sono bravi tutti.--Erasmo Barresi (disc.) 22:05, 19 dic 2011 (CET)[rispondi]

Il mio contributo per migliorare la Pagina principale: Io vedo 3 problemi principali nella bozza (e anche nella nostra attuale pagina principale):
1) I colori. Soluzione proposta: utilizzare ad esempio queste combinazioni di colori che ho or ora visto su Diaspora. Sarebbe bello far girare randomicamente molte combinazioni di colori (tutte ben abbinate).
2) Troppi spazi vuoti: lo spazio è prezioso e credo che si debba limitare al massimo lo spazio vuoto, aumentando la densità di informazioni.
3) Poca navigabilità: abbiamo un sacco di testi ma non sono accessibili se non tramite la ricerca. Io valorizzerei di più i box Indici e Biblioteca, portandoli in alto, e sposterei in basso gli altri.
La prima pagina è il punto di approdo dell'utente alle prime armi, dovremmo studiare la pagina principale con in mente l'obiettivo di farlo entrare nel progetto prima che se ne vada. --Accurimbono (disc) 15:46, 20 dic 2011 (CET)[rispondi]
Grande Accurimbono, i tuoi spunti sono fantastici! Come ideatore dell'attuale layout e giusto per mettere un po' di peperoncino nel rinnovo provo a spiegare le mie scelte:
1) Per i colori io sarei molto attento ed eviterei schemi multipli: è un dato ormai acclarato che uno schema di colori collega molto fortemente l'utente al prodotto, e ci sono prodotti che hanno fatto di un colore o di uno schema di colori la propria bandiera. Io ho avuto gioco fin troppo facile a mutuare i colori dal logo e a voler essere pedanti i colori potrebero anche rimanere gli stessi di ora, ma sono ben aperto a variazioni purché la loro combinazione sia efficace.
2) Il padding e le marginature tra i box li ho cercati proprio come li vedete. Il principio che soggiace a tale scelta è che testo e immagini debbano "respirare" piuttosto che concentrarsi e soffocarsi a vicenda. È un principio che però calato nella realtà presuppone schermi generosi e risoluzioni "moderne", mentre non mancano certo casi di portali e pagine ad alto traffico con contenuti affollati (penso alle testate online o a noti siti ci commercio e aste). Penso che ispirarsi alle home page progettate dai professionisti sia la soluzione migliore. aggiungo che con la skin Vector una porzione di schermo è "mangiata" dalla sidebar, dal logo e dalle linguette dei comandi: non si può prescindere dalla loro presenza
3) La disposizione di testo e immagini è a mio parere un punto molto importante e su cui ammetto che non mi sento a mio agio: le mie idee estetiche sono partite dall'impostazione del Portale:Autori per poi passare ad altri portali e infine alla pagina principale. Io ho un'ottica più "visiva" e basata su immagini che su liste di link testuali, e ho cercato l'armonia tra i due elementi a scapito dell'abbondanza di link (la pagina principale di en.source mi ha confermato in questo principio dato che il loro attuale layout è successiv ai miei esperrimenti con i portali).
Non ritengo certo di aver ottenuto il miglior risultato e non desidero imporre un mio POV su quello altrui. Spero che queste spiegazioni siano di aiuto per migliorare la prossima Pagina principale, siano esse seguite o disattese. Da questo dedurrete che non vorrei intervenire troppo spesso sui lavori di Erasmo o di altri fidandomi del (con)senso estetico della comunità. εΔω 17:36, 20 dic 2011 (CET)[rispondi]
Che ne dite di una revisione della Biblioteca, sostituendo i link con delle immagini? Sicuramente renderebbe la navigazione più facile per gli utenti ma soprattutto, li invoglierebbe ad utilizzare la biblioteca. Mi rendo conto che trovare un'immagine per ogni categoria è difficile, ma sicuramente non è impossibile (qualcuna la potremmo creare anche noi).
Sono d'accordo con l'utilizzo degli stessi colori. Non sono orribili e, soprattutto, rappresentano ormai una standard di riconoscimento per Wikisource, così che l'utente, quando entri, si trovi in un ambiente famigliare.
Provo a fare qualcosina qui. Sicuramente verrà fuori qualcosa di migliore. Il lavoro di gruppo e la discussione fa sempre bene. Samuele 18:26, 20 dic 2011 (CET)[rispondi]

È vero che un colore è come un segno di riconoscimento, ma qui non dobbiamo vendere nulla! Consideriamo la pagina principale di en.pedia: in essa sono usati 4 colori

  • il logo e la testata sono grigi
  • la colonna di sx è verde
  • la colonna di destra è blu
  • il box largo in basso è viola

Credo che, al di là degli 8 colori che ho usato io, non dispiaccia usarne 4. Nel nostro caso potrebbero essere rispettivamente blu, rosso (?), verde (?) e marrone (?), ma possiamo naturalmente decidere di cambiarli (rosso e verde ricordano la bandiera, il marrone fa pensare agli scaffali di una biblioteca). Bisogna constatare che un solo colore (e sue gradazioni) usato per tutti i box concilia il sonno e ciò credo allontani lo spaesato visitatore. Sia chiaro che potrebbe rimanere così com'è, ma io continuo a provare (con le combinazioni proposte qui: [2] [3], ma forse è venuto troppo chiaro) perché altrimenti il senso del rinnovo si perde.
Ho cercato di eliminare gli spazi tra riquadri, però ora essi sembrano "spiaccicati" uno sull'altro.
OK per la "Biblioteca" più in alto e per la possibilità di usare immagini, ma credo che le scritte andrebbero mantenute.--Erasmo Barresi (disc.) 21:42, 20 dic 2011 (CET)[rispondi]

Giusto per chiarire: io non criticavo lo spazio _tra_ i riquadri che va benissimo com'è, ma lo spazio vuoto _nei_ riquadri. Ad esempio: il primo riquadro con il benvenuto e l'immagine dell'amanuense (che BTW io toglierei subito) ha tutto uno spazio vuoto che occupa gran parte della prima schermata... io toglierei l'immagine, abbasserei il riquadro e lo riempirei di contenuti di navigazione. --Accurimbono (disc) 10:31, 21 dic 2011 (CET)[rispondi]

Avviso a chi usa "Strumenti per la rilettura" modifica

A chi usa Strumenti per la rilettura, e osa pure sistemare i suoi datiPagina: ho un'idea, ne parliamo in bar tecnico per non annoiare quelli che non osano ancora. Ci vediamo di là --Alex brollo (disc.) 20:42, 18 dic 2011 (CET)[rispondi]

Avviso generale per smanettoni: il problema precedente richiede di gestire cookies. Se qualcuno ha qualche problema adatto a essere gestito via cookie, questo è il momento; l'unione fa la forza...--Alex brollo (disc.) 10:17, 19 dic 2011 (CET)[rispondi]

Approfitto per segnalare che c'è anche un nuovo strumento: "Trova & Sostituisci" (ero stufo di tagliare-incollare il testo sul notepad solo per fare una banale sostituzione di testo...) Candalùa (disc.) 10:31, 19 dic 2011 (CET)[rispondi]

Magnifico. I due progetti si embricano: occorre che la regex interattiva di trova & sostituisci sia accodata alle regex di datiPagine (sarà meglio rivedere, così com'è non mi piace, meglio strutturarla in una lista di coppie trova/sostituisci) e sia "ricordata" dal futuro cookie. Sempre? talora? Ci penseremo. --Alex brollo (disc.) 11:12, 19 dic 2011 (CET)[rispondi]
Due commenti su trova e sostituisci:
  1. bello sarebbe se il box si aprisse come div fixed;
  2. occhio a chi lo usa, mi par di capire che trova è sempre considerato un'espressione regex, il che significa che se nella stringa di ricerca c'è uno qualsiasi dei caratteri critici [ \ ^ $ . | ? * + ( ) { } il risultato potrebbe causarvi qualche cefalea. Utente avvisato, mezzo salvato. :-) --Alex brollo (disc.) 11:55, 20 dic 2011 (CET)[rispondi]

[OT] Roghi 2011 modifica

Nell’Istituto erano conservati oltre 190mila manoscritti, libri stampati, giornali, mappe e documenti particolarmente preziosi e antichi.

Queste immagini sono veramente tristi. --Accurimbono (disc) 15:14, 20 dic 2011 (CET)[rispondi]

Trucco css3: testo in colonne modifica

Guardate questa cosa carina ottenuta con uno dei millanta trucchi css3 (testo che scorre in due colonne; niente tabelle!)

Lorem ipsum dolor sit amet, consectetuer adipiscing elit, sed diam nonummy nibh euismod tincidunt ut laoreet dolore magna aliquam erat volutpat. Ut wisi enim ad minim veniam, quis nostrud exerci tation ullamcorper suscipit lobortis nisl ut aliquip ex ea commodo consequat. Duis autem vel eum iriure dolor in hendrerit in vulputate velit esse molestie consequat, vel illum dolore eu feugiat nulla facilisis at vero eros et accumsan et iusto odio dignissim qui blandit praesent luptatum zzril delenit augue duis dolore te feugait nulla facilisi. Nam liber tempor cum soluta nobis eleifend option congue nihil imperdiet doming id quod mazim placerat facer possim assum. Typi non habent claritatem insitam; est usus legentis in iis qui facit eorum claritatem. Investigationes demonstraverunt lectores legere me lius quod ii legunt saepius.

Bellino vero? :-) Io lo implementerei in Common.css, ma solo se lo vedere con tutti i browser. Chi non vede il testo diviso in due colonne? --Alex brollo (disc.) 16:43, 20 dic 2011 (CET)[rispondi]

Niente da fare con IE 6, nè IE 7. :-( --193.43.176.29 16:47, 20 dic 2011 (CET)[rispondi]
Dall'ufficio con IE non lo vedo. Poi provo a casa con Firefox. --Lagrande (disc.) 07:42, 21 dic 2011 (CET)[rispondi]
Chrome e Firefox su Linux e Windows vanno bene. --Aubrey McFato 09:12, 21 dic 2011 (CET)[rispondi]
Sembra che la situazione sia quella classica "tutti vedono meno IE". :-(
Che si fa in questi casi, si aspetta pazientemente che Bill si dia una mossa....? --Alex brollo (disc.) 09:28, 21 dic 2011 (CET)[rispondi]
Nemmeno IE8 ce la fa. Questo esclude un buon 25%-30% degli utenti. Dovremo attendere qualche anno, che tutti si mettano al passo :-( Candalùa (disc.) 10:21, 21 dic 2011 (CET)[rispondi]
[Conflittato] Se il problema è solo con IE 6 (2,15%) e 7 (3,59%), io direi di procedere tranquillamente. Invece se il problema riguarda anche IE 8 (20,94%), allora ci penserei. Vedi percentuali su Statcounter. --Accurimbono (disc) 10:23, 21 dic 2011 (CET)[rispondi]
Purtroppo nessuna versione IE sembra supportare la cosa. Esiste un Columnizer JQuery Plugin che aggira l'incompatibilità IE. Che famo? Non mi sembra che sia già caricato di default. --Alex brollo (disc.) 11:02, 21 dic 2011 (CET)[rispondi]

E' così indispensabile? Mi sembra che finora ne abbiamo avuto bisogno solo nel namespace Pagina, dove comunque vogliamo scegliere noi dove mettere l'interruzione di colonna. Candalùa (disc.) 12:39, 21 dic 2011 (CET)[rispondi]

No, non è indispensabile; è solo carino. Ma nemmeno la scelta dei colori pastello dei box progetti o della pagina principale è indispensabile... ;-) --Alex brollo (disc.) 12:52, 21 dic 2011 (CET)[rispondi]
Confermo che da casa con Firefox si vede benissimo. --Lagrande (disc.) 20:35, 21 dic 2011 (CET)[rispondi]
finalmente a casa! i miei test: Win 7 + Chrome = ok; win 7 + I.E.8 aggiornato = una colonna. ciaone di corsa Silvio sloggtato
Lasciao perdere quindi, perlomeno dove la visualizzazione in colonne è essenziale. Al massimo, suggerirei di testarlo là dove non è indispensabile: ad esempio, nelle note a piè di pagina di Bibbia, che talora sono parecchie e che non sarebbe male "compattare" un po' con la doppia colonna. Se poi l'utente IE le vede in una colonna solo, pazienza, non succede niente. Alex brollo (disc.) 16:17, 25 dic 2011 (CET)[rispondi]

Liceo Ginnasio Rosmini modifica

Stanno caricando un bel po' di materiale, tra l'altro caricando qui le immagini nonostante Luigi abbia spiegato loro che è meglio metterle su Commons. Prima che diventi davvero troppa roba, sarebbe bene cominciare a organizzare il tutto e mettere un po' di ordine. Va bene che il loro lavoro con le lapidi storiche è abbastanza particolare, ma non mi sembra accettabile avere pagine come Ponte che contiene solo una foto di un ponte, inutile ed incomprensibile per un lettore medio. Prima che vada là io a prenderli per le orecchie, :-) chi si offre volontario per fare loro da guida e portarli sulla retta via? Candalùa (disc.) 20:26, 20 dic 2011 (CET)[rispondi]

Vorrei inoltre segnalare che le immagini sono prive di licenza, il che rende impossibile trasferirle su Commons se non addirittura candidate per la cancellazione. --Luigi62 (disc.) 21:00, 20 dic 2011 (CET)[rispondi]
Sul fatto che sono senza licenza, secondo me si può fare in fretta con un giro di bottolo... Però andrebbero tutorati davvero, e io mi trovo un po' in difficoltà (sia perchè non ho molto tempo di stargli dietro, sia perchè non ho idea di cosa dirgli. Le lapidi come possiamo gestirle?). --Aubrey McFato 17:27, 21 dic 2011 (CET)[rispondi]
Io ne ho sistemate un paio a titolo d'esempio. Effettivamente ci sono dei problemi riguardo al titolo, come categorizzarle, ecc. --Luigi62 (disc.) 21:17, 21 dic 2011 (CET)[rispondi]

Proprio quando comincio a intravedere un periodo di maggior tranquillità ecco che mi ritrovo con problemi agli occhi. Temo che la già sporadica presenza qui si diraderà ulteriormente. La mia idea sarebbe la seguente: attendere che il lavoro termini e nel contempo tener traccia dei caricamenti (con i registri si può fare abbastanza facilmente). Poi si integrano le immagini caricate nel djvu precedentemente creato, File:Lapidi di Rovereto.djvu e le si presenta in ns0 come sottopagine della raccolta. - εΔω 22:00, 21 dic 2011 (CET)[rispondi]

Magari può interessare qualcuno dei tecnici: Textus. --Aubrey McFato 09:46, 21 dic 2011 (CET)[rispondi]

Molto interessante, da tenere d'occhio per studiare i trucchi, e magari per forme di cooperazione. --Alex brollo (disc.) 14:38, 21 dic 2011 (CET)[rispondi]

Open Call for 2012 Wikimedia Fellowship Applicants modifica

 

I apologize that you are receiving this message in English. Please help translate it.

  • Do you want to help attract new contributors to Wikimedia projects?
  • Do you want to improve retention of our existing editors?
  • Do you want to strengthen our community by diversifying its base and increasing the overall number of excellent participants around the world?

The Wikimedia Foundation is seeking Community Fellows and project ideas for the Community Fellowship Program. A Fellowship is a temporary position at the Wikimedia Foundation in order to work on a specific project or set of projects. Submissions for 2012 are encouraged to focus on the theme of improving editor retention and increasing participation in Wikimedia projects. If interested, please submit a project idea or apply to be a fellow by January 15, 2012. Please visit https://meta.wikimedia.org/wiki/Wikimedia_Fellowships for more information.

Thanks!

--Siko Bouterse, Head of Community Fellowships, Wikimedia Foundation 14:06, 21 dic 2011 (CET)[rispondi]

Distributed via Global message delivery. (Wrong page? Fix here.)

Abbiamo un nostro cookie! modifica

Vi annuncio con malcelata soddisfazione che abbiamo un nostro originale sistema di gestione dei cookie, specifico per pagine Pagina dei singoli libri. Appena terminata l'implementazione (che adesso gira in modalità "prudente"), chi trova comodo editare in sequenza una pagina dopo l'altra le pagine di uno stesso libro potrà memorizzare una serie di informazioni utili (quelle che servono per Strumenti per la rilettura) immediatamente, intanto che edita la pagina e senza uscire dalla pagina, e queste informazioni saranno tutte disponibili nelle pagine successive e precedenti, compresi alcuni trova & sostituisci inseriti con il nuovo tool di Candalua. Manca veramente poco.... :-)... per l'implementazione "imprudente" attendo alcune modifiche di trova & sostituisci che Candalua ha annunciato in bar tecnico. --Alex brollo (disc.) 15:58, 21 dic 2011 (CET)[rispondi]

Alex, poi mi prendi per la manina e mi spieghi tutto passo passo? Grazie mille. --Lagrande (disc.) 20:10, 21 dic 2011 (CET)[rispondi]
Volentieri, ma l'obiettivo è che tutto funzi senza che l'utente se ne accorga. :-) Obiettivo ambizioso; per adesso (vedi messaggio subito sotto) l'utente si accorge benissimo che qualcosa non funziona più...:-( --Alex brollo (disc.) 22:03, 22 dic 2011 (CET)[rispondi]

Chi è stato? modifica

Perché non mi funziona più "postOCR"?

Solo a me o pure ad altri?

Aggiusta paragrafi corre, trova & sostituisci (cambiato) pure. AutoreCitato anche. Ma postOCR e RigaIntestazione no.

--Carlo M. (a.k.a. zi' Carlo) (disc.) 20:52, 21 dic 2011 (CET)[rispondi]

Non serve che ti risponda, vero? Già lo sapete chi è stato :-) Ci ho dato un'occhiata, ma chi-sapete-voi ultimamente ha fatto troppe modifiche e non ci tengo dietro... per cui ho curato i sintomi, vale a dire gli errori js in console, ma consiglio fortemente chi-so-io di rivedere il codice, in particolare tenendo conto del fatto che certi strumenti devono fare cose diverse a seconda del namespace, per esempio solo in nsPagina va messo RigaIntestazione, e solo in nsPagina esiste un elemento header... Candalùa (disc.) 00:19, 22 dic 2011 (CET)[rispondi]

Su su anche l'evoluzione naturale procede per tentativi ed errori. Ok, un'occhiata alla cronologia individua facilmente il responsabile (me). Quindi, se qualcuno dei marchingegni collegati a Strumenti per la rilettura non funziona, fate prima a segnalarmelo con un messaggio sulla mia talk page.... --Alex brollo (disc.) 22:01, 22 dic 2011 (CET)[rispondi]
Che fatica. Il problema era: a Utente:Alex brollo tutto funzionava perfettamente. A me che firmo, no. Il problema stava in Utente:Alex brollo/vector.js: ma dove? Cosa aggiungeva...? E' stata dura; adesso funziona anche a me, con vector.js vuoto; quindi tutto dovrebbe funzionare anche a voi. Datemi feedback, per favore! E scusatemi. --Alex brollo bis (disc.) 00:35, 23 dic 2011 (CET)[rispondi]
Ora funziona anche a me. de coeteris: "chi è stato?" era una domanda retorica. Immaginavo fosse un certo Alex. Ma il "colpevole" non è neanche importante. Anche perché non di colpevole si tratta. Siccome sono anziano, MOLTO anziano, perfino più di Silvio, ho qualche difficoltà ad andare oltre il FORTRAN e il Pascal, e quindi non so neanche cosa sia stato toccato che ha incasinato i "ferri del mestiere" che uso ma di cui non capisco nulla. Magari si potrebbe anche scegliere quali avere a portata di mano, (anzi topo) e quali no, ma non mi azzardo. Mi sembra più semplice l'osco che il Regex. L'importante è che le cose si sistemino. --Carlo M. (a.k.a. zi' Carlo) (disc.) 12:35, 23 dic 2011 (CET)[rispondi]
Mica penserai che io sia un ragazzino? :D Comunque, proprio perchè anch'io ho la stessa formazione informatica "vecchio stile". devo incoraggiarti a affrontare javascript. Il linguaggio è semplice e interattivo! Una favola. L'unica vera difficoltà è capire come si embrica ;-) con la pagina WEB, come corre; ma sono un paio di concetti soltanto, poi tutto fila liscio. Con le regex è un altro par di maniche, ma anche lì dopo averci sbattuto inutilmente il capino per alcuni anni, trovato il bandolo (e javascript aiuta, ha una ottima implementazione delle regex) tutto fila relativamente liscio. Animo dunque! --Alex brollo (disc.) 12:51, 23 dic 2011 (CET)[rispondi]
A proposito: RigaIntestazione non segue quanto scritto su Utente:Carlomorino/vector.js ma va per conto suo e scrive altre cose. Mi sparo subito o forse qualcuno a caso ..... --Carlo M. (a.k.a. zi' Carlo) (disc.) 15:28, 23 dic 2011 (CET)[rispondi]

Mi tocca spiegarvi... modifica

  1. molti di vi conoscono il sistema "datiPagine", per memorizzare stabilmente dati relativi a libri in corso di rilettura.
  2. la novità che ho introdotto causandovi qualche fastidio è che i dati di datiPagine si possono "cambiare in corsa" direttamente dalla pagina di edit di una pagina qualsiasi (chi usa datiPagine sa che è fastidioso, ad esempio, andare a cercare e modificare datiPagine aprendo MediaWiki:Variabili.js ogni volta che RigaIntestazione cambia perchè cambia capitolo, oppure per introdurre qualche nuova sostituzione di scannos frequenti).
  3. il datiPagine che avete modificato viene salvato in un cookie specifico per l'opera in corso. Se aprite un'altra pagina della stessa opera prima della scadenza del cookie, 7 giorni, i dati modificati saranno richiamati e "rulleranno" quelli scritti in MediaWiki:Variabili.js.
  4. E' con questo sistema che funziona il "ricorda la modifica" del tool trova & sostituisci: tutte le modifiche che avete decso di ricordare vengono aggiunge al cookie, e tutte scatteranno automaticamente con postOCR nelle pagine successive.
  5. Esiste già una funzione per modificare qualsiasi elemento di datiPagine "in corsa", ma prima di presentarvelo come gadget "ufficiale" vorrei sistemarlo un po' e aggiungere un'opzione "uccidi il cookie", perchè al momento, se vi pentite di qualche modifica, non è facile liberarsene. --Alex brollo (disc.) 07:20, 23 dic 2011 (CET)[rispondi]
Molto molto bene. Lo proverò appena ho un po' di tempo. Domanda: ma quando scade il cookie, cosa succede? I datiPagine che uno ha aggiunto si perdono? ed è possibile cambiare la scadenza del cookie a piacimento? Candalùa (disc.) 13:24, 23 dic 2011 (CET)[rispondi]
Al momento quando scade scade. Ma esiste un prototipo di funzione jsonview() che permette di visualizzare (in un popup) il codice corrente e aggiornato di datiPagine, quello salvato nel cookie, pronto a essere copiato tal quale in MediaWiki:Variabili.js, sia per condividerlo con gli altri utenti, che per "fissarlo" a scanso di perdite. Costerebbe comunque poca fatica aggiungere qua o là un dato di scadenza del cookie e magari ficcare anche lui dentro i dati di datiPag. Nota tecnica (evidente per chi riesce a leggere i miei script, cosa non facilissima..): il meccanismo di salvataggio di datiPag del cookie è "monoblocco", l'oggetto viene salvato tal quale; quindi, essendo datiPag un "array associativo", chiunque di voi gli può aggiungere una o più coppie nome variabile:valore variabile all'array(per esempio dalla comodissima console javascript, e anche loro saranno salvate nel cookie senza modificare nient'altro del codice. Per salvare il datiPag nel cookie dalla console, il comando è saveCook().
Approfitto per invitarvi a provare il tool virgolette, magari su una pagina SAL 25% di Indice:Daniele Cortis (Fogazzaro).djvu dalla 44 in poi, dove le doppie virgolette “” vanno sostituite con "caporali", «». Premete il tool virgolette più volte e guardate l'effetto, è o non è carino? :) Serve a gestire il caso in cui metà di una battuta sta in una pagina e l'altra metà nella seconda, e quindi le prime virgolette che si trovano non sono aperte, ma chiuse. --Alex brollo (disc.) 15:55, 23 dic 2011 (CET)[rispondi]

120 secondi modifica

120 secondi per passare una pagina dal puro OCR al SAL 75%, completa di tutto ... obiettivo molto ambizioso, me ne parlava qualcuno su en.source (ma sui testi scritti in inglese è molto più facile intercettare e correggere gli errori OCR). Tuttavia stasera ci ho dato dentro, per "stressare" l'insieme completo degli strumenti, trucchi ed accrocchi a disposizione, e vedo dalla cronologia di Ultime Modifiche, pagine di Indice:La pastorizia.djvu, che ci sono andato assai vicino per parecchie pagine di seguito, ed è a mio giudizio un buon SAL 75% (RigaIntestazione, numerazione versi, PieDiPagina...). Veramente, gli strumenti di cui disponiamo o che stiamo perfezionando qui su it.source sono molto potenti; occorre ancora un notevole sforzo per sistemarli e testarli a fondo, ma capperi, sono molto buoni. Avanti così direi, e senza timore di scartare tutto ciò che non è funzionale a fare presto e bene, che [talora] avviene. --Alex brollo (disc.) 01:54, 24 dic 2011 (CET)[rispondi]

Non voglio dati torto per spirito di contraddizione, ma quanto scrivi è giusto dati un paio di distinguo
  • Gli OCR dipendono dalla qualità della scansione: il testo di Carrer è praticamente già pronto, mentre altri sono dei campi di battaglia praticamente da riscrivere daccapo
  • L'italiano purtroppo è una lingua che ha stentato stenta a trovare un'ortografia univoca, e proprio in questo periodo sto correggendo a tutto spiano "perché" in "perche", "fu" in fù" e "ma" in "mà" (vera e propria nemesi casalinga del mio lavoro di insegnante) perché Antonio Abati li ha voluti tutti così. Senza entrare nel tema della sintassi e delle altre stranezze linguistiche che la giovane età del nostro paese ha alle spalle della propria unificazione ribadisco che ogni predisposizione al 75% richiede una certa attenzione anche nella sola lettura.
  • Questo lo si sa, ma i versi sono sempre meno rognosi della prosa da sistemare, se non altro perché l'area di pagina occupata è minore :D
Bene, questo non significa che quanto scritto da Alex sia sbagliato, ma che il giusto entusiasmo che esprime è in parte condizionato dallo status dell'opera che sta trattando in questo momento.
P.S. Anch'io proverei a usare gli strumenti per la rilettura tramite datiPagina, ma più che un tutoraggio (avessi tempo a disposizione mi arrangerei abbastanza facilmente) preferirei una pagina di aiuto a cui indirizzare i rilettori avanzati in generale. - εΔω 09:17, 24 dic 2011 (CET)[rispondi]
Edo, condivido quello che dici, ma dal mio punto di vista, considerando i tempi di trascrizione a cui sono abituato per il Brandimarte o il Cimarelli, anche se invece di 120 secondi, fossero 240 o 360, per me sarebbe un grande risultato! :) --Accurimbono (disc) 14:15, 24 dic 2011 (CET)[rispondi]
Spero che la mia nota non mi abbia fatto fare la figura dello "spandone". Tutt'altro: era solo per sottolineare che tool ben fatti (e quelli esistenti non lo sono ancora: sono delle prove, degli esperimenti) possono aiutare moltissimo. Sono tool che sono fortemente "source-specifici", non possiamo sperare molto aiuto dai bravissimi pediani, perchè loro semplicemente non hanno la mission "fedeltà a un originale" nè hanno i peculiari problemi del ns Pagina e della transclusione.
Prometto formalmente una pagina di aiuto, ma quando le cose saranno un po' assestate; tuttavia gli strumenti a disposizione, ed in particolare quello che diventerà il trova & sostituisci di Candalua, saranno troppo potenti perchè una pagina di aiuto sia esaustiva.
@ Edo: se il testo in prosa non è complesso, i 120 secondi sono un obiettivo possibile anche in prosa.... test fatto stasera. :-) --Alex brollo (disc.) 00:04, 31 dic 2011 (CET)[rispondi]

Innanzitutto Buon Natale e feste allegate modifica

E poi, vi racconto; poiché la discussione più su è andata un po' fuori tema, vorrei mi si rendesse più chiaro come comportarmi con le opere soi disant 100% nel NS0, quelle inserite nella pagina Discussioni_progetto:Trascrizioni#Testi_SAL_100.25_da_proofreadizzare. Ho trovato presenti in NS0 molti pezzi, isolati (per lo più poesie e racconti), uniti in raccolte che hanno una loro logica ma che in Rete, nel libri, non si trovano (io ma anche altri, vedo) sotto quel titolo. Esempio i Sonetti di Foscolo. Testi che sono inseriti in libri e libroni "Opere Scelte", "Altre opere", "Poesie", "Racconti" e così via. Per arrivare agli "Inni sacri" di Manzoni (100%...) che sono linkati a un librone Indice:Opere varie (Manzoni).djvu ben lontano dal 100% e dove gli Inni sono ancora ben nascosti. Se si vuole "evidenziare" il titolo della poesia (o racconto, eh!) per facilitare la ricerca mettendo in NS0 il pezzo singolo e mantenere l'unità libresca, per me i link in NS0 dovrebbero portare direttamente alla relativa poesia nel librone (e non so se sia tecnicamente possibile). Spero (ma non credo) di essermi "capito". Poi rimane, sempre secondo me, il problema di definire i significati delle percentuali. E rimando su a Wikisource:Bar#chiamata_alle_armi. Salutoni perplessi. --Silvio Gallio (disc.) 09:50, 25 dic 2011 (CET)[rispondi]

Buone Feste a tutti voi ragazzi e ragazze di Wikisource (qui ci starebbe bene una faccina con il cappellino rosso, vero Edo?). Condivido, nei limiti del mio scarso comprendonio, le perplessità di Silvio, e non mi sembra che si sia arrivati ad una conclusione. --Lagrande (disc.) 11:36, 25 dic 2011 (CET)[rispondi]
  --Xavier121 15:06, 25 dic 2011 (CET)[rispondi]
Io invece mi son fatto un'idea abbastanza chiara, a forza di maneggiare libuacci tipo "raccolte".
  1. Innanzitutto il template Testo mostra sia il SAL che la natura "proofread/non proofread" di un qualsiasi testo. Quindi c sono testi "SAL 100% non proofread" e "testi SAL 100% proofread", chiaramente distinti; quindi non ridurrei il SAL a quello non proofread (perlomeno, non acora).
  2. Un testo ns0 diventa SAL 100% quando:
    1. tutte le pagine che transclude sono SAL 100%;
    2. sono state fatte le necessarie rifiniture che non sono poi molte:
      1. Compilazione di Intestazione o IncludiIntestazione;
      2. aggiunta di eventuale indice (pagina principale, e pagine secondarie quando il testo si suddivide ulteriormente);
      3. sistemazione dei link di navigazione (precedente/successivo);
      4. eventuale aggiunta del template Sezione note quando serve.
      5. NON è necessario che l'indice in cui sono contenute le pagine del testo in ns0 sia SAL 100%; basta che siano SAL 100% tutte le pagine che sono utilizzate. Quindi, nel caso che l'Indice sia una raccolta, non è necessario completarne la rilettura per permettere alle opere singole di raggiungere il SAL 100%.
  1. Un Indice diventa SAL 100% quando:
    1. tutte le sue pagine sono portate a SAL 100% oppure SAL 0%;
    2. è stato compilato per bene il tag pagelist;
    3. è stato compilata una bella sezione Sommario.

Ogni Indice è collegato a UNA pagina in ns0, che nel caso che l'indice contenga una sola opera, la pagina principale dell'opera; nel caso l'Indice sia una raccolta, è una pagina principale ns0, che avrà come sottopagine solo le parti comuni del testo (frontespizio, dediche, prefazioni....) mentre rimanderà seplicemente, con opportuni link nell'indice, alle singole opere "indipendenti" che raccoglie. Questa pagina ns0 va considerata una "raccolta" e le opere linkate avranno un rimando alla raccolta, mediante il template Template:Raccolta. Queste opere/raccolta raggiungono SAL 100% quando l'indice è SAL 100% e tutti i link sono sistemati.

Per completezza, esiste anche un altro caso (tipo Zibaldone), in cui una singola grande opera monoblocco in ns0 deriva da più indici. Ma i casi sono così rari che non serve spezzarcisi il cranio.... :-) --Alex brollo (disc.) 16:12, 25 dic 2011 (CET)[rispondi]

Perfettamente d'accordo con Alex. I sonetti del Foscolo, che ho appena trascritto, li metterei come opere singole usando come titolo il primo verso, e creando gli opportuni redirect con i titoli con cui è abitualmente conosciuta l'opera (tipo In morte del fratello Giovanni -> Un dì, s’io non andrò sempre fuggendo).
Dissento invece dalla frase di Silvio "i link in NS0 dovrebbero portare direttamente alla relativa poesia nel librone". Immagino si intenda il link nel riquadro Intestazione, quello con l'icona  , che è generato dal campo "URL della versione cartacea a fronte".
I link alle singole pagine ce li abbiamo già a sinistra del testo; il link nel riquadro dovrebbe sempre puntare all'intero volume, cioè alla pagina Indice. Questo, perché è sulla pagina Indice che ci sono tutti i dati sull'edizione usata. Quindi uno clicca lì sopra per vedere che edizione abbiamo usato e a che punto siamo arrivati con la trascrizione/rilettura, non per essere mandato alla prima pagina del testo, che è una funzione ben diversa!
Inoltre, un domani potremmo decidere di mostrare direttamente in ns0 i dati dell'edizione (come mi pare si era accennato tempo fa): se in quel campo ci mettete sempre l'Indice, è facilissimo prendere i dati da lì e mostrarli dove si vuole; se ci mettete a volte l'Indice, a volte una Pagina, fate impazzire noi tecnici che dobbiamo gestire i due casi distintamente! :-)
Lo so, il nome del campo, cioè "URL della versione cartacea a fronte", è dovuto a ragioni storiche e non aiuta a capire cosa ci va inserito; in effetti, io lo cambierei semplicemente in "Nome della pagina indice", così non ci sono più dubbi :-) Candalùa (disc.) 19:01, 25 dic 2011 (CET)[rispondi]

Il regalo di it.source a Phe modifica

 

Eccolo. :-) --Alex brollo (disc.) 07:30, 26 dic 2011 (CET)[rispondi]

Quella a destra era la primissima prova. Adesso le cose sono andate avanti; gira nel mio vector.js una funzione evidenziaRiga() che, nelle opere sperimentali in cui sono caricate le coordinate delle righe (es. Indice:La pastorizia.djvu, pagine da 70 in avanti) "cattura" la posizione del cursore nel testo a sinistra ed evidenzia la riga corripondente nell'immagine a destra. --Alex brollo (disc.) 23:21, 26 dic 2011 (CET)[rispondi]

per chi volesse provare la questione, queste sono le istruzioni:
  1. copiare nel proprio vector.js gli script che stanno in Utente:Alex brollo bis/vector.js
  2. in basso a destra nello schermo, comparità un piccolo "tattoo", ossia un link trasparente fisso, Phe scripts, quando si entra in una pagina in modifica
  3. a questo punto andate in una pagina di Indice:La pastorizia.djvu dalla 70 in poi, entrate in edit, posizionate il puntatore su un verso qualsiasi nel testo e cliccate il link Phe scripts. Se tutto va bene, sull'immagine della pagina la riga di testo, corrispondente al puntatore, verrà evidenziata.
Anticipo una possibile domanda: a cosa serve tutto ciò? La risposta è semplicissima: non ne ho idea. Si tratta di qualcosa che ha proposto Phe (che sostituisce, al momento, ThomasV nella gestione di importanti aspetti del sistema proofread su toolserver) e che io ho implementato grazie all'esperienza complessiva di magheggi javascript che ormai caratterizza it.source. Si tratta quindi di una iniziativa sperimentale, collaborativa e amichevole it.source-fr.source, se son rose fioriranno. Dal mio punto di vista, la conferma che Phe è un utente prezioso, stimolante, e soprattutto amichevole e incoraggiante: quest'ultima, una qualità importantissima. :-) --Alex brollo (disc.) 09:24, 27 dic 2011 (CET)[rispondi]
Forse ho una mezza idea dell'uso di tale magheggio: un aggeggino simile lo si vede in uso sia su InternetArchive che su GoogleBooks: se si compiono ricerche di stringhe di testo all'interno di un libro i risultati vengono evidenziati anche nell'immagine della pagina. Se si tiene conto che nei siti sopracitati le ricerche intervengono su un OCR per quanto ben fatto, immaginate l'efficacia di un simile mezzo di evidenziazione quando all'immagine proofread è accoppiato un testo corretto da occhi umani. Con l'attuale status del progetto non ci sono chiari indizi di dove questo magheggio andrà a parare, ma evidentemente la direzione è quella che i siti dopraindicati ci indicano. - εΔω 13:43, 27 dic 2011 (CET)[rispondi]
L'ho finalmente provato ed è decisamente interessante. Sarebbe perfetto se riuscisse a gestre anche righe multiple (se seleziono un blocco di righe), o se si riuscisse a rendere preciso a livello di parola o carattere (ma immagino dipenda dalla mappatura iniziale del djvu...). Ottimo lavoro. Detto questo, appena è un po' più stabile io la implementerei di default, nel senso che non ha senso, secondo me,

avere un pulsantino per visualizzare l'evidenziazione, ma appena io seleziono un testo potrebbe essere tutto automatico. Sia in modifica che in lettura. --Aubrey McFato 15:07, 27 dic 2011 (CET)[rispondi]

Prima di entusiarmarvi troppo, tenete conto che questa non è che una "toppa", e precisamente è una toppa sul fatto che nulla delle potenzialità dei file djvu è sfruttata da mediaWiki. Con una implementazione decente dei djvu, la ricerca di parole e di testi sarebbe integrata e l'effetto sarebbe esattamente quello che vedete su IA. Quindi, non vale la pena (forse) di impegarci troppe energie, perchè tutto sarebbe radicalmente spazzolato da una "riforma della gestione dei file djvu".
Si pone però un problemuccio, che devo risolvere adesso. Tutto il sistema è basato (come qualcuno di voi sa) su un'area dati nascosta nel wikitesto della pagina. Ora, in visualizzazione non c'è alcuna traccia del wikitesto. In visualizzazione c'è solo l'elaborazione del wikitesto fatto dal server. La tecnica di memorizzazione che ho scelto (dati nascosti in un commento html) non lascia traccia in visualizazzione, perchè i commenti html non vengono "restituiti" dal server. Se voi ritenete che il "magheggio" debba funzionare anche in visualizzazione, devo ripiegare su un magheggio di tipo totalmente diverso, ossia una "div display:none". Ripiego?
Per quanto riguarda la visualizazzione a livello di parola, di paragrafo o più, ho rinunciato per semplicità e per il fatto che sia FineReader 11, sia MODI danno il dettaglio a livello riga. Non solo: restare a livello riga permette in qualche modo di salvare l'elemento del formato originale che viene perduto, nelle prose, ossia la suddivisione in righe del testo. La visualizzazione a livelli di parola è esclusa per l'enormità dello spazio che sarebbe necessario. Sulla visualizzazione a livello di paragrafo... chissà, potremmo pensarci, ma solo se è assolutamente necessario: sarebbe un'orribile faticaccia. Io mi baserei sul vecchio e saggio proverbio "in medio stat virtus", con relativo corollario "il meglio è nemico del bene". :-) --Alex brollo (disc.) 18:17, 27 dic 2011 (CET)[rispondi]

Aggiornamento modifica

C'è un sistema alternativo e migliore del tattoo per attivare la funzione: una piccola freccina verde all'interno del toolbox, a cavallo fra testo e immagine. Compare solo quando nella pagina ci sono i dati indispensabili.

Caricate nel vostro vector.js anche questo codicillo:

// Shows a fixed small green arrow/link to evidenziaRiga(), but only when datiPagina["righe"] is defined 
$(document).ready(function() {if (wgCanonicalNamespace == "Pagina" && wgAction == "edit" && datiPagina["righe"]!=undefined)
  $('<div style="position:absolute;top:50px;right:0px;z-index:500;"><a href="javascript:evidenziaRiga()"><img src="http://upload.wikimedia.org/wikipedia/commons/7/73/Arrow_green.svg" /></a></div>').appendTo($(".wikiEditor-ui-text"));
  }
);

e la freccina comparirà quando serve, e non comparirà quando sarebbe inutile. Magico javascript, può magheggiare anche chi non ci capisce quasi nulla... :-) --Alex brollo (disc.) 18:25, 27 dic 2011 (CET)[rispondi]

Dopo la pastorizia, un po' di scienza modifica

Ho fatto partire Alebot per caricare il "magheggio delle righe evidenziate" su Indice:Rivista di Scienza - Vol. II.djvu. Su tutte le pagine, comparirà la freccina. Nota bene: le pagine SAL 25% sembrano vuote; entrate in modifica, e il testo si materializzarà. Ma questo è un magheggio ormai vecchio. ;-) --Alex brollo (disc.) 23:27, 27 dic 2011 (CET)[rispondi]

Tutto va ben su Rivista di Scienza. Ho individuato un problema (l'accrocchio non funzionava in anteprima, me stupid), e ho visto con molta soddisfazione che il trucco funzia anche quando il testo viene grossolanamente spostato (es: annotazioni trattate con ref). Vi prego di segnalarmi i rari casi in cui l'evidenziazione della riga sballa (pagina, punto esattodella pagina): l'algoritmo di similitudine è empirico e DIY, e va raffinato. --Alex brollo (disc.) 07:29, 28 dic 2011 (CET)[rispondi]

Quasi pronti al caricamento in un gadget modifica

Secondo me l'accrocchietto evidenziaRighe è pronto per essere caricato in un gadget. Lo carichereste in Strumenti per la rilettura o in un gadget indipendente? --Alex brollo (disc.) 08:31, 28 dic 2011 (CET)[rispondi]

Secondo me è un gadget indipendente. E' uno strumento piuttosto potente per essere inserito tra gli strumenti per la rilettura, in quanto può essere utilizzato anche durante l'inserimento del testo. Samuele 11:35, 28 dic 2011 (CET)[rispondi]
Sì, a pensarci bene non dovrebbero esserci "dipendenze", infatti sul vector.js della mia utenza "dummy" Utente:Alex brollo bis, che utilizzo per verificare come vede le cose un utente "senza tastini", ci sono solo gli script di evidenziaRighe() e accessori, e le cose funziano. Ok, creo il gadget MediaWiki:Gadget-evidenziaRighe . --Alex brollo (disc.) 16:27, 28 dic 2011 (CET)[rispondi]

Pagina principale: è ora di decidere modifica

Ormai il 2011 sta per concludersi e bisogna decidere se rinnovare la nostra pagina principale, a cui tutti teniamo particolarmente. Ho cercato di seguire i consigli datimi sopra per migliorare la bozza: Pagina principale/Sandbox. I problemi della mia proposta (in particolare i colori) sono stati evidenziati e — credo — risolti. Adesso è ora di usare {{+1}} e {{-1}}.--Erasmo Barresi (disc.) 20:51, 26 dic 2011 (CET)[rispondi]

Pareri
  •   Unico neo a colpo d'occhio: mi manca un logo nel box intestazione in alto. Ero affezionato all'antica incisionee dell'amanuense. --Alex brollo (disc.) 23:18, 26 dic 2011 (CET)[rispondi]
  •   (Era' non te la prende, apprezzo tantissimo quello che stai facendo) ma... A me sembra un passo indietro: i colori continuano ad essere troppi, il colore delle iconcine della biblioteca non dialoga con il rosso, non riesco a vedere le riccorrenze con testi e autori; e anch'io sono affezionato all'amanuense (se ne possono scegliere altri). :) --Xavier121 23:45, 26 dic 2011 (CET)[rispondi]
  •   tendente al
  •   Sui colori ho già spiegato come la penso Le icone della serie HILLBLU non si accordano con il colore dei box. Insisto sull'utilizzo di una tavolozza di massimo quattro colori che comprenda anche intestazione e box in fondo. Non impazzirò se non vedrò l'immagine nell'intestazione (anche se l'amanuense mi è sempre piaciuto), ma un'immagine "rappresentativa" sarebbe carina: nota che un'immagine in intestazione questa è un'immagine storica molto gettonata ti sballa la centratura dei paragrafi, con effetto estetico discutibile: a duo tempo ci lavorai non poco. Per distanziare il testo in evidenza dalle ricorrenze basta un paio di caporiga o un "hr" ben stilizzato. - εΔω 01:00, 27 dic 2011 (CET)[rispondi]
  •   Non sono particolarmente affezionata all'amanuense, ma anche io penso che la gamma dei colori dovrebbe essere più ristretta, e più delicata. Fate vobis. --Lagrande (disc.) 08:01, 27 dic 2011 (CET)[rispondi]

Proposta fuori di testa modifica

Ci pensavo un attimo fa; in effetti potrebbe anche esere una stupidata, ma pensavo: la Videoguida su source compare contemporaneamente sul sitenoice e in pagina principale: credo che ormai possa essere tolta dal sitenotice, luogo convenzionalmente deputato a comunicazioni istituzionali, ma... non è che il video potrebbe essere anche tolto dalla pagina principale?

Non c'è un motivo importante per toglierlo, a a esempio un motivo potrebbe essere il guadagno di spazio, insomma mi piace l'idea di non darne per scontata l'ingombrante presenza. Ora lanciate pure gli ortaggi. - εΔω 01:37, 27 dic 2011 (CET)[rispondi]

  •   Spostiamo il video dalla pagina principale, e diamo pure per scontato che la percentuale di nuovi utenti che lo guarda cada dal 5-10% al 0.1%. Rilancio una proposta ancora più iconoclasta: e se lasciassimo le cose come sono? Pwersonalmente, io non amo affatto tornare in un sito di servizio dopo qualche tempo, e non riconoscerlo nei dettagli. In questi casi il mio pensiero è: che perdipalle! Adesso dovrò di nuovo capire come funziona. Quindi ridurrei, eventualmente, le modifiche a piccole cose, come l'aggiunta dell'anno 2012 bene in grande o cose del genere. IMHO la pagina principale dovrebbe cambiare solo quando il sito cambia profondamente; es, era opportuno cambiarlo nel momento della rivoluzione proofread; ergo, lo cambierei alla prossima rivoluzione e non prima. --Alex brollo bis (disc.) 07:35, 27 dic 2011 (CET)[rispondi]
  •   Pensavo che fosse obbligatorio ... Però tenderei a dare ragione ad Alex, mi sa che non lo leggerebbe proprio più nessuno. Comunque anche qui lascio la decisione a chi ne sa di più (praticamente tutti). --Lagrande (disc.) 08:04, 27 dic 2011 (CET)[rispondi]
  •   la videoguida ci ha fatto un gran bene, secondo me, e io la terrei in posti visibili e in posti strategici. Come ho fatto vedere, in commons hanno questo template collassabile (che io ho importato ma evidentemente qui non funziona), e la visualizzazione è ampia e confortevole. Nella finestrina di adesso, la guida si vede ma è sacrificata, e credo andrebbe migliorato questo aspetto. Aubrey McFato 12:07, 27 dic 2011 (CET)[rispondi]

{{Collapse |title = Wikiguida di Wikimedia Wikisource |header-c = steelblue |border-c = steelblue |background-c = lightsteelblue |border-w = 1px |border-s = solid |font-size = 120% |header-fs = 110% |header-fc = white |width = 100% |align =center |1= <big>Questa WikiGuida ti può aiutare a compiere i primi passi nel mondo di Wikisource</big><br /> [[File:Wikimedia Italia - WikiGuida 3 - Wikisource.ogv|frame|650px]] }}

Colori "bluizzati" modifica

Perfetto Aubrey. Metti tutto in {{Videoguida}} e abbiamo un riquadro libero per le ricorrenze; per indirizzare i novizi al template basta scrivere nell'header "Impara cosa si può aggiungere qui; comincia dalla guida essenziale o guarda la videoguida." Inoltre ho ripristinato nella proposta lo schema dei colori attuale e l'immagine dell'amanuense (un po' rimpicciolita).--Erasmo Barresi (disc.) 12:17, 27 dic 2011 (CET)[rispondi]

Bella, secondo me siamo nella direzione giusta. Un paio di feedback, anche da Edo:
  • l'header, tutto bianco così, mi piace molto, ma mi chiedo se ci siano troppe informazioni tutte insieme. Riusciamo a distribuirle un po'? A togliere qualcosa?
  • edo mi faceva notare che avere gli indici sotto potrebbe essere scomodo (per chi va in pagina principale come raccolta di link). Riusciamo a metterli sopra?
il template con la videogida (se riuscissimo a centrarla...) potrebbe stare direttamente sopra l'header. --Aubrey McFato 14:16, 27 dic 2011 (CET)[rispondi]


Mi piace, direi che ci siamo quasi. Qualche piccola pignoleria:

  • nel riquadro iniziale, anche a me sembra ci siano troppe cose: direi di eliminare i link ridondanti, es. il link alla Guida Essenziale c'è sia nella frasetta che nella riga sotto. Magari accorciare la frasetta, e dare un po' di margine tra una riga e l'altra
  • toglierei il "Benvenuto", che andava molto di moda agli albori del web quando si cercava di "far sentire a casa" il povero utente/utonto che navigava per la prima volta in vita, ma che ormai nessun sito "serio" usa più.
  • gli ultimi arrivi dovrebbero usare {{Testo}}, come ora
  • tra i riquadri si dovrebbe usare la stessa spaziatura sia in verticale che in orizzontale
  • "Oltre Wikisource", che è stato molto sfoltito, a questo punto potrebbe tornare nella colonna di destra (dov'era una volta), in modo da evitare lo sgradevole spazio bianco quando una delle due colonne è molto più corta dell'altra

Candalùa (disc.) 15:23, 27 dic 2011 (CET)[rispondi]

  • Nel riquadro iniziale ho tolto il doppio link alla guida essenziale, ma non so se togliere il benvenuto: anche Pedia (it, en, fr tra le altre) lo usa, e non possiamo certo dire che non è un sito "serio".
  • Non credo che riusciamo a mettere gli indici sopra il testo in evidenza: credo che il secondo funzioni meglio per invogliare alla lettura.
  • @Aubrey Ho messo la videoguida in un cassetto, sotto l'header: corrisponde pressappoco alla tua idea?
  • @Candalua [4]
  • Ho provato a normalizzare la spaziatura impostando 1.5em come padding.
  • "Oltre Wikisource" posizionato a destra.

--Erasmo Barresi (disc.) 17:09, 27 dic 2011 (CET)[rispondi]

Ho aggiustato un po' i margini, usando come "standard" lo stile "margin-bottom: 1.5em" su ogni elemento che deve avere uno spazio sotto di lui, e togliendo i <p> e gli altri margini che rompevano. Candalùa (disc.) 18:07, 27 dic 2011 (CET)[rispondi]


Ottimo lavoro! Quasi :). Fra cotanto senno, posso offrire un paio di banali suggerimenti? Premesso che uso un monitor 16:9 noto che aggiungere:

  • Un linea di spazio bianco o -tutt'al più- una righettina tipo "_______" sotto la riga di Benvenuto, la stacca dalle righe sotto. (Ho provato "in corpore vili" ma non ho salvato e mi sembra un po' migliorare la leggibilità senza appesantire.
  • Più o meno idem per le due righe degli Indici in "Biblioteca" per differenziare dalle categorie sottostanti.
  • Non ho mai visto il quadro in "In evidenza" molto più corto di quello attualmente in sandbox; e visto che le "Ricorrenze" raramente alzeranno di molto il loro quadro, temo che ci sarà sempre uno scalino in basso fra colonna destra e sinistra. Allora tanto vale lasciare qualche "Ultimo Arrivo" in più e/o aggiungere un altro quadretto (però adesso non mi viene in mente nulla di intelligente).

Per il resto il lavorone mi piace un bel po'. Complimenti! Silvio Gallio (disc.) 19:06, 27 dic 2011 (CET)[rispondi]


Provo ad aggiungere qualche margine per staccare le varie cose nel riquadro iniziale, che ora è tutto ammucchiato in alto.

Gli ultimi arrivi non mi convincono. Non credo che *tutti tutti* i testi che vengono riletti dovrebbero finire lì. Al momento negli Ultimi testi riletti ci sono 5 poesie tutte di Zanella, rilette tutte tra ieri e oggi; io, con l'attuale sistema, non le avrei mai inserite tutte quante, avrei aspettato che l'intero volume fosse riletto e avrei messo solo il link a Versi di Giacomo Zanella. Altrimenti i testi spariscono già dalla lista dopo uno-due giorni, che mi sembra troppo poco. E comunque il fatto che non si possa usare Tl:Testo è un grave handicap: il titolo da solo spesso non dice nulla. Proposta: continuiamo a gestire manualmente le due liste, mentre il nuovo sistema con dynamicpagelist lo spostiamo in una pagina separata, richiamabile con un link "Vedi tutti"; così possiamo anche aumentare da 5 a 20 o più. Candalùa (disc.) 19:37, 27 dic 2011 (CET)[rispondi]

Ok, --Xavier121 19:41, 27 dic 2011 (CET)[rispondi]
non è che gli Ultimi arrivi mi siano particolarmente cari; era solo per diminuire lo scalino. Altre soluzioni o altri quadri vanno benissimo! Silvio Gallio (disc.) 21:07, 27 dic 2011 (CET)[rispondi]

Fino a quando ci saranno utenti che sono disponibili per aggiornare la lista non sarà un problema gestirla manualmente. Mi piace il box di en.source: un link per vedere i nuovi testi e un altro per aggiungere alla lista. Ho importato qualcosa di equivalente da noi: chi vuole essere il primo a vandalizzare il riquadro? :-) Erasmo Barresi (disc.) 10:17, 28 dic 2011 (CET)[rispondi]

Grandi tutti, sta venendo proprio bene.
  • La Wikiguida secondo me va benissimo così, dite che è abbastanza visibile?
  • gli ultimi arrivi stanno effettivamente bene con il template testo, se la gente vuole aggiornare a mano ok.
  • che cosa sono le prime due sezioni qui? Sono curioso :-) Mi piace molto l'idea di spiegare qualcosa in Pagina principale, ne abbiamo bisogno.
  • PS: nessuno ci obbliga a cambiare il primo gennaio. Anzi, potremmo farlo per il compleanno di Wikipedia, il 15. Ad ogni modo, continuiamo così che la comunità si sta esprimendo ed è la cosa migliore, nessuno ci corre dietro. Aubrey McFato 11:12, 28 dic 2011 (CET)[rispondi]
Ho aggiunto gli Ultimi arrivi manuali, con un link "Elenco completo" come già c'era, perché i link v - m sono comodi, ma solo per chi li conosce. :-) A questo punto, a meno di qualche ultimo ritocchino, mi sembra che ci siamo! In particolare mi piace molto la Wikiguida, bella idea! La ruberò sicuramente per vec.source :-) Candalùa (disc.) 15:21, 28 dic 2011 (CET)[rispondi]
  •   A parer mio l'impostazione dei riquadri va benissimo, anche l'uso delle variazioni di un unico colore (non che con i colori slavati mi dispiacesse poi tanto, ma omogenea la vedo meglio); la wikiguida perfetta. Qualcosa da ridire sull'intenstazione, un po' per l'uso dello sfondo bianco (eh sì, comincio ad affezionarmi a quello presente, magari si potrebbe rendere più chiaro), un po' per il testo che a me pare troppo cuncintratu, ammassato l'uno sull'altro. La riga FAQ...DONAZIONI si potrebbe lasciare così com'è. Qualità dei testi nel rettangolino in basso a destra dove adesso vi è scritto NIENTE PANICO! (e non abbandonerei nemmeno il contatore, forse poco affidabile -è pur sempre perfettibile- ma è un indicatore da tenere in considerazione). Riguardo a 'Benvenuti in Wikisource', devo dire che lo preferisco alla vecchia maniera. Questa immagine linkata da edo non mi dispiaceva affatto, sbiadendone i colori ancora meglio; essendo più allungata potrebbe permettere una distribuzione migliore del testo. P.S. Davvero un ottimo lavoro! --Barbaforcuta (disc.) 01:50, 29 dic 2011 (CET)[rispondi]

Purtroppo quello che potrebbe apparire come un vantaggio, cioè avere uno spazio tra le righe più ampio, potrebbe causare problemi a chi usa basse risoluzioni. Lo sfondo blu invece rende meno distinguibili i link: come puoi notare nella bozza non ho usato link su sfondo colorato, a parte "v · m" negli "Ultimi arrivi"; ma quelli sono puramente tecnici e quindi non destinati a essere utilizzati dai visitatori. Per il contatore: non so se il consenso per mettere nel nostro "biglietto da visita" un dato palesemente inaffidabile ci sia. Inoltre, ma questo non è altrettanto importante, non saprei dove metterlo.--Erasmo Barresi (disc.) 21:24, 30 dic 2011 (CET)[rispondi]

Sì, ho notato; in effetti sono più visibili. Ritirate le obiezioni, ribadisco il mio parere positivo. Bene, a questo punto siamo quasi pronti a stappare lo spumante! :-)--Barbaforcuta (disc.) 23:59, 30 dic 2011 (CET)[rispondi]


Domanda abbastanza tecnica modifica

Come simulo qualcosa come una console javascript sotto IE? Ho bisogno di pasticciare sotto IE perchè ho scoperto una massa di incompatibilità.... :-( --Alex brollo (disc.) 10:45, 28 dic 2011 (CET)[rispondi]

IE8 ha una specie di "firebug" sotto Strumenti -> Strumenti di sviluppo Candalùa (disc.) 10:52, 28 dic 2011 (CET)[rispondi]

Premendo F12 appare qualcosa che assomiglia lontanamente a firebug. Dopo un bel periodo di esperimenti per la compatibilità ho imparato a non fidarmi della console di IE, alcune volte non funziona a dovere, quindi non ti arrabbiare ;) Samuele 11:31, 28 dic 2011 (CET)[rispondi]

Mi sa che dovrò arrangiarmi con una copia completa locale della pagina web, modificando i js con Blocco Note e disseminando gli script di alert... Sono lontano "due versioni" da IE 8... parlavo di IE 6! --Alex brollo (disc.) 13:42, 28 dic 2011 (CET)[rispondi]

export in ePub!!! modifica

Ci sono importanti novità sul fronte dell'esportazione dei testi in formato ePub e altri: i franciosi, che come al solito sono troppo più avanti, hanno messo su un sito apposta: http://wsexport.fr.nf/?lang=en. Dettagli su oldwikisource:Wikisource:Scriptorium#Wsexport_:_an_automatic_export_tool_for_Wikisource_fr. Candalùa (disc.) 23:22, 28 dic 2011 (CET)[rispondi]

E' una cosa veramente importante, soprattutto perchè (non so se lo sapete) siamo in contatto con quelli di Simplicissimus, che stanno facendo gli epub per Amazon.it... Direi che ci guardiamo, e mi piacerebbe che riuscissimo pure a capire cosa sono e come funzionano i microformat che i francesi dicono di usare nei template... --Aubrey McFato 01:01, 29 dic 2011 (CET)[rispondi]
Ho sciappinato un po' con Sigil (editor per epub), e devo dire che secondo me siamo ad un passo, sono proprio curioso di capire che hanno fatto i francesi. Secondo me WMI potrebbe occuparsi della struttura del sito, se è come penso che sia: un server che converte a domanda alcuni libri. Bisognerebbe esaminare il codice che hanno fatto. Aubrey McFato 03:41, 29 dic 2011 (CET)[rispondi]
Non si può semplicemente chiedere che ci spieghino come hanno fatto? --1FranzJosef (posta) 08:32, 29 dic 2011 (CET)[rispondi]
Ottimo, un pensiero in meno. ;-) --Alex brollo (disc.) 09:05, 29 dic 2011 (CET)[rispondi]
Se si riesce, volentieri. Il fatto è che non credo possano entrare troppo nei dettagli, alla fine hanno rilasciato il codice e credo che ci rimanderanno sempre a quello per capire il meccanismo al meglio. Comunque immagino che Candalua sia uno dei pochissimi che possa fare le domande giuste e soprattutto capire le risposte. La cosa che a me preme, personalmente, è cercare di capire qual'è la soluzione migliore nel medio e nel lungo periodo: come Wikimedia Italia eravamo da tempo in contatto con PediaPress per sviluppare un'estensione epub, e a questo punto mi piacerebbe non reinventare la ruota un'altra volta. Alla fine progetti che lavorano su wiki e epub ce ne sono stati vari (anche Alex ci si è sbizzarrito, con ottimi risultati, fra l'altro), ma nessuno, a parte questo, è mai arrivato a una soluzione che funzioni anche su larga scala. Per una volta, sarebbe bello lavorare ad uno strumento importante tutti insieme. --Aubrey McFato 11:22, 29 dic 2011 (CET)[rispondi]

La cosa è ora anche su toolserver e si può scegliere la lingua! Non è ancora perfetto, ma ora provo a implementare il microformat che dicevano Candalùa (disc.) 12:43, 29 dic 2011 (CET)[rispondi]

Io - per i nostri testi it.source - batterei la strada della post-elaborazione; ossia, di smontare, modificare (innanzitutto, eliminare o sistemare i link alle pagine) e rimontare l'ePub. Fra l'altro, la strada dell'ePub è anche una via maestra per avere una versione html delle nostre pagine. :-)
@ Aubrey: non ero io, era Candalua che aveva realizzato la cosa; io gli ho solo boicottato il progetto.... :-( --Alex brollo (disc.) 13:34, 29 dic 2011 (CET)[rispondi]

Piccolo problema modifica

certamente già risolto (pensavo) per altri autori.

L'Autore:Vincenzo Bellini (numismatico) viene confuso dal bot (I suppose) con il più noto e famoso compositore omonimo.

Nella voce dedicata al numismatico collega come testi in cui è citato quelli del compositore (Categoria:Testi in cui è citato Vincenzo Bellini) e non i suoi (Categoria:Testi in cui è citato Vincenzo Bellini (numismatico)).

Quale è il trucco per far tornare tutto al posto giusto?

--Carlo M. (a.k.a. zi' Carlo) (disc.) 12:31, 29 dic 2011 (CET)[rispondi]

Agh!! il caso dell'omonimia non era stato previsto! purtroppo c'è un bug di mediawiki che ci impedisce di usare il nome della pagina per generare le categorie. Quindi attualmente il template:Autore (non il bot, quello è un'altra cosa) usa i parametri Nome e Cognome, e se due tizi hanno lo stesso nome e cognome... Aggiungerò un nuovo parametro, opzionale: "Nome e cognome in caso di omonimia" (se vi viene in mente un nome più comprensibile fatevi avanti), che si possa compilare con "Vincenzo Bellini (numismatico)". Candalùa (disc.) 12:55, 29 dic 2011 (CET)[rispondi]

Nel frattempo, ho aggiunto numismatico al campo cognome in Intestazione; orrendo ma funziona, in attesa del terzo parametro. Io aggiungerei un campo opzionale con il solo contenuto dell'elemento disambiguatore, e lo si potrebbe chiamare "disambigua" (in questo caso "numismatico"; in genere sarebbe vuoto, ma la categorizzazione potrebbe essere fatta sempre da nome+cognome+disambigua. --Alex brollo (disc.) 13:06, 29 dic 2011 (CET)[rispondi]

Mi ero già lanciato a spronbattuto, ma la tua idea mi piace, è più semplice e pulita. Già che c'ero ne ho approfittato per togliere la pappardella "I testi dell'autore sono nella categoria ecc. ecc.", ora si vede solo "Testi di" Candalùa (disc.) 13:14, 29 dic 2011 (CET)[rispondi]

  Fatto, e incredibilmente ho pure aggiornato la guida :-) Candalùa (disc.) 13:28, 29 dic 2011 (CET)[rispondi]
uau!!!! Era il primo omonimo. BTW il {{AutoreCitato|Bellini}} porta a Vincenzo, ma volta credo che ne esista forse un altro (autore del seicento). --Carlo M. (a.k.a. zi' Carlo) (disc.) 15:21, 29 dic 2011 (CET)[rispondi]
Approfitto per ricordare che ogni autoreCitato "breve" andrebbe considerato provvisorio e di comodità; ma poi andrebbe "tradotto" in formale autoreCitato a due parametri, perchè le omonimie, con il solo cognome, sono parecchie; nel momento del completamento, eventuali "sviste" dell'algoritmo possono essere corrette. --Alex brollo (disc.) 20:19, 29 dic 2011 (CET)[rispondi]

Pagina principale: pronti al varo? modifica

Sembra che il mio modello di pagina principale (Pagina principale/Sandbox) abbia ricevuto il consenso della comunità. Propongo uno schema di migrazione in 4 passaggi.

1. Si sostituisce il codice di Pagina principale con il seguente, transcludendo temporaneamente da Pagina principale/Sezioni/Sandbox.

{{#section:Pagina principale/Sezioni/Sandbox|Titolo}}
<!--PRIMA COLONNA --><div style="float:left; width:60%"><div style="margin-right:1.5em">
{{#section:Pagina principale/Sezioni/Sandbox|In evidenza}}
{{#section:Pagina principale/Sezioni/Sandbox|Biblioteca}}
{{#section:Pagina principale/Sezioni/Sandbox|Citazioni}}</div></div>
<!-- SECONDA COLONNA --><div style="float:right; width:40%">
{{#section:Pagina principale/Sezioni/Sandbox|Rilettura del mese}}
{{#section:Pagina principale/Sezioni/Sandbox|Ricorrenze}}
{{#section:Pagina principale/Sezioni/Sandbox|Ultimi arrivi}}
{{#section:Pagina principale/Sezioni/Sandbox|Oltre Wikisource}}</div>
{{interprogetto|nolink|w|commons|b|q|n|wikt|v|meta=Main_Page}}
<!-- INTERLINK -->
[[ar:]][[az:]][[bg:]] ...

2. Si cancella Pagina principale/Sezioni...
3. ...per poi ricrearla con le nuove sezioni.
4. Si cancellano tutti i /Sandbox dal codice di Pagina principale.

Sia chiaro che:

  • per me tutto potrebbe rimanere così come, ma se cambiamo è meglio :)
  • qualcuno potrebbe prevedere un altro piano di lavoro, ma questo non è un problema

Prima di tutto ciò però bisogna decidere quale testo presentare per primo nel riquadro "In evidenza"; ho già scritto che nella mia idea lo cambierem(m)o con una cadenza regolare, ad esempio 10 giorni, scegliendo tra i nuovi inseriti.--Erasmo Barresi (disc.) 21:43, 30 dic 2011 (CET)[rispondi]

Sul piano tecnico e le varie fasi, nella mia ignoranza, non metto lingua; ma bel lavoro! Mi permetto di (cortesemente) essere in disaccordo su quanto dici -nel post di sopra- riguardo al contatore. È impreciso, d'accordo, ma dà una certa misura del lavoro fatto e viene usato da tutte le Source; ci sarà pure un motivo... :) Pubblicità verso l'"esterno" e riconoscimento del lavoro fatto verso l'"interno". Se non sai dove inserirlo posso suggerire il punto in alto a sinistra del benvenuto; in tal caso lo stesso benvenuto, per staccare otticamente, può tornare a sinistra a ridosso dell'immagine. Poi, as usual, non mi straccerò le vesti. C'è la crisi e devo risparmiare! Silvio Gallio (disc.) 09:50, 31 dic 2011 (CET)[rispondi]
Aggiunto contatore.--Erasmo Barresi (disc.) 10:42, 31 dic 2011 (CET)[rispondi]
Uhm! credevo meglio! Confesso che non avevo provato. Dal punto di vista estetico non è granché. E se rimettiamo il benevenuto al centro mentre il contatore andasse in basso a sinistra portando a destra il resto della riga "qualità dei testi"... Scusa il disturbo ma non "devi" fare quello che dico, i miei sono suggerimenti. Poi l'estetica -secondo me- ha il suo peso :) Silvio Gallio (disc.) 11:36, 31 dic 2011 (CET)[rispondi]
Certo che sono suggerimenti, ma se non proviamo non sapremo mai se sono validi :-) Erasmo Barresi (disc.) 20:45, 31 dic 2011 (CET)[rispondi]