Cómo se generan y resuelven las URL traducidas

POM Translate construye rutas localizadas a partir de tres partes separadas: la ruta base del sitio, un prefijo de locale cuando es necesario y segmentos de ruta específicos del idioma para el objeto de WordPress resuelto. Las URL no se traducen como frases ordinarias.

Cada locale configurado tiene un prefijo único

El prefijo estándar comienza con el código de idioma de dos letras del locale:

en_GB → en
fr_FR → fr

Cuando varios locales configurados comparten ese código, POM Translate usa un prefijo más específico basado en el locale para que las rutas sigan siendo inequívocas. Los prefijos se normalizan y se mantienen únicos.

Los idiomas adicionales siempre usan un prefijo. El idioma base usa uno solo cuando Use a subdirectory for the default language está habilitado.

Una ruta localizada puede contener varios segmentos traducidos

Según la ruta, POM Translate puede reconstruir:

• segmentos de jerarquía de entradas o páginas;
• una base de tipo de contenido personalizado;
• una base de archivo;
• bases de taxonomía;
• slugs de términos padre e hijo;
• el slug final de la entrada o del término;
• segmentos de sufijo admitidos, como la paginación.

Para una página jerárquica, traducir solo el slug hijo puede ser insuficiente. Su ruta de destino también puede depender de la ruta padre localizada.

Los slugs de origen siembran nuevos locales de destino

Cuando se guarda una entrada válida, POM Translate registra su slug de origen. Para cada locale adicional configurado sin un slug almacenado, el plugin inicializa una entrada de destino única a partir de ese slug de origen.

Esa semilla hace que la ruta sea resoluble antes de que un editor proporcione un slug localizado final. No es una prueba de que la URL haya sido traducida o aprobada.

Usa Translations → Translate URLs para revisar y guardar slugs específicos de cada locale.

La unicidad se aplica por contexto de enrutamiento

POM Translate comprueba los conflictos de slugs localizados y puede añadir un sufijo al inicializar o guardar un valor que de otro modo sería ambiguo. Una ruta debe probarse igualmente en su contexto completo porque las bases de WordPress, las rutas padre, las redirecciones y otro plugin de enrutamiento pueden afectar el resultado final.

No asumas que dos palabras finales idénticas entran en conflicto si pertenecen a bases válidas diferentes. A la inversa, dos etiquetas mostradas diferentes pueden seguir asignándose a la misma ruta.

Las rutas entrantes y salientes usan los mismos mapas

Para un enlace saliente, POM Translate comienza con la ruta de origen canónica, resuelve la entrada, el término o el archivo relacionado, reemplaza los segmentos admitidos por el locale de destino y añade el prefijo requerido.

Para una solicitud localizada entrante, realiza el trabajo inverso:

1. identifica el prefijo del locale;
2. lo elimina de la ruta usada para la resolución;
3. asigna las bases y los slugs localizados de vuelta a las variables de consulta canónicas;
4. deja que WordPress resuelva el objeto canónico;
5. muestra ese objeto en el locale seleccionado.

Este recorrido de ida y vuelta es la razón por la que una URL de destino puede mostrar contenido traducido sin un registro de entrada en el idioma de destino.

Las URL personalizadas tienen un diccionario separado

Los enlaces que se encuentran en el contenido admitido pueden apuntar a rutas internas que no son enlaces permanentes estándar de entradas o términos. POM Translate registra las apariciones de URL personalizadas válidas y deja que los editores las asignen por locale.

El traductor de contenido no debe reescribir estos destinos como prosa. Las asignaciones de URL tienen su propia normalización, validación e invalidación de caché.

Las cadenas de consulta y los fragmentos no son prosa

La generación de rutas localizadas trabaja sobre la ruta mientras conserva los sufijos admitidos, los valores de consulta y los fragmentos cuando corresponde. No traduzcas nombres de parámetros, tokens de seguridad, anclas ni datos de seguimiento en un campo de contenido.

Los endpoints especiales de WordPress y WooCommerce tienen un comportamiento de enrutamiento dedicado porque un segmento puede representar una clave o un valor de endpoint en lugar de un slug de entrada.

Verifica el recorrido de ida y vuelta de la ruta

Para una página anidada:

1. registra el enlace permanente de origen y el ID de entrada de WordPress;
2. guarda los slugs de destino para el padre y el hijo;
3. abre la URL de destino generada sin haber iniciado sesión;
4. confirma que muestra el mismo ID de entrada canónico;
5. inspecciona sus enlaces canónicos y de idiomas alternativos;
6. vuelve al idioma de origen y confirma que la ruta de origen se restaura;
7. sigue un enlace interno a la página desde otra entrada traducida;
8. confirma que el enlace saliente usa la misma ruta de destino;
9. prueba un slug en conflicto en un entorno de pruebas y verifica que la ruta guardada sigue siendo única.

Después de cambiar un slug público, actualiza deliberadamente las redirecciones, los sitemaps, las cachés de página y las copias de CDN. Una ruta nueva válida no retira las referencias externas a la antigua.