Realtime Translation Updates Should Be Useful, Not Required

Watching a translation move from queued to working to ready is useful. Teams can see progress without refreshing, open completed work quickly, and notice a failed request while the release is still active.

But live updates are a presentation capability. They should not be the mechanism that makes the workflow correct.

Durable state comes first

The database and job system should own translation state. Every phase transition needs to be recorded whether or not a browser is connected:

• request queued
• translation started and completed
• push started and completed
• publish started and completed
• failure and retry events

A realtime event can announce that durable change. It should not be the only record that the change occurred.

This distinction protects users who close the tab, lose network access, or work in an environment where websocket infrastructure is disabled.

Realtime has an operational cost

Broadcasting introduces more moving parts: a websocket service, connection authorization, channel configuration, proxy support, and browser reconnect behavior.

For teams that need live coordination, that cost can be worthwhile. For a smaller deployment, ordinary polling may be simpler and entirely adequate.

Making realtime opt in lets each environment choose the operational profile it can support without losing core translation behavior.

Design a graceful fallback

The UI should reach the same final state through realtime events or periodic refresh.

A practical approach is:

1. load the current durable state
2. subscribe to relevant events when realtime is enabled
3. merge incoming updates by request ID and version
4. poll at a modest interval while active work remains
5. stop frequent polling when the batch reaches a terminal state

Realtime makes the screen feel immediate. Polling closes gaps after reconnects and provides a fallback.

The two paths should not create competing status rules.

Avoid turning updates into noise

Not every internal event belongs in the interface. Broadcasting every token, worker heartbeat, or intermediate save can make the page unstable and increase infrastructure load.

Users usually need meaningful phase transitions and updated counts. Grouping rapid low-level changes into a smaller set of durable milestones keeps the experience calm and scannable.

The same principle applies to notifications. A completed batch may deserve attention. Every completed locale probably does not.

Test the quiet path

It is easy to test with realtime enabled and assume the fallback works. Reliability requires the opposite exercise:

• disable broadcasting
• start a multi-locale batch
• leave and return to the page
• confirm progress catches up
• retry a failed request
• verify the final counts and available actions

If that path works, realtime is an enhancement instead of a hidden dependency.

The takeaway

Live updates improve translation operations when they sit on top of durable state.

Record every transition first, make broadcasting configurable, and keep a measured polling fallback. The workflow should remain trustworthy even when the most immediate delivery channel is unavailable.