Localizing On-Screen Text and Graphics: Titles, Lower Thirds

Every frame of your video that contains readable text is a localization decision. Titles, lower thirds, callouts, data visualizations, UI captures, and motion graphics all carry meaning that must transfer cleanly into each target language. Yet visual localization is routinely treated as an afterthought, bolted on after dialogue dubbing or subtitling, leading to clipped text, broken animations, mismatched fonts, and costly rework cycles. This guide walks through a repeatable pipeline for auditing, extracting, adapting, and delivering localized on-screen graphics at scale. Whether you manage a handful of product videos or a library of thousands, the principles here will help you ship polished, linguistically accurate visuals in every market you serve.

If your team is already wrestling with graphics localization at scale, explore how Ollang's AI-powered pipeline handles visual localization end to end.

Auditing On-Screen Text Across Your Video Library

Before any translation begins, you need a complete inventory of every text element that appears on screen. Skipping this step is the single most common source of missed strings, last-minute fixes, and blown deadlines.

Building a Visual Text Inventory

Start by scrubbing through each video frame by frame, or, more practically, by exporting a thumbnail contact sheet at one-second intervals and flagging every frame that contains visible text. Your inventory should capture:

• Element type: title card, lower third, callout, bullet point, chart label, button overlay, end card, legal disclaimer.
• Timecode in/out: the exact frames where the element appears and disappears.
• Source string: the verbatim text as it appears on screen.
• Character count: critical for estimating expansion and enforcing limits.
• Layer or asset reference: the project file layer name, MOGRT component, or render file that generates the element.
• Animation behavior: static hold, type-on, kinetic, particle-driven, or tracked to camera motion.

For large libraries, semi-automated approaches help. Optical character recognition can surface text from rendered frames, and some NLE and compositing tools can export text layers as XML or JSON. But OCR alone is unreliable on stylized or animated type, always validate against the source project. Platforms like Ollang can automate OCR-based detection and export structured inventories for review.

Identifying Burned-In vs. Editable Elements

The cost and method of localization hinge on whether text lives in an editable project layer or has been permanently rendered ("burned in") to the video. Tag each element with one of these categories:

• Editable text layer (AE, Premiere, MOGRT): Source available, yes; localization method, direct edit or template swap; relative cost, low.
• Pre-rendered overlay with alpha channel: Source available, partial; localization method, re-render from source, composite; relative cost, medium.
• Burned-in text (baked into final pixel data): Source available, no; localization method, rotoscope/paint-out, OCR, recreate; relative cost, high.
• UI screenshot or screen recording: Source available, no (usually); localization method, re-capture in target locale or composite; relative cost, high.

The audit should tag every element with one of these categories so the production team can plan the right extraction and adaptation path.

Extracting and Preparing Source Projects

Working with MOGRTs and Essential Graphics Templates

Motion Graphics Templates (MOGRTs) are the most scalable vehicle for graphics localization. A well-built MOGRT exposes each text field, its character limit, font assignment, and color properties as editable parameters, meaning a translator or localization engineer can swap strings without opening After Effects.

The key requirements for localization-ready MOGRTs:

• Every user-facing text field must be exposed as an editable property, not hard-coded inside a precomp.
• Each field should carry a descriptive label (e.g., speaker_name, job_title, cta_line1) rather than generic names like Text Layer 3.
• Character limits should be defined per field, reflecting the maximum string length the layout can accommodate before clipping or overlapping adjacent elements.
• Font assignments should reference fonts that support the full Unicode range needed for your target languages, or include explicit fallback mappings.

If your creative team delivers MOGRTs that meet these criteria, you can localize dozens of language versions from a single template with minimal designer involvement. Ollang can ingest editable templates and automate string population across language versions to reduce manual work.

Direct Editing in After Effects and Premiere Pro

When templates aren't available, or when the design is too complex for MOGRT parameter exposure, localization happens inside the native project files (AEPs for After Effects, PPRO sequences for Premiere Pro).

This path requires the localization team to have access to the complete project, including all linked assets, fonts, plugins, and expressions. A common failure mode is receiving a project file that opens with missing fonts or broken plugin references, which stalls production immediately. The source preparation checklist should include:

• Collecting all project files and dependencies into a single, portable folder structure.
• Converting any proprietary or uncommon plugin-driven text effects to native alternatives, or providing the plugin installers.
• Embedding or packaging all fonts used in the project.
• Documenting any expressions that reference text content (e.g., character-count-driven scaling or sourceText expressions).

