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.
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 https://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
yroot/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:
- Ve al directorio de trabajo desde tu terminal de linea de comandos (es decir, donde creaste la estructura de carpetas descrita anteriormente).
- 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:
-
retirar
ac_add_options --disable-compile-environment
de.mozconfig
en el paso 3 -
usar
./mach build config
después del paso 4
- Actualiza el código de fuente de Mozilla:
$ cd mozilla-aurora
$ hg pull -u
- Inserta el siguiente comando para crear el archivo
.mozconfig
:$ nano -w .mozconfig
- 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).
- Inserta el siguiente comando para realizar la configuración:
$ ./mach configure
- 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
- Instala Aurora en tu lenguaje preferido.
- Instala el paquete-de-idioma .xpi que acabas de crear (o exportar)
- 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.
- 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.
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.
- 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:
https://hg.mozilla.org/l10n-central/x-testing
- 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.
- 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 protected]> date: Mon Nov 23 18:08:25 2009 +0100 summary: Added search bar strings
- Now compare the local repository on your machine with the remote Hg repository by entering this command:
$ hg outgoing https://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 https://hg.mozilla.org/l10n-central/x-testing searching for changes changeset: 0:7c543e8f3a6a tag: tip user: Your Name <[email protected]> date: Mon Nov 23 18:08:25 2009 +0100 summary: Added search bar strings
- Let's now push this changeset. Enter the following command:
hg push https://hg.mozilla.org/l10n-central/x-testing
- Mercurial will connect to your repo and ask you to provide your account information (i.e., the username and the password).
real URL is https://hg.mozilla.org/l10n-central/x-testing pushing to https://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 https://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!