MEMORIA TÉCNICA: GALLAECIA MEDIA HACKLAB

1. INTRODUCIÓN E CONTEXTO

GallaecIA Media Hacklab xorde como resposta á necesidade de crear un espazo dixital especializado para a materia Xornalismo Automatizado Intelixente da Facultade de Ciencias da Comunicación (USC), ante a rápida evolución do xornalismo impulsado por intelixencia artificial. Este laboratorio dixital funciona como punto de confluencia entre a intelixencia artificial, o xornalismo e a formación universitaria.

O nome GallaecIA Media Hacklab foi concibido como unha combinación poderosa, creativa e con forte identidade que reflicte tanto as raíces culturais como a proxección tecnolóxica do proxecto:

• GallaecIA: Fusiona Gallaecia, o nome histórico de Galicia durante o período romano, con IA (Intelixencia Artificial). Esta hibridación establece un vínculo distintivo entre a tradición cultural galega e a vangarda tecnolóxica, creando unha identidade única que ancla o proxecto no territorio mentres proxecta cara ao futuro.
• Hack: O termo "hack" achega dinamismo e enfoque na experimentación, innovación e colaboración. No contexto académico, evoca a filosofía hacker de libre información, libertade de expresión, curiosidade intelectual, aprendizaxe colaborativa e busca de solucións creativas a problemas complexos, moi adecuado para un laboratorio universitario onde se fomenta a experimentación coas tecnoloxías emerxentes.
• Media: Sitúa o laboratorio no terreo dos medios de comunicación, e faino en plural e en sentido amplo. Non se traballa cun soporte senón con todos: texto, son, vídeo, web e software. Esa amplitude non é decorativa —é literal— e reflíctese na estrutura do sitio, que recoñece cinco tipos de contido en vez de tratar todo como se fose unha páxina que se le.
• Lab: O sufixo "Lab" reforza explicitamente a idea dun espazo dedicado á investigación, creatividade e exploración. Transmite a natureza experimental e científica do proxecto, onde as fronteiras entre docencia, investigación e innovación se difuminan para crear unha contorna de aprendizaxe integral.

Así, GallaecIA Media Hacklab configúrase como un laboratorio de innovación en IA e xornalismo, ancorado na tradición galega pero mirando decididamente ao futuro, onde a identidade cultural non se opón á modernidade tecnolóxica senón que a enriquece e dóalle un carácter distintivo.

O proxecto nace nun momento –o ano 2025– no que a converxencia entre tecnoloxía e xornalismo esixe non só novos coñecementos técnicos, senón tamén espazos de experimentación, exhibición e arquivo que permitan tanto o aprendizaxe práctico como a documentación histórica desta transformación profesional.

2. OBXECTIVOS ESTRATÉXICOS

2.1 Obxectivos principais

• Consolidar un espazo de innovación onde os estudantes poidan experimentar con ferramentas de IA aplicadas ao xornalismo
• Establecer un repositorio evolutivo que documente o desenvolvemento de proxectos xornalísticos xerados con IA ao longo de diferentes cursos académicos
• Crear un escaparate de talento para mostrar as capacidades creativas desenvolvidas na facultade
• Xerar un recurso educativo aberto para a comunidade académica e profesional
• Formar en desenvolvemento de software aplicado: o alumnado non só usa ferramentas de IA, senón que constrúe as súas —asistentes, bitácoras, buscadores de fontes—, o que esixe programar, documentar e publicar código propio
• Que cada peza se poida compartir, para que o traballo sirva tamén fóra da aula: nunha candidatura, nun perfil profesional ou nunha conversa

2.2 Obxectivos técnicos

• Desenvolver un sistema autoxestionado capaz de organizar e presentar de forma automatizada non só contidos multimedia, senón tamén software: as entregas do alumnado inclúen xa aplicacións executables e código, que esixen unha presentación distinta á dunha reportaxe ou un podcast
• Implementar unha arquitectura extensible que permita a incorporación continua de novos proxectos e formatos
• Garantir a accesibilidade multiplataforma aos recursos xerados
• Asegurar a preservación a longo prazo dos traballos académicos

3. ARQUITECTURA DO SISTEMA

3.1 Estrutura organizativa

O portal estrutúrase en catro piares. O primeiro deixou de ser só «proxectos web»: recolle tamén software, e por iso na epígrafe seguinte se detallan os cinco tipos de contido que o sistema distingue.

1. Biblioteca de proxectos: traballos integrais desenvolvidos con tecnoloxías de IA, desde reportaxes navegables ata aplicacións con código propio
   • Sección curso actual
   • Arquivo histórico por anos académicos
2. Repositorio audiovisual: Contidos xerados mediante IA
   • Galería de vídeo (curso actual e arquivo)
   • Galería de audio (curso actual e arquivo)
3. Espazo de acollida: obra allea á materia que se hospeda no sitio
   • Traballos que non forman parte da avaliación pero que teñen interese
   • Convive coa galería do curso sen mesturarse con ela, e ten páxina de entrada propia