When Full Recreation Is the Only Option

Some legacy content, acquired footage, or third-party assets arrive with no editable source at all. In these cases, the graphics must be recreated from scratch: matching the original typography, color, animation timing, and spatial layout by eye. This is the most labor-intensive path, but it produces fully editable assets for future localization rounds. If you're commissioning new content, insist on receiving editable source projects, the cost savings downstream are substantial.

Font Strategy, Licensing, and Script Support

Choosing Fonts That Travel Well

A font that looks elegant in English may lack glyphs for Vietnamese diacritics, Korean jamo, or Arabic ligatures. Selecting typefaces early in the creative process that support your full target-language set prevents expensive font substitutions later.

Prioritize font families that offer:

• Broad Unicode coverage, including Latin Extended, Cyrillic, Greek, CJK Unified Ideographs, Arabic, Devanagari, and Thai blocks as needed.
• Multiple weights and styles, so bold, italic, and condensed variants are available across scripts.
• Consistent vertical metrics, ensuring line heights and baselines behave predictably when scripts change.

Google's Noto font family is specifically designed to cover every Unicode script and is freely licensed, making it a practical baseline for many localization workflows. For brand-critical work where a proprietary typeface is required, verify its script coverage against your target-language list before production begins.

Licensing Across Markets

Font licensing terms vary widely. A desktop license may not cover embedding in video, and a license valid for one region may not extend to distribution in another. Confirm that your font licenses permit:

• Embedding in rendered video files distributed globally.
• Use in interactive overlays or web-based players if applicable.
• Modification of outlines (converting to paths) if the workflow requires it.

Open-source fonts under the SIL Open Font License or Apache License sidestep most of these concerns, but always verify the specific license terms.

Handling RTL, CJK, and Complex Scripts

Right-to-left scripts (Arabic, Hebrew) and complex scripts (Thai, Devanagari, Burmese) require more than a font swap. Key considerations include:

• Text direction and alignment: RTL text must flow from right to left, and UI or graphic layouts may need to be mirrored entirely. Lower thirds with a name on the left and a title on the right may need to flip.
• Shaping and ligatures: Arabic requires contextual shaping, the same letter looks different at the start, middle, and end of a word. Not all motion graphics tools handle this correctly; After Effects, for example, has historically required workarounds or third-party plugins for proper Arabic shaping.
• CJK line breaking: Chinese, Japanese, and Korean text does not use spaces between words, and line-break rules differ from Latin text. Characters that must not begin or end a line (kinsoku shori rules) need to be respected.
• Vertical text: Japanese content sometimes uses vertical text layout, which most Western-oriented motion graphics tools do not natively support well.

Testing rendered output in each target script, not just previewing in the project, is essential. What looks correct in a composition panel may render incorrectly in the final export.

Managing Text Expansion and Layout Constraints

How Much Room Do You Actually Need?

Text expansion is the most predictable source of visual breakage in localized graphics. A concise English string almost always grows when translated. German and Finnish translations commonly expand by 30-40% in character count compared to English source text, according to IBM's globalization guidelines: https://www.ibm.com/docs/en/. Shorter strings expand proportionally more: a two-word English callout might double in length in German.

Practical rules for graphics localization:

• English source length 1-10 characters: allow 100% or more extra space.
• 11-20 characters: allow 50-80% extra space.
• 21-50 characters: allow 30-50% extra space.
• 51+ characters: allow 20-30% extra space.

These are guidelines, not guarantees. Always validate against actual translated strings rather than relying on ratios alone.

Safe Areas, Bounding Boxes, and Overflow Handling

Every text element in a motion graphic should be designed with a defined bounding box, the maximum area the text can occupy without overlapping other elements, exceeding title-safe margins, or breaking the animation.

Strategies for handling overflow:

• Auto-sizing text boxes that reduce font size to fit content, with a defined minimum size below which the text becomes illegible.
• Two-line allowances where a single-line English string may wrap to two lines in longer languages, with the vertical space pre-allocated.
• Abbreviated or adapted translations where the translator is given a strict character limit and writes to fit, rather than translating literally and hoping it fits.
• Responsive layouts where graphic elements reflow or resize based on text length, feasible in template-driven workflows, difficult in hand-animated compositions.

Title-safe and action-safe areas (typically 80% and 90% of the frame, respectively) remain important for broadcast delivery. Even for digital-only content, keeping text away from frame edges prevents clipping on devices with overscan or rounded-corner displays.

Localizing Screenshots, UI Captures, and Screen Recordings

