Guía de localización de SaaS: expándete globalmente sin reescribir tu app (2026)
La mayoría de los productos SaaS posponen la internacionalización durante años, no porque no sea importante, sino porque el enfoque convencional exige un proyecto de ingeniería completo antes de que un solo usuario vea una cadena traducida. Esta guía muestra cómo son las alternativas en la práctica.
El problema de la localización de SaaS
El consejo estándar para la localización de SaaS es adoptar una librería de i18n: react-i18next, i18next o formatjs. Cada una de estas librerías requiere la misma migración en varios pasos:
- →Envolver cada cadena de la interfaz en una llamada
t(), tocando cientos de componentes en toda la base de código. - →Crear y mantener un archivo de traducción JSON por idioma de destino.
- →Añadir definiciones de claves con tipado seguro para que las traducciones faltantes aparezcan en tiempo de compilación.
- →Implementar reglas de pluralización, que difieren significativamente entre idiomas.
- →Establecer un flujo de traducción para que las nuevas cadenas de interfaz se traduzcan antes de publicarse.
Para un producto SaaS típico con uno o dos años de desarrollo detrás, esto supone un proyecto de ingeniería de 2 a 4 semanas antes de que cualquier usuario vea una cadena traducida. Los equipos, racionalmente, lo posponen hasta que los ingresos internacionales se vuelven imposibles de ignorar.
Qué necesita traducirse realmente
Antes de elegir un enfoque, ayuda enumerar qué significa realmente “el producto” en términos de traducción. Para una aplicación SaaS típica:
| Tipo de contenido | ¿En el DOM? | Enfoque del widget |
|---|---|---|
| Cadenas de interfaz, navegación, botones | Sí | Cubierto automáticamente |
| Mensajes de error y notificaciones | Sí (cuando se muestran) | Cubierto mediante MutationObserver |
| Flujos de onboarding y texto de ayuda | Sí | Cubierto automáticamente |
| Contenido dinámico tras respuestas de API | Sí (tras el renderizado) | Cubierto mediante MutationObserver |
| Plantillas de correo electrónico | No | Fuera de alcance — necesita solución independiente |
| Cadenas fijas en los bundles de JS | Solo si se renderizan | Cubierto cuando se renderizan en el DOM |
Desplázate horizontalmente para ver todas las columnas.
La gran mayoría de lo que los usuarios ven en una aplicación web se renderiza en el DOM. Eso hace que la traducción basada en el DOM sea un punto de partida práctico, aunque no cubra todos los casos extremos.
La alternativa basada en el DOM
Un widget de traducción mediante etiqueta de script adopta un enfoque distinto: en lugar de instrumentar tu código fuente, observa el HTML renderizado en el navegador y lo traduce en el lugar.
El mecanismo funciona así:
- 1Al cargar la página, el script recorre el DOM y recolecta nodos de texto, agrupándolos en bloques para llamadas a la API eficientes.
- 2Las cadenas traducidas se devuelven desde la API y se insertan en el DOM. El texto original se conserva en memoria.
- 3Un MutationObserver vigila los nuevos nodos del DOM — provocados por navegación, apertura de modales, respuestas de API que llenan una lista — y los traduce de inmediato.
- 4Las traducciones almacenadas pueden reutilizarse sin generar otra solicitud de generación al proveedor.
Prueba el comportamiento de cambio de idioma en dispositivos y redes representativos. El enfoque de etiqueta de script puede dejar intacto el código fuente de la aplicación.
Qué hay que vigilar
El enfoque basado en el DOM cubre bien el 80-90% de los casos, pero hay situaciones específicas que evaluar para tu producto:
Cadenas que nunca se renderizan en el DOM
Si tu app construye una cadena en JavaScript y la pasa a una librería de toasts o a un alert, la cadena JS intermedia puede construirse antes de llegar al DOM. Una vez que alcanza un nodo de texto del DOM, el widget la cubre, pero si la cadena se muestra en un alert() nativo del navegador o en una superposición fuera del DOM, no se traducirá.
Contenido generado por el usuario
El contenido que escriben los usuarios — comentarios, notas, editores de texto enriquecido — se traduce cuando se renderiza, lo que puede no ser deseable. Usa los selectores de exclusión de Lingvit para marcar los contenedores de contenido de usuario como no traducibles.
Plantillas de correo del backend
Los correos transaccionales (bienvenida, factura, restablecimiento de contraseña) se envían del lado del servidor y nunca pasan por el DOM. Requieren gestión independiente, ya sea mediante las funciones de localización de tu servicio de correo o manteniendo plantillas de correo separadas por idioma.
Cadenas de respuesta de API
Si tu backend devuelve cadenas que se muestran directamente (por ejemplo, etiquetas de estado de una API), quedan cubiertas una vez renderizadas en el DOM. Si las mismas cadenas aparecen en contextos no renderizados (CSV descargados, webhooks), esos quedan fuera de alcance.
Configuración para un SaaS en React/Next.js
Añadir Lingvit a una aplicación React o Next.js existente lleva tres pasos y ningún cambio de código en tus componentes.
- 1
Regístrate y crea un proyecto
Crea un proyecto en app.lingvit.com y registra el dominio de tu aplicación. Recibirás una clave de proyecto.
- 2
Añade la etiqueta de script a tu layout raíz
En Next.js App Router, añádela a
app/layout.tsx:<Script src="https://cdn.lingvit.com/widget.bundle.js?v=1" strategy="afterInteractive" />Para Pages Router o React sin framework, pega la etiqueta
<script>antes de la etiqueta de cierre</body>. - 3
Selecciona los idiomas de destino en el panel
Elige tus idiomas de destino desde el panel. El selector de idioma se inyecta automáticamente. Las traducciones empiezan a generarse en la primera visita a la página para cada idioma.
Control editorial
La traducción automática gestiona el volumen, pero los nombres de producto, los términos legales y el lenguaje de marca necesitan supervisión humana. Lingvit ofrece varios mecanismos de control:
Navegador de traducciones
Revisa cada cadena traducida por idioma y sustituye cualquier traducción automática directamente desde el panel. Las sustituciones se almacenan de forma permanente y tienen prioridad sobre las traducciones automáticas para esa cadena.
Términos del glosario
Define términos que nunca deben traducirse: nombres de producto, nombres de funciones, terminología específica de marca. Las entradas del glosario se aplican globalmente en todos los idiomas.
Controles de publicación
Las traducciones se publican solo cuando tú las publicas. Redacta y revisa un idioma antes de que sea visible para los usuarios, luego publícalo sin un despliegue de código.
Preguntas frecuentes
- ¿El widget funciona con las funciones concurrentes de React y Suspense?
- Sí. El enfoque de MutationObserver es independiente del framework: observa la salida final del DOM sin importar cómo la renderice React. El modo concurrente, los límites de Suspense y el streaming SSR producen todos nodos del DOM que el observador gestiona con normalidad.
- ¿Qué pasa con el SSR? ¿El contenido traducido será indexado por los buscadores?
- La traducción mediante widget del lado del cliente significa que el HTML de origen contiene el idioma original. Para dashboards de SaaS protegidos por autenticación, esto rara vez importa. Para páginas de marketing públicas donde el SEO multilingüe sí importa, un enfoque de etiqueta de script es menos adecuado que el i18n renderizado en el servidor.
- ¿Puedo usar esto junto a una librería de i18n existente para nuevas funciones?
- Sí. Lingvit traduce lo que haya en el DOM: no le importa si las cadenas provienen de una librería de i18n, están escritas directamente o vienen de una respuesta de API. Puedes usar react-i18next para las funciones nuevas y dejar que Lingvit cubra el resto durante un periodo de migración.
Guías relacionadas
Expándete globalmente esta semana
Añade traducción a tu SaaS sin cambiar una sola línea de código.