Translate Text in Images: A Guide to Graphics Localization

The text fits the image - until you translate it¶

A product screenshot looks ready for a new market until the translated button label wraps onto two lines, the menu becomes cramped, and a callout covers part of the illustration. The words changed, but the graphic still assumes the original language.

Image localization means translating embedded text and adapting the visual asset so the translated version remains readable and coherent. The work isn’t just replacing one sentence with another. Someone has to identify every text element, preserve its meaning and reading order, fit it into the design, and check the final image.

A text layer in an editable design file is different from text printed into a flattened image. The editable layer can be changed as text. A PNG, JPEG, or screenshot usually stores the words as pixels, so software first has to recognize the characters before anyone can translate them.

That distinction affects the whole job: which tools you use, who needs to review the result, and whether you can reuse the existing layout. A one-off screenshot may need only a quick text extraction. A product manual, campaign, or set of diagrams needs a repeatable workflow and visual quality checks.

Google’s desktop guidance puts the underlying limitation plainly:

“Important: The translation accuracy depends on the clarity of the text. Translation of small, unclear, or stylized text may result in lower accuracy.”

The practical takeaway is simple: a translation tool can’t reliably translate characters it can’t read. Check the source image before choosing an automated route, especially when labels are small, decorative, or placed over a busy background.

The article focuses on commercial and product graphics: screenshots, infographics, diagrams, labels, and other visuals where the text is part of the asset. If your source is a scanned multi-page document rather than a graphic, the workflow may be closer to translating a scanned PDF in Trados Studio or translating a scanned PDF in memoQ.

What has to happen before a localized graphic is finished¶

Image translation is a three-part workflow: extract embedded text, translate the extracted content, then render the translation back into the image. Each part solves a different problem, and completing one doesn’t complete the job.

OCR stands for optical character recognition: software that reads letters and words from an image. OCR can return text along with coordinates that identify where the words appeared. Those coordinates help reconstruct order and placement, but they don’t automatically create a polished localized graphic.

Google Cloud distinguishes between general image text recognition and recognition designed for dense document text. The documentation describes TEXT_DETECTION as text extraction for images generally, while DOCUMENT_TEXT_DETECTION is optimized for dense text and documents. Both can return extracted text with location information such as bounding boxes, according to the Cloud Vision OCR documentation, checked 2026-10-14.

“TEXT_DETECTION detects and extracts text from any image.”

That description is useful when choosing an OCR approach for a graphic. General image text detection is aimed at text in images, while document-focused recognition is intended for denser page layouts. Neither label means that every stylized heading, curved label, or overlapping callout will be captured correctly.

For dense text, the same documentation describes a structured result that can include page, block, paragraph, word, and break information. That hierarchy can help a team determine which words belong together and how text should be read. A bounding box is a location clue, not a translation instruction or a design decision.

An API workflow also takes technical setup. The Cloud Vision REST example sends a POST request to the images:annotate endpoint with image content and a feature type such as TEXT_DETECTION; using the API requires a Google Cloud project and authentication, according to the Cloud Vision OCR documentation, checked 2026-10-14. A team that doesn’t need programmatic processing may prefer a desktop tool or a manual workflow.

The visual stage still needs a person to decide whether the result works. The translated sentence may be correct but too long for its box. An image with a textured background may show a visible patch after the original text is removed. A label may fit but lose emphasis if it no longer aligns with the diagram.

Treat extraction, translation, and rendering as separate deliverables. That makes it easier to identify the source of an error: OCR, language, or design. It also gives reviewers a clear checklist rather than asking them to approve a graphic without knowing what changed.

Choose a workflow based on the source files¶

The right workflow depends less on the image extension than on whether its text remains editable. A PNG may be an exported copy of a fully editable design, while a screenshot may be the only source anyone can find. Ask for the design file before committing to manual reconstruction.

When the editable design file exists¶

A layered design file stores text as editable objects. A designer or localization specialist can replace the source strings while preserving the rest of the composition. The team can adjust text size, line breaks, spacing, and positioning without painting over the original words.

Ask the design owner to provide the source file and any linked assets, then identify which text objects are part of the image. Some visible words may belong to icons or imported illustrations rather than separate text layers. Text that’s been converted to outlines may look sharp but no longer behave like ordinary editable text.

A file with editable layers is usually easier to revise than a flattened export, but editable doesn’t mean finished. The translated wording still needs context, and the graphic still needs a layout check. If the target language uses longer phrasing, the designer may need to widen a text area, reflow a callout, or rearrange nearby elements. For guidance on one common layout issue, see text expansion from English to German.

