Mejores prácticas para la localización de software: 10 pasos con ejemplos

Esta guía le muestra el proceso de localización de software de principio a fin, con mejores prácticas y ejemplos de código reales.

Su aplicación acaba de lanzarse en Francia. Los registros no paran de llegar y, de repente, los tickets de soporte empiezan a inundar su bandeja de entrada. Los usuarios no pueden hacer clic en el botón «Comprar ahora» porque está cortado. Los menús de navegación se rompen en dos líneas. Su interfaz de usuario, cuidadosamente diseñada, parece completamente rota.

Esto es lo que ocurre cuando se pasa directamente a la traducción sin localizar el software adecuadamente. El texto se traduce, pero la aplicación no se creó para procesarlo.

Esta guía cubre todo lo que necesita para hacer bien la localización de software. Aprenderá:

• Qué es la localización de software
• La diferencia entre localización, traducción e internacionalización
• Cómo prepararse para el proceso de localización de software
• Mejores prácticas para el contenido dinámico, la expansión del texto, el formato específico del locale y las pruebas
• El coste de la localización de software
• Cómo configurar un flujo de trabajo de localización que no se rompa en cada lanzamiento

¿Qué es la localización de software?

La localización de software es el proceso de adaptar su software para un mercado específico. Esto va más allá de la traducción del texto. Significa ajustar todo lo que afecta a la forma en que los usuarios del mercado de destino experimentan su software: formatos de fecha y número, moneda, diseño de la interfaz de usuario, imágenes y referencias culturales.

El objetivo es hacer que su software parezca haber sido creado para ese mercado desde el principio.

Aquí tiene un ejemplo que muestra cómo la misma fecha puede significar dos cosas distintas dependiendo de dónde se encuentre su usuario:

Ese es solo un pequeño ejemplo de lo que procesa la localización de software. Multiplíquelo por fechas, monedas, formatos y referencias culturales, y empezará a ver el alcance del trabajo.

Localización de software vs. traducción vs. internacionalización

Muchas personas utilizan estos tres términos indistintamente, pero significan cosas diferentes y ocurren en diferentes etapas del desarrollo.

El proceso de localización de software

La localización de software no es un único paso que se completa antes del lanzamiento. Es un proceso continuo que se ejecuta en paralelo al desarrollo. A continuación, se ofrece un desglose general de cómo funciona normalmente:

La mayoría de los equipos ejecutan el proceso de una de estas tres formas:

1. Cascada (Waterfall) La localización comienza una vez finalizado el desarrollo. Se termina de construir y luego se entrega todo para su traducción en un solo lote. Es fácil de gestionar, pero retrasa el lanzamiento en otros idiomas y hace que los errores sean costosos de solucionar en esa etapa.
2. Localización ágil La localización se ejecuta en paralelo al desarrollo. En lugar de un gran lote al final, se envían las cadenas para su traducción a lo largo del ciclo de desarrollo. Los tiempos son mejores, pero el proceso sigue siendo manual. Alguien de su equipo tiene que exportar las cadenas, gestionar las entregas e importar las traducciones de vuelta.
3. Localización continua La localización está totalmente automatizada. Su repositorio se conecta directamente a su herramienta de traducción, de modo que cuando una cadena cambia, se envía para su traducción automáticamente. Cuando la traducción está lista, se fusiona de nuevo automáticamente.

Mejores prácticas para la localización de software

Cada proyecto es diferente, y sus necesidades de localización dependerán de su stack tecnológico, sus mercados de destino y su equipo. Esta lista cubre el núcleo de lo que hace que la localización de software funcione.

Almacene todo su texto traducible en archivos separados

Cuando introduce texto directamente en su código fuente, las herramientas de traducción no pueden encontrarlo. Estas herramientas funcionan escaneando archivos de recursos como JSON, PO o YAML en busca de cadenas para traducir. Si su texto está oculto dentro de sus archivos JavaScript, PHP o Ruby, el escaneo no devolverá ningún resultado.

Esta es la razón más común por la que fracasan los proyectos de localización. Los equipos solo descubren el problema cuando intentan traducir y se dan cuenta de que primero necesitan refactorizar miles de cadenas.

