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

Esta guía le acompañará a través de todo el proceso de localización de software, desde el principio hasta el final, con mejores prácticas y ejemplos de código reales.

Su aplicación acaba de lanzarse en Francia. Los registros 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 el texto se ha cortado. Los menús de navegación se dividen en dos líneas. Su interfaz de usuario, cuidadosamente diseñada, parece completamente rota.

Esto es lo que ocurre cuando se salta directamente a la traducción sin localizar su software correctamente. El texto se traduce, pero la aplicación no se construyó para gestionarlo.

Esta guía cubre todo lo que necesita para que la localización de software sea un éxito. 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 contenido dinámico, expansión de texto, formatos específicos de cada región y 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 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 de destino 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 parezca haber sido creado específicamente para ese mercado desde el principio.

He aquí un ejemplo que muestra cómo la misma fecha puede significar dos cosas distintas según la ubicación del usuario:

Este es solo 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 la magnitud del trabajo.

Localización de software frente a traducción e internacionalización

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

El proceso de localización de software

La localización de software no es un paso único que se completa antes del lanzamiento. Es un proceso continuo que se ejecuta en paralelo al desarrollo. He aquí un resumen de cómo se desglosa habitualmente:

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

1. Waterfall (en cascada): La localización comienza una vez finalizado el desarrollo. Termina la construcción y luego entrega todo para traducir en un solo lote. Es fácil de gestionar, pero retrasa el lanzamiento en otros idiomas y hace que los errores sean costosos de corregir en esa etapa.
2. Localización ágil: La localización se ejecuta junto con el desarrollo. En lugar de un gran lote al final, se envían cadenas para traducir durante todo el ciclo de desarrollo. Los tiempos son mejores, pero el proceso sigue siendo manual. Alguien del equipo debe 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 traducir automáticamente. Cuando la traducción está lista, se fusiona de nuevo de forma automática.

Mejores prácticas para la localización de software

Cada proyecto es diferente y sus necesidades de localización dependerán de su tecnología, sus mercados de destino y su equipo. Esta lista cubre los pilares fundamentales para que la localización de software funcione.

Almacene todo el texto traducible en archivos separados

Cuando escribe texto directamente en el código fuente (codifica de forma rígida (hard-code)), 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á enterrado dentro de sus archivos JavaScript, PHP o Ruby, el escaneo no devolverá nada.

Esta es la razón más común por la que fallan 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 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 interfaz, botones y elementos de menú
• Mensajes de error y texto de validación
• Plantillas de correo electrónico y notificaciones
• Textos de ayuda, cuadros de información y marcadores de posición
• Mensajes de éxito y confirmación

El formato de archivo que utilice dependerá de su entorno de trabajo:

He aquí un antes y un después para cada uno de los principales entornos.

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 asignar a sus cadenas claves claras y descriptivas. Una clave llamada checkout.submit_button le indica al traductor exactamente dónde aparece esa cadena y qué hace. Por el contrario, string_147 no le dice nada, lo que provoca errores de traducción. Las claves descriptivas también facilitan que su propio equipo rastree qué cadenas se han externalizado y detecte cualquier falta.

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, es tentador construir la frase uniendo fragmentos de texto en el código. Esto no funciona en otros idiomas.

He aquí el motivo:

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 aparece en una posición diferente de la frase. Sus traductores no pueden reordenar los fragmentos, por lo que la frase acaba siendo gramaticalmente incorrecta.

Los marcadores de posición solucionan esto manteniendo la frase completa. Sus traductores o su herramienta de traducción reciben la frase entera para trabajar, incluyendo una marca que indica dónde va la variable. Pueden colocar esa marca donde la gramática de su idioma lo requiera.

Así es como se ven 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.

Construya su interfaz para gestionar textos más largos

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 su diseño basándose en 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; eso es un incremento del 567 %.

La solución es construir 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 el inglés y traduce después, pasará más tiempo depurando problemas de diseño en cada idioma del que habría pasado integrando la flexibilidad desde el principio.

Escriba textos que sean fáciles de traducir

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

Los problemas más comunes que debe evitar:

Frases 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 errónea significa una traducción incorrecta.

Escriba frases completas con un sujeto y un verbo claros.

Antes: ambiguo

"No items"

Después: significado claro

"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 su idioma original, 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.

Gestione correctamente fechas, números y monedas

Los formatos de fecha y número varían significativamente entre regiones. Escribir estos formatos de forma fija (hard-coding) causa el mismo problema que con el texto: funciona en un mercado y se rompe en otros.

Utilice las utilidades de localización integradas en su entorno de trabajo para formatear estos elementos automáticamente según la región 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 gestiona el formato correctamente para cada región que soporte.

