Com fer un lloc web multilingüe amb publicació contínua

La meva experiència

El programari sovint és traduïble, ja que els desenvolupadors i les desenvolupadores són conscients de la utilitat d’aquest esforç.

Amb una mica de sort, s’utilitzarà una plataforma de traducció de qualitat, com Weblate, i de manera fluida, els canvis del programari arribaran sobre la marxa als traductors i les traductores, i les traduccions tornaran al dipòsit.

El programari és la punta de l’iceberg, allò que s’utilitza directament, però sense les coses del voltant per parlar-ne, és difícil comunicar-ho àmpliament si totes les comunicacions són en anglès. Calen explicacions sobre què fa el programari, per a què serveix, com s’utilitza, etc.

Els llocs web, base de la comunicació d’un projecte, sovint són traduïbles. Les piles tecnològiques per crear aquests llocs web estan relativament poc estandarditzades i es veuen afectades per un desig de personalització per part dels creadors i les creadores per diversificar els continguts, la qual cosa és factible mitjançant algunes etiquetes HTML.

Les documentacions són un món a part, on les eines sovint provenen dels ecosistemes de desenvolupament (documentació tècnica) o de col·laboració (wiki); és bastant rar que aquestes eines ofereixin els requisits previs d’internacionalització que permeten la col·laboració. Tanmateix, el problema és molt semblant al d’un lloc web.

Finalment, les comunicacions més directes, que van des dels canvis d’una nova versió fins a les comunicacions a les xarxes socials per promoure les eines, rarament són multilingües.

Per què pocs llocs poden ser traduïbles?

Per a un bon nivell de traducció, calen capacitats d’internacionalització de programari per reduir l’esforç i la complexitat del desenvolupament i un procés fluid on els traductors i les traductores puguin integrar-se.

Requisits previs d’internacionalització d’un lloc web:

1. admetre l’escriptura de dreta a esquerra
2. publicar el contingut en multilingüe sense haver de modificar els enllaços interns
3. permetre canviar d’idioma a qualsevol pàgina
4. tenir en compte la capçalera Accept-Language per dirigir a l’idioma correcte
5. autoritzar qualsevol idioma i tipus d’escriptura al món

Així dit sembla ampli i impressionant, però alguns estàndards com UTF-8, algunes etiquetes HTML i eines pensades per a aquestes necessitats ho fan prou fàcil.

Les eines en què es basen els desenvolupadors han de contenir les funcionalitats per fer-ho fàcilment, això s’anomena internacionalització. Si l’eina no té un exemple multilingüe a la seva documentació o una secció dedicada a la internacionalització, fugiu. Segur que n’hi ha de millors, no hi ha discussió.

Requisits previs de col·laboració: els desenvolupadors han de conèixer les eines que faciliten la vida als traductors i traductores i utilitzar-les fàcilment.

• Un traductor ha de poder traduir sense accedir al més mínim codi font o dipòsit de programari.
• Un traductor ha de poder afegir el seu idioma sense demanar permís.
• Un traductor ha de poder modificar una traducció sense demanar autorització.
• Un traductor ha de poder ser notificat de canvis que impliquin una traducció.
• Les traduccions s’han de desplegar automàticament sense la intervenció d’éssers humans.
• L’equip de desenvolupament ha de ser fàcil de contactar en cas de problema (autonomia != autarquia)

Triar bé la teva eina de generació de llocs estàtics

Aquí només es valoraran les eines que permeten generar llocs a partir de fitxers. Un lloc dinàmic té una complexitat molt particular que no és necessària per a la majoria de projectes de programari lliure. Fins i tot és una complexitat innecessària de la qual es pot prescindir, per estalviar en treballs de manteniment, costos i riscos de seguretat.

Sense necessitat d’experiència en desenvolupament, comparem doncs aquestes tres eines:

• Hugo té una pàgina sobre publicació multilingüe, és completa, dóna exemples, això és important per a aquest projecte ⇒ proveu-la <3
• Jekyll no té una pàgina sobre internacionalització, tret que accepteu utilitzar un connector i n’accepteu les limitacions de compatibilitat o les solucions improvisades ⇒ fugiu!
• Eleventy té una pàgina d’internacionalització de manera que sembla factible, però és molt manual, la qual cosa no inspira confiança ⇒ fugiu!
• Pelican només tracta de la traducció d’un article, no hi ha cap pàgina dedicada a la internacionalització, un embrió de funcionalitat no és suficient ⇒ fugiu!
• Publii no té cap pàgina d’internacionalització ⇒ fugiu!

La reflexió és curta: voleu un lloc estàtic clau en mà que funcioni en diversos idiomes? Utilitzeu Hugo.

Això no és personal contra Pelican i Jekyll, però a més de tenir menys funcionalitats que Hugo, simplement el requisit previ de modificar les capçaleres dels fitxers a traduir és un pas restrictiu en l’automatització. I aquest és l’objectiu: automatitzar a tot arreu demanant el mínim treball possible! Alguns projectes aconsegueixen internacionalitzar correctament llocs web amb aquestes eines, a costa d’un esforç més gran tot i oferir probablement menys funcionalitats (per exemple, els URL estaran en anglès en lloc de ser traduïts).

Un cas d’estudi: aquest bloc

Per fer concretament aquest treball d’automatització amb dades reals, aquí hi ha les meves especificacions:

• No s’ha de fer cap modificació als articles en l’idioma original
• Ús de Weblate com a plataforma de traducció
• Cap configuració a Weblate per afegir un article nou
• Cap configuració a Hugo per afegir un idioma
• Una publicació totalment automatitzada

Els passos fets són senzills.

Trobar una organització del contingut satisfactòria

• content/fr contindrà tot el contingut del lloc
• l10n/ tots els fitxers de traducció
• l10n/config les cadenes a traduir relacionades amb la traducció d’Hugo
• l10n/pot les plantilles de traducció (fitxers POT)
• l10n/po/%lang% les traduccions en cada idioma (fitxers PO)

El convertidor de format po4a convertirà el contingut en plantilles de traducció (fitxers POT).

Un script de Python cridarà polib per identificar els idiomes que tinguin almenys un article traduït almenys un 80% (percentatge de paraules d’origen traduïdes).

Un altre script de Python actualitzarà la configuració d’Hugo utilitzant les petites configuracions a traduir (nom del bloc, descripció del bloc…).

És un arranjament que funciona, però es poden fer diverses coses per simplificar aquestes eines. Utilitzar la configuració de po4a en lloc de cridar les seves subcomandes i eliminar la necessitat d’utilitzar polib per tenir un sol fitxer de Python.

Per què no utilitzar la compatibilitat de Weblate amb Markdown? Weblate és una plataforma de traducció, convertir fitxers és un altre paper. Eines dedicades ho fan millor que Weblate, i separar les responsabilitats redueix la dependència i, per tant, augmenta l’autonomia per desenvolupar la cadena d’automatització. Exemple típic: po4a podria ser substituït per una altra eina.

Resultat i aprenentatge

La nostra comunitat de programari lliure té l’oportunitat de fer llocs multilingües molt fàcilment.

Tanmateix, falta documentació per explicar com acoblar les eines existents per crear una cadena de producció completa.

Aquest article, doncs, pretén omplir aquest buit i fomentar la còpia d’aquest mecanisme per a projectes interessats.

Segurament es milloraran i simplificaran les eines, i s’emmagatzemaran en un petit projecte dedicat que expliqui com funciona per maximitzar-ne la reutilització. Avui en dia, podeu buscar al dipòsit de git del lloc languages-in-floss per trobar els pocs scripts.