4. Sistema de metadatos: Capa de organización que cataloga e relaciona contidos
   • Metadatos de autor
   • Metadatos temporais
   • Metadatos descritivos

3.2 Os cinco tipos de contido

A biblioteca de proxectos deixou de ser só «proxectos web». Desde o curso 2025-26 o sistema recoñece cinco tipos, porque as entregas deixaron de parecerse entre si: xa non todas son unha web que se abre e se le.

O tipo non se adiviña: cada entrega decláraio no seu _meta/proxecto.json, xunto coa páxina que hai que abrir (entrada_publica) e a súa ficha metodolóxica. Se ese ficheiro non existe, o xerador dedúceo da estrutura de carpetas.

3.3 Como se organiza unha entrega

Unha entrega non é só o que se publica. Trae tamén código fonte, dependencias, apuntamentos e a copia da súa ficha. Se todo iso vai xunto, acaba no servidor: node_modules enteiros, entornos virtuais de Python, ficheiros de traballo. Por iso cada entrega se normaliza cunha estrutura fixa que separa o publicable do que non o é:

<autoría>/
├── index.html          # A entrada pública. Isto é o que ve quen visita
├── media/              # Vídeo de demostración e material público
├── _fonte/             # Código fonte e material de traballo
├── _local/             # node_modules, .venv, .git — nunca se publica
├── _meta/              # proxecto.json: tipo, entrada pública, ficha
└── _metodoloxia/       # Copia interna da ficha da autoría
            

As carpetas que empezan por guión baixo non se soben nunca: están excluídas en .ftpignore e na comprobación previa ao despregue, que ademais percorre o inventario real buscando calquera cousa que pareza privada. Encárgase da normalización scripts/normalizar_proxectos.py, que por defecto só simula e esixe --apply para mover nada.

3.4 Que entra na entrega e que non

Na carpeta de cada traballo vai o que forma parte da peza e o código necesario para reproducila. O material co que se traballou —o texto en Word, o guión en PDF, a folla de cálculo dos datos— gárdase aparte, fóra do árbore do proxecto.

O motivo é de privacidade máis ca de peso: un documento de ofimática leva nos seus metadatos internos o nome legal completo de quen o escribiu, comprimido dentro do ficheiro, onde un escáner de texto non chega. Publicalo sería publicar ese nome sen sabelo. Por iso a comprobación previa ao despregue mira o árbore enteiro —e tamén dentro dos ZIP, que son carpetas comprimidas— e detense se atopa algún.

3.5 Fluxo de traballo

O sistema implementa un fluxo de traballo automatizado:

1. Entrada: Os estudantes depositan os seus proxectos en carpetas específicas (proxectos/curso_actual, video/curso_actual, audio/curso_actual)
2. Procesamento: Scripts automatizados detectan, optimizan e catalogan os contidos
3. Arquivado: Ao finalizar o curso académico, os contidos trasladanse automaticamente ao arquivo histórico
4. Visualización: O frontend presenta os contidos organizados segundo a súa tipoloxía e cronoloxía

4. IMPLEMENTACIÓN TÉCNICA

4.1 Stack tecnolóxico

O proxecto desenvolveuse baixo un paradigma de simplicidade efectiva, priorizando a mantenibilidade e robustez sobre a complexidade innecesaria.

Frontend:

• HTML5 semántico para estrutura de contidos
• CSS3 con sistema de deseño baseado en Grid/Flexbox
• JavaScript vanilla para interactividade (evitando dependencias de frameworks)
• Deseño responsivo con enfoque mobile-first

Backend/Automatización:

• Python 3.x para xeración automática de HTML e procesamento de metadatos
• Bash scripting para automatización de tarefas de optimización
• Sistema de plantillas baseado en f-strings para xeración de código
• JSON como formato lixeiro de almacenamento de metadatos

Multimedia:

• ffmpeg para optimización de vídeo e conversión de formatos
• Librería Pillow para procesamento de imaxes e xeración de miniaturas
• Metadatos embebidos para preservación de información de autoría

Seguridade e optimización:

• Configuración .htaccess para control de acceso e protección de recursos
• Todo o tráfico cifrado: as peticións en http:// redirixen (301) á mesma ruta en https://
• Minificación CSS/JS para optimización de rendemento
• Carga diferida (lazy loading) para recursos multimedia

4.2 Solucións de deseño

Deseño visual: Adoptouse unha estética "retro-futurista" inspirada en interfaces de terminal, aplicando:

• Paleta cromática limitada pero impactante (verdes, azuis e magentas sobre fondo escuro)
• Tipografía monoespaciada que evoca terminais de comando
• Efectos visuais inspirados en pantallas CRT (scanlines, glowing, etc.)
• Microinteraccións sutiles para mellorar a experiencia de usuario

Estrutura de interface:

