Wikisource:Bar/Archivio/2016.07

Archivio delle discussioni del mese di luglio dell'anno 2016

Categoria: Archivio Bar 2016 Bar   Archivio    luglio 2016 




Modifiche nsPagina modifica

Mi sono appena accorto di una "modifica bloccante" della struttura dell'header in nsPagina; questa modifica mi bloccava autoRigaIntestazione, è possibile/probabile che le conseguenze siano estese a una varietà di tool e di script che lavorano con il codice nsPagina. --Alex brollo (disc.) 09:15, 1 lug 2016 (CEST)[rispondi]

In effetti, di colpo mi si è incantato uno script che carica pagina Pagina, blocco risolto dopo "normalizzati" header e footer.

Uovo di Colombo modifica

Avviene che un'opera in ns0 derivi da più di una pagina Indice. Aimè, nel campo "Url della versione a fronte" di Intestazione c'è spazio solo per un Indice, e quindi autoNs0 "vede" solo quella, e non c'è modo di fargli costruire le sottopagine che derivano da indici diversi da quella.

Soluzione banalissima: finito di usare autons0 per creare le sottopagine relative al primo indice, sostituire in "Url della versione a fronte" il nome del primo indice con quello del secondo, e andare avanti: autoNs0 funzionerà regolarmente :-) --Alex brollo (disc.) 11:31, 1 lug 2016 (CEST)[rispondi]

Verificato in Odissea (Romagnoli), oltre che in Lettere (Sarpi), dove @Lino Marco aveva segnalato il problema. --Alex brollo (disc.) 05:47, 2 lug 2016 (CEST)[rispondi]

Proposte di inserimento libri modifica

Ciao amici, non so bene come fare ma mi sarebbe piaciuto inserire un piccolo pulsante (o un vero form o qualcosa) nella pagina principale, per permettere ai nostri lettori di suggerire un libro o un autore da inserire su Wikisource. Dovrebbe essere, nella mia testa, una cosa molto semplice da fare (non è richiesto neanche loggarsi) per avere magari un feedback su libri a cui non pensiamo ma che magari sono desiderati da vari lettori. Dite che si può fare?Intanto stavo creando Wikisource:Proposte. --Aubrey (disc.) 18:49, 3 lug 2016 (CEST)[rispondi]

Progetto:Duecento/Desiderata: creata nel 2007, prima e unica richiesta nel 2016 di un testo che non è duecentesco tra l'altro... --Accurimbono (disc) 14:43, 4 lug 2016 (CEST)[rispondi]
Però è un'ottima richiesta! ;-) perchè non sposti direttamente la tua bella pagina ad una più visibile? Aubrey (disc.) 23:38, 4 lug 2016 (CEST)[rispondi]
Sì, in effetti un testo interessante.
Lo scopo della pagina è circoscritto al Progetto:Duecento ed è linkato in evidenza nella home page del progetto (terzo box nella colonna di destra)
Più che spostare, si può copiare e adattare la pagina per farne una per il Progetto letteratura o altri progetti, oppure farne una generale per Wikisource da linkare in Pagina principale, se va bene alla comunità.
Resto però scettico, in quanto anche avendo dei feedback, poi non potremmo essere in grado di soddisfare la richiesta generando delusione nell'utente. Però è una bella idea. Ci avvicina molto anche alle biblioteca tradizionali che hanno (spesso) un quaderno in cui richiedere i libri mancanti. --Accurimbono (disc) 03:47, 5 lug 2016 (CEST)[rispondi]
  •   alla fine è quello che facciamo da anni in varie pagine: uno di noi chiede un testo, qualcun altro individua le scansioni su IA o Google Books, qualcun altro le carica e poi si inizia la trascrizione. Solo che adesso la procedura è "chiedi ad Alex" :D, invece deve diventare: "chiedi in Wikisource:Proposte" (pingando Alex :D). E la nuova pagina va pubblicizzata in homepage. Potrebbe essere anche un modo per coinvolgere qualche lettore di passaggio, del tipo "ti interessa il testo X? eccoti caricate le scansioni, ci daresti una mano a trascriverlo, se ti va?" Can da Lua (disc.) 12:38, 5 lug 2016 (CEST)[rispondi]
Ho ampliato un po' la pagina aggiungendo qualche istruzione. Mi sono ricordato che la stessa proposta era venuta fuori l'ottobre scorso; si parlava delle "proposte di trasferimento" da Wikipedia e del fatto che in generale non si può importare un testo direttamente da WP, e sarebbe meglio perciò avere una procedura facile per richiedere l'inserimento di un testo "da zero". Can da Lua (disc.) 13:12, 5 lug 2016 (CEST)[rispondi]

Ok, wiki non è un blog.... modifica

...ma chissà: un "blog integrato" forse ci starebbe. Alle volte sento l'esigenza di pubblicare un "articolo", ossia una esposizione personale di media lunghezza su qualche cosa, aperta ovviamente a correzioni (minori) e a commenti (quanti se ne vuole).

Proposta: aprire una pagina Wikisource:Blogs con sottopagine per utente, a loro volta con sottopagine, ognuna delle quali sarebbe un "articolo". Che ne dite? --Alex brollo (disc.) 12:17, 4 lug 2016 (CEST)[rispondi]

  •   tu potrai anche scrivere le tue sottopagine utente come vorrai, ma una tale licenza darebbe inevitabilmente la stura a qualunque forma di arbitrio, POV ecc. Ribadisco la sufficienza di una sottopagina utente (peraltro anch'essa da usarsi con grande cautela). I Blog veri hanno altre caratteristiche di paginazione, etichettatura e aggiornamento che qui non sono replicabili. Lasciamo perdere. - εΔω 14:09, 4 lug 2016 (CEST)[rispondi]
Ok. --Alex brollo (disc.) 14:38, 4 lug 2016 (CEST)[rispondi]
Il problema è solo quello della "reperibilità" dei contributi. Quanto al blog generale wikimedia, la rilevanza degli argomenti e l'ampiezza dei temi è di vari ordini di grandezza superiore ai contributi che avevo in mente io ;-), pensavo a cose molto più specifiche e limitate; la galoppata nelle traduzioni di Romagnoli è stata entusiasmante e molto istruttiva.... ma sta finendo. --Alex brollo (disc.) 15:57, 4 lug 2016 (CEST)[rispondi]
Un esempio...? Non li trovo...Alex brollo (disc.) 16:42, 4 lug 2016 (CEST)[rispondi]
Vedi la categoria in inglese w:en:Category:User_essays. Sono sottopagine utente, ma c'è una organizzazione di categorie interessante. Poi si possono far vedere in un portale. Aubrey (disc.) 17:27, 4 lug 2016 (CEST)[rispondi]
Ok, c'è qualcosa di simile anche su en.source: en:Wikisource:Essays. A questo punto, direi che si può partire con sottopagine utente tipo "essay", con l'unica avvertenza di "marcarle" fin dall'inizio con una categoria che dovrebbe essere Categoria:Saggi degli utenti, rimandando l'organizzazione al momento in cui ce ne sarà un certo numero. Alex brollo (disc.) 17:33, 4 lug 2016 (CEST)[rispondi]

21:45, 4 lug 2016 (CEST)

Traduzioni di Romagnoli: il punto modifica

Finita (tranne Pindaro che attende una riparazione del file djvu I) la galoppata nelle traduzioni di Romagnoli e caricato l'OCR preformattato sono abbastanza soddisfatto, ma non completamente. Le opere sono queste:

  1. Sofocle (tre volumi)
  2. Aristofane (tre volumi)
  3. Euripide (sei volumi)
  4. Omero - Iliade (due volumi)
  5. Omero - Odissea (due volumi)
  6. Pindaro - Odi (due volumi)   Fatto

In particolare, una tecnica di caricamento rapido delle immagini (passaggio a ScanTailor) che non mi sembrava male, ha dato come risultato immagini abbastanza grossolane, da considerare una "brutta copia"; invito chi può e sa a caricarne nuove versioni sullo stesso nome, che è strutturato in modo da dare grandi vantaggi di automatismo.

Spero che la formattazione del testo risulti decente; se c'è qualche suggerimento per migliorarla via bot, il momento buono è questo. Date un'occhiata per favore, e non risparmiate critiche. --Alex brollo (disc.) 00:15, 5 lug 2016 (CEST)[rispondi]

Ho usato la raccolta dei giocattoli per indentare ma mi pare non funzioni.... Forse bisogna fare un lavoro a priori con i template giusti come hai fatto in Amleto (Rusconi)? Aubrey (disc.) 00:33, 5 lug 2016 (CEST)[rispondi]
@Aubrey Finita la galoppata di caricamento, adesso vorrei preparare (come da suggerimento di Xavier121) un memoregex comune per facilitare la formattazione; il termine di paragone dovrebbe essere Indice:Tragedie di Sofocle (Romagnoli) II.djvu e precisamente Antigone. Le grosse indentature le ho inserite con un {{Gap}} che viene inserito con memoRegex per sostituzione di un due punti a inizio verso (default 10 em, si sta un attimo a cambiare il valore). Penso che farò un dettagliato "aiuto di trascrizione/formattazione" da transcludere, pari pari, in tutte le pagine Discussione indice correlate (tutta la serie Romagnoli ha uno stile analogo, anche in dettagli tipografici come gli accenti sulle i e sulle u: í ú). Alex brollo (disc.) 09:05, 5 lug 2016 (CEST)[rispondi]
In che senso non funziona? Xavier121 09:21, 5 lug 2016 (CEST)[rispondi]
Cioè, funziona, ma non è facile capire quante volte uno deve indentare... Aubrey (disc.) 09:32, 5 lug 2016 (CEST)[rispondi]
qui: Utente:Alex brollo/Suggerimenti formattazione Romagnoli una prima bozza di "aiuto generale di formattazione" per le opere della serie Romagnoli. Aubrey, hai ragione, le indentature con spazi sono traditrici; per questo ho ripiegato su Gap, tenendo conto della posizione del personaggio centrato (che cade circa sugli 8em) ci si arrangia abbastanza bene. Alex brollo (disc.) 10:40, 5 lug 2016 (CEST)[rispondi]
PS: L'avventura Romagnoli ha dimensioni notevoli.... in pochi giorni sono state create varie migliaia di pagine, per la maggor parte del tipo più ostico: pagine di teatro in versi. Non è una cosa da poco. Alex brollo (disc.) 11:05, 5 lug 2016 (CEST)[rispondi]
Update. Adesso mi dedicherò alla rilettura di alcune pagine di ciascun volume, giusto per rendermi conto dei problemi, rifinire le sbavature, sistemare i memoRegex. Ho modificato un pochino {{Vc}} in modo da dargli un po' di margine sopra e sotto: questo significa che non serve più lasciare una riga bianca attorno al template, e quindi nelle ultime opere (dove avevo inserito una riga bianca) farò in modo che sia eliminata via memoRegex. Un secondo problema è la numerazione versi (indispensabile) che richiede un ritocco per "saltare" anche altri tipi di versi rispetto a quelli previsti. @Candalua Sto verificando le modifiche su una copia esterna dello script, se tutto funziona porterò le modifiche in MediaWiki:Gadget-RegexMenuFramework.js dove sta lo script generale. Alex brollo (disc.) 12:15, 6 lug 2016 (CEST)[rispondi]
Un grandissimo lavoro. Complimenti! --Accurimbono (disc) 02:40, 11 lug 2016 (CEST)[rispondi]

Open call for Project Grants modifica

 

Aiutaci a tradurre nella tua lingua:

Greetings! The Project Grants program is accepting proposals from July 1st to August 2nd to fund new tools, research, offline outreach (including editathon series, workshops, etc), online organizing (including contests), and other experiments that enhance the work of Wikimedia volunteers.
Whether you need a small or large amount of funds, Project Grants can support you and your team’s project development time in addition to project expenses such as materials, travel, and rental space.
Also accepting candidates to join the Project Grants Committee through July 15.
With thanks, I JethroBT (WMF) 17:25, 5 lug 2016 (CEST)[rispondi]

AutoWikiBrowser modifica

Ho riscoperto AWB, w:AutoWikiBrowser, molto utile per sostituzioni sistematiche su molte pagine quando non si dispone di un bot; su Commons BrolloBot non è flaggato, e quindi dopo aver commesso un errore banale che si è diffuso in moltissime pagine mi sono informato, e ho visto che anche l'uso di AWB dev'essere autorizzato; l'autorizzazione è arrivata in poche ore.

Due segnalazioni:

  1. se avete bisogno di una "revisione sistematica" di testi che avete caricato su Commons, una delle possibilità è chiedermi di usare AWB per sistemare;
  2. se non l'avete mai fatto, e lavorate attivamente nel campo del "lavoro sporco", vi suggerisco di prendere in considerazione il tool. --Alex brollo (disc.) 07:12, 7 lug 2016 (CEST)[rispondi]

piccoli problemi del niubbo (e pure rinco) modifica

Salve. Il buon Alexbrollo ha dato l'ultimo colpo (dopo il primo e il secondo) al mio magro contributo Programma per la gran linea di via ferrata negli stati pontifici adesso mi pare-spero che manchino solo i soliti dettagli per definire. Mi è sorto un problemino. Non avevo quasi mai usato il template "autore citato" ho provato stavolta. Uno degli autori, Angelo Ferlini, viene citato in Ilarione Petitti's Delle strade ferrate italiane e del miglior ordinamento di esse a pag 313. Ho provato a templatizzare e non mi pare che il Programma delle ferrate romane abbia recepito. Due considerazioni: 1) Non sono riuscito a trovare un aiuto per il template ed eventuali magheggi per l'uso; ma questa e certo colpa mia. 2) Penso di essere l'unico in Italia a sapere di questo link qui su Source. Il problema è stato come trovare il nome di Ferlini nel testo di Petitti; sapevo che c'era ma dove? Sono oltre 650 pagine! Qui, la divisione in capitoli non aiuta. O almeno, IO non ho capito come fare. Ho risolto grattando dentro I.A., ma se c'è un modo per trovare una stringa dentro un testo in Source sarei contento di conoscerlo. E con me altri, immagino. Salutoni estivi--Silvio Gallio (disc.) 09:44, 8 lug 2016 (CEST)[rispondi]

@Silvio Gallio Se sono parole ("ferrovia") o nomi comuni ("Rossi") è un problema; ma se sono cose tipo "Ferlini", inusuali, scaraventa la parola in "Ricerca" e la becchi: Ricerca cerca sull'intera wikisource.
Volendo invece fare una ricerca più accurata su un grosso testo hai due strade facili:
  1. scaricarti il djvu e usare la ricerca testo di DjView (ma mancherà tutte le parole in cui l'OCR ha fatto stranezze)
  2. transclidere l'intera opera in una tua sandbox con un "pages" globale e poi puoi farci dentro tutte le ricerche che vuoi con la funzione di ricerca del browser (sia sull'anteprima, o, se preferisci, sul testo salvato) --Alex brollo (disc.) 10:06, 8 lug 2016 (CEST)[rispondi]
@Silvio Gallio, Alex brollo Ne abbiamo parlato di recente, vedi #Ricerca nei libri, ed è emerso che abbiamo un template {{Ricerca}} che si può mettere nelle pagine (che sarebbe bene evolvere in un tool disponibile ovunque per default). Can da Lua (disc.) 10:46, 8 lug 2016 (CEST)[rispondi]
{{Ricerca}}, di cui si può ammirare la splendida documentazione..... --Carlo M. (disc.) 10:53, 8 lug 2016 (CEST)[rispondi]
Wikisource, di cui si può ammirare la splendida documentazione..... :P :P :P Can da Lua (disc.) 10:55, 8 lug 2016 (CEST)[rispondi]

Ricerca l'ho creato io il 30 agosto del 2012, non potete certo aspettarvi chissache... :-D Scherzi a parte, mi/vi chiedo, ancora: perchè non mettere la barra di ricerca direttamente dentro il template intestazione? Secondo me sarebbe molto molto utile. Aubrey (disc.) 11:06, 8 lug 2016 (CEST)[rispondi]

@Carlomorino Orpo, avevo visto la discussione ma non l'avevo mica capita..... :-( Devo sperimentare as soon as possible. Intravedo due usi, se tutto funzia come deve: una copia in pagina utente, per cercare in qualsiasi libro, e una copia in ns0 per cercare nell'opera. Alex brollo (disc.) 11:32, 8 lug 2016 (CEST)[rispondi]
Grazie delle risposte ma ci avevo provato (per "Ricerca" si intende quella "solita" in alto a destra, vero?) e mi ha sputato in faccia :) boh. Io ho sempre avuto un rapporto difficile con questo software. Sarà per la prossima. salut. Ah no., @Alex brollo ma se devo transcludere tutto un malloppone di 650 pagine (o peggio - ci sono altri mega testi qui) non sarebbe carino fornire quella pagina sandbox 'già confezionata con una linguetta in alto? Provo a spiegarmi: non una sandbox ma proprio un testo intero e completo esso ce l'abbiamo già. Oppure è troppo complicato? Direi che sarebbe un servizio eccellente a gradito proprio da chi le ricerche le deve fare. (io, per esempio) :D Ciao a tutti Silvio Gallio (disc.) 12:56, 8 lug 2016 (CEST)[rispondi]
@Carlomorino Inputbox è un tantino stravagante: per fargli cercare un testo in un'opera diversa da quella della pagina corrente occorre entrare in modifica e salvare il parametro (del codice o del template cambia poco). Intravedo una soluzione, ma non so se avrò tempo e voglia di implementarla.... Alex brollo (disc.) 13:04, 8 lug 2016 (CEST)[rispondi]
@Alex brollo graecum est, non legitur --Carlo M. (disc.) 13:06, 8 lug 2016 (CEST)[rispondi]
Scusa.... in pratica: metti un template {{ricerca}} nella tua pagina utente e fa in modo di poter cercare una parola in un testo qualsiasi di cui passi il nome nella cella inputbox (non nella tua pagina utente, ovviamente). Senza entrare in modifica. Se ci riesci guarderò il codice con molto interesse. Alex brollo (disc.) 13:21, 8 lug 2016 (CEST)[rispondi]
praticamente ti apre la casella di ricerca con un "parola prefix:testo", ma anche "descrizione prefix:template:" (senza i due punti alla fine non funziona). Utile. --Carlo M. (disc.) 15:01, 8 lug 2016 (CEST)[rispondi]
Vediamo:
Sembra che nel secondo campo si possa infilare il prefisso della pagina in cui cercare ;-), ma guarda un po' com'era facile.... Alex brollo (disc.) 15:46, 8 lug 2016 (CEST)[rispondi]

Rieccomi fra i monti :P - sono contento di aver mosso un po' le acque. Soprattutto perché mi avete fatto trovare questo template che ho prontamente inserito nella mia pagina utente. Grazie. Suggerimento: partendo da qui non è che si può inserire un campo "ricerca" anche in testa al testo :)? così ogni libro avrebbe subito la possibilità di essere ricercato dentro. E soprattutto lo si vede subito; tutti anche i polli come me. Ovvio che se ci fosse stato, tutto sto girotondo non sarebbe avvenuto. Già che ci siamo, qualcuno ha voglia di mettere la manina anche nell'intestazione?

- Ci sono (almeno) tre modi [1) linguetta "Fonte", 2) icona col libro aperto, 3) "informazioni sulla fonte del testo"] per andare nel testo a fronte senza che sia chiarito da nessuna parte;

- manca, appunto un campo ricerca che -se messo in intestazione e per alleggerire graficamente- dovrebbe essere IMHO uguale a quello "Ricerca" usuale in alto a dx con solo, dentro, specificato "Ricerca nel libro"/testo".

-Cambiando la linguetta "Fonte" in "Testo a fronte" ( i non-admin hanno un sacco di spazio per le linguette) penso si potrebbero eliminare sia l'icona che il link "Informazioni sulla fonte del testo" liberando spazio per la suddetta casella di ricerca.

