Release one locale without releasing another locale’s draft

Record the state you intend to release

Create a small ledger with the entry, locale, approved version, current publication state and requested transition. Separate a first publication from an update to an already public translation. Include the relevant assets and references, because publishing the parent text does not establish that every dependency is available in the intended state. Identify the owner authorized to release each locale.

Contentful’s help distinguishes locale-specific publication from publishing all locales and notes that availability depends on the plan and environment. It also explains that an overall Published status can coexist with draft locales. Use those facts to ask precise configuration questions. Do not treat an editor’s broad status badge as proof that every language is ready or that none of its drafts can be delivered.

Verify how the public route enforces that state

Ask the implementation owner which delivery API, request options, build process and cache supply the public page. Keep preview and public delivery clearly distinguished. Contentful’s June 2026 API notice describes an opt-in request header that makes supported delivery requests respect locale publication status; it also distinguishes that status from fallback resolution. The lesson is to verify the deployed request path, not assume an editorial setting automatically controls every consumer.

Build a test matrix using fictional content: one published locale, one draft, one published locale with pending changes, and references with differing states. Define the expected public result before running it. A draft may require a clear unavailable response rather than a partially assembled page. Do not weaken required-field validation or other release protections to make an incomplete locale appear publishable.

Compare preview, delivery response and rendered page

Capture what the editor preview shows, what the public delivery route returns and what the browser finally displays. A preview containing the new translation is expected; the same text appearing publicly before approval is a defect. Conversely, a delivery response may be correct while a stale build continues serving an older version. Record the layer where the mismatch occurs instead of repeatedly pressing Publish without diagnosis.

Test the actual release method, including scheduled or grouped releases when the campaign depends on them. Do not infer that a feature supported by a manual entry action is also supported by every scheduling mechanism. Check the current route-specific documentation and ask for a bounded test where behavior is uncertain. Preserve the expected state of unrelated locales while investigating; a repair should not release their drafts as a side effect.

Close the release with evidence and a withdrawal plan

After the authorized release, verify the intended locale and a deliberately unchanged locale through the public route. Include any references the release changed. Record the visible version, test time, route and unresolved limitations. If the site is generated or cached, verify that the appropriate delivery process completed rather than promising instantaneous propagation from a CMS status change.

Before a later withdrawal, identify shared dependencies and other locales that rely on the affected content. Agree the desired customer-facing result and the supported recovery path with the responsible owner. Do not assume unpublishing one locale withdraws every derivative or permits deletion of the entry. Keep the release ledger current so the next editor can distinguish an approved older public version from an accidentally stale page.

Make the reasoning concrete.

A fictional training site has an approved German guide, an English guide with pending revisions and a French draft. The German editor sees the complete translation in preview and requests release. The public website uses an API path configured separately from the editorial interface.

The team releases only through its verified workflow, confirms the intended German content and unchanged boundaries for the other locales, and saves the evidence with the release ledger.

Take the questions into your next brief.

Use these prompts in your own notes. Nothing is submitted from this page.

1. Intent

   Which exact locale/version transition is approved?

2. Dependencies

   Which referenced entries and assets must have compatible states?

3. Delivery

   Which API options, build and cache actually serve the public page?

4. Matrix

   What should published, draft and pending-change locales return?

5. Closure

   What evidence confirms release and what supported path handles withdrawal?

Watch for the wrong conclusion.

• Treating a global Published badge as a per-locale guarantee.
• Using preview as proof of public delivery.
• Assuming manual publication and scheduled releases have identical capabilities.

Sources & scope

Workflows, worksheets and fictional examples are original editorial analysis. Sources support only specifically attributed principles. Platform guidance can change; legal requirements depend on jurisdiction and context. No measured results or named human reviewer are claimed.

• Contentful: Locale-based publishing →Primary platform documentation · Supports: Contentful documents locale-level publishing and status visibility with plan/environment limitations. No guarantee is made that every release mechanism supports the same behavior.
• Contentful: Locale-based publishing request header for the Content Delivery API and GraphQL API →Primary platform change notice, 15 June 2026 · Supports: The 15 June 2026 Contentful notice describes opt-in locale-status behavior for CDA/GraphQL and separates publication status from fallback content resolution.