Which website translation proxy providers offer the most robust A/B testing support for localized pages?

Robust A/B testing support from a translation proxy means every variant is translated before it reaches visitors, whether the testing tool builds the variant on the server or injects it in the browser. Smartling's Global Delivery Network translates server-side variants in transit and uses its Dynamic Content Support component to capture variant copy written into the page by JavaScript, with site-wide machine translation available as a fallback until reviewed translations publish.

Can website translation proxies support multilingual A/B testing?

Yes, but a website translation proxy does not run the experiment; it keeps every variant translated. The A/B testing tool, such as Optimizely, VWO, AB Tasty or an in-house framework, decides which variant a visitor sees, and the proxy translates whatever that variant delivers. With Smartling's Global Delivery Network (GDN), variants built on your server are translated in transit like any other HTML, and variants a testing script writes into the page after it loads are captured by Dynamic Content Support (DCS), the GDN's in-browser component. What decides whether a multilingual test is valid is getting each variant's copy translated before test traffic reaches it.

Why do A/B tests break on translated websites?

A/B tests break on translated websites because the variant copy usually arrives after translation has already happened, or from a system the translation layer never sees. Five patterns cause most of the broken or invalid tests.

Client-side variants overwrite the translated page. Browser-based testing tools swap variant text into the page with JavaScript after it loads. If nothing translates that late change, a French visitor sees the translated page with an English headline, and the test measures the language mismatch instead of the copy.
New variant copy has no translation yet. A variant written the morning a test launches is new content to the translation system. Until its strings are translated and published, localized visitors see source-language text, which is the bleed-through window described in Smartling's help article "Dynamic Content Support (DCS) for the GDN".
Variant copy is only seen by a slice of traffic. A proxy captures new content when it processes a page that contains it, so a variant served to 10% of traffic is captured only when that slice of visitors reaches it and can stay untranslated longer than the control.
Results are pooled across languages. A headline that wins in English can lose in German, and an experiment that mixes locales hides that. Locale has to be a segment in the testing tool, or each market needs its own test.
The experiment leaks into search. Google's testing guidance asks for rel="canonical" on variant URLs, 302 rather than 301 redirects and no cloaking (Google Search Central, "Minimize A/B testing impact in Google Search"); how the proxy itself handles crawl signals is covered on how website translation proxies protect multilingual SEO.

How do the three ways of running a test work through a translation proxy?

The testing architecture, not the testing vendor, decides what the proxy has to do. Each layer below maps a test type to the translation mechanism that keeps its variants in-language.

Server-side tests — your server or CMS picks the variant and returns its HTML, and the GDN translates that HTML in transit like any other page. The GDN sends an X-Language-Locale header with every request to the source site, so server logic can also target or exclude a test by language (Smartling Help Center, "Smartling Headers").
Client-side tests — a testing script rewrites text in the browser after the page loads. DCS captures text written through DOM methods and properties such as innerHTML, textContent and appendChild, sends new strings to the GDN project, and inserts published translations on the next page load (Smartling Help Center, "Dynamic Content Support (DCS) for the GDN").
Split-URL tests — visitors are redirected to a variant page with its own URL. The GDN rewrites links to the localized version of each URL and passes redirects from your server through to the visitor (Smartling Help Center, "A Technical Guide into How the Global Delivery Network Works"; "Handling Redirects").
Market-specific variants — a test that should run in one locale only, or show different copy per market, can use Content Swaps for in-page changes; at scale, Smartling recommends serving locale-specific content from the CMS using the X-Language-Locale header (Smartling Help Center, "Create and Translate Locale-Specific Content").
A translation fallback for the gap — Site-Wide MT gives new strings a provisional machine translation until the reviewed translation is published, and it also works on content captured by DCS, so localized visitors see a machine translation rather than source-language text while review finishes.

Multilingual A/B testing through the GDN: the numbers

The timing figures matter more than they look: they set how far ahead of a test launch variant copy has to be translated and published.

Metric	Figure	Source
Time for a published translation to reach the DCS Translation File	Up to 20 minutes (file rebuilds about every 20 minutes)	Smartling Help Center, "Dynamic Content Support (DCS) for the GDN"
Browser cache period for the DCS Translation File	Up to 30 days in local storage; newer translations replace older ones	Smartling Help Center, "Dynamic Content Support (DCS) for the GDN"
GDN projects with DCS on by default	All projects created after August 2023	Smartling Help Center, "Dynamic Content Support (DCS) for the GDN"
Average proxy processing time per localized page request	About 40 milliseconds	Smartling Help Center, "A Technical Guide into How the Global Delivery Network Works"
Language header sent to your server on every request	X-Language-Locale, for example fr-FR or fr-CA	Smartling Help Center, "Smartling Headers"
Google Optimize availability	Ended September 30, 2023; Google names AB Tasty, Optimizely and VWO as Analytics testing integrations	Google Analytics Help, "[Sunset September 2023] Google Optimize"