Poi io la faccio facile tanto, come si vede, manco mi ricordo cone si fa a creare i numeretti o i punti. Me lo dovrei ripassare anche questo :(. robb de matt. salutoni Silvio Gallio (disc.) 11:57, 9 lug 2016 (CEST)[rispondi]

Questa è la mia modesta proposta, da valutare e migliorare. Differisce dalla pratica corrente in molti punti (ad esempio l'uso di una tabella e non di un contenitore div), che se volete posso spiegare in dettaglio.--Erasmo Barresi (disc.) 16:30, 9 lug 2016 (CEST)[rispondi]
Se si deve cercare in un unico testo che ha la pagina Indice (DjVu o PDF) si può anche usare Book2Scroll, dalla pagina indice cliccando in alto a destra, carica tutte le pagine e tutte le trascrizioni in un'unica schermata. Da lì, ctrl+F e si cerca da browser.
Ovviamente per il lettore sarebbe più comodo avere una interfaccia di ricerca più facilmente raggiungibile. --Accurimbono (disc) 03:06, 11 lug 2016 (CEST)[rispondi]
@Erasmo Barresi a me interessa il dettaglio. Come mai hai scelto la tabella? Premetto che trovo la scelta condivisibile dato che le informazioni così come le hai predisposte sono organizzate proprio in forma tabellare. --L0ll0 (disc.) 06:30, 11 lug 2016 (CEST)[rispondi]
Interessante, anche se dovrò studiarlo nel prossimo giorno di ferie ;-) . Come vedi l'inserimento di una pagina come quella? Mi pare troppo per essere "sostitutiva" del template Intestazione; ma forse non ho capito niente :-) Alex brollo (disc.) 08:43, 11 lug 2016 (CEST)[rispondi]
(confl. da alex) @Accurimbono Temo che il Djvu sia destinato a perdere importanza e -purtroppo- a scomparire. A meno che qualcuno non prenda in mano la faccenda in modo organico. Quindi abbiamo una soluzione parziale. Se invece il TxT viene fornito dalla ditta Source & Co, una volta fatto siamo a posto definitivamente. Visto che il template funziona (sempre IMHO) e se si può semplificare a un solo campo "Ricerca nel testo" da rendere ben visibile, questo problema dovrebbe scomparire. Perfino io riuscirei a comprendere l'uso al primo colpo :) L'ottimo template di Aubrey (ottimo per i risultati per il resto non sono in grado di giudicare) è più articolato perché deve funzionare ovunque ma deve (dovrebbe) essere reso più visibile. Quanto all'intestazione, forse sarebbe "più meglio" che fosse discusso in un posto o pagina dedicato/a anche perché se quello proposto da Erasmo è ciò che vede uno appena arriva temo si spaventi. Ciao di corsa Silvio Gallio (disc.) 08:54, 11 lug 2016 (CEST)[rispondi]
@Silvio Gallio Innanzitutto ci vuole una pagina di aiuto per Ricerca: Aiuto:Ricerca. Avendo "penetrato" un po' i misteri della questione Ricerca, dovrebbero bastare poche righe per spiegare che inserendo "Creonte prefix:Pagina:Tragedie di Sofocle", si otterrà l'elenco di tutte le pagine che il cui nome inizia con "Pagina:Tragedie di Sofocle" e che contengono Creonte. Basta stressare che prima deve essere inserita la parola, poi prefix:, e subito dopo il prefisso della pagina. Alex brollo (disc.) 09:12, 11 lug 2016 (CEST)[rispondi]

──────────────────────────────────────────────────────────────────────────────────────────────────── Sono d'accordo con la filosofia che porta Silvio Gallio: l'utente non deve spaventarsi. A proposito del Template:Ricerca trovo inutile e fuorviante la seconda box, quella che va a comporre il prefisso del testo in cui cercare.
Scavando e scavando nel codice ho notato che stando alla pagina di aiuto su pedia w:Aiuto:Inputbox#Parametri il parametro "prefix" non dovrebbe far comparire la seconda box. (type="hidden")
Infatti, ad un occhio attento e ad una connessione lenta, non sfuggirà il fatto che la seconda input con il prefisso compare dopo, in ritardo rispetto alla input principale della ricerca. Penso di aver individuato il responsabile nella penultima riga del file MediaWiki:Common.js:

$("input[name='prefix']").attr("class",$("input[name='search']").attr("class")).attr("type","text");

Non ho capito cosa sistemi, ma temo che "sporchi" il template {{Ricerca}} andando a visualizzare quella seconda inputbox (mettendo type="text"). Qualcuno più esperto del file Common.js può controllare?
Secondo me già nascondendo quel secondo box il template {{Ricerca}} acquista notevole bellezza e si potrebbe dire già pronto per essere usato negli infobox. --L0ll0 (disc.) 09:38, 11 lug 2016 (CEST)[rispondi]

@L0ll0 Quella riga è un mio "scherzo da hacker". La cancelliamo presto. Consente però di usare il template per cercare all'interno di qualsiasi prefisso; in pratica, consente di utilizzare il template nella propria pagina utente, impostando specificamente il prefisso di un'opera; altrimenti, non c'è modo di passare al template qualcosa di diverso dal nome pagina dove il template è stato inserito. In pratica, il template così com'era può funzionare solo nelle pagine principali ns0.
Rollbacko la modifica su Common.js, me la carico nel mio common.js personale (a me va bene così). --Alex brollo (disc.) 10:40, 11 lug 2016 (CEST)[rispondi]
Caro Alex, 10 anni fa sarei stato d'accordo, basta fare una decina di click, cosa vuoi che sia. Sia chiaro, ho una sviscerata ammirazione per te e per tutto quello che ti inventi per semplificare l'editing qui dentro. Ma io, niubbo & rinco, perché devo avere un template nascosto, che nemmeno so che esista (e non lo sapeva nessuno fino a qualche giorno fa!), dover andare in una pagina di aiuto per vedere come usare una cosa che non so nemmeno che c'è? Basta metterla lì in bella vista, magari al posto di link meno utili in quanto doppioni. O forse mi spiego male io?.
Ma veniamo alla "Ricerca". Se nell'intestazione, ad esempio sotto il titolo e gli autori, trovo il campo "Ricerca in questo testo" (o simile dicitura) perfino io credo di non necessitare di particolare aiuto; è identico a quello in alto a destra solo che dentro, in colore grigiasto, la dicitura è differente e auto-esplicante. O no? @L0ll0, nella mia immane niubberia credo di aver capito che il template così com'è possa< essere usato per raggiungere qualsiasi testo da qualsiasi pagina o quasi. Diverso l'inserimento del campo ricerca, nel testo stesso o nell'intestazione, che sarebbe finalizzato alla ricerca di stringhe solo in quel testo ma che sarebbe ben visibile a me-niubbo. A questo punto la domanda sarà: "Funziona? È possibile?" Ciao, esco.Silvio Gallio (disc.) 10:44, 11 lug 2016 (CEST)[rispondi]
Ci vuol poco per inserirlo in Intestazione e farlo comparire nelle pagine principali; il problema è che ha un formato un po' ingombrante e che bisognerebbe lavorarci (sul css) per sistemarlo. A voi :-D ! Personalmente sono pienamente soddisfatto di aver capito come Ricerca funziona :-) (e ho aggiunto due righe alla doc di {{Ricerca}} in attesa di fare una bella pagina Aiuto:Ricerca) Alex brollo bis (disc.) 10:59, 11 lug 2016 (CEST)[rispondi]

──────────────────────────────────────────────────────────────────────────────────────────────────── Mi sono un po' perso nel discorso, ma provo a dire la mia: io credo che la casella di ricerca inserita de facto nel template intestazione sia l'idea migliore: la gente vuole cercare dentro quel libro, e si trova senza dover fare nulla la casello in tutti i libri, nel ns0, che è quello che vedono. Direi che è la cosa più facile e semplice per tutti.

Che poi ci siano, nel template {{Ricerca}}, parametri e barbatrucchi per usarlo su varie pagine, mi pare anche quello una cosa ottima: potremmo fare caselle di ricerca per progetti o per namespace o anche per raccolte (per esempio, cerca in tutti gli articoli di questa rivista), ma è una cosa da utente espertissimo e la faremo a mano noi, nel caso.

La proposta di @Erasmo Barresi su un nuovo template intestazione ha cose che mi piacciono e cose che mi lasciano dubbioso, ma sicuramente lo ringrazio per averci provato, è importante questo tipo di audacia grafica. Mi piace molto per esempio la barra in alto dei download, più chiara della scrittina che ho inserito io. Mi piacerebbe fosse più leggera, forse, e che magari tutta la serie dei metadati fosse in un "cassetto collassabile"? Non so, parliamone. ANche l'immagine a volte potrebbe essere ridondante, ma se manda alla pagina Indice è certamente più chiara dell'attuale iconcina che riconosciamo solo noi... Se avete voglia ne parliamo, il template intestazione gradirebbe certamente una riscrittura, e necessita di tutte le cure possibili. E' il template più importante che abbiamo. Aubrey (disc.) 11:02, 11 lug 2016 (CEST)[rispondi]

@Alex brollo grazie mille, ora infatti la seconda input rimane nascosta. Però non ho capito la questione ns0: il template {{Ricerca}} inserito in questa discussione più sopra ↑ cerca correttamente all'interno del solo bar, che non è in ns0. Per il fatto che non permetta di cambiare il prefisso a piacere quello è vero, ora è "blindato" alla pagina in cui si trova. Secondo me è più corretto così (che di default non lo mostri), se si vuole lasciare una ricerca libera si può studiare se e come passare un parametro al template che si occupi di mostrare la input del prefisso su richiesta.
@Silvio Gallio ora che la seconda input è correttamente nascosta (se si vede ancora bisogna cancellare la cache del browser) facciamo un esempio pratico: Ordini di cavalcare. Nella pagina principale, all'inizio dell'indice, ha il template {{Ricerca}}. Prova a digitare qualcosa come "Re de gli animali" e far partire la ricerca. Vedrai che mostra solo i risultati all'interno di quel testo.
@Aubrey nel frattempo che scrivevo hai scritto pure tu e mi trovo pienamente d'accordo con te. --L0ll0 (disc.) 11:08, 11 lug 2016 (CEST)[rispondi]
Proposta: visto che dopotutto l'output di "Ricerca" in ns0 non fa del tutto schifo, io proverei a implementarla in Intestazione, ma siccome la ricerca è utilissima in alcuni testi e meno utile in altri, in Intestazione metterei, con calma, un parametro aggiuntivo tipo "mostra form Ricerca si/no (default si)". Do uno sguardo a Intestazione per vedere come fare. Alex brollo bis (disc.) 12:16, 11 lug 2016 (CEST)[rispondi]
  Fatto, adesso nelle pagine principali (spero solo in quelle) che contengono Intestazione compare la casella di ricerca nel testo. E funziona. Rifiniremo dopo le adeuate verifiche. Alex brollo (disc.) 13:09, 11 lug 2016 (CEST)[rispondi]
Non c'è modo di allineare al centro sia la casella che il bottone di ricerca? Così è più bello da vedere e si presenta meglio. --Accurimbono (disc) 05:42, 12 lug 2016 (CEST)[rispondi]
Scusate se insisto. Il campo "Ricerca" in alto a destra, quello fornito da sempre, è un rettangolo e dentro scritto "Ricerca" a sinistra la "Q" all'estrema destra. Con "Ricerca in questo libro" non si può fare le stesso ed eliminare il bottone di lancio? Se non altro per rendere simili le metodologie e l'uso oltre che per alleggerire al massimo la grafica. E parlando di grafica, scusate ancora -magari sono due problemi diversi- l'iconcina col libro e "Informazioni sulla fonte del testo" portano allo stesso link. Personalmente toglierei l'icona che è meno comprensibile. buona giornata.Silvio Gallio (disc.) 08:23, 12 lug 2016 (CEST)[rispondi]

──────────────────────────────────────────────────────────────────────────────────────────────────── @Silvio Gallio in modo semplice ed immediato non si può rendere uguale a quello in alto a destra. Siccome si usa una inputbox le opzioni sono limitate. Al massimo si può mettere il testo "Ricerca" in grigio dentro. Per spostare l'icona delle lente di ingrandimento (la "Q") dentro al campo della ricerca e ottenere uno stile identico alla ricerca generale in alto a destra bisogna agire sullo stile (CSS vector, ma chi usa ancor il monobook?) generale.
Aggiungendo semplicemente il placeholder verrebbe più o meno così:

--L0ll0 (disc.) 09:26, 12 lug 2016 (CEST)[rispondi]

Peccato, ma mi pare già un miglioramento. Mi pare. ByeSilvio Gallio (disc.) 09:53, 12 lug 2016 (CEST)[rispondi]
Esiste un carattere Unicode per la lentina di ingrandimento, ci siamo avvicinati all'aspetto del campo Ricerca standard, ho modificato il codice di L0ll0, che ne dite? Alex brollo (disc.) 07:22, 13 lug 2016 (CEST)[rispondi]
Dico che se aggiungiamo 4 righe di stile CSS (buttate lì in velocità su Firefox)
.classe-da-dare-al-contenitore-del-template-ricerca .mw-ui-button {
    position: relative;
    right: 40px;
    background-color: transparent;
    border: 0;
}
si otterrebbe un risultato molto simile. --L0ll0 (disc.) 09:28, 13 lug 2016 (CEST)[rispondi]

Commons: template Institution modifica

Lo ricordavo vagamente, adesso ho aperto almeno la pagina del template commons:Template:Institution e come mi sembrava è il template per inserire l'anagrafica di istituzioni (biblioteche comprese). Bisognerebbe verificare che le biblioteche con cui siano collegati per collaborazioni abbiano tutte il loro item Institution, ho già avvisato @EusebiaP di prendere in considerazione l'inserimento della Biblioteca comunale di Trento. --Alex brollo (disc.) 08:47, 11 lug 2016 (CEST)[rispondi]

A suo tempo! :) --Xavier121 09:08, 11 lug 2016 (CEST)[rispondi]
Ciao, abbiamo già il Template Institution, ora lo inseriamo nelle immagini delle mappe che hai caricato. Grazie per il *meraviglioso* lavoro che hai fatto! --EusebiaP (disc.) 14:12, 11 lug 2016 (CEST)[rispondi]

Spiegazioni modifica

Ringrazio @L0ll0, Alex brollo, Silvio Gallio, Aubrey per aver dato un'occhiata alla mia sandbox (vedi sopra). Mi sembrava opportuno dare delle spiegazioni, indipendentemente dal fatto che se ne faccia qualcosa oppure no.

  • Come Alex temeva ;-) la cosa è effettivamente "sostitutiva" del template Intestazione. Ciò non toglie che se ne possano prendere solo alcune componenti per integrarle nel template Intestazione attuale. L'idea è quella di mettere insieme in modo più organico le cose che si sono andate accumulando nel corso del tempo. La nostra grafica è in effetti diventata sempre più "farcita": abbiamo aggiunto un link al download EPUB e l'indicazione della lingua originale nel caso di traduzioni; usiamo un template {{Raccolta}} nel caso di antologie e un template {{Nota disambigua}} nel caso di edizioni diverse della stessa opera; oltre a questo c'è un template {{Qualità}} separato. Quindi ho pensato di inserire tutte queste informazioni in un unico flow. L'ordine può ovviamente essere cambiato (es.: spostare i link per il download in fondo se si pensa che sia più opportuno).
  • div vs tabella: Lo standard per gli infobox su Wikipedia è la tabella. La versione mobile è stata pensata in modo da funzionare bene con infobox-tabella, mentre se guardate una nostra pagina ns0 su un cellulare vedete che il contenitore div esce dalla larghezza dello schermo.
  • barra dei download: Aubrey, se ritieni puoi sperimentare, anche direttamente nella mia sandbox, i modi di renderla più leggera.
  • immagine: È la cosa a cui tengo di meno e non risponde ad alcuna necessità particolare. Si può mettere o non mettere; nel caso bisognerebbe decidere se deve linkare a qualcosa, tenendo presente che abbiamo testi in ns0 provenienti da più di una pagina indice.
  • metadati: Questa invece è una componente fondamentale. Aubrey e Silvio temevano che risultasse troppo grande; in realtà, se nella bozza ho voluto elencare tutte le proprietà Wikidata relative alle edizioni, molto difficilmente ci sarà un'edizione in cui saranno usate tutte. Nella maggior parte dei casi ce ne saranno 3-5.
  • SAL: Ho pensato a un'indicazione del SAL più discorsiva e che contenesse in modo più chiaro il link alla pagina indice, invitando il lettore a collaborare.
  • casella di ricerca interna: Se ne parlava poco sopra; ovviamente comparirebbe solo se ci sono sottopagine, negli altri casi basta usare la funzione Ricerca del browser.
  • link "Citazioni di questa edizione": Comparirebbe molto raramente, in quanto la maggior parte delle citazioni sono di opere, non di specifiche edizioni o traduzioni. Questo presuppone che ci sia un link "Citazioni di quest'opera" nella pagina opera.
  • font: Non è casuale che io abbia usato il font di default dell'interfaccia Vector invece di Georgia. Prima del typography refresh usare un font diverso da quello di default era comprensibilissimo, ma l'aggiornamento è stato frutto di una riflessione ponderata, con considerazioni di leggibilità, accessibilità e coerenza tra interfaccia desktop e interfaccia mobile. È ancora opportuno sovrascrivere il font di default? Un'altra cosa che dovremmo considerare è la ridondanza della spaziatura tra paragrafi e dell'indentazione: si dovrebbe usare uno solo di questi metodi. Su http://webtypography.net/2.3.2 ci sono indicazioni tecniche in questo senso. Infine nella bozza la larghezza del div "supercontenitore" (quello di div class=testi) è aumentata di 3 em.

Spero che queste spiegazioni incoraggino ulteriore feedback :-) --Erasmo Barresi (disc.) 13:05, 11 lug 2016 (CEST)[rispondi]

Nel caso che quella pagina debba sostituire il tlIntestazione, la mia opinione è: no, l'output di Intestazione va rimpiccolito, semplificato, alleggerito prendendo esempio dai nostri fratelli maggiori (en.source e fr.source), non certo appesantito.
La pagina è comunque preziosa per i meccanismi di raccolta dei dati, che vanno senz'altro sfruttati, ma su una sottopagina (o su un infobox espandibile) Alex brollo (disc.) 15:37, 11 lug 2016 (CEST)[rispondi]
Osservazione sulle citazioni. Le citazioni bibliografiche ben fatte sono SEMPRE relative a edizioni, MAI a opere; infatti sono sempre associate (sempre che siano ben fatte) a una fonte bibliografica ben precisa, titolo, capitolo, pagina, ossia a una edizione. Alex brollo (disc.) 15:54, 11 lug 2016 (CEST)[rispondi]


Mi piacciono la barra dei download (giusto offrire tutte le alternative) e il SAL discorsivo; ok anche il font, no invece all'immagine. Bene anche il box di ricerca, anche se io lo terrei fuori dal template (come appena fatto sul vecchio Intestazione). Per il resto lo trovo un po' troppo schematico, soprattutto la parte dei metadati: io preferirei riprendere il nostro stile "classico", arricchendolo dei (pochi) dati essenziali che oggi mancano, in particolare indicando l'edizione nella forma sintetica "Autore, Titolo, Editore, Luogo, Anno.", che mi sembra la più chiara e leggibile. Il template {{Edizione}} era un tentativo in tal senso, vedi esempio su Il Principe. Questo credo sia il primo punto su cui dovremmo decidere: vogliamo mantenere la vecchia grafica, o vogliamo creare qualcosa di totalmente nuovo? Teniamo anche conto che probabilmente il passaggio avverrebbe molto gradualmente, e per un po' di tempo il nuovo dovrebbe convivere col vecchio. Can da Lua (disc.) 16:00, 11 lug 2016 (CEST)[rispondi]

Ho provato ad alleggerire il tutto con un bel cassetto (per i metadati) e mi pare molto molto meglio. Ovviamente tanti dettagli possono essere cambiati (grandezza dei font, disposizione, larghezza del tutto). Devo dire che mi esalta sempre di più l'idea di un template che finalmente possa parlare "da pari a pari" con la sua relativa pagina Indice... che non rappresenta certo tutti i casi, ma una grande parte. Una cosa che manca adesso (come ho scritto anche qui) è un bel bottone/icona che ci faccia passare chiaramente da uno all'altro. Deve essere molto più chiaro dell'icona attuale, che solo noi conosciamo. Per quello che riguarda i colori, io non avrei problemi ad avere un template master e tanti sottotemplate per progetto come adesso, ma forse è l'occasione di semplificare e fare come tutte le altre source, con un template solo? Aubrey (disc.) 16:56, 11 lug 2016 (CEST)[rispondi]

