Operations · 8 jul 2026
Los estados de traducción deben responder a la siguiente pregunta
Un buen diseño de estados les dice a los editores qué terminó, qué está bloqueado y qué acción está disponible sin exponer la implementación del trabajador.
Los sistemas de traducción generan mucho estado. Los trabajos se ponen en cola, los proveedores responden, los borradores se guardan, Contentful se actualiza, las entradas se publican y los reintentos comienzan.
Mostrar toda esa actividad no hace automáticamente que el progreso sea claro.
Un estado útil debe responder a la siguiente pregunta que tiene el editor.
Una solicitud tiene varios ciclos de vida
Una solicitud multilingüe suele pasar por tres fases principales:
- traducir
- enviar
- publicar
Cada fase puede estar inactiva, en cola, en curso, ser exitosa, omitida o fallida. Comprimir esos estados en una sola palabra hace que se pierda información importante.
"Completado" podría significar que el borrador de traducción está listo para revisión, que la configuración regional de destino se escribió en Contentful o que la entrada está publicada. Esos son resultados sustancialmente diferentes.
La interfaz debe nombrar la fase y su estado juntos.
El estado y la acción van juntos
Los editores leen el estado para decidir qué pueden hacer a continuación.
- Una traducción lista puede revisarse.
- Una traducción aprobada puede enviarse.
- Un envío exitoso puede publicarse.
- Un fallo transitorio puede reintentarse.
- El trabajo activo puede poder cancelarse.
Si la acción disponible no coincide con el estado mostrado, el producto se siente inconsistente. Un botón de publicar junto a una solicitud que nunca se envió no es simplemente confuso; debilita la confianza en el flujo de trabajo subyacente.
El backend debe determinar la disponibilidad a partir del estado persistente y los permisos, y luego la UI debe reflejar esa decisión de manera consistente.
Los conteos de progreso necesitan un denominador estable
El progreso por lote se vuelve engañoso cuando cada fase usa un total diferente sin explicarlo.
Un lote con diez solicitudes de traducción puede tener diez traducciones, ocho envíos y seis publicaciones porque algunas configuraciones regionales eran solo para revisión o la automatización estaba deshabilitada.
El progreso debe distinguir entre:
- solicitudes totales
- solicitudes elegibles para la fase actual
- solicitudes completadas, activas, fallidas y omitidas
Omitidas es especialmente importante. Es una decisión terminal, no trabajo sin terminar.
Conservar el historial sin saturar la pantalla
El estado actual debe seguir siendo compacto, pero los operadores todavía necesitan historial cuando algo sale mal.
Una línea de tiempo de eventos expandible puede mostrar cuándo la solicitud se puso en cola, qué intento falló, si se ejecutó un reintento automático y cuándo Contentful aceptó la actualización. Eso facilita la depuración sin convertir cada fila de la tabla en un visor de registros.
Usa lenguaje humano para el estado principal y conserva los identificadores técnicos y las marcas de tiempo en la vista de detalle.
Los estados terminales deben seguir siendo terminales
Los eventos de sondeo y en tiempo real pueden llegar fuera de orden. Un evento anterior de "en curso" no debe hacer retroceder una solicitud completada. Una página actualizada no debe mostrar temporalmente "en cola" después de que la base de datos ya registró el éxito.
Las transiciones de estado necesitan orden e idempotencia. La interfaz debe fusionar las actualizaciones usando la marca de tiempo o versión autorizada, no simplemente aceptar el último mensaje entregado al navegador.
La conclusión
El diseño de estados es parte del flujo de trabajo, no una decoración a su alrededor.
Separa las fases de traducción, envío y publicación. Empareja cada estado con la acción que habilita, cuenta honestamente el trabajo omitido y mantén cerca un historial detallado. El mejor estado es el que hace clara la siguiente decisión.