When only a flattened image exists¶

A flattened image stores text as pixels rather than editable words. OCR can read those pixels and provide text for translation, but a designer or suitable tool still needs to remove or cover the source text and place the translation in the graphic.

A clear, simple background is easier to repair than a photograph or a detailed illustration. A flat color can often be recreated without changing the image’s look. A complex background may require careful retouching because removing the text can also remove texture or part of the artwork.

A direct image-translation tool can be useful when someone needs to understand a graphic quickly. Google Translate’s desktop Images tab accepts an image file after the user selects source and target languages or uses language detection. Google says users can display the original alongside the translated image, copy extracted translated text, or download the translated image; the behavior was described on its help page checked 2026-10-14 (Google Translate Help). Treat that as a quick translation route, not proof that a finished marketing asset meets design standards.

For a phone-based check, Google Translate’s Android app can work from an existing image in the device gallery or text captured with the camera. Users can select portions of text in an image, then copy translated text, listen to it, search it, or send it to Translate Home. Camera translation can work offline after downloading the required languages, according to Google’s Android help page checked 2026-10-14. Product behavior can change, so check the current instructions before building an operational process around the feature.

When you’re processing a batch¶

Bulk image localization needs a way to connect each extracted string to its asset and location. A spreadsheet or content-management system can record the filename, source text, target text, language, reviewer, and approval status. The goal is to prevent a correct translation from ending up in the wrong screenshot or release folder.

For automated extraction, the Cloud Vision documentation distinguishes image text detection from document text detection and describes location data in its OCR results. Azure’s documentation makes a similar workflow distinction: synchronous Image Analysis OCR is positioned for lighter, non-document image scenarios, while text-heavy digital or scanned documents are directed to Document Intelligence Read OCR. The current guidance was checked on 2026-10-14 (Azure Vision OCR documentation).

A batch process still needs human review. OCR output can miss a label or split a phrase in an unexpected way, and a machine translation can’t infer every product-specific meaning from a short string. Build review into the process rather than treating a successful export as approval.

Compare the available options¶

No single option handles every source file, volume, and quality requirement. Compare what each route returns: extracted text, translated text, a rebuilt image, or an editable document.

For teams already using an OCR API, Google’s Cloud Vision example describes sending image content and a feature type to an annotation endpoint. Azure separates lighter image OCR from text-heavy document recognition. Those are different product approaches, not a universal ranking: match the OCR service to the source material and test it on representative assets before you standardize a workflow.

ChatsControl is another option when the asset is really a scanned document or photo that needs a formatted document output, rather than a standalone marketing graphic. In ChatsControl, you upload a scan or image; OCR reads the page and the service builds a formatted Word copy that follows its layout before translating it. That’s useful for forms and document pages where tables, labels, and page structure matter. It isn’t a full graphics editor, and handwriting or very degraded scans remain unreliable, so a flattened infographic that needs precise art direction still calls for design work.

For document jobs, the product’s bilingual review view shows source and translation together, with translated text highlighted and the original available on hover. That can help a reviewer check text in context, but it doesn’t replace checking a separately rendered image. Choose the output you actually need: a translated document, a set of translated strings, or a localized graphic.

A practical process from source file to approved asset¶

A repeatable process prevents teams from treating OCR output as the final deliverable. Start with the source file, keep extracted content tied to its location, and approve the rendered graphic rather than just the translation.

1. Collect the source files. Ask for the editable design file first. If the team only has a PNG, JPEG, or screenshot, preserve the original and record which asset it belongs to. A clear filename and version label help prevent a translated graphic from replacing the wrong source.
2. Inventory the visible text. List headings, labels, button text, footnotes, legends, and text inside charts or diagrams. Don’t assume that OCR has found everything. A quick manual scan of the image can reveal small annotations or a label integrated into an illustration.
3. Extract the strings. Read editable text objects from the design file, or use OCR for a flattened image. Keep the original text and its location together. When an OCR tool returns boxes or polygons, use them to help preserve grouping and reading order.
4. Check the extraction. Compare every recognized string with the image. Correct character errors, restore punctuation, and note any text that can’t be read confidently. Don’t silently guess at a product name or a value in a diagram.
5. Translate with context. Tell the translator what the asset is for and what each short string labels. A button, a chart legend, and a safety warning may need different wording even when the source text is brief. Keep approved terminology consistent across related graphics.
6. Place the translation. Replace editable text in the design file when possible. For a flattened image, remove or cover the original words, repair the background, and add the translation in an appropriate text layer.
7. Review the rendered asset. Check correctness, completeness, reading order, fit, hierarchy, and background artifacts. Review the actual export, not just the working file, because rendering can change how the text appears.
8. Record approval and version. Save the approved language, reviewer, asset version, and final output together. If a string changes later, the record helps the team find every graphic that uses it.