Ho eliminato l'immagine e ho spostato il box di ricerca fuori dalla tabella; il link "Citazioni di questa edizione", rimasto solo, l'ho spostato vicino ai download. Capisco che la presentazione dei metadati non sia del tutto convincente, ma non ho trovato un modo migliore di visualizzare i valori di proprietà come "edizione o traduzione di", "pubblicato in", "parte di", "consiste di": per questo tipo di dati l'impostazione attuale, che imita la copertina di un libro, risulta poco funzionale. Altrimenti si può fare un sistema ibrido, in cui i dati "semplici" sono visualizzati nella forma "Traduzione di Tizio", "A cura di Tizio", ecc., mentre i dati "complessi", come quelli che dicevo, stanno in un luogo a parte. Questo porrebbe il problema di dove debba stare l'autore, che non è neanche una proprietà dell'edizione ma dell'opera... per questo la mia soluzione mi pare un buon compromesso. Che poi si possa migliorare la spaziatura tra righe, o togliere il grassetto, è solo un fatto estetico.
Alex, il soggetto delle citazioni è sempre un edizione, ma l'oggetto può essere qualsiasi cosa: un autore, un'opera, una specifica edizione, ma anche una città, un edificio, un piatto tipico e chi più ne ha più ne metta. Noi abbiamo {{AutoreCitato}} per le citazioni che hanno come oggetto autori, e {{TestoCitato}} per le citazioni che hanno come oggetto opere o edizioni — che per ora sono indistinte, ma nella maggior parte dei casi si tratta di opere.
Fino a qui è quello che avevo scritto prima che Aubrey mi conflittasse ;-) L'incassettamento nasconde tutte le informazioni tranne il titolo e il sottotitolo, il che a prima vista mi sembra un problema, ma forse mi sbaglio.--Erasmo Barresi (disc.) 17:07, 11 lug 2016 (CEST)[rispondi]
Ho compattato i metadati ispirandomi agli infobox di Wikipedia, penso che così funzionino. Considerate sempre che nella maggior parte dei testi che abbiamo compariranno soltanto cinque righe al massimo.--Erasmo Barresi (disc.) 18:38, 11 lug 2016 (CEST)[rispondi]
Titolo e autore (anche anno?) secondo me devono essere ben visibili da subito, mentre tutto il resto può essere cassettato. Ricordiamoci poi che la grafica si può sempre cambiare, intanto cerchiamo di avere lo "scheletro" fatto bene (a me adesso non spiace). Forse, ripeto, potremmo allargare un pochino. Non mi piace molto (ma forse sono l'unico) il SAL così verboso e grosso: dopo le prime volte che uno lo legge, ingombra troppo. O cassettiamo anche quello oppure potremmo mettere tutta la spiegazione in un popup/mouse over se uno clicca l'icona SAL (che non mi dispiace invece avere grossa). Dai che ci stiamo arrivando. Aubrey (disc.) 19:26, 11 lug 2016 (CEST)[rispondi]

──────────────────────────────────────────────────────────────────────────────────────────────────── @Erasmo Barresi ho visto che hai scelto uno stile più simile a Wikipedia. Io però sono d'accordo con Aubrey sul blocco troppo indigesto a vista che si crea tenendolo fuori dal cassetto.
Si potrebbe creare un ibrido, sempre ispirandosi a Wikipedia, in cui si spostano i metadati di lato. Del resto le due bande laterali bianche sono parecchio spoglie. A destra si potrebbe tenere fissato in alto l'infobox coi metadati che, come su Wikipedia, nella versione mobile viene messo in mezzo ma nel cassetto.
Lo propongo come compromesso, anche se non nascondo una preferenza per tenerlo nascosto... (Del resto quei dati anche gli editori non li mettono in copertina, ma all'interno. Magari scritti in piccolo).
Per quanto riguarda i colori terrei lo schema attuale che dà molto più allegria che il grigiume totale. Il fatto che le altre Source preferiscano l'uniformità in questo caso non mi sembra un modello da imitare. Ritornando sempre a Wikipedia anche lì i vari infobox hanno un colore specifico per progetto e l'effetto, a mio modesto parere, rende graficamente bene. --L0ll0 (disc.) 20:20, 11 lug 2016 (CEST)[rispondi]

Desidero dare un parere personale che è anche una preghiera: il nostro template intestazione è divenuto ingestibile proprio a causa della volontà di porre tutto tutto nello stesso posto e più spazio esso guadagna più esso distoglie dal testo vero e proprio a cui dovrebbe essere subordinato. O esso diventa a tutti gli effetti una "copertina" virtuale del testo — e il testo richiederebbe ulteriori clic, scroll o altro per essere raggiunto, il che mi pare una perversione — o assegniamo tali clic, scroll o simili impicci alle metainformazioni sotto forma di sottopagine o incassettamenti, ma prego tutti i tecnici e i designer di puntare a minimizzare l'intestazione piuttosto che ingrandirla per bulimia di informazione. Se questo obiettivo ha come effetto collaterale l'uniformazione di colori o il sacrificio di icone, ben venga. - εΔω 09:44, 12 lug 2016 (CEST)[rispondi]
Ultimi aggiornamenti: ho cambiato il colore del bordo in {{Colore portale sfondo barre 2}}, così è più evidente che si tratta di un blu e non di un grigio; ho messo la barra dei download e il link "Citazioni di questa edizione" fuori dal bordo, sicché sono rimasti dentro solo i dati veri e propri; ho fatto una prova del testo del SAL senza il titolo centrato (solo con il 25% per ora, ma se piace lo provo con tutti).--Erasmo Barresi (disc.) 11:38, 12 lug 2016 (CEST)[rispondi]
Concordo con Edo e rinnovo l'invito a uniformarsi quanto più possibile con il template header "monacale" di en.source e fr.source. Prenderei in seria considerazione - se dovessimo ristrutturare a fondo it.source - di prendere di peso il codice di uno dei due template header. Alex brollo (disc.) 11:41, 12 lug 2016 (CEST)[rispondi]
Purtroppo non penso che quei modelli ci possano essere poi tanto utili. Ad esempio: fr.source non ha i link per il download, ma ha un banner in alto che svolge la stessa funzione, tra l'altro presentando solo il formato PDF; en.source li ha messi nella sidebar, ma non so chi li veda... Nessun altro ha una biblioteca ipertestuale come noi, per cui nessuno necessita del link "Citazioni di questa edizione", ma noi si. Nessuno ha la casella di ricerca. Né anglofoni né francofoni hanno un SAL in ns0, a differenza ad esempio di de.source, a cui peraltro mi sono ispirato. Ma soprattutto, nessuno ha ancora pensato a come collegare Wikisource a Wikidata in modo coerente, e questo cambiamento concettuale richiede anche una diversa presentazione grafica. Il punto è che, considerato tutto quello che abbiamo e quello a cui aspiriamo, il template Intestazione una certa altezza la deve avere. Ma neanche troppa in fin dei conti: non tutti i libri hanno un sottotitolo; per la maggior parte ci sarà solo da indicare "edizione o traduzione di", luogo di pubblicazione, casa editrice e anno di pubblicazione. Sullo schermo del mio portatile sarebbero circa 8 cm di altezza, dai download alla casella di ricerca.--Erasmo Barresi (disc.) 12:13, 12 lug 2016 (CEST)[rispondi]
Per quel che mi riguarda, benedico lo sforzo di Erasmo di guardare la questione Wikidata in faccia, cosa che nessun altro ha fatto. Io purtroppo sono ancora fermo con l'importazione perchè vorrei riuscire ad avere un buon corpo di metadati dei libri da poter caricare su Wikidata, ma finchè non riusciamo ad estrarli siamo sempre a punto e a capo. Credo che la nostra struttura con i vari template Ac, Tc, e nsOpera sia molto logica e funzionale, e questo andrà a nostro favore. Personalmente, amo molto l'header nostro e dei francesi, lo trovo più leggibile, anche perchè lascia ampi margini bianchi ai lati (cosa che fanno tutti i siti in cui bisogna leggere, da Medium a Vox ai blog, ecc.). Se gli altri header hanno caratteristiche utili importiamole pure, ma come larghezza io credo dobbiamo stare sulla nostra. Aubrey (disc.) 12:38, 12 lug 2016 (CEST)[rispondi]

Con le ultime modifiche di Erasmo la cosa inizia anche a piacermi :). Qualche altro hint: secondo me i dati fondamentali dell'edizione (autore-titolo-editore-luogo-anno) dovrebbero essere ben visibili, gli altri dati meno importanti (parte di, consiste di, schede di autorità...) magari si possono anche cassettare. Se vogliamo accorciare il template, perché non mettere qualcosa a fianco di esso, ad esempio la barra del download, quella della ricerca e il SAL? (Ovviamente facendo in modo che su uno schermo stretto questi elementi "cadano" al di sotto del template se non ci stanno). Can da Lua (disc.) 14:47, 12 lug 2016 (CEST)[rispondi]

@Candalua se sai come mettere a fianco bene, fallo; io non saprei da dove iniziare...--Erasmo Barresi (disc.) 13:23, 13 lug 2016 (CEST)[rispondi]

@Erasmo Barresi, OrbiliusMagister, L0ll0, Alex brollo, Silvio Gallio, Aubrey come primo passo ho provato a sviluppare l'idea dei link di download, con l'intenzione di aggiungerlo gia' da subito se piace: esempio su Alla conquista di un impero. Ho messo delle icone colorate attira-click. Rinuncio all'idea di allinearlo a sinistra, non c'e' un modo pulito al 100% per farlo. Che ve ne pare? Can da Lua (disc.) 22:09, 21 lug 2016 (CEST)[rispondi]

  •   @Candalua a me piace. Solo alcuni appunti estetici:
    • Si riesce a dargli la classe testi e un display: block che setta la larghezza come quella del testo e lo spinge al centro come il testo e l'intestazione?
    • Sempre in materia di centramento si potrebbe dargli un text-align: center; per centrare il testo come il sottostante titolo.
    • Un ultimo appunto sulla grandezza. Il testo è grande come l'autore e di soli due pixel più piccolo del titolo. Questo va bene se vogliamo attribuirgli l'importanza data all'autore. Secondo me potrebbe bastare una grandezza equivalente a quella dell'anno dell'edizione e ridurre un pelo le icone (che forse sono poi quelle che "ingrandiscono" visivamente tutto il blocco in quanto poco uniformi in grandezza col testo che le accompagna...)
Mi trovi pienamente d'accordo anche con l'utilizzo di colori acchiappa click! --L0ll0 (disc.) 22:50, 21 lug 2016 (CEST)[rispondi]
Se perseguiamo questa strada (e, secondo me, possiamo, anche se esteticamente non è la mia preferita) direi di adeguarci al template francese, nel senso di fare una vera e propria barra e cercare di allineare al centro. Inoltre metterei icone e scritte leggermente più piccole di qualche punto, sono molto grosse così). Però l'idea mi piace, la gente può scaricarsi quello che gli pare ed è molto visibile e chiaro. Aubrey (disc.) 22:50, 21 lug 2016 (CEST)[rispondi]

@Erasmo Barresi, OrbiliusMagister, L0ll0, Alex brollo, Silvio Gallio, Aubrey (pingate anche altri se vi viene in mente qualcuno) ho accolto i vostri feedback (il centrato poi lo faccio meglio). Poi pensavo anche di aggiungere le iconcine nel template Testo, tipo sulle pagine degli autori: ora c'e' l'epub, ma ci metterei anche mobi e pdf che sono anche piu' diffusi. La mia idea e' che da un lato dobbiamo impegnarci per una "rivoluzione" come prospettato da Erasmo, ma dall'altro dobbiamo anticipare piu' possibile quello che si puo' fare da subito. Can da Lua (disc.) 23:11, 21 lug 2016 (CEST)[rispondi]

[fuori crono] I francesi negli "Ultimi arrivi" della pagina principale scrivono:
Ma da noi l'output del template Testo è già lungo così:
Se vogliamo mettere altre due icone dobbiamo togliere qualcos'altro. Si noti ad esempio, nei nostri "Ultimi arrivi", l'abbondanza di anni di pubblicazione duplicati. Io lascerei solo l'ultimo, quello che accompagna città ed editore. IMHO si può togliere anche la lingua originale.--Erasmo Barresi (disc.) 07:42, 22 lug 2016 (CEST)[rispondi]
bello bello e soprattutto utile e chiaro. Non so se hai già ridotto le icone che io vedrei ancora un pochino più piccole (ma è un dettaglietto). Immagino che toglierai il link "Scarica come epub" per cui, a questo punto, suggerirei di eliminare anche "Informazioni sul testo" e l'icona libretto non (imho) immediatamente comprensibile creando poi una linguetta "Testo a fronte" a destra di "Testo". Il tutto derindondando così. Domanda: stai facendo una revisione generale dell'intestazione o lavori solo la parte alta? Perchè avrei un paio di cosette sul campo "Ricerca" (si, si, sempre lui! :)(forse sarebbe da spostare la discussione in pagina più globale sull'Intestazione?) Silvio Gallio (disc.) 07:39, 22 lug 2016 (CEST)[rispondi]
@Erasmo Barresi Vero, sarebbe meglio togliere il primo anno e la lingua (anche perché a volte è un'indicazione sbagliata: non è detto che la traduzione sia avvenuta direttamente dalla lingua originale!) @Silvio Gallio 1) le ho ridotte già un pochino; 2) immagini giusto; 3) la linguetta è un po' più problematico, ma in effetti sarebbe bello fondere icona, link "Info fonte" e linguetta tutto in uno; 4) la mia idea è cominciare facendo un passetto alla volta, perché meglio un uovo oggi, uno domani e uno posdomani, che una maxifrittatona chissà quando. Can da Lua (disc.) 10:12, 22 lug 2016 (CEST)[rispondi]
Se capisco bene l'approccio di @Candalua, la barra download mi piace e la trovo chiara e funzionale. Aggiungerei forse una scritta chiarificatrice: "Scarica" o "Download".
Esteticamente non è molto coordinata con la nostra intestazione rosina, ma forse si risolve facendo come i francesi e creando una "barra download" che stacchi l'intestazione. Se lo facciamo, io sarei pure per metterla a breve in ogni testo toglieno "Scarica come epub" in intestazione, in attesa di una futuro rivisitazione totale del template Intestazione sull'onda dell'ottimo prototipo di @Erasmo Barresi (di fatto, la barra sopra potrebbe essere uguale). Aubrey (disc.) 11:50, 22 lug 2016 (CEST)[rispondi]

Qualcuno sa o intuisce il motivo per cui sia en.source che fr.source propongono per il download il pdf-A5 e non il pdf-A4? Forse per gli ebook reader; ma se io devo leggere su Kindle o Kobo scarico il mobi o l'epub, mentre il pdf è più per la lettura su pc e la stampa... giusto?--Erasmo Barresi (disc.) 22:14, 24 lug 2016 (CEST)[rispondi]

17:14, 11 lug 2016 (CEST)

Template Ricerca in Intestazione modifica

@Accurimbono Non so se ho capito bene la tua richiesta di "centratura", va bene così? Ho anche rimpicciolito un pochino il font. Se non ho capito basta annullare l'ultima modifica al template {{Ricerca}}. --Alex brollo (disc.) 09:15, 12 lug 2016 (CEST)[rispondi]

@Alex brollo Va benissimo, grazie. --Accurimbono (disc) 09:31, 12 lug 2016 (CEST)[rispondi]
Scorse un po' di pagine ns0 vedo un caso in cui (inevitabilmente) il sistema non funziona: nel caso delle "pagine-raccolta", in cui le opere elencate nell'indice NON hanno lo stesso prefisso della pagina ns0. Esempio: Tragedie di Sofocle (Romagnoli) I. Tuttavia, siccome in questo caso tutte le pagine nsPagina hanno un prefisso comune, Pagina:Tragedie di Sofocle (Romagnoli), infilando un template ben fatto in nsIndice, oppure (manualmente) anche in ns0, si potrebbe ottenere la ricerca nell'intera raccolta. Verifico se un Ricerca in Sommario dà problemi. --Alex brollo (disc.) 15:05, 12 lug 2016 (CEST)[rispondi]
A mio avviso questo deriva dal fatto che il compromesso è a monte: non esiste un metodo ad hoc che permetta di cercare all'interno di un libro (ns0) per cui ci appoggiamo alla ricerca col prefix. Ovviamente se uso prefix=Orlando faccio ricerche dentro a "Orlando furioso", "Orlando innamorato", "Orlando (1532)", ecc.
Trattandosi di un compromesso questa scelta viene inevitabilmente trascinata ai livelli successivi, compresa la difficile generalizzazione del metodo. --L0ll0 (disc.) 15:24, 12 lug 2016 (CEST)[rispondi]
Il problema è che non si può passare un parametro a un template stando in modalità visualizzazione. Si possono passare in fase di edit, è quello che ho fatto in Indice:Tragedie di Sofocle (Romagnoli) I.djvu dove ho potuto impostare (grazie a com'erano costruiti i nomi dei tre indici) la ricerca su tutte le pagine dei tre indici ossia, su tutte le tragedie di Sofocle che l'umanità possiede oggi. In realtà il template Ricerca, e la sottostante estensione inputbox, non fanno altro che costruire una query API, quindi, volendo fatica', potremmo costruirci un nostro javascript che faccia la stessa cosa, e di più (ad esempio, potrebbe far comparire l'output in un dropbox), anche dalla modalità visualizzazione; ma penso che non ce ne sia l'esigenza. --Alex brollo (disc.) 15:52, 12 lug 2016 (CEST)[rispondi]

Category loop detected modifica

Ciao from Australia! I'm sorry for writing in English. I'm attempting to find the root cause of what looks like a category loop:

   [0] => Una_speranza - Categoria:CantaStoria
   [1] => Una_speranza - Categoria:Canti
   [2] => Una_speranza - Categoria:Canti-U
   [3] => Categoria:Canti-U - Categoria:Canti_in_ordine_alfabetico
   [4] => Categoria:Canti_in_ordine_alfabetico - Categoria:Canti
   [5] => Categoria:Canti_in_ordine_alfabetico - Categoria:Testi_musicali_in_ordine_alfabetico
   [6] => Categoria:Testi_musicali_in_ordine_alfabetico - Categoria:Testi_delle_arti_performative_in_ordine_alfabetico
   [7] => Categoria:Testi_musicali_in_ordine_alfabetico - Categoria:Testi_musicali
   [8] => Categoria:Testi_musicali - Categoria:Musica
   [9] => Categoria:Testi_musicali - Categoria:Testi_delle_arti_performative
   [10] => Categoria:Testi_delle_arti_performative - Categoria:Arti_performative
   [11] => Categoria:Testi_delle_arti_performative - Categoria:Testi_delle_arti
   [12] => Categoria:Testi_delle_arti - Categoria:Arti
   [13] => Categoria:Testi_delle_arti - Categoria:Categoria:Testi_delle_arti
   [14] => Categoria:Categoria:Testi_delle_arti - Categoria:Arti
   [15] => Categoria:Categoria:Testi_delle_arti - Categoria:Categoria:Testi_delle_arti

The trouble comes with Categoria:Testi_delle_arti: it appears to somehow be in the category Categoria:Categoria:Testi_delle_arti — but there's nothing about that in the text of the former (not that the latter category doesn't exist, but if you open it you'll see that Testi_delle_arti is listed as a subcategory). Can anyone please tell me what I'm doing or seeing wrong? Thanks! (And double-thanks for hosting a brilliant Wikimania, by the way.)

Samwilson (disc.) 14:29, 13 lug 2016 (CEST)[rispondi]

@Samwilson hi from Italy! =)
Looking at the Categoria:Testi_delle_arti history on 11 november 2015 a bot added the category Categoria:Categoria:Testi_delle_arti. Then Utente:Accurimbono revert the edit. Curiously the page remained in the wrong category...
Right now I've tried to re-save the page without the wrong category Categoria:Categoria:Testi_delle_arti. My edit doesn't appear in the history, but the category loop seems disappeared! Maybe a bug? --L0ll0 (disc.) 15:11, 13 lug 2016 (CEST)[rispondi]
Thanks @L0ll0! That's really strange. But well done fixing it, that's cool, and confusing. :) (BTW, I maintain a tool that tells me about category loops sometimes, is how I found out about it.) —Samwilson (disc.) 04:00, 14 lug 2016 (CEST)[rispondi]

