Handling Graphics on Multilingual Sites: Inline SVG, Image Localization, and Where Translation Stops

Bottom line first: The most common half-finished multilingual site is one where the pages are translated but the images aren’t. Text baked into bitmaps can’t be edited, costs a lot to redo, and doubles your file sizes. Of the four approaches, inline SVG with both languages in one file is the least work: the same image carries two sets of text, shown or hidden by language, with the whole block excluded from translation. The catch is that your layout has to allow 1.3 to 1.5x padding for English running longer than Chinese.

1. Pages translated, images not: the most common half-finished multilingual site

The first thing clients notice after a multilingual site goes live isn’t the grammar, it’s the images. An English page with a few flowcharts still labeled in Chinese tells the client immediately that this is a “translated version.”

The four half-finished patterns differ in how often they show up and what they cost:

Page area	Result of translating text only	How buyers react	How often it happens
Body images with Chinese labels	Labels are unreadable, readers guess from context	Content feels incomplete	Highest
Flowcharts and topology diagrams	The whole image becomes a puzzle	They suspect the site was thrown together	High
Product spec diagrams	Units and scales can’t be read	They won’t pick a model from the diagram	Medium

The subtler problem: text inside images can’t be read by search engines or by AI. If an image carries a three-layer structure that only the image explains, that information simply doesn’t exist to any machine. Localizing diagrams therefore solves two things at once: people understand them, and machines can read them.

When this doesn’t apply: If your site only has Chinese and English, and English visitors are mostly existing customers and dealer channels, images can wait behind product pages and certification pages. But if the English site is meant to capture search traffic from strangers, Chinese labels in your images are a real liability.

2. Why text in images is hard to handle: the cost of four approaches

Text in bitmaps can’t be edited, and that’s where all the trouble starts: the text has been flattened into pixels, so changing it means going back to the design source file and redoing it.

The bitmap approach has three specific problems:

Problem	Why	Cost
Text can’t be edited	The text is already pixels	Every change means going back to the design source file
File sizes double	One file per language	Your image library has as many files as images times languages
Versions fall out of sync	Chinese and English versions maintained separately	You update a spec in the Chinese version, the English version still shows the old number

Here’s how the four approaches trade off, and this table settles about 80% of the decision:

Solution	How to do it	One-time cost	Long-term maintenance	When it applies
Translated bitmap	Export one image per language	Medium, it’s a full redo	High, every change means redoing it	Complex, terminology-heavy diagrams
Inline SVG, bilingual	One image, two sets of text, shown or hidden by language	High — needs developer support	Low — change one place and it applies to every language	Structure diagrams, flowcharts, table-style image cards
Move text out of the image	Draw only the structure in the image; put the text in the page copy	Medium — requires re-layout	Low	Simple diagrams, arrow diagrams
Leave as is	Keep the original image	zero	zero	Decorative images, plain product photos

There is only one question when choosing an approach: will this image change later? For a complex infographic that won’t change within two years, two sets of bitmaps is the least hassle. If parameters, flows or names may still change, go with inline SVG or move the text out of the image. Plain product photos are the fourth case — there is no text to handle, so don’t spend budget on them.

3. Inline SVG with both languages: one image, two sets of text

The advantage of inline SVG is that text stays text, not pixels. Put Chinese and English in the same image and let the page language decide which set shows — no need to maintain two files.

Implementation notes	How to do it	Why we do it this way
Both sets of text share one source	Chinese and English appear as pairs in the same image	Change one place and you won’t miss the other language
Show or hide by language	The page root element carries the current language code, each set of text carries its matching code, and styles control what is shown and hidden	No need to generate a new file for each language
Block translation for the whole image	Mark the entire image as do-not-translate	Stops translation plugins from translating both sets of text again
Validate length at generation time	Check for overflow against the real length in both languages when the image is generated	Fixing overflow after launch costs far more
One file per image	One image, one file — don’t split by language	Decouples the number of image files from the number of languages

“Block translation for the whole image” is the easiest rule to miss. Without the marker, a translation plugin treats the Chinese labels in the image as body text and translates them into English, so the English page shows both the translated English and the English that was already there, stacked on top of each other, and the image is ruined. This problem is very common on sites that rely on plugins for automatic translation.

There is a naming rule to go with it: image filenames and alt text should not carry a language suffix. A suffix means a new batch of files for every language you add, so your image library grows along with your language count, and it becomes hard to tell which images are still in use when you clean up. Alt text should describe what the image shows, not what language it is in.

4. English runs 1.3 to 1.5 times longer than Chinese — leave room for that in your layout

This is the one number to remember from this article: a row of labels that just fits on a Chinese page usually runs 1.3 to 1.5 times longer in English, and short labels are worse.

