Los archivos de localización son archivos de texto que se pueden abrir y editar en un editor de texto como Notepad o TextEdit o en una de las numerosas herramientas de edición de texto mejoradas utilizadas por los programadores. Estos archivos generalmente siguen el principio de clave-valor. Esto significa que contienen una lista de fragmentos de texto (cadenas) que están asociados con identificadores únicos (claves). Cada cadena es así un valor de una clave (Este simple ejemplo es el formato de los archivos de localización utilizados en la programación en Java.):
-
key1 = value1
-
key2 = value2
-
...
-
keyN = valueN
Creación de archivos de localización
Los archivos de localización son archivos de texto plano con una estructura simple. Pueden ser creados manualmente, pero generalmente son generados automáticamente por utilidades de internacionalización o scripts que están disponibles para diferentes entornos de desarrollo. La creación automática de archivos de localización asegura que las estructuras de los archivos sean válidas.
Para crear un archivo de localización, todos los fragmentos de texto mostrables son reemplazados por identificadores únicos en los archivos de código. Las cadenas de texto son luego añadidas al archivo de localización con sus identificadores.
Uso de archivos de localización
En lugar de las cadenas de texto reales, el código ahora contiene solo claves. Cuando el software genera una vista para el usuario, estas claves son utilizadas para buscar las cadenas asociadas en el archivo de localización.
Si una aplicación está configurada para ser utilizada en inglés y español, todo el texto en inglés puede ser mantenido en un archivo llamado English.txt y es la ubicación de texto predeterminada. Si un usuario no selecciona un idioma, todo el texto será extraído de este archivo para generar cualquier visualización. Si el usuario selecciona español, el software es redirigido a Spanish.txt. Se pueden utilizar muchos idiomas con un sistema como este.
La ventaja es que la elección del idioma para la visualización no afecta al código. Si el software necesita mostrar un botón de inicio de sesión, puede requerir la cadena asociada con la clave login_button y solo necesita saber en qué archivo buscar para recuperar la cadena apropiada para el idioma dado.
Gestión de cadenas
Como plataforma de traducción basada en claves, Phrase admite muchos tipos diferentes de archivos de recursos. Después de que los archivos se suben, se extraen las claves y sus valores de cadena asociados. Las claves y las cadenas se presentan al traductor en un formato estandarizado. Los traductores se centran en su tarea sin tener que preocuparse por el formato exacto del archivo de localización. Pueden inspeccionar las claves, porque la clave en sí puede proporcionar un contexto crucial y guiarlos hacia las elecciones de palabras correctas.
Cuando todas las cadenas están traducidas, los archivos se descargan. En el proceso, se crean los formatos de archivo de localización necesarios que coinciden con el archivo fuente original.
Formatos de archivos de recursos
Se admiten cuatro tipos amplios de recursos, todos esencialmente basados en texto y que se pueden abrir e inspeccionar en un editor de texto.
Hojas de cálculo
.XLSX y .CSV son formatos admitidos. Estos formatos son equivalentes para fines de localización y contienen filas de pares clave-valor. Las claves están en una fila, mientras que los valores correspondientes están en una fila adyacente. Qué columna exacta se utiliza para qué propósito depende de la aplicación, y un localizador necesita configurar Phrase para interpretar las columnas correctamente. Los archivos .CSV de ZenDesk tienen una estructura fija, por lo que este tipo de archivo no requiere ajustes adicionales:
"Título","Idioma predeterminado","Texto predeterminado","Texto en inglés","Estado de variante" "simple_key","German","Einfacher Schlüssel.","Simple key.","Current"
XML
XML es un formato que ofrece metainformación en forma de <tags>. La estructura de etiquetas se utiliza para determinar dónde están las claves y sus valores correspondientes, como se muestra aquí en un archivo XML de Android:
<string name="simple_key">Solo una clave con un mensaje.</string>
Dos formatos de traducción XML estándar son .TMX y .XLIFF. Estos no solo contienen claves y valores en un idioma, sino que también asocian pares de valores de un idioma fuente con valores correspondientes de un idioma meta. Tales archivos son típicamente bilingües, como muestra esta unidad de traducción en un archivo Symfony Xliff:
<trans-unit id="simple_key" resname="simple_key"> <source xml:lang="de-DE">Solo una clave simple con un mensaje simple.</source <target xml:lang="en-GB">Solo una clave simple con un mensaje simple.</target> </trans-unit>
Los programas QT utilizan archivos de recursos con una estructura muy similar a estos formatos estandarizados, pero por razones históricas tienen un diseño diferente.
Listas de clave-valor simples
Hay archivos de recursos que contienen solo listados simples de claves y valores, como muestra este fragmento de un YAML de Ruby on Rails:
simple_key: Solo una clave simple con un mensaje simple.
Muchos lenguajes de programación o plataformas diferentes utilizan tales formatos con ligeras diferencias de diseño.
Dado que estos son archivos monolingües, un programa de localización necesita mantener versiones paralelas de tales archivos: una para el idioma fuente y otras para los idiomas meta.
Gettext produce archivos de clave-valor que contienen información adicional, como comentarios descriptivos o variantes plurales:
# ¡Esta es la increíble descripción para esta clave! msgid "key_with_description" msgid_plural "" msgstr[0] "¡Échale un vistazo!" ¡Esta clave tiene una descripción! (Al menos en algunos formatos)" msgstr[1] "¡Échale un vistazo! ¡Esta clave tiene %s descripciones! (Al menos en algunos formatos)"
Existen formatos competidores con funcionalidades y diseños similares que varían en formas relativamente menores.
Arreglos asociativos
Mientras que otros formatos requieren código personalizado (analizadores) para leerlos, algunos formatos son más fáciles para desarrolladores y localizadores. Los formatos basados en .JSON (JavaScript) y arreglos .PHP pueden ser leídos y mapeados directamente en estructuras de código comunes (arreglos) que son fáciles de manipular. Los arreglos pueden ser complejos y diferentes aplicaciones generan estructuras de arreglos personalizadas.
Por ejemplo, go-i18n JSON se refiere a claves como id:
{
"id": "simple_key",
"translation": "clave simple, mensaje simple, tan simple."
},
Angular utiliza las claves mismas como claves en sus arreglos:
"simple_key": "Soy una clave simple con un mensaje simple.".
Dado que existen estas diferencias menores pero cruciales, se admiten estructuras de arreglos .JSON y .PHP ampliamente utilizadas.