Bloglillon

Bundling some things I posted elsewhere, exploring


1 Comment

Accessibilità: facciamo che eravamo sordi, ciechi #edmu14

Nel post Cose che succedono in rete, se si lavora bene… (questioni di accessibilità)- #edmu14, Andreas Formiconi ha gentilmente citato alcune idee  di attività  un po’ alternative con strumenti di sottotitolazione che gli avevo mandato.

E proprio mentre mi stavo chiedendo cosa proporre più concretamente, lui ha pubblicato un altro post, non per #edmu14 ma per gli studenti di medicina: Un Medico all’Inferno: Medicina e dolore nell’Inferno dantesco, dove ha inserito l’omonimo video delle biblioteche dell’università di Firenze:

Ma l’ha fatto con un’aggiunta molto importante: ha trascritto normalmente nel post le informazioni scritte nel video su data e luogo dell’evento annunciatovi, rendendole accessibili ai ciechi tramite il software di sintesi vocale.

Vero che queste informazioni (meno l’ora) ci sono anche scritte normalmente nella descrizione del video su YouTube, però appunto, quando un video viene inserito altrove, la descrizione YouTube manca, perciò è importante ripeterle o riassumerle nella nuova pagina.

Però si potrebbe provare a rendere l’intero video interamente accessibile, cioè come i bambini, facciamo che eravamo sordi, che eravamo ciechi, per capire come viene percepito da altri.

Facciamo che eravamo sordi

Possiamo sì leggere i testi nel video, e fruire le illustrazioni di Doré all’Inferno di Dante – però ci perdiamo completamente “O Fortuna” dalle Carmina Burana di Orff che si sente su di esse all’inizio e alla fine: e se è stato scelto quel brano, ci sarà pure un motivo. E forse non sei sordo dalla nascita, e quel brano lo conosci bene e te lo potresti sentire in testa, sapendo che c’è.

Poi da 0:12 a 1:51, per la recitazione dei passi dell’Inferno, al limite possiamo attivare i sottotitoli automatici, ma se sei sordo, ci vuole una serie dose di senso dell’umorismo dissacrante per apprezzarne le distorsioni: più verosimile che t’arrabbi.

Facciamo che eravamo ciechi

La musica di Orff e  la recitazione dell’Inferno le sentiamo, ma ci perdiamo le informazioni scritte e non sappiamo che ci sono le illustrazioni di Doré, che forse ricordiamo per averle viste prima di diventare ciechi.

Proposta

Proviamo a rendere tutto il contenuto del video fruibile da tutti. A questo fine, ne ho utilizzato l’URL (indirizzo web) per aprire la pagina http://www.amara.org/en/videos/2hvKFS5lsko2/info/un-medico-allinferno-medicina-e-dolore-nellinferno-dantesco/ . E lì ho già iniziato 3 piste di sottotitoli, ciascuna per fare una cosa diversa:

  1. Metadata: Geo che è una delle lingue inesistenti di Amara, dove ho caricato tali quali i sottotitoli automatici di YouTube, e dove li potremo correggere: senza star li a ritrascrivere tutto, si può usare la versione digitale dell’Inferno in http://it.wikisource.org/wiki/Divina_Commedia/Inferno .
  2. Latin (latino) per sottotitolare le parti con “O Fortuna”: anche lì, senza stare a trascrivere il latino cantato, che non è facile, si può usare il testo in http://www.tylatin.org/extras/cb1.html
  3. Metadata: Audio Description: In un prossimo futuro, i browser saranno in grado di riconoscere le piste di audio descrizione e di farne la sintesi vocale, fermando il video per il tempo necessario, ma non ci siamo ancora. Perciò per ora si tratta soprattutto di produrre una descrizione testuale continua che contenga le informazioni scritte e le descrizioni delle illustrazioni di Dante.
    Certo, si potrebbe anche piratare il video e aggiungervi una versione veramente audio di questa descrizione, ma cozzerebbe con la musica di Orff.