Categoria di errore esoterica modifica

E' comparsa improvvisamente una categoria rossa Categoria:Pagine che utilizzano tag HTML auto-chiusi non validi che comprende, aimè, tre pagine che ho creato io in ns0. Non capisco! :-( Nelle pagine non mi sembra ci sia niente che non va, inoltre se l'errore fosse nelle pagine nsPagina che vengono transcluse mi aspetterei che anche loro fossero elencate nella categoria. Help! --Alex brollo (disc.) 06:17, 14 lug 2016 (CEST)[rispondi]

La categoria si sta lentamente popolando.... e sempre con pagine fatte da me! :-( --Alex brollo (disc.) 06:40, 14 lug 2016 (CEST)[rispondi]
Ne è comparsa un'altra analoga molto più popolata: Categoria:Pages using invalid self-closed HTML tags :-( --Alex brollo (disc.) 06:42, 14 lug 2016 (CEST)[rispondi]
@Alex brollo tranquillo, non sei appestato. ;-)
Come scritto su Phabricator e su Gerrit hanno cominciato a segnalare quei tag che sono diventati obsoleti con l'HTML5, standard ora usato anche da tutti i progetti WikiMedia. Praticamente i tag come <hr> e <br> una volta si chiudevano con una slash finale <br />, ora non è più accettato. Le pagine che contengono il modo vecchio vengono inserite in quelle due categorie in attesa di essere modificate. Ovviamente se il tag è in un template questo viene ripetuto ad ogni inclusione. --L0ll0 (disc.) 07:21, 14 lug 2016 (CEST)[rispondi]
Ok, le categorie si stanno lentamente popolando e non sono solo più pagine mie. Il codice html di queste pagine è fitto di tag <br /> prodotti - mi pare - dal server stesso. Un template che genera un <hr..../> è {{Rule}}, provo a togliere lo slash. --Alex brollo (disc.) 08:02, 14 lug 2016 (CEST)[rispondi]

──────────────────────────────────────────────────────────────────────────────────────────────────── In effetti il tag <poem>, ad esempio, sembra creare montagne di tag <br />. Suppongo che <poem> sia parte del core di MediaWiki o di un'estensione e che quindi su quello ci sia poco da fare se non aspettare eventuali patch... --L0ll0 (disc.) 08:29, 14 lug 2016 (CEST)[rispondi]

Una cosa possiamo farla: creare le due categorie come categorie nascoste ;-) Alex brollo (disc.) 09:13, 14 lug 2016 (CEST)[rispondi]
..Azz! Sono sempre stato convintissimo che la grafia <br /> con spazio tra br e slash fosse quella definitiva in XHTML... dovrò rimangiarmi quanto avevo detto ai miei studenti. - εΔω 09:22, 14 lug 2016 (CEST)[rispondi]
@OrbiliusMagister credo che in XHTML sia ancora vero. Il fatto è che l'HTML a volte segue regole leggermente diverse. Trovi alcuni esempi su pedia alla pagina Elemento HTML#Tipologie e alcuni cenni sull'argomento anche alla pagina XHTML. --L0ll0 (disc.) 10:43, 14 lug 2016 (CEST) [rispondi]

A proposito, come andrà gestito il tag <references /> presente nel Template:Sezione note di migliaia di pagine? - εΔω 09:24, 14 lug 2016 (CEST)[rispondi]

Quello ed altri sono pseudo-tag html, il software di estensione li trasforma in html, per fortuna non c'entrano. In ogni caso, penso che possiamo ignorare, ma mi infastidisce il fatto che in fr.source l'errore non compare. da noi l'errore compare anche in pagine completamente svuotate, tranne Intestazione e Qualità: il problema dovrebbe stare quindi là dentro. Alex brollo (disc.) 09:46, 14 lug 2016 (CEST)[rispondi]
Il tag <br /> è anche quello inserito dal pulsantino "Nuova riga" nella barra degli strumenti. --BluesBrothers (disc.) 10:24, 14 lug 2016 (CEST)[rispondi]

Momento momento momento. Intanto non confondiamo HTML5 con altri standard come XHTML, che è una cosa diversa. Inoltre non mi pare che il problema siano i br. Da quel che so, in HTML5 il formato raccomandato è <br>, ma anche <br/> e <br /> sono accettati. Ciò che invece credo sia vietato è chiudere i tag che prevedono un contenuto: ad esempio non si può scrivere <div/>, <span/> e simili. Quindi, almeno da quello che ho capito io, la deprecazione si riferisce solo a questi ultimi. In effetti avevamo uno <span/> nel template Intestazione, ora l'ho tolto e vediamo se la categoria si spopola. Can da Lua (disc.) 10:56, 14 lug 2016 (CEST)[rispondi]

Da 15.000 siamo scesi a sole 76 pagine :) A questo punto il problema sui template è risolto, queste pagine rimaste invece hanno dentro qualche tag scritto un po' a capocchia: ho visto dei center chiusi male, degli small inutilmente chiusi su sé stessi ecc. Cerchiamo di risolverli un po' alla volta. I <br /> invece l'hanno scampata per ora... almeno finché qualche furbone un giorno non decida di deprecare anch'essi, giusto per far perdere qualche migliaio di ore-lavoro ai programmatori di tutto il globo (cosa tutt'altro che improbabile, nel brutto mondo in cui viviamo... del resto dicono che "è così che gira l'economia"... :D) Can da Lua (disc.) 11:38, 14 lug 2016 (CEST)[rispondi]
Santo @Candalua! :-D Aubrey (disc.) 12:00, 14 lug 2016 (CEST)[rispondi]

Ancora sulla disambiguazione autori - traduttori modifica

Cari amici,

mi trovo qui a replicare una necessità di chiarimento e ufficializzazione: abbiamo due casi non chiaramente documentati in Aiuto:Disambigua

  • Due traduzioni dell’Edipo re, una di Bellotti e una di Romagnoli
  • Due Elettra, una di Sofocle e una di D'Annunzio.

Come muoversi in sede di disambiguazione?

IMHO il flusso di lavoro, maturato dall'esperienza, è il seguente:

  1. Finché non ci sono motivi per disambiguare il primo arrivato prende posto (Pensieri inizialmente conteneva solo i Pensieri di Leopardi poi è divenuto disambigua con l'arrivo di altri Pensieri)
  2. Quando arrivano opere di ugual titolo si crea il problema, dunque se due testi di ugual titolo
    1. sono di due autori si spostano con titolo Titolo (Autore)
    2. sono traduzioni di un medesimo testo si spostano con titolo Titolo (Autore - Traduttore)

Attualmente il titolo Elettra dà una indebita precedenza a D'Annunzio rispetto a Elettra (Romagnoli), inoltre Elettra (Romagnoli) sembra il titolo un'opera scritta e non tradotta da Romagnoli. Questi vizi di forma vanno corretti con adeguate titolazioni e disambigue (che varranno anche per Edipo re che presenta un problema simile e altri titoli).

La mia proposta, che vorrei ufficializzare, è:

Mi rendo conto che questo secondo caso contiene una piccola forzatura rispetto al punto 1 del flusso indicato sopra ma mi sembra opportuno per coerenza nel caso si scopra che qualche autore moderno ha composto un testo originale dal titolo Edipo re. Dite la vostra. - εΔω 11:15, 14 lug 2016 (CEST)[rispondi]

Il primo caso mi pare perfetto, mentre mi chiedo se nel secondo dobbiamo fare
Edipo re --> Edipo re (Sofocle)
Il dubbio è: c'è qualche altro "Edipo re" non di Sofocle? Io farei solo una pagina Opera di Edipo re e basta... (mi viene anche in mente: Elettra di D'Annunzio c'entra qualcosa con la tragedia?) discriminare fra works differenti è un incubo e non c'è logica che tenga... Aubrey (disc.) 11:58, 14 lug 2016 (CEST)[rispondi]
Distrazione anche mia! Avevo preparato i testi di Romagnoli in un periodo diverso e non ho controllato possibili disambigue per i titoli. Userò titoli chiari già su Commons per evitare confusione. --Xavier121 14:40, 14 lug 2016 (CEST)[rispondi]
Ho provato a creare Opera:Edipo re (Sofocle) come da suggerimento di Xavier. Servirà una disambigua che riunisca, eventualmente, le diverse opere Edipo re, di autori diversi da Sofocle. Il collegamento fra work e edition basta farlo su wikidata?
Nota: occorrerebbe che il namespace Opera fosse aggiunto ai namespaces di default per la ricerca. Come si fa? A chi si chiede/si propone? Alex brollo (disc.) 16:04, 14 lug 2016 (CEST)[rispondi]
Bella domanda. E' un namespace vero? Cmq io chiederei a Nemo, che sa sempre tutto. Aubrey (disc.) 16:53, 14 lug 2016 (CEST)[rispondi]

Opera vs Disambigua modifica

Wow, Avevo scritto "Dite la vostra" e voi mi avete preso per Russel Crowe!

Intanto il caso Elettra è esplicativo: Vittorio Alfieri ha scritto una Antigone senza tradurre Sofocle. Ma non solo: Seneca ha scritto un Edipo senza tradurre Sofocle e magari a sua volta è stato tradotto da qualche oscuro traduttore secentesco con il titolo di Edipo re... le probabilità sono meno snowball di quel che si potrebbe ritenere a prima vista. Insomma, prevediamo il caso in maniera non sbrigativa.

Non avevo inserito il caso delle edizioni multiple di una medesima opera perché ritenevo pacifico che quello fosse il caso del nsOpera, e mi accorgo che dovevo precisare ulteriormente. Ora chiedo spiegazione: a cosa serve esattamente il nsOpera fintantoché già esistono le pagine di disambiguazione?

Io ho intuito, ma non ho la pretesa di aver capito perfettamente perché per un lungo periodo la mia presenza è stata assai ridotta, che il nsOpera servisse per identificare e raggruppare differenti edizioni di una medesima opera, dunque casi come i Canti di Leopardi piuttosto che le Vite di Vasari, ma guardando Opera:Odissea che contiene differenti traduzioni (Omero non può aver prodotto alcunché che possa definirsi edizione nel senso moderno del termine) o ad esempio Opera:Il castello di Otranto che di fatto non disambigua alcunché, capisco che la mia latitanza da Wikidata mi rende incapace, e che qualcosa sta sfuggendo al controllo delle disambigazioni. Dove posso trovare della documentazione a descrizione dell'uso del NsOpera che spieghi quando usarla al posto della familiare pagina di disambiguazione? - εΔω 17:18, 14 lug 2016 (CEST)[rispondi]


@OrbiliusMagister non dimenticare che una traduzione è anche una edizione. Ciò che hai scritto si potrebbe modificare così: "il nsOpera serve per identificare e raggruppare differenti edizioni o traduzioni di una medesima opera". E l'Odissea è sempre la stessa opera, può averla tradotta chi vuoi, ma sono sempre partiti dal testo di Omero (ok, dai vari testi tramandatici sotto quel nome). Qualcuno lo ha poi usato anche in casi in cui possediamo 1 sola edizione, cosa a cui sono contrario. @Aubrey certo che è un namespace vero, lo abbiamo fatto creare apposta. ;) Can da Lua (disc.) 17:50, 14 lug 2016 (CEST)[rispondi]
@OrbiliusMagister La pagina disambigua serve a districare problemi di omonimia: sotto Canti o Pensieri ci sono opere completamente diverse, ed è giusto riuscire ad orientare il lettore. La pagina Opera, come dice bene sopra Candalua, cerca invece di raggruppare edizioni o traduzioni di quello che si riconosce come un'unica opera. Ribadisco che in realtà i casi possono essere anche più complicati, ma tendenzialmente è così. La pagina Opera poi è importante perchè appunto ci facilita la vita su Wikidata, in cui è ancora più importante fare chiarezza. Nulla vieta, infine, di avere pagine disambigua che linkino a pagine opera... Penso per es. ad una bella pagina Edipo, che raccolga magari la trilogia e altre opere dedicate a. Aubrey (disc.) 18:08, 14 lug 2016 (CEST)[rispondi]
Vedo un po' di luce in fondo al tunnel... mi sono devastato il cervello con la questione opera/edizione, per un po' in penosa solitudine, adesso sono totalmente d'accordo con Candalua. L'opera è l'entità astratta - ma anche concreta - Edipo re creata da Sofocle, con un unico item wikidata su cui puntano tutte le edizioni e traduzioni del mondo. Dirò di più, io ci farei puntare anche eventuali sommari; ma non opere derivate da o ispirate a, che aggiungano qualcosa di "creativo" e che comunque saranno connesse a Edipo re con le apposite proprietà diverse da edizione di. Quindi, pagina Opera:Edipo re (Sofocle) senza dubbio. Su wiki c'è una bella pagina di disambigua fra opere Edipo re. Alex brollo (disc.) 19:15, 14 lug 2016 (CEST)[rispondi]

Tech News de noaltri :-) modifica

Ho già avvisato Candalua che ho manipolato gli script che consentono il calcolo del numero versi (con continuazione del numero della pagina precedente). Le modifiche dovrebbero risultare invisibili, tutto funziona come prima, tranne dettagli tecnici. Occhi aperti.... --Alex brollo (disc.) 15:34, 14 lug 2016 (CEST)[rispondi]

Proposta convenzioni per le pagine opera modifica

Sottopongo questo alla vostra attenzione. Si tratta di una pagina che chiarisce lo scopo delle pagine opera e propone una struttura fissa, che ho pensato diversa nel caso di opere tradotte da altre lingue. Mi pongo anche una domanda cui al momento non saprei cosa rispondere: in che misura è opportuno inserire link a edizioni (scansioni o trascrizioni) presenti su altri siti, a parte ovviamente Wikilivres?--Erasmo Barresi (disc.) 11:17, 15 lug 2016 (CEST)[rispondi]

Bene la pagina, anche se non capisco perché sotto Progetto:Qualità e non sotto Aiuto:. Secondo me è sempre opportuno mettere i link esterni, a condizione che siano fonti attendibili: in fondo il nostro scopo è quello di facilitare l'accesso ai testi, quindi se un testo non è presente in WS non ci vedo nulla di male a linkare un altro sito; e ciò può anche aiutare chi volesse caricare quel testo. Can da Lua (disc.) 11:47, 15 lug 2016 (CEST)[rispondi]
Da spostare sotto Aiuto: se un po' tutti sono d'accordo :-) Erasmo Barresi (disc.) 12:40, 15 lug 2016 (CEST)[rispondi]
La pagina di Aiuto dovrebbe contenere molte altre informazioni: in primo luogo spiegare quali proprietà mettere nell'elemento Wikidata affinche il tl {{Opera}} funzioni. (vanno indicate tutte le proprietà applicabili e fare per ciascuna un esempio, come fatto in Aiuto:Come_compilare_il_template_autore#Le_variabili_da_inserire_su_Wikidata)
Non metterei come esempio la pagina Opera dei Promessi sposi perché è molto complessa e del tutto particolare, io scegliere come esempio una pagina Opera completa ma più semplice. --Accurimbono (disc) 15:21, 17 lug 2016 (CEST)[rispondi]
Se chi sa farlo completa per bene Opera:Edipo re (Sofocle) quella pagina potrebbe essere un buon candidato, chiarisce anche il rapporto logico fra opere e loro diverse traduzioni. --Alex brollo (disc.) 09:28, 18 lug 2016 (CEST)[rispondi]
Ho indicato le proprietà Wikidata da inserire in ogni item opera. Adesso mi pongo due nuove domande: bisogna creare una pagina opera anche quando su it.source c'è una sola edizione dell'opera? la pagina opera deve contenere link a tutte le edizioni/traduzioni presenti su tutte le edizioni linguistiche di Wikisource?--Erasmo Barresi (disc.) 13:26, 25 lug 2016 (CEST)[rispondi]
@Erasmo Barresi secondo me: 1) ha senso creare la pagina opera se ci sono più edizioni, o comunque se ci sono altre edizioni rilevanti da elencare (magari con link esterni), o se l'opera ha una storia editoriale su cui vale la pena fare due cenni. In altre parole: se la pagina opera non aggiunge nulla all'unica pagina edizione presente, meglio non crearla. 2) Sicuramente non deve contenere i link a tutte le edizioni anche in altre lingue; deve contenere i link a tutte le edizioni italiane disponibile, e può indicare le edizioni presenti nella lingua originale, e forse anche in altre lingue se si tratta di edizioni particolarmente rilevanti per qualche motivo. Can da Lua (disc.) 13:40, 25 lug 2016 (CEST)[rispondi]
1) Io creerei sempre la pagina opera per coerenza: cosicché possiamo, ad esempio, avere sempre gli stessi link in uscita nella pagina autore e nella pagina ns0.
2) Il criterio di Candalua di considerare obbligatori solo i link a edizioni italiane e facoltativi tutti gli altri può funzionare.--Erasmo Barresi (disc.) 14:07, 25 lug 2016 (CEST)[rispondi]

──────────────────────────────────────────────────────────────────────────────────────────────────── Non entro nella questione link obbligatori o opzionali (non ci ho riflettto molto, anche se la proposta di Candalua mi pare ottima), ma io sarei assolutamente per non creare una pagina Opera per ogni libro che possediamo. L'astrazione "opera" è stata inventata dai bibliotecari per mettere ordine ad un limitatissimo (numericamente) segmento della popolazione dei libri, letteralmente uno su un milione. La stragrande maggioranza dei libri avrà sempre uno e una sola edizione (neanche traduzioni). Certo, qui su Wikisource e anche su Pedia cerchiamo di mettere libri importanti, per cui con traduzioni e varie edizioni. Ma la cosa più semplice e chiara (anche se forse non la più "logica") è avere pagine Opera quando servono, e linkare ad esse un item su Wikidata creato ad hoc. Dopo quasi due anni che periodicamente sbattiamo contro questo problema (qui e su Wikidata) mi sono convinto che sia la cosa più sensata da fare che di fatto ci da meno problemi, ed è chiara anche per un utente esterno che si vedrebbe praticamente 3 pagine per libro (ns0, Opera e Indice)... Aubrey (disc.) 18:24, 25 lug 2016 (CEST)[rispondi]

Futuro template AutoreCitato modifica

Ciao a tutti, mi è venuto in mente che, per il nostro beneamato {{AutoreCitato}}, sarebbe forse possibile pensare ad un (futuro) miglioramento: cioè usare Wikidata.

L'idea è quella di avere un qualcosa tipo:

{{AutoreCitato|Q1067|Dante Alighieri}}

