Proyecto NAVE

Aquí encontrarás información detallada y referencias sobre cómo colaborar en cualquier de las tareas de NAVE. Siempre que sea posible y procedente, remitiremos a información general disponible en los sitios de documentación de mozilla.org, el MDC, Mozilla Developer Center y wmo, el Wiki de Mozilla.org. Éstas son las habilidades necesarias:

• Castellano: dominio del castellano, sin faltas de ortografía y buena redacción.
• Inglés: buen nivel de inglés leído y escrito, y capacidad para traducir correctamente al castellano.
• Informática básica: capacidad para seguir instrucciones simples como crear y navegar por directorios, ejecutar órdenes en la interfaz en modo consola y tareas similares.
• Informática media: capacidad para seguir instrucciones más complejas, relacionadas con el uso de sistemas de control de versiones, compresión y descompresión de paquetes, posiblemente en un entorno Unix/Linux.
• Tecnologías web básicas: navegación por páginas web, uso de miniLitmus, wikis, Google Docs y otras aplicaciones web de nivel de usuario.
• Tecnologías web medias: conocimientos de HTML/CSS/JS, uso de Litmus y otras aplicaciones web avanzadas.
• Programación media: conocimientos de scripting en BAT (MS DOS), Bash, PHP, Python, para usar, corregir y crear pequeños scripts. Ocasionalmente, conocimientos de la arquitectura de Drupal.

Además, las tareas normalmente pueden incluirse en alguna de las siguientes categorías:

• Traducción de productos
• Traducción de extensiones
• Revisión del resultado de otras tareas, principalmente productos, extensiones y traducciones para la web de Mozilla Europe
• Programación y diseño del sitio web de Proyecto NAVE
• Documentación para el sitio web de Proyecto NAVE
• Traducciones y contenido propio para Mozilla Europe y Mozilla Hispano

Traducción de productos

La traducción de productos de Mozilla en NAVE se lleva a cabo principalmente con una herramienta Java llamada MozillaTranslator. La propia descarga del programa incluye un manual en inglés en formato OpenDoc (OpenOffice.org 2.x) que se encuentra disponible en formato PDF en el wiki de mozilla.org, en el apartado destinado a MozillaTranslator.

Además, hay ciertos contenidos (archivos XHTML, RDF, XML y algún archivo de texto) que no se traducen directamente en MozillaTranslator, sino usando editores que admitan codificación UTF-8. En general, los archivos .DTD y .properties se traducen dentro de MozillaTranslator y el resto, salvo que tengan poco tamaño, se mantienen fuera de éste. Es posible que recurramos a Google Docs para ello (para más detalles sobre esto, revisa el último apartado de este documento, Traducciones y contenido propio para Mozilla Europe y Mozilla Hispano).

Lo que hay que traducir se obtiene a través de un repositorio CVS. El proceso de traducción de productos Mozilla está fuertemente ligado al proceso de desarrollo de código y por ello se usa un mecanismo de colaboración muy similar en la traducción al de la programación en sí. Por ello, se usan repositorios CVS con checkouts, updates, commits y un sistema de gestión de incidencias y bugs.

Los detalles generales de una traducción se pueden averiguar a través del documento del MDC Create a new localization. En cualquier caso, antes de plantearte cualquier tipo de actuación, plantéalo en la lista de correo. La traducción es-ES corresponde a Proyecto NAVE y en mozilla.org no admitirán tu colaboración oficialmente si no está refrendada por algún miembro registrado de nosotros.

Si echas a faltar información en este apartado, pregunta en la lista de correo y nos ayudarás a mejorarlo (si las dudas tienen carácter general no exclusivo de Proyecto NAVE, intentaremos añadir esa información en la documentación general disponible en mozilla.org).

Traducción de extensiones

La traducción de las extensiones depende de cómo estén construidas éstas. En muchos casos la traducción se puede llevar a cabo de un modo similar a la de los productos de Mozilla, usando MozillaTranslator, aunque con ciertas diferencias al generar los .XPIs.

En otros casos, no obstante, no existe separación entre el código y la interfaz de la extensión, lo que hace necesario modificar las cadenas de texto directamente sobre el código fuente y generar un instalador completo traducido de la extensión.