Por eso es mejor mover todo el texto orientado al usuario a archivos de recursos dedicados desde el principio. Esto incluye todo lo que sus usuarios pueden ver:

• Etiquetas de la interfaz de usuario, botones y elementos de menú
• Mensajes de error y texto de validación
• Plantillas de correo electrónico y notificaciones
• Texto de ayuda, información sobre herramientas y texto de los marcadores de posición
• Mensajes de éxito y confirmación

El formato de archivo que utilice dependerá de su framework:

Aquí tiene un antes y un después para cada uno de los principales frameworks.

React:

Antes

<button>Submit</button>

Después, usando react-i18next

<button>{t('submit_button')}</button>

WordPress:

Antes

echo 'Submit';

Después, WordPress i18n

echo __( 'Submit', 'your-textdomain' );

Ruby on Rails:

Antes

flash[:notice] = "Profile updated successfully"

Después, usando Rails I18n:

flash[:notice] = t('profile.update_success')

También es importante dar a sus cadenas claves claras y descriptivas. Una clave llamada checkout.submit_button indica a un traductor exactamente dónde aparece esta cadena y qué hace. Por otro lado, string_147 no les dice nada, lo que da lugar a traducciones incorrectas. Las claves descriptivas también facilitan a su propio equipo el seguimiento de qué cadenas se han externalizado y la detección de cualquier elemento que falte.

Utilice marcadores de posición para nombres, números y fechas

Cuando su texto incluye datos variables como el nombre de un usuario o un número de pedido, resulta tentador construir la oración uniendo fragmentos de texto en su código. Esto se rompe en otros idiomas.

Este es el motivo:

const message = 'Hello, ' + name + '!';

Este ejemplo divide la oración en tres fragmentos. En inglés, el orden de las palabras funciona. Pero en idiomas como el japonés, el nombre aparece en una posición diferente en la oración. Sus traductores no pueden reordenar los fragmentos, por lo que la oración acaba siendo gramaticalmente incorrecta.

Los marcadores de posición solucionan esto al mantener la oración completa. Sus traductores o su herramienta de traducción obtienen la oración completa para trabajar, incluyendo un marcador que indica dónde va la variable. Pueden colocar ese marcador donde la gramática de su idioma lo requiera.

Este es el aspecto de los marcadores de posición en diferentes formatos de archivo:

JSON:

{ "greeting": "Hello, {name}!" }

YAML:

greeting: "Hello, %{name}!"

PO:

msgid "Hello, %s!"

La sintaxis varía según el formato, pero el principio es el mismo.

Cree su interfaz de usuario para que admita texto más largo

La mayoría de los idiomas son más largos que el inglés. Un botón que encaja perfectamente en su interfaz de usuario en inglés a menudo se cortará en alemán, francés o español. Si ha creado su diseño en torno a anchos fijos, tendrá una interfaz de usuario rota en cada idioma que añada.

Estas son las tasas típicas de expansión del texto con las que trabajará:

Las palabras individuales pueden expandirse mucho más que estos promedios. “FAQ” se convierte en “Preguntas frecuentes” en español; eso supone un aumento del 567 %.

La solución es crear diseños flexibles en lugar de fijos. En lugar de establecer un ancho fijo en un botón, deje que crezca con su contenido:

Antes: el ancho fijo se rompe en idiomas más largos

button { width: 120px; }

Después: crece con el texto traducido

button {
  min-width: 120px;
  width: auto;
  padding: 8px 16px;
}

Piense en esto durante la fase de diseño. Si diseña primero para inglés y traduce después, pasará más tiempo depurando desajustes del diseño en cada idioma del que habría invertido integrando la flexibilidad desde el principio.

Escriba texto que sea fácil de traducir

La forma en que escribe su texto de origen afecta a la calidad de la traducción. El fraseo impreciso, las expresiones idiomáticas y los juegos de palabras ingeniosos a menudo producen traducciones confusas o incorrectas.

Los problemas más comunes que debe evitar:

Oraciones incompletas

Una cadena como “No items” podría significar varias cosas. ¿No hay artículos en el carrito? ¿Una búsqueda no ha devuelto resultados? Su traductor tiene que adivinar, y una suposición incorrecta significa una traducción incorrecta.