Un template AutoreCitato che vada a prendere il suo Q... da Wikidata: se facessimo così, sarebbe più semplice, anche in futuro, poter distinguere gli "autori" citati da semplici personaggi citati. Cioè si potrebbe sempre sapere, tramite Wikidata, se una certa persona citata è un autore (presente su Wikisource) piuttosto che un vero personaggio storico presente su Wikipedia. Avremmo automaticamente a disposizione milioni di persone (e personaggi letterari (magari appunto citati in un'opera diversa dall'originale) senza dover creare pagine Autore apposta.

Non sono ancora sicuro di tutto quello che si potrebbe fare e dei vari possibili problemi, ma sarebbe molto bello per "unificare" i template e i wiki ed interlink... Non avremmo più quindi wikilink a WS e interlink a WP, ma solo lo stesso template. Per l'utente sarebbe quasi uguale (lui dovrebbe sempre "taggare" una parola sul libro, e scrivere il nome esteso della persona), mentre il resto verrebbe fatto da un bot su labs o simile... Ovviamente, se la cosa va bene per le persone, si potrebbe fare con i testi ecc.

Che ne dite? Ha senso? Quanto sarebbe complicato scrivere il bot e mantenere il tutto? Aubrey (disc.) 10:38, 16 lug 2016 (CEST)[rispondi]

Wikidata comporta una vera rivoluzione concettuale, ci metteremo molti anni a digerirla. Il concetto è: niente ripetizioni di dati; se un dato è su wikidata, non dev'essere da nessun'altra parte. Quindi sono d'accordo.
Vedo due problemi:
1. come selezionare l'elemento wikidata giusto (non può farlo un bot!), occorre organizzare uno script che legga wikidata e costruisca un elenco chiaro di item fra cui scegliere quello giusto a cura dell'utente; la ricerca dovrebbe essere fatta per similitudine.
2. come costruire un "qualcosa" (penso, un popup) che permetta immediatamente di visualizzare le informazioni rilevanti passando sopra all'output del template; per noi le "informazioni rilevanti" sono innanzitutto la presenza di una pagina Autore ma soprattutto la presenza di opere dell'autore su wikisource.
3. un'alternativa al punto 1 è continuare a usare autoreCitato come lo usiamo adesso, ma una volta che esiste la pagina autore aggiungere via bot il link a wikidata dentro il template, e potremmo farlo immediatamente con un parametro "nominale" aggiuntivo (wikidata=).
Quindi qualcosa del tipo:
{{AutoreCitato|wikidata=Q1067|Dante Alighieri}}
Alex brollo (disc.) 16:35, 16 lug 2016 (CEST)[rispondi]
Hai ragione, bisogna pensare al template a regime e alla fase attuale, in cui bisogna ancora operare la transizione da all'uno all'altro. Io credo che la forma finale debba essere come la tua, così è leggibile da tutti, umani e bot. la grande maggioranza dei template attuali ha sempre il doppio parametro, per cui credo davvero potremmo iniziare a sostituirlo con il corrispondente Q di Wikidata. Un popup che in base al nome (magaricon l'autocomplete!) mostri l'item su wikidata sarebbe fantastico... Ma non ho ancora visto nulla del genere. Aubrey (disc.) 19:39, 16 lug 2016 (CEST)[rispondi]
Ci sono già i bengalesi che aspettano i nostri progressi su questo template :-) Aubrey (disc.) 22:01, 16 lug 2016 (CEST)[rispondi]
Wait! Stiamo creando qualcosa di diverso, quindi meglio cambiargli il nome. L'osservazione più ovvia è che, potendo ora il template linkare anche a persone non-autori, non ha più senso chiamarlo AutoreCitato. Ma posso andare un tantino più in là: perché non abolire del tutto la distinzione tra AutoreCitato e TestoCitato? La categoria sarebbe "Edizioni in cui è citato il soggetto dell'elemento Wikidata Q...", mentre il link dovrebbe puntare alla pagina di Wikisource collegata, se esiste, altrimenti alla pagina di Wikipedia collegata, se esiste, altrimenti niente link fino alla creazione di una delle due. Ma a questo punto... (tolerate this visionary for a moment, will you?) si potrebbe usare questo template generico "CitazioneWikidata" per linkare anche ad altre cose che non sono persone né testi. Ricordo che una volta si voleva costruire un Portale:Italia e serviva un template per censire le citazioni di luoghi. Quindi si porrebbe il problema di quanto e che cosa è opportuno linkare... E qui mi fermo per il momento :-) Erasmo Barresi (disc.) 08:00, 17 lug 2016 (CEST)[rispondi]
@Erasmo Barresi teoricamente hai ragione, ma bisogna sempre fare i conti con Wikidata e cosa accetta. E intendo nel caso specifico non degli item, ma delle proprietà che poi noi dovremmo mappare su Wikidata.
Cioè: se io metto un AutoreCitato qui, idealmente vorrei su Wikidata avere una proprietà che dica "item Q123 cita l'autore Q321".
Proprio per fare questo, io in passato ho proposto ben 2 volte la proprietà mentions, ma due volte è stata rifiutata.
Mentre adesso invece è stata accettata un proprietà cita, che è ristretta ai documenti, nel senso di bibliografie. Se un articolo ha un libro in bibliografia, quell'articolo cita quel libro. Al momento è un proprietà che sta andando molto bene, ed equivale al nostro {{TestoCitato}}, che però, tristemente, è un template meno "corretto" di AutoreCitato, sul quale abbiamo lavorato molto di più. TestoCitato lavora con i titoli in ns0, e a volte usa dei redirect,...: insomma, dovremmo ricontrollarlo per poter usare l'analoga proprietà cites su Wikidata, ma si può fare e lo faremo (prima, dobbiamo mettere un item su WD per ogni libro, e ancora non ci siamo).
Tornando a noi, quello che voglio dire è che se su Wikisource possiamo fare quello che ci pare, su Wikidata no. I wikidatari sono molto "conservatori" nel creare nuove proprietà, perchè poi possono venire usate male da altri utenti.
Per questo, l'idea visionaria di citare luoghi, personaggi, libri, ecc. è assolutamente fattibile qui da noi, mentre non lo è su Wikidata. Per questo, forse, mi piacerebbe essere prudente, e avere inizialmente template distinti per autori e testi e altro, in modo da poter poi lavorare su Wikidata in maniera coerente e senza dover impazzire per imporare là le relazioni con le giuste proprietà... Spero di essermi spiegato. Aubrey (disc.) 12:04, 17 lug 2016 (CEST)[rispondi]
Ho visto la discussione sulla proprietà "mentions" e... devo dire che condivido il loro approccio (cioè: collegare due item solo quando uno rappresenta il main topic dell'altro; non farlo se un compilatore ottocentesco si è ritrovato a menzionare di sfuggita la Retorica di Aristotele in una sua prefazione). Anzi, anche le nostre categorie "Testi in cui è citato..." sono un tantino forzate; del resto abbiamo il tool "PuntanoQui", per cui quelle pagine sarebbero in ogni caso rintracciabili anche senza categoria. Capisco che ad @Aubrey piace l'idea della biblioteca ipertestuale, ma mi chiedo: anche adesso, in quanti tra i visitatori del sito consultano quelle categorie? e in quanti ne tirano fuori qualcosa di utile? Il mio punto è che la categoria, o la corrispondente proprietà su Wikidata, è di gran lunga meno importante dell'esistenza, e della stabilità, dei link stessi.
Ciò non toglie che i template possano essere tenuti separati in per facilitare un'eventuale manutenzione futura. Dico solo che non dovremmo perderci la testa.--Erasmo Barresi (disc.) 14:15, 17 lug 2016 (CEST)[rispondi]
Il discorso mentions al momento è caduto: io lo riporterei su solo per la citazione di autori, il che lo renderebbe più circoscritto e forse più accettabile. Da un certo punto di vista io credo sia interessante sapere se in un a prefazione una autore cita un'altro autore o meno: certo, sapere chi e quanto cita Shakespeare o Dante diventa un esercizio lezioso, ma invece nella "coda lunga" dei testi più piccoli credo che la cosa abbia un suo senso. Come dici tu (almeno, come interpreto io) l'esistenza del link è in sè un qualcosa di interessante, su cui il lettore può cliccare se interessato. Esattamente come su Wikipedia. Il fatto che noi ci attacchiamo delle categorie secondo me è una cosa in più che serve "per il futuro", perchè può essere eventualmente utile (inoltre, non ci costa nulla farlo). La proprietà su Wikidata secondo me è molto interessante per il TestoCitato, soprattutto quando parli di articoli scientifici contemporanei e puoi fare cose del genere... Io credo che Wikisource possa strutturarsi bene anche per il futuro e mi piacerebbe far capire che con una semplice rilettura si scala bene fino a fornire strumenti utili per gli accademici. E' inoltre uno dei valori aggiunti di Wikisource. Sono d'accordo con te che adesso li userà poca gente, ma il mio istinto mi dice che la direzione è quella giusta (poi, magari, il mio istinto si sbaglia). Aubrey (disc.) 14:35, 17 lug 2016 (CEST)[rispondi]
Scusate! Prima ancora di leggere quello che avete scritto mi correggo: io non abolirei affatto i due parametri attuali, aggiungerei il parametro aggiuntivo wikidata. Sono stato indotto in errore copiaincollando Aubrey :-(. Quindi:
{{AutoreCitato|wikidata=Q1067|Dante Alighieri|Alighieri}}
o ancora meglio:
{{AutoreCitato|Dante Alighieri|Alighieri|wikidata=Q1067}}
che è più leggibile per un umano e non modifica per nulla le attuali abitudini. --Alex brollo (disc.) 00:12, 18 lug 2016 (CEST)[rispondi]

A latere: palazzo alle Colonne (Palazzo massimo alle Colonne) funziona. Potrebbe andar bene se non fosse molto più scomodo a mettere. Sarebbe meglio quando manca la voce si it:wp. --Carlo M. (disc.) 12:59, 20 lug 2016 (CEST)[rispondi]

Se il Q di Wikidata è univoco perché su wikidata non si ripetono dati, l'autore non dovrebbe essere trovato direttamente dal bot? Ciò significherebbe che il template AC rimane così com'è, ma il link verrebbe generato in base al Q di wikidata Pic57 (disc.) 09:59, 23 lug 2016 (CEST)[rispondi]
Non so @Pic57 se ho ben capito quello che stai dicendo: di fatto, potrebbe essere possibile avere un bot che in base al nome va a vedere un autore, ma ci dovrebbe essere il modo per l'utente di sceglierlo tutte le volte... Nel senso che i casidi omonimia, io quelli in cui c'è uno pseudonimo o altro dovrebbero essere risolti da una persona. Se il tool è "complesso " e fatto bene si può fare, ma questo vuol dire cmq che qualcuno deve farlo... Aubrey (disc.) 20:38, 23 lug 2016 (CEST)[rispondi]
Sì @Aubrey, ma potrebbe essere che l'utente venga interpellato solo nel caso in cui la query non dia un risultato univoco su wikidata, elencandogli le alternative tra cui scegliere. E' già qualcosa, ma forse si può osare di più: come si comporta wikidata nei casi di omonimia non saprei, però si potrebbe aggiungere alla query qualche elemento che aiuti wikidata ad effettuare direttamente la scelta. Ad esempio: il tempo e il genere letterario possono essere dedotti automaticamente dal contesto. Intendo dire: se il testo in cui ricorre l'autore citato è di letteratura del XVII secolo e su wikidata c'è una omonimia con un calciatore, la scelta è bell'e che fatta. In sostanza WS deduce automaticamente dal contesto le categorie del tempo e dell'argomento aggiungendole alla query che va a wikidata e voglio vedere quanti casi di ambiguità ancora vengono fuori... e solo in quei casi interpello l'utente elencandogli le possibili alternative a partire dalla più probabile Pic57 (disc.) 00:08, 24 lug 2016 (CEST)[rispondi]
A questo punto vorrei chiedere agli esperti @Candalua, Erasmo Barresi, Accurimbono, Ricordisamoa avete mai visto un template su una wiki che riproduca l'autocomplete di Wikidata? Che permetta cioè, da un'altra wiki, in modalità edit, di fare query su Wikidata? Io non l'ho mai vista ma forse è ciò che ci serve. Aubrey (disc.) 13:26, 24 lug 2016 (CEST)[rispondi]
Io non l'ho mai visto, ma non ho molta esperienza in questo campo.
Essendo un template utilizzato in moltissime pagine, invito tutti alla massima cautela prima di una sua radicale modifica come quella proposta. Bisogna considerare tutte le eventualità: anche come gestire in automatico il fatto che su Wikidata l'item può variare (per unione di item duplicati ad esempio) e qui su Wikisource il template (o il bot che gestirà il template) dovrebbe gestire queste eventualità in automatico.
Inoltre siamo sicuri che l'item Wikidata non si possa già ora ricavare in automatico a partire dal NS Autore indicato come parametro nel template? In fondo sono associati biunivocamente. --Accurimbono (disc) 14:16, 24 lug 2016 (CEST)[rispondi]
magari sì, ma non saprei. Però ad esempio questa API su wikidata mi restituisce nei campo id, concepturi, URL, title il Q dell'autore Luigi Pirandello
https://www.wikidata.org/w/api.php?action=wbsearchentities&search=Luigi%20Pirandello&language=it
Basterebbe nella variabile search sostituire il valore Luigi Pirandello con quello dell'autore citato.
Insieme a Q mi restituisce tante altre cose che magari qualcuno che sa di wikidata sa come scartare. Certo cautela prima di cambiare il bel template AC di WS anche perché finire su wikidata direttamente dà un effetto di straniamento, con tutto quel popo' di roba. Invece finire sulla pagina autore di WS mi sembra più immediatamente utile al lettore e da lì semmai proporre il salto su Wikidata dando il tempo di acquisire consapevolezza di dove si sta andando a finire Pic57 (disc.) 18:08, 27 lug 2016 (CEST)[rispondi]
Per potersi fare, si fa. Io non ho ancora le idee chiarissime, ma al momento non penso di cambiare il funzionamento visibile, ma quello invisibile. Cioè vorrei che il template AC potesse da subito prendere il Q dell'autore, e, se l'autore è presente su Wikisource, mandarlo alla pagina Autore. Se no, mandarlo a Wikipedia (ma mai a Wikidata). Aubrey (disc.) 19:18, 27 lug 2016 (CEST)[rispondi]
Concordo con Aubrey. --Accurimbono (disc) 04:20, 6 ago 2016 (CEST)[rispondi]

Wikisource Search modifica

Nel frattempo, l'ottimo @Samwilson sta lavorando ad un estrattore di metadati dalle varie Wikisource, in modo da poter esportare i dati tutti insieme, e iniziare (fra gli altri) il lavoro su Wikidata. Aubrey (disc.) 14:42, 17 lug 2016 (CEST)[rispondi]

Ehehehe.... auguri Sam... il problema non è estrarre i dati, ma verificarne la congruenza... spero che Sam abbia molta pazienza. :-) --Alex brollo (disc.) 00:23, 18 lug 2016 (CEST)[rispondi]
Se riusciamo ad estrarli, io proverò a pulirli un pochino con OpenRefine, e a fare qualche import su Wikidata. Però estrarli è già importante :-) Aubrey (disc.) 10:42, 19 lug 2016 (CEST)[rispondi]

Link rosso esplicativo in campo oggetto automatico modifica

qui ho notato che l'oggetto automatico crea un link esplicativo "(Etichetta: Modifica visuale)" ma rosso. ergo non "esplica" come dovrebbe (ovviamente capisco grossomodo di che si tratta, ok, manca Wikisource:VisualEditor).

E' sempre stato così? Non me ne sono mai accorto perché quasi nessuno usa il VE qui su wikisource?--Alexmar983 (disc.) 18:19, 17 lug 2016 (CEST)[rispondi]

Nessuno lo usa, c'è da 10 giorni circa, e non ho neanche guardato quali pagine bisognerebbe creare/tradurre. Se hai voglia tu... :-D Aubrey (disc.) 18:58, 17 lug 2016 (CEST)[rispondi]
Bluificato, sulla base dell'esempio in en.source (sono poche parole....). Commento OT: al momento, usare VE in nsPagina è piacevole come darsi una martellata su un dito (soprattutto nelle opere che contengono poem)--Alex brollo (disc.) 00:21, 18 lug 2016 (CEST)[rispondi]
Alex brollo nella mia esperienza (e i sono uomo di wiki-mondo, anche se non ho fatto il militare a Cuneo) il VE si è sempre rivelato "piacevolissimo" ovunque sono stato... ho rinunciato a capirlo, ogni tanto lo apro ma regolarmente lo chiudo. C'ho i pregiudizi lo so, che ci posso fare.--Alexmar983 (disc.) 07:10, 19 lug 2016 (CEST)[rispondi]
Alexmar983 Un ritardo anche brevissimo nella risposta all'input di tastiera mi affligge profondamente, e il fatto di non capire completa la misura, per me.... e quel poco che capisco mi pare bizantino, una "lectio difficilior" che evito volentieri. Sarà l'età. Largo ai giovani.... --Alex brollo (disc.) 07:59, 19 lug 2016 (CEST)[rispondi]
oh se son rose con i niubbi fioriranno... a me non sembrano siano davvero fiorite e se fioriscono mi fanno venire un po' l'allergia, ma suppongo che chi deve il suo stipendio all'iniziativa non avrà mancato di provare il contrario, in modo certo professionale o obiettivo. Lunga vita al VE. un giorno convincerà anche me, spero. Io mi sarei accontentato di almeno un tipo di edit in cui mi paresse più rapido, ma finora nisba.--Alexmar983 (disc.) 08:13, 19 lug 2016 (CEST)[rispondi]
Il VE è indubbiamente lentissimo, e certo non serve per chi come noi vuole fare in fretta e conosce tutti i comandi. Ma sarebbe molto interessante se ci facesse guadagnare una o due pagine lette per niubbo. Ricordatevi che qui la comunità ha deciso che le iconcine del SAL non ci sono per i non loggati (e anche per i loggati sono minuscole e quasi invisibili). Di fatto Wikisource, che ci piaccia o meno, è un progetto per power users e secondo me ogni tentativo che va nella direzione di incorporare altri utenti per me è corretto. Aubrey (disc.) 09:55, 19 lug 2016 (CEST)[rispondi]
Ottimo; però una cura ancora maggiore IMHO andrebbe dedicata a facilitare l'opera dei core contributors, che svolgono una bella parte del lavoro....no? Alex brollo (disc.) 13:10, 19 lug 2016 (CEST)[rispondi]

──────────────────────────────────────────────────────────────────────────────────────────────────── si e no, secondo me. Il fatto che su Wikisource ci siano solo core contributors e pochi passanti, a mio umile parere, è un difetto di Wikisource, non le permette di crescere davvero. Certo sarebbe bellissimo avere dozzine di core contributors, ma è più semplice tentare di avere dozzine di persone che ogni due giorni si rileggono una pagina. Di fatto, se guardi le statistiche, qui in pochissimi rileggono portando al 100%, che è comunque un'azione importante per noi (ancora più importante portare da niente a 75%, e difatto è quello che fanno i wikisourciani esperti, da sempre). Il punto è certamente che le innovazioni non devono frutrare troppo i vecchi utenti, ma personalmente benedico ogni esperimento (anche fallimentare) che cerca di guadagnarne anche solo uno facilitando il lavoro qui. Aubrey (disc.) 15:41, 19 lug 2016 (CEST)[rispondi]

Sono quasi d'accordo, sostituirei però quel "frutrare troppo" con "frustrare per niente" (abbi pazienza.... l'occhio del wikisourciano scova ogni typo in quello che scrivono gli altri... ;-) Alex brollo (disc.) 17:43, 19 lug 2016 (CEST)[rispondi]
Se vuoi aumentare i passanti ti faccio una campagna di messaging mirato che ti garantisco funziona meglio di un VE allo scopo
Qua mi limito a far notare come l'utenza assidua è in molti casi stata prima un'utenza sporadica: ciò che l'ha resa tale e l'ha fidelizzata è proprio essere messa in condizione di lavorare meglio alla pari. la dicotonomia delle "utenze nuove" e "vecchie" piace quando ci si preoccupa dei nuovi come "bambini", ma in concreto nella mia esperienza se c'è una cosa che fidelizza e motiva i nuovi arrivati è quando metti nelle loro mani qualcosa di raffinato, avanzato mostri loro che lo sanno usare, allora sì che si gasano. Tu dici loro fin dall'inizio che possono contribuire alla pari, quindi in poco tempo contribuiscono alla pari. Invece la mentalità dl VE non è inclusiva e infatti si è rinunciato da parte di molti a vederlo come un "catalizzatore". Del resto allo stato VE è stato introdotto su parecchie piattaforme ma davvero ha funzionato nell'aumentare i contributi sporadici? Non ho letto mai nulla di certo, anzi su itwiki si è investito più che da altre parti (per dire su altre wiki hanno detto "no grazie") ed è stato un po' "imbarazzante" scoprire che i mesi di introduzione VE e dl calo di itwiki coincidevano (guarda la discussione al bar). Alla fine VE nel migliore di casi non fece una differenza in positivo comunque. I nuovi sporadici non arrivano, i vecchi assidui si sono un po' assottigliati (e magari chissà avrebbero abbandonato di meno se si fosse resa la loro presenza più piacevole con tool diversi da VE) .
Se speriamo che porti qualche rilettura ok, ma come dissi allora: niente ipotesi vaghe e conferme a posteriori. Quanto abbiamo ora, quanto ci aspettiamo che VE faccia la differenza? 5%? 10%? Vediamo. Del resto oramai una volta pagato (e non mi pare "poco" almeno in termini di tempo investito) continuare a provarlo male non può fare...--Alexmar983 (disc.) 11:20, 20 lug 2016 (CEST)[rispondi]