Puede encontrarse documentación sobre las particularidades y precauciones a tener en cuenta durante la traducción de las extensiones respecto de la traducción de los productos Mozilla en el apartado de documentación. Encontrarás particularmente útil la recopilación de documentación para traducir extensiones en NAVE.

Revisiones

Básicamente, esta categoría incluye revisar lo hecho en tareas de cualquier otra categoría. Puede tratarse de revisar la traducción de un producto o una extensión, de revisar la traducción de un documento web de Mozilla Europe (lo que a nuestros efectos incluye documentos de mozilla.com y mozilla.org), o de revisar contenidos o funcionalidades añadidas a la web de Proyecto NAVE.

Revisiones de productos mediante Litmus

Litmus (http://litmus.mozilla.org/) es el sitio oficial de pruebas para los productos Mozilla. Para usarlo, lo primero que tienes que hacer es crearte una cuenta en él, iniciar sesión y escoger la opción Run tests. Entonces escoges el producto, plataforma y versión (incluido el día concreto de descarga o, para ser más exactos, el Build ID), y seleccionas una tanda de pruebas que, en el caso de las pruebas de traducción, será la tanda de pruebas de L10n. Mozilla Links tiene un artículo donde ilustran con imágenes una sesión de uso de Litmus.

La tanda de pruebas puede ser simplemente una serie de tests que debes ejecutar manualmente, cumplimentando el resultado en la página web y, si hay un error claro, creando un bug en BugZilla. En el caso de los navegadores web, algunos tests (normalmente no relacionados con la traducción) los puede realizar directamente la página web, o al menos ayudarte a probarlos (por ejemplo, si hay que verificar que algunos sitios web populares se visualizan correctamente, te puede poner la lista de enlaces que lleve directamente a esos sitios web).

Aunque puede parecer un procedimiento un tanto insulso, las ventajas de Litmus son que:

• Los resultados quedan registrados y son accesibles para todos, de manera que si varias personas quieren probar la misma plataforma del mismo producto en el mismo idioma, pueden ver lo que ha hecho el otro y ahorrarse pasos. Como es lógico, esto ayuda a que sea más fácil, porque cuantos más ayuden, más fácil y corto es para todos.
• Los resultados también son públicos para los desarrolladores y les demuestran que la comunidad local (los usuarios españoles de productos Mozilla, en nuestro caso) se preocupan por ayudar a probar las versiones traducidas.
• Se organizan testdays, días en los que se promueve el que todo el mundo pruebe binarios de un día concreto y tales convocatorias suelen ser justo antes del lanzamiento de las versiones oficiales, usando las llamadas RC (Release Candidates). Eso permite detectar errores antes de que se hagan públicos en la versión oficial. Si los errores detectados son graves, pueden incluso retrasar la publicación de la versión definitiva, corrigiendo tales errores y dando lugar a la publicación de una nueva tanda de RCs.

En lo sucesivo, intentaremos alertaros de los testdays de productos Mozilla, y os rogamos que participéis en ellos. Si os resulta difícil cursar bugs en BugZilla, podéis hacérnoslo saber en la lista de correo, indicándonos el test en el que detectasteis el error y cuál es éste, y nosotros lo intentaremos reproducir, cursando el bug si tenemos éxito.

Es posible que también os pidamos ejecutar los tests de Litmus fuera de los testdays, ya que éstos suelen tener lugar demasiado cerca del lanzamiento final del producto y no podríamos corregir errores en la traducción. En tal caso lo haremos coincidiendo con el lanzamiento de versiones beta. ¿Por qué ejecutar los tests también en los testdays, entonces? Para que si, a pesar de las pruebas, llega a colarse algún error en la traducción, nos aseguremos al menos que la siguiente versión de mantenimiento lo corrige (p.e.: 2.0.0.1 vs. 2.0.0.0).

Por supuesto, el que nosotros os pidamos realizar el juego de tests L10n de un producto en cuestión no quiere decir que no podáis hacer también los test generales de funcionalidad. :-) Además, aunque los testdays son especialmente útiles, podéis llevar a cabo los tests siempre que queráis, como método sistemático de detectar errores e informar de ellos.

Revisiones de productos y extensiones (al margen de Litmus)

En ocasiones, os pediremos que probéis binarios diarios de productos y extensiones al margen de Litmus. Estas pruebas son para evitar que lleguemos a los testdays con errores en la traducción, pero normalmente estarán circunscritas a elementos específicos.