A translation brief can improve consistency when a project has established product terms, a specific audience, or a house tone. Include the intended use of the asset, the role of each label, and any words that shouldn’t be translated. For a related approach to improving translation input, see pre-editing source text for machine translation.

Keep text segments short where possible, but don’t shorten a warning or label until the meaning has been checked. A space-saving edit can change an instruction. If the target language doesn’t fit, ask whether the design can expand or reflow before compressing the language.

Where image localization breaks down¶

The most expensive mistakes often happen between stages. OCR can return plausible text that’s wrong, translation can be accurate but unsuitable for the design, and a visually polished export can still omit a small label.

“DOCUMENT_TEXT_DETECTION also extracts text from an image, but the response is optimized for dense text and documents.”

The distinction matters when a team has both graphics and page-like assets. A dense table or scanned page may need a document-oriented recognition result that preserves grouping. A sparse illustration with labels is a different image-recognition problem. Google’s description doesn’t promise perfect extraction in either case; it explains the purpose of the two modes (Cloud Vision OCR documentation, checked 2026-10-14).

Watch for these common failure points:

• Small or stylized type. Decorative fonts and low-clarity text are harder to recognize. Google specifically warns that clarity affects image-translation accuracy and that small, unclear, or stylized text may yield lower accuracy (Google Translate Help, checked 2026-10-14).
• Angled or curved text. A label that isn’t set on a straight line may be harder to extract and place in the right order. Check it against the source rather than assuming that every recognized word belongs to the nearest box.
• Overlapping elements. Text over an icon, photograph, or other label can confuse extraction. Review both the character and its association with the visual element.
• Dense tables and diagram labels. Closely packed text can be read in the wrong sequence. Group related cells, legends, or labels before translation.
• Handwriting. Handwritten notes don’t behave like clean printed labels. Route uncertain text for a human reading rather than filling a gap with a guess.
• Background repair. Removing text from a flat color is different from reconstructing a photograph or textured illustration. Zoom in on the repair area and look for smudges, repeated patterns, or visible patches.
• Text expansion and line breaks. A translation may take more room than the source. Don’t reduce type until it becomes hard to read; explore a wider box, a different break, or a revised composition.
• Lost reading order. A graphic can contain numbered steps, a legend, or a flow that depends on a particular sequence. Check that the translation follows the visual path intended by the designer.

A useful review checklist is short enough to apply to every export:

Cloud Vision’s OCR results can include detected text and location data, and Azure Read OCR describes recognized lines and words with bounding polygons. Those data points can help reviewers locate text, but visual approval remains a separate task. For teams checking a machine-translated document before release, client-ready documents versus translated text explains why a translated string alone isn’t the same as a finished deliverable.

FAQ¶

How do you translate text inside an image and keep the original layout?¶

Use the editable design file when it’s available, translate the text objects, and adjust the composition for the target language. For a flattened image, use OCR to extract the text, translate it, then rebuild the graphic and check the finished layout.

How can I translate text in a PNG or JPEG?¶

A direct image-translation tool can help you understand a one-off image. For a publishable asset, extract and verify the strings, translate them with context, place them back into the graphic, and review the exported image.

How accurate is OCR for small or stylized text in images?¶

OCR accuracy depends on how clearly the image presents the text. Google warns that small, unclear, or stylized text may yield lower image-translation accuracy, so compare extracted strings with the original before relying on them (Google Translate Help, guidance checked 2026-10-14).

Can I translate screenshots and graphics in bulk?¶

Yes. A batch workflow can use OCR to extract strings, a translation process to handle the language, and a rendering step to rebuild each asset. Keep each string connected to its filename and location, and include human review before release.

Do I need a designer to localize an infographic?¶

A designer is especially useful when text needs to move, the background needs repair, or translated strings don’t fit the existing layout. An editable source file makes those changes easier; a flattened image may require more manual work.

Can a translated image be published without visual review?¶

A translated image should be checked before publication. Reviewers need to confirm completeness, wording, reading order, fit, visual hierarchy, background repair, and the final export, because OCR and translation don’t make those design decisions automatically.