Text type	Chinese length	Typical English multiple	Description
Short labels, 4 characters or fewer	For example, four characters	1.6 to 2.0 times	The shorter it is, the less predictable — and the more it expands
Medium phrases, 8 to 15 characters	A short description that fits on one line	1.3 to 1.5 times	The most typical range
Full sentences, 20 characters or more	A complete sentence	1.2 to 1.4 times	With context, the ratio actually drops
Text containing abbreviations or model numbers	e.g. parameter abbreviations	Close to 1.0 times	Model numbers and units stay untranslated, so length barely changes

Languages like German and Russian run even longer, usually another 10% to 20% on top of English. If you plan to launch a German site, budget the extra space for German, not just English.

Once you know the multiplier, you still need to turn it into concrete spacing rules, or the number is useless:

Element type	Minimum font size	How to calculate available width	Minimum clearance
Card title	No smaller than 15 pt	Card width minus 12 px padding on each side	Reserve 40% of the width as free space
Card body line	No smaller than 12 pt	Distance to the left edge of the next column	Reserve 45% of the width as free space
Axis and tick labels	No smaller than 10 pt	Distance to the next tick	Reserve 50%, switch to two lines if needed
Legend and footnotes	No smaller than 10 pt	Distance to the right edge of the text block	Reserve 35% for extra-long abbreviations

Use the extra space to wrap, not to shrink the font. If it doesn’t fit on one line, move it to a second line and let it grow up and down from the original baseline. Only if it doesn’t fit vertically either should you reduce the font size, and never below the minimum in the table above. Don’t reverse this order — shrinking the font first makes the English version a size smaller than the Chinese, so the two languages carry different visual weight.

Overflow shows up in three ways, and each needs a different fix:

Type of overflow	What it looks like	How to handle it
Horizontal overflow	Text runs into the neighboring card	Wrap based on the distance to the neighbor, don’t shrink the font
Vertical overlap	Multiple lines cover the line below	Reserve line height at 1.3 to 1.4 times the font size
Card overflow	Text spills past the card edge	Add padding first, then consider making the card taller

5. Localizing tables: column widths, numbers, units, dates

Tables are trickier than graphics because they’re alive: column widths change with the content, and the content changes with the language. Five things go wrong most often:

Checklist	FAQ	Handling rule
Column width	A narrow column sized for Chinese forces the English header onto two lines	Redistribute column widths based on English header length
Number format	Comma thousands separators mixed with space thousands separators	Standardize to the target language’s convention, one rule per site
Units	Chinese headers include units, English headers drop them	Put units in the header, not in the data cells
Dates	Year-month-day order is read differently across locales	Use a four-digit year plus an English month abbreviation, avoid all-numeric dates
Overlong translations wrap	Cell text makes the whole row taller	Allow wrapping but cap it at two lines; beyond that, use a shorter header

Numbers and units are where the landmines are. Decide the rules up front for these common differences:

Content	Common in Chinese	Common in English-speaking regions	Watch out for
Thousands separator	10,000 or 10000	10,000	Don’t mix up the decimal point and the thousands separator
Decimal	0.5	0.5 or .5	Never use a comma as a decimal point
Dimensions	200 mm	200 mm	Leave a space before the unit symbol
Temperature	20 °C	20 °C	Leave a space between the degree symbol and the letter
Range	10 to 20	10 to 20 or 10–20	Use a hyphen or en dash consistently
Currency	CNY 30,000	CNY 30,000	No line break between currency and amount

Test how tables behave on mobile separately. You can let them scroll horizontally, or convert them into cards. What you want to avoid is shrinking the whole table to fit the screen, because the font becomes too small to read. The test: can you read the table headers on a phone without zooming in?

6. What must be translated in images, and what must never be translated

You can’t apply one rule to everything inside an image. Each type is handled differently:

Content type	Translate?	Reason
Data labels, axis descriptions, legends	Translation	These are key to understanding the chart. Skip them and the chart is useless.
Process nodes, module names	Translation	This is body content and maps one-to-one with the page text
Brand names and company names	Do not translate	A brand name has one correct spelling. Translating it creates inconsistency.
Product model numbers and serial numbers	Do not translate	Model numbers are anchors for cross-language search. Translate them and they can’t be found.
Unit symbols and formulas	Do not translate, but follow the typographic conventions of each language	The symbols themselves are universal; spacing and notation follow regional conventions
Certification and standard numbers	Do not translate	Numbers are fixed external identifiers

One test works here: if a customer searching in another language can’t find the equivalent of this text, don’t translate it. Model numbers, ID numbers and brand names fall into this extreme category.

There is one more consistency rule: the terms in the images must match the glossary. If the same parameter is called “travel” in one place on the English page and “stroke” in another, readers will assume these are two different parameters. For a multilingual site, build the glossary first, then localize the images. Get the order wrong and you will redo the work again and again. The same logic applies to how you handle parameter definitions, so you can compare the two./insight/13-product-catalog-filter-search-experience/.

7. QA checklist: four checks for every image in every language

QA can’t just look at the Chinese version. The approach is four checks for every image in every language. Anything that fails doesn’t go live.

