Localizing text baked into images and textures (and how to avoid it)

Your title logo. The shop sign hanging above the door. The tutorial diagram with arrows and labels on it. The splash-screen texture that says press any button. The little banner in the menu reading NEW. None of these live in your string table, so none of them appear in your word count, and none of them are in the file you hand a translator.

They are usually discovered by a player, in a screenshot, after release. Text baked into images is the most reliably forgotten part of a localization, and it is also the most expensive per word, because fixing it is art work rather than translation work — and art work that has to be repeated in every language, every time the art changes.

The way through it is not heroic effort. It is a list, a decision per asset, one of two mechanisms, and a design rule that stops the list from growing again.

Why baked text stays invisible until someone screenshots it

Every tool in a localization pipeline works on strings. Word counts, missing-translation reports, pseudolocalization, diffs between builds — all of them read text files. An image is an opaque blob to all of them. Nothing in your toolchain will ever flag a PNG whose pixels spell out SHOP.

It escapes human review too, and for a subtler reason. Whoever reviews the translated build is reading text, and the eye classifies artwork as scenery rather than content. If the reviewer happens to speak your source language, a sign in the source language does not register as untranslated at all — it just looks like part of the picture.

It also hides in more places than the obvious ones. Beyond logos and UI images, baked text turns up in sprite and UI atlases, particle and effect textures, textures applied to 3D props such as signs, posters and book covers, pre-rendered cutscene video, splash and loading screens, control and tutorial diagrams, labelled maps, achievement icons, in-game promotional banners, and anything a shader composes at runtime.

Build the inventory before deciding anything

You cannot scope or budget this without a list, and there is no tool that will produce the list for you. The search can be narrowed, though: sweep the art source folders, filter for filenames that suggest text such as logo, title, sign, banner or tutorial, and do one deliberate playthrough where somebody screenshots every distinct screen and reads the art rather than the words.

Record the same fields for every asset you find. The one that predicts cost most reliably is whether the layered source still exists — a flattened export whose original project file is gone means recreating the artwork from scratch, which is a different order of work from editing a text layer.

Do the sweep once, then keep the list alive. Every new asset containing text gets a row on the day it is made, not the day somebody spots it in a screenshot. That one habit is the difference between a single audit and a permanent archaeology problem that grows with the project, and it costs whoever made the asset about ten seconds.

• Asset path, and where in the game it appears
• The exact text visible in it
• Whether the player needs to read it to play, or it is decoration
• Whether the layered source file still exists, and which font it used
• The decision: localize, redesign to remove the text, or leave as-is

Decide per asset: localize, redesign, or leave it

Not everything containing text needs translating, and treating it as all-or-nothing is exactly how the task becomes too large to start. Sort each asset into one of three outcomes.

Localize what the player must read to play: tutorial and control diagrams, labelled maps, UI images containing words, anything that gives instructions or names a mechanic. If a player who cannot read the source language would be blocked or confused, it is not decoration.

Redesign what only contains text because text was convenient at the time. A button image with the word SHOP on it can become an icon; a labelled sign can become a symbol; a diagram can use numbers and shapes instead of captions. Removing the text once is permanently cheaper than translating it into every language forever, and it usually reads better as well.

Leave what belongs to the world. A neon sign in a fictional city, graffiti on a wall, a newspaper prop in the background, a shop front that is meant to feel foreign to the player — these are set dressing, and translating them can actively damage the atmosphere. Leaving them alone is a perfectly good decision, but it has to be a decision recorded in the inventory rather than an omission nobody noticed.

A quick test for the middle category: if the screen would still be understood with the text replaced by a plain shape, the text was decoration and you can design it away.

Two mechanisms: per-language assets, or text drawn over art

The first mechanism is one asset variant per language, selected at load time by a folder or filename convention. It gives complete typographic control, which is why it is the right answer for a title logo where the lettering is the design rather than a label on top of it. The costs are real though: asset count and memory multiply by the number of languages, every future art revision has to be redone once per language, a missing variant needs a defined fallback, and download size grows unless you can load only the active language.

The second mechanism is to ship the artwork without text and draw the string over it with your normal text system. One asset serves every language. The words flow through the pipeline you already have, which means they get counted, checked, reviewed and fixed like every other string, and changing the wording later costs nothing. The costs here are that the art needs a clean area to hold the text, the typography will be less bespoke than hand-lettering, and you have to leave room for the text to be longer in some languages than in your own.

Default to the second and reserve the first for the small number of pieces where the lettering genuinely is the artwork — in most projects that is the title logo and very little else. For signage there is a good hybrid: a stretchable nine-slice plate as art, with a normal text label drawn on it, so one asset covers signs of any width in any language.

// per-language asset, resolved by convention
art/ui/title_logo.en.png
art/ui/title_logo.ja.png
art/ui/title_logo.de.png

// text over art — one asset, one key
art/ui/sign_plate.png  +  key: shop.signLabel

Designing so you do not bake text in again

Most of what makes baked text expensive is decided at the moment the art is made, not at the moment someone tries to localize it. A handful of production rules removes most of the future cost:

• Keep text on its own layer, and keep the layered source in version control next to the exported asset
• Never flatten type; store the font file with the source and note the size, spacing and effects used
• Leave horizontal room, because a translated label frequently needs more width than the source did
• Avoid text on curved, rotated or perspective surfaces if it will ever need localizing — that is the most expensive shape to redo
• Avoid text inside animation frames or video, since localizing a video means re-rendering it once per language
• Use one naming convention for every asset that contains text, so the inventory can be regenerated by a search instead of a playthrough

What it costs, and what to check before shipping

The cost of baked text is not translation cost. It is artist hours multiplied by the number of languages, and then repeated every time the underlying art changes. A workable estimate is the number of assets you decided to localize, times languages, times the hours one variant takes — and then the same multiplier again for every future revision of that art. That recurring part is what turns a long list of baked-text assets into a cost you pay for years rather than once, and it is the real argument for shrinking the list aggressively before you start.

Video deserves to be called out separately, because it is the worst case by some distance. A pre-rendered sequence with text burned into the frames has to be re-rendered per language, which means the source project, the fonts, and somebody who knows how to operate that timeline all have to still be available every time a word changes — often years later. If a sequence will ever need localizing, carrying its text as a subtitle track or a runtime overlay is usually worth the loss of typographic control.

When the variants are made, the checks that actually catch problems are per-language and mostly visual:

• Every localized asset has a variant in every language, and a missing variant produces a visible, defined behaviour rather than silently falling back to source-language art
• Variants match the original dimensions, resolution and transparency — a variant exported at a different size shifts the layout around it
• Text drawn over art still fits its plate in the longest language, not only in the source language
• The font used for overlay text covers the target script at the size the artwork assumed, with no missing glyphs
• Video and pre-rendered cutscenes were re-checked separately, since they are usually produced outside the main asset pipeline
• A screenshot pass, per language, of every screen that contains a localized asset