Confusing status after publishing collection by language

[italodr]

Describe the Bug

I have noticed some issues related to the feature that allows publishing collections by language.

Expected behavior:

The status bar should show "Published" for the selected language after publishing. The editor should clearly understand which language versions are published versus in draft status. These changes would enhance the user experience by reducing confusion and providing more flexibility in managing multilingual content.

Actual behavior:

After publishing a language, the status bar shows "Changed - Revert to published" instead of "Published," which confuses content editors and may lead to errors.

Additional suggestion: It would be helpful to add an option to unpublish individual languages. This would improve content management by allowing editors to control the publication status of each language version independently.

Link to the code that reproduces this issue

https://github.com/italodr/payload-test/tree/issue-publishing-by-language

Reproduction Steps

1. Clone the above repository
2. Update the config file to add your postgres URL. Currently as "postgresql://postgres:[email protected]:5430/postgres_db"
3. Run pnpm install to install dependencies
4. Run pnpm dev _community to start the admin panel
5. Access the admin panel
6. Add new post in all languages and save it as "Draft"
7. Change language to "Deutsch"
8. Click on "Publish in Deutsch"

Which area(s) are affected? (Select all that apply)

area: ui

Environment Info

Payload: 3.0.0-beta.123 Node.js: v20.12.2 Next.js: 15.0.0

[github-actions[bot]]

This issue has been marked as stale due to lack of activity.

To keep this issue open, please indicate that it is still relevant in a comment below.

[github-actions[bot]]

This issue was automatically closed due to lack of activity.

[Thisisjuke]

Hi 👋 ,

I spoke with an editor, and I think there is a related bug tied to this issue. The editor cannot unpublish a Page for a specific locale if the page is no longer available in that locale. For example, he wants to unpublish an "editorial discount page" in FR while keeping it published in EN (the discount is no longer valid in France). He also wants to keep the option to republish it in a few weeks.

Currently, there is no button to unpublish, and the slug for the FR page is still returned. As a result, the French discount page continues to appear in the sitemap.xml of our website.

Using the payload.find method, it is impossible to determine whether the FR version of the document is unpublished while the EN version remains published. This is because the slug field is present in both cases. An editor may complete the page by writing a slug but then only unpublish the page for a specific locale.

If I have a Pages collection with a field like this:

 {
      name: 'slug',
      type: 'text',
      localized: true,
},

And then I query it like this :

await payload.find({
      collection: 'pages',
      where: {
        'id': { equals: pageDocument.id },
        '_status': { equals: 'published' },
      },
      draft: false,
      limit: 1,
      depth: 3,
      locale: 'all',
      req,
})

returns:

│ {
│   docs: [
│     {
│       id: 3,
│       'unique-title': 'Not localized',
│       slug: { fr: 'slug-fr', en: 'slug-en' },
│       updatedAt: '2025-01-17T16:58:14.665Z',
│       createdAt: '2025-01-17T16:57:46.881Z',
│       _status: 'published'
│     }
│   ],
│   hasNextPage: false,
│   hasPrevPage: false,
│   limit: 1,
│   nextPage: null,
│   page: 1,
│   pagingCounter: 1,
│   prevPage: null,
│   totalDocs: 1,
│   totalPages: 1
│ }

For SEO, sitemap, and consistency purposes, when I unpublish fr, the fr slug should not appear in the docs[0].slug object. However, there is no way to hide it or deduce whether the document linked to this slug is unpublished.

Currently, the only way to unpublish en is to duplicate the document, delete the original, and then publish the new one in en. After this process, en is published, and fr is not.

In this case, slug looks correct : slug: { en: 'slug-en' }.

This workflow is not optimal because I have hooks that track deleted pages. Deleting the original document triggers false positives. Moreover, duplicating and deleting a Page document is not straightforward for editors in their application workflow.

Thx !

[maximseshuk]

I agree with the need for independent statuses. It would make the workflow much smoother, especially when working with translations. The current approach where all localizations share the same status creates unnecessary blockers.

A few key points worth considering:

• Each localization should have its own draft/published state
• Teams should be able to work on translations without affecting the main version
• Version control and history should track status changes per language

This would help a lot with content management and quality control across different languages.

[DanRibbens]

@JessChowdhury let's do some planning to implement the feedback here.

[maximseshuk]

The easiest way to solve translation issues is to store timestamps and _status separately for each translation, while keeping common fields in the main collection table.

If we move these fields to a [COLLECTION_NAME]_locales table within each collection that stores translations, migrating existing translations becomes simple - we just need to duplicate the current timestamps and status there.

While this could be built as a plugin, there are many subtle complexities that would be harder to handle in a plugin compared to implementing it directly in the codebase.

[jessrynkar]

Thanks for all the input on this thread everyone! We are breaking down localization UI related improvements and adding it to our roadmap - the status component renovation will be included in this. You can follow and add to the discussion here.

[github-actions[bot]]

This issue has been automatically locked. Please open a new issue if this issue persists with any additional detail.