Skip to main content

Visit Mozilla.org

Escribir código localizable

De MDC

Tabla de contenidos

[editar] Escribir código localizable

Esta página muestra las mejores prácticas y guías de estilo para trabajar con interfaces de usuario respecto a la configuración regional. Está pensado para desarrolladores de Mozilla y de sus extensiones.

Para más detalles técnicos, por favor, véase Tutorial de XUL:Configuración regional.


[editar] Acerca de los traductores

Un par de apuntes sobre los traductores para desarrolladores que raramente trabajan con ellos.

  • A los traductores les gustan las herramientas, no los editores de texto.
  • Las herramientas de configuración regional están basadas con frecuencia en pares clave/valor.
  • Los traductores no tienen porqué ser expertos en programación o en la construcción de aplicaciones y se centran en hacer sólo su trabajo.

[editar] Guías de estilo

Por tanto, existen un par de guías de estilo que se deberían seguir para facilitar la traducción del código.

Elegir nombres de claves apropiados
Los nombres elegidos para las claves (sin importar de que estén en un DTD o en un fichero de propiedades) deberían ser descriptivos. Si la semántica de una cadena traducible cambia, entonces la clave también debería cambiar. Esto mejorará el nombre de la clave y las herramientas podrán detectar que lo que se ha cambiado es algo más que una simple corrección ortográfica o gramátical.
No asumir el uso de gramática en la cadenas compuestas
Si se dividen frases en varias claves se presupone el uso de una gramática, una estructura de frase y tales cadenas compuestas son con frecuencia muy difíciles de traducir. Cuando se necesite una cadena compuesta, es aconsejable darles a los traductores espacio para moverse. Un buen ejemplo de cadena compuesta es la característica de Firefox para páginas visitadas: el traductor puede (implícitamente) poner el campo de texto como él crea conveniente.
No usar macros de preprocesador
El uso de #if #else #endif o #expand es extremadamente desalentador. Existen unas pocas excepciones para esta regla, pero en general el fichero de configuración regional debería cumplir los estándares y no debería necesitar herramientas de compilación para ser transformado. Si se quiere añadir proceso de compilación a los fichero de configuración regional, habría que asegurarse de pedir feedback de l10n@. En la mayoría de los casos, las instrucciones de proceso también se pueden poner en el código de contenido y referenciar diferentes pares clave/valor en l10n
Utilizar una buena estructura de directorios
Asegúrate de poner los ficheros de configuración regional en el lugar apropiado. La inclusión de nuevos directorios superiores es compromiso entre el dueño del módulo en el repositorio cvsroot y la facilidad de la traducción.
Utilizar una buena estructura de directorios chrome
Para un módulo mod en particular, la ruta jar:ab-CD.jar!/locale/ab-CD/mod/foo.dtd ha sido ampliamente probada y es un buen lugar para referenciar los ficheros como chrome://mod/locale/foo.dtd. Utilizar una estructura de directorios como esta facilita el proceso de traducción sin el código fuente y es especialmente recomendada para desarrolladores de extensiones. JAR Manifests puede hacer esto de forma fácil.

[editar] El impacto l10n

En árboles congelados, existe la regla de no comprobar los cambios del impacto l10n. ¿Pero qué significa esto? El impacto l10n es

  • cualquier cambio en mozilla/@mod@/locales; los traductores los encontrarán si encuentran cambios consultando el resto de ficheros, como haría cualquiera.
  • Cualquier cambio o nueva utilización de cadenas de configuración regional; Lo que sea que dispare un ciclo QA en nuestras más de 40 configuraciones regionales es un impacto l10n.
Obtenido de "http://developer.mozilla.org/es/docs/Escribir_c%C3%B3digo_localizable"