Bloglillon

Bundling some things I posted elsewhere, exploring


1 Comment

Traduzione #LOPTIS in bilingue e a colori significanti

Nel post Servizi di scrittura collaborativa e un primo progetto – #loptis , Andreas Formiconi proponeva di tradurre un saggio di Ron Tinsley and Kimberly Lebak su un suo wiki Wikispaces, in http://loptis.wikispaces.com/+Articolo+da+tradurre+e+discutere .

La prima revisione della pagina contiene un’introduzione in italiano, poi il testo dell’articolo in inglese. Perciò in teoria sarebbe stato possibile vedere la traduzione in bilingue confrontando questa prima revisione con la più recente: avrebbe mostrato le traduzioni aggiunte in verde e in rosso, l’inglese cancellato man mano che si traduceva. Però dopo un certo numero di revisioni, la loro lista è stata suddivisa su più pagine dal software. E siccome il software consente soltanto il confronto tra revisioni che sono sulla stessa sottopgina, non era più possibile effettuare quello tra la prima e l’ultima revisione, apparentemente.

Allora c’è stato un tentativo alternativo interessante: mettere (umanamente) il passo tradotto in blu e lasciare sotto il testo originale in nero. Ha funzionato per un po’ ma dopo diverse revisioni, il blu ha allagato tutta la traduzione: vedi il commento Arginare lo tsunami blu. I tentativi di rimuovere i tag per il blu soltanto sui passi in inglese funzionavano sì in anteprima, ma non quando si salvava. Quindi alla fine li ho tolti tutti, e il testo è tornato tutta in nero.

Però un po’ mi seccava, allora ho cercato un modo per confrontare lo stesso la prima revisione con l’ultima, giocando con l’URL del confronto. Cioè se:

  1. http://loptis.wikispaces.com/page/diff/%20Articolo%20da%20tradurre%20e%20discutere?v1=477278940&v2=479023432 è l’URL  del confronto tra la prima e la seconda revisione
  2. http://loptis.wikispaces.com/page/diff/+Articolo+da+tradurre+e+discutere/480826050 è l’URL dell’ultima revisione (al momento della prova: quando la pagina wiki verrà ulteriormente modificata, quell’URL cambierà)

allora sostituendo 480826050 (identificatore dell’ultima revisione – per ora) a 479023432 (identificatore della 2a revisione) in 1, ottengo:

http://loptis.wikispaces.com/page/diff/%20Articolo%20da%20tradurre%20e%20discutere?v1=477278940&v2=480826050 , cioè il confronto tra la prima e l’ultima revisione, con, per la parte traduzione,

  • i passi inglesi cancellati in rosso
  • i passi inglesi lasciati in nero
  • i passi italiani aggiunti in verde

Così:

cattura di schermo di http://loptis.wikispaces.com/page/diff/%20Articolo%20da%20tradurre%20e%20discutere?v1=477278940&v2=480826050 -

Beh, non è che la cosa sia di lettura molto agevole, riconosco. Ma non è ne più né meno agevole, diciamo, di un documento LibreOffice o Word dove si sono salvate e si mostrano tutte le modifiche. È una questione di abitudine.

E c’è un vantaggio rispetto al blu previamente imposto da noi sulle parti tradotte, che il software aveva poi fatto dilagare dopo N revisioni: questo blu e questo verde sono del software stesso. Perciò difficilmente il software li inca[ot]izzerà.


10 Comments

Cantieri o(pml)erosi – #ltis13

Aggiornamento: i ritratti degli abitanti del Villaggio cmook#ltis13

Monica Terenghi invece ha trasformato il file OPML per #ltis 13 in una stupenda tabella dove appaiono tutti nostri avatarl linkati ai nostri blog o alle nostre pagine gravatar: Villaggio cmooc#ltis13. E spiega chiarissimamente come ha fatto in L’html e l’arte di arrangiarsi.

Compito OPML

Il 18 aprile 2013, nel post Cantieri – #ltis13, Andreas ci ha proposto di mettere in un nostro aggregatore il file OPML con la lista dei feed dei post e dei commenti dei nostri blog per #ltis13, file che aveva linkato in cima a destra del suo blog: così avremmo potuto seguire facilmente ciò che facevano gli altri, e anche interagire direttamente con loro.

Questa volta quasi ci stavo.

Per altri due suoi corsi precedenti, avevo preferito dirottare il suo file OPML per crearmi una pagina wikispaces con aggregatori separati per ciascun feed:

In passato, certo, ho adoperato aggregatori: ne avevo persino fatto uno pubblico su Bloglines per ADISI, così era più facile mostrare cosa facevano i feed. Però gli aggregatori mi mettono il magone. I contenuti dei feed (qui, dei nostri blog) ci stanno dentro come i polli negli allevamenti in batteria. Preferisco dare a ciascuno dello spazio per ruspare.

