Fase QA

Esta traducción está incompleta. Por favor, ayuda a traducir este artículo del inglés.

Después de todo ese duro esfuerzo de localización estamos seguros que no sólo deseas ver tu trabajo funcionando, sino que quieres asegurarte que sea exacto y fiel. Si no tienes mucha experiencia con código, podrías incluso estar preocupado de que no se haya roto algo (Uuuy!). Ahora te guiaremos a través de la realización de algunas pruebas de control de calidad en tu trabajo para que te asegures de ir por buen camino.

Si estás localizando sitios web de Mozilla, tu trabajo se desplegará poco después de realizarlo sin necesidad de construir un paquete de idioma. Si ese fuera el caso, esta parte de la guía podría no ser completamente aplicable para tí. De cualquier forma, siéntete libre de saltar a la siguiente sección dando click en el vínculo "Siguiente", ubicado en la parte inferior de la página.

Para ver tu trabajo en Firefox (u otra aplicación de Mozilla), necesitarás tener un paquete de idioma construído para instalarlo en tu 'instancia' local.

Construcción manual y automatizada

Con sólo dar click en un botón, algunas herramientas de L10n (como Narro y Koala) automáticamente crearán paquetes de idiomas para tí. Si estás usando una de estas herramientas, no dudes en saltarte a la sección Probar tu L10n y ver tu trabajo. Si no estás usando una de esas herramientas, déjanos guiarte a través de la construcción manual de tu propio paquete de idioma.

Nota: ¿Recuerdas todos esos requisitos previos de las herramientas que te preguntamos, y que eran necesarios para realizar la instalción en la configuración inicial?  Pues bien, los necesitararemos casi todos ellos. Si aún no los has instalado, este es el momento de hacerlo.

Instrucciones preliminares