Illustrazioni di libri: nome dei file modifica

Da un po' sto usando una comoda convenzione personale per il nome dei file immagine delle illustrazioni: nome base del file djvu+numero della pagina normalizzato a 4 cifre (0001, 0002...) per cui so a colpo sicuro come si chiama l'immagine del file xxxx.djvu, in pagina yy: si chiama senz'altro file:xxxx-00yy.jpg o qualche altro tipo file (.png, per esempio). Inoltre, per avere tutto sott'occhio, carico una galleria completa delle immagini in Discussione indice. Esempio: Discussioni indice:Commedie di Aristofane (Romagnoli) III.djvu. Mi ci trovo bene. --Alex brollo (disc.) 17:16, 18 lug 2016 (CEST)[rispondi]

22:18, 18 lug 2016 (CEST)

I castelli del Tirolo - un consiglio modifica

Per un'iniziativa che si svolgerà ai primi di Settembre a Trento vorremmo organizzare un laboratorio di rilettura in Wikisource di un testo significativo per la storia e il territorio trentino; abbiamo individuato questo bel testo di Agostino Perini, ricco di immagini molto belle e documentazione: "I castelli del Tirolo colla storia delle relative antiche potenti famiglie (1834-39"). Nella pagina autore in Wikisource il testo risulta in rosso, con un riferimento alle immagini di Google Books [26] Volevo chiedervi se secondo voi quelle immagini sono di buona qualità per il trasferimento qui, o se, come avevamo pensato prima di trovarlo in Google Books, è opportuno fotografare il nostro testo originale e inserire quello. Grazie per il consiglio --EusebiaP (disc.) 13:54, 19 lug 2016 (CEST)[rispondi]

Le pagine in testo vanno "lavorate" un po' ma sono IMHO soddisfacenti. Anche le figure sono di buona qualità, ma forse vale la pena di rifotografarle con ottima risoluzione per essere caricate separatamente come file immagine. In definitiva: produco un djvu dal testo Google, poi avendo voglia e tempo si potrà rifotografare, ricostruire e ricaricare. --Alex brollo (disc.) 15:54, 19 lug 2016 (CEST)[rispondi]
Nel frattempo tramite BUB lo sto caricando su IA, così Alex se vuoi puoi usare djvuCL. Aubrey (disc.) 16:25, 19 lug 2016 (CEST)[rispondi]
Grazie, in realtà ho scoperto che forse (ma devo verificarlo nei prossimi giorni) abbiamo già le foto ad alta risoluzione delle immagini (ma non del testo). Verifico e vi faccio sapere. Grazie --EusebiaP (disc.) 16:35, 19 lug 2016 (CEST)[rispondi]
Anyway, è qui. Aubrey (disc.) 17:29, 19 lug 2016 (CEST)[rispondi]
@Aubrey Bravo, ma puoi migliorare :-) : scaricati briss e impara a usarlo, è "magico" per croppare grossolanamente i file pdf, mantenendo identiche la risoluzione e perfino lo strato OCR: non estrae le immagini, non converte, agisce misteriosamente sul pdf come tale. E' un programma estremamente semplice e intuitivo. Non fa miracoli come Scantailor, ma fa molto bene quello che fa (splittare, croppare). Una croppatina, prima della conversione djvu, quel pdf la chiede ad alta voce. Alex brollo (disc.) 17:39, 19 lug 2016 (CEST)[rispondi]

──────────────────────────────────────────────────────────────────────────────────────────────────── @EusebiaP Ho il djvu dal testo Google Books "croppato" ma non sono soddisfatto: si tratta di tre volumi stampati indipendentemente (in date diverse) e rilegati insieme. Questo crea problemi perchè viola la regola: "un libro, un indice" con perfide conseguenze sulla numerazione pagine, metadati ecc. Se sei d'accordo caricherei tre djvu separati per tre indici separati (ovviamente collegati fra di loro). Alex brollo bis (disc.) 18:58, 20 lug 2016 (CEST)[rispondi]

Ciao @Alex brollo, grazie di tutto. Ho visto che il testo è caricato e che le immagini possono andare bene così. Va bene, per noi, la soluzione che hai scelto di caricarli separatamente. Devo anche dire che, proprio per il fatto che era già esistente un'edizione digitale di questo testo, per la nostra iniziativa abbiamo deciso di utilizzare altri testi, inediti in formato digitale, che abbiamo in biblioteca, sempre sulla storia e cultura trentine. Sono in arrivo quindi altre digitalizzazioni (con calma, da qui alla fine di agosto) di altri 4 o 5 testi che non ci sono in Google Books o Internet Archive. Essendo però questo di rilevanza trentina, lavoreremo anche su questo. Grazie ancora --EusebiaP (disc.) 08:55, 22 lug 2016 (CEST)[rispondi]
  •   @EusebiaP, Aubrey, Alex brollo Scusate ragazzi se intervengo per rompere i castellucci ma io sarei per rifare tutto daccapo! Immagini su GB pessime (molte con testo mancante - grossolanamente tagliate nella parte superiore); se esiste la possibilità di ripartire da zero con scansione a colori e immagini alta risoluzione, IMO, in ossequio agli altissimi standard del progetto qualità che rifugge come la peste google, consiglierei alle biblioteche di rifare il lavoro: da parte nostra tutta la disponibilità per formattazione e rilettura. Non esiste una regola precisa da seguire, solo un po' di buon senso, ma queste sono accasioni irripetibili per procurarsi OTTIME immagini da tramandare. Xavier121 09:36, 22 lug 2016 (CEST)[rispondi]
Testo mancante? Mi è sfuggito. Sta il fatto che sono fautore de "Meglio un uovo oggi che una gallina domani", tanto più che la gallina, volendo, potremo averla anche lei.... nulla impedisce di cominciare a sistemare il testo subito e di sostituire i File: con altri di migliore qualità in un secondo momento. Alex brollo (disc.) 10:59, 22 lug 2016 (CEST)[rispondi]
Come dicevo, dovremmo avere tutte o gran parte delle immagini già fotografate ad alta risoluzione, ma lo saprò con certezza fra una decina di giorni; se non le abbiamo ci vorrà un po' più di tempo, ma comunque possiamo farlo. Grazie a tutti --EusebiaP (disc.) 11:29, 22 lug 2016 (CEST)[rispondi]

Galoppata fuori casa modifica

Dopo una breve ma intensa galoppata "da sysop" in la.source e su Commons, porto a casa questo risultato: so come caricare files di dimensioni superiori ai famosi 100Mb (ho sostituito un pdf "grandino", di 1.9 Gby, con uno più compatto, di "soli" 111Mby).

PS: mi trovo ad essere sysop di la.source su invito, in quell'unica puntata da sysop che ho fatto un paio di giorni fa ho approfittato per importare il template {{non fatto|not done}} e rifiutare proposte di cancellazione di vari file, uno dei quali caricato da @Accurimbono. Ho agito come il classico sysop odioso ;-) --Alex brollo (disc.) 17:30, 19 lug 2016 (CEST)[rispondi]

@Alex brollo Quale file? --Accurimbono (disc) 03:18, 20 lug 2016 (CEST)[rispondi]
Ti avevo pingato qui... la:Vicifons:Deletiones_Propositae#May_2016. In realtà eri uno dei contributori, non "il caricatore", avevo guardato in fretta. --Alex brollo (disc.) 06:52, 20 lug 2016 (CEST)[rispondi]

Da cancellare per mancanza di fonte modifica

Vagando sul sito ho visto Donna Paola di M. Serao "Da cancellare per mancanza di fonte" una versione è in internet archive https://archive.org/details/donnapaola00sera se da qualche parte ci sono istruzioni aggiornate su come scaricare potrei provarci. Saluti --Utoutouto (disc.) 19:22, 19 lug 2016 (CEST)[rispondi]

@Utoutouto Buon divertimento! --Xavier121 20:24, 19 lug 2016 (CEST)[rispondi]
Per le istruzioni, Aiuto:Guida alla pubblicazione di un testo dovrebbe essere abbastanza aggiornata... Certo, visto che le pagine ns0 esistono già, vanno solo modificate per inserire il tag pages e non create ex novo tramite tool come descritto lì. --Erasmo Barresi (disc.) 08:15, 20 lug 2016 (CEST)[rispondi]
Il tool Match & split sembra bloccato, ho avvisato Phe. --Alex brollo (disc.) 13:31, 20 lug 2016 (CEST)[rispondi]
A posto, grazie @Phe --Alex brollo bis (disc.) 18:40, 20 lug 2016 (CEST)[rispondi]

WikiCon IT modifica

Salve a tutti! Con Jaqen e CristianNX ci è ci è venuta la pazza idea di organizzare una WikiConference italiana, su modello delle esperienze di altri paesi (ad es. quella tedesca). AlessioMela e altri si sono prontamente detti disponibili a dare una mano. Si tratterebbe, in breve, di una tre giorni (da venerdì alla domenica) di incontri fra utenti di Wikipedia e degli altri progetti Wikimedia. L'idea è di farla a Trento in primavera 2017. Abbiamo creato la pagina su Meta per chiedere finanziamenti a Wikimedia Foundation (l'idea è anche quella di coprire ai partecipanti vitto e alloggio, e a quanti possibile anche le spese di viaggio).
Al momento chiaramente è solo una bozza, ma è già possibile dare il proprio endorsement. Inoltre, per aiutarci a organizzare sarebbe importante avere un'idea di quanta gente potrebbe partecipare: se vi va potete farcelo sapere qui, nella talk su meta, via mail a me, ecc. So che senza nemmeno sapere quando sarà è difficile rispondere, ma ci basta anche un "forse parteciperò".
La sezione Partecipants su meta invece non è per chi semplicemente parteciperà, ma per chi dà una mano, e in effetti se avete voglia di dare una mano siete più che i benvenuti. Troveremo sicuramente qualcosa da farvi fare :)
Dite anche se avete idee sul programma (es. qualcosa di cui secondo voi bisognerebbe assolutamente parlare). Potete scriverlo qua, o direttamente a me. Chiaramente più avanti abbiamo intenzione di mettere in piedi un sistema meglio strutturato, ma intanto ci pare utile raccogliere idee.
In caso di qualunque dubbio, suggerimento, ecc. siamo a disposizione! --Yiyi 09:49, 20 lug 2016 (CEST)[rispondi]

Interessante, grazie per il messaggio. --Accurimbono (disc) 10:01, 20 lug 2016 (CEST)[rispondi]

Doppia categoria modifica

Segnalo che ci sono due duplicati: Categoria:Crema e Categoria:Crema (Italia). Bisognerebbe sceglierne una e cancellare l'altra (collegando quella giusta su Wikidata). --Superchilum(scrivimi) 11:56, 20 lug 2016 (CEST)[rispondi]

  Fatto Can da Lua (disc.) 12:19, 20 lug 2016 (CEST)[rispondi]

E un'altra cosa, se poteste aggiustare Categoria:Nati a Missouri perché proprio non si può leggere :) ho visto che viene generato automaticamente tramite template. --Superchilum(scrivimi) 11:59, 20 lug 2016 (CEST)[rispondi]

Il problema è proprio quello, è generato automaticamente e non sappiamo come fare a scegliere la preposizione giusta (e non vogliamo mantenere una serie di liste lunghissime di "parole che vogliono la preposizione nel", "parole che vogliono la preposizione nello" ecc.). Can da Lua (disc.) 12:19, 20 lug 2016 (CEST)[rispondi]
@Candalua Ok, allora potreste mettere direttamente la città di nascita, ovvero Montgomery City. --Superchilum(scrivimi) 09:23, 25 lug 2016 (CEST)[rispondi]
  Fatto aggiornato su Wikidata. Can da Lua (disc.) 09:56, 25 lug 2016 (CEST)[rispondi]

D'annunzio ossia ogni lasciata è persa modifica

Vedo su IA la serie completa di Laudi di D'Annunzio (questo il link al volume 1) con djvu che mi sembrano ottimi: io li acchiapperei, d'accordo? Intanto me li scarico per dargli una buona occhiata. --Alex brollo (disc.) 17:17, 20 lug 2016 (CEST)[rispondi]

Piglia tutto, D'Annunzio è importante. Aubrey (disc.) 17:33, 20 lug 2016 (CEST)[rispondi]
Ok, muovo IA upload --Alex brollo (disc.) 17:41, 20 lug 2016 (CEST)[rispondi]
IA Upload mosso. Vado agli Indici (annotadoli anche in pagina Autore) --Alex brollo (disc.) 18:08, 20 lug 2016 (CEST)[rispondi]
Al solito stte leggendo il mio pensiero. In questo momento sono in un momento di "grazia WiFi" in un lluogo di vacanza disconnesso dal mondo. Quando tornerò dalla disconnessione (grossomodo tra dieci giorni) sarò contento di dare una mano! - εΔω 16:18, 21 lug 2016 (CEST)[rispondi]

Pagine Bianche Notizie del bello, dell'antico, e del curioso della città di Napoli modifica

ad un passo dal completamento al 75% mi accorgo che le pagine https://it.wikisource.org/wiki/Pagina:Notizie_del_bello,_dell%27antico,_e_del_curioso_della_citt%C3%A0_di_Napoli.djvu/291 292 e 383 sono bianche e sfalsano i link di collegamento presenti nell'indice alfabetico https://it.wikisource.org/wiki/Pagina:Notizie_del_bello,_dell%27antico,_e_del_curioso_della_citt%C3%A0_di_Napoli.djvu/353 C'è qualcuno che può risolvere? Saluti --Utoutouto (disc.) 19:21, 20 lug 2016 (CEST)[rispondi]

Prova se si è sistemato (l'errore stava nel non aver sistemato per bene il pagelist) --79.20.9.14 20:43, 20 lug 2016 (CEST) (Alex sloggato)[rispondi]

Sembrerebbe di sì, grazie --Utoutouto (disc.) 21:03, 20 lug 2016 (CEST)[rispondi]

Prima o poi occorrerebbe "pubblicizzare" un po' la questione Modulo:Dati, ma è così complessa che non ho cuore di farlo.... :-( Tecnicamente, in Modulo:Dati/[nome indice] vengono memorizzati tutti i dati di pagelist (sbagliati se pagelist è sbagliato) e di Indice sommario, poi avviene il "miracolo" che il template {{Pg}} trasforma un banale numero pagina in link attivo alla pagina djvu giusta in nsPagina, al capitolo giusto in ns0. Ma spiegare come fa è veramente difficile. L'unica cosa che è veramente importante sapere è che dopo ogni correzione di pagelist o di Indice sommario occorre riscrivere il modulo dati; il che si fa con un click ben assestato. --Alex brollo (disc.) 10:08, 21 lug 2016 (CEST)[rispondi]
Il Modulo:Dati è una cosa molto bella e importantissima, andrebbe standardizzato per tutte le wiki con un bottolino/estensione che lo aggiorna automaticamente ad ogni revisione della relativa pagina Indice. Aubrey (disc.) 12:41, 21 lug 2016 (CEST)[rispondi]
Al tempo non avrei saputo come fare, adesso sì. Il mio "spirito ecologista" si ribella un po' all'idea di fare modifiche frequenti a pagine pesanti, ma poi guardo le cronologie di pedia e mi tranquillizzo: la nostra "media modifiche" delle pagine, grandi o piccole, è ridicola in confronto con la media di pedia, come è ridicolo il numero di pagine complessive. Globalmente siamo quasi irrilevanti ;-). Quindi, facciamolo. Alex brollo (disc.) 16:00, 21 lug 2016 (CEST)[rispondi]

Licenze e open archive modifica

Sono molte le Università che depositano il loro materiale con licenze aperte. Per fare un esempio Reti Medievali che partita dall'Università di Napoli, è diventata una rete che coinvolge trasversalmente molti tra i più importanti istituti universitari e cattedre di medievistica. La licenza la si trova qui. Se si guarda in giro situazioni simili coinvolgono anche altre università ed altre materie. Se le licenze sono ritenute compatibili si aprirebbero filoni molto interessanti con il superamento di una Wikisource limitata al solo Pubblico Dominio"-Mizar (ζ Ursae Maioris) (disc.) 22:16, 20 lug 2016 (CEST)[rispondi]

Sul sito, nella pagina degli articoli, è riportata esplicitamente la licenza CC 4 BY che è certamente compatibile (anzi, è più vasta della CC 3 BY SA); particolarmente interessante che manca la limitazione NC. Direi che si possono caricare, farò un test di caricamento "tal quale" come pdf, in questo caso la conversione djvu dovrebbe essere del tutto inutile. Ovviamente il lavoro da fare è comunque pesantuccio (riformattazione, immagini, codice per le annotazioni...) e va pesato con l'unico "plus" che deriva dal caricamento, cioè con l'inserimento dell'opera nella "rete di dati" di MediaWiki. Non è escluso che rovistando nel pdf con le routine xpdf (in particolare pdftohtml) non si possa "estrarre" qualcosa di utile (metadati, formattazione, illustrazioni); questi pdf sono molto diversi dai pdf "raccolta di immagini" che si costruiscono con le scansioni delle pagine. C'è qualcuno che sa maneggiare per bene xpdf, o programmi analoghi? --Alex brollo (disc.) 08:04, 21 lug 2016 (CEST)[rispondi]
Fatto un caricamento locale File:test.pdf e corrispondente Indice:test.pdf, ci farò sopra varie prove, sono ottimista per una notevole "preformattazione", se ci lavorate tenete conto che poi tutto sarà accuratamente cancellato :-) --Alex brollo (disc.) 09:07, 21 lug 2016 (CEST)[rispondi]
È da molto tempo che io penso che Wikisource debba aprirsi alla letteratura open access (la cui licenza preferita è solitamente la CC-BY, e non la CC-BY-SA). Solo che, dato il numero, io sono assolutamente convinto che dobbiamo trovare un modo per incorporare questa letteratura che non sia la modalità proofread. Da un punto di vista, come dire, filologico, non credo sia sensato trascrivere come fossero manoscritti dei testi che nascono digitalmente, su documenti Word o simili.
Se il nostro problema è l'aderenza alla fonte, penso potremmo trovare altre modalità (non tanti, ma molti articoli sono pubblicati in HTML e non PDF; in tal caso, si può pensare ad una trasformazione automatica in wikicodice). Rimango abbastanza contrario a trascrivere PDF, nel senso che vorrei che la comunità investisse il minore tempo possibile nel rifare del lavoro che è stato già fatto. L'attenzione e il tempo degli utenti è una risorsa scarsissima e la mia personale priorità è quella di preservarlo il più possibile, senza sprecarla in azioni inutili. Capisco che la formattazione è un problema molto serio: però, proviamo ad elaborare delle soluzioni, secondo me ne vale la pena. Aubrey (disc.) 12:30, 21 lug 2016 (CEST)[rispondi]
Il problema maiuscolo è che l'html (che pure nasce come puro testo modificabile) non può essere importato. Alcuni tag funzionano, ma altri sono impossibili da importare per motivi di sicurezza. Fra questi, il tag a (e saltano ancore, annotazioni, link) e il tag img (e sakltano tutte le immagini), oltre a tutto il css. In teoria (avendo a che fare con serie di pagine, non con una pagina sola: es. riviste) ci si può spaccare il cervello per tradurre l'html in markup wiki. Varrebbe comunque per alcune pagine "simili" e non per altre. Fatta questa fatica improba e incompleta, alla fine il codice potrebbe essere modificato, e noi dobbiamo poterlo modificare, altrimenti è impossibile raggiungere l'unico obiettivo serio che giustifica l'importazione di un testo che nasce digitale: ossia, l'aggiunta di link che lo facciano colloquiare con il resto del mondo mediawiki.
I pdf sono molto peggiori, perchè fatti per essere immodificabili o modificabili con grande difficoltà. L'estrazione del testo in un formato modificabile è indispensabile e non facilissima. La formattazione può, in gran parte, essere estratta con la trasformazione pdf->html ma ricadiamo della situazione precedente.
Conclusione: una fase di editing (non facile) è indispensabile; prendere o lasciare. Di certo, non farò mai più la sciocchezza di dare un pdf testuale (che già contiene il testo perfetto) a un OCR, che restituisce un testo più o meno inesatto; anche la trasformazione in djvu è una grossolana perdita di tempo; tuttavia, importare questi testi è, e sarà sempre, una bella faticaccia. ne vale la pena? Alex brollo (disc.) 15:49, 21 lug 2016 (CEST)[rispondi]
PS: anche se il testo è perfetto, la suddivisione in pagine, a cui obbliga l'interfaccia proofreading, secondo me è utile lo stesso per l'indispensabile edit di altro. Quindi, anche se farò ogni sforzo per automatizzare/preformattare, i pdf "testuali" comunque li caricherei in nsIndice->nsPagina->transclusione in ns0. È questo il senso del caricamento test. Alex brollo (disc.) 16:56, 21 lug 2016 (CEST)[rispondi]
Guardate mw:Extension:Html2Wiki, forse può servire. Inoltre l'estensione HTMLets permette l'uso di HTML completo dentro l'apposito tag.--Erasmo Barresi (disc.) 08:12, 22 lug 2016 (CEST)[rispondi]
A vedere l'estensione mw:Extension:Html2Wiki sembra magica ma: perchè nessuna wikisource "di riferimento" (fr, en) l'ha installata? Chi scova una wikisource, magari minore, dove l'estensione sia installata, giusto per esaminare la differenza fra teoria e pratica? Alex brollo (disc.) 11:07, 22 lug 2016 (CEST)[rispondi]