• Cabeceira: Identidade visual e navegación principal
• Menú de navegación: Acceso ás diferentes seccións con versión responsiva para dispositivos móbiles
• Corpo principal: Sistema de galerías modulares con previsualizacións
• Sistema de acordeóns: Para acceso ao arquivo histórico
• Reproductor modal: Para visualización de contidos multimedia sen navegación
• Pé de páxina: Información legal, licenza e créditos institucionais

Como se adapta a pantallas estreitas:

As galerías son unha rexa CSS que reparte as tarxetas en tantas columnas como caiban, cun ancho mínimo por tarxeta. Escrito da maneira habitual —minmax(350px, 1fr)— ese mínimo é literal: nunha pantalla máis estreita ca el a columna non encolle, e a tarxeta sáese. A forma que si funciona en calquera ancho é minmax(min(350px, 100%), 1fr): nun escritorio 100% é maior ca 350px e o resultado é o mesmo de sempre; nun móbil o mínimo pasa a ser o ancho dispoñible e a columna encólle ata caber. Un só valor, sen depender de puntos de ruptura.

O mesmo criterio no resto: os contedores contan o seu recheo dentro do ancho (box-sizing: border-box), as marxes laterais redúcense por baixo de 600px, os títulos e as rutas longas poden partirse (overflow-wrap) e os botóns que se tocan cun dedo manteñen 44x44 píxeles. A comprobación é medible e faise a 320, 360, 390 e 430px: o ancho desprazable do documento nunca debe superar o da xanela.

5. IMPLEMENTACIÓN COMO PWA (PROGRESSIVE WEB APP)

5.1 Características PWA implementadas

O proxecto foi deseñado como unha Progressive Web App completa, permitindo aos usuarios instalar a aplicación nos seus dispositivos como se fose unha app nativa:

• Manifest.json: Configuración completa con metadatos, iconos e atallos personalizados
• Service Worker: Xestión inteligente de caché con estratexias Cache First e Network First
• Instalabilidade: Botón de instalación automático en navegadores compatibles
• Funcionamento offline: Acceso a contidos cacheados sen conexión a internet
• Atallos de aplicación: Acceso directo a Proxectos, Arquivo e Metodoloxía

5.2 Arquitectura do Service Worker

Implementouse un sistema de caché en dúas capas:

• Caché estático: Para recursos fundamentais (HTML, CSS, JS, iconos)
• Caché dinámico: Para contidos JSON e metadatos que se actualizan con frecuencia
• Exclusións intelixentes: Arquivos multimedia pesados excluídos do caché para optimizar espazo
• Actualización automática: Sistema de notificacións para informar sobre novas versións

5.3 Xestión de iconos e metadatos

Creouse un sistema completo de iconos optimizados:

• 32x32px: Favicon e iconos pequenos
• 96x96px: Iconos para atallos de aplicación
• 192x192px: Tamaño mínimo requirido para instalación PWA
• 512x512px: Icono de alta resolución para splash screens

6. SCRIPTS DE AUTOMATIZACIÓN

O proxecto inclúe varios scripts esenciais para o seu funcionamento:

6.1 Xerador de galerías (xerar_galeria.py)

• Escanea directorios de proxectos, vídeo e audio
• Extrae metadatos (títulos, descricións, autores) de arquivos
• Xera bloques HTML para cada tipo de contido
• Actualiza automaticamente o index.html cos novos contidos
• Xestiona a estrutura de arquivos JSON para persistencia
• Implementa limpeza automática de recursos orfos
• Xestión avanzada de caracteres especiais e acentos galegos

6.2 Optimización multimedia

• optimizar_videos.sh: Comprime os vídeos con ffmpeg (H.264, lado maior 1280, AAC 192k), iguala o volume a -16 LUFS e evita reprocesar o xa optimizado
• optimizar_audio.sh: Converte o audio a MP3 a 192 kbps, iguala o volume a -16 LUFS e mantén o rexistro do xa procesado
• marcar_ficheiros_procesados.sh: Sistema de seguimento que evita reprocesar o material xa optimizado, comprobando que cumpre antes de marcalo
• converter_videos_ios.sh: Converte os perfís H.264 que Safari en iOS non reproduce
• optimizar_videos_paralelo.sh: Versión paralela do optimizador de vídeo: reparte o traballo entre os núcleos dispoñibles con GNU parallel
• transcribir_aperturas.py: Transcribe en local a apertura dunha peza para poder titulala cando o título entregado non a nomea

6.3 Xestión PWA e optimización

• pwa-manager.js: Xestión completa de instalación PWA, notificacións e funcionamento offline
• service-worker.js: Implementación de caché inteligente e estratexias de rede
• manifest.json: Declara o nome, as cores, os atallos e o xogo de iconas en 32, 96, 192 e 512 px, que son os tamaños que os navegadores piden para instalar a aplicación

6.4 Privacidade e preparación da publicación