Vamos a usar los siguientes directorios de archivo para este ejemplo:

    Tu directorio de trabajo (root)/mozilla-aurora (fuente de en-US, tomado de http://hg.mozilla.org/releases/mozilla-aurora)/
    l10n-central (directorio de archivos de L10n, uno por cada L10n; a menudo denominado "l10n base")/
    tu-codigo-de-idioma (un directorio con tus archivos de L10n, en este ejemplo usaremos prueba-x)

    Ejemplo: root/mozilla-aurora y root/l10n-central/prueba-x

Además, necesitarás copiar y traducir el archivo toolkit/defines.inc directamente de en-US, antes de que puedas construir. Esto se debe a un fallo en la lógica de construcción.

Por favor sigue la estructura de arriba de cerca o ajusta los comandos siguientes de acuerdo con tu instalación personalizada.

Para copiar este archivo en el directorio apropiado, haz lo siguiente:

  1. Ve al directorio de trabajo desde tu terminal de linea de comandos (es decir, donde creaste la estructura de carpetas descrita anteriormente).
  2. Ingresa los siguientes comandos:
mkdir -p l10n-central/prueba-x/toolkit/

cp mozilla-aurora/toolkit/locales/en-US/defines.inc l10n-central/prueba-x/toolkit/defines.inc

Tarán! Copiados!

Para finalizar, necesitarás un archivo llamado .mozconfig para proceder con el manual de construcción. Este archivo contiene las instrucciones de construcción necesarias.

Para crear y configurar este archivo, sigue estas insctrucciones:

Hasta antes de la corrección del fallo 1063880 en mozilla-aurora y mozilla-beta, al construir los paquetes de idioma en contra de estos dos árboles, usted debía:

  1. retirar  ac_add_options --disable-compile-environment  de .mozconfig en el paso 3

  2. usar ./mach build config  después del paso 4

  1. Actualiza el código de fuente de Mozilla:

$ cd mozilla-aurora
$ hg pull -u

  1. Inserta el siguiente comando para crear el archivo  .mozconfig : $ nano -w .mozconfig
  2. Inserta las siguientes líneas en tu archivo .mozconfig :
mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/../firefox-build
ac_add_options --disable-compile-environment
ac_add_options --with-l10n-base=../l10n-central # path relative to MOZ_OBJDIR
ac_add_options --enable-application=[browser or mail]

Necesitarás especificar qué aplicación estás localizando en la cuarta línea (por ej. para Firefox sería browser, Thunderbird debería ser mail, etc).

  1. Inserta el siguiente comando para realizar la configuración: $ ./mach configure
  2. Una vez tu línea de comandos finalice devolviendo la salida del 'comando de configuración', ve al directorio recientemente creado: $ cd ../firefox-build/browser/locales

Ahora estás listo para construir! En este punto puedes seleccionar entre dos opciones de construcción:

  • Crear un paquete-de-idioma, que es el que está instalado en la parte superior de tu aplicación de Mozilla.
  • Re-empaquetar la aplicación 'binaria' (también conocido como una L10n 're-empaquetada'),  que te permirá instalar tu aplicación al lado de la instalación de la aplicación de Mozilla existente y usarla por separado.

Visita los enlaces de arriba para aprender cómo hacer estas pruebas de construcción.

Probar tu L10n y observar tu trabajo

Ahora que tienes tu paquete-de-idioma o L10n re-empaquetada, vamos a hablar de cómo ver tu trabajo y probarlo en tu aplicación.

Probar el paquete-de-idioma te pondrá un paso más cerca de tener tu L10n añadida a los lanzamientos oficiales. Sigue los pasos siguientes para probar tu localización

  1. Instala Aurora en tu lenguaje preferido.
  2. Instala el paquete-de-idioma .xpi que acabas de crear (o exportar)
  3. Selecciona tu lenguaje usando el Interruptor de Localización Rápida o la add-ons del Interruptor de Localización, yendo a Herramientas->Lenguaje->Tu código de localización del lenguaje.
  4. Reinicia el navegador y comienza tus pruebas.

En este punto deberías estar en la capacidad de ver todo tu trabajo funcionando. Da click aquí para consultar las guías de cómo realizar pruebas para tu localización.

Don't lose your work!

Your work is SO important! We would really hate to see you lose any of it. After you test your localization, you should send it to a remote repository, which will serve as a backup for your work and will let others follow your progress. We're going to go through the process below.

The official localization teams use repositories at hg.mozilla.org. Before a team becomes official, we like to get the localizers comfortable with the Hg commands that allow for cloning, pulling, committing, and pushing work to an experimental repository.  We use a web service called Bit Bucket to start the learning process.

Note: You must have Mercurial configured before you begin. That step is back on the initial setup page. If you haven't done that yet, don't worry, we'll wait for you!

Pushing to your repository

There are a couple of things you should take note of before you push to your repository:

  • Make sure that your files have been encoded in Unicode without BOM (byte order mark).
  • Remember that here you are pushing an entire directory, not a .zip archive file or an .xpi lang pack.

The instructions below will help you learn how to use your Hg repository.

  1. After your new repository is created by the l10n-drivers, please visit the URL for your repo. We'll use x-testing here for our example. You can do this by entering the following URL into your browser: http://hg.mozilla.org/l10n-central/x-testing
  2. Now, navigate to your locale's directory on your local machine.

If you're using Koala, this should be located at /path/to/your/koala.project/locale/3.6/x-testing, otherwise, it should be located at /path/to/your/working_dir/l10n_base/x-testing.

In this directory, you should have an hg repository. You might have created it yourself by running hg init or hg clone or you might have had it created by Koala when you were setting up a new localization project. Also at this point, you shouldn't have any uncommitted changes (i.e., running the hg status command should show nothing). Let's see what the last revision in this repository is.

  1. Enter the following command: $ hg log -l 1

You should see an output similar to the one below:

changeset:   0:7c543e8f3a6a
tag:         tip
user:        Your Name <email@example.com>
date:        Mon Nov 23 18:08:25 2009 +0100
summary:     Added search bar strings
  1. Now compare the local repository on your machine with the remote Hg repository by entering this command: $ hg outgoing http://hg.mozilla.org/l10n-central/x-testing

The hg outgoing command compares the two repositories and lists all changesets that are present locally, but not in the remote repository. These changesets will need to be "pushed" to the remote repository. You can expect to see output like this:

comparing with http://hg.mozilla.org/l10n-central/x-testing
searching for changes

changeset:   0:7c543e8f3a6a
tag:         tip
user:        Your Name <email@example.com>
date:        Mon Nov 23 18:08:25 2009 +0100
summary:     Added search bar strings
  1. Let's now push this changeset. Enter the following command: hg push http://hg.mozilla.org/l10n-central/x-testing
  2. Mercurial will connect to your repo and ask you to provide your account information (i.e., the username and the password).
real URL is http://hg.mozilla.org/l10n-central/x-testing
pushing to http://hg.mozilla.org/l10n-central/x-testing
searching for changes
http authorization required
realm: hg.mozilla.org HTTP
user: your_id
password: 

After you enter your account information, the changeset will be pushed.

adding changesets
adding manifests
adding file changes
added 1 changesets with 2 changes to 2 files
bb/acl: your_id is allowed. accepted payload.
quota: 979.7 KB in use, 150.0 MB available (0.64% used)

Your changeset has been successfully pushed to your repository!

As you begin to move through your translations, you should commit the changes locally and push your work to this experimental repository. For instance, if you have finished translating all the .dtd and .properties files in your x-testing/browser/chrome/browser/ directory, then you should run these commands:

$ hg status
$ hg commit -m "Translated browser/chrome/browser/"
$ hg outgoing
$ hg push http://hg.mozilla.org/l10n-central/x-testing

Note that due to the distributed nature of Hg, hg commit saves the changes locally (i.e., in your computer's Hg repository). You can see the history of commits with hg log. After doing hg commit, you still need to send the changes to the remote repository. This is where hg push comes in. This sends your commits to the remote repository.

Now you're ready to proceed to the release phase!

 

Etiquetas y colaboradores del documento

 Colaboradores en esta página: diegomez
 Última actualización por: diegomez,