Reliability · 1 jul 2026
Las actualizaciones de traducción en tiempo real deben ser útiles, no obligatorias
El estado en vivo es valioso, pero las operaciones de traducción deben seguir siendo correctas cuando la infraestructura en tiempo real no está disponible o está deshabilitada intencionalmente.
Ver cómo una traducción pasa de en cola a en proceso a lista es útil. Los equipos pueden ver el progreso sin actualizar, abrir rápidamente el trabajo completado y notar una solicitud fallida mientras la publicación sigue activa.
Pero las actualizaciones en vivo son una capacidad de presentación. No deben ser el mecanismo que hace que el flujo de trabajo sea correcto.
El estado duradero va primero
La base de datos y el sistema de trabajos deben ser los responsables del estado de la traducción. Cada transición de fase debe registrarse haya o no un navegador conectado:
- solicitud en cola
- traducción iniciada y completada
- envío iniciado y completado
- publicación iniciada y completada
- eventos de fallo y reintento
Un evento en tiempo real puede anunciar ese cambio duradero. No debe ser el único registro de que el cambio ocurrió.
Esta distinción protege a los usuarios que cierran la pestaña, pierden acceso a la red o trabajan en un entorno donde la infraestructura de websocket está deshabilitada.
El tiempo real tiene un costo operativo
La difusión introduce más partes móviles: un servicio de websocket, autorización de conexión, configuración de canales, soporte de proxy y comportamiento de reconexión del navegador.
Para los equipos que necesitan coordinación en vivo, ese costo puede valer la pena. Para una implementación más pequeña, el sondeo normal puede ser más simple y totalmente adecuado.
Hacer que el tiempo real sea opcional permite que cada entorno elija el perfil operativo que puede soportar sin perder el comportamiento central de la traducción.
Diseña una alternativa elegante
La interfaz debe llegar al mismo estado final mediante eventos en tiempo real o actualización periódica.
Un enfoque práctico es:
- cargar el estado duradero actual
- suscribirse a los eventos relevantes cuando el tiempo real esté habilitado
- combinar las actualizaciones entrantes por ID de solicitud y versión
- sondear a un intervalo moderado mientras siga habiendo trabajo activo
- detener el sondeo frecuente cuando el lote alcance un estado terminal
El tiempo real hace que la pantalla se sienta inmediata. El sondeo cierra brechas después de reconexiones y proporciona una alternativa.
Las dos rutas no deben crear reglas de estado en competencia.
Evita convertir las actualizaciones en ruido
No todos los eventos internos pertenecen a la interfaz. Difundir cada token, latido del worker o guardado intermedio puede hacer que la página sea inestable y aumentar la carga de la infraestructura.
Los usuarios normalmente necesitan transiciones de fase significativas y conteos actualizados. Agrupar cambios rápidos de bajo nivel en un conjunto más pequeño de hitos duraderos mantiene la experiencia tranquila y fácil de revisar.
El mismo principio se aplica a las notificaciones. Un lote completado puede merecer atención. Probablemente no cada configuración regional completada.
Prueba la ruta silenciosa
Es fácil probar con el tiempo real habilitado y asumir que la alternativa funciona. La fiabilidad requiere el ejercicio contrario:
- deshabilitar la difusión
- iniciar un lote multirregional
- salir y volver a la página
- confirmar que el progreso se actualiza
- reintentar una solicitud fallida
- verificar los conteos finales y las acciones disponibles
Si esa ruta funciona, el tiempo real es una mejora en lugar de una dependencia oculta.
La conclusión
Las actualizaciones en vivo mejoran las operaciones de traducción cuando se apoyan sobre un estado duradero.
Registra primero cada transición, haz que la difusión sea configurable y mantén una alternativa de sondeo mesurada. El flujo de trabajo debe seguir siendo confiable incluso cuando el canal de entrega más inmediato no esté disponible.