# General Translation Knowledge Base: ¿Qué debo comprobar antes de lanzar una aplicación multilingüe?
URL: https://generaltranslation.com/es/kb/multilingual-app-launch-checklist.mdx
Docs index: https://generaltranslation.com/llms.txt
Description: Antes de lanzar una aplicación multilingüe, prueba nueve aspectos en cada configuración regional compatible: recorridos de usuario completos, incluidos los errores; detección y cambio de idioma; variables y plurales; moneda y zonas horarias; expansión del texto; diseño right-to-left; accesibilidad; entrega de traducciones en producción; y URL de idioma rastreables para SEO. Cada comprobación necesita un criterio de aprobación explícito.
Category: Internacionalización
Last updated: 2026-10-16
Authors: Jackie Chen
Published: 2026-10-16

Una página de inicio traducida puede parecer terminada aunque el proceso de pago, los errores de validación o el flujo de restablecimiento de contraseña sigan en el idioma de origen. Empieza por los recorridos que un usuario necesita completar y pruébalos en la compilación de producción.

Antes de lanzar una aplicación web multilingüe, comprueba estos nueve aspectos en cada configuración regional compatible:

1. **Los recorridos completos están traducidos**, incluidos los estados de carga, vacíos y de error, los correos electrónicos y las notificaciones.
2. **La selección de idioma es coherente** en la primera visita, después de cambiar de idioma y en visitas posteriores.
3. **Las variables y los plurales son correctos** en todas las categorías de plural que usan tus idiomas.
4. **La moneda y la zona horaria se definen explícitamente**, con independencia del idioma de la UI.
5. **Los diseños aguantan la expansión del texto** en pantallas estrechas y con el zoom del navegador.
6. **Los idiomas right-to-left** tienen la dirección, el diseño y el texto bidireccional correctos.
7. **Las tecnologías de asistencia reciben el idioma, las etiquetas y los nombres accesibles correctos**.
8. **La compilación de producción incluye traducciones completas**, y el texto nuevo se traduce antes del lanzamiento.
9. **Las páginas públicas tienen URL de idioma rastreables** con metadatos traducidos y `hreflang`.

Prueba el contenido en cada configuración regional compatible, y el diseño y la interacción en dispositivos y navegadores representativos. La comprobación 9 solo se aplica a las páginas públicas que quieras indexar.

## Comprobar el comportamiento del contenido y del idioma

### 1. Traduce el recorrido completo, incluidos los estados de error

Elige un recorrido crítico, como crear una cuenta o completar una compra. Pon a prueba sus estados de carga, vacío, éxito y error. Revisa los botones, los cuadros de diálogo, la validación de formularios, los marcadores de posición, las etiquetas de accesibilidad y cualquier correo electrónico o notificación que envíe el recorrido.

**Criterio de aprobación:** Todas las superficies usan contenido revisado en el idioma de destino, salvo excepciones intencionadas, como el nombre de un producto. No aparecen claves sin procesar, marcadores de mensajes faltantes ni contenido alternativo injustificado en el idioma de origen.

**Con General Translation:** Comprueba que la salida de [`gt translate`](/docs/cli/reference/commands/translate) sea la versión incluida en el lanzamiento. ([`gt generate`](/docs/cli/reference/commands/generate) solo escribe plantillas de origen, que aún necesitan el texto traducido). Los revisores corrigen la redacción en el [Editor de Traducciones del panel de control](/docs/platform/dashboard/guides/reviewing-translations); si tu equipo prefiere editar los archivos generados directamente en el repositorio, ejecuta [`gt save-local`](/docs/cli/reference/commands/save-local) para que las ejecuciones posteriores conserven esos cambios. Para que los términos del producto sean coherentes en tu aplicación, tu documentación y tus notificaciones, asigna términos de glosario y prompts personalizados compartidos mediante [grupos de contexto](/docs/platform/dashboard/guides/defining-context-for-translations) antes de generar las traducciones. Los cambios de contexto se aplican a las traducciones nuevas, pero no reescriben las existentes.

### 2. Verifica las primeras visitas, el cambio de idioma y las visitas recurrentes

Prueba con un navegador nuevo, una elección explícita de idioma, una recarga, un enlace profundo y un idioma de navegador no compatible. Si la aplicación guarda una preferencia de idioma en la cuenta, prueba también el inicio y el cierre de sesión. Anota qué ajuste prevalece cuando la URL, la preferencia guardada y el navegador no coinciden.

**Criterio de aprobación:** La aplicación aplica esa política de forma coherente y el usuario puede deshacer una elección de idioma no deseada. En las aplicaciones server-rendered, inspecciona tanto la respuesta inicial como la página hidratada.