• sanear_fichas.py: Xera a copia pública saneada de cada ficha metodolóxica (contido/fichas/) a partir do orixinal privado, sen correos e coas imaxes extraídas a ficheiros
• escanear_pii.py: Porta de privacidade: busca correos, teléfonos, DNI e credenciais no material publicable e detén a publicación se atopa algo sen revisar
• preparar_despregue.py: Comprobacións antes de publicar: datos persoais, fichas saneadas, .htaccess, nomes portables, rutas que resolvan, documentación ao día e minificados
• xerar_sitemap.py: Constrúe o sitemap.xml a partir do contido real publicado
• baixar_respaldo.py: Baixa do servidor unha copia do publicado e un inventario completo, para poder volver atrás
• ftp_comun.py: Conexión FTP cifrada e percorrido do servidor, compartido polas ferramentas de respaldo, limpeza e publicación
• limpar_remoto.py: Retira do servidor o material que non debe estar publicado, gardando antes unha copia
• publicar_ftp.py: Sobe ao servidor só o que é novo ou cambiou, comparando contra un respaldo previo
• verificar_publicado.py: Comproba contra o servidor real que o publicado funciona e que nada privado responde

6.5 Presentación e contido

• xerar_pezas.py: Dálle a cada traballo unha URL propia con etiquetas Open Graph, para que ao compartilo se vexa a súa tarxeta e non unha ligazón espida
• xerar_espazos_apps.py: Constrúe o portal público de cada aplicación, da materia ou acollida no sitio: demostración, árbore de ficheiros do repositorio (Markdown formatado), ZIP, ficha metodolóxica ou referencia citable
• capturar_miniaturas.py: Captura as miniaturas dos proxectos web con Chrome en modo headless
• optimizar_imaxes.py: Redimensiona e recomprime as imaxes conservando o nome do ficheiro, para non romper as referencias do código do alumnado
• normalizar_contedores.py: Deixa todo o multimedia en .mp4 e .mp3: remuxea sen recodificar cando o contido xa é válido
• inxectar_volver_galeria.py: Inxecta un botón flotante «Volver á galería» nas entregas que non teñen navegación de retorno propia
• minificar.sh: Xera styles.min.css e bundle.min.js para produción

6.6 Estrutura das entregas e auditoría

• normalizar_proxectos.py: Normaliza cada entrega á estrutura estándar: entrada pública na raíz e material non publicable en _fonte/, _local/, _meta/ e _metodoloxia/
• auditar_estado_local.py: Informe de só lectura sobre cursos, datos públicos, fichas e multimedia
• control_fichas_metodoloxia.py: Detecta fichas metodolóxicas ausentes ou orfas respecto do material entregado
• detectar_enlaces_proxectos.py: Descobre e verifica o repositorio e a aplicación en liña de cada entrega, sen listas escritas a man
• actualizar_rutas.sh: Actualiza a función de visualización de rutas nos scripts de optimización
• limpar_duplicados.sh: Detecta e retira ficheiros multimedia duplicados
• normalizar_nomes.py: Deixa os nomes de ficheiro e carpeta en NFC e sen espazos sobrantes, para que as rutas funcionen fóra de macOS

O listado completo, sempre ao día e co código descargable, está en directorio.html: xérase a partir dos propios ficheiros, así que non pode quedar desfasado como si lle pasa a un texto escrito a man.

7. ESTRUTURA DE CARPETAS