Escriba oraciones completas con un sujeto y un verbo claros.

Antes: ambiguo

"No items"

Después: significado claro

"You have no items in your cart."

Expresiones idiomáticas

“This is a piece of cake” tiene sentido para un hablante nativo de inglés. Si se traduce literalmente al alemán, sus usuarios se preguntarán por qué su aplicación está hablando de postres. La mayoría de las expresiones solo funcionan en el idioma dado, por lo que es mejor evitarlas por completo.

Vocabulario complejo

Las palabras sencillas se traducen de forma más fiable. Escriba “remove” en lugar de “eliminate” y “use” en lugar de “utilize”. En caso de duda, elija la palabra más corta y común.

Procese fechas, números y monedas correctamente

Los formatos de fecha y número varían significativamente entre los distintos locales. Incrustar estos formatos en el código causa el mismo problema que incrustar el texto: funciona en un mercado y se rompe en otros.

Utilice las utilidades de localización integradas en su framework para darles formato automáticamente en función del locale del usuario.

JavaScript:

Antes

const price = '$' + amount.toFixed(2);

Después

const price = new Intl.NumberFormat(userLocale, {
  style: 'currency',
  currency: currencyCode
}).format(amount);

Ruby on Rails:

Antes

"$#{price}"

Después

number_to_currency(price, locale: I18n.locale)

De esta forma, el mismo código procesa el formato correctamente para cada locale que usted admita.

Planifique para el locale, no solo para el idioma

El idioma y el locale no son lo mismo. El español es un idioma. El español de México (es-MX), el español de España (es-ES) y el español de Argentina (es-AR) son locales. Las diferencias entre ellos van más allá del vocabulario. Los formatos de fecha, la moneda, las referencias culturales y el tono pueden variar.

Si solo especifica un código de idioma sin un locale, corre el riesgo de mostrar el contenido incorrecto a los usuarios de regiones específicas.

Tomemos el francés como ejemplo:

Cuando configure sus archivos de recursos, utilice códigos de locale completos en lugar de solo códigos de idioma. Esto le da la flexibilidad de ofrecer diferente contenido a diferentes regiones sin tener que reestructurar su configuración más adelante.

Dé a los traductores el contexto que necesitan

Si decide trabajar con traductores humanos, tenga en cuenta que trabajan directamente desde sus archivos de recursos. Sin información adicional, todo lo que ven es la cadena en sí. No tienen forma de saber dónde aparece en la interfaz de usuario, a qué se refiere o en cuánto espacio tiene que encajar la traducción.

Una cadena como “Cancel” podría referirse a cancelar un pedido, una suscripción o el envío de un formulario. Cada una de estas opciones podría traducirse de forma diferente según el idioma.

Añada comentarios a sus archivos de recursos para explicar qué hace cada cadena y dónde aparece:

JSON con comentarios de contexto

{
  // Button in the checkout flow. Cancels the current order. Keep short.
  "checkout.cancel_button": "Cancel",

  // Error message shown when login fails. Followed by a link to reset password.
  "auth.login_error": "Incorrect email or password."
}

Si utiliza una herramienta de traducción, la mayoría de las plataformas le permiten adjuntar capturas de pantalla que muestran dónde aparecen estas cadenas. Esto permite a las herramientas de traducción producir traducciones significativamente más precisas que cuando se trabaja solo con texto.

Configure la detección de idioma

Una vez que sus cadenas estén en archivos de recursos y su interfaz de usuario sea flexible, necesita mostrar a cada usuario el idioma correcto automáticamente. La mayoría de los frameworks procesan esto con bibliotecas i18n integradas.

React con react-i18next:

i18n
  .use(LanguageDetector)
  .use(initReactI18next)
  .init({
    resources,
    fallbackLng: 'en',
    detection: {
      order: ['navigator', 'localStorage']
    }
  });

Ruby on Rails:

before_action :set_locale

def set_locale
  I18n.locale = extract_locale_from_accept_language_header || I18n.default_locale
end