Por ejemplo, os podremos pedir que descarguéis un binario diario de Firefox 3.0 para ver si algunos cambios recientes hechos en la traducción que afectan a la ventana de preferencias pueden haber dado lugar a que algunos elementos de ésta no se vean correctamente en alguno de los sistemas operativos. Pruebas parecidas pueden ser necesarias con las extensiones.

Programación y diseño de la web de Proyecto NAVE

La web de Proyecto NAVE debe ser útil, y debe seguir una filosofía de estándares abiertos. Por ello, debe contener información actualizada, debe ser cómoda de navegar, debe permitir encontrar la información rápidamente, y debe cumplir los estándares del World Wide Web Consortium.

Puedes colaborar en las tareas de esta categoría si sabes HTML/CSS, PHP o Drupal.

Documentación para el sitio web de Proyecto NAVE

Queremos reorientar este aspecto de la web. Entendemos que los traductores no deben tener problema en leer información en inglés, por lo que la documentación sobre procedimientos de la traducción que no sean específicos de Proyecto NAVE deberían incorporarse en MDC, Mozilla Developer Center o wmo, el Wiki de Mozilla.org. Internamente, nos interesa mantener al día la documentación sobre traducción de extensiones, sobre creación manual de instaladores de SeaMonkey, o sobre los procedimientos descritos en este mismo documento de metodología. Ayúdanos a detectar fallos en esta documentación o contribuye a detallarlo donde creas conveniente. Como siempre, avisa primero en la lista de correo.

Si detectamos algo que queremos retocar de la web, puede que hagamos uso de Google Docs para facilitar vuestra colaboración (para más detalles sobre esto, revisa el siguiente apartado de este documento, Traducciones y contenido propio para Mozilla Europe y Mozilla Hispano).

Traducciones y contenido propio para Mozilla Europe y Mozilla Hispano

Mozilla Europe coordina la traducción de diverso contenido web necesario para considerar un producto de Mozilla totalmente traducido a un idioma, además de producir contenido para su propia web que también debe traducirse. En ocasiones, Mozilla Hispano también puede necesitar traducir documentación del inglés al español. Algunos ejemplos de todos estos contenidos son:

• Cierto contenido que tradicionalmente era parte del paquete de idioma de los productos de Mozilla, como las páginas de inicio del correo, se han convertido en páginas en servidores web de Mozilla Corporation.
• Otros contenidos que antes sólo estaban disponibles en inglés, como las políticas de privacidad o las notas de publicación, ahora se traducen a los idiomas en que aparecen las versiones oficiales de los productos Mozilla.
• Mozilla Europe publica notas de prensa en múltiples idiomas. Si los documentos son largos, puede hacer falta ayuda para su traducción.

Para este tipo de traducciones, que suele consistir en archivos HTML, en ocasiones con pequeñas secciones de código PHP que no hay que modificar, se está usando Google Docs. Para ayudar, una vez te hayas creado cuenta en él, sólo tienes que seguir estos pasos:

• Una vez detectes alguna entrada en la lista de tareas que pertenece a esta categoría (MozEurES), indica en la lista que quieres ayudar y el nombre de tu cuenta en Google. Algún encargado te invitará a modificar el documento en Google Docs.
• Entra en Google Docs y mira lo que hay pendiente en ese momento: para controlar lo que falta por hacer usamos etiquetas que asignamos a los documentos. Los documentos que no tienen las etiquetas Completado ni RevisiónPendiente están pendientes de traducir. Los que tienen RevisiónPendiente están pendientes de revisar y los que tienen Completado ya están totalmente traducidos y revisados.
• Escoge el documento en el que quieres colaborar y ponte a traducir lo que falte. Si entráis varios colaboradores a la vez, cada uno verá lo que está haciendo el otro y sólo debéis preocuparos de atacar partes distintas del documento para no interferiros el uno al otro.
• Cuando te canses de traducir, guarda los cambios y cierra el documento. Si lo has terminado de traducir, una vez lo hayas guardado y vuelvas a la lista de documentos, márcalo y asígnale la etiqueta RevisiónPendiente.
• Si ves algún documento etiquetado como RevisiónPendiente, puedes revisarlo y corregir los errores tipográficos que veas. Sin embargo, por el momento preferimos que la etiqueta Completado sea asignada únicamente por Nukeador.