# General Translation Knowledge Base: ¿Cómo configuro el SEO de una aplicación de Next.js multilingüe? URL: https://generaltranslation.com/es/kb/multilingual-nextjs-seo.mdx Docs index: https://generaltranslation.com/llms.txt Description: 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. Category: SEO multilingüe Last updated: 2026-10-22 Authors: General Translation Team Published: 2026-02-17 El SEO multilingüe en Next.js consiste en dar a cada versión de idioma de una página su propia URL e indicar a los motores de búsqueda cómo se relacionan esas URL entre sí. Una página que elige su idioma a partir de una cookie o de la cabecera `Accept-Language` tiene una sola URL, por lo que los motores de búsqueda suelen indexarla en un único idioma. Cada versión de idioma debe cumplir los seis requisitos de esta tabla, y el enrutamiento, los metadatos y el mapa del sitio deben coincidir en la URL de cada idioma. | Requisito | Qué hace | Dónde se define en Next.js | | --------------------------------- | ----------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------- | | Una URL por idioma | Cada versión es una página independiente que se rastrea e indexa | Un segmento de ruta `[locale]` y un middleware de enrutamiento por configuración regional | | `` | Identifica el idioma de la página para los navegadores y las tecnologías de asistencia | El layout raíz, `app/[locale]/layout.tsx` | | URL canónica | Indica que esta URL es la versión preferida para su propio idioma, no un duplicado de otro idioma | `alternates.canonical` en `generateMetadata` | | Versiones alternativas `hreflang` | Todas las versiones de idioma publicadas de la página, incluida la actual, más una opción de respaldo `x-default` | `alternates.languages` en `generateMetadata` | | Título y descripción traducidos | El texto que suelen mostrar los resultados de búsqueda en ese idioma | `title` y `description` en `generateMetadata` | | Entrada en el mapa del sitio | Todas las URL de idioma publicadas de cada página | `app/sitemap.ts` | `gt-next` de General Translation dirige cada idioma a una URL como `/es/about` y traduce los títulos y las descripciones con [`getGT`](/docs/react/nextjs/reference/functions/get-gt). La URL canónica, las versiones alternativas `hreflang` y el mapa del sitio se generan con la [API de metadatos](https://nextjs.org/docs/app/api-reference/functions/generate-metadata#alternates) de Next.js. ## Video The video is narrated in English, with English captions. [How do I set up SEO for a multilingual Next.js app?](https://caxecubb9c64cezv.public.blob.vercel-storage.com/films/kb-multilingual-nextjs-seo.mp4) (50 s) General Translation lets you give every language its own URL and tell search engines about them. Move your pages into `app/[locale]` with `gt-next`'s middleware, set the html `lang` attribute with `useLocale`, add canonical and hreflang links with a helper, translate the title with `getGT`, and list every page in every language in a sitemap. ## ¿Por qué Google indexa solo un idioma de mi sitio de Next.js? Google indexa un solo idioma cuando todos los idiomas comparten la misma URL. Googlebot [envía solicitudes sin la cabecera `Accept-Language`](https://developers.google.com/search/docs/specialty/international/locale-adaptive-pages) y [no conserva las cookies entre cargas de página](https://developers.google.com/search/docs/crawling-indexing/javascript/fix-search-javascript), así que una página que elige su idioma a partir de cualquiera de las dos siempre le muestra a Google su idioma predeterminado. Los demás idiomas no tienen ninguna URL que Google pueda rastrear. La solución es tener una URL independiente para cada idioma, incluida en las versiones alternativas `hreflang` y en el mapa del sitio. Google [recomienda usar URL independientes para cada versión de idioma](https://developers.google.com/search/docs/specialty/international/managing-multi-regional-sites) en lugar de cookies o la configuración del navegador. Una aplicación de General Translation con `gt-next` sin middleware tiene el mismo problema: su selector de configuración regional guarda la elección en una cookie y mantiene las URL sin prefijo hasta que añades [`createNextMiddleware`](/docs/react/nextjs/reference/functions/create-next-middleware). Unas páginas en inglés y en francés completamente traducidas no se consideran duplicadas solo porque describan el mismo producto. Google trata las versiones localizadas como duplicadas únicamente cuando el contenido principal sigue sin traducir. (Consulta la [guía de Google sobre versiones localizadas](https://developers.google.com/search/docs/specialty/international/localized-versions)). ## ¿Las versiones por idioma deben usar subdirectorios, subdominios o dominios independientes? Usa subdirectorios, como `example.com/es/about`, a menos que cada mercado necesite su propia ubicación de servidor o su propio sitio. La guía de Google sobre [cómo gestionar sitios multirregionales y multilingües](https://developers.google.com/search/docs/specialty/international/managing-multi-regional-sites) describe los subdirectorios como fáciles de configurar y de bajo mantenimiento, ya que todos los idiomas se mantienen en un mismo host, y desaconseja los parámetros de URL. | Estructura | Ejemplo | Valoración de Google | En una aplicación de Next.js | | ---------------------- | --------------------------- | -------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Subdirectorios | `example.com/es/about` | Fácil de configurar, bajo mantenimiento (mismo host), una sola ubicación de servidor | El middleware `gt-next` de General Translation sirve esta estructura de forma predeterminada | | Subdominios | `es.example.com/about` | Fácil de configurar, permite distintas ubicaciones de servidor | Enrutamiento basado en host que debes implementar tú; [`createNextMiddleware`](/docs/react/nextjs/reference/functions/create-next-middleware) enruta según la ruta | | Dominios de país | `example.es/about` | Segmentación geográfica clara, pero costosos, requieren más infraestructura y se limitan a un país por dominio | Un despliegue o enrutamiento basado en host para cada dominio | | Parámetros de URL | `example.com/about?lang=es` | No recomendado | Evitar | | Solo cookie o cabecera | `example.com/about` | Se recomienda usar URL independientes | Se indexa en un solo idioma | Usa subdominios o dominios de país cuando los mercados necesiten alojamiento independiente o segmentación por país. Para un único despliegue de Next.js, los subdirectorios son la opción que menos código requiere: el middleware `gt-next` de General Translation sirve `/es/about` de forma predeterminada, mientras que los subdominios y los dominios de país necesitan un enrutamiento basado en host que debes implementar tú. (Consulta la [comparación de estructuras de URL](/kb/multilingual-url-structure) para conocer las ventajas y desventajas de cada opción). ## ¿Cómo asigno a cada idioma su propia URL en Next.js? Agrega un middleware de enrutamiento por configuración regional y un segmento de ruta `app/[locale]`. Con `gt-next` de General Translation, crea `proxy.ts` en la raíz del proyecto (`middleware.ts` en Next.js 15 y versiones anteriores): ```ts title="proxy.ts" import { createNextMiddleware } from 'gt-next/middleware'; export default createNextMiddleware({ prefixDefaultLocale: true }); export const config = { matcher: ['/((?!api|static|.*\\..*|_next).*)'], }; ``` Luego, mueve tus páginas dentro de `app/[locale]`: ```text proxy.ts app/ ├── sitemap.ts └── [locale]/ ├── layout.tsx ├── page.tsx └── about/ └── page.tsx ``` `prefixDefaultLocale: true` coloca todas las configuraciones regionales, incluido el inglés, bajo un prefijo, de modo que cada URL de contenido siempre sirve un único idioma. Este artículo usa esa configuración en todo momento. Una ruta sin prefijo como `/about` se convierte en un punto de entrada: el middleware responde con una redirección temporal `307` a la configuración regional guardada del visitante o a la que mejor coincida con `Accept-Language`, o bien a `/en/about` si no hay ninguna de las dos. Una URL localizada nunca cambia: `/en/about` devuelve la página en inglés incluso a un navegador que prefiera el francés. Sin esta opción, la configuración regional predeterminada no lleva prefijo y `/about` puede redirigir según la cookie o la cabecera del navegador. (Consulta [enrutamiento por configuración regional y SEO](/kb/locale-routing-seo) para saber por qué esto es importante). Hay otros dos ajustes que modifican el enrutamiento: * [`pathConfig`](/docs/react/nextjs/reference/functions/create-next-middleware#path-config) traduce las rutas; por ejemplo, `/fr/a-propos` para `/about`. * [`ignoreBrowserLocales: true`](/docs/react/nextjs/config#ignore-browser-locales) en `withGTConfig` impide que el middleware elija la configuración regional a partir de la cabecera `Accept-Language`. Google [desaconseja redirigir](https://developers.google.com/search/docs/specialty/international/managing-multi-regional-sites) a los visitantes en función de suposiciones sobre su idioma. Si prerrenderizas páginas con `generateStaticParams`, añade también `getLocale.ts` en la raíz del proyecto, ya que el middleware no se ejecuta durante la generación estática. En la [guía de middleware del App Router](/docs/react/nextjs/app-router-middleware#root-locale) encontrarás el archivo y todos los pasos de enrutamiento. ## ¿Cómo establezco el atributo lang de html para cada configuración regional? Establece `lang` a partir del parámetro de ruta `[locale]` en el layout raíz, `app/[locale]/layout.tsx`. Con la comprobación de [`isLocaleSupported`](/docs/react/nextjs/reference/functions/is-locale-supported), si una configuración regional no está definida en tu proyecto, esa URL devuelve un 404 en lugar de recurrir a la configuración regional predeterminada: ```tsx title="app/[locale]/layout.tsx" import { GTProvider, isLocaleSupported } from 'gt-next'; import { notFound } from 'next/navigation'; export default async function LocaleLayout({ children, params, }: { children: React.ReactNode; params: Promise<{ locale: string }>; }) { const { locale } = await params; if (!isLocaleSupported(locale)) { notFound(); } return ( {children} ); } ``` El atributo `lang` identifica el idioma de la página para las tecnologías de asistencia y para los comportamientos del navegador que dependen del idioma. Google determina el idioma a partir del [contenido visible](https://developers.google.com/search/docs/specialty/international/managing-multi-regional-sites#language), no del atributo `lang`, así que mantenlo correcto por motivos de accesibilidad y no como un factor de posicionamiento. El layout raíz debe ubicarse en `app/[locale]/layout.tsx` cuando las páginas se prerenderizan, ya que un layout situado por encima del segmento `[locale]` no puede leer la configuración regional durante la generación estática. Si un segmento de URL es un alias, como `/cn` para el chino, conviértelo con [`resolveCanonicalLocale`](/docs/react/nextjs/reference/functions/resolve-canonical-locale) para que `lang` sea `zh`. En [Gestión del SEO de alias de configuración regional](/docs/react/nextjs/locale-alias-seo) se explica cómo tratar los alias en los metadatos y en el mapa del sitio. ## ¿Cómo agrego enlaces alternativos hreflang y URL canónicas en el App Router de Next.js? En el App Router de Next.js, agrega enlaces alternativos `hreflang` devolviendo `alternates.languages` desde el `generateMetadata` de cada página, y la URL canónica devolviendo `alternates.canonical`. Next.js renderiza cada entrada de `alternates.languages` como una etiqueta ``. Google exige que [cada versión de idioma se incluya a sí misma y a todas las demás versiones](https://developers.google.com/search/docs/specialty/international/localized-versions), e ignora los enlaces `hreflang` que no estén declarados en ambas páginas, por lo que todas las versiones de una página deben devolver la misma lista. La entrada `x-default` es la URL para los visitantes cuyo idioma no coincide con ninguna de las versiones. La URL canónica de cada versión apunta a su propia URL; evita que las páginas traducidas apunten a la versión en inglés. Una URL canónica es una señal, no una garantía. (Consulta [etiquetas hreflang y canónicas](/kb/what-is-hreflang#should-hreflang-pages-use-self-referencing-canonicals)). Una traducción puede ir por detrás de su página, así que genera la URL canónica, las versiones alternativas y el mapa del sitio a partir de un único registro que indique en qué configuraciones regionales está publicada cada página. Esta función auxiliar construye la URL canónica y las versiones alternativas a partir de ese registro, y marca como `noindex` cualquier versión que aún no esté publicada: ```ts title="lib/i18n-metadata.ts" import type { Metadata } from 'next'; import { getLocale } from 'gt-next/server'; export const BASE_URL = 'https://example.com'; // Configuraciones regionales en las que se publica cada página. Añade una configuración regional cuando se haya revisado su traducción. export const PUBLISHED: Record = { '/': ['en', 'fr', 'es'], '/about': ['en', 'fr', 'es'], '/pricing': ['en', 'fr'], // El español aún no está traducido }; export const localeUrl = (locale: string, path: string) => `${BASE_URL}/${locale}${path === '/' ? '' : path}`; export async function getI18NMetadata(path: string): Promise { const locale = await getLocale(); const published = PUBLISHED[path] ?? []; // Excluye del índice las versiones no publicadas. if (!published.includes(locale)) { return { robots: { index: false }, alternates: null, }; } const languages: Record = {}; for (const loc of published) languages[loc] = localeUrl(loc, path); languages['x-default'] = localeUrl(published.includes('en') ? 'en' : published[0], path); return { alternates: { canonical: localeUrl(locale, path), languages } }; } ``` Luego, llámala desde cada página: ```tsx title="app/[locale]/pricing/page.tsx" import { getI18NMetadata } from '@/lib/i18n-metadata'; export async function generateMetadata() { return getI18NMetadata('/pricing'); } ``` Compilada con Next.js 16.4.2 y `gt-next` 11.4.14, la página `/fr/about`, publicada en los tres idiomas, renderizó este ``: ```html title="/fr/about" ``` `/fr/pricing` no incluye ningún enlace alternativo en español, porque la página de precios en español no está publicada: ```html title="/fr/pricing" ``` La ruta sigue respondiendo en `/es/pricing`, pero su `` solo incluye ``, sin URL canónica ni versiones alternativas, de modo que los rastreadores pueden descubrir la instrucción `noindex`. Establecer `alternates: null` elimina cualquier URL canónica o versión alternativa heredada de un layout padre. Mantén la ruta rastreable: `noindex` no es un mecanismo de control de acceso. `x-default` apunta al inglés si está publicado y, si no, a la primera configuración regional publicada. La función auxiliar asume la misma ruta en todas las configuraciones regionales; si usas rutas traducidas de `pathConfig`, slugs localizados o alias de rutas, construye la URL de cada configuración regional a partir de ese mapa de rutas, de forma que `fr` apunte a `/fr/a-propos`. Ofrece también un [selector de idioma](/kb/language-switcher) con enlaces normales a las páginas equivalentes. Hreflang no sustituye a una opción de navegación visible. ## ¿Cómo traduzco los títulos de página y las metadescripciones para cada configuración regional en Next.js? Traduce las cadenas que devuelve `generateMetadata`. Los resultados de búsqueda suelen mostrar el título y la descripción de una página, así que una página en español con un título en inglés mostrará texto en inglés en los resultados de búsqueda en español. Además, los motores de búsqueda pueden reescribir los títulos y fragmentos que muestran, por lo que los metadatos que proporcionas no garantizan una presentación exacta. La función [`getGT`](/docs/react/nextjs/reference/functions/get-gt) de General Translation, disponible en `gt-next/server`, devuelve una función de traducción para la configuración regional de la solicitud actual y funciona dentro de `generateMetadata`. Devuelve el título y la descripción traducidos junto con las versiones alternativas que genera la función auxiliar: ```tsx title="app/[locale]/about/page.tsx" import type { Metadata } from 'next'; import { getGT } from 'gt-next/server'; import { getI18NMetadata } from '@/lib/i18n-metadata'; export async function generateMetadata(): Promise { const gt = await getGT(); const i18nMeta = await getI18NMetadata('/about'); return { title: gt('About us'), description: gt('Meet the team that builds our product.'), ...i18nMeta, }; } ``` Pasa literales de cadena, como en el ejemplo anterior, para que el paso de compilación pueda detectarlos. Las traducciones de producción para [`getGT`](/docs/react/nextjs/reference/functions/get-gt) se generan antes del despliegue, así que ejecuta [`npx gt translate`](/docs/cli/reference/commands/translate) antes de `next build`: ```json title="package.json" { "scripts": { "build": "npx gt translate && next build" } } ``` Cuando cambia el título en inglés, la siguiente compilación traduce el nuevo texto a todas las configuraciones regionales, sin necesidad de actualizar archivos de mensajes. Revisa los títulos y las descripciones en el [editor del panel de control](/docs/platform/dashboard/guides/reviewing-translations) antes de añadir una configuración regional a `PUBLISHED`. Los [términos compartidos del glosario](/docs/platform/dashboard/guides/defining-context-for-translations) ayudan a mantener la coherencia de los nombres de producto entre la página y sus metadatos de búsqueda. Tras la publicación, mide las impresiones, los clics y las conversiones reales en lugar de dar por hecha una mejora fija en la tasa de clics. (Consulta [¿Cómo traduzco los títulos SEO y las metadescripciones?](/kb/translate-seo-metadata) para obtener información sobre las palabras clave por mercado, la longitud en distintos idiomas y las etiquetas Open Graph). ## ¿Cómo agrego todos los idiomas a un mapa del sitio de Next.js? Incluye en `app/sitemap.ts` una entrada por cada página y cada configuración regional publicada. Lee el mismo registro `PUBLISHED` para que el mapa del sitio y los enlaces `hreflang` siempre coincidan: ```ts title="app/sitemap.ts" import type { MetadataRoute } from 'next'; import { PUBLISHED, localeUrl } from '@/lib/i18n-metadata'; export default function sitemap(): MetadataRoute.Sitemap { return Object.entries(PUBLISHED).flatMap(([path, locales]) => locales.map((locale) => ({ url: localeUrl(locale, path) })), ); } ``` El `/sitemap.xml` generado incluía ocho URL: `/en`, `/fr`, `/es`, las tres versiones de `/about`, `/en/pricing` y `/fr/pricing`. `/es/pricing` queda fuera hasta que se publique. Si añades `lastModified`, usa la fecha en que el contenido de la página se actualizó de forma sustancial, no la hora en que se generó el mapa del sitio. (Consulta la [guía sobre mapas del sitio](https://developers.google.com/search/docs/crawling-indexing/sitemaps/build-sitemap) de Google). Como los metadatos de la página ya declaran `hreflang` en el HTML, este mapa del sitio solo enumera las URL. También puedes declarar `hreflang` en el mapa del sitio: asigna a cada entrada un mapa `alternates.languages`, que Next.js 14.2 y versiones posteriores convierten en versiones alternativas `xhtml:link` dentro de cada ``. Google trata [`hreflang` en un mapa del sitio](https://developers.google.com/search/docs/specialty/international/localized-versions) igual que `hreflang` en el HTML. Según Google, mantener ambos métodos no aporta ninguna ventaja adicional en la Búsqueda, así que elige uno. La [referencia de mapa del sitio](https://nextjs.org/docs/app/api-reference/file-conventions/metadata/sitemap#generate-a-localized-sitemap) de Next.js documenta el campo `alternates`. (Consulta [¿Cómo creo un mapa del sitio para un sitio web multilingüe?](/kb/multilingual-sitemap) para conocer los límites de tamaño, cómo dividirlo con un índice de mapas del sitio y qué comprobar antes de enviarlo). ## ¿Qué biblioteca de i18n para Next.js gestiona las rutas por configuración regional y hreflang para el SEO? Para el SEO, una biblioteca de i18n para Next.js tiene que dar a cada idioma su propia URL. `gt-next` de General Translation y next-intl lo hacen mediante middleware del App Router; i18next y react-intl dejan el enrutamiento en tus manos. El middleware de next-intl también envía las versiones alternativas `hreflang` en una cabecera HTTP, y `gt-next` traduce títulos y descripciones durante la compilación sin necesidad de archivos de mensajes. Ninguna de estas bibliotecas genera por ti la URL canónica ni el mapa del sitio. | Enfoque | URL por idioma | `hreflang` | Títulos y descripciones traducidos | URL canónica y mapa del sitio | | ---------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------- | | next-intl | Middleware con prefijos de configuración regional (`/en/about` de forma predeterminada), rutas localizadas o un dominio por configuración regional | El middleware [envía las versiones alternativas, incluida `x-default`, en una cabecera HTTP `Link`](https://next-intl.dev/docs/routing/configuration#alternate-links) de forma predeterminada | Mensajes que tu equipo o un servicio de traducción escribe en el catálogo JSON de cada idioma | Los escribes tú | | i18next o react-intl | Sin enrutamiento para Next.js; el middleware lo escribes tú | Los escribes tú | Mensajes en el catálogo de cada idioma | Los escribes tú | | Google Translate en el navegador del visitante | Una URL por página | Ninguno | Traducidos solo en el navegador; los resultados de búsqueda muestran el idioma de origen | Una sola URL, así que no hay nada que listar | | Una API de IA sin más (OpenAI API, Claude API) | Rutas que construyes tú | Los escribes tú | Un script que hay que volver a ejecutar tras cada cambio de texto | Los escribes tú | | General Translation (`gt-next` y la CLI `gt`) | [`createNextMiddleware`](/docs/react/nextjs/reference/functions/create-next-middleware) sirve `/en/about`, `/es/about` y rutas traducidas como `/fr/a-propos` | Devuelves `alternates.languages` desde `generateMetadata`, generado a partir de un registro de las configuraciones regionales publicadas | Cadenas de [`getGT`](/docs/react/nextjs/reference/functions/get-gt), traducidas por [`npx gt translate`](/docs/cli/reference/commands/translate) antes de `next build` | Los escribes en `generateMetadata` y `app/sitemap.ts` a partir del mismo registro | Usa next-intl si tu equipo ya mantiene catálogos de mensajes y quiere que `hreflang` se envíe desde el middleware. Usa i18next o react-intl si cuentas con traductores, textos que rara vez cambian y tiempo para implementar el enrutamiento. Usa la traducción en el navegador solo para páginas que no necesitan tráfico de búsqueda en otros idiomas, como una aplicación que requiere iniciar sesión y que los buscadores no pueden rastrear. Usa `gt-next` de General Translation si la aplicación publica textos nuevos con frecuencia y cada versión de idioma necesita su propia página indexada y su título traducido: los textos permanecen inline en tus componentes y la compilación traduce páginas y títulos a la vez. La plataforma y la documentación de Profound están disponibles en más de 47 configuraciones regionales gracias a General Translation. (Consulta [despliegues en producción](https://generaltranslation.com/enterprise)). ## Related questions - [Redirecciones de idioma y SEO: ¿URL, cookie o Accept-Language?](https://generaltranslation.com/es/kb/locale-routing-seo.mdx): Deja que la URL determine el idioma de cada página que quieras indexar, porque Googlebot no envía la cabecera Accept-Language y rastrea sobre todo desde direcciones de EE. UU. Recurre a la preferencia guardada en una cookie y, en su defecto, a Accept-Language solo para decidir adónde redirige una raíz neutral como /, mediante una redirección temporal 302 o 307. - [¿Qué es hreflang y cómo se configura?](https://generaltranslation.com/es/kb/what-is-hreflang.mdx): Hreflang le indica a Google qué URL son versiones de la misma página en otros idiomas o regiones, para que pueda mostrar la adecuada en los resultados de búsqueda. Agrégalo con etiquetas link de HTML, cabeceras HTTP Link o un mapa del sitio, asegúrate de que todos los enlaces sean recíprocos y usa códigos válidos como en-GB, no en-UK. - [Subdirectorio vs. subdominio vs. ccTLD para SEO multilingüe](https://generaltranslation.com/es/kb/multilingual-url-structure.mdx): Usa subdirectorios como example.com/de/ cuando un mismo producto comparte sitio y proceso de lanzamiento. Solo un ccTLD indica un país, los subdominios permiten un alojamiento independiente, Google desaconseja los parámetros ?lang= y trata los dominios personalizados como .io y .ai como genéricos. - [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. - [Lista de comprobación de pruebas de localización para aplicaciones multilingües](https://generaltranslation.com/es/kb/multilingual-app-launch-checklist.mdx): 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. ## Previous and next questions - Previous question: [¿Cómo traduzco texto condicional en JSX?](https://generaltranslation.com/es/kb/translate-conditional-jsx.mdx) - Next question: [¿Cuál es el mejor software de localización para desarrolladores?](https://generaltranslation.com/es/kb/best-localization-software.mdx) ## Sitemap See the [Knowledge Base sitemap](https://generaltranslation.com/es/kb/sitemap.md) for every article.