Ma questa volta, siamo in tanti partecipanti a #ltis13. Quindi ho pensato, vada per l’aggregatore, sigh.

Adattamento / dirottamento del compito

Poi ci ho ripensato: per fare editing_multimediale_02_blogoclasse_feed e linf12 aggregatore, avevo adoperato wikispaces.com con l’editore WISYWIG, usando “inserisci Widget -> RSS” per ogni feed, il ce ti crea un grosso quadrato con sopra “rss” e basta nella pagina di scrittura:

Tra le parti testuali - nome autore, commenti, nome autore ecc: quadrati con solo scritto rss per tutti

Hic sunt leones insomma: facile sbagliare un URL.

Invece i widget di wikispaces, visti nell’editore wikitext, appaiono appunto in wikitext, cioè in testo. E per quel widget RSS, il wikitext è semplice. Esempio:

=Donatella Carli Moretti=
[rss url="http://carlimoretti.wordpress.com/feed" link="true" description="true" length="200" number="5" date="true" author="true"]

Soprattutto,  corrisponde abbastanza a quello per un dato feed nel file OPML. Esempio:

<outline title=”Donatella Carli Moretti” xmlUrl=”http://carlimoretti.wordpress.com/feed&#8221; />

perché valesse la pena provare a automatizzare almeno in parte la trasformazione del file OPML in pagina wiki con reader separati, cioè:

  1. nel file OPML, fare “trova e cambia tutti” ripetuti per sostituire a)  <outline title=” con = , b)  ” xmlUrl=” con = (cioè mettere il nome dell’autore tra =, che in wikitext crea un titolo H1 che può essere ripreso in un sommario piatto creato con [[toc|flat]]) e infine c) feed” /> con feed
  2. nell’editore wikitext della pagina wiki, incollare il risultato: cioè nome autore come titolo, seguito dall’URL del feed
  3. tra nome-titolo e URL,  creare un primo lettore di feed in codice wikitext
  4. incollarlo tale quale tra nome e URL per tutti i feed dello stesso tipo (ad es. tutti i feed dei post di blog WordPress)
  5. in ciascun lettore di feed, sostituire  il nome del blog con quello vero, copiato dall’URL proveniente dal file OPML, poi cancellare quell’URL
  6. come sopra per gli altri tipi di blog

Una volta ottenuti così i lettori feed per i post dei blog, ho deciso che preferivo avere per ciascuno il lettore dei commenti sotto quello dei post, invece di avere tutti i lettori di commenti dopo, ma anche questo l’ho fatto con dei copia-incolla.

Poi ho aggiunto i feed per il blog di Andreas, che non c’è nel file OPML perché lui ci aveva già chiesto prima di aggiungerlo all’aggregatore, ma non l’avevo fatto.

Risultato finora

Questa attività di sostituzioni e copia-incolla ha prodotto linf13-blog (veramente dovrei omogeneizzare il modo di intitolare quelle pagine aggreganti), attualmente alla 29a revisione, perché tendo a salvare spesso.

[Aggiornamento
😀 faccio  29 revisioni senza nemmeno accorgermi che ho mescolato gli acronimi linf12 e ltis13 nel titolo della pagina – meno male che con wikispaces, si possono rinominare le pagine creando un reindirizzamento dall’URL precedente: quindi adesso  linf13-blog reindirizza al più logico ltis13-blog. Ma è un fatto che è  sempre nei titoli che si annidano più facilmente i refusi: forse proprio perché sono belli grossi, quando controlliamo un testo, li percepiamo come “vabbé, è un titolo”, ma non li leggiamo veramente]

Svantaggi

  • La pagina è enorme, anche se il sommario interattivo ne facilita un po’ la navigazione.
  • È un lavoro un po’ noioso, soprattutto nella parte 5. È un po’ come lavorare all’uncinetto – ci sono momenti in cui la ripetitività ti ripulisce la mente, altri in cui te l’addormenta.
  • C’è un rischio di errori causati dalla noia.
  • Quando il file OPML viene aggiornato, gli aggiornamenti vanno trasferiti a mano.