Establezca siempre un idioma de reserva. Cuando falta un archivo de traducción o una cadena aún no se ha traducido, su aplicación muestra la reserva en lugar de una clave rota como auth.login_error.

Para las aplicaciones web, también puede permitir a los usuarios anular el idioma detectado manualmente. Almacene su elección para que persista entre sesiones:

// Save the user's choice
localStorage.setItem('userLanguage', selectedLanguage);

// Check for a saved choice first, then fall back to the browser language
const userLanguage = localStorage.getItem('userLanguage') || navigator.language;

Las aplicaciones móviles generalmente no necesitan un selector de idioma. Los usuarios esperan que las aplicaciones móviles sigan la configuración de su dispositivo.

Elija una herramienta de localización

Un flujo de trabajo de localización manual se parece a esto: exportar cadenas a una hoja de cálculo, enviarla a un traductor, esperar varios días, recibirla de vuelta, copiar las traducciones en sus archivos, descubrir que le faltan 12 cadenas y volver a empezar. No es escalable.

Una herramienta de localización de software gestiona todo el flujo de trabajo por usted. Una buena herramienta le permitirá:

• Conectarse a su repositorio, detectar cadenas nuevas y modificadas, y mantener las traducciones actualizadas de forma continua
• Dar a su equipo un lugar central para gestionar todas las traducciones
• Incluir funciones CAT integradas como memoria de traducción, detección de límite de longitud y gestión terminológica

PTC hace todo esto. Además, la prueba cubre sus primeras 20.000 palabras en 2 idiomas, y empezar lleva menos de 5 minutos.

Descubra cómo PTC procesa la localización de software

Pruebe cada versión localizada antes del lanzamiento

La traducción no es el último paso. Antes de publicar una versión localizada, pruébela de la misma manera que probaría cualquier otro lanzamiento.

Diseño: ¿Encaja el texto sin cortarse? ¿Sigue funcionando la navegación o está viendo un desbordamiento?

Funcionalidad: ¿Se envían los formularios correctamente? ¿Aparecen los mensajes de error en el idioma correcto? ¿La búsqueda admite caracteres acentuados como é, ñ y ü?

Formato: ¿Están las fechas en el formato correcto para el locale? ¿Tienen los números y las monedas el formato correcto? ¿Está el símbolo de la moneda en la posición correcta?

Idiomas de derecha a izquierda: Si admite árabe o hebreo, pruebe el diseño RTL completo por separado. La compatibilidad con RTL afecta a algo más que a la dirección del texto. Afecta a todo el diseño de su interfaz de usuario.

Integre las pruebas de localización en su proceso de QA desde el principio. Encontrar un proceso de pago roto en alemán a través de las reseñas de los usuarios es significativamente más caro que detectarlo antes del lanzamiento.

¿Cuánto cuesta la localización de software?

Una buena localización de software no tiene por qué ser cara. El factor más importante de su presupuesto no es cuántos idiomas admite. Es cómo traduce.

La traducción humana profesional para software suele costar entre 0,10 $ y 0,30 $ por palabra. Para una aplicación de tamaño medio con 15.000 palabras, eso supone entre 1.500 $ y 4.500 $ por idioma, antes de tener en cuenta las pruebas, la gestión de proyectos o las futuras actualizaciones cada vez que cambie su producto.

La traducción con IA con una herramienta como PTC cuesta una fracción de eso:

Después de la prueba, PTC funciona con un modelo de pago al consumo. Sus primeras 500 palabras cada mes son gratuitas. Cuanto más traduzca, menor será su tarifa por palabra y, una vez que alcance una tarifa más baja, la mantendrá durante tres meses incluso si su volumen disminuye.

Para obtener una cifra exacta para su proyecto, utilice la calculadora de costes de PTC o suba su archivo de recursos directamente para ver el coste antes de comprometerse.

Calcule su coste de traducción

Configure su proceso de localización de software en 3 pasos

Las mejores prácticas para la localización de software anteriores cubren mucho terreno. Algunas, como escribir texto traducible o planificar para el locale, requieren decisiones deliberadas por parte de su equipo. Pero una gran parte del trabajo técnico, como detectar cambios en las cadenas, gestionar archivos de traducción, señalar problemas de longitud y mantener las traducciones sincronizadas, puede automatizarse con la herramienta adecuada.

