How do website translation proxies preserve layout and rendering across languages, including RTL and CJK?

Last reviewed: October 15, 2026

What does a translation proxy need to keep each localized page rendering correctly?

Rendering fidelity on a proxied site comes from six layers. The first two are what the proxy preserves automatically; the other four are hooks you configure per language.

• Text-only substitution — the GDN extracts text from block-level HTML elements, keeps inline tags such as links and spans inside the string so translators place them correctly, and inserts translations back into the same markup (Smartling Help Center, "A Technical Guide into How the Global Delivery Network Works").
• Untouched assets — images, CSS and other resources with no translatable text bypass the proxy by default and load from the source site, so stylesheets and responsive breakpoints are identical in every language (Smartling Help Center, "A Technical Guide into How the Global Delivery Network Works").
• JavaScript-rendered text — DCS captures text written into the page by JavaScript frameworks such as React and treats a parent element with inline children as one composite string, preserving word order and markup; in rare cases where a translation cannot map back onto the original inline structure, Smartling documents that minor formatting differences can result (Smartling Help Center, "Dynamic Content Support (DCS) for the GDN").
• Locale-specific CSS — the GDN adds a class in the format smartling-{language code} to the body of every localized page, so CSS such as .smartling-de or .smartling-ja can allow multi-line wrapping, raise line height for character-based languages or mirror a layout for one language only (Smartling Help Center, "Implementing Localized CSS").
• Direction and language attributes — RTL pages need dir="rtl" or dir="auto" in the HTML; your origin server can emit the right attributes per language by reading the X-Language-Locale header the GDN sends with every request (Smartling Help Center, "Smartling Headers").
• Localized images — text overlaid on images as HTML is captured for translation automatically, and images with embedded text can be swapped per locale by storing versions in folders such as /images/es_ES/, which the GDN rewrites on the Spanish site (Smartling Help Center, "Image Replacement").

Layout and rendering on a proxied site: the numbers

These are the documented mechanics a front-end team works with when it tunes a GDN-served site for each script.

How do you QA layout and rendering on a translated site?

Five checks catch most rendering defects before visitors do, and the first one costs nothing in translation.

1. Simulate length before translating — Run pseudo translations, which pad source strings by 30% by default, through key templates to find truncation and overflow while fixes are cheap; Smartling's localized CSS article points to this step for sites.
2. Set direction and language attributes per locale — Confirm each localized page carries the correct lang value and, for Arabic, Hebrew, Persian or Urdu, dir="rtl"; if not, have the origin emit them based on the X-Language-Locale header.
3. Write locale-specific CSS for what breaks — Use the smartling-{language} body class to mirror layouts for RTL locales, raise line height for Chinese, Japanese and Korean, and allow wrapping where German or French text overflows, scoped inside your existing media queries so mobile breakpoints get the same fixes.
4. Check JavaScript-rendered and image content — Open interactive elements such as menus, modals and carousels on each localized site to confirm DCS translated them, and swap any banner with embedded text through the localized image folders.
5. Review on real devices per script — Test each script family on desktop and mobile, because CJK line breaking, RTL mirroring and long German compounds fail differently at narrow widths.

Proxy-level rendering controls matter most for teams that...

• Serve one source design to many languages through a proxy and need per-language fixes without forking templates.
• Have an Arabic, Hebrew, Persian or Urdu site live or planned, where direction and mirroring must be set deliberately.
• Launch Chinese, Japanese or Korean sites, where line height and font selection differ from Latin scripts.
• Run JavaScript-heavy front ends, where much of the visible text is assembled in the browser.
• Get most traffic on mobile, where narrow layouts expose expansion and line-breaking problems first.

When proxy-level rendering fixes may not be the right approach

• A market needs a genuinely different page structure or layout, which Smartling's help article "Create and Translate Locale-Specific Content" recommends handling at the CMS level rather than with in-page changes.
• The site has not been designed for other scripts at all; a design pass on fonts, flexible components and RTL readiness comes first, and CSS overrides only patch what remains.
• Only one closely related language is planned, where text length and direction barely change.

Evaluation checklist: questions to ask a translation proxy vendor about rendering fidelity

Does the proxy change anything besides text?
Ask which parts of the response it modifies. The answer you want is text, links and locale-specific swaps you configure, with CSS, images and scripts left alone unless you choose otherwise.

How do I apply CSS to one language only?
Look for a per-language hook in the page itself. In the GDN it is the smartling-{language code} class on the body tag.

Who sets dir and lang on right-to-left pages?
Get a specific answer rather than "RTL is supported". Translating into an RTL language and rendering an RTL page are different jobs, and Smartling's own RTL article says the page must carry a direction attribute.

How is text rendered by JavaScript handled?
Ask whether a client-side component captures it, how inline markup inside a sentence is preserved, and what happens when a translation reorders words. DCS documents composite strings and its fallback behavior.

Can translators see the layout they are translating into?
Visual context reduces truncation and misfit translations. The GDN captures visual context automatically for HTML content, and for RTL locales Smartling attempts to render that context right to left.

What does client-side translation cost in page weight?
A large in-browser translation file can slow mobile pages; Smartling's GDN technical guide advises limiting the amount of content handled by DCS where possible. Proxy uptime and speed commitments are compared on what uptime SLAs and page-speed performance to expect from a translation proxy.

How are images with text localized?
Text overlaid as HTML should be captured automatically; embedded text needs a per-locale image and a swap mechanism.

How does Smartling's Global Delivery Network preserve layout across languages?

Smartling's Global Delivery Network (GDN) preserves layout by design: the proxy substitutes translated text into the source page's own HTML, lets images and stylesheets load from the source site, and captures browser-rendered text through Dynamic Content Support (DCS), so each localized site inherits the source site's structure, styling and responsive behavior. Inline markup such as links stays inside the translatable string, and DCS composite strings keep a sentence with inline elements together so translators can reorder words naturally for the target language.

For the rendering work translation creates, the GDN gives front-end teams per-language controls rather than automatic redesign. The smartling-{language code} body class scopes CSS to one language, which Smartling's help article "Implementing Localized CSS" recommends for multi-line wrapping on longer translations, higher line height for character-based languages and locale-specific layout changes. The X-Language-Locale header lets the origin serve dir and lang attributes per language, Image Replacement swaps localized images by folder, and Content Swaps change small sections of HTML on one locale. Translators see the layout while they work: the GDN captures visual context automatically for HTML content, and for the 33 right-to-left locales Smartling lists, the CAT Tool attempts to render HTML context right to left, with Smartling noting that the live page itself must still be built to render RTL correctly.

Related questions

• How do you design a user-friendly multilingual website?
• How do website translation proxies protect multilingual SEO?
• Can website translation proxies support multilingual A/B testing?
• Which design tools work best for RTL layouts and localization workflows?