Metadatos de imágenes y gestión de medios en WordPress multilingüe

Qué cambia con el idioma y qué debe seguir compartido

Un sitio de WordPress multilingüe suele tener dos tipos distintos de datos de imagen. Uno es contenido orientado al idioma: el texto alternativo, los pies de foto y cualquier texto descriptivo que vean los usuarios o los motores de búsqueda en el contexto de una página. El otro son los datos compartidos de los medios: el archivo de imagen real, su registro técnico de adjunto y cualquier metadato que describa el archivo y no el idioma de la página.

Esta distinción importa porque traducir datos técnicos compartidos crea duplicación sin mejorar el significado, mientras que no traducir el texto orientado al idioma deja la imagen desconectada del idioma de la página. El límite correcto suele venir determinado por si el campo se lee como contenido o como información del archivo.

Texto alternativo: traduce el significado, no el nombre del archivo

El texto alternativo es el campo de imagen más sensible al idioma en WordPress porque se consume como contenido descriptivo. En una configuración multilingüe, el texto alternativo normalmente debe coincidir con el idioma de la página donde aparece la imagen, porque las tecnologías de asistencia y los sistemas de búsqueda lo interpretan en ese contexto de página.

Eso no significa que cada imagen necesite una descripción conceptual distinta en cada idioma. Si la imagen es puramente decorativa, el texto alternativo debe permanecer vacío o seguir el enfoque de accesibilidad del sitio en lugar de traducirse a una frase sin sentido. Si la imagen transmite información, el texto alternativo traducido debe describir esa información en el idioma de destino, no conservar una redacción en el idioma de origen que el lector no pueda usar.

Un fallo habitual es reutilizar el texto alternativo de un idioma en todas las traducciones porque el elemento multimedia se comparte. Eso simplifica la biblioteca de medios, pero rompe la relación entre la imagen y el contenido traducido de la página. Otro fallo es traducir el texto alternativo de forma mecánica mientras se deja sin cambiar el texto de la página circundante, lo que puede crear desajustes en la terminología o en los nombres de productos.

Pies de foto: tradúcelos cuando formen parte de la narrativa de la página

Los pies de foto se comportan más como el texto del cuerpo que como metadatos del archivo. Si un pie de foto es visible para los lectores, participa en el idioma de la página y normalmente debe traducirse junto con el resto del contenido. Esto es especialmente cierto cuando el pie de foto añade contexto, atribución o interpretación de la que depende el texto circundante.

Como los pies de foto se renderizan en el front end, pueden afectar tanto a la comprensión como al diseño. Un pie de foto traducido puede expandirse o contraerse respecto al idioma de origen, así que quienes implementan deben esperar diferencias en el ajuste de línea y en el espaciado en lugar de asumir una coincidencia visual uno a uno.

Si un pie de foto se usa como fuente de verdad para varios lugares del sitio, las decisiones de traducción se vuelven más importantes. Reutilizar un mismo pie de foto en varios idiomas puede reducir el trabajo editorial, pero también obliga a que cada versión lingüística herede la misma redacción, que puede no coincidir con la terminología local o con los requisitos legales o de atribución.

Metadatos de adjuntos: en su mayoría compartidos, a veces sensibles al idioma

Los metadatos de adjuntos en WordPress suelen describir el archivo en sí y no el idioma de la página. Eso incluye las propiedades técnicas asociadas al medio subido y el registro del adjunto que almacena el archivo en la biblioteca de medios. En la mayoría de los flujos de trabajo multilingües, estos datos deben permanecer compartidos porque el recurso subyacente es el mismo en todos los idiomas.

La excepción práctica es cuando el registro del adjunto contiene texto orientado al usuario que se muestra en la biblioteca de medios o en el front end. En ese caso, el texto se comporta como contenido y puede necesitar traducción. La cuestión técnica clave es si el campo se usa como identificador técnico o como texto editorial visible.