Los identificadores de configuración regional siguen el estándar BCP 47: `es-MX` y `es-AR` pueden ser destinos independientes para el español de México y el de Argentina. Prueba cada destino regional que publiques. Un selector basado en cookies y las rutas con prefijo de configuración regional responden a necesidades distintas; comprueba cómo se comportan realmente las URL de la aplicación.

**Con General Translation:** Define los idiomas compatibles, incluidos los destinos regionales, en la [configuración regional](/docs/react/guides/managing-locales) de tu proyecto.

### 3. Prueba variables y categorías de plural

Prueba cantidades como 0, 1, 2 y valores mayores; después, añade casos para las categorías de plural de tus idiomas de destino. Incluye nombres con signos de puntuación, nombres de cuenta largos y oraciones cuyas variables puedan cambiar de orden al traducirse. Evita construir oraciones concatenando fragmentos traducidos por separado.

**Criterio de aprobación:** Los valores se mantienen intactos, la oración se lee correctamente y cada forma plural obligatoria tiene contenido utilizable. Las [reglas de plural](https://cldr.unicode.org/index/cldr-spec/plural-rules) de Unicode explican por qué no basta con un único par de pruebas singular/plural en inglés.

**Con General Translation:** [`<Plural>`](/docs/react/reference/components/plural) aplica las reglas de plural de la configuración regional: el inglés tiene dos categorías cardinales, mientras que el árabe tiene seis. Usa [`<Branch>`](/docs/react/reference/components/branch) cuando la redacción dependa de un valor explícito, como el género gramatical de una persona, y [`<Var>`](/docs/react/reference/components/var) para texto dinámico, como un nombre. Los valores dentro de ese contenedor de variable no se envían a la API de traducción. El [artículo sobre pluralización en React](/kb/how-to-handle-plurals-in-react) explica el patrón de implementación.

## Revisa el formato, el diseño y la accesibilidad

### 4. Separa el idioma, la moneda y la zona horaria

Prueba el mismo importe y el mismo instante con varias configuraciones regionales. Define explícitamente la moneda y la zona horaria correspondientes cuando tu producto lo requiera. La preferencia de idioma, por sí sola, no indica en qué moneda paga un cliente ni en qué zona horaria se programa una cita.

Por ejemplo, este código da formato a un importe existente en USD según las convenciones alemanas:

```js
new Intl.NumberFormat('de-DE', {
  style: 'currency',
  currency: 'USD',
}).format(1234.5);
```

Da formato al importe indicado sin convertir divisas. Al aplicar formato, los dígitos mostrados pueden redondearse, así que comprueba la precisión que necesita tu producto. Del mismo modo, usa una zona horaria explícita cuando muestres un instante en una ubicación concreta:

```js
new Intl.DateTimeFormat('en-GB', {
  dateStyle: 'medium',
  timeStyle: 'short',
  timeZone: 'Europe/Paris',
}).format(new Date('2026-01-15T12:00:00Z'));
```

**Criterio de aprobación:** Los separadores, la moneda, la fecha del calendario y la hora mostrada se corresponden con el significado que el producto pretende transmitir. Incluye un cambio de horario de verano si alguna de las zonas horarias que admites lo aplica. Las API de [números](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/NumberFormat) y de [fechas](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/DateTimeFormat) exponen estas opciones por separado.

**Con General Translation:** [`<Currency>`](/docs/react/reference/components/currency), [`<DateTime>`](/docs/react/reference/components/datetime) y [`<Num>`](/docs/react/reference/components/num) dan formato a los valores según la configuración regional activa. Define la moneda y la zona horaria en función del significado de negocio que buscas; cambiar el idioma de la UI no debería alterar el importe adeudado ni el momento en que ocurre un evento.

### 5. Prueba la expansión del texto en distintos tamaños de pantalla

Abre las pantallas traducidas en viewports estrechos y con el zoom del navegador activado. Revisa la navegación, los botones, las tablas, los cuadros de diálogo y los mensajes de validación. Incluye cadenas traducidas largas y valores largos introducidos por el usuario: un encabezado corto no exige lo mismo al diseño que una dirección completa.

**Condición de aprobación:** El texto esencial se mantiene legible y los controles siguen siendo utilizables. Ninguna acción queda oculta tras texto recortado o elementos superpuestos. Revisa el truncamiento de forma deliberada en lugar de recurrir a él para ocultar cualquier desbordamiento.

La [pseudolocalización](https://lingui.dev/guides/pseudolocalization) puede ayudar a detectar problemas de diseño y cadenas sin marcar antes de que las traducciones estén listas. Complementa las pruebas con idiomas reales, pero no garantiza la calidad de la traducción.

### 6. Prueba el contenido right-to-left como un requisito de diseño

Si das soporte a árabe, hebreo u otro idioma right-to-left, prueba la dirección del documento, el orden de navegación, los formularios y el contenido con direcciones mixtas, como direcciones de correo electrónico e ID de pedido. Usa propiedades lógicas de CSS cuando el diseño deba seguir la dirección del texto y revisa los iconos direccionales uno a uno.

**Criterio de aprobación:** El diseño respeta la dirección de lectura prevista y los valores left-to-right incrustados siguen siendo legibles. Definir un código de idioma no define la dirección del texto; consulta la [guía sobre la dirección en HTML](https://www.w3.org/International/questions/qa-html-dir) del W3C.

### 7. Comprueba el idioma que reciben las tecnologías de asistencia

Verifica el atributo `lang` de la página, los cambios de idioma dentro del contenido cuando corresponda, las etiquetas visibles, los nombres accesibles y el texto alternativo. Prueba el recorrido principal navegando con el teclado y con un lector de pantalla. Un texto de ejemplo traducido no puede sustituir a una etiqueta de formulario permanente.

**Criterio de aprobación:** el documento declara el idioma correcto, los controles tienen nombres localizados significativos y el diseño traducido sigue siendo utilizable. El W3C explica las [declaraciones de idioma](https://www.w3.org/International/questions/qa-html-language-declarations) y su [guía sobre etiquetas de formulario](https://www.w3.org/WAI/tutorials/forms/labels/) aborda cómo asociar las etiquetas.

## Comprueba el lanzamiento que recibirán los usuarios

### 8. Verifica los recursos de producción y las actualizaciones de traducción

Genera una compilación a partir de un checkout limpio con el proceso de lanzamiento y, después, ejecuta esa compilación con cada configuración regional compatible. Confirma que los recursos de traducción estén presentes y se carguen correctamente. Modifica un mensaje de origen en una rama de prueba y comprueba que el flujo de traducción detecte el cambio antes del siguiente lanzamiento.

**Condición de aprobación:** La aplicación sirve las traducciones previstas sin depender de archivos que hayan quedado del desarrollo. Si faltan recursos o falla la generación, se produce un error visible o se usa un contenido alternativo aceptado explícitamente, en lugar de un lanzamiento parcial silencioso.

**Con General Translation:** Ejecuta [`gt validate`](/docs/cli/reference/commands/validate) para detectar los errores de traducción inline compatibles antes de una llamada a la API y, luego, coloca el [paso de traducción incremental antes de la compilación](/docs/cli/guides/generating-translations). Este paso reutiliza las traducciones anteriores y traduce el contenido modificado, de modo que los textos nuevos pueden publicarse ya traducidos en el mismo lanzamiento que los incorpora. El [seguimiento de ramas](/docs/cli/guides/branching) mantiene separadas las ramas de desarrollo paralelas. Las [automatizaciones de Locadex](/docs/platform/locadex/guides/configuring-automations) pueden gestionar las actualizaciones de traducción mediante pull requests. Como parte de esta comprobación del lanzamiento, prueba el disparador configurado con un cambio en el texto de origen.

Con el [flujo de trabajo de almacenamiento local](/docs/react/guides/storing-translations), la aplicación sirve traducciones incluidas en el paquete sin hacer llamadas a General Translation en tiempo de ejecución; las actualizaciones se publican con una nueva compilación. Con la entrega mediante CDN, las ediciones publicadas pueden llegar a la aplicación sin volver a desplegarla, en función de su versión de traducción y su configuración de caché. Prueba esa vía de actualización. Mantén las credenciales privadas de las herramientas de traducción en el entorno de compilación, fuera de los paquetes del navegador.

### 9. Verifica que las versiones públicas en cada idioma sean detectables

En las páginas que deban aparecer en los buscadores, comprueba que cada versión de idioma tenga una URL rastreable, títulos y descripciones traducidos, la URL canónica prevista y versiones alternativas de idioma válidas. Comprueba que las referencias `hreflang` sean recíprocas, incluida la de la propia página. Si las versiones alternativas se declaran en un sitemap, verifica que este refleje las mismas relaciones entre páginas.

**Condición de aprobación:** Cada URL pública de idioma carga el contenido esperado, es indexable cuando corresponde y apunta a versiones alternativas reales. La [guía sobre páginas localizadas](https://developers.google.com/search/docs/specialty/international/localized-versions) de Google describe los métodos de anotación admitidos. Para una implementación en Next.js, consulta la [guía de SEO multilingüe](/kb/multilingual-nextjs-seo).

Los prefijos de ruta, los subdominios de idioma y los dominios de país permiten ofrecer URL independientes para cada idioma. Una cabecera `Accept-Language` o una cookie pueden seleccionar el idioma de un visitante, pero por sí solas no crean una URL rastreable para cada versión. La [guía sobre sitios multilingües](https://developers.google.com/search/docs/specialty/international/managing-multi-regional-sites) de Google recomienda usar URL independientes. Es posible que un panel de control con autenticación no necesite URL de idioma indexadas; elige la política de enrutamiento en función de la audiencia del producto.

## Mantén un registro de cada lanzamiento

Registra la compilación, la configuración regional, el recorrido, el navegador o dispositivo, el resultado esperado, el resultado real y el revisor. Asigna un responsable a cada fallo. No trates igual una traducción que falta en el proceso de pago o una acción principal ilegible que una simple preferencia de redacción, y deja constancia explícita de cualquier contenido alternativo que se acepte.

Para una primera revisión rápida de un sitio público, el [Report Card](https://generaltranslation.com/report-card) gratuito de General Translation puntúa su localización. No tiene acceso a los flujos autenticados ni a los estados de error, así que compleméntalo con las comprobaciones de recorridos anteriores.

## Preguntas frecuentes

### ¿Cómo se prueba una aplicación multilingüe?

Ejecuta recorridos de usuario completos en cada configuración regional compatible con una compilación de producción, incluidos los estados de error, los correos electrónicos y las notificaciones. Comprueba los plurales, las variables, la moneda, las zonas horarias, el diseño, el texto right-to-left y la accesibilidad, y define un criterio de aprobación para cada comprobación.

### ¿Cuál es el error de localización que más se pasa por alto?

Los estados de error sin traducir. Los mensajes de error, la validación de formularios, los estados vacíos y los correos electrónicos transaccionales suelen seguir en el idioma de origen incluso después de traducir las pantallas principales. Pruébalos expresamente en la comprobación 1.

### ¿Qué es la pseudolocalización?

La pseudolocalización sustituye el texto de origen por un texto de marcador de posición más largo y con acentos, para que puedas detectar desbordamientos en el diseño y cadenas sin marcar antes de contar con traducciones reales. No reemplaza las pruebas con idiomas reales. Consulta la [guía de pseudolocalización de Lingui](https://lingui.dev/guides/pseudolocalization).

### ¿Las páginas multilingües necesitan URL distintas para el SEO?

Sí, en el caso de las páginas que quieras indexar. Google recomienda usar una [URL distinta para cada versión de idioma](https://developers.google.com/search/docs/specialty/international/managing-multi-regional-sites), enlazadas entre sí mediante `hreflang`. Una cookie o una cabecera `Accept-Language` por sí solas no generan versiones rastreables. Para Next.js, consulta [SEO multilingüe en Next.js](/kb/multilingual-nextjs-seo).

## Related questions

- [¿Cuál es la mejor biblioteca de i18n para una aplicación React?](https://generaltranslation.com/es/kb/best-react-i18n-library.mdx): Las cuatro principales bibliotecas de i18n para React son gt-react de General Translation, react-i18next, Lingui y React Intl. Las cuatro renderizan traducciones y les dan formato, pero solo gt-react también las genera a partir de textos escritos inline en tu JSX. Elige react-i18next si quieres conservar los catálogos y plugins de i18next, Lingui si buscas extracción a catálogos compilados y React Intl si prefieres FormatJS y el formato de mensajes ICU.
- [¿Puedo hacer i18n sin archivos de traducción?](https://generaltranslation.com/es/kb/i18n-without-translation-files.mdx): Sí. Con gt-react o gt-next, el contenido se mantiene inline en tus componentes, dentro de un componente `<T>`, y las traducciones se generan en tiempo de compilación, por lo que no tienes que escribir claves ni archivos JSON por configuración regional ni mantenerlos sincronizados.
- [¿Cómo gestiono los plurales en React?](https://generaltranslation.com/es/kb/how-to-handle-plurals-in-react.mdx): No codifiques la lógica de pluralización a mano con comprobaciones como n === 1. Para aplicaciones solo en inglés basta con una pequeña función auxiliar, pero las aplicaciones multilingües necesitan reglas de pluralización adaptadas a la configuración regional, y un componente de i18n como `<Plural>` de gt-react o gt-next se encarga de ellas en todos los idiomas.
- [¿Cómo configuro el SEO de una aplicación de Next.js multilingüe?](https://generaltranslation.com/es/kb/multilingual-nextjs-seo.mdx): Asigna a cada idioma su propia URL, define el atributo lang de html, haz que la URL canónica de cada página apunte a sí misma, añade versiones alternativas hreflang para cada idioma, traduce los títulos y las descripciones, e incluye todas las versiones de idioma en tu sitemap.

## Previous and next questions

- Previous question: [¿Por qué usar General Translation en lugar de un TMS (Smartling, Lokalise, Phrase, Crowdin o Transifex)?](https://generaltranslation.com/es/kb/general-translation-vs-tms.mdx)
- Next question: [Alternativas a Crowdin: General Translation vs. Crowdin](https://generaltranslation.com/es/kb/general-translation-vs-crowdin.mdx)

## Sitemap

See the [Knowledge Base sitemap](https://generaltranslation.com/es/kb/sitemap.md) for every article.