Cómo hacer un website multilingüe con publicación continua

Mi experiencia

Los softwares son a menudo traduisibles, porque los desarrolladores y desarrolladoras tienen conciencia de la utilidad de este esfuerzo.

Con una poca suerte, una plataforma de traducción de calidad, tal que Weblate estará utilizada, y de modo fluido, los cambios del software llegarán al hilo del agua a los traductores y traductoras, y las traducciones volverán en la imposición.

El software, es la parte emergida del iceberg, este que se utiliza directamente, pero sin las cosas que son alrededor para hablar, es difícil de comunicar ampliamente sobre éste si el conjunto de las comunicaciones son en ingleses. Falla explicaciones sobre lo que hace el software, para qué sirve, cómo utilizarlo, etc.

Los sitios web, base de la comunicación de un proyecto, suelen ser fácilmente traducibles. Las tecnologías utilizadas para crearlos no están estandarizadas y se ven influenciadas por el deseo de los creadores de personalizar el contenido para diversificarlo, algo que se logra con unas pocas etiquetas HTML.

Las documentaciones son un mundo aparte entero, cuyas herramientas provienen a menudo ecosistemas de desarrollos (documentación técnica) o de colaboración (wiki), es más bien escaso que estas herramientas ofrecen las prérequis de internacionalización que permite la colaboración. Sin embargo, el problema es muy similar a aquel para un website internet.

Finalmente, las comunicaciones más directas, disposición de los cambios de una nueva versión a las comunicaciones sobre las coberturas sociales para promover las herramientas, son raramente multilingües.

Porqué poco websites pueden- traduisibles ?

Para un buen nivel de traducción, falla capacidades de internacionalización de los softwares que permiten reducir el esfuerzo y la complejidad desarrolladora y un proceso fluido en el cual los traductores y traductoras pueden insertarse.

Prérequis de internacionalización de un website internet :

1. tomar carga la escritura derechista a izquierda
2. publicar el contenido en multilingüe sin tener necesidad de modificar los vínculos internos
3. permitir cambiar de lengua sobre cualquier página
4. tomar cuenta la #encabezamiento Accept-Language para dirigir sobre la buena lengua
5. autorizar cualquier lengua y tipo de escritura al mundo

Dicho así, suena complejo e impresionante, pero unos pocos estándares como UTF-8, algunas etiquetas HTML y herramientas diseñadas para satisfacer estas necesidades lo hacen bastante sencillo.

Las herramientas que utilizan los desarrolladores deben incluir funciones que faciliten este proceso; a esto se le llama internacionalización. Si una herramienta no incluye un ejemplo multilingüe en su documentación ni una sección dedicada a la internacionalización, mejor descártala. Seguro que hay una opción mejor; no cabe duda.

Requisito previo para la colaboración: los desarrolladores deben conocer y saber utilizar las herramientas que facilitan el trabajo de los traductores.

• Un traductor debe ser capaz de traducir sin acceder a ningún código fuente ni repositorio de software.
• Un traductor debería poder añadir su propio idioma sin necesidad de pedir permiso.
• Un traductor debería poder modificar una traducción sin pedir permiso.
• Un traductor debe poder ser notificado de los cambios relacionados con una traducción.
• Las traducciones deben implementarse automáticamente sin la intervención humana.
• El equipo de desarrollo debe ser fácilmente contactable en caso de problemas (autonomía ≠ autosuficiencia)

Elegir la herramienta adecuada para la generación de sitios estáticos

Aquí solo se considerarán las herramientas que generan sitios web a partir de archivos. Un sitio web dinámico implica una complejidad muy específica e innecesaria para la mayoría de los proyectos de software libre. De hecho, se puede eliminar para ahorrar en mantenimiento, costes y riesgos de seguridad.

Sin necesidad de tener conocimientos de desarrollo, comparemos estas tres herramientas:

• Hugo tiene una página sobre publicación multilingüe, es muy completa y ofrece ejemplos, lo cual es importante para este proyecto ⇒ ¡Pruébala! <3
• Jekyll no tiene una página de internacionalización, a menos que aceptes usar un complemento y aceptes sus limitaciones de compatibilidad/solución alternativa ⇒ ¡huye!
• Eleventy tiene una página de internacionalización, así que parece factible, pero es muy manual, no inspira confianza ⇒ ¡huye!
• Pelican solo gestiona la traducción de un artículo, no hay una página dedicada a la internacionalización, una función rudimentaria es insuficiente ⇒ ¡huye!
• Publii no tiene una página de internacionalización ⇒ ¡huye!

La idea es sencilla: ¿quieres un sitio web estático listo para usar que funcione en varios idiomas? Usa Hugo.

Esto no es una crítica personal a Pelican y Jekyll, pero además de tener menos funciones que Hugo y requerir simplemente la modificación de los encabezados de los archivos que se van a traducir, supone un paso engorroso en el proceso de automatización. Y ese es precisamente el objetivo: ¡automatizarlo todo con el mínimo esfuerzo posible! Algunos proyectos consiguen internacionalizar sitios web con éxito utilizando estas herramientas, pero a costa de un mayor esfuerzo y probablemente con menos funciones (p.e., las URL estarán en inglés en lugar de traducidas).

Un estudio de caso: este blog

Para llevar a cabo este trabajo de automatización con datos reales, estas son mis especificaciones:

• No se deben realizar cambios en los artículos en el idioma original
• Utilizar Weblate como plataforma de traducción
• No se requiere ninguna configuración en Weblate para agregar un nuevo artículo
• No hay ninguna configuración en Hugo para agregar un idioma
• Un proceso de publicación totalmente automatizado

Los pasos a seguir son sencillos.

Cómo organizar el contenido adecuadamente

• content/fr contendrá todo el contenido del sitio.
• l10n/ contendrá todos los archivos de traducción.
• l10n/config contendrá las cadenas de texto que se traducirán para la traducción de Hugo.
• Plantillas de traducción l10n/pot (archivos POT)
• l10n/po/%lang% las traducciones en cada idioma (archivos PO)

El convertidor de formato po4a convertirá el contenido en plantillas de traducción (archivos POT).

Un script de Python llamará a polib para identificar idiomas con al menos un artículo traducido al menos en un 80% (porcentaje de palabras de origen traducidas).

Otro script de Python actualizará la configuración de Hugo utilizando las pocas configuraciones que se deben traducir (nombre del blog, descripción del blog…).

Es una solución alternativa que funciona; se pueden hacer varias cosas para simplificar esta herramienta. Use la configuración po4a en lugar de invocar a sus sub‐comandos y elimine la necesidad de usar polib para tener un solo archivo Python.

¿Por qué no aprovechar la compatibilidad con Markdown de Weblate? Weblate es una plataforma de traducción; la conversión de archivos es otra función. Las herramientas especializadas lo hacen mejor que Weblate, y al separar las responsabilidades se reduce la dependencia y, por lo tanto, aumenta la autonomía para escalar el proceso de automatización. Un ejemplo típico: po4a podría reemplazarse por otra herramienta.

Resultado y lección

Nuestra comunidad de software libre tiene la capacidad de crear fácilmente sitios web multilingües.

Sin embargo, existe una falta de documentación que explique cómo ensamblar las herramientas existentes para crear una línea de producción completa.

Por lo tanto, este artículo pretende llenar este vacío y fomentar la copia de este mecanismo para proyectos interesados.

Es probable que las herramientas se mejoren y simplifiquen, y se almacenen en un pequeño proyecto dedicado que explique su funcionamiento para maximizar su reutilización. Actualmente, puedes buscar los scripts en el repositorio Git del sitio web languages-in-floss.