Escribir código localizable

Escribir código localizable

Esta página explica las buenas prácticas y directrices al tratar con código de interfaces de usuario en relación a la localización. Está dirigido a desarrolladores de Mozilla y de sus extensiones.

Para más detalles técnicos, por favor, revisa el Tutorial de XUL:Localización.

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 traducción están basadas con frecuencia en pares clave/valor.
• Al menos algunos traductores dirigen su talento a la habilidad con los idiomas y no son expertos en programación, ni siquiera en la compilación de aplicaciones.

Directrices

Por tanto, hay algunas directrices que se deberían seguir para facilitar la localización de tu código.

Elegir nombres de claves apropiados

Los nombres elegidos para las claves (sin importar que estén en un DTD o en un fichero properties) deberían ser descriptivos. Piensa en ellos como nombres de variable largos. 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 gramatical.

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 configuración de páginas visitadas en Firefox: 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 está profundamente desaconsejado. Existen unas pocas excepciones a esta regla, pero en general el fichero traducido debería cumplir los estándares y no debería necesitar herramientas de compilación para ser transformado. Si se quiere añadir procesamiento durante la compilación a ficheros de localización, habría que asegurarse de pedir opinión a 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 localización en el lugar apropiado. La inclusión de nuevos directorios superiores es un compromiso entre la propiedad 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 ésta 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.

El impacto l10n

En árboles congelados, existe la regla de no aplicar cambios que supongan impacto l10n. ¿Pero qué significa esto? El impacto l10n es

• cualquier cambio en mozilla/@mod@/locales; los traductores averiguan si hay cambios que deben replicar en su idioma haciendo consultas a bonsai, como haría cualquiera. Ningún cambio significa que el resultado de estas consultas debe estar vacío.

• Cualquier cambio o nueva utilización de cadenas de localización; lo que sea que dispare un ciclo QA en nuestras más de 40 localizaciones es un impacto l10n.