gallaecia_media_hacklab/
├── index.html            # A galería: a portada do sitio
├── acollida.html         # Entrada do espazo de acollida
├── directorio.html       # Este repositorio explicado, co código descargable
├── memoria.html          # Esta memoria técnica
├── viewcode.html         # Visor do código do proxecto no propio sitio
├── bloques_*.html        # Anacos de HTML xerados e enxertados no index
├── pezas/                # Unha páxina por traballo, con Open Graph
├── sitemap.xml           # Mapa do sitio para os buscadores
├── assets/               # Recursos estáticos
│   ├── css/              # Estilos (styles.css, styles.min.css)
│   ├── js/               # JavaScript (bundle.js, bundle.min.js, pwa-manager.js)
│   ├── img/              # Imaxes de interface e iconos PWA
│   └── thumbs/           # Miniaturas xeradas automaticamente
├── datos/                # Metadatos persistentes (JSON)
├── logs/                 # Arquivos de seguimento para optimización
│   ├── audio_procesados.json  # Rexistro de audios procesados
│   ├── videos_procesados.json # Rexistro de vídeos procesados
│   └── procesamento_*.log    # Logs detallados de operacións
├── proxectos/            # Proxectos web, aplicacións e programación
│   ├── curso_actual/     # Proxectos do curso vixente 2025-26
│   └── arquivo/          # Proxectos de cursos anteriores (2024-25)
├── video/                # Contidos de vídeo optimizados
│   ├── curso_actual/     # Vídeos do curso 2025-26
│   └── arquivo/          # Arquivo histórico de vídeos (2024-25)
├── audio/                # Contidos de audio optimizados
│   ├── curso_actual/     # Audios do curso 2025-26
│   └── arquivo/          # Arquivo histórico de audios (2024-25)
├── espazo_de_acollida/   # Traballos acollidos alleos á materia
├── metodoloxia/          # Sistema de fichas metodolóxicas
├── metodoloxia_fichas/   # Fichas orixinais (LOCAL: levan datos de contacto)
├── contido/fichas/       # Copia saneada e pública: é a que le a web
├── xerar_galeria.py      # O xerador: le o disco e reconstrúe o sitio enteiro
├── scripts/              # Scripts de automatización e optimización
├── docs/                 # Notas de traballo do profesorado (non se publican)
├── deploy/               # Informes de despregue e lista revisada de datos persoais
├── backup/               # Respaldos automáticos con timestamp
├── manifest.json         # Configuración PWA
├── service-worker.js     # Service Worker para funcionamento offline
├── .htaccess             # Bloqueos, cabeceiras de caché e regras do servidor
├── .ftpignore            # Que non se publica (espello das exclusións do panel)
├── htaccess-modelo.txt   # O .htaccess en texto, para poder lelo desde a web
├── dashboard-metodoloxias-modelo.txt  # O visor docente, só como modelo
├── robots.txt            # Que poden indexar os buscadores
├── requirements.txt      # Dependencias de Python
├── LICENSE-CODE          # GPL v3, para o código
├── LICENSE-CONTENT       # CC BY-NC-SA 4.0, para o contido
├── AUTHORS               # Autoría do proxecto
└── README.md             # Documentación do proxecto
            

8. INTEGRACIÓN REDES SOCIAIS (OPEN GRAPH)

Cada traballo do alumnado ten dirección propia e pode compartirse por redes, mensaxería ou correo amosando a súa tarxeta: imaxe, título e autoría. O sitio enteiro leva ademais as etiquetas do laboratorio.

8.1 Implementación técnica

<meta property="og:title" content="Altavoz Divino — Paula Bouza, Adrián Abelenda e Lucía Bello">
<meta property="og:description" content="Peza sonora · Curso 2025-26 · GallaecIA Media Hacklab">
<meta property="og:image" content="https://ia.xornalismo.gal/assets/thumbs/…/audio2.jpg">
<meta property="og:url" content="https://ia.xornalismo.gal/pezas/2025-26/audio/altavoz-divino.html">
<meta property="og:type" content="article">
<meta property="og:locale" content="gl_ES">

<!-- Twitter específico -->
<meta name="twitter:card" content="summary_large_image">
<meta name="twitter:title" content="Altavoz Divino — Paula Bouza, Adrián Abelenda e Lucía Bello">
<meta name="twitter:image" content="https://ia.xornalismo.gal/assets/thumbs/…/audio2.jpg">
            

A og:image ten que ser unha URL absoluta: as redes non resolven rutas relativas. As imaxes que se anuncian van de 640×360 a 1200×630 segundo a peza, todas por riba do mínimo de 200×200 que esixen as redes.

8.2 Por que páxina propia e non un parámetro na URL

A solución simple sería ?peza=<id> abrindo o modal correspondente. Non serve: as redes sociais e a mensaxería non executan JavaScript. Un enlace así permitiría enviar a peza a alguén, pero WhatsApp, LinkedIn ou Bluesky seguirían amosando unha ligazón espida. A previsualización esixe que as etiquetas veñan xa no HTML que devolve o servidor, e iso obriga a ter unha páxina real.

Aplícase segundo o que xa existe, sen duplicar nada:

• Proxectos e traballos acollidos xa teñen páxina propia —a entrega do alumnado—, así que só se lles inxectan as etiquetas no <head>, cun marcador que permite reexecutar sen duplicar.
• Audio e vídeo non tiñan páxina: xérase unha en pezas/<curso>/<tipo>/<slug>.html, co reprodutor, a autoría, a licenza e a volta á galería.

Encárgase scripts/xerar_pezas.py, que escribe tamén datos/pezas.json: o mapa que usa a galería para poñer o botón «Compartir» en cada tarxeta sen ter que reproducir no navegador a regra dos nomes.

8.3 Beneficios

• O alumnado pode ensinar o seu traballo: nunha candidatura, nun perfil profesional ou nunha conversa, cun enlace que se ve ben. Antes o máximo que se podía enviar era a sección enteira con 62 audios.
• Visibilidade en buscadores: cada peza é unha URL indexable; o sitemap.xml pasou de 31 a 143.
• Presentación coherente da identidade visual.
• Sen dependencias externas: as vías de compartir son ligazóns de intención (wa.me, mailto:…), non widgets. Non se carga ningún script de terceiros, así que ningunha rede social recibe datos de quen visita a web só por estar na páxina.

8.4 Que se amosa en cada dispositivo, e por que

