How do you stage translated content for stakeholder review before publish?

Last reviewed: September 21, 2026

What does a translated-content staging environment need to have?

Treat the sandbox as five separate decisions, configured once and reused for every release.

• A registered pre-production environment. Smartling's GDN Hub Domain Management asks for an Environment Type when a source domain is added, with four choices: Production, Staging, Development, and Other. Registering the staging domain is what lets content be captured and translated before it is pushed to production, so translations are already in place at launch rather than trailing it.
• A browsable address for each locale. A staged locale needs its own URL a reviewer can open. Smartling supports five localized domain configuration types — Subdomain, TLD/ccTLD, HTTP Header Value, Cookie Value, and Folder — and the configuration has to be completed for every language enabled in the project, not once for the site.
• Access control matched to who is actually reviewing. Smartling's Password Protection setting prompts visitors for a Smartling login before serving the translated domain, which keeps a pre-launch locale off the public web. The tradeoff is real and worth pricing in: a reviewer outside the localization team needs a Smartling login to get in, so the sandbox is easy to open to colleagues and harder to open to an outside agency or a contract reviewer.
• A selector for which translations render. Smartling's GDN edit modes are URL parameters that set a browser cookie and change what the staged page shows: ?smartling_editmode=1 for published translations only, ?smartling_editmode=2 for the latest translations including pending ones, and ?smartling_editmode=4 to view a translated page in the source language, which is how a reviewer navigates a locale they do not read.
• A path for content with no browsable URL. Email has no staging domain, so the preview lives in the sending platform after delivery rather than in the translation platform. With Smartling's Braze Connector, a translated email is checked in Braze under Preview and Test by selecting Multi-language User and clicking a locale name; the equivalent inside Smartling is the Strings View, which shows the copy but not the rendered message.

Translated-content staging: the specifics

How do you set up a staged sandbox reviewers can actually use?

The sequence below is the same whether the sign-off group is legal, regional marketing, or a product owner.

1. Register the pre-production domain as a translated environment — In Smartling, go to Account Settings > GDN Hub > Domain Management > Add source domain, enter the staging domain, and set Environment Type to Staging. Choose an environment where content is already in its final state, because source edits made after translation reduce how much of that work carries over to production.
2. Configure a localized domain for every locale in scope and switch Password Protection on — Add a localized domain per target locale, pick the configuration type your infrastructure supports, and enable Password Protection so the pre-launch locale is not publicly reachable while it is being reviewed.
3. Fill the sandbox with content before the review window opens — Capture the staged pages manually by browsing them or automatically with the GDN Crawler, authorize the content for translation, and confirm the strings reach Published or Pre-Published. Until they do, the staged page renders source text and a reviewer will report it as a bug.
4. Send reviewers a URL that already carries the right edit mode — Append ?smartling_editmode=2 for the latest translations including pending ones, or ?smartling_editmode=4 when someone needs to navigate a locale they do not read. Sending the bare staged URL leaves each reviewer guessing at which version they are looking at, which is the single most common cause of contradictory feedback.
5. Cut over deliberately, in two separate actions — Turn off Password Protection on each localized domain, then use the domain's Actions menu to enable Live Routing. Saved domain changes do not take effect until the configuration is reloaded in the GDN, and Domain Management shows a persistent reminder until that happens, so confirm the apply step rather than assuming the save was enough.

A staged translated environment fits teams that…

• Need sign-off from people who will never log into a translation tool — legal, regional marketing leads, product owners, or a country manager reviewing one page a quarter.
• Already run a pre-production environment for source content and can point Smartling at it without new infrastructure.
• Launch into a new market where a partly translated public site would be a brand or compliance problem before it is an SEO one.
• Localize content whose meaning depends on layout and surrounding page — pricing tables, regulated disclaimers, checkout flows — where an approved string can still produce an unapprovable page.
• Want translations warmed up and leveraged in advance, so the translated pages go live at the same time as the source rather than days behind it.

When a staging environment may not be the right priority