Product videos frequently include screenshots, app UI captures, or screen recordings showing software in action. These elements contain dense, context-sensitive text that must be localized to match the viewer's language.

The cleanest approach is to re-capture the UI in each target locale, running the software in the localized version and recording new footage. This ensures every menu label, button, tooltip, and system string is authentic. When re-capture isn't feasible (because the localized software version doesn't exist yet, or the original recording conditions can't be reproduced), composite replacement is the fallback:

1. Isolate the text regions in the original capture using masking or rotoscoping.
2. Paint out the original text, reconstructing the background behind it.
3. Composite the translated text in the correct font, size, and position.
4. Match any cursor movements, highlights, or transitions that interact with the replaced text.

This process is painstaking but sometimes unavoidable. Planning for it in the production budget prevents surprises.

Re-Animating Type: Kerning, Tracking, and Motion

Animated typography, type-on effects, kinetic text, character-by-character reveals, is sensitive to the length and visual rhythm of the translated string. Simply swapping the text and hoping the animation still works is a recipe for awkward pacing.

When re-animating localized type:

• Adjust timing per character or word count. A type-on effect timed for a 12-character English word will feel rushed on a 20-character German equivalent. Scale the animation duration proportionally, or retime keyframes manually.
• Re-kern and re-track. Different scripts have different natural spacing. Latin text kerned for English may look too tight or too loose with accented characters. CJK characters are typically monospaced and need uniform tracking. Arabic connected script has its own spacing logic entirely.
• Preserve motion intent, not motion data. If a word animates from left to right in English, the equivalent Arabic animation should move from right to left. If a word scales up to emphasize importance, the localized version should scale up at the same narrative beat, even if the word is longer.
• Watch for expression-driven animations. After Effects expressions that reference text.sourceText.length or similar properties may need adjustment when the string length changes dramatically.

Replacing Burned-In Text: Roto, OCR, and Cleanup

When editable source files are unavailable and text is permanently rendered into the video, replacement requires frame-by-frame cleanup, one of the most expensive operations in graphics localization.

The typical workflow:

1. OCR extraction: Run optical character recognition on the burned-in text to capture the source strings. Validate manually, especially for stylized or partially obscured type.
2. Rotoscoping or masking: Isolate the text region in each frame. For static text over a simple background, a single mask may suffice. For text over moving footage, frame-by-frame roto or AI-assisted object removal is needed.
3. Background reconstruction: Paint or clone-stamp the area behind the removed text to reconstruct a clean plate. AI-powered inpainting tools have improved this step significantly, but results still require human review, especially on complex backgrounds.
4. Text compositing: Place the translated text over the cleaned plate, matching the original font, size, color, shadow, and position as closely as possible.
5. Motion matching: If the original text was tracked to camera movement or object motion, the replacement text must follow the same track. Match-moving or point-tracking data from the original shot is essential here.

This process can cost several times more per minute of video than template-based localization. It's a strong argument for maintaining editable source projects from the start.

If burned-in text replacement is a recurring challenge in your video library, see how Ollang's pipeline handles visual cleanup and recomposition across languages.

Translator-Designer Handoff: A Practical Spec

The gap between translators and motion designers is where most graphics localization errors originate. Translators don't know the visual constraints; designers don't know the linguistic requirements. A structured handoff spec bridges this gap.

What the Handoff Document Should Include

For each text element, provide the translator with:

• Layer/field name: Matches the project file layer name exactly (e.g., lower_third_name).
• Source string: The original text.
• Context description: Where and how the text appears (for example, "speaker name, lower third, visible for 3 seconds").
• Character limit: Maximum characters that fit the layout, including spaces.
• Line limit: Maximum number of lines allowed.
• Timing: Timecode in/out, or duration of visibility.
• Screenshot: A frame grab showing the text in context.
• Notes: Any constraints ("must be formal register," "abbreviation OK," "do not translate brand name").

Deliver this as a structured spreadsheet or JSON file, not as free-text instructions in an email. The designer should be able to import translated strings directly into the project using the layer/field names as keys.

Review Loop with Annotated Proxies

After the designer places translated text, generate a low-resolution proxy render of each localized version. The linguistic reviewer watches the proxy and annotates issues directly on the video, flagging truncated text, incorrect line breaks, timing mismatches, or mistranslated strings.

Tools that support frame-accurate annotation (such as Ollang, Frame.io, or similar review platforms) make this loop efficient. The reviewer should not need access to the project file; they review the visual output and return corrections keyed to timecode and element name. The designer applies fixes and re-renders. One to two review rounds is typical; more than three suggests the handoff spec was incomplete.