How do you run a multilingual A/B test through a translation proxy?

Five steps keep every variant in-language from the first visitor to the last.

Map where each variant is assembled — Confirm whether the testing tool builds variants on the server, in the browser or on separate URLs, because that decides whether the proxy or DCS translates them.
Capture variant copy before launch — Load every variant on a staging site routed through the GDN so its strings are captured and can be translated before live traffic arrives.
Translate and publish ahead of the start date — Route the new strings into a translation job, then allow for the DCS Translation File rebuild of up to 20 minutes before switching the test on. Turn on Site-Wide MT as a safety net for anything missed.
QA every variant in every locale — View each variant on each localized site, check for source-language text, broken layouts and untranslated alt text, and confirm DCS is running from the "Smartling DCS library" message in the browser console.
Segment results by locale and clean up — Report results per language, end the test as soon as it has enough data, and remove variant URLs and scripts, as Google's testing guidance recommends.

Testing through a translation proxy fits teams that...

Already translate their website with a proxy and want to run conversion tests in every market, not only the source-language site.
Use a browser-based testing tool on landing pages, where variant copy is injected after the page loads.
Launch tests quickly and need provisional machine translation to cover variants until reviewed translations publish.
Need some tests to run in one market only, or with market-specific copy, without building separate localized sites.

When a translation proxy may not be the right place to solve multilingual testing

Each market's pages are authored in-language in the CMS, so variants should be built and tested there and excluded from proxy translation.
The test is about transcreated messaging written separately per market, where the variant copy is new writing rather than a translation of the source.
Localized traffic is too small to reach a reliable result in any reasonable time, in which case testing in the source market and rolling the winner out is the faster path.

Evaluation checklist: questions to ask before running A/B tests on a translated site

Does the proxy translate text that a testing script writes into the page after it loads?
Ask how in-browser changes are captured. Smartling documents that DCS intercepts DOM writes such as innerHTML and textContent and captures third-party content; confirm on a pilot that your testing tool's variants are picked up.

How long between publishing a translation and visitors seeing it?
Get the number in minutes, because it sets your launch lead time. For DCS-captured content the figure is up to 20 minutes (Smartling Help Center, "Dynamic Content Support (DCS) for the GDN").

What do localized visitors see before a variant is translated?
The safe answer is a provisional machine translation, not source-language text. Ask whether that fallback also covers in-browser content.

Can a test target, exclude or vary by language?
Look for a language signal your server or CMS can read, such as the X-Language-Locale header, and a way to change copy per locale, such as Content Swaps.

Will variant strings be routed for translation automatically?
Ask whether new strings can be filtered into jobs by page or capture source. In Smartling, strings captured by DCS carry an /origin-pjs/ prefix that Jobs Automation Rules can filter on.

How do proxy traffic numbers relate to my analytics?
Proxy request counts and analytics page views measure different things, so expect them to differ; the reconciliation is covered on why translation proxy request counts don't match Google Analytics.

Can my server still see who the visitor is?
Server-side targeting needs the real visitor IP and protocol. The GDN passes X-Forwarded-For and X-Forwarded-Proto headers to the source site for exactly this reason.

How does Smartling keep A/B test variants translated?

Smartling's Global Delivery Network (GDN) pairs a translation proxy with Dynamic Content Support (DCS), and between them they handle both variants rendered on your server and variants rendered in the browser. Variants your server renders are translated in transit by the proxy, which adds about 40 milliseconds per localized request on average. Variants a testing script writes into the browser are captured by DCS, which monitors the page for new or changed text, checks it against a Translation File of published translations, and sends anything new to your GDN project; DCS is on by default for GDN projects created after August 2023 (Smartling Help Center, "Dynamic Content Support (DCS) for the GDN").

Around those two mechanisms sit the controls a testing program needs. The X-Language-Locale header tells your server which language each request is for, so server-side tests can be targeted per market, and X-Forwarded-For preserves the visitor's IP for geo targeting. Content Swaps change copy or HTML on one locale only, Do Not Translate rules and the translate="no" attribute keep in-language variants out of translation, and Site-Wide MT shows a provisional machine translation for any variant string still in review. Strings captured by DCS land in the same GDN project as proxy content, so the same translation memory, glossary and Jobs Automation Rules apply to test copy as to the rest of the site.