A continuación, le explicamos cómo establecer un proceso de localización funcional con PTC.

Regístrese en PTC

Cree un proyecto en PTC, suba sus archivos de recursos y seleccione sus idiomas de traducción. Durante la prueba, puede seleccionar 2 idiomas.

PTC genera automáticamente una descripción de su aplicación basándose en el archivo subido. Revise la descripción y consérvela o edítela. También puede subir traducciones preexistentes y añadir un glosario de términos que deban traducirse siempre de una forma específica, como nombres de productos o terminología técnica.

Toda la configuración lleva menos de 5 minutos.

Vea y perfeccione las traducciones

Una vez que las traducciones estén listas, en lugar de editar cadenas individuales manualmente o añadir miembros al equipo para que procesen las revisiones en idiomas específicos, puede hacer una revisión de la traducción con IA con PTC.

El AI Visual QA lleva el proceso estándar de revisión cadena por cadena más allá al examinar su interfaz de usuario real en cada idioma de destino.

Lo que deja de hacer:

• Abrir manualmente su producto en cada idioma de destino para comprobar si hay problemas de visualización
• Coordinar revisores de QA que hablen los idiomas de destino
• Descubrir desajustes del diseño o cadenas ausentes después de un lanzamiento

Lo que obtiene en su lugar:

• PTC revisa visualmente su interfaz de usuario traducida y encuentra problemas que la inspección de cadenas no puede detectar
• Los problemas encontrados en las traducciones que generó PTC se solucionan automáticamente
• Cada idioma se revisa antes del lanzamiento, en minutos en lugar de horas

Para empezar, vaya a la pestaña AI Visual QA desde su panel de control. Dependiendo del tipo de software que esté traduciendo, podrá subir capturas de pantalla de su interfaz de usuario o utilizar la extensión de navegador PTC Visual QA para grabar las pantallas para su revisión.

PTC escaneará en busca de problemas que solo aparecen una vez que su aplicación se está ejecutando. Soluciona automáticamente problemas a nivel de traducción, como fraseo extraño, tono incorrecto o texto que no encaja en el contexto. Los problemas a nivel de código, como claves ausentes, cadenas incrustadas en el código y errores de formato, se señalan para que su equipo los resuelva en el código fuente.

Conecte su flujo de trabajo de desarrollo

Cuando se sienta cómodo con el funcionamiento de PTC, actualice a pago al consumo para acceder a las funciones Pro, como conectar PTC a su repositorio de GitHub, GitLab o Bitbucket. Con esta integración, PTC detecta cadenas nuevas y modificadas automáticamente y mantiene sus traducciones actualizadas sin subidas de archivos manuales.

Si desea ir más allá, la API de PTC le permite integrar la traducción directamente en su pipeline de CI/CD, para que las versiones localizadas estén siempre listas para publicarse junto a su idioma de origen.

Empiece a usar PTC durante 30 días

Ejemplo de localización de software: traducción de WPML con PTC

WPML es uno de los plugins multilingües más utilizados para WordPress. Mantenerlo traducido en 23 idiomas no es opcional. Es parte de cada lanzamiento.

Durante años, el equipo lo hizo de la forma tradicional: contratando traductores humanos profesionales, gestionando archivos de glosario y coordinando las actualizaciones en todos los idiomas para cada lanzamiento. Cada vez, tenían que volver a explicar el producto, la terminología y las expectativas desde cero. El coste oscilaba entre 1.000 $ y 8.000 $ por lanzamiento.

Probaron alternativas: crowdsourcing, flujos de trabajo automatizados y modelos híbridos. Nada solucionó el problema.

Desde que cambiaron a PTC, los lanzamientos salen a tiempo. Las traducciones son completas, precisas y coherentes en los 23 idiomas, sin congelación de cadenas, sin esfuerzo de coordinación y sin retrasos.

Antes de PTC

Después de PTC

Empiece a localizar su software hoy mismo

La prueba de PTC cubre sus primeras 20.000 palabras en 2 idiomas. Empezar lleva menos de 5 minutos.

Comience su prueba