# General Translation Knowledge Base: Lista de comprobación de pruebas de localización para aplicaciones multilingües
URL: https://generaltranslation.com/es/kb/multilingual-app-launch-checklist.mdx
Docs index: https://generaltranslation.com/llms.txt
Description: Prueba nueve aspectos en cada configuración regional compatible en una compilación de producción: recorridos completos, incluidos los estados de error y los correos electrónicos; cambio de idioma; plurales; moneda y zonas horarias; expansión del texto; diseño right-to-left; accesibilidad; entrega de traducciones; y URL de idioma rastreables. Asigna a cada comprobación 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.

## Video

The video is narrated in English, with English captions.

[What should I check before launching a multilingual app?](https://caxecubb9c64cezv.public.blob.vercel-storage.com/films/kb-multilingual-app-launch-checklist.mp4) (33 s)

Before launching a multilingual app, test nine things in every supported locale: complete user journeys including errors, language detection and switching, variables and plurals, currency and time zones, text expansion, right-to-left layout, accessibility, production translation delivery, and crawlable language URLs. With General Translation, run gt validate, then `npx gt translate` before the build so new copy ships translated.

## 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 textos de ejemplo, las etiquetas de accesibilidad y cualquier correo electrónico o notificación que envíe el recorrido. Usa [comprobaciones de cadenas codificadas de forma fija](/kb/find-hardcoded-strings) para detectar literales en el idioma de origen antes de la revisión manual.

**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, los revisores corrigen la redacción en el [Editor de Traducciones del panel de control](/docs/platform/dashboard/guides/reviewing-translations). Comparte [términos de glosario y prompts personalizados](/docs/platform/dashboard/guides/defining-context-for-translations) entre los proyectos de la aplicación y del correo electrónico antes de generar traducciones nuevas. Los cambios de contexto se aplican a las traducciones nuevas; revisa a conciencia la redacción existente en lugar de dar por hecho que también ha cambiado.

### 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. La [guía de detección de idioma](/kb/detect-user-language) explica la coincidencia de preferencias; la [guía del selector de idioma](/kb/language-switcher) aborda las elecciones explícitas y la navegación accesible.

**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.

### 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.

En las bibliotecas de React de GT, [`<Plural>`](/docs/react/reference/components/plural) selecciona las formas plurales específicas de la configuración regional, [`<Branch>`](/docs/react/reference/components/branch) mantiene las alternativas condicionales dentro de la unidad de traducción y [`<Var>`](/docs/react/reference/components/var) sustituye localmente los valores dinámicos. Prueba cada alternativa, no solo la oración predeterminada; los valores del usuario dentro de [`<Var>`](/docs/react/reference/components/var) no tienen por qué enviarse a la API de traducción.

**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. En el caso de mensajes basados en catálogos, prueba también las ramas de tus [mensajes ICU](/kb/icu-message-format). (Consulta [¿Cómo gestiono los plurales en React?](/kb/how-to-handle-plurals-in-react) para ver un patrón basado en componentes).

## 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. Cambiar el idioma de la UI no debería alterar el importe adeudado ni el momento en que ocurre un evento. Los componentes [`<Currency>`](/docs/react/reference/components/currency) y [`<DateTime>`](/docs/react/reference/components/datetime) de GT aplican un formato adaptado a la configuración regional con opciones explícitas de moneda y zona horaria; prueba esas opciones igual que harías con las llamadas a `Intl` anteriores.

### 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](/kb/pseudo-localization) 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. La [guía de Lingui](https://lingui.dev/guides/pseudolocalization) muestra un ejemplo de implementació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. La [guía de CSS para RTL](/kb/right-to-left-css) explica el espaciado, los iconos y los valores con direcciones mixtas.

**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. Mantén las credenciales de las herramientas de traducción en el entorno de compilación, fuera de los paquetes del navegador.

Con GT, ejecuta [`gt validate`](/docs/cli/reference/commands/validate) y, luego, [`gt translate`](/docs/cli/reference/commands/translate) antes de la compilación. Puedes configurar la compilación para que se detenga si fallan las traducciones. [`gt generate`](/docs/cli/reference/commands/generate) solo escribe plantillas de origen. Si los revisores editan la salida local, usa [`gt save-local`](/docs/cli/reference/commands/save-local) para conservar esos cambios en ejecuciones posteriores.

Prueba la vía de actualización que configuraste: [Locadex](/docs/platform/locadex/guides/configuring-automations) debería crear o actualizar su pull request de traducción al activar el disparador configurado, ya sea push, pull request o manual. Confirma que se hace el seguimiento de la rama prevista. Con [traducciones empaquetadas](/docs/react/guides/storing-translations), la aplicación desplegada puede renderizar los archivos suministrados sin depender del servicio de GT. Con la entrega mediante CDN, prueba las ediciones publicadas con tu configuración de versión y caché, incluido cualquier retraso antes de que lleguen a los usuarios.

### 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](/kb/what-is-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; la [guía sobre estructura de URL](/kb/multilingual-url-structure) los compara. 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 (consulta [Redirecciones de idioma y SEO](/kb/locale-routing-seo)). 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. El [Report Card](https://generaltranslation.com/report-card) gratuito de GT puede ofrecerte una primera evaluación de la localización de un sitio público, aunque no puede inspeccionar recorridos que requieren autenticación ni provocar deliberadamente tus estados de error.

## 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. Un registro completado podría tener este aspecto:

| Compilación      | Configuración regional | Comprobación                       | Dispositivo        | Esperado                                                     | Real                                                  | Resultado                                           |
| ---------------- | ---------------------- | ---------------------------------- | ------------------ | ------------------------------------------------------------ | ----------------------------------------------------- | --------------------------------------------------- |
| 4.12.0 (a1b2c3d) | `de`                   | 1. Tarjeta rechazada en el pago    | Chrome, escritorio | Error en alemán con opción de reintentar                     | Error en alemán, etiqueta del botón recortada a 320px | Fallo: bloquea el lanzamiento, responsable asignado |
| 4.12.0 (a1b2c3d) | `pl`                   | 3. Carrito con 2, 5 y 22 artículos | Safari, iPhone     | Formas polacas few y many                                    | Se muestra la forma `few` para 5 artículos            | Fallo: corregir las claves de plural                |
| 4.12.0 (a1b2c3d) | `ar`                   | 6. Configuración de la cuenta      | Chrome, Android    | Diseño en espejo, la flecha de retroceso apunta a la derecha | Según lo esperado                                     | Aprobado                                            |

## Related questions

- [¿Cómo encuentro cadenas codificadas de forma fija que no están traducidas?](https://generaltranslation.com/es/kb/find-hardcoded-strings.mdx): Ejecuta en CI un linter que marque los literales de cadena visibles para el usuario, como la regla no-literal-string de eslint-plugin-i18next para JSX, la comprobación HardcodedText de Android Lint o el linter HardCodedString de erb_lint para Rails. Después, recorre la app con una pseudoconfiguración regional para detectar el texto que las comprobaciones estáticas no pueden rastrear.
- [Buenas prácticas para el selector de idioma: UX, SEO y accesibilidad](https://generaltranslation.com/es/kb/language-switcher.mdx): Escribe el nombre de cada idioma en ese mismo idioma, como Deutsch o 日本語, y no uses banderas, que representan países. Enlaza cada opción a la misma página en ese idioma mediante un enlace rastreable, guarda la elección en una cookie y nunca redirijas automáticamente una URL localizada.
- [¿Qué es la pseudolocalización?](https://generaltranslation.com/es/kb/pseudo-localization.mdx): La pseudolocalización es una prueba que sustituye tu texto de origen por una versión alterada (con acentos, alrededor de un 40 % más larga y entre corchetes) para que las cadenas codificadas de forma fija, el truncamiento, las fuentes rotas y las oraciones concatenadas salgan a la luz antes de que exista ninguna traducción. Android incluye para ello las pseudoconfiguraciones regionales en-XA y ar-XB.
- [¿Cómo doy soporte a idiomas RTL (right-to-left) en CSS?](https://generaltranslation.com/es/kb/right-to-left-css.mdx): Coloca dir="rtl" y lang en el elemento html, ya que lang por sí solo no cambia la dirección, y luego sustituye el CSS físico, como margin-left, por propiedades lógicas, como margin-inline-start. Las filas flex, las columnas de grid y la alineación de texto predeterminada se invierten solas; translateX(), left y right, no.
- [¿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 con prefijo, como /en/about y /es/about, y luego publica html lang, una URL canónica autorreferente, versiones alternativas hreflang con x-default, un título y una descripción traducidos, y una entrada en el mapa del sitio para cada idioma publicado. Marca con noindex las versiones no publicadas. gt-next de General Translation dirige cada idioma a su propia URL y traduce los títulos con getGT.

## Previous and next questions

- Previous question: [General Translation vs. Weblate: ¿cuál deberías usar?](https://generaltranslation.com/es/kb/general-translation-vs-weblate.mdx)
- Next question: [¿Cómo debo nombrar las claves de traducción de i18n?](https://generaltranslation.com/es/kb/i18n-key-naming.mdx)

## Sitemap

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