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

Esta guía le acompaña a lo largo de todo el proceso de localización de software, de principio a fin, con buenas prácticas y ejemplos reales de código.

Su aplicación acaba de lanzarse en Francia. Las altas empiezan a llegar y, de repente, los tickets de soporte inundan su bandeja de entrada. Los usuarios no pueden hacer clic en el botón “Comprar ahora” porque se ha cortado. Los menús de navegación se rompen en dos líneas. Su interfaz, diseñada con tanto cuidado, parece completamente rota.

Esto es lo que ocurre cuando se pasa directamente a traducir sin localizar correctamente el software. El texto se traduce, pero la aplicación no se diseñó para gestionarlo.

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 localización de software es el proceso de adaptar su software a un mercado específico. Esto va más allá de traducir texto. Significa ajustar todo lo que afecta a cómo los usuarios del mercado objetivo experimentan su software: formatos de fecha y número, moneda, diseño de la interfaz, imágenes y referencias culturales.

El objetivo es que su software se sienta como si se hubiera creado para ese mercado desde el principio.

Aquí tiene un ejemplo que muestra cómo la misma fecha puede significar dos cosas distintas según dónde se encuentre el usuario:

Ese es un pequeño ejemplo de lo que gestiona 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 usan estos tres términos indistintamente, pero significan cosas diferentes y ocurren en etapas distintas 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 avanza en paralelo al desarrollo. A continuación, se muestra un resumen de cómo suele desglosarse:

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

1. En cascada
   La localización comienza cuando el desarrollo ha finalizado. Primero se termina de construir y luego se entrega todo para traducir en un único lote. Es sencillo de gestionar, pero retrasa el lanzamiento en otros idiomas y hace que los errores sean caros de corregir en esa fase.
2. Localización ágil
   La localización se ejecuta en paralelo al desarrollo. En lugar de un gran lote al final, se envían cadenas a traducir a lo largo del ciclo de desarrollo. El momento es mejor, pero el proceso sigue siendo manual. Alguien del equipo debe exportar 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 cambia una cadena, se envía a traducir automáticamente. Cuando la traducción está lista, se integra de vuelta automáticamente.

Buenas prácticas de localización de software

Cada proyecto es diferente, y sus necesidades de localización dependerán de su stack, sus mercados objetivo y su equipo. Esta lista cubre lo esencial para que la localización de software funcione.

Cuando incrusta texto directamente en el 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 el texto está enterrado dentro de sus archivos JavaScript, PHP o Ruby, el escaneo vuelve vacío.

Este es el motivo más habitual por el que fracasan los proyectos de localización. Los equipos solo descubren el problema cuando intentan traducir y se dan cuenta de que primero deben refactorizar miles de cadenas.

Por eso, lo mejor es mover desde el principio todo el texto visible para el usuario a archivos de recursos dedicados. 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 placeholder
• Mensajes de éxito y confirmación

El formato de archivo que utilice depende de su framework:

Aquí tiene un antes y un después para cada framework principal.

React:

<button>Submit</button>

<button>Submit</button>

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

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

WordPress:

echo 'Submit';

echo 'Submit';

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

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

Ruby on Rails:

flash[:notice] = "Profile updated successfully"

flash[:notice] = "Profile updated successfully"

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

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

También es importante dar a sus cadenas claves claras y descriptivas. Una clave llamada checkout.submit_button le dice a un traductor exactamente dónde aparece esa cadena y qué hace. En cambio, string_147 no le dice nada, lo que conduce a errores de traducción. Las claves descriptivas también facilitan que su propio equipo haga seguimiento de qué cadenas se han externalizado y detecte cualquier cosa que falte.

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

He aquí por qué:

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

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

Este ejemplo divide la frase en tres fragmentos. En inglés, el orden de las palabras funciona. Pero en idiomas como el japonés, el nombre va en una posición distinta dentro de la frase. Sus traductores no pueden reordenar fragmentos, así que la frase acaba siendo gramaticalmente incorrecta.

Los placeholder resuelven esto manteniendo la frase completa. Sus traductores o su herramienta de traducción reciben la frase entera, incluido un marcador que indica dónde va la variable. Pueden colocar ese marcador donde la gramática de su idioma lo requiera.

Así es como se ven los placeholder en distintos formatos de archivo:

JSON:

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

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

YAML:

greeting: "Hello, %{name}!"

greeting: "Hello, %{name}!"

PO:

msgid "Hello, %s!"

msgid "Hello, %s!"

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

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

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

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

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

button { width: 120px; }

button { width: 120px; }

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

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

Piense en esto en la fase de diseño. Si diseña primero para inglés y traduce después, dedicará más tiempo a depurar problemas de diseño en cada idioma que el que habría dedicado a incorporar flexibilidad desde el principio.

La forma en que redacta el texto de origen afecta a la calidad de la traducción. Las formulaciones vagas, los modismos y los juegos de palabras ingeniosos suelen producir traducciones confusas o incorrectas.

Los problemas más habituales que conviene evitar:

Frases incompletas

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

Escriba frases completas con un sujeto y un verbo claros.

"No items"

"No items"

"You have no items in your cart."

"You have no items in your cart."

Modismos

