Tutorials Accessibility

Localising On-Screen Text and Graphics

Intermediate · ~18 min

Overview

Subtitling a video is straightforward. What breaks localisation is everything else on screen: lower thirds, titles, charts, callouts, and screen recordings with interface text baked into the picture. Text that lives in pixels cannot be translated without rebuilding the graphic, and text that fits in English frequently does not fit once translated. This guide covers designing for localisation from the start and the practical fixes when a project was not.

What You Need

Project files rather than only rendered output
Text stored as editable text, not rasterised
Fonts that support the target scripts
A translator, and enough context for them to work from
Layouts with room for text expansion designed in
A review pass by someone who reads the target language

Steps

Keep text as text, never as flattened pixels

Graphics delivered as flattened images cannot be localised without rebuilding them from scratch. Keep titles, lower thirds, and callouts as live text layers in project files you retain. This single practice determines whether localisation is an afternoon or a reconstruction.

Design layouts for text expansion

Translated text is frequently longer than the English original, sometimes substantially: German and Finnish commonly run longer, and a short English label can become a phrase. Design lower thirds and buttons with room to grow rather than fitting the English text exactly, or every localised version needs manual layout repair.

Choose fonts that cover your target scripts

A typeface chosen for its Latin character set may have no Cyrillic, Greek, Arabic, or CJK coverage at all, producing missing glyphs. Check script coverage before committing to a typeface, and be aware that right-to-left scripts affect layout direction as well as characters.

Avoid burning interface text into screen recordings

Software demonstrations with the interface visible are the hardest content to localise, since the interface text is part of the picture. Where possible, re-record with the software in the target language, or design around it, showing the action while narration carries the specifics.

Give translators context, not just strings

A list of disconnected phrases produces poor translation because the same word translates differently depending on whether it is a button, a heading, or part of a sentence. Supply the video, screenshots, or at minimum a note of where each string appears and how much room it has.

Review in-context before publishing

Have someone who reads the target language watch the finished localised version, not just proofread the strings. Overflowing text, wrong line breaks, missing glyphs, and text colliding with graphics only appear once assembled, and they are exactly the errors that make a localisation look careless.

Pro Tips

Design lower thirds with roughly a third more room than the English text needs.
Never rasterise text layers in a project you may localise. It converts an edit into a rebuild.
Check that your typeface actually contains the scripts you need before committing to it.
Narration that says the specifics rather than pointing at them localises far more easily.
Right-to-left languages affect layout direction, not just characters. Test rather than assuming.

Knowledge Base

What You'll Learn

Localisation fails at the graphics far more often than at the translation. Below: the text expansion problem, and why baked-in text is the expensive mistake.

The Text Expansion Problem

Translated text rarely occupies the same space as the original, and the direction is usually longer.

English is comparatively compact. Translations into several European languages commonly run noticeably longer, and short strings expand proportionally more than long ones. A single-word label can become three words, while a paragraph might grow by a smaller fraction.

This matters because designed layouts are usually fitted to the original text. A lower third sized precisely to the English name and title overflows once translated. A button label that fit wraps awkwardly. A chart label collides with the axis.

The fix is to design with slack from the start, layouts that accommodate meaningfully more text than the original needs, text that can wrap gracefully, and avoiding designs where text is precisely fitted to a container.

The alternative is manual layout repair for every language, which is exactly the cost that makes organisations abandon localisation after the first attempt. Designing with room is nearly free at the template stage and expensive to retrofit across a library.

Why Baked-In Text Is the Expensive Mistake

Text that exists only as pixels in a rendered image is, from a localisation perspective, not text at all.

It cannot be extracted, translated, and reinserted. It has to be identified by a human watching the video, recreated in a graphics tool, translated, re-rendered, and re-composited, for every instance and every language. The cost scales multiplicatively rather than additively.

The most common sources are graphics delivered as flattened files with no project retained, titles rendered and then archived without the source, and screen recordings of software in a single language.

Screen recordings are the hardest, because the interface text is inseparable from the demonstration. The workable strategies are re-recording in the target language, or designing narration and framing so the specifics are spoken rather than only shown, which is also better for accessibility, since it means the visual information exists in the audio.

The general principle: anything that might be translated should exist as editable text in a project file you keep. The retention policy matters as much as the design decision.

Where This Fits

This guide covers one specific part of captions and access. The wider picture, caption formats, reading speed, speaker identification, what automatic captioning still gets wrong, and a practical QA pass, is in Beyond Auto-Captions: Caption Quality, Styling, and Readability, which frames the discipline as a whole and links out to the detailed guides underneath it, including this one. If you are starting from scratch rather than solving a specific problem, read that first and come back here.

FAQ

Q: Why is localisation harder than just translating the subtitles?
A: Because subtitles are the easy part. On-screen text (lower thirds, titles, charts, callouts, and interface text in screen recordings) lives in the picture and cannot be translated without rebuilding the graphic. That work, repeated per language, is what makes localisation expensive.

Q: How much extra space should I design in for translation?
A: Roughly a third more than the English text needs is a common working allowance, more for very short labels which expand proportionally most. Design layouts that wrap gracefully rather than fitting text precisely to a container, since precisely fitted designs break in every language.

Q: What do I do about software screen recordings?
A: Either re-record with the software set to the target language, or design around it, frame and narrate so the specifics are spoken rather than only shown on screen. The second approach also improves accessibility, since it puts visual information into the audio where it is available to more people.

Q: Do I need a native speaker to review the result?
A: Yes, reviewing the assembled video rather than proofreading the strings. Overflowing text, awkward line breaks, missing glyphs, and text colliding with graphics only appear once everything is composited, and they are precisely the errors that make a localised version look careless regardless of translation quality.