A API navigator.share abre a folla de compartir do sistema operativo. No móbil é a mellor opción posible, porque amosa as aplicacións que esa persoa ten instaladas de verdade. Pero tamén existe en macOS, e alí abre a folla do sistema —Notas, Recordatorios, AirDrop—, que non é o que espera quen preme «Compartir» nunha web.

Por iso a decisión non se toma polo tamaño da pantalla senón polo tipo de dispositivo, coa consulta (hover: none) and (pointer: coarse): sen hover e con punteiro groso hai un dedo, non un rato.

• Móbil e tableta: ábrese directamente a folla do sistema.
• Escritorio (Windows, Linux, macOS, calquera navegador): ábrese o menú propio. Quen queira a folla do sistema aínda a ten como última opción do menú.

8.5 Que vías se ofrecen, e por que esas

Nove vías, escollidas polo que usa de verdade este público —xornalismo e universidade en Galicia— e non por moda: WhatsApp, Telegram e correo para enviarllo a alguén concreto, que é como máis se comparte un traballo; Mastodon, Bluesky, LinkedIn, Facebook, Threads e X para publicalo. Máis copiar a ligazón.

Mastodon ten unha particularidade: non hai un dominio único, cada persoa está na súa instancia. Por iso se lle pregunta a primeira vez e se garda no seu navegador, para non volver preguntar. Esa preferencia non sae do seu equipo: non se envía a ningures nin queda rexistrada no servidor.

E as que non están? Moitas plataformas moi usadas non ofrecen ningunha ligazón de intención: Matrix/Element, Signal, Discord ou Slack non teñen forma estándar de recibir unha URL desde unha web. Non é unha omisión, é que non existe. Para todas elas hai dúas vías que si funcionan: copiar a ligazón —por iso é unha opción de primeira clase e non un recurso menor— e, no móbil, a folla do sistema, que si coñece as aplicacións instaladas. Ese mesmo camiño serve para calquera plataforma que apareza no futuro, sen tocar o código.

A lista non cambia segundo o tipo de peza, e é deliberado: as plataformas non distinguen entre un audio e un proxecto, todas reciben unha URL e pintan a tarxeta de Open Graph. Facer listas distintas por tipo sería inventar unha diferenza que non existe. O que si muda é o texto, que é onde a distinción ten sentido:

Se a persoa pecha a folla sen compartir, non pasa nada máis: pechar non é un fallo. Só se recorre ao menú se a folla dá erro de verdade. E para copiar a ligazón úsase o portapapeis moderno cando está dispoñible —esixe conexión segura— cun método antigo de reserva, para que funcione tamén onde non o estea.

9. FLUXO DE ACTUALIZACIÓN

O proceso de actualización segue un fluxo sistemático:

9.1 Recollida de novos contidos

Na carpeta de cada entrega vai a peza e o código que fai falta para reproducila. O material co que se traballou —textos en Word, guións en PDF, follas de cálculo— gárdase fóra do árbore do proxecto: non é contido web e leva nos seus metadatos internos o nome legal de quen escribiu o ficheiro.

• Os estudantes entregan traballos en formatos predefinidos
• Deposítanse nas carpetas correspondentes do curso actual

9.2 Preparación e optimización

Antes de procesar os novos contidos, é fundamental executar o script de marcado para establecer un punto de referencia:

bash scripts/marcar_ficheiros_procesados.sh

Este script crea un rexistro dos arquivos existentes en logs/audio_procesados.json e logs/videos_procesados.json para evitar o reprocesamento innecesario, mellorando a eficiencia do sistema. A continuación, procédese á optimización dos contidos multimedia. Ademais de comprimir, os dous scripts igualan o volume a -16 LUFS e limitan o lado maior do vídeo a 1280 px, de xeito que ningunha peza se escoite máis alta nin se vexa máis grande ca outra:

bash scripts/optimizar_videos.sh
bash scripts/optimizar_audio.sh

O sistema inclúe mecanismos para preservar caracteres especiais e acentos nos nomes de autores. Se é necesario modificar manualmente os nomes con tildes ou caracteres especiais, pódese utilizar o seguinte comando:

python3 xerar_galeria.py --editar-autores

9.3 Xeración de estrutura e metadatos

python3 xerar_galeria.py

9.4 Minificación para produción

bash scripts/minificar.sh

Convén minificar antes de xerar. O ?v=<hash> que rompe a caché do navegador escríbeo xerar_galeria.py co contido que ten o asset nese intre, así que minificar despois deixa o hash apuntando á versión anterior: o ficheiro do servidor sería o novo e o navegador seguiría co vello ata que caducase a caché, un mes. Se se fai nesa orde, abonda con volver executar o xerador; a comprobación previa ao despregue detecta o desfase e detense.

9.5 Publicación no servidor

A xeración deixa o sitio listo en local; publicalo é un paso á parte, e faise sempre nesta orde. As dúas primeiras ordes non soben nada, e a terceira só sobe o que cambiou.

