How can a professional translator explain Server-Sent Events without confusing a browser’s EventSource reconnection with guaranteed recovery of lost information? This guide covers the text/event-stream format, data and event fields, event IDs, retry delays, the Last-Event-ID request header, named events and the distinction between a stream connection and a durable event log. It is for readers searching for SSE examples, EventSource reconnect behavior, last event ID semantics, HTTP 204 stopping reconnection and multilingual real-time interface documentation.
Server-Sent Events, usually called SSE, allow a server to push a stream of text events to a client through HTTP. The browser EventSource interface handles the stream, parses events and can reconnect under the HTML Standard’s rules. Yet the standard does not promise that an application’s server will store every missed message or interpret an event ID as a database position. Translation must preserve exact field names and syntax while explaining which recovery guarantees the particular application has actually built.
Imagine a worldwide public library streaming lecture captions, queue announcements and booking updates to visitors in several languages. A librarian closes a page while walking between rooms; a visitor’s phone loses mobile reception; an accessibility reader receives delayed captions. A clear guide can explain when the browser may reconnect, how the id field is used, and why a gap in updates still needs an application-level policy. It must not promise that every reconnection reconstructs the entire past.
Quick answer: separate the visible words from the event-stream grammar
The quick rule: localize explanatory prose, accessible interface labels and appropriate human-facing data fields. Keep the event-stream parser field names data, event, id and retry; preserve the event type tokens and identifier semantics expected by applications.
EventSource is a client API for receiving events, not a general bidirectional socket. Use a separate request mechanism to submit data back to the server unless the application specifies an alternative. The EventSource readyState says something about connection state, not whether a booking was completed.
Last-Event-ID can help a reconnecting client tell a server what ID it last saw. Replay only happens if the server has retained data and implements the appropriate resumption logic. An ID header is evidence of a cursor request, not proof of recovered records.
The stream’s low-level structure matters. A blank line dispatches accumulated data, repeated data lines join with newline characters, comment lines are ignored, and retry carries a numeric reconnection delay in milliseconds. A formatting translation can quietly change parser behavior.
How a live library stream should be understood
A browser may be connected, a particular event may be dispatched, an application may be caught up with the latest stored event, or a business transaction may be confirmed. These are four different claims. An SSE article that uses one attractive word such as ‘synchronized’ for all four does not help a developer debug a missing notice or a visitor understand a pending request.
Reading order for this guide
Start with transport and parsing, then examine id and retry behavior, connection lifecycle, security and real-world reliability. Every section gives a contract meaning, an example, a misleading interpretation to avoid and a check. Remember that the HTML Standard defines the browser interface and event parser; application persistence and recovery are separate design decisions.
1. SSE as one-way server push
Server-Sent Events provide a convenient way for an HTTP server to send a sequence of event updates to a client. They do not themselves define an upstream client-to-server message channel.
Imagine a realistic implementation. A museum sends exhibition-room availability updates while the browser makes ordinary HTTP requests to reserve a ticket. For an international reader the sentence needs to identify the wire-level fact, the browser behavior and the application behavior without collapsing them into one assumption.
The translation pitfall is specific: Describing SSE as a full-duplex chat protocol can prompt developers to search for a send method that the native EventSource API does not provide. A page can sound perfectly fluent and still teach a copied sample that no longer parses, or a guarantee that the application never made.
A useful acceptance step is: Explain what moves from server to browser, and name the separate operation used for user commands or booking requests. When the observed browser events disagree with the translated explanation, revise the explanation rather than changing the protocol to make the prose seem right.
2. The EventSource interface
A browser creates an EventSource object for a stream URL and registers message or named-event listeners. The connection lifecycle is managed by the user agent under standard rules.
Imagine a realistic implementation. An online library page subscribes to /updates/events and listens for upcoming lecture changes. For an international reader the sentence needs to identify the wire-level fact, the browser behavior and the application behavior without collapsing them into one assumption.
The translation pitfall is specific: A translation that calls EventSource a persistent database queue treats a browser API as infrastructure it does not supply. A page can sound perfectly fluent and still teach a copied sample that no longer parses, or a guarantee that the application never made.
A useful acceptance step is: Show the constructor, endpoint and listener roles without claiming a specific server-side storage design. When the observed browser events disagree with the translated explanation, revise the explanation rather than changing the protocol to make the prose seem right.
3. The text/event-stream MIME type
The event stream response is identified using text/event-stream, which tells the browser to process the response using SSE parsing rules.
Imagine a realistic implementation. A server responds to /events with Content-Type: text/event-stream and streams event lines over time. For an international reader the sentence needs to identify the wire-level fact, the browser behavior and the application behavior without collapsing them into one assumption.
The translation pitfall is specific: Replacing the MIME type with a translated sentence or ordinary text/plain can prevent correct native parsing. A page can sound perfectly fluent and still teach a copied sample that no longer parses, or a guarantee that the application never made.
A useful acceptance step is: Keep the MIME token literal and verify the actual response headers used by the application. When the observed browser events disagree with the translated explanation, revise the explanation rather than changing the protocol to make the prose seem right.
4. UTF-8 is the stream encoding
The HTML Standard requires event streams to be decoded as UTF-8. An application can place multilingual text in data fields, but it must preserve the wire encoding.
Imagine a realistic implementation. A public archive streams Arabic, Japanese and English captions in one standards-conforming UTF-8 event stream. For an international reader the sentence needs to identify the wire-level fact, the browser behavior and the application behavior without collapsing them into one assumption.
The translation pitfall is specific: Translating the example into another character encoding without checking the byte stream can corrupt names and punctuation. A page can sound perfectly fluent and still teach a copied sample that no longer parses, or a guarantee that the application never made.
A useful acceptance step is: Test non-Latin scripts, combining marks and right-to-left text using actual streamed bytes, not only a copy of the page. When the observed browser events disagree with the translated explanation, revise the explanation rather than changing the protocol to make the prose seem right.
5. The data field
A line beginning data: contributes text to an event’s data buffer. The data may hold prose, JSON or another application format agreed between producer and consumer.
Imagine a realistic implementation. A library sends data: The reading room opens at ten, which appears in the browser’s message handler. For an international reader the sentence needs to identify the wire-level fact, the browser behavior and the application behavior without collapsing them into one assumption.
The translation pitfall is specific: Changing the literal field name data into a local-language synonym causes the parser to ignore it. A page can sound perfectly fluent and still teach a copied sample that no longer parses, or a guarantee that the application never made.
A useful acceptance step is: Keep the parser key unchanged and translate only human-facing content inside the data value when appropriate. When the observed browser events disagree with the translated explanation, revise the explanation rather than changing the protocol to make the prose seem right.
6. Multiline data
Multiple data lines in the same event are combined with newline separators before dispatch. The browser does not treat every data line as a separate event.
Imagine a realistic implementation. A lecture caption contains two paragraphs and the server emits them as consecutive data lines followed by a blank line. For an international reader the sentence needs to identify the wire-level fact, the browser behavior and the application behavior without collapsing them into one assumption.
The translation pitfall is specific: A localization that inserts a blank line between paragraphs may prematurely dispatch two events instead of one. A page can sound perfectly fluent and still teach a copied sample that no longer parses, or a guarantee that the application never made.
A useful acceptance step is: Validate the exact line layout of the translated stream and inspect what event.data delivers to a real client. When the observed browser events disagree with the translated explanation, revise the explanation rather than changing the protocol to make the prose seem right.
7. Blank lines are event boundaries
A blank line triggers the dispatch algorithm for a pending event when data has been accumulated. Line breaks therefore have structural significance beyond page formatting.
Imagine a realistic implementation. A demonstration stream contains data: welcome followed by an empty line, which dispatches the event. For an international reader the sentence needs to identify the wire-level fact, the browser behavior and the application behavior without collapsing them into one assumption.
The translation pitfall is specific: A translated code sample that removes the separating blank line may leave a reader waiting for a message that never arrives. A page can sound perfectly fluent and still teach a copied sample that no longer parses, or a guarantee that the application never made.
A useful acceptance step is: Keep code blocks structurally exact and test both common line-ending forms accepted by the parsing model. When the observed browser events disagree with the translated explanation, revise the explanation rather than changing the protocol to make the prose seem right.
8. End of stream is not always a dispatch
A pending final event block without a terminating blank line is not automatically dispatched merely because the transport stream ends.
Imagine a realistic implementation. A museum server writes a last data line but closes the connection without completing the event separator. For an international reader the sentence needs to identify the wire-level fact, the browser behavior and the application behavior without collapsing them into one assumption.
The translation pitfall is specific: A tutorial that implies every final line becomes a delivered message can misdiagnose missing last updates. A page can sound perfectly fluent and still teach a copied sample that no longer parses, or a guarantee that the application never made.
A useful acceptance step is: Test the final blank-line boundary and distinguish what was written by the server from what the browser dispatched. When the observed browser events disagree with the translated explanation, revise the explanation rather than changing the protocol to make the prose seem right.
9. Named events
The event: field changes the event type from the default message to a specified name that client listeners subscribe to.
Imagine a realistic implementation. The application emits event: room.changed and the page uses addEventListener for that exact event name. For an international reader the sentence needs to identify the wire-level fact, the browser behavior and the application behavior without collapsing them into one assumption.
The translation pitfall is specific: Translating room.changed inside a sample stream while leaving the listener unchanged silently breaks event routing. A page can sound perfectly fluent and still teach a copied sample that no longer parses, or a guarantee that the application never made.
A useful acceptance step is: Maintain event-type tokens exactly and localize their human explanations separately. When the observed browser events disagree with the translated explanation, revise the explanation rather than changing the protocol to make the prose seem right.
10. Default message events
When an event has no custom event type, the standard dispatches it as a message event, which an onmessage handler can receive.
Imagine a realistic implementation. A simple public weather display streams unnamed updates consumed by source.onmessage. For an international reader the sentence needs to identify the wire-level fact, the browser behavior and the application behavior without collapsing them into one assumption.
The translation pitfall is specific: Explaining every SSE event as a custom named event may cause examples to attach the wrong listener. A page can sound perfectly fluent and still teach a copied sample that no longer parses, or a guarantee that the application never made.
A useful acceptance step is: Show a default message example beside a named event example and verify handler registration. When the observed browser events disagree with the translated explanation, revise the explanation rather than changing the protocol to make the prose seem right.
11. The id field
The id: field updates the event source’s last event ID string when the value is acceptable under parsing rules. It is an identifier supplied by the stream, not a universal sequence number format.
Imagine a realistic implementation. A lecture stream uses id: captions-0028 for one caption update, then id: captions-0029 for the next. For an international reader the sentence needs to identify the wire-level fact, the browser behavior and the application behavior without collapsing them into one assumption.
The translation pitfall is specific: A translation that automatically converts these opaque tokens into local numerals can break exact cursor matching on reconnection. A page can sound perfectly fluent and still teach a copied sample that no longer parses, or a guarantee that the application never made.
A useful acceptance step is: Keep opaque IDs exact and document which component assigns them and whether they map to durable storage. When the observed browser events disagree with the translated explanation, revise the explanation rather than changing the protocol to make the prose seem right.
12. The Last-Event-ID request header
When reconnecting and the stored last event ID is not empty, a browser can include Last-Event-ID in its request to indicate the last ID seen.
Imagine a realistic implementation. After a mobile network interruption, the reconnecting client sends Last-Event-ID: captions-0029 to the library server. For an international reader the sentence needs to identify the wire-level fact, the browser behavior and the application behavior without collapsing them into one assumption.
The translation pitfall is specific: Saying this header guarantees the server will resend captions-0030 onward invents replay support the HTML Standard does not require. A page can sound perfectly fluent and still teach a copied sample that no longer parses, or a guarantee that the application never made.
A useful acceptance step is: Explain the header’s meaning and separately document the server’s actual replay and retention behavior. When the observed browser events disagree with the translated explanation, revise the explanation rather than changing the protocol to make the prose seem right.
13. Empty id resets the cursor
An id field with no value can reset the EventSource last event ID string to empty; after that, a reconnect may omit Last-Event-ID.
Imagine a realistic implementation. A system intentionally clears a resumable cursor before switching a visitor to a new lecture session. For an international reader the sentence needs to identify the wire-level fact, the browser behavior and the application behavior without collapsing them into one assumption.
The translation pitfall is specific: A translator who removes the empty id line as ‘unnecessary whitespace’ changes the reconnect request’s meaning. A page can sound perfectly fluent and still teach a copied sample that no longer parses, or a guarantee that the application never made.
A useful acceptance step is: Keep syntactically significant empty fields intact and verify the browser’s resulting last event ID. When the observed browser events disagree with the translated explanation, revise the explanation rather than changing the protocol to make the prose seem right.
14. Invalid id content
The standard ignores an id value containing a NULL character; the value space and parser conditions are not free-form human copy rules.
Imagine a realistic implementation. A malformed test record includes a prohibited control character in its id field. For an international reader the sentence needs to identify the wire-level fact, the browser behavior and the application behavior without collapsing them into one assumption.
The translation pitfall is specific: Saying IDs can contain any arbitrary text encourages broken or ambiguous cursor values. A page can sound perfectly fluent and still teach a copied sample that no longer parses, or a guarantee that the application never made.
A useful acceptance step is: Keep control-character rules exact and choose an application ID format that can be tested and safely logged. When the observed browser events disagree with the translated explanation, revise the explanation rather than changing the protocol to make the prose seem right.
15. The retry field
The retry: field sets the reconnection time when its value consists only of ASCII digits; the number represents milliseconds, not seconds.
Imagine a realistic implementation. A server includes retry: 5000 to suggest a five-second reconnection delay under the standard parsing model. For an international reader the sentence needs to identify the wire-level fact, the browser behavior and the application behavior without collapsing them into one assumption.
The translation pitfall is specific: Converting the field to retry: 5 because prose says ‘five seconds’ changes the intended interval by a factor of one thousand. A page can sound perfectly fluent and still teach a copied sample that no longer parses, or a guarantee that the application never made.
A useful acceptance step is: Leave the numeric field and parser token untouched, while displaying a localized human explanation of its units. When the observed browser events disagree with the translated explanation, revise the explanation rather than changing the protocol to make the prose seem right.
16. Invalid retry values are ignored
If the retry value does not follow the required ASCII digit form, the parser ignores it. Locale-specific number formatting can therefore be hazardous in executable examples.
Imagine a realistic implementation. A translated page uses retry: 5,000 or retry: ５０００ and assumes either string is equivalent to 5000. For an international reader the sentence needs to identify the wire-level fact, the browser behavior and the application behavior without collapsing them into one assumption.
The translation pitfall is specific: A reader who copies the sample may see different reconnection behavior because the instruction was no longer a valid retry value. A page can sound perfectly fluent and still teach a copied sample that no longer parses, or a guarantee that the application never made.
A useful acceptance step is: Use the exact ASCII digits in wire samples and keep friendly local number formatting outside the protocol block. When the observed browser events disagree with the translated explanation, revise the explanation rather than changing the protocol to make the prose seem right.
17. Comment lines beginning with a colon
A colon at the start of a stream line denotes a comment; it is not dispatched as an application event. Servers often use comments to keep a connection active.
Imagine a realistic implementation. A lecture stream sends : keepalive between two caption events to maintain intermediary activity. For an international reader the sentence needs to identify the wire-level fact, the browser behavior and the application behavior without collapsing them into one assumption.
The translation pitfall is specific: A support page that counts comments as missing application updates misstates the number of events actually delivered. A page can sound perfectly fluent and still teach a copied sample that no longer parses, or a guarantee that the application never made.
A useful acceptance step is: Distinguish comments, real data events and protocol-level connection liveness when describing monitoring. When the observed browser events disagree with the translated explanation, revise the explanation rather than changing the protocol to make the prose seem right.
18. Connection states
The EventSource readyState exposes CONNECTING, OPEN and CLOSED states. Those values describe the client connection lifecycle, not whether an external operation succeeded.
Imagine a realistic implementation. A library’s stream is OPEN while the separate book reservation endpoint returns a validation error. For an international reader the sentence needs to identify the wire-level fact, the browser behavior and the application behavior without collapsing them into one assumption.
The translation pitfall is specific: A dashboard that displays ‘booking succeeded’ simply because readyState is OPEN confuses transport and business state. A page can sound perfectly fluent and still teach a copied sample that no longer parses, or a guarantee that the application never made.
A useful acceptance step is: Explain the state constants separately from application statuses and do not translate executable constant names. When the observed browser events disagree with the translated explanation, revise the explanation rather than changing the protocol to make the prose seem right.
19. The open and error events
The EventSource object can fire open when it establishes a connection and error when connection issues occur. Error does not automatically identify one particular server defect.
Imagine a realistic implementation. A phone temporarily loses connection inside a lift and later reconnects as permitted by the processing model. For an international reader the sentence needs to identify the wire-level fact, the browser behavior and the application behavior without collapsing them into one assumption.
The translation pitfall is specific: Translating error as ‘server permanently failed’ may alarm a visitor during an ordinary recoverable interruption. A page can sound perfectly fluent and still teach a copied sample that no longer parses, or a guarantee that the application never made.
A useful acceptance step is: Report the observed browser state and distinguish recoverable reconnect attempts from terminal failures. When the observed browser events disagree with the translated explanation, revise the explanation rather than changing the protocol to make the prose seem right.
20. Reconnection is conditional
EventSource supports a reconnection algorithm, with delays and possible backoff, but some responses and failures stop it. Endless guaranteed retries are not a universal promise.
Imagine a realistic implementation. A lecture feed reconnects after an interrupted response, while another request may fail permanently under the standard’s rules. For an international reader the sentence needs to identify the wire-level fact, the browser behavior and the application behavior without collapsing them into one assumption.
The translation pitfall is specific: Promising continuous automatic reconnect regardless of HTTP status or application shutdown makes documentation unreliable. A page can sound perfectly fluent and still teach a copied sample that no longer parses, or a guarantee that the application never made.
A useful acceptance step is: Describe the actual termination and restart conditions with the deployed server and browser implementation. When the observed browser events disagree with the translated explanation, revise the explanation rather than changing the protocol to make the prose seem right.
21. HTTP 204 stops reconnecting
The HTML Standard describes HTTP 204 No Content as a way for a server to tell an EventSource client to stop reconnecting.
Imagine a realistic implementation. A museum closes an ended event stream intentionally and returns 204 for that endpoint. For an international reader the sentence needs to identify the wire-level fact, the browser behavior and the application behavior without collapsing them into one assumption.
The translation pitfall is specific: A translator who presents 204 as a request to keep retrying reverses the intended browser behavior. A page can sound perfectly fluent and still teach a copied sample that no longer parses, or a guarantee that the application never made.
A useful acceptance step is: Retain HTTP status code numbers and explain this no-reconnect behavior in plain language. When the observed browser events disagree with the translated explanation, revise the explanation rather than changing the protocol to make the prose seem right.
22. Redirect behavior
EventSource requests can follow supported HTTP redirects including 301 and 307, subject to the processing model and normal web security rules.
Imagine a realistic implementation. The library migrates its lecture-stream URL to a new endpoint and responds with a supported redirect. For an international reader the sentence needs to identify the wire-level fact, the browser behavior and the application behavior without collapsing them into one assumption.
The translation pitfall is specific: A translated article that assumes every redirect permanently changes the original event stream URL may be inaccurate. A page can sound perfectly fluent and still teach a copied sample that no longer parses, or a guarantee that the application never made.
A useful acceptance step is: Document the redirect type, final origin and deployment behavior, and test an actual browser client. When the observed browser events disagree with the translated explanation, revise the explanation rather than changing the protocol to make the prose seem right.
23. CORS and origin trust
Cross-origin EventSource connections involve web fetch and CORS rules. Access control must consider server policy and browser origin rather than treating stream URLs as public by default.
Imagine a realistic implementation. A university partner embeds authorized lecture notifications across domains using a properly configured cross-origin response. For an international reader the sentence needs to identify the wire-level fact, the browser behavior and the application behavior without collapsing them into one assumption.
The translation pitfall is specific: An article that says adding an EventSource URL bypasses access controls invites insecure engineering practices. A page can sound perfectly fluent and still teach a copied sample that no longer parses, or a guarantee that the application never made.
A useful acceptance step is: Use the standard browser security model, check allowed origins and document authentication and credentials separately. When the observed browser events disagree with the translated explanation, revise the explanation rather than changing the protocol to make the prose seem right.
24. Credentials and withCredentials
EventSource can be constructed with credential mode options for cross-origin requests, subject to the relevant browser rules. The option is not an identity proof on its own.
Imagine a realistic implementation. A member-only library event stream uses a session mechanism compatible with the server’s origin policy. For an international reader the sentence needs to identify the wire-level fact, the browser behavior and the application behavior without collapsing them into one assumption.
The translation pitfall is specific: Translating a credentials flag as ‘everyone is authorized’ erases permission checks performed by the backend. A page can sound perfectly fluent and still teach a copied sample that no longer parses, or a guarantee that the application never made.
A useful acceptance step is: Explain when credentials are included and separately identify what the server validates before returning protected events. When the observed browser events disagree with the translated explanation, revise the explanation rather than changing the protocol to make the prose seem right.
25. Native EventSource does not submit commands
The browser EventSource interface listens to server updates, while submitting data to a server normally requires another HTTP operation or application channel.
Imagine a realistic implementation. An attendee uses fetch to submit a question and EventSource to learn whether it was accepted for the discussion. For an international reader the sentence needs to identify the wire-level fact, the browser behavior and the application behavior without collapsing them into one assumption.
The translation pitfall is specific: A translation that instructs readers to call source.send(‘question’) on native EventSource invents a nonexistent standard method. A page can sound perfectly fluent and still teach a copied sample that no longer parses, or a guarantee that the application never made.
A useful acceptance step is: Show the two separate operations and clarify which one changes business state. When the observed browser events disagree with the translated explanation, revise the explanation rather than changing the protocol to make the prose seem right.
26. Replay is an application feature
SSE parsing and Last-Event-ID supply a reconnect hint; actual replay depends on the server’s own history, retention window and cursor logic.
Imagine a realistic implementation. A library keeps only the last hundred captions, so a visitor returning next week cannot recover the full event through the live stream. For an international reader the sentence needs to identify the wire-level fact, the browser behavior and the application behavior without collapsing them into one assumption.
The translation pitfall is specific: A guide that says ‘every event is preserved forever’ conflates a browser header with durable archival policy. A page can sound perfectly fluent and still teach a copied sample that no longer parses, or a guarantee that the application never made.
A useful acceptance step is: Document server-side retention, cursor expiration and full-history retrieval paths if they truly exist. When the observed browser events disagree with the translated explanation, revise the explanation rather than changing the protocol to make the prose seem right.
27. Cursor gaps and deduplication
An application may use stable event IDs and sequence tracking to detect gaps or duplicates after a reconnect. Such mechanisms are conventions beyond basic SSE syntax.
Imagine a realistic implementation. A visitor gets caption 42, reconnects and receives caption 42 again before caption 43. For an international reader the sentence needs to identify the wire-level fact, the browser behavior and the application behavior without collapsing them into one assumption.
The translation pitfall is specific: Assuming a cursor always prevents duplicates may cause the UI to display a repeated notice or process an action twice. A page can sound perfectly fluent and still teach a copied sample that no longer parses, or a guarantee that the application never made.
A useful acceptance step is: Define application-level deduplication and idempotency where required, and do not translate stable event keys. When the observed browser events disagree with the translated explanation, revise the explanation rather than changing the protocol to make the prose seem right.
28. Order and authoritative timestamps
Events appear in stream order as delivered through one connection, but timestamps, cross-stream ordering and authoritative event time are application concerns.
Imagine a realistic implementation. Two campuses publish queue changes to different sources while a screen combines both feeds. For an international reader the sentence needs to identify the wire-level fact, the browser behavior and the application behavior without collapsing them into one assumption.
The translation pitfall is specific: A translated ‘latest’ label may imply a total global ordering not guaranteed by independent streams. A page can sound perfectly fluent and still teach a copied sample that no longer parses, or a guarantee that the application never made.
A useful acceptance step is: Document event time, processing time, source identity and any explicit merge rules used by the application. When the observed browser events disagree with the translated explanation, revise the explanation rather than changing the protocol to make the prose seem right.
29. Buffering and delayed delivery
HTTP intermediaries and server frameworks may buffer streamed output, delaying the user’s view despite correct SSE syntax.
Imagine a realistic implementation. A visitor receives several captions at once because a proxy flushes them in a batch. For an international reader the sentence needs to identify the wire-level fact, the browser behavior and the application behavior without collapsing them into one assumption.
The translation pitfall is specific: The phrase ‘real time with zero delay’ is not supported by a mere text/event-stream response. A page can sound perfectly fluent and still teach a copied sample that no longer parses, or a guarantee that the application never made.
A useful acceptance step is: Verify proxy buffering, server flush behavior, client processing and realistic network latency before claiming freshness. When the observed browser events disagree with the translated explanation, revise the explanation rather than changing the protocol to make the prose seem right.
30. Connection limits and resource costs
Long-running event streams consume client and server resources. Browser connection limits and HTTP transport details depend on implementation and deployment.
Imagine a realistic implementation. A library opens six independent classroom feeds in browser tabs under a constrained connection environment. For an international reader the sentence needs to identify the wire-level fact, the browser behavior and the application behavior without collapsing them into one assumption.
The translation pitfall is specific: A guide that assures limitless connections may cause missed events and poor battery behavior. A page can sound perfectly fluent and still teach a copied sample that no longer parses, or a guarantee that the application never made.
A useful acceptance step is: State actual deployment limits and use shared feeds or coordinated connection management where appropriate. When the observed browser events disagree with the translated explanation, revise the explanation rather than changing the protocol to make the prose seem right.
31. Error messages and user-facing copy
Operational event tokens and user-facing error copy should be separated. A service may send a stable state value with an independently localized explanation.
Imagine a realistic implementation. A queue stream sends status: pending and a caption explaining that a reservation still needs confirmation. For an international reader the sentence needs to identify the wire-level fact, the browser behavior and the application behavior without collapsing them into one assumption.
The translation pitfall is specific: Translating the machine state pending inside a structured payload can break client conditional handling. A page can sound perfectly fluent and still teach a copied sample that no longer parses, or a guarantee that the application never made.
A useful acceptance step is: Keep stable keys and enum values intact, and localize only fields designated for display. When the observed browser events disagree with the translated explanation, revise the explanation rather than changing the protocol to make the prose seem right.
32. Accessibility and live announcements
A rapidly changing stream can overwhelm assistive technology unless applications control when and how new text is announced.
Imagine a realistic implementation. A museum caption page updates a transcript region and provides a calmer separate notice for critical room changes. For an international reader the sentence needs to identify the wire-level fact, the browser behavior and the application behavior without collapsing them into one assumption.
The translation pitfall is specific: A localized guide that says ‘announce every event immediately’ could create unusable audio output for screen-reader users. A page can sound perfectly fluent and still teach a copied sample that no longer parses, or a guarantee that the application never made.
A useful acceptance step is: Describe accessible announcement policies, reading order and language tagging as interface decisions distinct from the SSE wire format. When the observed browser events disagree with the translated explanation, revise the explanation rather than changing the protocol to make the prose seem right.
33. Privacy and sensitive event data
A stream can deliver protected records or private user status; logs, caches and reconnect URLs should not expose them unnecessarily.
Imagine a realistic implementation. A visitor’s private membership renewal notice shares a stream with public lecture information only if access policy permits. For an international reader the sentence needs to identify the wire-level fact, the browser behavior and the application behavior without collapsing them into one assumption.
The translation pitfall is specific: A tutorial with real session IDs or visitor names in sample streams could leak personal information. A page can sound perfectly fluent and still teach a copied sample that no longer parses, or a guarantee that the application never made.
A useful acceptance step is: Use invented test data, minimize sensitive values and enforce authorization at the server for every protected stream. When the observed browser events disagree with the translated explanation, revise the explanation rather than changing the protocol to make the prose seem right.
34. Testing the complete reconnection cycle
An accurate guide should exercise successful dispatch, multiline data, named events, cursor reset, valid and invalid retry, 204 stopping behavior and missed-event recovery.
Imagine a realistic implementation. A QA engineer interrupts connectivity after event 12 and verifies the exact request header and server response on reconnection. For an international reader the sentence needs to identify the wire-level fact, the browser behavior and the application behavior without collapsing them into one assumption.
The translation pitfall is specific: A single screenshot of EventSource.readyState OPEN proves none of these recovery behaviors. A page can sound perfectly fluent and still teach a copied sample that no longer parses, or a guarantee that the application never made.
A useful acceptance step is: Record browser version, server settings and final rendered events, and test the published target-language code samples. When the observed browser events disagree with the translated explanation, revise the explanation rather than changing the protocol to make the prose seem right.
End-to-end example: museum lecture captions after a disconnection
Worked case, first connection: the visitor opens a page and constructs an EventSource for a lecture stream. The response has Content-Type: text/event-stream and sends data: The lecture begins, followed by a blank line. The browser dispatches a message event. The human text can be translated; the data field and separation line cannot.
Second event: the server sends event: caption.updated, id: cap-00042 and a data field containing localized caption text. The page listens for caption.updated exactly. A translator can change the display text, but changing the event token or opaque ID will change which handler runs or how a reconnect can resume.
Third event: two data lines form one caption event with an internal newline. During review, a formatting tool inserts an extra blank line because it prefers visual paragraph separation. The parser then dispatches an earlier event than intended. The corrected sample restores the wire layout and verifies the final value of event.data.
Fourth event: the visitor’s connection drops. The client has last event ID cap-00042 and may send Last-Event-ID on reconnection. If the server’s history begins at cap-00040, replay might work under the application’s policy. If the server deleted older records or does not implement replay, that header is not a recovery guarantee. The guide must make this limitation explicit.
Fifth event: the lecture is over. The server can use HTTP 204 to tell the client to stop reconnecting. The visitor still needs a separate authoritative confirmation if they registered for a certificate or purchased a ticket. Ending a stream is not the same thing as finishing an unrelated workflow.
Practical publication checklist
Preserve parser field names, response MIME type, event names, identifiers, retry syntax and HTTP response codes. Use real EventSource browser tests to verify the target-language sample, including multiline content, a blank-line event boundary and a valid UTF-8 response. Test reconnection with a server that supports history and with one that does not, so that the article does not accidentally promise durable replay.
Review live interface language separately from the transport sample. A person should be able to tell whether the page is reconnecting, whether a notice may have been missed, whether the data source is fully synchronized and whether a requested booking is still pending. Those conditions need distinct wording, especially when errors affect accessibility, safety or important transactions.
Frequently asked questions
Does EventSource send messages to the server?
The native interface receives a server stream; client submissions normally use a separate request mechanism.
Does Last-Event-ID guarantee replay?
No. The server must implement and retain the events needed for replay.
Is retry: 5000 five seconds?
Yes, the value is in milliseconds. The parser requires ASCII digits in that field.
Why does an SSE message need a blank line?
The blank line dispatches the pending event block. Whitespace is structurally significant.
Can data contain multilingual text?
Yes, streams use UTF-8. Preserve structural keys and properly encode the human-facing text.
Does a missing event name prevent dispatch?
No. Without a named event type the default message type is used when data is present.
Can HTTP 204 stop EventSource reconnection?
Yes. It is the standard’s documented no-reconnect response.
Will an empty id field preserve the old cursor?
No. An empty id can reset the last event ID string, affecting the subsequent reconnect header.
What is the best localization test?
Run the stream through a real browser parser, disconnect and reconnect, and compare resulting events and authoritative business state.
Official standard and reference material
WHATWG HTML Living Standard, Server-sent events: https://html.spec.whatwg.org/multipage/server-sent-events.html . Browser EventSource API: https://developer.mozilla.org/en-US/docs/Web/API/EventSource . Validate the actual server implementation, retention policy, security settings and browser behavior before promising a particular replay or timing guarantee. The HTML Standard is a living document; check its date and the versions of your actual clients.
Conclusion
The point of translating an SSE guide is not simply to replace English phrases with equivalent phrases. It is to help the reader distinguish event framing, browser dispatch, reconnection hints, server-side replay and final business state. When that distinction survives translation, an international developer can use the documentation confidently without silently changing the protocol.