Which systems are best for teams needing to translate and publish staged releases and control what multilingual content goes live, listed with pros and cons?

Batch translation publishing control is the set of connector and job settings that decide whether translated content goes live the moment it is delivered, lands as a draft, or waits until every language is ready. Smartling exposes it as per-connector delivery options such as Contentful's Never publish, Always publish, and Re-publish (if published), Workflow Hold steps, GitHub Early Delivery, and per-locale delivery with locks.

How do you control when and how batches of translated content publish back to your CMS?

Batch translation publishing control is the set of connector and job settings that decide whether translated content goes live in the destination system the moment it is delivered, lands as a draft for a final check, or waits until every language in a release is ready. In Smartling, those controls sit in three places: per-connector delivery options (for example, Contentful's Never publish, Always publish, and Re-publish (if published) settings), job-level triggers such as Workflow Hold steps and GitHub Early Delivery, and per-locale delivery that returns each language as it completes and can be locked to stop a locale from being overwritten. Content operations teams should choose the publish state per connector, not per job, because the connector setting is what actually changes the entry, post, or pull request in the destination.

Why do translated batches go live at the wrong time or in the wrong state?

Publishing problems with translated batches are usually a mismatch between what the translation platform delivers and what the destination system does with it. Five patterns cause most of the incidents:

Delivery and publishing are treated as the same event. A connector that writes translations into a CMS entry is delivering; whether that entry then goes live depends on a separate publish-state setting. Teams that never look at that setting inherit a default, which in Smartling's Contentful connector is Re-publish (if published): a published English entry re-publishes in every target locale as soon as translations arrive.
Languages finish at different times. File-based connectors such as Contentful (Entries), Webflow, and CaptionHub deliver each target locale as soon as that locale is fully translated. Without a hold, a ten-language product page shows German live on Tuesday and Japanese live on Friday.
Source content changes mid-batch. Connectors that detect source changes on a schedule (Contentful (Fields), Zendesk, and HubSpot check every three hours) batch the updates into a new job, so a locale that was manually edited in the CMS is overwritten on the next delivery unless it is locked.
Developers need translations before review finishes. Repository pipelines cannot wait days for human review, so teams either ship untranslated strings or bypass review entirely; the fix is a connector setting that delivers a pre-published pass first and the final pass later, not a shorter workflow.
Nobody can see delivery status per asset per language. A job dashboard says In Progress while the CMS shows three of eight locales delivered. When delivery timestamps and per-locale status are missing, the publish decision is made on guesswork.

What controls does a translation platform need for batch publishing?

Treat publish control as four layers, configured once per connector and reused for every job that runs through it:

Destination publish state — A per-connector setting that fixes what the translated asset's status will be after delivery. Smartling's Contentful connector offers Never publish (translations arrive marked Changed and unpublished), Always publish (the entry publishes even if the source was a draft), and Re-publish (if published) (the entry keeps its source status). The Zendesk connector carries the same three options, and the Intercom connector offers Never publish, Always publish, and Smart publish for articles. The WordPress connector separates the decision into Don't change status, Always publish, and Always draft.
Delivery trigger — The event that causes the connector to write translations back. Smartling's WordPress connector can download translations when a job reaches the Published step ("Translation Completed") or whenever a translation in a file is added or changed ("Progress Changes"); its Retrieval Type can also return Pseudo translations (source text lengthened by about 30 percent) for layout testing before real translations exist.
Release gating across locales and jobs — Controls that hold a batch until everything is ready. Inside the workflow, a Workflow Hold step pauses translated strings until an Account Owner or Project Manager releases them, so all locales publish together; at the connector level, the GitHub connector's default is one translation pull request when every string in the job is Published, and Early Delivery adds a first pull request when all strings are pre-published and a Final Delivery pull request when the job completes. Per-locale locks in the Contentful (Entries) connector stop the connector from re-delivering a specific language.
Manual override and export — A way to push or pull a batch outside the automation. Smartling connectors expose an Export Language action per asset for on-demand delivery, and the Jobs Dashboard's Download Files action returns current translations per language as a .zip organized by subfolder, by locale ID in the filename, or both, in eight formats including DOCX, XLSX, IDML, JSON, and XLIFF.

The step-level settings that decide when a string counts as publishable inside the workflow — Pre-publish strings, reject paths, and the Idle String Rule — are covered on the translation approval workflow controls page; this page covers what happens after those strings are released to the connector.

Batch publishing controls: the numbers

Controllo	Figure	sorgente
Contentful delivery publish states	3 — Never publish, Always publish, Re-publish (if published); Re-publish is the default	Smartling Help Center, Contentful Publishing Options Configuration
WordPress post-status options after delivery	3 — Don't change status, Always publish, Always draft	Smartling Help Center, WordPress Connector Expert Settings
WordPress download triggers	2 — Translation Completed (Published step) or Progress Changes	Smartling Help Center, WordPress Connector Expert Settings
GitHub deliveries per job with Early Delivery on	2 pull requests — Early Delivery (all strings pre-published) and Final Delivery (job Completed)	Smartling Help Center, Get Translations Before Job Completion with Early Delivery
GitHub delivery branch-name tokens	4 — {source_branch_name}, {source_pull_request_number}, {commit}, {translation_job_id}	Smartling Help Center, Early Delivery
Source-change detection interval (Contentful Fields, Zendesk, HubSpot connectors)	Every 3 hours	Smartling Help Center, connector setup articles
Pseudo-translation length expansion for layout testing	30 percent longer than source	Smartling Help Center, WordPress Connector Expert Settings
Manual download formats from the Jobs Dashboard	8 — DOCX, PPTX, XLSX, IDML, INDD, SRT, JSON, XLIFF; 3 folder-organization options	Smartling Help Center, Download Files for Post-Translation Production
Strings View CSV export columns	6 — String ID, Source Text, Variant, File/URL, Locale, Translation Text	Smartling Help Center, Download Files for Post-Translation Production

How do you set up publish control for a recurring translation batch?

The sequence is the same for a weekly blog batch, a product-catalog refresh, or a release-notes drop.

Decide the destination state per connector — For content that a market owner must check before it goes live, set the connector to deliver as draft (Never publish in Contentful or Zendesk; Always draft in WordPress). For content that is already approved inside the translation workflow, use Re-publish (if published) so the translated entry mirrors the source status and drafts stay drafts.
Choose the delivery trigger — Leave delivery on job completion when every language must arrive as a finished set. Switch to progress-based delivery (WordPress "Progress Changes") or GitHub Early Delivery only when developers or reviewers need translations in the destination before the workflow finishes, and pair it with a Final Delivery so the reviewed version overwrites the early one.
Gate the release — Add a Workflow Hold step before Published when all locales must go live together, and release the batch from the Strings View once the last language clears review. In Contentful (Entries), lock any locale that carries market-specific edits so the next delivery does not overwrite it.
Control how source changes re-enter the batch — Set the connector's automation to Automatically request translation when changed source should flow through without a request, or to Flag changed content (Manual) when a person should decide what re-translates; either way, the change check runs every three hours, so plan the publish window around that interval.
Verify delivery per asset and per language before announcing — Use the connector tab's Asset Details view, where the Delivered column shows the date and time each locale's translations landed, and export a Strings View CSV when a stakeholder wants a record of exactly which translations shipped in the batch.

Connector-level publish control fits content operations teams that...

Publish translated content through a CMS, help center, or repository connector rather than by uploading files, so the connector setting is what determines live status.
Run recurring batches — weekly blog posts, catalog updates, release notes — where the same publish rules should apply every cycle without re-deciding them per job.
Manage ten or more locales that finish translation at different times and must go live together for a launch.
Keep market-specific edits in certain locales and need those locales protected from automatic re-delivery.
Have developer pipelines that need a first pass of translations before human review completes, followed by a reviewed final pass.

When connector publish settings may not be the right priority

Teams whose real question is which approver can hold or reject a string before it is released are solving a workflow-step problem, covered on the translation approval workflow controls page.
Teams still choosing between a proxy, a CMS connector, and an API integration for website content should start with the website translation workflow page; publish-state settings only matter once a connector is in place.
Teams translating spreadsheets and CSV exports by hand, with no destination system to publish into, need import and export tooling rather than delivery settings — see CSV localization and data conversion tools.
Teams building custom notifications when a job completes are better served by translation webhooks than by connector publish options.

Evaluation checklist: questions to ask about batch publishing control

Can the publish state after delivery be set per connector, and what is the default?
Ask for the exact options (publish, draft, or match source status) and confirm the default, because the default is what runs on every job nobody configured. In Smartling's Contentful connector the default is Re-publish (if published).

Does the connector deliver per locale as each finishes, or only when the whole job completes?
Per-locale delivery is faster but publishes languages at different times; job-level delivery keeps the set together. Confirm which model each connector uses and whether a hold step can override it.

Is there a way to deliver a preliminary pass before review, and does the final pass overwrite it?
Look for a two-stage delivery such as GitHub Early Delivery, where an early pull request is followed by a final pull request that supersedes it. Ask whether machine and human translations are both eligible for early delivery.

Can a specific locale be locked against re-delivery?
If a regional team edits a translation directly in the CMS, the next delivery will overwrite it unless the locale is locked. Confirm the lock exists and where it is set.

How often does the connector check for source changes, and does it re-translate automatically or flag for review?
A three-hour polling interval is typical for Smartling's CMS connectors. Confirm whether detected changes are batched into a job and authorized automatically or held in Awaiting Authorization for a person to release.

Can a batch be delivered or downloaded manually when the automation should not run?
Ask for a per-asset export action and a per-language download from the job, including the file formats supported, so a stakeholder can review a batch offline without publishing it.

Where is delivery status visible per asset and per language, with timestamps?
A job status of Completed does not prove the CMS received every locale. Confirm the connector shows a delivered date and time for each asset and language.

Where does rollback live — in the translation platform or the destination?
Connectors deliver translations; version history and rollback of the published entry stay with the CMS. Confirm which system is the record of what was live on a given date before assuming the TMS can revert a publish.

How Smartling controls when translated batches publish

Smartling separates delivery from publishing and exposes the publish decision as a setting on each connector. In a Contentful project, Settings > Contentful Settings > Delivery Options offers Never publish (translations arrive marked Changed and stay unpublished), Always publish (the entry publishes after delivery even if the source was a draft), and Re-publish (if published), the default, which keeps the entry's current status so a Published source re-publishes and a Draft source stays Draft. The Zendesk connector offers the same three publishing options and delivers completed translations on a schedule that defaults to every three hours; the Intercom connector offers Never publish, Always publish, and Smart publish for articles. The WordPress plugin's Expert Settings split the decision further: Download translated files when Translation Completed or Progress Changes, Retrieval Type of Published or Pseudo (source text lengthened by 30 percent for layout testing), and Change asset status on completed translation set to Don't change status, Always publish, or Always draft.

For staged releases, two mechanisms work together. Inside the workflow, a Workflow Hold step pauses translated strings until an Account Owner or Project Manager releases them from the Strings View, so every locale in a launch publishes at once. At the repository, the GitHub connector delivers one translation pull request when all strings in a job reach Published; enabling Early Delivery on a configuration set adds an Early Delivery pull request as soon as every string in the job is pre-published (Pre-publish strings set to On Submit on the workflow step) and a Final Delivery pull request when the job reaches Completed, with branch names built from tokens such as {source_branch_name} and {translation_job_id}. Early Delivery works in both Pull Request mode and Single Branch mode and applies to human and machine translation alike.

File-based connectors — Contentful (Entries), Webflow, CaptionHub, and others — deliver each target locale automatically once that locale's file is fully translated, and every connector tab includes an Export Language action for manual delivery of a single asset or language. In Contentful (Entries), a Lock action on an asset stops the connector from re-delivering a locale that carries market-specific edits, and the Asset Details view records the date and time each locale was delivered. Source changes are picked up on a three-hour cycle by the Contentful (Fields), Zendesk, and HubSpot connectors, either batched into a job and authorized automatically or, in the HubSpot connector's Flag changed content (Manual) mode, surfaced for a person to decide. When a batch needs to leave the platform without publishing, the Jobs Dashboard's Download Files action returns current translations per language as a .zip in DOCX, PPTX, XLSX, IDML, INDD, SRT, JSON, or XLIFF, organized by language subfolder, locale ID in the filename, or both, and the Strings View exports a CSV of String ID, Source Text, Variant, File/URL, Locale, and Translation Text for an audit record of what shipped. For the Adobe Experience Manager connector, resubmitting a page creates an AEM launch for the language copy, and the connector approves and promotes that launch when translations are downloaded, with a manual approve-and-promote path in the AEM Translation Project if automation fails.