Planifique para la región, no solo para el idioma

El idioma y la región (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 regiones. 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 una región, corre el riesgo de mostrar contenido incorrecto a los usuarios de zonas específicas.

Tome el francés como ejemplo:

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

Ofrezca a los traductores el contexto que necesitan

Si decide trabajar con traductores humanos, tenga en cuenta que trabajan directamente con 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, a qué se refiere o de cuánto espacio dispone 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 uno de estos casos 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 que las herramientas de traducción produzcan resultados significativamente más precisos que cuando trabajan solo con texto.

Configure la detección de idioma

Una vez que sus cadenas están en archivos de recursos y su interfaz es flexible, necesita mostrar a cada usuario el idioma correcto automáticamente. La mayoría de los entornos de trabajo gestionan esto con librerías 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 (fallback). 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.

Para aplicaciones web, también puede permitir que los usuarios cambien el idioma detectado manualmente. Guarde 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 los ajustes 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, copiar las traducciones en sus archivos, descubrir que le faltan 12 cadenas y empezar de nuevo. No es escalable.

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

• Conectarse a su repositorio, detectar cadenas nuevas y modificadas, y mantener las traducciones actualizadas de forma continua.
• Ofrecer a su equipo un lugar centralizado para gestionar todas las traducciones.
• Incluir 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 las primeras 20.000 palabras a 2 idiomas de forma gratuita, y empezar lleva menos de 5 minutos.

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

Pruebe cada versión localizada antes del lanzamiento

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

Diseño: ¿El texto encaja sin cortarse? ¿La navegación sigue funcionando o hay desbordamientos?

Funcionalidad: ¿Los formularios se envían correctamente? ¿Los mensajes de error aparecen en el idioma correcto? ¿La búsqueda gestiona caracteres con acentos como é, ñ y ü?

Formato: ¿Las fechas están en el formato correcto para la región? ¿Los números y las monedas están formateados correctamente? ¿El símbolo de la moneda está en la posición adecuada?

Idiomas de derecha a izquierda: Si soporta árabe o hebreo, pruebe el diseño RTL completo por separado. El soporte RTL afecta a algo más que a la dirección del texto; afecta a todo el diseño de su interfaz.

Integre las pruebas de localización en su proceso de control de calidad desde el principio. Encontrar un flujo de pago roto en alemán a través de las reseñas de los usuarios es significativamente más costoso 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 en su presupuesto no es cuántos idiomas soporta, 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 las pruebas, la gestión del proyecto o las futuras actualizaciones cada vez que su producto cambie.

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 al consumo. Sus primeras 500 palabras de cada mes son gratuitas. Cuanto más traduzca, menor será su tarifa por palabra y, una vez que alcance una tarifa inferior, 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 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 de localización de software mencionadas anteriormente cubren mucho terreno. Algunas, como escribir textos traducibles o planificar para la región, requieren decisiones deliberadas de su equipo. Pero 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.

He aquí cómo poner en marcha 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 destino. Durante la prueba gratuita, puede seleccionar 2 idiomas.

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

Toda la configuración lleva menos de 5 minutos.

Revise 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 gestionar las revisiones en idiomas específicos, puede realizar una revisión de traducción con IA con PTC.

AI Visual QA lleva el proceso estándar de revisión a nivel de cadena un paso más allá, examinando su interfaz de usuario real en cada idioma de destino.

Lo que dejará de hacer:

• Abrir manualmente su producto en cada idioma de destino para comprobar problemas de visualización.
• Coordinar a revisores de control de calidad que hablen los idiomas de destino.
• Descubrir diseños rotos o cadenas faltantes después de un lanzamiento.

Lo que obtendrá a cambio:

• PTC revisa visualmente su interfaz traducida y encuentra problemas que la inspección de cadenas no puede detectar.
• Los problemas encontrados en las traducciones generadas por PTC se corrigen 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 de su panel de control. Dependiendo del tipo de software que esté traduciendo, podrá subir capturas de pantalla de su interfaz 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 cuando su aplicación está en funcionamiento. Corrige automáticamente problemas a nivel de traducción, como frases forzadas, tono incorrecto o texto que no encaja en el contexto. Los problemas a nivel de código, como claves faltantes, cadenas fijas (hardcoded) y errores de formato, se señalan para que su equipo los resuelva en el origen.

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 al día sin necesidad de subir archivos manualmente.

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

Comience a usar PTC gratis durante 30 días

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

WPML es uno de los plugins multilingües más utilizados para WordPress. Mantenerlo traducido a 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 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 solucionaba 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 sobrecarga de coordinación y sin retrasos.

Antes de PTC

Después de PTC

Comience a localizar su software hoy mismo

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

Comience su prueba gratuita