Vantaggi

  • È una pagina web, quindi ci posso accedere sia dal laptop sia dal tablet – e altri, se vogliono, la possono anche usare da un apparecchio diverso da quello dove hanno installato l’aggregatore; oppure, se non hanno ancora dimestichezza con i feed e i loro aggregatori, per vederli in atto prima di creare un proprio aggregatore.
  • Può essere archiviata con WebCite, per conservare la situazione dei feed in un dato momento: vedi la versione archiviata il 20 aprile 2013, e quella archiviata il 22 aprile 2013.
  • Ciascun aggregatore può essere configurato separatamente: quello di quasi tutti i feed di post mostra 5 link, salvo per il blog di Andreas Formiconi, dove il reader dei post per ora ne mostra 21, cioè tutti i post #ltis13 attuali: quando ne aggiungerà uno, cambierò il parametro a 22.
  • Si possono aggiungere osservazioni a proposito di un aggregatore direttamente sopra o sotto di esso.

E da lì?

Alfabetizzare l’ordine e quindi il sommario? Ma forse questo è un desiderio da immigrante digitale. Forse è inutile nei testi digitali, visto che c’è Ctrl F. impareranno ancora l’alfabeto nell’ordine ABC ecc. i bambini tra, diciamo, 5 anni? Già 50 anni fa, nella classe di prima elementare di mio fratello, c’era un bambino  che rifiutava di impararlo a memoria, dicendo che lo si trova comunque all’inizio dei dizionari.  Mi pare che abbia retto fino in 3a o 4a, poi alla fine ha ceduto.

Creare una sottopagina per il blog di Andreas e per altri con intensa attività nei commenti? Non lo so: per i blog WordPress e NoBlogs si potrebbe, perché ogni post ha il suo feed proprio. Ma non con quelli Blogger (che d’altronde non hanno nemmeno tutti un feed funzionante per i commenti – strano).

Mettere assieme i due blog di Simonetta Maestri – blogspot e livejournal, come già fatto per quelli di Nicoletta Farmeschi – WordPress e NoBlogs? Questo, forse sì.


Leave a comment

#ltis13: diario 2013-04-14

(gratt)acapo/i

Ieri, copiando qui il diario fuori blog per #ltis 13 fatto su PiratePad, ho pasticciato un bel po’, soprattutto a causa degli a capo (“line breaks”).

Avevo scartato l’idea di copiare il contenuto di ciascun giorno in un post separato che avrei retrodatato alla data pertinente come si può fare con WordPress. Jim Shimabukuro lo fa per tutti i profili di autori di ETCJournal.com: post normali retrodatati a diverse date del 2008, soprattutto il 1° ottobre 2008, salvo quando si distrae e lascia la data vera, o se l’autore chiede di usare un suo profilo esistente.

Mai capito perché non usa invece pagine statiche, che sono proprio fatte per questo tipo di contenuti. La data dei post è una caratteristica fondamentale dei blog, che sono come una sfilza di email ordinati per ordine cronologico, in una specie di e-rotolo di carta igienica cronologico. Vabbé, adesso sui bordi si possono anche aggiungere merletti: elenchi di post e commenti, ultimi tweet, ecc ecc. Ma con le date dei post non va pasticciato.

Dunque scartata la retrodatazione, volevo mettere tutto il diario “pre-blog” in un solo post. Però mi serviva una specie di sommario con sotto-link per facilitare la navigazione, e siccome non son capace di scriverne uno direttamente in codice html (sbaglio sempre qualcosa nel creare le ancore), sono passata dall’editore per pagine Web di LibreOffice.

Primo piccolo (gratt)acapo: PiratePad usa i ritorni a capo invece di paragrafi veri . Quindi oltre a sostituire i  titoli puramente visivi (fatti con grassetto e grassetto sottolineato) con titoli strutturali per poter trarne un sommario, ho anche sostituito tutti gli a capo con paragrafi veri: abbastanza facile con Cerca e Sostituisci nella sorgente.

Secondo (gratt)acapo: l’idea era di copiare la sorgente LibreOffice nell’editore di post WordPress in modalità Text (sorgente). Però nella sorgente di LibreOffice ci sono degli a capo puramente visivi  per facilitare la lettura, che poi non appaiono in lettura normale – ma invece il software  WordPress traduce quegli a capo puramente visivi della sorgente in a capo veri che si vedono nel post. Ma siccome sono puramente visivi, non ci hanno  tag che si potrebbero rimuovere in una sola volta con Cerca e Sostituisci in LibreOffice, allora ho tolto i stramaledetti a capo uno ad uno nell’editore WordPress  e quindi il post l’ho pubblicato dopo mezzanotte, cioè con data di oggi…

Avrei anche potuto ricopiare le parti tra i titoli dal file  LibreOffice in modalità normale, non sorgente, però proprio perché era tardi, non ci ho pensato 😀

Stili strutturali e fruibilità

OK, nel post di ieri della copia nel diario pre-blog, volevo stili di titoli strutturali per poter trarre un sommario interattivo usabile da tutti.  Oggi non sto creando un sommario, perché questo post non dovrebbe essere  così mostruosamente lungo.  Però lo stesso, uso titoli strutturali (di livello H3 perché H1 e H2 sono già usati dalla struttura globale del blog).

