i18n real en Next.js App Router con next-intl

Un hostal en el centro de Almería recibe turistas en español, inglés e italiano por igual. La web necesitaba tres idiomas reales, no un selector decorativo que traduce cuatro frases. next-intl con App Router resolvió esto sin reescribir la estructura de rutas a mano.

La estructura de rutas con locale

next-intl usa un segmento dinámico [locale] en la raíz de app/. Cada ruta vive una sola vez en el código; el locale se resuelve por middleware antes de renderizar. Esto evita la trampa clásica de tener app/en/precios/page.tsx y app/es/precios/page.tsx como archivos separados y sincronizados a mano.

Middleware de Edge para detectar idioma

El middleware de next-intl detecta el idioma preferido del navegador (Accept-Language), lo cruza con los idiomas soportados y redirige a la ruta con locale correcto. Corre en el Edge, así que la detección pasa antes de tocar el servidor de renderizado, sin coste de latencia perceptible.

Traducciones estructuradas, no strings sueltos

Cada idioma vive en un archivo JSON con namespaces por sección (hero, precios, contacto). El hook useTranslations('hero') en componentes cliente y getTranslations en Server Components acceden a esas claves con autocompletado si tipas el schema. Nada de strings hardcoded mezclados con el idioma por defecto.

Lo que se complica en producción

El SEO multi-idioma necesita hreflang correcto por página y un sitemap que liste cada locale como URL independiente. next-intl no lo hace solo: hay que generar esas etiquetas explícitamente en generateMetadata para cada ruta, cruzando el locale actual con los alternativos.

Conclusión

next-intl es la opción más madura para i18n real en App Router. La inversión inicial en estructurar el middleware y las traducciones por namespace se paga sola en cuanto el negocio recibe tráfico de más de un idioma — que, en zonas turísticas, es la norma y no la excepción.