Localización de software

Este servicio es distinto de la localización de sitios web. En un sitio web hay sobre todo textos fluidos y de contexto claro; en el software, en cambio, los textos están dentro de los archivos fuente en forma de fragmentos cortos, dispersos y desligados de su contexto. Palabras sueltas como «Save», «Open» o «None» se traducen sin ver en qué punto de la pantalla van a aparecer. Esa desconexión es la dificultad más determinante de la localización de software.

El texto está separado del código

En un software localizable, todos los textos visibles para el usuario se extraen del código y se reúnen en archivos fuente aparte. El traductor no trabaja con el código, sino con esos archivos. Pero esos archivos contienen elementos especiales: marcadores de posición donde entrarán las variables, formas de plural y marcas de formato. Si se tocan, la aplicación se bloquea. Por eso la localización de software exige saber qué se traduce y qué no se debe tocar.

En una lengua aglutinante como el turco, los sufijos de plural y de caso plantean un problema aparte. Una expresión que en inglés se añade sin más al final de una variable, en turco cambia según el último sonido de la palabra. Por eso los diseños que colocan una variable en mitad de la frase suelen dar un resultado defectuoso; estos puntos deben detectarse durante la localización y comunicarse al desarrollador.

¿Cómo funciona el proceso?

El proceso de localización de software se parece más a una disciplina de ingeniería que a la traducción; en cada paso se vigilan a la vez la corrección lingüística y la técnica. El flujo que sigue parte del hecho de que los textos llegan en fragmentos desligados de su contexto: por eso reunir contexto es un paso tan importante como la traducción misma. Conservar los marcadores de posición y los códigos de formato es una regla que no cambia a lo largo del proceso. La prueba que viene al final de los pasos es el eslabón más determinante del proceso, porque si una traducción es realmente correcta o no solo se sabe cuando se ve dentro de la aplicación.

1. Recepción de los archivos fuente. Se reúnen los archivos de idioma que contienen los textos y, si los hay, las capturas de pantalla o las notas de contexto.
2. Guía de terminología y estilo. Se fijan los términos básicos del producto y se decide con qué equivalente se dará cada concepto cercano, como «delete», «remove» o «cancel».
3. Traducción. Los textos se traducen respetando los marcadores de posición y los límites de caracteres; para los fragmentos de contexto incierto se abre una consulta al desarrollador.
4. Prueba sobre la compilación. La traducción se integra en la aplicación y se ve en las pantallas reales; se corrigen los textos que desbordan, los que caen en el lugar equivocado y los que quedan fuera de contexto.
5. Mantenimiento de versiones. En la versión nueva se marcan los textos que han cambiado y solo se actualizan esos; no se empieza de cero en cada versión.

Formato de entrega

La entrega consiste en los archivos fuente con la traducción ya integrada; el desarrollador puede llevarlos directamente a la compilación. Los marcadores de posición, los códigos de formato y la estructura de los archivos se conservan intactos. Si se ha solicitado la fase de prueba, se informa además de la lista de problemas vistos en pantalla y de las correcciones propuestas. Si también se van a traducir la documentación y los textos de ayuda del producto, se abordan en unidad terminológica con la interfaz.

Puntos de atención propios de este servicio

El mayor riesgo es la falta de contexto. Una palabra traducida sin ver en qué punto de la pantalla va a aparecer puede llevar un significado erróneo: «close» significa a la vez «kapat» y «yakın»; cuál de los dos es solo lo dice el contexto. Por eso las capturas de pantalla y un canal de consultas abierto con el desarrollador son el factor más determinante de la calidad. En un proyecto en el que no se aporta contexto, la tasa de error aumenta de forma inevitable.

El segundo punto es no dar por terminado el trabajo sin verlo en la interfaz real. Una traducción que sobre el papel parece correcta puede no caber en un menú estrecho o leerse mal por culpa de una variable que cae en mitad de una frase. Estos problemas solo se ven probando sobre la compilación. Si junto con su aplicación también se va a localizar el sitio web, los dos trabajos se llevan con unidad terminológica dentro de nuestros servicios de traducción.

Internacionalización y ciclo de pruebas

El éxito de la localización de software depende de un paso anterior a la traducción: la internacionalización. Si la aplicación no se ha construido de forma que pueda soportar distintos idiomas, el resultado saldrá defectuoso por buena que sea la traducción. Que el texto esté separado del código, que los formatos de fecha y de número sean configurables y que la interfaz deje sitio al texto que se alarga son condiciones que deben cumplirse antes de traducir. Si faltan, primero hay que corregir el lado del desarrollo.

El segundo factor determinante es el ciclo de pruebas. La localización no es una entrega en un solo sentido, sino un proceso que se repite: la traducción se integra, se ve en la compilación, se marcan los problemas y se corrigen. A medida que llegan versiones nuevas solo se procesan las cadenas que han cambiado y el mismo ciclo se repite a pequeña escala. Los proyectos que se llevan sin establecer este orden empiezan de nuevo con cada actualización, salen caros y pierden coherencia. Una localización sólida define este ciclo desde el principio como un flujo.

¿Qué determina el precio?

El primer factor que determina el coste es el volumen real del texto que hay que traducir; en los archivos fuente ese volumen suele ser mayor de lo que parece, porque los mensajes de error y los textos de ayuda pasan desapercibidos. El segundo es la situación del contexto: un proyecto en el que se facilitan capturas de pantalla y notas avanza rápido, mientras que uno en el que se trabaja a ciegas se ralentiza. El tercero es el alcance de las pruebas; si se pide una revisión sobre la compilación, eso supone un esfuerzo aparte. No se puede dar un precio fiable sin ver los archivos fuente.

Puede compartir sus archivos fuente y los idiomas de destino a través del formulario de presupuesto. Los niveles de precio los encontrará en la página de precios y los idiomas con los que trabajamos en las páginas de idiomas.

Situaciones habituales

• Lista de textos sin contexto. Una tabla de palabras enviada sin capturas de pantalla; es la situación que más aumenta el riesgo de significado erróneo.
• Deterioro de los marcadores de posición. Tocar por descuido las marcas de variable; provoca el bloqueo de la aplicación, por eso se conservan.
• Texto que desborda. Que el texto alargado en el idioma de destino no quepa en una interfaz estrecha; solo se ve con la prueba sobre la compilación.
• Desorden de versiones. Traducir todo el texto de nuevo en cada actualización; en cambio, solo deberían procesarse las cadenas que han cambiado.

Este contenido ofrece el marco general; los detalles propios de cada trámite pueden variar. Dado que la práctica puede cambiar, tome como referencia la condición vigente en el momento de la solicitud.