i18n vs l10n: ¿Cuál es la diferencia?

Al igual que el famoso menú *secreto* de In-N-Out Burger, cada nicho de la industria tiene un lenguaje secreto que, una vez que lo dominas, te hace sentir parte de un grupo selecto. El sector de la traducción y la localización no es diferente. Como siempre nos sentimos un poco inferiores en comparación con nuestros amigos matemáticos, nuestra industria ha decidido intercalar números en medio de nuestras palabras clave: i18n y l10n.

Suena técnico e intimidante, ¿verdad?

Resulta que es simplemente una forma abreviada de referirse a la internacionalización y la localización .

La internacionalización , o i18n (que se pronuncia “ai-dieciocho-en”), se refiere al trabajo de ingeniería que prepara el software para ejecutarse en cualquier idioma. Esto se logra extrayendo cadenas de texto del código, gestionando la codificación de caracteres y creando formatos flexibles para fechas, monedas y unidades. El paso i18n se refiere al trabajo técnico interno que se realiza como preparación para la localización (l10n), la cual se lleva a cabo para cada idioma y mercado.

La mayoría de las páginas explicativas que veo resultan un poco confusas porque tratan los niveles i18n y l10n como dos variantes de la misma tarea, y luego dedican el resto del artículo a hablar sobre bibliotecas de código. No son la misma tarea. La internacionalización es algo que tu equipo de ingeniería hace, ¡con suerte solo una vez! Por otro lado, la localización es lo que le sucede a tu sitio web cada vez que agregas un mercado, y es la parte que determina si un visitante multilingüe se siente bienvenido cuando lo visita o si siente que ha entrado en el valle inquietante, es decir, que algo no cuadra pero no puede precisar qué es.

Esta distinción es algo más que una simple manía mía (que sin duda lo es, ¡pero en este caso importa para los equipos que se dedican a la localización!). Un sitio web puede estar perfectamente internacionalizado y aun así percibirse como "fuera de lugar" en el idioma de destino. Su equipo se esmeró en diseñar botones que se expanden para dar cabida al texto en alemán, etiquetas de precio con el símbolo de moneda correcto y fechas impresas en un formato familiar para el lector. ¡Eso son i18n! Pero ¿qué pasa con la frase que está al lado del botón? ¿Parece que lo escribió alguien que entiende el mercado o que simplemente lo pasaron por una aplicación de traducción y lo pusieron directamente en la página? Esa es la función de la localización, y es el factor decisivo para que el visitante siga navegando o abandone la página.

Qué significa realmente el número i18n

Ya lo he dicho antes, pero vale la pena repetirlo (valga la redundancia): internacionalización es un numerónimo. Toma la primera letra (i), la última letra (n), cuenta las 18 letras entre ellas, y voilà , obtienes i18n. Es una abreviatura que se popularizó porque los desarrolladores querían una forma de escribir la palabra sin tener que deletrearla cincuenta veces en una revisión de código. Por lo tanto, l10n para localización y a11y para accesibilidad, etc.

Pero la abreviatura es la parte aburrida. Lo que importa es lo que realmente hace i18n .

Es el proceso de estructurar un código base para que pueda admitir cualquier idioma o configuración regional sin necesidad de reescribirlo:

• Cadenas de texto extraídas del código a archivos externos, en lugar de estar codificadas de forma fija.
• Codificación UTF-8, por lo que los caracteres acentuados y los alfabetos no latinos se muestran correctamente.
• Diseño que no presupone que el texto siempre se lee de izquierda a derecha.
• Los formatos de fecha, número y moneda se tratan como variables, no como supuestos fijos.

Bien hecho, el curso i18n es como el agua para un pez dorado, invisible y desapercibido (en el mejor sentido posible).

l10n: la parte que nunca termina

Si i18n es el coche, entonces l10n es el combustible. Cuando decides añadir francés, estás localizando el idioma. Cuando añades japonés, vuelves a localizar. No se trata de una fase que se completa, sino de un proceso repetitivo, por lo que la localización necesita su propio flujo de trabajo, responsable y conjunto de herramientas, manteniéndose separada de la ingeniería.

Un equipo puede lanzar un producto genuinamente internacionalizado y aun así fallar en la localización, porque la localización no es solo cambiar palabras. También puede incluir modismos y formalidad, así como intercambios de imágenes e incluso sutiles cambios de color.

Donde la diferencia se muestra en una página en vivo

Los problemas de formato son la forma más sencilla de ver cómo funcionan las versiones i18n y l10n por separado.

Tomemos los números como ejemplo. En Estados Unidos, mil dólares y cincuenta centavos se escribe como 1,000.50. En gran parte de Europa se escribe el mismo valor que 1.000,50, intercambiando la coma y el punto. En el recuadro de divisas se muestran 99.00 dólares estadounidenses y 99,00 euros alemanes, con los símbolos en lados opuestos. Las fechas se dividen aún más. 03/04/2026 significa 4th de marzo en EE. UU. y 3rd de abril en casi todos los demás lugares, razón por la cual existe la norma ISO 8601 (AAAA-MM-DD), para evitar la ambigüedad en lugar de discutir sobre ello país por país. Los códigos de idioma también siguen un estándar: la norma ISO 639-1 asigna códigos de dos letras como de, ja y pt, de modo que un sistema de configuración regional dispone de un identificador estable con el que trabajar, en lugar de tener que adivinarlo a partir del nombre de un país.

