Handling overseas live chat: route before you translate

Most teams handle live chat by wiring up a translation service, pushing every comment through it, and then complaining that the output is poor.

The engine is not the problem. The problem is sending chat into translation in bulk. In a cross-border session, only a small slice of the chat genuinely needs to be understood. The rest is either a structured event or a question whose answer never changes. Separate those out and what remains is small enough that the choice of engine barely matters.

What follows is a routing scheme. Work through it and you end up with a trigger table and a priority queue rather than a more expensive translation vendor.

The first question decides the architecture

Ask this before anything else, because the answer changes everything downstream.

YouTube has a first-party API. The Live Streaming API exposes chat through the liveChatMessages resource as structured events, each carrying a type, author identity and timestamp, with amount and currency attached to paid messages. You can automate on top of that with confidence.

TikTok does not. TikTok publishes no API for reading live stream chat in real time. Everything currently in use is either a third-party managed service such as EulerStream or TikTool, or a community-maintained unofficial library — and those projects’ own documentation states that they are not affiliated with or endorsed by TikTok, and that self-hosted protocol clients break frequently when the platform updates.

That gap is not a detail; it sets how much engineering is worth spending. On YouTube an automated routing pipeline pays off. On TikTok the same rules are more reliable as a manual assistant workflow, because the technical dependency can stop working on the morning of a broadcast.

One correction worth making while we are here: the automatic captioning and translation TikTok has publicised is a video-side capability. There is no citable specification for the live side. Do not plan around “the platform handles translation”.

The connection has to exist before you go live

YouTube’s documentation includes a detail that is easy to skim past and expensive to discover late: a first request made without a continuation token returns only the most recent messages, and the API does not retrieve messages older than the ones that initial request returned.

Chat history, in other words, cannot be backfilled. Connect twenty minutes into a session and those twenty minutes are gone permanently. Drop the connection mid-broadcast and the gap is gone too.

So the connection needs to be established before the broadcast and held, with automatic retry on disconnect. If you intend to analyse chat afterwards — and the rule maintenance below depends on it — persistence has to start from the first message.

Polling rate does not need guessing. The response carries pollingIntervalMillis, which states how long the client should wait before asking again; going faster returns a 403 rateLimitExceeded, or RESOURCE_EXHAUSTED on the streaming endpoint. maxResults accepts 200 to 2000 per request and defaults to 500. When you need lower latency, the official streamList method opens a server-streaming connection instead of polling.

Layer one: split on event type, not on text

This is the highest-yield step in the whole scheme, and the one most often skipped in favour of jumping straight to language processing.

Every YouTube message carries a snippet.type field, and the documented enumeration already separates these cases:

Event type	Meaning
textMessageEvent	An ordinary viewer comment
superChatEvent / superStickerEvent	Paid highlighted message, paid sticker
newSponsorEvent / memberMilestoneChatEvent	New member, member milestone message
membershipGiftingEvent / giftMembershipReceivedEvent	Gifted memberships, gift received
giftEvent	Gift
pollEvent	Poll
userBannedEvent	A user was banned
chatEndedEvent / tombstone	Chat ended, message deleted

Only textMessageEvent needs to continue. Everything else exposes structured fields that require no text understanding at all. Paid messages carry superChatDetails with amountMicros, an ISO 4217 currency code, and a tier derived from the amount spent — that tier also determines the highlight colour in the chat UI, the maximum message length, and how long the message stays pinned in the ticker. Membership events carry level names. Author identity sits in authorDetails, including channel ID, display name and the author’s role in that chat.

This layer produces no false positives, because it reads labels the platform assigned rather than inferring them.

The second official signal is snippet.hasDisplayContent, which marks whether a message has content meant for display; chatEndedEvent and tombstone have no displayMessage field whatsoever. Filter on those, then add your own rules for emoji-only lines, single characters and the same user repeating themselves. Regular expressions cover all of it.

Layer two: a trigger table for the repeats

Cross-border chat repeats heavily: shipping cost, dispatch time, size availability, payment methods, cash on delivery, returns.

The exact distribution depends on category, platform and audience mix, and nobody’s percentages describe your room, ours included. You do not need anyone else’s numbers. Export your last session’s chat log, group the questions and count. Ten minutes gives you your own real distribution, which is the only sound basis for building the table anyway.

The table looks like this:

Trigger	Prepared reply (target language)
shipping / ship to / country codes	Fixed wording for cost and serviceable regions
cod / cash on delivery	Fixed wording for payment options
size / fit / numeric sizes	Size conversion and fit guidance
when / eta / arrive	Dispatch and delivery timing

Anything matching a template never enters the translation queue. Its latency is zero and its accuracy beats machine translation.

Short text happens to be the hardest input machine translation gets, which is not a shortcoming of any particular engine. Real comments look like this:

• ship to PH?
• cod?
• mine?
• next size pls

In a commerce context cod means cash on delivery, but it is also a fish, and an isolated cod? gives an engine nothing to disambiguate with. mine? is more extreme still: it means “was that last order mine”, and the meaning lives in something the host said thirty seconds earlier. No per-message translation can reach that context.

The conclusion is not that machine translation is inadequate. It is that comments like these should never enter a translation pipeline. A trigger table should catch them, or they should be dropped.

Layer three: the priority queue

By now the volume is much lower, but peaks will still outpace what a person can handle. What that calls for is an explicit order of sacrifice, not a faster translator.

1. Paid events — superChatEvent, superStickerEvent and membership events, all decidable straight from API fields;
2. First-time commenters — this authorChannelId has not appeared this session, which is a table lookup once you are persisting;
3. Questions repeating three or more times within a minute — a shared confusion, worth answering once, publicly;
4. Everything else, sampled — one comment every few seconds is plenty.

Fix this order in writing and do not let the assistant decide in the moment. Improvised attention tends to land on the newest few lines, and the newest few lines are the least representative ones available.

What actually deserves translation

Very little survives to this point, and the test is a single question: does this comment contain information you did not already have?

Worth translating: a viewer describing their own use case, raising something you had not anticipated, or correcting a claim you got wrong. None of those can be covered by a template, and all of them genuinely need understanding.

Not worth translating: expressions of feeling, agreement, and any question you have already prepared an answer for in the trigger table.

Dividing the work

Rules only help if someone runs them. A division that works in practice: the assistant watches the queue, the host only reads.

The assistant watches the priority queue, pulls the matching script when a template fires, forwards only what needs translating, and condenses the result into a sentence or two the host can say directly. The host never reads raw chat — the moment a host starts scanning comments personally, their pacing falls apart.

There is a detail here that ties back to the speech pipeline: do not break your speaking rhythm to answer chat. The host’s audio is still being segmented, translated and synthesised, and dropping a clipped exchange into the middle of that disrupts sentence boundaries and degrades quality on the speech side. Park chat responses in the natural gaps between segments.

When responding, batch rather than naming individuals:

“A few of you asked about shipping —”

That opening does two jobs. It reframes the time gap as ordinary conversational pacing, and it lets one answer serve several people. The host never has to pretend to be instantaneous.

Catching rules that have gone stale

Trigger tables expire. New products, new markets and platform changes all shift how viewers phrase things.

Every few sessions, export what the rules discarded and read a sample. What you are hunting for is questions that should have matched and did not — they get dropped quietly as low priority, and nothing in the live room reveals it. This is the only way to detect drift, and it is the one part of this scheme that needs ongoing attention.

The discarded pile also happens to be the best source of new trigger words, considerably more accurate than imagining how viewers might phrase a question.