Quella che non c’è per ora è la pista dell’italiano: quella la faremo una volta fatte le altre cose, traducendo “O Fortuna” dalla pista latina, e ricopiando semplicemente la versione corretta dei sottotitoli di Dante dalla pista “Metadata: Geo”

Poi alla fine, potremo scaricare tutte le trascrizioni risultanti da tutti i sottotitoli, scaricabili come TXT dalle rispettive piste, per poi farne un unico documento testuale, illustrabile.

Ci sono interessati?

 

Advertisements


Leave a comment

Coursera’s Global Translator community: Transifex subtitle translation interface

NB this post is made to illustrate a reply to Transifex Support about the video player in the subtitle translation interface for the Global Translator Community. Transifex Support sent me a link to their Translating Subtitles in Transifex resource that explains about

It would be great if that were how it works in Coursera’s GTC projects, but it doesn’t.

From November 1 to November 18 2014, in GTC projects, the video player in the translation interface appeared like this (1):

screenshot of a Transifex Italian translation page for GTC subtitles

i.e.  not playing anything, just a black rectangle with the original subtitle overlaid

And since Nov. 19, 2014, the player has entirely disappeared.

[update Nov. 27, 2014: screenshot of the same https://www.transifex.com/projects/p/coursera-android/translate/#it/43/21811835 translation page, without any player:

screenshot of the page indicated above, taken on November 27, 2014

/update (1)]

Now the Translating Subtitles in Transifex resource also says:

If you want to see the default editor view without the video, click the gear icon and uncheck the box next to “enable video editor.”

So I checked if I had done that inadvertently, but I didn’t: the box is checked.

Could it be that the issue lies with the first part, i.e. that the maintainers of Coursera’s GTC projects made an error in adding the video links to create players?

(1) click on the picture to enlarge it


18 Comments

Sottotitoli: attenti al bug di Amara! #ltis13

Ieri tutti i sottotitoli in corso a partire dalla pagina http://www.amara.org/en/videos/cAxUVvevQqil/info/what-the-internet-is-doing-to-our-brains-epipheotv sono stati colpiti da un bug di Amara, ivi compresi i sottotitoli italiani ai quali Monica Terenghi stava lavorando.

Come ho scritto nel commento datato June 3, 2013 at 1:00 am al post “Sottotitoliamo insieme? #ltis13” questo bug colpisce a volte, ma non sempre, quando qualcuno aggiorna un set di sottotitoli tramite un upload di sottotitoli fatti altrove, oppure quando ripristina una versione precedente di un set di sottotitoli.  Il bug affetta i sottotitoli in corso e:

  1. li sostituisce con una versione che appare come “uploaded by retired user” nella lista delle revisioni dei sottotitoli (nel caso dei sottotitoli italiani di Monica, si tratta della Revision 2 ); di conseguenza, non è più possibile utilizzare l’interfaccia di traduzione con una casella dove tradurre sotto ogni sottotitolo: la sola possibilità – in Amara – è di tradurre direttamente dal video.
  2. cancella il contenuto delle revisioni precedenti, impedendo così di ripristinarle o almeno di scaricarle.

Congratulazioni a Monica che pur avendo appena cominciato a sottotitolare, non si è persa d’animo e ha semplicemente continuato a tradurre nelle difficili condizioni descritte in 1.

Però mi dispiace molto: siccome da un po’ di tempo, il bug non aveva colpito, credevo che gli sviluppatori di Amara lo avessero finalmente eliminato. In effetti, è almeno dal 22 marzo 2012, quando Amara si chiamava ancora Universal Subtitles, che è stato ripetutamente segnalato loro da utenti, persino nel caso di un video per la cui sottotitolazione “crowdsourced” Amara aveva un contratto con le Nazioni Unite: vedi Critical issue with uploads and rollbacks: software deletes/mangles subtitles and revisions.

Avessi saputo che invece il bug era ancora attivo, avrei proposto un’altro strumento online di sottotitolazione – anche se Amara rimane per altri versi lo strumento più facile da imparare a utilizzare: questa facilità non compensa casini di questo genere.