Checklist	Test	Fix for failure
Overflow	Text stays inside the card and doesn’t press against neighboring elements	Break the line; if there’s not enough vertical space, reduce the font size
Overlap	No overlap between lines of text, or between text and graphics	Adjust line height or make the container taller
Font size	Not smaller than the minimum font size for that element	Shorten the copy instead of shrinking the font further
Card overflow	Padding between text and border is at least 12 pixels	Add padding or widen the card

When to just make two sets of images

Situation	Rationale	Recommended approach
Terminology-heavy process diagrams	More than 20 technical terms in one image	Two sets of bitmaps, checked by someone fluent in both languages
Complex multi-layer infographics	More than four levels of hierarchy in the image	Split into several simple images, then use bilingual SVG
3D-rendered product cross-sections	Text distorts along curved surfaces	Two sets of bitmaps, rendered once per language
Images destined for print	Print materials don’t accept SVG	Two sets of bitmaps, keep high-resolution source files
Client-specified image and text layout	Layout is locked by the client	Two sets of bitmaps, to avoid changing the layout

The logic is straightforward: the more complex the information in an image, the more it relies on manual verification, and the more it needs to be delivered off-site, the more you should make two sets of images. Conversely, structural diagrams, process cards, and comparison charts used on-site should always use bilingual SVG, which cuts maintenance costs by an order of magnitude. For images and files in the delivery stage, check against the list in /site/ For trust pages and credential displays, you can follow the credibility writing approach in /insight/09-trust-pages-ai-credibility-evidence/ You can also send your existing chart inventory to /contact/ for a language-by-language audit.

FAQ

Should text in images be translated?

It depends on what the image does. Images that carry data labels, process nodes, or legends must be translated; without translation, the image is useless. Pure product photos, decorative graphics, and brand-only images don’t need translation. A practical test: cover up the text in the image. If readers can’t understand what the image is about, that text must be translated. Brand names, product model numbers, and certification numbers are never translated; they are anchors for cross-language search.

Bitmap or inline SVG?

Decide based on “will this image change again?” For complex infographics that won’t change within two years, two sets of bitmaps are the easiest option: low development cost, no compatibility issues. If parameters, processes, or names will still change, use inline SVG with bilingual coexistence: one image holds two sets of text, and one edit applies to all languages. A middle ground is to draw only the structure in the image and let the page carry the text, which suits arrow diagrams and simple schematics. The cost of choosing wrong shows up every time you need to redo the work for each change.

What if the English translation gets longer and doesn’t fit?

Allow 1.3 to 1.5 times the Chinese length for English, and 1.6 to 2.0 times for short labels; the shorter the label, the less accurate the estimate. The first fix when it doesn’t fit is line wrapping, growing vertically from the original baseline. Only if it still doesn’t fit vertically should you reduce the font size, and never below the minimum for each element. Don’t reverse the order; shrinking the font first makes the entire English version one size smaller. If you plan to add German, calculate the allowance based on German, which typically needs another 10% to 20% on top of English.

Do translation plugins automatically translate text in images?

They don’t automatically translate text in bitmaps; that’s pixels. But they treat text in inline SVG as body content. Without a no-translate tag, the plugin will translate the existing English again, and two overlapping sets of text will appear on the English page. The solution is to mark the entire image as no-translate and build both sets of text in during generation. This is most likely to cause problems on sites that rely on plugin auto-translation, so be sure to spot-check each language before launch.

What if a table doesn’t fit on mobile?

Fix the structure before you touch the styling. Keep table headers to two to four characters where you can, put units in the header rather than in the data cells, and consider splitting any table with more than five columns into two. For styling, horizontal scrolling or a card layout both work. What you want to avoid is scaling the whole table down to fit the screen, because the font ends up too small to read. The test is simple: can you read the headers on a phone without zooming in? If not, it fails.

Do I have to redo the graphics every time I add a language?

With bilingual SVG you don’t redo the graphics, but you do need to add a text set for each new language and re-check the layout against that language’s length. The work is in the copy and the checking, not the drawing. With a bitmap approach you export a separate image for every language, so the work scales with the number of images. So the order of decisions is: first confirm how many languages the site will support, then choose the chart approach. If you plan to go from two languages to five within two years, starting with bilingual SVG saves a lot of rework.

Final thoughts

Chart localization looks like a design problem, but it’s really a structural one. Bitmaps weld the text into the pixels, so every new language means redoing the whole thing; embedded SVG leaves the text in a place you can swap out, so the cost barely changes as languages are added. The difference between the two approaches doesn’t show up now, it shows up at the third redesign.

There are only two things you need to settle up front: will this chart change again later, and how much longer is English than Chinese. The first decides the approach, the second decides the headroom. Both have an answer before you start; discovering them after launch usually means redoing the work.

One line to remember: keep the text in the chart somewhere you can swap it out, and leave layout headroom for English running 1.3 to 1.5 times the length of Chinese.