Índice
Hay una conversación que ocurre en casi todas las startups alrededor de la Serie A. Alguien mira los análisis y nota que el 30% de los registros provienen de países no angloparlantes. El producto es solo en inglés. La deserción de esas cohortes es brutal. El líder de ingeniería dice: "necesitamos internacionalizar".
Luego llega la estimación: seis meses como mínimo.
Esa estimación es casi siempre precisa y casi siempre evitable.
El costo real de incorporar i18n retroactivamente
Según CSA Research, el 87% de los consumidores no comprarán en un producto solo en inglés cuando existen alternativas en su idioma. El mercado de localización alcanzó los $6,27 mil millones en 2023 y sigue creciendo. Estos no son números de nicho — representan un techo sobre su mercado direccionable que ha instalado silenciosamente en su base de código.
La razón por la que la incorporación retroactiva es costosa no es porque la internacionalización sea técnicamente difícil. Es por cómo se construyen las aplicaciones sin tener en mente i18n:
- Literales de cadenas dispersos en 200 componentes
- Formato de fecha y número codificado de forma fija a las convenciones de EE. UU.
- Columnas de base de datos dimensionadas para texto en inglés
- Diseño de derecha a izquierda nunca considerado
- Contenido estructurado en torno a suposiciones gramaticales del inglés
- Manejo de zonas horarias vinculado a una sola región
Cada uno de estos es barato de hacer correctamente desde el primer día. Cada uno es doloroso de desenredar en el mes 18, cuando la base de código tiene 40,000 líneas y cuatro ingenieros que han construido sobre las suposiciones originales.
La estimación de seis meses no es para agregar traducciones. Es para auditar y reescribir las partes de su aplicación que se construyeron sin tener en mente i18n. La traducción es el 20% del trabajo. El otro 80% es arqueología.
¿Cuándo debería internacionalizar realmente?
Esta pregunta tiene dos partes: cuándo hacer que su arquitectura esté lista para i18n y cuándo lanzar realmente múltiples idiomas.
Arquitectura: El primer día, siempre.
El costo de construir con compatibilidad i18n desde el principio es de aproximadamente dos horas de configuración. No está traduciendo nada. No está contratando traductores. Solo está tomando decisiones que no cierran puertas.
- Externalice sus cadenas en archivos de recursos en lugar de codificarlas de forma fija
- Use una biblioteca de fecha/hora compatible con configuración regional (Luxon, date-fns con soporte de configuración regional, Temporal)
- Elija un enfoque de formato de números que envuelva
Intl.NumberFormat - Deje espacio en su interfaz de usuario para la expansión de texto (el alemán puede ser un 30% más largo que el inglés)
- Almacene la configuración regional como preferencia de usuario desde el principio
Esto no es optimización prematura. No es gold-plating. Es la misma razón por la que usa variables de entorno para valores de configuración que podría querer cambiar — no está anticipando una necesidad específica, está evitando una trampa específica.
Lanzar traducciones: Después de tener señal.
No necesita lanzar francés el primer día. Necesita estar listo para hacerlo. La decisión de invertir realmente en un segundo idioma debe estar impulsada por datos:
- Está viendo registros orgánicos desde un mercado objetivo
- Una conversación de ventas lo requiere para cerrar un trato
- Está entrando en un mercado donde la penetración del inglés es baja
- Una cohorte de clientes con un idioma específico está desertando a una tasa más alta
Cuando aparece esa señal, "listo para i18n" significa que puede lanzar un segundo idioma en una semana, no en seis meses.
La trampa del cronograma de 3 meses
Así es como los equipos quedan atrapados: saben que necesitan i18n, no quieren hacerlo mal, así que planifican un "proyecto i18n adecuado". Lo estiman en tres meses. Esa estimación incluye:
- Auditar cadenas existentes
- Construir un pipeline de traducción
- Integrar un sistema de gestión de traducción
- Coordinar con un proveedor de traducción
- Control de calidad en todos los locales
Mientras el proyecto está en planificación, la hoja de ruta sigue avanzando. El proyecto de tres meses sigue siendo deprioritizado porque no lanza funciones. Para cuando finalmente se prioriza, es un proyecto de cinco meses porque la base de código creció.
La trampa es tratar i18n como una migración de gran explosión. La alternativa es tratarlo como una base que se coloca de manera incremental, comenzando con la arquitectura.
La configuración mínima viable de i18n
Así es como se ve "listo para i18n" en la práctica para una aplicación React o Next.js en etapa semilla. Cuesta dos horas configurarlo y tiene cero gastos generales continuos hasta que esté listo para traducir.
Paso 1: Elija un enfoque de externalización de cadenas.
No codifique de forma fija las cadenas de visualización. Como mínimo, colóquelas en archivos JSON. Mejor: use una solución tipada desde el principio.
// Malo — cadena codificada de forma fija
<button>Get started for free</button>
// Mejor — externalizada, aunque sea solo inglés por ahora
// messages/en.json
{
"cta.getStarted": "Get started for free"
}
// Componente
const t = useTranslations();
<button>{t('cta.getStarted')}</button>
Aún no necesita una plataforma de traducción. Un archivo JSON por configuración regional, aunque sea solo inglés, es suficiente. El hábito de usar t() en lugar de cadenas en línea es lo que importa.
Paso 2: Formato compatible con configuración regional desde el primer día.
// Malo — formato de EE. UU. codificado de forma fija
const formatted = `$${price.toFixed(2)}`;
const date = new Date(ts).toLocaleDateString('en-US');
// Bueno — compatible con configuración regional
const formatted = new Intl.NumberFormat(locale, {
style: 'currency',
currency: 'USD'
}).format(price);
const date = new Intl.DateTimeFormat(locale, {
dateStyle: 'medium'
}).format(new Date(ts));
Cuando agrega un segundo local más tarde, el formato simplemente funciona. Sin grep-and-replace en 80 archivos.
Paso 3: Diseñe con la expansión de texto en mente.
Deje espacio para respirar en su interfaz de usuario. Use CSS que se degrade con gracia cuando el texto se extienda. Evite anchos fijos en píxeles en los contenedores de texto. Esto no cuesta nada en diseño pero ahorra dinero real en control de calidad cuando lance alemán.
Paso 4: Almacene la configuración regional como atributo de usuario de primera clase.
Incluso si está lanzando un idioma, almacene preferred_locale en su modelo de usuario. Cuando agrega un segundo idioma, sus usuarios existentes ya tienen una preferencia de configuración regional almacenada. No está migrando un esquema bajo datos en vivo.
Errores comunes de startups
"Agregaremos i18n cuando lo necesitemos." El momento en que lo necesitas es el momento en que no tienes tiempo para hacerlo correctamente. La señal que desencadena la decisión — un cliente importante que requiere francés, un empuje regional de go-to-market — siempre viene con urgencia adjunta.
Construir un pipeline de traducción personalizado. La gestión de traducción es un problema resuelto. Una solución personalizada cuesta semanas en construirse y meses en mantenerse. Use las herramientas que ya existen.
Tratar la localización como solo traducción. El idioma es el 20% de la localización. Moneda, formatos de fecha, formatos de dirección, requisitos legales, soporte RTL, convenciones de UX específicas de la configuración regional — estos son el otro 80%. Una cadena traducida en un diseño roto sigue siendo una experiencia rota.
Dar a los traductores acceso directo a los archivos JSON. Los traductores humanos nunca deben editar JSON manualmente. La tasa de error es alta y el ciclo de retroalimentación es lento. Necesitan una interfaz de usuario construida para el trabajo de traducción, con contexto, límites de caracteres y aplicación de consistencia de términos.
Asumir que el orden de palabras en inglés se generaliza. Concatenar cadenas traducidas con interpolación de cadenas de JavaScript se rompe en idiomas con diferentes estructuras gramaticales. Use el formato de mensaje ICU para cualquier cosa con variables.
// Malo — asume el orden de palabras en inglés
t('welcome') + ' ' + userName + '!'
// Bueno — formato ICU, la configuración regional puede reordenar los tokens
t('welcome', { name: userName })
// en: "Welcome, {name}!"
// ja: "{name}さん、ようこそ！"
Un marco de decisión
Use esto para decidir dónde se encuentra y qué hacer:
| Etapa | Arquitectura i18n | Traducciones activas |
|---|---|---|
| Antes del producto | Configurar cadenas externalizadas, formato compatible con configuración regional | No |
| Antes de PMF | Mantener la base, no traducir todavía | No |
| Después de PMF, antes de Serie A | Si está viendo señal internacional, traducir los 2 idiomas principales | Tal vez |
| Serie A+ | Tratar la localización como requisito del producto | Sí |
La idea clave: la decisión de arquitectura y la decisión de traducción son independientes. Tome la decisión de arquitectura ahora. Tome la decisión de traducción cuando los datos se lo indiquen.
La lista de verificación práctica
Antes de escribir otro componente, revise esto:
- Las cadenas están externalizadas (no codificadas de forma fija en JSX/plantillas)
- El formato de fecha usa APIs compatibles con configuración regional
- El formato de números y moneda usa
Intl.NumberFormat - El modelo de usuario tiene un campo
locale - Los diseños de interfaz de usuario probados con texto un 30% más largo
- Sin concatenación de cadenas con partes traducibles
- Formato de mensaje ICU usado para cadenas con variables
- Pluralización manejada correctamente (no solo agregar "s")
Completar todo esto lleva dos horas. Perder cualquiera de ellos a escala cuesta semanas.
Cómo se ve esto en la práctica
Cuando está listo para lanzar realmente múltiples idiomas, el flujo de trabajo cambia de "excavación arqueológica" a "proyecto de traducción". Necesita:
- Una forma de exportar cadenas fuente a traductores
- Un proceso de revisión para traducciones
- Un pipeline de despliegue que actualice cadenas sin un despliegue de código
- Entrega en tiempo de ejecución del local correcto a cada usuario
En Better i18n, construimos una plataforma en torno a este problema específico — SDKs con tipos seguros para React, Next.js, Vue y Svelte, flujos de trabajo de traducción basados en Git para que las traducciones pasen por revisión como el código, y entrega por CDN para que pueda actualizar traducciones sin volver a desplegar. El nivel gratuito en nuestra página de precios está dimensionado para equipos en etapa temprana que quieren construir la base sin compromiso de presupuesto. Si quiere ver cómo encajan las piezas técnicas, la página para desarrolladores tiene el panorama completo.
La reescritura de seis meses no es inevitable. Es el resultado de una decisión de dos horas diferida demasiado tiempo.