──────────────────────────────────────────────────────────────────────────────────────────────────── Ricordavo di aver letto da qualche parte che LibreOffice esportava in MediWiki, infatti nel menu "File > Esporta..." si trova anche il markup MediaWiki[27]. Inoltre, cercando quella pagina, mi sono imbattuto in w:en:Help:WordToWiki che tra le altre cose rimanda anche al tool toollabs:magnustools/html2wiki.php. --L0ll0 (disc.) 11:40, 22 lug 2016 (CEST)[rispondi] ──────────────────────────────────────────────────────────────────────────────────────────────────── Mi pare che nessuna Wikisource l'abbia utilizzata (e non mi stupisce): questo è un problema che si era presentato soprattutto nella WIkisource in inglese, in cui si potevano importare migliaia di articoli in open access. La cosa bella, però, è che quegli articoli erano in origine in JATS, una forma di XML per gli articoli scientifici, il che aveva permesso una conversione automatica con un bot da JATS a markup mediawiki. Ci sono ancora problemi, ma pare che stiano andando avanti con il lavoro. Aubrey (disc.) 12:16, 22 lug 2016 (CEST)[rispondi]

Ripeto il mio caldo invito a procurarsi e a provare a fondo le routine xpdf (in particolare pdftohtml). pdftohtml, lanciato sull'opera test File:test.pdf, produce in un lampo pagine html individuali e autonome, straordinariamente simili, a vederle, con l'originale pdf. Ma è una somiglianza apparente; la struttura testo del pdf è quello che è, e nessun convertitore può aggiungere quello che non c'è; c'è inoltre una marea di codice html pressochè inutile, e, temo, nessun convertitore è in grado di distinguere il codice utile da quello inutile. Io proverò a "battere" una strada diversa: partire dal puro testo, ed estrarre dall'html quel poco che serve. Vediamo. --Alex brollo (disc.) 13:43, 22 lug 2016 (CEST)[rispondi]

A proposito di export e di LibreOffice: come avrete visto sto caricando i vari capolavori salgariani: lo sto facendo partendo da file ODT o RTF presi da LiberLiber, che poi dò in pasto ad OpenOffice 4 su cui ho installato il plugin "Sun Wiki Publisher", che permette di fare "Esporta come... -> Mediawiki". Il risultato è buono, mi divide bene i paragrafi e mantiene tutti i corsivi e gli allineamenti centro/destra. Forse la cosa può tornare utile anche per altri documenti. Per chi volesse provarci: se avete OpenOffice per Windows dovete installare una JRE 6 o 7 a 32 bit, sennò non c'è verso di installare il plugin. Can da Lua (disc.) 14:34, 22 lug 2016 (CEST)[rispondi]

Tech news de noaltri poareti modifica

Effetto collaterale dei test su Indice:test.pdf, penso di riattivare una vecchia idea, che consiste nello spostamento automatico di un eventuale RigaIntestazione presente in corpo pagina in header (sovrascrivendo l'eventuale RigaIntestazione già presente) e di un eventuale PieDiPagina in footer. Fatto questo header e footer, se tutto funziona come immagino, potrebbero restare chiusi di default nel 99% dei casi. L'idea è quella di attaccare lo spostamento alla fine dell'esecuzione di memoRegex e anche a postOCR. --Alex brollo (disc.) 08:21, 22 lug 2016 (CEST)[rispondi]

Ce l'ho, alex.moveRi(), per ora la provo con BAT poi quando sono soddisfatto la esporto qui. --Alex brollo (disc.) 11:15, 22 lug 2016 (CEST)[rispondi]

Tastini di scelta rapida modifica

Quanti di voi sanno che premere Alt-Shift-C equivale a cliccare sulla linguetta "Testo"? Quanti di questi usano questa scorciatoia? Siccome immagino che la risposta alle due domande sia un numero approssimabile allo zero, ho pensato di associare tale combinazione di testi al bottone del Centrato, così ora per centrare una parola basta selezionare e fare Alt-Shift-C. Se la cosa piace possiamo vedere di "riciclare" allo stesso modo altre combinazioni di tasti ora poco utili. Can da Lua (disc.) 13:53, 22 lug 2016 (CEST)[rispondi]

@Alex brollo vedi MediaWiki:Gadget-pulsanti-centrato.js, si tratta solo di mettere l'attributo access. C'è il solito title che compare al passaggio. Can da Lua (disc.) 23:29, 24 lug 2016 (CEST)[rispondi]

Se non ci sono obiezioni, pensavo di associare Ctrl-Shift-Y al tasto di Indentazione e Ctrl-Shift-U a quello di De-indentazione, che sono molto usati (volevo usare I, ma a quanto pare Chrome usa già la stessa combinazione di tasti; quindi ho pensato Y come Yndent e U come Unindent :D). Al momento Y richiama "i miei contributi", U richiama "Upload", che mi sembrano entrambe funzioni non così frequenti. Se con il vostro browser non riusciste ad usare queste particolari combinazioni di tasti, proponete pure delle altre. Can da Lua (disc.) 12:32, 27 lug 2016 (CEST)[rispondi]
  Fatto Can da Lua (disc.) 11:48, 29 lug 2016 (CEST)[rispondi]

I limiti di Ritaglio modifica

Mi raccomando, {{Ritaglio}} va considerato un sistema per visualizzare temporaneamente un'immagine; poi va sostituito con un codice immagine "regolare", perchè l'esportazione in ePub non funziona, e appesantisce terribilmente il file. --Alex brollo (disc.) 18:43, 23 lug 2016 (CEST)[rispondi]

@Alex brollo forse conviene escluderlo dall'export, direi... Can da Lua (disc.) 18:52, 23 lug 2016 (CEST)[rispondi]
@Candalua Pienamente d'accordo. --Alex brollo (disc.) 19:11, 23 lug 2016 (CEST)[rispondi]
  Fatto Can da Lua (disc.) 18:15, 25 lug 2016 (CEST)[rispondi]

Il punto è che ritaglio è favoloso, e nettamente il sistema migliore per mettere le immagini. Molti di noi non hanno le competenze nè il tempo per andare ad estrarre tutte le immagini da un libro, cropparle e caricarle su Commons con nomi e categorie giuste. Com tool secondo me è uno dei migliori che abbiamo mai avuto. Non ho idea di come si possa risolvere, ma io proverei a sottoporre la questioni a Tpt per l'export. Aubrey (disc.) 19:35, 23 lug 2016 (CEST)[rispondi]

In teoria, è possibile usare i dati di Ritaglio per ricavare un ritaglio fisico della pagina djvu, ottenendo un file immagine in qualsiasi formato. Sempre in teoria, poichè tale file è un "derived from" da un file già su Commons, dovrebbe essere possibile caricarlo in automatico su Commons: i metadati ci sono, le categorie si possono ricavare. Da qualche parte dovrei avere qualcosa, ma non sono in grado di immaginare un tool completo. Forse potrei arrivare al punto di raccogliere le immagini ritagliate un una cartella, pronte a essere ulteriormente ritoccate e poi caricate con Commonist; ma resterebbe un "lavoro sporco per specialisti". --Alex brollo (disc.) 21:57, 23 lug 2016 (CEST)[rispondi]
Idealmente, io vedrei bene un bot che passa dopo (quando vuole, anche una volta a settimana) e sostituisce le immagini. Oppure dici che "basta" la categoria e si fa di lavoro sporco? Come al solito, finirebbe sulle spalle dei soliti noti (cioè, tu). Aubrey (disc.) 22:17, 23 lug 2016 (CEST)[rispondi]
A parte che faccio poco lavoro sporco, e che un bot è indispensabile, il problema è che caricare su Commons immagini ex novo bene, via bot, non è uno scherzo. Inoltre ci vuole un bot flaggato su Commons, suppongo. Immagino una soluzione intermedia, un bot locale che rovisti e carichi le immagini pronte in una cartella locale, in modo che poi ci sia solo da impostare e lanciare commonist; la cosa resterebbe comunque a carico di quelli, fra noi, che si azzardano a lanciare uno script python e a manovrare commonist. Non siamo moltissimi. :-(
SE trovo l'ispirazione, cercherò di preparare lo script "scaricatore e ritagliatore", se non altro sarà un primo passo. Alex brollo (disc.) 07:46, 24 lug 2016 (CEST)[rispondi]

fixRitaglio.py modifica

Fatte alcune prove, mi fermo a metà. Non è il caso di automatizzare oltre. fixRitaglio.py, datogli come parametro il nome base della pagina/indice, scarica il djvu, trova le pagine che incorporano Ritaglio, ne salva il codice quindi scarica il tiff della pagina. Fine. Ci si ritrova con una cartella di immagini con il nome "standard" da esaminare, sistemare, convertire e ritagliare. Non è il caso di automatizzare oltre; alle volte le immagini fanno pietà; alle volte vanno raddrizzate; bisogna scegliere la conversione e la correzione dei colori/del contrasto. Un bot non può farlo. Alex brollo (disc.) 19:33, 24 lug 2016 (CEST)[rispondi]

Se a monte non funziona, non c'è modo di scaricare a valle l'immagine prodotta da mediawiki? --Accurimbono (disc) 07:51, 25 lug 2016 (CEST)[rispondi]
Mi sono spiegato male. Certo, se c'è il djvu è sempre possibile ricavare un'immagine esattamente uguale a quella prodotta da Ritaglio; il problema è che talora l'immagine è di bassissima qualità, perchè tale è nel djvu. Esempio, i numerosi Ritaglio (centinaia) in Don_Chisciotte_della_Mancia. Ma ripensandoci, è un altro caso di "meglio l'uovo oggi che la gallina domani" quindi, belle o brutte che siano, bisogna procedere e produrle; si possono sempre ricaricare, avendole, immagini migliori. --Alex brollo (disc.) 10:01, 25 lug 2016 (CEST)[rispondi]
Riguardo Wikisource, anche io penso che "meglio l'uovo oggi che la gallina domani sia un'ottima filosofia", semplicemente perchè è alla base del wiki e, credo, sia meglio avere un libro illustrato in maniera non eccellente che un libro senza illustrazioni. Molti problemi che noi (giustamente) ci facciamo con la qualità non sono avvertiti (mentre probabilmente altri problemi che non ci facciamo sono avvertiti). Fra l'altro, aggiungo, se si riesce a caricare bene su Commons con un bot significherà che i titoli dei file e le categorie saranno omogenei, cosa che aiuta moltissimo i nuovi utenti (perchè si può documentare), e soprattutto perchè sostituire un'immagine è molto più facile che prendere tutte le decisioni necssarie per caricarne una completamente nuova (convenzioni per i nomi, categorie, metadati, ecc.). Tu alex riesci ormai a usare bene wmflabs o hai bisogno di una mano? Aubrey (disc.) 10:24, 25 lug 2016 (CEST)[rispondi]
@Aubrey No, sono anni che non uso wmflabs (ho dovuto cercare per confermare cos'è...), il massimo che posso produrre è un file python locale, l'implementazione come tool andrà fatta da uno bravo. Posso solo confermare che per caricare le immagini i dati ci sono tutti (il djvu ha le immagini e Ritaglio ha le coordinate esatte per il ritaglio: tutti i metadati solo nella pagina File: del djvu; nomi immagine e categorie possono essere standardizzate). Quindi, per caricare immagini tratte così come sono dentro i djvu, non manca niente. Alex brollo (disc.) 12:10, 25 lug 2016 (CEST)[rispondi]
Qua: commons:Category:Illustrations from Manuale di economia politica con una introduzione alla scienza sociale tutti i file prodotti con il giro sperimentale di fixRitaglio.py. L'unico comando che ho dato in console è stato python fixRitaglio.py "Manuale di economia politica con una introduzione alla scienza sociale.djvu". I nomi delle immagini sono automatici e standard (sono lunghetti, ma "logici"). Poi con commonist ho caricato i file risultanti, com'erano. Così è anche più chiaro che alle volte i file derivati dal djvu fanno senso ;-) Alex brollo (disc.) 22:47, 25 lug 2016 (CEST)[rispondi]
 
File:Don Chisciotte (Gamba-Ambrosoli) Vol.1-0081.jpg
Qua: Discussioni indice:Manuale di economia politica con una introduzione alla scienza sociale.djvu la galleria delle immagini caricate. Si vede la "convenzione sul nome" delle immagini: nome base Indice+trattino+numero pagina a quattro cifre+lettera a,b,c... finale nel caso che vi siano più immagini sulla stessa pagina. Con la gestione del caso "ritagli multipli" considero conclusa la verifica di fattibilità. Adesso lancio su Don Chisciotte, il "caso duro". Alex brollo (disc.) 23:41, 25 lug 2016 (CEST)[rispondi]

──────────────────────────────────────────────────────────────────────────────────────────────────── Ecco a destra il risultato dell'estrazione di una fra le oltre 300 immagini di Don Chisciotte, volume 1. Può andare come uovo oggi? commonist è pronto a caricarle tutte. Alex brollo (disc.) 00:30, 26 lug 2016 (CEST)[rispondi]

──────────────────────────────────────────────────────────────────────────────────────────────────── per me, si. Fai conto che in un ebook reader cmq le immagini sarebbero piccole comunque. Aubrey (disc.) 01:59, 26 lug 2016 (CEST)[rispondi]

Procedi pure con l'uovo di oggi ;) Ottimo lavoro. Chi volesse migliorare la qualità delle immagini su un'opera specifica potrà sempre farlo. --Accurimbono (disc) 02:58, 26 lug 2016 (CEST)[rispondi]

La pulizia modifica

Caricate le vere immagini, dato loro un nome standardizzato, adesso si tratta di sostituire Ritaglio con FI, cosa facile perchè i due template sono parenti (Ritaglio è figlio di FI). Le istruzioni sono le seguenti:

  1. aprite un FI così:
{{FI
| file =
| width =
| float =
}}
  1. in file mettete il nome dell'immagine >(nome base della pagina senza djvu, trattino, numero pagina a quattro cifre "riempite con zeri", .jpg); se in Discussioni indice c'è la galleria il nome immagine lo prendete da lì;
  2. in width mettete il wWidth (non il width!) di Ritaglio;
  3. in float mettete il float di Ritaglio. Fine. Alex brollo (disc.) 12:14, 26 lug 2016 (CEST)[rispondi]
Intanto che provate, se vi va, su Indice:Don Chisciotte (Gamba-Ambrosoli) Vol.1.djvu, io comincio a spennare la gallina ;-) --Alex brollo (disc.) 15:09, 26 lug 2016 (CEST)[rispondi]

La gallina modifica

 

Le galline in realtà sono due.

La prima: se il djvu deriva da IA, utilizare le immagini sorgenti jp2 e non le immagini massacrate dalla compressione tipica dei file djvu. Questa ce l'ho. :-)

La seconda: automatizzare (sia via javascript che via bot) la conversione {{Ritaglio}} -> {{FI}}. Questa è una gallina furba non facilissima da acchiappare. Alex brollo (disc.) 10:04, 27 lug 2016 (CEST)[rispondi]

Download a volontà modifica

Ho mangiato l'"uovo oggi" :) e ho abilitato i bottoni del WSExport come discusso più sopra. Ovviamente non dev'essere la versione definitiva, ma come al solito credo il modello migliore per noi, sia andare live con le modifiche prima possibile e perfezionare poi vedendo come va. Tra l'altro notavo sulle statistiche che in luglio siamo il progetto col maggior numero di download di ePUB, 6400 contro i 4300 dei francesi e i 3700 degli anglosassoni (però i francesi hanno 2200 mobi e ben 22000 pdf!). Poi non so se è stato Alex che ha cliccato seimila volte sul bottone :D, però è un segno incoraggiante. Sarà interessante vedere come si evolveranno ora le statistiche. Can da Lua (disc.) 11:28, 25 lug 2016 (CEST)[rispondi]

@Xavier121 non so se vengono tracciati anche i titoli, bisognerebbe chiedere a Tpt. Can da Lua (disc.) 10:14, 1 ago 2016 (CEST)[rispondi]

21:54, 25 lug 2016 (CEST)

CropTool modifica

L’ho appena scoperto e mi piace molto: CropTool, uno strumento per croppare e ricaricare direttamente dei file già presenti su Commons. Non credo funzioni con file multi-pagina, ma sarebbe comodissimo, nel caso. Aubrey (disc.) 10:37, 26 lug 2016 (CEST)[rispondi]

L’avevo adocchiato ma un limite terribile mi ha fatto cadere l’entusiasmo: non gestiva le immagini dai file multipagina (djvu e pdf). Adesso le gestisce? In altri termini, è possibile croppare l’immagine di una pagina recuperata con un parametro |page= ? --Alex brollo (disc.) 09:57, 27 lug 2016 (CEST)[rispondi]
Me ne sono accorto anche io ieri sera. Adesso provo a chiedere allo sviluppatore quanto è complicato aggiornarlo... Aubrey (disc.) 10:50, 27 lug 2016 (CEST)[rispondi]
Gli ho appena scritto, se volete dare un +1... Se ce lo fa è (quasi) la soluzione a tutti i nostri problemi. Aubrey (disc.) 11:01, 27 lug 2016 (CEST)[rispondi]
  Fatto. Ovviamente i djvu devono avere buone immagini, altrimenti garbage in, garbage out; ma anche l’uovo ha lo stesso problema. --Alex brollo (disc.) 11:13, 27 lug 2016 (CEST)[rispondi]
Nessuna risposta ancora.... @Candalua, Ricordisamoa non si potrebbe recuperare il codice e adattarlo alle esigenze di wikisource trasformandolo in un tool tutto nostro? Alex brollo (disc.) 11:14, 28 lug 2016 (CEST)[rispondi]
Perchè trasformarlo in un tool tutto nostro? Secondo me è sbagliato, come approccio. Dato che il codice è su GitHub, se qualcuno riesce a migliorare il tool non deve fare altro che proporre una modifica al codice e chiedere di incorporarla nel tool generale (puro stile open source). Aubrey (disc.) 13:45, 28 lug 2016 (CEST)[rispondi]
Andando un po' più a fondo, il tool perfetto per source dovrebbe avere caratteristiche particolari, come il nome immagine automatico, la categorizzazione specifica automatica, e probabilmente altro. Penso che provando e riprovando ci accorgeremmo di parecchie differenze necessarie; usare i file jpg provenienti da file multipagina sarebbe solo il primo passo. In ogni caso, siccome la programmazione sarebbe probabilmente oltre le mie possibilità e la mia ignoranza sulla netiquette dell'intervento su un tool di altri è totale, la cosa lascio a chi sa farla. --Alex brollo (disc.) 15:53, 28 lug 2016 (CEST)[rispondi]
Ho capito quello che dicek dici. Nulla esclude un CropTool per Wikisource, se proprio serve, ma lo vedo ancora più difficile che modificare l'esistente: dovremmo di fatto re un fork, e poi mantenercelo da soli. Aubrey (disc.) 17:13, 28 lug 2016 (CEST)[rispondi]

Post sul blog Wikimedia su Wikisource (in Bengalese!) modifica

Eccolo. Aubrey (disc.) 10:55, 26 lug 2016 (CEST)[rispondi]

il titolo delle pagine e' troppo grande? modifica

Mi e' capitato di navigare senza il mio css personalizzato (che ha un layout ultracompatto), e la mia impressione e' che il titolo delle nostre pagine (quello sotto le linguette per capirci, non quello nel box) sia davvero troppo grande: addirittura 1.8em, il che sul mio Chrome lo fa apparire totalmente sproporzionato rispetto a tutto il resto, e nettamente piu' piccolo del titolo che si vede nel box. Che dite, lo rimpiccioliamo almeno ad 1.4 o anche 1.2? In questo modo recuperiamo anche spazio in altezza. Can da Lua (disc.) 21:59, 26 lug 2016 (CEST)[rispondi]

Guarino Guarini - Dissegni d'architettura civile et ecclesiastica modifica

Due cose. La prima: se qualcuno avesse voglia di schiacciare qualche bottone (Button, Button, ma che pal.. sempre la stessa storia) il volume in oggetto in pochi minuti potrebbe passare al 100%. Ho visto Luigi in azione, ma mi sembra poco deciso ad arrivare fino in fondo. La seconda: non so cosa abbia portato Aubrey a caricare questo volume costituito da sole immagini, ma vorrei che consideraste la possibilità di NON ripetere l'esperienza. L'elaborazione delle immagini è sempre un'operazione in perdita, mi viene da dire sottrattiva, e questo indipendentemente dalle capacità di chi la esegue. Non so cosa abbia da offrire questo progetto a colui o colei che consulta una edizione come questa. --Naamar (disc.) 23:13, 27 lug 2016 (CEST)[rispondi]

Non ricordo bene, ma credo mi fosse stato richiesto da un amico che poi però non l'ha formattato... Aubrey (disc.) 02:16, 28 lug 2016 (CEST)[rispondi]
Per di più i simboli del SAL sono disallineati (a me risulta che spesso sono rossi in Indice e verdi in Pagina)...--Silvio Gallio (disc.) 07:37, 28 lug 2016 (CEST)[rispondi]
Non condivido la critica di Naamar. Un libro è un libro, anche se contiene immagini invece che testo; ma soprattutto avere il libro scansionato significa avere la fonte implicita, la migliore possibile, di ognuna delle immagini. Wikisource è l'unico progetto in cui la fonte dell'item (pensiamo a wikidata) è lo stesso oggetto che viene caricato, se si esegue la procedura proofread. Fra la'altro, mi è capitato in mano, me l'ha prestato mia figlia, uno straordinario libro che racconta una avventura fantastica, fatto di soli disegni, senza alcuna parola! Straordinario perchè "multilingue", perfettamente comprensibile per chiunque nel mondo, perfino se analfabeta. Purtroppo è recente, e quindi sotto copyright, mi dispiace di non poterlo caricare. --Alex brollo (disc.) 08:51, 28 lug 2016 (CEST)[rispondi]
Trovo che i libri senza parole hanno un nome: "silent books". Se ne trovate uno free, lo carico personalmente... ma su quale progetto? Qui? Su oldwikisource? Quale progetto accetta "language=None"? ;-) --Alex brollo (disc.) 10:47, 28 lug 2016 (CEST)[rispondi]
Il frontespizio è in italiano. Anche per SBN è in lingua italiana. ([35]) --Accurimbono (disc) 11:34, 29 lug 2016 (CEST)[rispondi]

