Coordinación mediante el robot de traducción

De forma experimental, y desde febrero de 2004 un robot atiende a los correos enviados a la lista de traducción para ayudar a coordinar los mensajes recibidos de los distintos traductores. También existe un robot general disponible en https://l10n.debian.org/coordination/spanish/ que da servicio a todas las listas de traducción en Debian incluyendo la española.

El robot supervisa los correos enviados y gestiona el siguiente proceso (que es el que se sigue para las traducciones):

El robot permite supervisar en qué estado están las traducciones publicando la lista de traducciones y su estado. Esta información se puede consultar en:

Para que el robot sea capaz de distinguir los correos de este tipo de otras discusiones en la lista se utilizan asuntos concretos con un formato específico.

En resumen, como nos cuenta Ricardo, la idea es la siguiente: Tomando uno al azar, por ejemplo, hace unos días, Javi Castelo envió un mensaje diciendo:

Subject: Me hago cargo de la traducción po-debconf de exim4

En lugar de eso, si hubiera estado el servicio en marcha, habría enviado uno indicando:

Subject: [ITT] po-debconf://exim4

El robot, al reconocer el formato del asunto del mensaje, lo procesa, y capta los datos adecuados (es un ITT, de un po-debconf, del paquete exim4, quién manda el mensaje, y la fecha), los almacena en la BD, y eso aparece en la página web, adscrito al equipo correspondiente ([es], en nuestro caso). El cuerpo principal del mensaje no se procesa, sólo el asunto, así que ahí se puede comentar lo que se quiera. Esta regla vale incluso para RFR, RFR2 y LCFC, ya que el bot sólo procesa los adjuntos, y descarta las partes del mensaje que no estén asociadas a un nombre de fichero.

Días (u horas) después, Javi quiere enviar lo que tiene hecho, para revisión pública:

Subject: [RFR] po-debconf://exim4

Y adjunto, envía el fichero correspondiente (es.po, sin comprimir, que el robot todavía no es capaz de trabajar con ellos). El robot procesa la petición, y se refleja el cambio de estado en la web, aparte de ponerse un enlace al documento. Cuando crea que está preparado para enviarlo, Javi envía un LCFC (misma sintaxis que para RFR), y a los pocos días (pongamos, 3), si nadie dice nada al respecto, Javi manda el documento a quien corresponda, haciendo uso del BTS, y para que quede constancia:

Subject: [BTS#123456] po-debconf://exim4

Tras lo cual, una tarea periódica en el servidor del robot revisará si ese bug ha sido cerrado, para marcarlo como DONE.

Si quieres cerrar manualmente una entrada del robot (independientemente de su estado) sólo tienes que enviar un correo como éste: Subject: [DONE] po-debconf://exim4

En resumen, lo que hay que hacer es:

Pendiente

Las siguientes tareas aún no están implementadas en el robot:

Pseudo-urls

Los pseudo-urls son el texto que se incluye en el asunto del mensaje para que el robot pueda discriminarlo del resto del tráfico en la lista. Tienen el siguiente formato:

[(ITT|RFR|RFR2|LCFC|BTS#<bugnr>)] (po-debconf|po|debian-installer|man|wml)://<name>

El estado (entre corchetes) puede ser uno de los siguientes:

ITT (Intent To Translate, Intención de traducción)

Se envía para indicar que se va a trabajar en una traducción, evitando la duplicación de esfuerzos.

RFR (Request For Review, Solicitud de revisión)

La traducción se ha terminado y, adjunto al correo, se envíe para que otras personas puedan revisarla y detectar errores. Le sigue en algunos casos un RFR2 si se realizan cambios sustanciales. Por favor, responda al mensaje si ha revisado la traducción aunque no haya encontrado errores en ésta.

ITR (Intent To Review, Intención de revisión)

Se envía para evitar que se envíen LCFC cuando hay revisiones pendientes y se utiliza principalmente cuando la revisión va a durar algunos días (porque la traducción es muy grande o no hay tiempo hasta el fin de semana, etc.). El correo debería indicar cuándo se espera que finalize la revisión.

LCFC (Last Chance For Comments, última oportunidad para enviar comentarios)

Indica que la traducción se ha terminado, se han incorporado los cambios del proceso de revisión y se enviará en breve al lugar apropiado. Se pueden enviar cuando no hay ITR, la discusión relacionada con el RFR anterior ha terminado y han pasado al menos tres días desde el RFR. Observe que no se debería enviar a menos que se haya producido al menos una revisión

BTS (Bug Tracking System, Sistema de seguimiento de erratas)

Indica que se ha registrado una errata con respecto a la traducción en el BTS. Cada día el robot comprobará si el informe de error sigue o no abierto.

DONE (Hecho)

Indica que la traducción ya se ha hecho, o bien se ha arreglado la errata enviada al BTS o bien la traducción ya no aplica (el paquete se ha borrado, se ha abandonado el trabajo, etc.).

El tipo puede ser po-debconf (para plantillas de debconf), debian-installer (para partes del instalador), po (para ficheros gettext), man (para páginas de manual) o wml (para ficheros del servidor de web). La estructura del nombre depende del tipo elegido. Éste es sólo un identificador pero se recomienda seguir las siguientes reglas:

Si envía un LCFC,RFR ó RFR2 debería adjuntar el fichero que desea revisar. El fichero debe tener la extensión correcta para el tipo definido. Para po, po-debconf y debian-installer será un fichero po, para el tipo wml un fichero wml y aún no está definido para el tipo man. Este fichero será publicado en la lista de estado en el servidor web.

El estado BTS es un tanto especial dado que el robot lo utilizará para seguir su estado si la traducción ha sido enviada al BTS. Se comprobará cada día si existen informes de erratas abiertos o si han sido cerrados. Por ejemplo: [BTS#1234] po-debconf://cupsys