La expansión de texto es uno de los aspectos que los equipos de ingeniería suelen subestimar. Phrase’s own i18n documentation uses a shoe size as a clean illustration: a UK size 10 is a European size 38, and a US size 38 is a completely different EU 6. Ahora, si traduces una etiqueta de interfaz de usuario de la misma manera, obtendrás el mismo tipo de discrepancia en la longitud de las palabras. Los textos en alemán y finlandés suelen ser entre un 20 y un 35 por ciento más largos que el texto original en inglés, razón por la cual un botón con la etiqueta "Submit" encaja perfectamente y "Zur Kasse gehen" no, a menos que el diseño se haya creado con contenedores flexibles. El árabe y el hebreo, al ser lenguas que se escriben de derecha a izquierda (RTL), plantean un problema completamente diferente: todo el diseño se refleja, y no solo la dirección del texto.

Nada de esto se resuelve adecuadamente en el momento de la traducción. Debería resolverse en el código, de ahí mi insistencia en hacer bien la versión i18n antes de que empiece la l10n .

El flujo de trabajo: construye tu casa sobre una base sólida.

En un sistema saludable, la internacionalización se produce una sola vez y la localización se repite indefinidamente sobre la misma. Extraes tus cadenas de texto, configuras la codificación y creas diseños flexibles una sola vez. Luego se traduce al francés. Más tarde, lo localizas al japonés. Más tarde aún, se incorporó el árabe, sin volver a tocar la arquitectura subyacente, porque esta se diseñó desde el principio para adaptarse a cualquier contexto geográfico.

Lo que suele hacer tropezar a los equipos es saltarse el primer paso e intentar solucionarlo durante el segundo. Es entonces cuando te encuentras con cadenas de texto codificadas de forma rígida, enterradas a tres niveles de profundidad, y selectores de fecha que solo entienden MM/DD/YYYY. Finalmente, el proyecto de traducción se convierte en una reestructuración que nadie había previsto.

¿Tenemos que reconstruir nuestra infraestructura tecnológica?

He participado en suficientes llamadas de ventas como para saber qué preocupa a la mayoría de los equipos: "¿Tenemos que reconstruir nuestra infraestructura tecnológica para hacer esto bien?". Aquí se parte de la premisa de que si su sitio web no fue internacionalizado desde el principio, entonces localizarlo correctamente implica una revisión y transformación completas. La mayoría de las veces, la respuesta es NO.

Si la capa de localización se ejecuta sobre el sitio web existente en lugar de dentro de su código fuente, entonces no es necesario reconstruirlo. Me estoy delatando un poco, pero así es precisamente como funciona Bablic . En la mayoría de los casos, un fragmento de código JavaScript ligero se ejecuta en el navegador del visitante y reemplaza el texto traducido por el texto en el idioma correcto en el momento de la solicitud, sin rastrear ni reconstruir el sitio de origen (el servidor original donde reside la página).

La preocupación sobre el rendimiento que suele surgir es que un enfoque del lado del navegador implica cargar todo el corpus de traducción en cada visualización de página. Si esto le preocupa de verdad, elija una herramienta que ofrezca almacenamiento en caché de pretraducción, que guarda el texto traducido previamente para que el navegador no tenga que acceder a la API de traducción desde cero en cada solicitud.

A estas alturas estarás diciendo: "pero mi producto es una aplicación nativa con lógica condicional profundamente anidada y sin separación entre cadenas y código"... bla, bla, bla. Bueno, ¡ese sí que es un problema de ingeniería que una capa del lado del navegador no va a solucionar! En este caso, busque una solución con un SDK. Pero en el caso de los sitios web de marketing y las tiendas online, cuyas páginas se crearon una vez en un idioma y ahora deben dar servicio a cinco mercados, la suposición de que se trata de una reestructuración es, en general, errónea.

No traduzcas sin contexto.

A page can pass every i18n check (the currency’s right, the date format is right) and still read as obviously foreign to the person it’s supposed to be speaking to. Los clientes se dan cuenta cuando un mensaje no da en el clavo o es ligeramente incorrecto, y las personas que lo perciben no se convierten en clientes. Ese es el valle inquietante que mencioné antes, y eso es un verdadero asesino de conversiones.

Comprender y aplicar el contexto ayuda a resolver este problema. En primer lugar, al tener control sobre términos específicos, como el nombre de su marca y los nombres propios de su producto, se asegura de que las frases clave se traduzcan siempre de la misma manera, independientemente de la traducción automática que utilice por defecto. Un glosario que te permita dejar constancia de esas decisiones es lo que hace que una página traducida suene como tu marca, en lugar de una versión genérica dirigida a nadie en particular.

La segunda ventaja es la posibilidad de ver directamente la página traducida y corregir los errores en el mismo lugar, sin necesidad de dominar el idioma de destino para detectar una frase que resulte incómoda. Un editor contextual muestra la página traducida en tiempo real y permite editarla directamente, lo que significa que un compañero hispanohablante puede revisar el resultado en pocos minutos en lugar de que un traductor tenga que rehacer todo el trabajo desde una hoja de cálculo.

Para la mayoría de las páginas, la traducción automática (TA) es un punto de partida razonable. Los motores predeterminados de Bablic son Google Translate y DeepL, que procesan el primer borrador a una velocidad que ningún equipo humano puede igualar. Para la mayoría de las empresas con las que hablamos, estos motores, combinados con un glosario y una revisión puntual con un editor contextual, son suficientes para que sientan que su sitio web está verdaderamente localizado.

Preguntas más frecuentes