How to lay out bilingual live captions without hiding the product

Once bilingual captions are technically visible, layout becomes the difference between useful translation and two lines covering the product. Making both lines large and placing them at the bottom is not a neutral default: it competes with shopping cards, comments, and the subject itself.

Set information hierarchy first, placement second, and colour and size last.

Pick one primary language

For an overseas audience, the translation is the primary layer and the source is supporting information. Make the target larger, brighter, or heavier. Make the source recede on at least one of those dimensions.

ObsTrans green-screen captions can show source and target independently and style their colours separately. Keep both for bilingual verification; turn off source text when the audience only needs the target. Reducing two crowded lines is usually worse than removing the unnecessary one.

The software cannot choose your audience. That decision belongs to the language-pair strategy, not to the presenter’s native language.

Limit the information in each update

An early W3C caption readability reference recommends roughly five words or 25–35 characters per line and notes that languages require different space. Those figures came from a particular display context and should not become a modern pixel rule. The durable point is that moving captions need much shorter lines than static prose.

Do not solve long sentences by shrinking the font. Long updates often indicate segmentation that waits too long. Fix that in the latency and segmentation path; layout cannot repair a paragraph-sized recognition result.

Avoid two categories of obstruction

First, protect your own important content: product details, price cards, size tables, and the host’s hands. Second, protect platform overlays: comments, shopping controls, buttons, and system notices.

W3C’s explanation of live captions says captions should not obscure information needed to understand the video. The FCC’s captioning quality overview likewise treats placement alongside accuracy, synchronicity, and completeness. These are not universal pixel specifications for every social platform. They establish the useful principle: captions must not replace one form of access by hiding another.

Dragging the caption box in the ObsTrans green window is only the first pass. Final placement belongs to the viewer interface.

Build contrast that survives compression

Transparent text disappears over pale products. A solid black rectangle can hide the demonstration. A restrained semi-transparent dark panel is a practical middle ground, with the target in a strong colour and source in white or lower brightness.

Do not distinguish lines by red versus green alone. Add a second cue through size, weight, or vertical order. That survives colour-vision differences and platform recompression.

The phone is the acceptance canvas

The OBS preview proves that captions exist in the encoded frame. It does not show the platform UI. YouTube’s official streaming tips call for checking Live Control Room, verifying the stream on mobile, and monitoring audio and video continuously.

Run an unlisted or test stream and check:

1. the target is readable at a glance on a small screen;
2. opening comments or a product card does not cover it;
3. the longest real sentence wraps without clipping;
4. source and target can be distinguished immediately;
5. close-up product shots remain visible.

Open captions are not a closed-caption track

Captions composited through chroma key are open captions: every viewer sees them and nobody can turn them off. Their advantage is independence from the platform’s language support.

YouTube’s live caption requirements describe embedded 608/708 captions and supported software that sends captions by HTTP, and currently state that YouTube supports one caption track. The ObsTrans green-screen overlay does not send that track; it renders captions into the picture.

Both approaches can be useful, but they solve different requirements. If viewers need selectable captions and stronger accessibility support, evaluate the platform’s closed-caption path separately.