Gestión de contenido multilingüe en PHP: modelo y flujo editorial

Una aplicación multilingüe no consiste solo en traducir etiquetas de pantalla. Si también ofrece artículos, fichas de producto u otros recursos editoriales, debe representar qué idioma tiene cada contenido, cómo se relacionan sus versiones y qué significa que una traducción esté lista para publicar. Un modelo impreciso termina mostrando textos desactualizados, enlaces sin destino o borradores a usuarios que no deberían verlos.

Para planificar la gestión de contenido multilingüe en PHP, conviene separar las decisiones de interfaz, datos y flujo editorial. La implementación puede apoyarse en archivos de traducción para la interfaz y en la base de datos para el contenido variable, pero esa división debe responder al dominio y a las necesidades de quienes editan.

Separar idioma de interfaz, idioma original y traducción

El idioma de interfaz determina etiquetas, mensajes de validación, formatos de fecha y otros textos propios del producto. En una aplicación PHP puede gestionarse mediante catálogos de traducción, por ejemplo archivos organizados por locale, y seleccionarse a partir de una preferencia de usuario o de una configuración de sesión. No debería confundirse con el idioma del contenido que se consulta.

El idioma original, por su parte, identifica la lengua en que se creó un recurso editorial. Cada traducción es una versión asociada a ese recurso y tiene su propio idioma. Un usuario puede navegar por la interfaz en español y abrir una página cuyo contenido original está en inglés; la aplicación debe decidir explícitamente si eso está permitido y cómo informarlo.

Guarda códigos de idioma normalizados y aplica una política coherente para locales regionales cuando sea necesario. No supongas que idioma y país son intercambiables: una variante regional puede afectar al texto, pero también a formatos, disponibilidad o requisitos comerciales. Define qué locales admite el producto y cuáles se usan para resolver una preferencia incompleta.

Elegir un modelo de datos que represente el dominio

Hay tres patrones comunes, con compromisos distintos:

• Campos por idioma: columnas como title_es y title_en son sencillas cuando hay pocos idiomas, un conjunto estable de campos y consultas directas. Pierden flexibilidad al añadir idiomas y hacen que cada cambio de esquema dependa del catálogo de lenguas.
• Registros independientes: cada versión se guarda como un recurso separado. Puede ser apropiado si las versiones tienen ciclos de vida o estructuras realmente independientes, pero exige otra forma fiable de agruparlas. No uses un título parecido o una URL como vínculo implícito.
• Tabla de traducciones relacionada: un recurso común se asocia con una fila por idioma, por ejemplo mediante content_id y locale. Facilita añadir lenguas y consultar las versiones disponibles. Requiere restricciones que impidan duplicar una traducción del mismo idioma para un recurso.

La tabla relacionada suele encajar cuando las versiones comparten identidad y estructura, pero no es una regla universal. Si ciertos campos no se traducen —por ejemplo, una referencia interna— pueden permanecer en la entidad común; los campos editoriales localizados van en la traducción. Aclara también si una traducción puede tener una URL, metadatos de búsqueda o una fecha de publicación propios.

En la base de datos, define claves foráneas, unicidad por recurso e idioma y el comportamiento al eliminar datos. La lógica de aplicación en PHP debe validar además que el idioma esté admitido y que el recurso relacionado exista. Las restricciones de base de datos protegen frente a escrituras concurrentes y errores que una validación previa por sí sola no evita.

Relacionar versiones sin exigir que estén todas

No todos los recursos existirán en todos los idiomas, y no todas las traducciones se completarán al mismo tiempo. Modela esa realidad: la ausencia de una fila no debería interpretarse como un error de integridad si la traducción es opcional. En cambio, un estado editorial debe indicar qué ocurre cuando sí existe una fila, pero todavía no puede publicarse.