“This is a piece of cake” tiene sentido para un hablante nativo de inglés. Traducido literalmente al alemán, sus usuarios se preguntarán por qué su aplicación habla de postres. La mayoría de las expresiones solo funcionan en el idioma en cuestión, así que lo mejor es 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.

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

Utilice las utilidades de localización integradas de su framework para formatear todo esto automáticamente según la configuración regional del usuario.

JavaScript:

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

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

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

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

Ruby on Rails:

"$#{price}"

"$#{price}"

number_to_currency(price, locale: I18n.locale)

number_to_currency(price, locale: I18n.locale)

De este modo, el mismo código gestiona el formato correctamente para cada configuración regional que admita.

Idioma y configuración regional 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 configuraciones regionales. Las diferencias van más allá del vocabulario. Los formatos de fecha, la moneda, las referencias culturales y el tono también pueden variar.

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

Tome el francés como ejemplo:

Cuando configure sus archivos de idioma, use códigos completos de configuración regional en lugar de solo códigos de idioma. Esto le da flexibilidad para servir contenido diferente a distintas regiones sin tener que reestructurar su configuración más adelante.

Si decide trabajar con traductores humanos, tenga en cuenta que trabajan directamente desde sus archivos de recursos. Sin información adicional, solo ven la cadena en sí. No tienen forma de saber dónde aparece en la interfaz, a qué se refiere o cuánto espacio debe ocupar 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 caso podría traducirse de forma distinta según el idioma.

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

{
  // 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."
}

{
  // 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 permiten adjuntar capturas de pantalla que muestran dónde aparecen estas cadenas. Esto permite que las herramientas de traducción produzcan traducciones significativamente más precisas que cuando trabajan solo con texto.

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

React con react-i18next:

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

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

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 el idioma de reserva en lugar de una clave rota como auth.login_error.

En aplicaciones web, también puede permitir que los usuarios sobrescriban manualmente el idioma detectado. Guarde su elección para que se mantenga 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;

// 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, por lo general, no necesitan un selector de idiomas. Los usuarios esperan que las aplicaciones móviles sigan la configuración del dispositivo.

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 faltaban 12 cadenas y empezar de nuevo. No escala.

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

• Se conecta a su repositorio, detecta cadenas nuevas y modificadas, y mantiene las traducciones actualizadas de forma continua
• Ofrece a su equipo un lugar central para gestionar todas las traducciones
• Incluye funciones CAT integradas como memoria de traducción, detección de límites de longitud y gestión de terminología

PTC hace todo esto. Además, puede traducir gratis las primeras 20.000 palabras a 2 idiomas, y empezar le lleva menos de 5 minutos.

La traducción no es el paso final. Antes de publicar una versión localizada, pruébela igual que probaría cualquier otra versión.

Integre las pruebas de localización en su proceso de QA desde el principio. Encontrar un flujo de pago roto en alemán a través de reseñas de 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 mayor factor de su presupuesto no es cuántos idiomas admite, sino 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 pruebas, gestión del proyecto o futuras actualizaciones cada vez que cambie su producto.

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

Tras la prueba gratuita, PTC funciona con un modelo de pago por uso. Sus primeras 500 palabras cada mes son gratis. Cuanto más traduzca, menor será su tarifa por palabra, y cuando alcance una tarifa más baja, la mantendrá durante tres meses aunque su volumen disminuya.

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

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

Las buenas prácticas de localización de software anteriores cubren mucho terreno. Algunas cosas, como redactar textos traducibles o planificar para la configuración regional, requieren decisiones deliberadas por parte de su equipo. Pero gran parte del trabajo técnico —como detectar cambios en cadenas, gestionar archivos de traducción, señalar problemas de longitud y mantener las traducciones sincronizadas— puede automatizarse con la herramienta adecuada.

Así es como puede poner en marcha un proceso de localización funcional con PTC.

01

Regístrese en PTC

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

Después, añada contexto sobre su aplicación: qué hace y para quién es. Esto es lo que hace que las traducciones de PTC sean precisas y no genéricas. También puede añadir un glosario de términos que siempre deban traducirse de una forma específica, como nombres de producto o terminología técnica.

PTC los traduce automáticamente, aplicando su contexto y glosario a cada cadena. Toda la configuración lleva menos de 5 minutos.

02

Ver y perfeccionar traducciones

Cuando las traducciones estén listas, revíselas desde su panel. Puede editar cadenas individuales manualmente o añadir miembros del equipo para que se encarguen de las revisiones en idiomas concretos.

Si detecta una traducción que podría ser mejor, márquela e indique a PTC cuál es el problema. PTC la retraduce gratis y aplica lo aprendido a futuras traducciones de su proyecto.

PTC también comprueba automáticamente la longitud de la traducción. Las cadenas que podrían ser demasiado largas para su interfaz se resaltan en amarillo. Puede pedir a PTC que las retraduzca para que encajen, o ajustar los límites de longitud para que coincidan con lo que permite su interfaz.

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

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

Durante años, el equipo lo hizo de la forma tradicional: contratando traductores humanos profesionales, gestionando archivos de glosario y coordinando actualizaciones en todos los idiomas para cada versión. 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 versión.

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

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

Antes de PTC

Después de PTC

Empiece a localizar su software hoy

PTC es gratis para sus primeras 20.000 palabras en 2 idiomas. Empezar lleva menos de 5 minutos.

Empiece su prueba gratuita