Los conflictos de versión de Contentful deben reintentarse de forma segura

Contentful protege las entradas con bloqueo optimista. Cada actualización incluye la versión que el cliente cree que está editando. Si otro cambio se aplica primero, Contentful rechaza la actualización desactualizada en lugar de permitir que sobrescriba trabajo más reciente.

Ese conflicto es una función de seguridad. No debería convertirse en un callejón sin salida para la localización.

Por qué ocurren conflictos en equipos saludables

Una solicitud de traducción puede llevar tiempo. Mientras se genera o revisa, un editor puede corregir la entrada de origen, puede actualizarse otra configuración regional, o una automatización puede cambiar metadatos.

Para cuando el valor localizado está listo para enviarse, la versión de la entrada capturada antes ya está desactualizada.

Esto no significa que alguien haya cometido un error. Significa que varias partes del sistema de publicación están funcionando al mismo tiempo.

Nunca reintentes a ciegas la misma carga útil desactualizada

El reintento más simple repite la solicitud rechazada. Eso no puede tener éxito porque lleva la misma versión obsoleta.

La alternativa peligrosa obtiene el número de versión más reciente y reenvía toda la carga útil antigua de la entrada. Eso puede pasar la verificación de versión mientras sobrescribe campos modificados desde que comenzó la traducción.

Un reintento seguro necesita un estado actualizado y un parche limitado.

Volver a leer, fusionar y actualizar

Cuando Contentful informa un conflicto de versión, el flujo de trabajo debería:

1. obtener la entrada actual del mismo espacio y entorno
2. inspeccionar los campos y la versión más recientes
3. fusionar solo los valores aprobados de la configuración regional de destino de la solicitud de traducción
4. preservar los campos no relacionados y los valores de otras configuraciones regionales
5. enviar la actualización con la versión reciente

Esto mantiene el reintento alineado con la intención real del usuario. La solicitud de traducción quería cambiar campos localizados específicos, no restaurar una instantánea antigua de toda la entrada.

Decidir cuándo no reintentar

La recuperación automática de conflictos necesita límites.

Si el campo exacto de la configuración regional de destino cambió después de que comenzó la revisión, el sistema ha encontrado una colisión editorial real. Reintentar automáticamente podría reemplazar trabajo humano más reciente. Ese caso debería detenerse y pedir revisión.

Del mismo modo, los conflictos repetidos pueden indicar un bucle de automatización activo o una integración que escribe la entrada continuamente. Un número limitado de reintentos evita que la localización se una a ese bucle indefinidamente.

El error debe seguir siendo accionable: identificar la entrada, la configuración regional y los campos afectados, y la etapa en la que ocurrió la colisión.

Mantén clara la propiedad de origen y destino

El manejo de conflictos es más sencillo cuando el flujo de trabajo tiene un límite de escritura estricto. Los envíos de traducción deben cambiar solo las configuraciones regionales de destino aprobadas. No deben escribir campos de origen, metadatos del tipo de contenido, etiquetas ni valores de configuraciones regionales no relacionadas.

Ese límite reduce la complejidad de la fusión y hace que los registros de auditoría sean significativos. Cuando un reintento tiene éxito, el equipo puede ver exactamente qué campos localizados cambiaron y por qué.

La conclusión

Los conflictos de versión son normales en un CMS colaborativo. Tratar cada conflicto como una traducción fallida hace que el flujo de trabajo parezca frágil; ignorar el conflicto lo hace inseguro.

Obtén la entrada más reciente, fusiona el cambio aprobado más pequeño y reintenta dentro de límites claros. Cuando el mismo campo cambió en ambos lados, detente para una revisión humana. La confiabilidad proviene de respetar el trabajo concurrente, no de fingir que no ocurre.