Deliverables: Formats, Packages, and Versioning

Project Files and Pre-Renders

A complete graphics localization delivery includes:

• Editable project files (AEP, PPRO, or equivalent) with all translated text in place, organized by language in clearly named folders.
• Pre-rendered overlays with alpha channels (ProRes 4444, DNxHR 444, or PNG sequences) for each language version, allowing downstream editors to composite without opening the source project.
• JSON or XML string tables mapping each field name to its translated string in every language, enabling automated template population for future versions.
• Font packages containing all fonts used, with license documentation.

Ollang accepts structured string tables (JSON/XML) to automate template population and streamline downstream rendering.

Naming Conventions and Version Control

Adopt a naming convention that encodes language, version, and element type:

projectname_element_lang_v##.ext
brand-intro_lower-third_de-DE_v02.mogrt

Store all versions in a version-controlled repository or asset management system. When a source video is updated, the string tables and templates should allow rapid re-localization without starting from scratch.

Common Failure Modes and How to Avoid Them

Even experienced teams hit recurring pitfalls. Here are the most frequent and how to prevent them:

• Missing font fallbacks. The project opens on a different machine, the font isn't installed, and the system substitutes a default. Fix: package fonts with every project delivery and define explicit fallback fonts in the spec.
• Ignoring text expansion. The English version fits perfectly; the German version clips. Fix: design for the longest expected language from the start, or enforce character limits in the translator brief.
• Untranslated elements. A callout buried in a precomp or a text element on a hidden layer gets missed. Fix: the visual text audit catches these before translation begins.
• Broken Arabic or Hebrew shaping. Text renders as disconnected letters or in the wrong order. Fix: test rendered output (not just the project preview) in every RTL language, and use plugins or tools that handle complex script shaping correctly.
• Animation timing mismatches. A type-on effect finishes before the voiceover reaches the corresponding word, or text disappears before the viewer can read it. Fix: re-time animations to match the localized audio and apply appropriate reading-speed guidelines (roughly 15-20 characters per second for most Latin-script languages, adjusted for script complexity).
• Delivering only rendered files, no sources. The client receives final videos but can't update them for the next campaign. Fix: always deliver editable project files and string tables alongside rendered output.

Frequently Asked Questions

How do I handle text expansion in lower thirds without redesigning the template?

Design your lower-third templates with a flexible width or a two-line allowance from the outset. Set a character limit per field based on the longest target language in your set (German and Finnish are common expansion benchmarks for Latin-script languages). Provide translators with these limits upfront so they can write concise, space-aware translations rather than literal ones that overflow.

What's the best approach for localizing animated kinetic typography?

There is no shortcut: each language version needs its keyframes reviewed and likely adjusted. The animation timing, character spacing, and directional flow all depend on the translated string. For high-volume work, build expressions or scripts in After Effects that auto-scale duration based on string length, but always review the result visually. Automated scaling gets you close; human judgment gets you to polished.

Should I use AI-generated inpainting to remove burned-in text?

AI inpainting tools have become remarkably capable at reconstructing backgrounds behind removed text, especially on relatively uniform or slowly changing backgrounds. They significantly reduce the manual paint-out labor. However, they can produce artifacts on complex textures, faces, or fast motion. Use AI inpainting as a first pass, then have an artist review and clean up any frames where the reconstruction is visibly imperfect.

How do I manage font licensing for dozens of language versions distributed globally?

Start with fonts licensed for unlimited global video embedding, open-source families like Google Noto or Adobe's Source family are strong defaults. If brand guidelines require a proprietary typeface, work with the foundry to secure a license that covers all distribution channels and territories before production begins. Retrofitting font licenses after delivery is expensive and legally risky. For teams that want to automate and track licenses alongside assets, Ollang supports embedding license metadata in delivery packages.

Build a Repeatable Graphics Localization Pipeline

Localizing on-screen text and graphics is detail-intensive work, but it doesn't have to be chaotic. The pipeline outlined here, audit, extract, translate within constraints, adapt layouts, review in context, deliver structured packages, turns a fragile, ad-hoc process into a repeatable system. The upfront investment in template design, handoff specs, and font strategy pays for itself many times over as your language count and video volume grow.

Ollang's localization platform is built to manage exactly this kind of complexity, from visual text extraction through designer handoff, AI-assisted adaptation, and frame-accurate review. Book a Demo