Libro interessante, immagini pulite, un b/n anche meglio della pagina giallastra da cui proviene, quindi, tutto questo sottrattivo mi è oscuro; imo dovrebbe venir fuori anche un buon epub. La filosofia del nostro progetto, per chi ancora se lo domanda, è: RINGRAZIA CHIUNQUE PASSI DA QUESTI PIZZI E MODIFICA ANCHE SOLO PER UN "CIAO"! E' tutto, sempre e comunque, qualcosa di guadagnato, quindi in più. Restando in tema di oggetti senza parole, esiste anche un bellissimo fumetto ambientalista giapponese, GON, un piccolo adorabile dinosauro, magari qualcuno lo leggeva... :) --Xavier121 15:01, 28 lug 2016 (CEST)[rispondi]

Va bene caricare il libro, ma quello che mi chiedo è: c'era proprio bisogno di creare una pagina per ciascuna immagine? Can da Lua (disc.) 16:35, 28 lug 2016 (CEST)[rispondi]
Se ti aspetti che sia io a rispondere c'è piuttosto bisogno di una riformulazione della domanda. --Naamar (disc.) 17:23, 28 lug 2016 (CEST)[rispondi]

E' stato in test durissimo, ho imparato un mare di cose (sono in ferie, per fortuna....), fixRitaglio.py ha funzionato oltre le aspettative (anche in casi imprevisti). Date un occhio all'Indice, c'erano pagine con immagini (e didascalia) erroneamente marcate con SAL 00%, che ho dovuto riportare a SAL 75%. Sono poche. Vi proporrei la prova del 9, lo scaricamento dell'ePub e un accurato controllo che tutto sia a posto. --Alex brollo (disc.) 11:00, 28 lug 2016 (CEST)[rispondi]

@Alex brollo Non si scarica in mobi o epub :( --Xavier121 02:08, 30 lug 2016 (CEST)[rispondi]

Nemmeno Don Chisciotte della Mancia, invece Don Chisciotte della Mancia Vol. 2, ancora più leggero, sì. Fortse superano qualche limite di pesantezza? Provo ad allegerirlo....--Alex brollo (disc.) 07:13, 30 lug 2016 (CEST)[rispondi]
Confermo. "Tagliandolo" ai primi 39 capitoli, si scarica come grosso ePub di oltre 30 Mby. Le immagini mi sembrano perfette, ma se c'è un limite, occorre trovare il modo di alleggerle di parecchio (in questi test non ho minimamente "badato ai byte"). --Alex brollo (disc.) 07:23, 30 lug 2016 (CEST)[rispondi]
@Xavier121 Forse ho capito. Un paio di test in Sandbox e poi modifico {{FI}} --Alex brollo (disc.) 14:30, 30 lug 2016 (CEST)[rispondi]
@Xavier121 Riprova adesso :-) --Alex brollo (disc.) 15:22, 30 lug 2016 (CEST)[rispondi]
@Alex brollo Perfetto. Più tardi provo anche su K. Xavier121 16:49, 30 lug 2016 (CEST)[rispondi]
IL problema è il seguente: FreeImg (nella sua versione originale) scarica un'immagine a grandezza piena, poi la riduce a livello di visualizzazione. Normalmente invece le immagini sono scaricate in dimensioni già ridotte. Nella nostra versione era stata aggiunta la possibilità di variare la grandezza dell'immagine scaricata, ma era una possibilità opzionale. Ho cambiato le cose: adesso FreedImg scarica di default le immagini rimpicciolite, e opzionalmente le immagini più grandi, registrando esplicitamente un valore per il parametro tsize (cosa che non farà nessuno ;-) ) --Alex brollo (disc.) 07:13, 31 lug 2016 (CEST)[rispondi]

@Alex brollo Prima o poi si dovrà affrontare il risultato sugli ebook reader, quindi cominciamo: sul Kindle, quando l'immagine si esprime con [[File:nome file.djvu|px]] ecc. la centratura segue la grandezza dell'immagine che occupa tutta la linea di testo (anche se fosse leggermente spostata a dx o sx non si noterebbe tanto); quando è inserita con template FI il parametro center, sembra non abbia effetto e l'immagine è tutta spostata a sx; stessa cosa sui lettori per pc, tipo calibre, anche se meno accentuato. P.S. non esiste un modo per restituire un file epub o mobi con testo giustificato di default? Xavier121 15:10, 31 lug 2016 (CEST)[rispondi]

@Xavier121 Faccio una ricognizione del codice. Esiste una questione ePub2 - ePub3, FI potrebbe richiedere ePub3. La domanda "Perchè usare FI invece che il normale markup?" ha varie risposte, due sono rilevanti:
  1. è facilissimo inserire le didascalie, qualsiasi sia la posizione dell'immagine (stanno dentro il "blocco" che con tiene l'immagine);
  2. permette la piccola magia del testo "floating-center", ossia dell'immagine centrata che però non interrompe il testo.
Se questi due vantaggi sono giudicati indispensabili, occorre risolvere i problemi di esportazione (che dipendono da difetto dei lettori, non ci sono "trucchi", è normale HTML - CSS). Alex brollo (disc.) 16:14, 31 lug 2016 (CEST)[rispondi]

Effetto collaterale della sostituzione massiccia di Ritaglio modifica

Una delle cose molto interessanti emersa dal lavoraccio che sto facendo è la conferma della estrema utilità di standardizzare i nomi delle immagini; triplica la velocità di inserimento del codice e, associata a analoga standardizzazione del template Information su Commons, facilita molto anche l'inserimento. Come ormai è tradizione intanto ripeto qui lo standard che uso, provatelo e poi, dopo discussione e rifinitura, ne faremo una pagina di aiuto.

{{Information
|Description={{it|1=Immagini da Don Chisciotte (Gamba-Ambrosoli) Vol.1,  1841 }}
|Source={{derived from|File:Don Chisciotte (Gamba-Ambrosoli) Vol.1.djvu}}
|Date=1841
|Author={{Creator:Miguel de Cervantes}}
|Permission=
|other_versions=
}}
== {{int:license-header}} ==
{{PD-old-70-1923}}
[[Category:Illustrations from  Don Chisciotte (Gamba-Ambrosoli)]]

Se osservate il nome dell'immagine, vedete che non c'è alcun bisogno di cercarla: la ricavate dal nome della pagina; ma non solo: anche il software la ricava dal nome della pagina, quindi l'inserimento del codice "indovinato" è totalmente automatizzabile; non più di un click su un pulsante o una combinazione di tasti produce un "codice standard" che poi potete rapidamente rifinire; per cui si può scrivere (e quindi bisogna scrivere subito) il codice per un gadget che lo faccia. Visti i vantaggi di {{FI}} sul codice standard, io proporrei di usare quello.--Alex brollo (disc.) 06:44, 29 lug 2016 (CEST)[rispondi]

Riesci a modificare le poche pagine di Aiuto riferite all'immagine con la nuova regola del nome? Mi pare funzionale. Aubrey (disc.) 10:56, 29 lug 2016 (CEST)[rispondi]
Andrebbero rifatte ex novo, sono di impostazione evidentemente wikipediana, qui servirebbero delle istruzioni riguardanti solo ed esclusivamente le illustrazioni rimandando ad altre pagine tutto ciò che è generale. Proverò a impostare una pagina Aiuto:Illustrazioni. --Alex brollo (disc.) 12:53, 29 lug 2016 (CEST)[rispondi]
Come vedete il titolo Aiuto:Illustrazioni si è bluificato; aiuto!!!! Alex brollo (disc.) 19:39, 29 lug 2016 (CEST)[rispondi]

Usato come testo di verifica per la eliminazione di {{Ritaglio}}, completata via bot per il volume I, ho ristrutturato pesantemente l'abbozzo del Volume II trasformandolo in un titolo principale Don Chisciotte della Mancia Vol. 2 per semplicità di gestione. Mi propongo di fare un caricamento massiccio delle immagini ancora mancanti in modo che siano già pronte con nome "standard" al momento della rilettura delle pagine e che possano essere quindi caricate con un click senza bisogno di usare Ritaglio. --Alex brollo (disc.) 01:20, 30 lug 2016 (CEST)[rispondi]

Ritrovata, con qualche difficoltà , la fonte di Don Chisciotte della Mancia Vol. 2 (mi aspettavo di trovarla su Commons... del vecchio template Infotesto mi ero completamente dimenticato!), che è IA, ho visto le immagini jp2, è indecoroso usare quelle massacrate dalla compressione djvu. Butto via tutto il lavoro già fatto sul djvu e mi scarico gli oltre 800 Mby dello zip jp2. --Alex brollo (disc.) 17:32, 30 lug 2016 (CEST)[rispondi]

Vita Nova modifica

Mi sto affezionando alla Vita Nova - nell'edizione del Barbi, 1907 - , di cui ho nei gg. scorsi completato rilettura e formattazione al 75% del capitolo sui Manoscritti. Vedo però che esiste in lavorazione anche questa versione del 1829, Tipografia Nobili. Ma quella del Barbi è decisamente il massimo. Nel canone poi compare un link ad una versione minima dell'opera, ma, se non capisco male, andrebbe riletta e riformattata per benino. Eventualmente vorrei raccordarmi con qualcuno che ci stia lavorando (se qualcuno al momento lo sta facendo) --Pic57 (disc.) 14:01, 30 lug 2016 (CEST)[rispondi]

Hai tutto il mio sostegno. Confermo: la versione del Barbi è una gran bella (autorevole) edizione. Dimmi di più. P.S. per ragioni estetiche e di sintesi rinominerei le note testo e le note lezione con α e β.

--Xavier121 16:45, 30 lug 2016 (CEST)[rispondi]

@Xavier121, la questione è complicata e ci sto ragionando sopra rileggendomi il primo capitolo dei Criteri fondamentali dove il Barbi dice un po' di cose da cui sarebbe bene non allontanarsi. Già che ci sono rileggo e correggo quelle pagine
1.Intanto complimenti per l'architettura di note che hai ideato e che sostanzialmente mi pare poter reggere l'edizione digitale dell'opera.
2. Bisognerebbe però evitare di interrompere la continuità della lettura del testo con note_testo e note_lezione. Il problema è che Dante aveva diviso e chiosato il testo molto più di quanto poi abbia fatto Boccaccio rieditando la Vita Nova. Per il Barbi ha ragione Boccaccio che d'altra parte giustifica la sua scelta con il fatto che Dante stesso "si vergognava" di aver scritto tutto quell'apparato a corredo, e la giustificava solo per il fatto che la Vita Nova era un'opera giovanile.
3. A noi posteri risulta invece chiara la eccezionale creatività di un poeta, ancorché giovane, che scrive con una struttura che risulta singolare nell'intera storia della letteratura (italiana e non): il prosimetro. E sarebbe bene cercare di interferire il meno possibile con quel testo, seguendo il Boccaccio
4. Barbi infatti NON fa alcuna nota dentro il testo (cioè dentro il prosimetro) e pone le note in relazione al numero della riga. Nei limiti del possibile questa impostazione andrebbe a mio modo di vedere mantenuta
5. Certamente α e β sono più agili. O forse anche T (testo) e L (lezione). Ma eliminarli proprio mettendo dei link alle parole visibili solo avvicinando il mouse o ideando qualcosa del genere? In questo modo il testo sarebbe libero proprio da interferenze come quello editato dal Barbi
--Pic57 (disc.) 20:08, 30 lug 2016 (CEST)[rispondi]
Molto interessante. Faccio delle prove. Che Alfred ci illumini!!! :) P.S. Proprio in questi giorni stiamo cercando di inserire un altro grande prosimetro, i Canti Orfici di Dino Campana, tormentato capolavoro del '900, a testimonianza della straordinaria continuità poetica della nostra letteratura. Xavier121 11:31, 31 lug 2016 (CEST)[rispondi]

@Pic57 osserva bene la modifica, se la ritieni valida si limiterebbero le note alle varianti dei diversi codici, mentre i passi approfonditi dal Barbi sarebberero semplicemente ancorati: testo e commento critico separati da section. Unica differenza la progressione numerica dei commenti sul testo continuo della nostra versione (originale diviso per pagine, 5-6 righe alla volta ecc.)Xavier121 01:21, 1 ago 2016 (CEST)[rispondi]

Sto lavorando alla formattazione in ns0, ancora un po' di pazienza :P, Xavier121 12:46, 1 ago 2016 (CEST)[rispondi]
@Xavier121, mi pare che ci siamo! E' vero che abbiamo inserito note numerate, però diamo il vantaggio del tooltip, che Boccaccio e Barbi non potevano immaginarsi :-) Un valore aggiunto della versione digitale. Solo qualche osservazione:
a. Cliccando sul numero della nota (non sulla parola, sul numero) mi saltano fuori errori in rosso
b. Questo carattere ζ te l'ho copiato, ma non sono riuscito a trovarlo tra i caratteri speciali dell'editor. E' così, o non ho aguzzato bene la vista?
c. Prima di provare anch'io a fare una pagina del prosimetro attendo che tu metta bene a posto le cosette. Nel frattempo procedo con il capitolo delle edizioni dove anche lì il lavoro non manca...
d. Tanto per mantenerti in allenamento, attiro infine la tua attenzione su La Scienza Nuova di G.B. Vico, dove l'architettura delle note è un labirinto forse anche peggiore della Vita Nova. Un anno fa intrapresi la rilettura e la formattazione di quest'opera devastante (ma comunque nel canone della letteratura italiana): avrò fatto le prime 200 pagine circa. Ma non sono imprese che si possono compiere da soli. E poi magari a te viene in mente un sistema di note più efficiente. --Pic57 (disc.) 20:41, 1 ago 2016 (CEST)[rispondi]

Adesso la questione è più chiara (grazie ad @Alex brollo). Unico problema tecnico è sulle parole ancorate: passando con il mouse non si apre la finestra pop-up come avviene invece per le note, non so da cosa dipenda... (link e testo evidenziato funzionano perfettemante) Xavier121 17:01, 2 ago 2016 (CEST)[rispondi]

@Pic57 Ancorati anche i capitoli con R (la dritta qui quando tutti insieme decideremo di riscrivere il manuale non sarà mai troppo tardi!). Sulla destra, sempre con R, abbiamo spostato i numeri di riga, ma ci sono anche altri numeri e non so come renderli (o se si devono mantenere). Xavier121 15:23, 3 ago 2016 (CEST)[rispondi]
@Xavier121 Visto, ok. Ma prima voglio finire la rilettura e lo studio dell'introduzione. Oggi ho concluso il capitolo sulle edizioni e aperto quello sulla classificazione dei testi, dove il Barbi spiega un bel po' di cose. Sono alle prese con le tabelle. Ho aggiornato la pagina di discussione dell'Indice e salvato un pezzo di memoregex sicuramente rudimentale, ma finora utile a me per le pagine dell'introduzione.
--Pic57 (disc.) 00:40, 7 ago 2016 (CEST)[rispondi]

Ogni promessa è un debito: il gadget FI modifica

Ecco qui la breve doc di cosa fa il gadget FI, che compare come bottone in toolbox: Aiuto:Illustrazioni#FI. --Alex brollo (disc.) 13:44, 31 lug 2016 (CEST)[rispondi]

Lo sto sperimentando in Indice:Don Chisciotte (Gamba-Ambrosoli) Vol.2.djvu, mi pare una vera goduria.... ma è noto che ogni scarafone è bello a mamma sua. --Alex brollo (disc.) 07:49, 1 ago 2016 (CEST)[rispondi]
A proposito, sto lavorando all'OCR di Indice:Don Chisciotte (Gamba-Ambrosoli) Vol.2.djvu, faceva pietà, in pochi giorni dovrebbe arrivare un "OCR preformattato sostitutivo". E' un grosso lavoro.... --Alex brollo (disc.) 08:08, 4 ago 2016 (CEST)[rispondi]
E acneh sulle immagini: ma sono tante! finora caricate, e importabili con il gadget FI, fino alla pag 450 circa del volume 2. Ne mancano centinaia :-( --Alex brollo (disc.) 13:21, 9 ago 2016 (CEST)[rispondi]