python3 scripts/preparar_despregue.py     # audita o que se subiría
python3 scripts/baixar_respaldo.py        # garda o que hai publicado
python3 scripts/publicar_ftp.py           # simulacro: que subiría
python3 scripts/publicar_ftp.py --aplicar # sobe só o novo ou cambiado
python3 scripts/verificar_publicado.py    # comproba contra o sitio publicado

A comprobación previa detense se atopa datos persoais sen revisar, fichas orixinais no inventario, nomes de ficheiro que non funcionarían noutro sistema ou documentación desactualizada. A subida vai cifrada, compara contra o respaldo para non retransmitir o que xa está igual, pódese retomar se se corta e nunca borra nada. Para retirar algo do servidor hai unha ferramenta á parte, que copia e verifica antes de borrar: o material privado, e tamén o que quedou fóra do sitio (o curso que pasou a arquivo, nomes e formatos que cambiaron).

9.6 Arquivado ao finalizar curso académico

• Os contidos migran automaticamente ao arquivo histórico
• Presérvase a estrutura e metadatos asociados
• As ligazóns antigas a curso_actual/ seguen funcionando: o servidor redirixe a arquivo/

9.7 Limpeza automática de recursos

O sistema inclúe funcionalidades de limpeza automática:

• Miniaturas orfas: Elimina miniaturas de vídeos que xa non existen
• Autores orfos: Limpa entradas de autores sen contido asociado
• Entradas JSON orfas: Elimina referencias a arquivos inexistentes

10. DESAFÍOS E SOLUCIÓNS

10.1 Desafíos técnicos

Durante o desenvolvemento, enfróntanse diversos retos técnicos:

1. Heteroxeneidade de formatos multimedia: Solucionado mediante scripts de normalización que garanten compatibilidade cross-browser.
2. Nomenclatura inconsistente: Implementamos un sistema de normalización de nomes de arquivos que preserva a autoría mentres estandariza a estrutura.
3. Optimización de recursos pesados: Desenvolvemos unha cadea de procesamento que reduce significativamente o tamaño dos arquivos multimedia sen comprometer a calidade perceptible: vídeo a H.264 con CRF 24 e lado maior de 1280 px, audio a 192 kbps e volume igualado a -16 LUFS. A redución depende de canto pesaba o orixinal: nun vídeo de cámara en 4K chega ao 85 %, e nun 1080p habitual está entre o 60 % e o 65 %.
4. Adaptabilidade a distintos dispositivos: Implementamos un deseño responsivo con breakpoints estratéxicos e tratamento específico para a visualización de vídeos verticais vs. horizontais.
5. Escalabilidade do repositorio: A arquitectura modular permite a incorporación continua de contidos sen degradar o rendemento do sistema.

10.2 Axustes de deseño

O proceso iterativo incluíu varias refinamentos de deseño:

1. Mellora de grid responsivo: Inicialmente xurdiron problemas coa visualización de galerías en diferentes tamaños de pantalla. Resolvéuse mediante un sistema de grid avanzado que mantén a coherencia visual.
2. Optimización de controis de reprodución: Os controis nativos adaptáronse para mellorar a accesibilidade e experiencia de usuario.
3. Refinamento do sistema modal: Implementouse un lightbox personalizado para visualización de contidos sen interferir coa navegación principal.

11. IMPACTO EDUCATIVO

11.1 Beneficios pedagóxicos

O proxecto aporta múltiples vantaxes ao contorno académico:

• Motivación por exhibición: O coñecemento de que os seus traballos serán publicamente accesibles incrementa a motivación e compromiso dos estudantes.
• Aprendizaxe por observación: O acceso a traballos de cursos anteriores proporciona referencias e establece estándares de calidade.
• Documentación de evolución: Permite observar a progresión de técnicas e aproximacións ao longo do tempo.
• Creación de portafolio: Os estudantes obteñen un espazo permanente onde mostrar as súas competencias a potenciais empregadores.

11.2 Proxección profesional

O laboratorio actúa como ponte entre formación e profesión:

• Visibilidade externa: Expón o talento estudantil ao sector profesional.
• Experimentación sen riscos: Permite explorar técnicas innovadoras nun contorno controlado.
• Documentación de procesos: Non só se mostran resultados finais, senón tamén metodoloxías e procesos creativos.

12. ANÁLISE DE RESULTADOS

12.1 Métricas actuais

• Volume do repositorio: 24 proxectos, 51 vídeos e 62 audios catalogados (curso 2025-26: 15 proxectos, 15 vídeos e 28 audios; arquivo 2024-25: 9 proxectos, 36 vídeos e 34 audios)
• Diversidade de formatos: Proxectos web, aplicacións, programación, vídeos, podcasts e pezas sonoras
• Fichas metodolóxicas: 137 fichas públicas, unha por peza
• Cobertura temporal: 2 cursos académicos documentados (2024-25 e 2025-26)
• Redución de peso: arredor do 60 % de media sobre o material orixinal, ata o 85 % nas gravacións en 4K
• Formato uniforme: todo o vídeo en H.264 cun lado maior de 1280 px e todo o audio en MP3 a 192 kbps, co volume igualado a -16 LUFS