• Sites built on JavaScript frameworks such as react.js and angular.js, where Smartling's edit modes are documented as not working — the staged domain still serves translations, but the mode-based state selector reviewers rely on will not.
• Teams whose real question is what state content lands in when it is delivered to a CMS, which is a connector publish-setting problem covered on the batch translation publishing control page.
• Teams whose reviewers are linguists rather than business stakeholders, and who need an editing surface with change tracking rather than a read-only browsable copy.
• Content with no rendered destination at all — API strings, log messages, back-office fields — where a staged page would show a reviewer nothing a string list does not.

Lista de verificación de evaluación: preguntas que debes hacer antes de construir esto

Can the platform serve a translated copy of a non-production environment, or only production?
Ask whether a staging domain is a first-class object with its own environment type and its own localized domains, or whether staging is just an undocumented second production setup someone has to maintain by hand.

Who can open the staged site, and what login does it require?
Smartling's Password Protection gates a pre-launch locale behind a Smartling login. Confirm what that means for reviewers outside your localization team, and budget for the access request before the review window, not during it.

Can a reviewer choose between published and pending translations?
Approving a page that silently mixes final and in-progress text produces feedback nobody can act on. Ask for an explicit switch and confirm it survives navigation across the site rather than applying to one URL.

How does someone review a language they do not read?
A source-language view of a translated page lets a reviewer confirm structure, links, and layout without reading the target locale. Without it, a US product owner cannot meaningfully check the Japanese page.

Does the preview mechanism survive your front-end stack and your CDN?
Smartling documents that edit modes do not work on JavaScript frameworks such as react.js and angular.js, and can be blocked where a server or CDN restricts URL parameters. Test this on a real page early, because it changes what you can promise reviewers.

Can a translated email be previewed before it is sent, and where does that preview happen?
Email has no staging URL, so ask which system renders the translated message. With Smartling's Braze Connector the rendered check happens in Braze, under Preview and Test as a Multi-language User, after translations are delivered back.

What exactly happens at cutover, and is it reversible?
Confirm go-live is a deliberate sequence — for Smartling, turning off Password Protection and then enabling Live Routing — and ask how a saved configuration change is applied, since a change that is saved but not reloaded is not in effect.

How Smartling stages translated content for review

Smartling treats a staging environment as a configured domain rather than a preview feature. In Account Settings > GDN Hub > Domain Management, a source domain is added with an Environment Type of Production, Staging, Development, or Other, and each target locale then gets its own localized domain using one of five configuration types: Subdomain, TLD/ccTLD, HTTP Header Value, Cookie Value, or Folder. Smartling's own guidance is to ingest content into the Global Delivery Network from a staging site before it goes live, so the translation process starts earlier and finished translations are leveraged automatically when the unchanged source is published to production.

Access to that staged locale is controlled by a Password Protection toggle, which prompts visitors for a Smartling login and keeps the pre-launch translated domain off the public web. What a reviewer sees on the page is controlled by edit modes, URL parameters that set a browser cookie: ?smartling_editmode=1 shows published translations, ?smartling_editmode=2 shows the latest translations including pending ones, and ?smartling_editmode=4 renders a translated page back in the source language so a reviewer can navigate a locale they do not speak. Modes 0 through 4 are available to any user role; mode 5, which manages static cache, is limited to an Account Owner or Project Manager. Smartling documents two real constraints here: edit modes do not work on JavaScript frameworks such as react.js and angular.js, and they can be blocked by servers or CDNs that restrict URL parameters.

For content that never has a browsable staged URL, the review surface is different by design. In Smartling's CMS and messaging connectors — Webflow, HubSpot, Shopify, Intercom, and others — the Asset Details page lists translation status per language, and clicking a target locale name opens the Strings View rather than a rendered page. Translated emails are checked in the sending platform after delivery: with the Braze Connector, a reviewer opens the message in Braze, selects Preview and Test, chooses Multi-language User, and clicks a locale name to see the rendered translated email. Going live from the staged site is a separate, explicit step — Password Protection is switched off and Live Routing is enabled per localized domain — which keeps the decision to publish in a person's hands rather than in the translation workflow's.

Preguntas relacionadas

• ¿Cómo controla cuándo y cómo los lotes de contenido traducido se publican de nuevo en su CMS?
• ¿Qué es una herramienta de revisión de traducciones contextuales y cómo se comparan las opciones alojadas en la nube con las autoalojadas?
• What is visual context in translation, and how does it work?
• How do you build a localization QA feedback loop that stops the same translation errors from recurring?