Evita duplicar en cada traducción información que pertenece al recurso compartido, salvo que el dominio requiera variaciones. Si las traducciones pueden desvincularse, trasladarse o conservarse como archivo, define esas operaciones y sus permisos. Para conocer el grupo de versiones, utiliza una relación estable, no coincidencias de texto, slug o fecha.

Cuando una traducción cambia, registra qué versión del original sirvió de referencia si el equipo necesita detectar contenido potencialmente desactualizado. Esa señal no demuestra por sí sola que la traducción sea incorrecta; permite priorizar una revisión. Para algunos productos bastará con una marca de revisión pendiente, mientras que otros necesitarán historial de versiones y auditoría.

Definir estados editoriales por idioma

El estado de publicación debe pertenecer a cada traducción cuando cada lengua puede redactarse, revisarse y publicarse de forma independiente. Un recurso puede estar publicado en un idioma y seguir en borrador en otro. Un único booleano de publicación a nivel de recurso no representa esa diferencia.

Diseña un flujo pequeño y explícito, por ejemplo borrador, en revisión y publicado. Define quién puede cambiar cada estado, qué campos son obligatorios y si una revisión requiere aprobación. La fecha de publicación, la persona responsable y el historial de cambios pueden ser necesarios para operar el proceso; evita añadir estados que no correspondan a acciones reales del equipo.

Las consultas públicas deben filtrar por estado e idioma, no confiar en que la interfaz editorial oculte las filas no publicadas. En PHP, concentra estas reglas en una capa de acceso al dominio o en consultas reutilizables, y prueba que controladores, API y tareas en segundo plano las respeten. Las acciones de edición y publicación también deben verificar permisos sobre el idioma y el recurso concretos.

Resolver ausencias, URLs y búsqueda de forma coherente

Si falta una traducción, hay varias políticas posibles. La aplicación puede ocultar el recurso en ese idioma, informar de que solo existe en otro, o mostrar un fallback. Elige según el tipo de contenido y el efecto sobre la experiencia; un fallback no debe presentarse como si fuera una traducción. Si se muestra contenido en otro idioma, indícalo claramente y conserva la posibilidad de volver a la versión solicitada.

Aplica una regla distinta para la interfaz y para el contenido. Que las etiquetas de navegación tengan fallback a otro catálogo no implica que los artículos deban sustituirse automáticamente por su versión original. El fallback editorial debe estar limitado a idiomas permitidos y a contenido publicable, y no debe devolver borradores.

Las URLs deben identificar una versión real o seguir una regla documentada de redirección. Al cambiar de idioma, busca la traducción del mismo recurso; si no existe, ofrece una salida explícita en lugar de construir una ruta que parezca válida. Para SEO, evita publicar páginas vacías o duplicadas por fallbacks invisibles. La búsqueda debe indexar únicamente versiones elegibles y usar el idioma correspondiente para filtrar y presentar resultados.

Lista de comprobación antes de publicar

• ¿La interfaz, el idioma original y el idioma de cada traducción son conceptos separados en el modelo?
• ¿Se impide guardar dos traducciones del mismo recurso en el mismo idioma?
• ¿Una traducción puede estar ausente sin crear un estado incoherente?
• ¿El equipo puede distinguir borrador, revisión y publicación por idioma?
• ¿Las rutas públicas y los enlaces de cambio de idioma comprueban que existe una versión visible?
• ¿El fallback está definido por caso de uso, se comunica al usuario y nunca expone borradores?
• ¿La búsqueda filtra por idioma y estado, y deja de indexar una versión retirada?
• ¿Se han probado permisos, edición concurrente, eliminación, contenido incompleto y cambios de idioma?

Prueba también la retirada de una traducción ya enlazada, la actualización del original después de publicar una versión y la petición directa de una URL no disponible. En cada caso, verifica la respuesta, la navegación y la visibilidad en búsqueda. El objetivo no es obligar a que todas las lenguas avancen al mismo ritmo, sino hacer que cada versión tenga una identidad, un estado verificable y un comportamiento predecible para editores y usuarios.