12.2 Logros cualitativos

• Estandarización de entregas: Establecemento de formatos e procesos consistentes
• Documentación histórica: Preservación sistemática da evolución da materia
• Interface intuitiva: Acceso estruturado a contidos complexos
• Identidade visual distintiva: Estética memorable que reforza o concepto do laboratorio

13. SISTEMA DE FICHAS METODOLÓXICAS

13.1 Innovación pedagóxica

Unha das características máis distintivas do sistema é a implementación dun sistema de fichas metodolóxicas progresivas que documenta non só os resultados finais dos proxectos, senón tamén os procesos, ferramentas e metodoloxías empregadas polos estudantes.

13.2 Funcionalidades do sistema

• Fichas básicas: Permiten crear entradas con datos esenciais (título, autor, tipo) para mostrar contidos inmediatamente
• Completado progresivo: As fichas poden irse expandindo gradualmente con información metodolóxica detallada
• Carga automática de títulos: O sistema detecta fichas básicas e actualiza automaticamente os títulos na interface
• Indicadores visuais: Diferenciación clara entre fichas completas e en proceso mediante avisos contextuais
• Dashboard de xestión: Ferramenta interna para profesorado que permite análise, filtrado e exportación de fichas

13.3 Dous planos: por que a ficha que le a web non é a orixinal

O formulario pídelle ao alumnado o nome completo e o correo, porque o profesorado precisa saber de quen é cada entrega e poder responderlle. Iso convirte cada ficha nun documento con datos persoais, e ese documento non pode ser o mesmo que serve a web pública.

De aí que haxa dous planos, e que a diferenza sexa física e non un permiso que se poida esquecer:

A autoría si é pública: é o recoñecemento do traballo, e para iso se publica. O que non sae é a forma de contactar con esa persoa.

Tres barreiras independentes sosteñen a separación, e ningunha depende de que alguén se lembre no momento de publicar:

1. Os orixinais non se soben: están excluídos en .ftpignore e na preparación do despregue.
2. Se chegasen ao servidor por erro, o .htaccess respóndelles 403.
3. O navegador non os pide nunca: o JavaScript le só de contido/fichas/.

A comprobación previa ao despregue verifica as tres, e ademais que ningunha das fichas públicas conteña un correo. Non abonda con que non suban os orixinais: unha copia pública mal xerada pasaría esa comprobación e non esta.

13.4 Beneficios educativos

Este sistema aporta valor pedagóxico significativo:

• Documentación de procesos creativos: Non só se preservan resultados, senón metodoloxías e aprendizaxes
• Flexibilidade temporal: Permite entregas escalonadas sen afectar á experiencia de usuario
• Análise comparativa: Facilita o estudo de diferentes aproximacións metodolóxicas
• Feedback estruturado: Base para avaliación detallada e constructiva

14. CONCLUSIÓNS

GallaecIA Media Hacklab representa unha resposta integral aos desafíos que presenta a incorporación da intelixencia artificial ao currículo xornalístico. Non só funciona como un repositorio técnico, senón como un espazo vivo de experimentación, documentación e exhibición.

A súa posta en marcha demostrou que:

1. A automatización de procesos libera tempo para centrarse en aspectos creativos e pedagóxicos.
2. A preservación sistemática de traballos académicos crea un valioso recurso educativo evolutivo.
3. A estética distintiva reforza conceptualmente a natureza innovadora do proxecto.
4. A arquitectura modular garante sustentabilidade e adaptabilidade a futuras necesidades.

Este proxecto establece as bases para un novo paradigma na ensinanza do xornalismo automatizado, onde a tecnoloxía non só é obxecto de estudo, senón tamén infraestrutura que facilita e potencia o proceso educativo.

ANEXO: EQUIPO E CONTACTO

Dirección do proxecto:
Alberto Quian
Facultade de Ciencias da Comunicación - Universidade de Santiago de Compostela

Integración institucional:
GallaecIA Media Hacklab é un dos Proxectos de Xornalismo que aloxa xornalismo.gal, un conxunto de espazos de experimentación e innovación en comunicación dixital promovidos co apoio do grupo de investigación Novos Medios, na Facultade de Ciencias da Comunicación da Universidade de Santiago de Compostela. Ocupa o subdominio ia.xornalismo.gal, dedicado en exclusiva á intersección entre xornalismo e intelixencia artificial.

Contexto académico:
Este proxecto desenvólvese no marco das materias e liñas de investigación en innovación xornalística, novas narrativas e tecnoloxías emerxentes do Departamento de Ciencias da Comunicación, co apoio do grupo de investigación Novos Medios, ofrecendo un espazo de converxencia entre docencia, investigación e transferencia de coñecemento.