Ma gli sviluppatori sviluppano, non sottotitolano. Ed è probabilmente più stimolante per loro  elaborare gimmick dall’utilità dubbia (vedi Scrap the team dashboard page)  che non eliminare un mero bug, quali che ne siano le conseguenze devastanti per la sottotitolazione.

Come procedere?

Per le sottotitolazioni già in corso su Amara,

  • nel caso di una traduzione di sottotitoli: scaricate i vostri sottotitoli tradotti  sul computer ogni volta che fate “Save and Exit”, come file TXT e anche, se avete quasi finito, come file SBV o SRT, e aggiungete al nome del file il numero della revisione: sarà possibile riutilizzare questi file su un’altra piattaforma di sottotitolazione, oppure con il Google Translator Toolkit.
  • nel caso di una prima sottotitolazione nella lingua del video: se ci sono già traduzioni in corso, non fate aggiornamenti via upload e non ripristinate una versione anteriore dei sottotitoli.

Per nuovi video che desiderate sottotitolare o di cui desiderate tradurre sottotitoli esistenti, indicateli in un commento a questo post, e decideremo assieme come procedere.


1 Comment

Embed Google Drive 2: file audio e video

Vediamo se la procedura usata per inserire un foglio elettronico Drive nel  post precedente si può adattare a file audio e video  che si possono caricare su Drive, ma non sembrano coperti dall’aiuto WordPress.com, che sembra risalire a quando Google Drive era Google Docs  e funzionava soltanto con file testo (.odt, doc…), presentazioni slide e, appunto, fogli elettronici.

File audio

Drive non propone un codice embed per i file audio, soltanto un link da condividere pubblicamente, che consente solo il download, non l’esecuzione. Quindi non si potrebbe nemmeno pasticciarci per per produrre uno shortcode. Però provo con https://docs.google.com/file/d/0B5uzSw0MoY82Q2otZ0lReFp5Ykk/edit?usp=sharing cioè il file audio in http://iamarf.org/2013/05/05/post-audiomobilistico-2/ salvato e caricato su Drive, cioè con

(parentesi quadra)googleapps domain=”docs” query=”key=0B5uzSw0MoY82Q2otZ0lReFp5Ykk”(parentesi quadra):

Lo shortcode rimane anche dopo il passaggio a visual e il salva come bozza, ma non produce niente in Anteprima e la sorgente dell’anteprima dice:

<!-- Unsupported URL -->

File video

Drive propone un codice embed di tipo iframe per i video caricati. Provo con uno, cioè
(parentesi puntuta)iframe src=”https://docs.google.com/file/d/0B5uzSw0MoY82Q29rV2NubG9FOWc/preview&#8221; height=”385″ width=”640″(parentesi puntuta)(parentesi puntuta)/iframe(parentesi puntuta):
:

In modalità visual si vede un widget (accidenti, ho premuto Publish invece di Anteprima) e si vede pure il video embeddato nel poste: in effetti il software ha sputato uno shortcode:

(parentesi quadra)googleapps domain=”docs” dir=”file/d/0B5uzSw0MoY82Q29rV2NubG9FOWc/preview” query=”” width=”640″ height=”385″ /(parentesi quadra)

Però il video è lento a caricare, non è possibile aggiungervi dei sottotitoli – e ovviamente non ci sono nemmeno i sottotitoli automatici prodotti da YouTube.

Riassunto temporaneo

  • Per embeddare un file audio con player, non caricarlo su Drive ma ma un’altra piattaforma (vedi Prove di inserimento (embed) in blog WordPress.com – #ltis13)
  • Per embeddare un  file video con player, meglio caricarlo su YouTube (la soluzione più facile); Drive si può forse usare se si teme che l’ecerbero anticopia di YouTube decida che è la terza violazione grave del copyright e ti cancelli l’account. Ma quell’e-cerbero essendo una creatura Google, potrebbe anche spadroneggiare negli embed da Google Drive.

(Ma perché sto provando tutte queste soluzioni embed??? Io preferisco dare un semplice link, anzi, un semplice URL cliccabile agli “oggetti” esterni… W il testo, M al multimedia!!)