Traducción y localización de software: proceso, costes y qué enviar a su proveedor
La traducción y localización de software sigue ocho pasos: preparar el código para otros idiomas, extraer las cadenas en archivos traducibles, aportar contexto, acordar la terminología, traducir y revisar, probar con pseudolocalización y revisión en contexto, publicar y repetir en cada actualización. El coste depende sobre todo del texto nuevo frente al reutilizado, del número de idiomas y de la frecuencia de lanzamientos. DEMA Solutions localiza software y documentación para empresas tecnológicas europeas.
A quién va dirigida esta guía
Esta guía está pensada para quienes tienen que lanzar un producto en varios idiomas sin frenar el desarrollo: product managers que preparan su primera versión multilingüe, responsables de desarrollo que gestionarán los archivos de cadenas y responsables de localización que han heredado un proceso que funciona casi siempre. También se dirige a fabricantes de maquinaria y equipos cuyos productos ya incluyen software, como un configurador, un portal de clientes o una aplicación complementaria, y que descubren que el software no se traduce como un manual.
Las preguntas son prácticas: qué tiene que ocurrir en el código, qué archivos enviar, cómo probar el resultado y por qué los presupuestos varían tanto. Las secciones siguientes recorren el proceso en el orden en que usted se lo encontrará.
Qué es la localización de software y en qué se diferencian traducción y localización
Localizar un software significa adaptar los textos visibles, los formatos y el comportamiento de un programa para que resulte natural a los usuarios de otro idioma y otro mercado. La traducción es la parte central, pero solo una parte. Un producto localizado también muestra fechas, números, monedas y unidades como las esperan los usuarios locales, gestiona formas de plural que el inglés no tiene, encaja textos más largos en los mismos botones y cuadros de diálogo y usa los mismos términos en la interfaz, el centro de ayuda y la documentación. Por eso la localización en traducción de software va mucho más allá de cambiar palabras.
La diferencia entre traducción y localización importa porque cambia quién participa. Un documento lo pueden traducir solo lingüistas. Un software no: los desarrolladores deciden cómo se almacenan y componen las cadenas, los diseñadores cuánto espacio tiene una etiqueta y el equipo de producto qué mercados salen y cuándo. Si esas decisiones tienen en cuenta otros idiomas, la traducción es rápida y previsible. Si no, los traductores reciben fragmentos sin contexto y los problemas aparecen tarde, en la compilación de lanzamiento, en un idioma que nadie del equipo lee.
Primero, la internacionalización
Antes de la localización está la internacionalización, el trabajo de ingeniería que prepara un producto para cualquier idioma. Es la causa más frecuente de una localización lenta y cara, y depende casi por completo del equipo de desarrollo.
Externalice todas las cadenas visibles. El texto escrito directamente en el código no se puede extraer ni actualizar sin modificar el código. Etiquetas, mensajes, tooltips, plantillas de correo y textos de error deben estar en archivos de recursos, referenciados con claves estables.
No construya frases a trozos. El código que concatena «You have » + count + » new messages» presupone el orden de palabras del inglés. Use frases completas con marcadores de posición con nombre y deje que cada idioma los ordene.
Admita las reglas de plural. El inglés y el español tienen dos formas de plural; muchos idiomas tienen más, con categorías distintas. Los formatos de mensaje que admiten categorías de plural, como la sintaxis ICU, permiten a los traductores aportar todas las formas necesarias.
Deje espacio para la expansión del texto. El texto traducido suele ser más largo que el inglés, y las etiquetas cortas se alargan proporcionalmente más. Los diseños flexibles y los límites de caracteres acordados donde el espacio es realmente fijo evitan la mayoría de los textos cortados.
Use formatos según la configuración regional y Unicode en todas partes. Fechas, números y ordenación deben salir de la configuración regional, y cada capa, de la base de datos a las fuentes, debe admitir los caracteres de los idiomas de destino.
Nada de esto es traducción, pero cada carencia se convierte en un problema de traducción. Un buen proveedor le señalará los problemas de internacionalización que encuentre en sus archivos; lo que no puede hacer es corregirlos en su código.
El proceso de localización de software, paso a paso
Desde fuera, localizar parece «enviar cadenas, recibir cadenas». El proceso de localización que funciona en la práctica tiene más pasos, y la mayoría ocurre antes o después de la traducción.
1. Defina el alcance y los idiomas. Decida qué componentes (interfaz, onboarding, notificaciones, centro de ayuda, documentación) salen en qué idioma y con qué versión.
2. Extraiga las cadenas. Exporte archivos de recursos que el proveedor pueda procesar sin copiar a mano, con claves, estructura y codificación intactas.
3. Pseudolocalice. Pruebe la compilación con texto generado y alargado antes de que empiece la traducción real.
4. Prepare el contexto. Capturas de pantalla, comentarios en las cadenas y límites de caracteres indican al traductor dónde aparece cada cadena.
5. Acuerde terminología y estilo. Se crean o actualizan el glosario y la guía de estilo, aprobados por alguien que conozca el producto en ese mercado.
6. Traduzca y revise. Lingüistas nativos traducen las cadenas nuevas y modificadas, se reutilizan las traducciones aprobadas y un segundo lingüista revisa el resultado.
7. Pruebe en contexto. Las cadenas traducidas se comprueban en las pantallas reales: significado, cortes y coherencia.
8. Publique y mantenga. Cada corrección vuelve a la memoria de traducción y al glosario, para que la siguiente versión parta del texto corregido.
Las secciones siguientes se detienen en los pasos donde fallan la mayoría de los proyectos.
Archivos de cadenas y formatos: qué debe recibir su proveedor
Los formatos de recursos cambian según la plataforma, y cada uno tiene sus riesgos. El proveedor no necesita conocer su sistema de compilación, pero sí recibir archivos que pueda abrir, traducir y devolver con exactamente la misma estructura. Los formatos más habituales son:
- XLIFF, el estándar XML de intercambio para localización, que mantiene juntos el texto de origen, la traducción y las notas;
- JSON, muy extendido en front ends web y móviles, a menudo anidado y sin campo nativo de comentarios, por lo que el contexto debe enviarse aparte;
- RESX para aplicaciones .NET, con un elemento de comentario por cadena;
- archivos PO de gettext, que admiten comentarios para el traductor, contexto del mensaje y formas de plural;
- archivos .strings y .stringsdict para aplicaciones iOS y recursos XML de cadenas para Android, cada uno con su propia sintaxis de plural.
Sea cual sea el formato, ciertos elementos deben volver intactos: claves, marcadores de posición como {name} o %s, etiquetas de marcado, caracteres de escape y la codificación del archivo. Los marcadores pueden moverse dentro de la frase, porque el orden de las palabras cambia, pero nunca deben traducirse, eliminarse ni duplicarse. Los controles automáticos detectan la mayoría de estos errores antes de la entrega, y preguntar a un proveedor cómo detecta un marcador dañado es una prueba rápida de su proceso.
Un hábito ahorra mucho tiempo: envíe solo las cadenas nuevas y modificadas, o indique claramente qué ha cambiado desde la última entrega. Reenviar cada vez los archivos completos sin esa información obliga a alguien a volver a localizar las novedades, y ahí es donde se cuelan cambios involuntarios en cadenas ya aprobadas.
Contexto: capturas, comentarios y límites de caracteres
La mayoría de los errores de localización son errores de contexto, no de idioma. «Open», «Update» o «Save» pueden ser un verbo en un botón o un sustantivo en un menú, y en español se convierten en «Actualizar» en un caso y «Actualización» en el otro. Una cadena como «%d items» puede referirse a productos en un carrito o a entradas en un registro. Sin contexto, incluso un traductor cuidadoso tiene que adivinar.
Tres tipos de contexto marcan la diferencia. Las capturas de pantalla muestran dónde está una cadena y cuánto espacio tiene. Los comentarios en las cadenas explican para qué sirve una clave y qué contendrá cada marcador. Los límites de caracteres para botones, cabeceras de tabla y notificaciones indican al traductor cuándo hace falta una formulación más corta, antes de que un probador encuentre la etiqueta cortada.
No hacen falta los tres en cada cadena. Una nota en las claves ambiguas, capturas actualizadas en cada versión y límites solo donde el espacio es realmente fijo eliminan casi todas las suposiciones, y los equipos que comentan las claves al crearlas apenas reciben consultas de los traductores.
Terminología y estilo: una sola voz en cada idioma
Una interfaz es un vocabulario reducido que se usa miles de veces. Si «workspace» se traduce de tres maneras entre la aplicación, el centro de ayuda y los correos de bienvenida, los usuarios creen que son tres cosas distintas. Un glosario de términos de producto, con la traducción aprobada en cada idioma y una nota sobre los términos que se quedan en inglés, evita esa deriva. Nuestro artículo sobre la gestión terminológica centralizada entre traductores y proveedores explica cómo crear un glosario así y mantenerlo al día.
El estilo importa igual. ¿La interfaz trata al usuario de tú o de usted? ¿Los botones usan infinitivo («Guardar») o imperativo («Guarde»)? ¿Cómo se redactan los mensajes de error? Una breve guía de estilo para la traducción por idioma responde a estas preguntas de una vez, para todos los traductores y revisores. En familias de productos más amplias, un servicio estructurado de gestión terminológica convierte el glosario en una base terminológica mantenida que pueden usar todos los proveedores y equipos internos.
Traducción y revisión
Con los archivos, el contexto y la terminología listos, la traducción es el paso más previsible. Lingüistas nativos con experiencia en convenciones de software traducen las cadenas nuevas y modificadas, las traducciones aprobadas de la memoria se reutilizan allí donde el origen no ha cambiado y un segundo lingüista compara cada traducción con el original en cuanto a significado, terminología, marcadores y longitud.
La traducción automática tiene su sitio, sobre todo en centros de ayuda, bases de conocimiento y actualizaciones de documentación de gran volumen. Funciona mejor cuando trabaja sobre su propio glosario y su memoria aprobada, con un lingüista cualificado que posedita el resultado. Las cadenas de interfaz son cortas, ambiguas y visibles en cada pantalla, así que normalmente necesitan un traductor humano desde el principio. En la página sobre traducción automática con posedición explicamos cómo decidimos qué contenidos son adecuados.
Pseudolocalización y QA lingüístico en contexto
Dos tipos de prueba protegen una versión localizada, y encuentran problemas distintos.
La pseudolocalización se hace antes de traducir y prueba el código, no el idioma. Un script sustituye cada cadena de origen por una versión alargada, con caracteres acentuados y entre marcadores visibles, de modo que «Save changes» puede convertirse en [Šåvé çhåñgéš !!!]. Al recorrer esa compilación se ve enseguida qué texto está escrito en el código (sigue en inglés normal), qué etiquetas se cortan (desaparece el marcador de cierre) y qué caracteres se rompen. Cuesta poco, no necesita traductores y detecta justo los fallos más caros de descubrir en diez idiomas a la vez.
El QA lingüístico en contexto se hace después de traducir, en una compilación o un entorno de staging con las cadenas reales. Un lingüista o un revisor del mercado de destino recorre los principales flujos de usuario y comprueba lo que ninguna revisión sobre archivos puede ver: si una traducción encaja en su contexto, si el texto se corta, si fechas y números aparecen correctamente y si cada término es el mismo en todas las pantallas. Las correcciones entran en la memoria de traducción, no solo en la compilación, para que no reaparezcan en la siguiente versión.
En un primer lanzamiento conviene hacer ambas pruebas en todos los idiomas; en las versiones rutinarias suelen bastar los controles automáticos y la revisión en contexto de las funciones nuevas.
Localización continua para lanzamientos frecuentes
Los productos que salen cada una o dos semanas no pueden localizarse en grandes lotes ocasionales: cuando un lote vuelve, el origen ya ha cambiado. La localización continua sustituye el lote por un flujo constante: en cada versión se recogen y traducen las cadenas nuevas y modificadas mientras el sprint sigue en marcha, de modo que cada idioma sale con el original y no semanas después.
Más que la velocidad, cuenta la disciplina. Las cadenas deben marcarse como estables antes de ir a traducción; si no, el mismo texto se traduce tres veces mientras la redacción se asienta. El contexto debe acompañar cada lote, porque el traductor no ha visto la demo de la función. Las decisiones terminológicas necesitan un responsable que conteste rápido, y la memoria debe actualizarse con cada entrega.
La ventaja es tangible: los lotes pequeños se revisan con más facilidad, los errores se corrigen antes de propagarse y cada versión cuesta solo lo que realmente ha cambiado. Ahí convergen casi todas las buenas prácticas de localización: localizar poco y a menudo, con contexto, sobre una sola memoria y un solo glosario.
Interfaz, ayuda y documentación coherentes
Los usuarios no distinguen entre interfaz y documentación. Si el botón dice una cosa y el artículo de ayuda otra, pierden la confianza en ambos. Sin embargo, estos textos suelen nacer en equipos, formatos y calendarios distintos, a veces con proveedores diferentes.
La solución es tratarlos como un único conjunto de contenidos. El mismo glosario y la misma memoria de traducción deberían servir para la interfaz, el centro de ayuda, las notas de versión, la documentación de API y, en el caso de los fabricantes, el manual de instrucciones. Los manuales y guías de instalación que acompañan a un software siguen la misma lógica que el resto de sus traducciones técnicas: deben reutilizar la terminología de la interfaz, no reinventarla.
Si sus traducciones anteriores están en archivos antiguos y no en una memoria, aún pueden recuperarse. La alineación de memorias de traducción empareja traducciones previas con sus originales, de modo que la redacción aprobada sea reutilizable desde la primera versión con un nuevo proveedor.
Qué determina el coste de la localización de software
La localización de software suele presupuestarse por palabra, pero la tarifa explica menos del coste final de lo que muchos compradores esperan. Estos son los factores que realmente mueven la cifra.
Texto nuevo frente a repetido. Las cadenas ya aprobadas en la memoria, o repetidas en el producto, cuestan mucho menos que el texto nuevo, con las coincidencias parciales a medio camino. En un producto maduro, la mayor parte de cada versión es reutilización; en un primer lanzamiento, casi todo es nuevo.
Aprovechamiento de la memoria. Un proveedor que parte de su memoria existente factura solo lo que es realmente nuevo; uno que no puede usarla lo factura todo de nuevo. Por eso la propiedad de la memoria de traducción importa tanto como la tarifa.
Número de idiomas. El coste crece de forma casi lineal con los idiomas, así que conviene comprobar si cada componente necesita realmente cada idioma.
Frecuencia de lanzamientos y tamaño de los lotes. Cada lote conlleva un esfuerzo fijo de gestión de archivos, controles y gestión de proyecto. Los lotes regulares y planificados son eficientes; las cadenas enviadas de una en una, no.
Contexto, calidad de los archivos y alcance de las pruebas. Los archivos limpios, con comentarios y capturas, se traducen más rápido y con menos consultas. La falta de contexto se paga dos veces, en consultas y después en correcciones tras las pruebas. El QA en contexto y la revisión en el mercado suponen un esfuerzo que debe planificarse, no descubrirse.
Un ejemplo sencillo muestra por qué pesa tanto la reutilización. Supongamos que una versión modifica 2000 palabras de interfaz: 1200 nuevas, 500 coincidencias parciales y 300 que ya están en la memoria. En diez idiomas son 12 000 palabras nuevas que traducir, 5000 que ajustar y 3000 que comprobar, no 20 000 palabras traducidas desde cero. Un proveedor que informa de este reparto en cada entrega hace que el coste de cada versión sea explicable.
Errores habituales y lo que cuestan
Traducir antes de que las cadenas sean estables. El texto que aún se está reescribiendo se traduce, se vuelve a traducir y se cambia otra vez, y cada ronda se paga.
Enviar cadenas sin contexto. Las etiquetas ambiguas se interpretan, las suposiciones parecen plausibles y los errores los encuentran los clientes antes que los probadores.
Dejar que cada proveedor tenga su propia memoria. Cuando cambia de proveedor, o la aplicación y el manual van a proveedores distintos, la redacción aprobada se pierde y la terminología diverge.
Qué enviar a su proveedor y cómo elegirlo
Un briefing completo, a menudo llamado kit de localización, permite al proveedor presupuestar con precisión y empezar sin una ronda de consultas. Para una versión de software debería incluir:
- los archivos de recursos con las cadenas nuevas y modificadas identificadas, más la ayuda o documentación incluida en el alcance;
- los idiomas y configuraciones regionales de destino, y qué componentes necesita cada uno;
- el contexto: capturas o acceso a una compilación de prueba, comentarios en las cadenas y límites de caracteres;
- su glosario, guía de estilo y memoria de traducción existente, si los tiene;
- el calendario de versiones, la frecuencia de los lotes y la persona de contacto para consultas.
Al comparar proveedores, haga preguntas que revelen cómo trabajan. ¿Pueden procesar sus formatos de forma nativa y devolverlos sin claves ni marcadores dañados? ¿Qué controles automáticos se ejecutan antes de la entrega? ¿Revisa cada traducción un segundo lingüista cualificado? ¿Parten de su memoria existente, puede exportarla en cualquier momento y cómo indican qué era nuevo y qué se ha reutilizado? Nuestro artículo sobre el control de calidad de la traducción explica qué pruebas pedir antes de confiar un proyecto a un proveedor.
Cómo trabaja DEMA Solutions en la localización de software
Nuestros servicios de localización de software y traducción tecnológica están pensados para equipos de producto que publican de forma continua. Las cadenas nuevas y modificadas se traducen en cada versión, al ritmo de sus sprints, en lugar de agruparse en grandes proyectos ocasionales. Los archivos JSON, XML y otros archivos de recursos vuelven con su estructura original, sin extracción manual ni claves rotas, y los controles automáticos buscan variables dañadas, cadenas cortadas y errores de formato antes de que lleguen a una compilación de lanzamiento.
Nuestros traductores son lingüistas técnicos nativos que trabajan con terminología de software y desarrollo, y el proceso está certificado según la norma ISO 17100, con un segundo lingüista cualificado que revisa cada traducción, como se describe en nuestra página de calidad de traducción. Sus ingenieros y jefes de producto pueden revisar directamente en el entorno de traducción y no en hojas de cálculo exportadas, de modo que las correcciones llegan de inmediato a la memoria. La memoria y los glosarios siguen siendo suyos, exportables en cualquier momento en formatos portátiles como TMX y TBX, y los informes de reutilización muestran qué parte de cada versión procede de texto ya aprobado. Nuestros equipos en Italia, Serbia y España se ocupan también de la ayuda, la documentación de API, las notas de versión y los manuales, con un equipo propio de maquetación para los formatos de diseño, para que interfaz y documentos compartan la misma terminología.
Dónde encaja TUBE
Para productos con lanzamientos continuos, TUBE es nuestra solución para mantener cada ciclo de localización bajo su control. Su glosario y su memoria de traducción controlan la traducción automática, cada traducción aprobada pasa a una memoria de su propiedad que puede exportar, y los informes de reutilización muestran qué parte de cada actualización procede de texto que ya ha aprobado.
Preguntas frecuentes
Internacionalizar el código, extraer las cadenas, pseudolocalizar, preparar el contexto, acordar terminología y estilo, traducir y revisar, probar la compilación traducida en contexto, y después publicar y llevar las correcciones a la memoria de traducción. Con lanzamientos frecuentes, el ciclo se repite solo con las cadenas nuevas y modificadas.
La internacionalización prepara el producto para cualquier idioma: cadenas externalizadas, gestión de plurales, formatos según la configuración regional y diseños flexibles. La localización lo adapta a un idioma y un mercado concretos, incluidas la traducción y las pruebas. La primera se hace una vez y se mantiene; la segunda se repite en cada idioma y cada versión.
El que su sistema de compilación genere de forma fiable y que mantenga intactos claves, marcadores y contexto. XLIFF es el formato de intercambio más robusto; JSON, RESX, PO y los archivos de cadenas de cada plataforma funcionan bien si los marcadores son coherentes y se aporta contexto.
Sustituye las cadenas de origen por texto alargado y acentuado entre marcadores visibles, de modo que el texto escrito en el código, los cortes y los problemas de codificación aparecen antes de la traducción real. Conviene usarla antes de los primeros idiomas y cada vez que se añaden funciones importantes.
Depende de cuánto texto es realmente nuevo, cuánto puede reutilizarse de una memoria de traducción, del número de idiomas, de la frecuencia de lanzamientos y del alcance de las pruebas. Pida presupuestos que muestren por separado el texto nuevo, las coincidencias parciales y el reutilizado, para comparar proveedores sobre la misma base.
Puede apoyar contenidos amplios y repetitivos como centros de ayuda y documentación, si trabaja sobre un glosario y una memoria aprobados y un lingüista cualificado posedita el resultado. Las cadenas cortas de interfaz son ambiguas y muy visibles, por lo que en general necesitan un traductor humano y una revisión.
Marque las cadenas como estables antes de traducir, envíe solo cadenas nuevas y modificadas con contexto, use una sola memoria y un solo glosario para todos los contenidos y acuerde con su proveedor un plazo fijo por lote.
Planifique su próxima versión multilingüe
Si está preparando su primera versión localizada, o su proceso actual no consigue seguir el ritmo de sus sprints, cuéntenos su producto, sus formatos de archivo y sus idiomas de destino. Revisaremos sus archivos y le propondremos un flujo de localización adaptado a su ciclo de lanzamientos.
¿Cómo podemos ayudarle?
Cuéntenos qué necesita y le responderemos con las soluciones adecuadas.