Cómo selecciona POM Translate el idioma activo
El idioma activo es un contexto de solicitud. POM Translate lo determina antes de que se muestren el contenido localizado, las URL, los menús, los metadatos SEO o las respuestas dinámicas compatibles.
El locale de origen proviene de WordPress
El idioma principal sigue a Settings → General → Site Language. Los locales adicionales se configuran en Settings → POM Translate → Languages setup.
Cambiar el idioma del sitio WordPress es, por tanto, una decisión sobre el idioma de origen, no solo una preferencia de la interfaz de administración. Revisa las traducciones y rutas existentes antes de cambiarlo en un sitio multilingüe que ya tenga contenido.
La ruta pública es la autoridad
En una solicitud normal de frontend, POM Translate inspecciona primero la URL:
- Un prefijo de locale reconocido selecciona ese locale y lo guarda como la preferencia del visitante.
- Una ruta sin prefijo reconocido empieza en el locale base.
- Si el locale base está configurado para usar un prefijo, una ruta apta sin prefijo redirige a su equivalente con prefijo.
Un visitante que abra /fr/menu/ debería, por tanto, permanecer en francés incluso si una preferencia guardada o una cabecera del navegador sugiere otro idioma configurado.
Solo se aceptan los locales configurados. Los prefijos desconocidos no crean un nuevo locale activo.
La selección por URL y la redirección por navegador son distintas
POM Translate puede detectar un idioma a partir de la ruta actual sin forzar a cada visitante que llega por primera vez a una ruta coincidente con su navegador.
El ajuste Browser language detection controla una redirección opcional para las rutas aptas sin prefijo. Cuando está habilitado, POM Translate comprueba primero una preferencia guardada válida, después las preferencias Accept-Language del navegador y, por último, la alternativa de navegador configurada. Los resultados no compatibles recurren al locale base.
Mantén desactivada la detección por navegador mientras validas las URL deterministas de origen y destino. Cuando la actives, prueba por separado las primeras visitas, las preferencias existentes, los bots, las rutas similares a la raíz y las solicitudes excluidas.
La detección por navegador no debería anular un prefijo de locale explícito.
La administración permanece en el contexto de contenido base
Las solicitudes normales de administración de WordPress usan el locale base para el contexto de contenido de POM Translate. Esto evita que una cookie de visitante o una ruta pública hagan que el editor de origen se comporte como si estuviera editando contenido traducido.
Los editores siguen eligiendo un locale de destino explícitamente dentro de Translations.
Las solicitudes dinámicas necesitan una señal de idioma permitida
Las llamadas AJAX y REST no siempre incluyen la ruta visible de la página de la misma forma que el documento del navegador. POM Translate gestiona las solicitudes compatibles mediante una lógica de contexto dedicada:
- las solicitudes AJAX aptas de frontend pueden establecer un locale de destino normalizado;
- las rutas REST incluidas en la lista permitida pueden usar su contexto de solicitud para seleccionar un locale;
- las solicitudes AJAX de WooCommerce y de la Store API tienen una gestión de locale adicional;
- los contextos no compatibles, de administración, cron, línea de comandos, sitemap y otros contextos excluidos permanecen fuera de la localización normal del frontend.
Una integración debería pasar una de las señales de idioma compatibles del plugin en lugar de confiar en la cookie que esté presente en ese momento.
El contexto del correo puede sobrevivir a la solicitud del navegador
El renderizado de correos de WooCommerce puede ocurrir más tarde o fuera de la página de pago original. POM Translate registra y restaura el locale del pedido mediante la integración de WooCommerce para que los asuntos, encabezados, valores del cuerpo, datos de los artículos y enlaces de cuenta puedan usar el idioma previsto.
El idioma del navegador del administrador actual no debe determinar el locale del correo de un cliente.
El contexto debe restaurarse
Las anulaciones temporales de locale para el trabajo compatible con AJAX, Store API, vista previa o correo están limitadas a esa operación y se restauran después. Esto evita que una operación traducida filtre su idioma a un trabajo no relacionado durante el mismo proceso.
Verifica la precedencia de forma deliberada
Usa una ruta de origen y una ruta de destino configurada:
- desactiva la detección de idioma por navegador;
- abre la ruta de origen en una ventana privada y confirma el idioma base;
- abre la ruta de destino con prefijo y confirma el idioma de destino;
- cambia de idioma mediante un selector y confirma que la URL de destino lleva la elección;
- recarga ambas rutas explícitas y verifica que cada una se mantiene estable;
- activa la detección por navegador en el entorno de pruebas;
- inicia una nueva sesión privada con una preferencia de navegador coincidente;
- confirma que solo la primera visita apta sigue el comportamiento de redirección configurado;
- vuelve a abrir una ruta explícita de origen o destino y confirma que la URL sigue siendo la autoridad.
Si el contenido, el estado del selector, la URL canónica y el idioma del documento no coinciden, diagnostica el contexto del idioma activo antes de editar las traducciones.