Esta distinción también afecta al mantenimiento. Los datos compartidos de los adjuntos reducen la duplicación y mantienen sincronizadas las actualizaciones, pero pueden dificultar el control editorial específico por idioma si el flujo de trabajo no separa el texto descriptivo de la identidad del archivo. Los registros de adjuntos sensibles al idioma dan a los editores más control, pero también aumentan el riesgo de divergencia entre versiones si la misma imagen se actualiza en un idioma y no se refleja en los demás.

Nombres de archivo y SEO de imágenes: útiles para el descubrimiento, pero no un objetivo de traducción por defecto

Los nombres de archivo de las imágenes forman parte de la capa de archivo, por lo que normalmente se comparten en lugar de traducirse por idioma. Cambiar los nombres de archivo después de subirlos puede crear complejidad operativa porque la ruta del archivo, las referencias en el contenido y cualquier URL derivada pueden necesitar mantenerse alineadas. Por esa razón, es mejor tratar los nombres de archivo como identificadores técnicos y no como contenido específico de un idioma.

Desde la perspectiva del SEO de imágenes, los nombres de archivo siguen siendo importantes porque contribuyen a cómo se nombra y organiza el recurso. Pero en WordPress multilingüe, la señal lingüística más fuerte suele venir del contenido circundante de la página, del texto alternativo traducido, de los pies de foto y de la propia estructura de rutas y canónicas de la página. Un nombre de archivo traducido por sí solo no localiza de forma significativa una imagen si el texto visible a su alrededor sigue en otro idioma.

La compensación es sencilla: traducir los nombres de archivo puede mejorar la legibilidad humana en la biblioteca de medios, pero también puede complicar la reutilización, el almacenamiento en caché y las referencias entre versiones lingüísticas. Mantener los nombres de archivo compartidos preserva la estabilidad y facilita gestionar el recurso como un único archivo usado por varias traducciones.

Medios reutilizables: un archivo, muchos contextos lingüísticos

Los medios reutilizables son donde WordPress multilingüe se vuelve operativamente interesante. Una sola imagen puede aparecer en varias traducciones, pero cada versión lingüística puede necesitar un texto descriptivo distinto, un texto circundante diferente o incluso un recorte distinto si cambia el diseño. El archivo compartido sigue siendo el mismo, mientras que la presentación específica de cada idioma cambia a su alrededor.

Esta separación es útil porque evita duplicar innecesariamente activos binarios. También significa que la biblioteca de medios y la capa de contenido no tienen por qué seguir el mismo modelo de traducción. La imagen puede compartirse globalmente mientras que los metadatos a nivel de página que la describen se localizan por idioma.

El principal fallo es asumir que un medio compartido implica un significado compartido. Una imagen que funciona en una versión lingüística puede necesitar un pie de foto, un texto alternativo o incluso una imagen de sustitución diferente en otro idioma si cambia el contexto cultural o editorial. La reutilización es eficiente, pero no debe imponerse sobre la adecuación lingüística.

Cómo decidir qué traducir

Una regla práctica es traducir todo aquello que un lector interpretaría como parte del mensaje de la página y mantener compartido todo lo que identifique o almacene el archivo en sí. Eso significa que el texto alternativo y los pies de foto suelen traducirse, mientras que el archivo de imagen subyacente y la mayoría de los metadatos de los adjuntos permanecen compartidos.

Cuando un campo queda en el medio, haz dos preguntas: ¿el campo aparece para los usuarios y su significado depende del idioma de la página? Si la respuesta a cualquiera de las dos es sí, la traducción puede ser apropiada. Si el campo solo está ahí para apoyar la gestión de archivos o el renderizado, normalmente debe seguir siendo global.

Esta decisión también afecta al flujo editorial. Los equipos que localizan el texto de las imágenes necesitan un proceso para mantener alineadas las descripciones traducidas con las actualizaciones de la página. Los equipos que mantienen los medios compartidos necesitan una regla clara para saber cuándo una nueva versión lingüística debe reutilizar el recurso existente y cuándo debe recibir una imagen o un pie de foto separados.