--- title: Escribir código localizable slug: Escribir_código_localizable tags: - Localización translation_of: Mozilla/Localization/Writing_localizable_code ---

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.

{{ draft }}

Acerca de los traductores

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

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

{{ languages( { "en": "en/Writing_localizable_code", "fr": "fr/\u00c9criture_de_code_localisable" } ) }}