Configurar internacionalización en Next.js sin librerías pesadas es posible si entiendes cómo funciona el middleware y las rutas dinámicas. Aquí aprendes a detectar el idioma del usuario y redirigirlo a la versión correcta de tu aplicación usando solo Next.js, JavaScript y un par de utilidades de apoyo.

Esta guía es útil si construyes apps con audiencia global y quieres controlar la lógica de redirección por idioma sin depender de paquetes externos como next-intl o next-i18next.

Qué hace el middleware en Next.js y por qué importa para i18n

El middleware es una capa que se ejecuta entre el cliente y el backend. Intercepta cada request antes de que llegue a la página y te permite tomar decisiones según de dónde viene el usuario y hacia dónde va [01:54].

Para internacionalización, esto es oro. Puedes leer la URL, revisar los headers del navegador y redirigir al idioma correcto sin tocar el código de tus páginas.

¿Qué es el middleware en Next.js? Es una función que se ejecuta antes de renderizar una página y permite interceptar el request del usuario para modificarlo, redirigirlo o dejarlo pasar según tu lógica de negocio.

Cómo detectar el idioma del usuario con Accept-Language

Los navegadores envían un header HTTP llamado Accept-Language que indica los idiomas configurados en el sistema operativo del usuario. Tu servidor puede leerlo y decidir qué versión mostrar [05:24].

El valor llega como un string con formato específico del protocolo HTTP, separado por punto y coma. Hacer el parsing manual es posible, pero existen librerías especializadas que lo hacen mejor.

Qué librerías de apoyo usar

En la implementación se usan dos utilidades clave:

• Negotiator: librería de bajo nivel que extrae los idiomas aceptados desde el header Accept-Language y los devuelve como un array [05:55].
• Match de Format.js: encuentra la intersección entre los idiomas que pide el navegador, los que tu app soporta y un valor por defecto [06:08].
• Locales soportadas: en el ejemplo se trabaja con ES y EN, con español como idioma por defecto.

El resultado es que getLocal devuelve la mejor coincidencia posible para ese usuario.

Cómo construir la lógica de redirección en tres escenarios

La estrategia se divide en tres casos que el middleware debe resolver en orden. Cada uno responde a una pregunta distinta sobre el estado del request.

Escenario uno: ignorar rutas fuera del scope

Si la ruta no empieza con i18n, el middleware hace un return y deja pasar el request sin modificarlo. Esto se valida con request.nextUrl.pathname [02:54].

Así evitas que la lógica de internacionalización se aplique a páginas que no la necesitan.

Escenario dos: dejar pasar si ya hay un locale válido

Si la URL ya contiene /es o /en, no hay nada que hacer. Para validarlo se usa una utilidad llamada hasPathnameLocale ubicada en utils/i18n [03:31].

Esta función recibe el pathname y la lista de locales soportados, y devuelve true si alguno de los segmentos coincide. Si entra fr o pr, devuelve false porque no están en la configuración.

Escenario tres: detectar y redirigir cuando no hay locale

Si el usuario llega sin idioma en la URL, se llama a getLocal pasándole el header Accept-Language. Con el resultado se muta request.nextUrl.pathname concatenando el locale detectado [05:00].

Luego Next.js hace la redirección automática hacia la nueva URL.

¿Por qué mutar nextUrl en lugar de retornar una nueva URL? Porque Next.js detecta el cambio en el objeto y ejecuta la redirección con el nuevo pathname, manteniendo el resto de la información del request intacta.

Cómo probar la redirección por idioma en el navegador

La prueba más rápida es cambiar el idioma preferido en la configuración del navegador. Si tu navegador está en inglés, el middleware redirige a /en. Si lo cambias a español como prioridad, recargas y la redirección apunta a /es [07:12].

Esto demuestra que el flujo lee correctamente el header y aplica la decisión basada en la preferencia real del usuario.

Qué casos adicionales puedes resolver con este patrón

La misma estructura del middleware sirve para escenarios más complejos que no se cubrieron en el ejemplo base:

• Redirigir cuando el usuario ingresa un locale inválido a propósito.
• Manejar locales no soportados con un fallback al idioma por defecto.
• Aplicar lógica de negocio adicional como autenticación o feature flags.

El middleware te da control total sobre el request antes de que toque tu aplicación, y eso lo convierte en una herramienta clave para apps que escalan a múltiples regiones.

¿Has implementado i18n en Next.js de otra forma? Cuéntanos en los comentarios qué enfoque prefieres y por qué.