Motivo: ance se  chi ci vede e non ha problemi di lettura può scorrere facilmente attraverso il testo, i titoli strutturali servono per farlo a chi deve usare un programma di sintesi vocale – come JAWS, NVDA – per leggere: i ciechi e forti dislessici ad esempio.  In effetti quei programmi di sintesi vocale non si limitano a leggere il testo dall’inizio alla fine con voce sintetica, ma permettono di spostarcisi da titolo a titolo – a patto, appunto, che siano titoli strutturali H1 H2 H3 ecc, e non cavolate puramente decorative (fatte con grassetto, sottolineato ecc)  come i soli titoli che si possono fare con PiratePad, o TextEdit su Mac, purtroppo.

Nei post di Andreas per  #ltis 13, in particolare in Ok, qualcosa su Piratepad – #ltis13, lui ha ripetutamente insistito sul fatto che PiratePad non è una piattaforma wiki.  Eppure PiratePad conserva le revisioni, consente di ripristinarne una anteriore, ha uno spazio commenti (la chat) —  come una pagina wiki, o come una pagina Google Docs o – ad uso degli autori, come un post WordPress. Una differenza, come dice lui, sta nel fatto che un pad PiratePad è UNA sola pagina, e che non ne è garantita la durabilità. Però secondo me la differenza più importante – ed irritante – sta proprio in quell’impossibilità di adoperare stili – e in particolare titoli – strutturali con PiratePad

Virgole

In Apriamo il blog #lt13. Andreas prima ci aveva chiesto di mandargli un email con oggetto “mooc” poi  dati separati da virgole: nome completo, cognome, URL del blog, eventuali nickname usati in rete, insistendo sull’importanza delle virgole e del non scrivere nient’altro.

Avevo pensato: caspita, ha un trucco per estrarre automaticamente quei dati dai nostri e-mail e per creare un file .csv (comma-separated values9. E che se ne farà, serve forse per i <a href=”http://iamarf.org/tag/sociogramma/”>sociogrammi </a> che ha usato in passato per rappresentare l'(inter)attività dei partecipanti a un corso?

Poi ha sostituito la richiesta di e-mail con un modulo Google Drive e i moduli Google Drive ti sputano le risposte belle ordinate in uno spreadsheet (foglio di lavoro / di calcolo?) pure quello GD,  che in un certo senso è la visualizzazione di un file .csv, e soprattutto che può essere scaricato come .csv.  Perché vabbé, già uno spreadsheet sarebbe una bella cosa, però appunto, cos’altro puoi combinare con un file .csv: quei sociogrammi? Oppure c’è un trucco per traadurli automaticamente in file OPML come quello che ci aveva proposto da aggiungere nei nostri aggregatori durante linf12, per seguire tutti i blog dei partecipanti? Cioè il passaggio da un file csv o perlomeno csvoide a un file xmloide si può fare con i sottotitoli, quindi perché no a un file OPML che è un file XML(oide) qnche quello. Ma non ci sarebbero un po’ troppi tipi di dati per un file OPMLoide?

Oppure arà diverse cose a partire della spreadsheet dei risultati: ne potrebbe fare una copia, tagliarvi le colonne che non servono per il file OPML, scaricarne il file .csv, trasfformarlo in file .OPML – e dalla spreadsheet completa, estrarre un .csv – ma per farne cosa?

LOL – sono proprio una filologa manquée come mi diceva G.S., a partire così per la tangente a proposito di virgole. Vedremo.

Lavello WordPress

Nel commento #84 a Apriamo il blog #lt13, annacilia aveva scritto:

,,, ho aperto il blog e scritto il primo articolo. La barra degli strumenti di scrittura è però molto povera; qualcuno sa dirmi come posso aggiungere altri comandi?

Poi nel commento #95 ha scritto:

Scusate ho risolto il problema era una sciocchezza.

Visto che il blog linkato sul suo nome è un blog WordPress, sembra che abbia scoperto il “lavello” (“kitchen sink”) della barra strumenti dell’editore di testo WordPress, che apre una seconda barra con un sacco di altri comandi, inclusi gli stili.  In gamba: io ci avevo messo mesi.

Ma perché diamine WordPress non mostra questa seconda barra strumenti automaticamente? a paura che turbi le nostre testoline?  Ma dover cliccare su un’icona chiamata “kitchen sink”per vederla non è affatto intuitivo: io vedo “Kitchn sink”, penso: “No grazie, i piatti li o già lavati” oppure “li laverò dopo”.