Localization enhancements

[JessChowdhury]

We aim to improve current localization features with the following items:

1. Renovation of the document status bar to include all locale status information. Related thread here by italodr.
2. Adding the ability to unpublish specific locales

Any other localization enhancements requests are welcome, they will be prioritized and incorporated into the roadmap accordingly.

[rilrom]

Being able to unpublish specific locales really needs to be prioritised. It seems like a fundamental feature for localization.

Currently the only way I can see to unpublish a locale is completely deleting the document and re-implementing it without publishing the specific locale, causing all version history to be lost (which in our case is not practical).

If anyone has any other workarounds I'd appreciate if they could share.

Glad to see it's showing up here for discussion.

[maximseshuk]

@rilrom, I support your view, and here's how I see this improvement for Payload's localization to match Strapi's excellent implementation. We need two key features for collections with translations:

1. Independent Timestamps

   • Each language version should have its own timestamps
   • This makes it easy to track when each translation was last modified

2. Separate Status Controls

   • Each language version needs its own status field (_status)
   • Status options would be: draft, published, or edited (for versions)
   • This allows us to manage different versions of each translation
   • Enables proper API response handling (e.g., return 404 for unpublished translations)

For example: if content ID 5 has English published but French in draft:

• GET /api/content/5?locale=en returns the content (200 OK)
• GET /api/content/5?locale=fr returns not found (404)

This solves the common issue where content exists in some languages but not others, ensuring users only see properly published content in their requested language.

These changes would significantly improve Payload's localization workflow and make it more user-friendly for content managers working with multiple languages.

[italodr]

@maximseshuk I completely agree with your points. These ideas would significantly improve language management.

Additionally, it might be worth exploring the option to manage deletions by language. This could provide greater security and stability for content editors.

Currently, as @rilrom mentioned, the only option is to delete the entire file.

One potential solution could be for the delete button to restore the initial version of the file (empty), allowing individual language versions to be restored later (a kind of soft delete). And, if it’s the only language available, the file would be permanently deleted.

[maximseshuk]

@maximseshuk I completely agree with your points. These ideas would significantly improve language management.

Additionally, it might be worth exploring the option to manage deletions by language. This could provide greater security and stability for content editors.

Currently, as @rilrom mentioned, the only option is to delete the entire file.

One potential solution could be for the delete button to restore the initial version of the file (empty), allowing individual language versions to be restored later (a kind of soft delete). And, if it’s the only language available, the file would be permanently deleted.

Deletion can actually be implemented right now using a custom button and custom query, since deleting a row in the collectionName_locales table isn't difficult.

Drafts will generally cover the deletion-related issues, but I agree - having the ability to delete would make things even better!

[Thisisjuke]

Hello 👋

There are also questions around the locale data model to make it easier to retrieve all slugs for all locales for a document in a given collection.

When generating a sitemap, it is generally better to request the document in a single language rather than using locale: '*'. This avoids unnecessary more efficient data retrieval, especially when generating a sitemap or a list of articles in a single language.

Another use case is language switching. When I fetch a document to display it on my page, it’s helpful to have the slug in other available languages so I can directly link to the corresponding language version on a language switch. For example, in a real life front-end application, there is no way editors will redirect /en/discover-my-product to /fr/discover-my-product, it would switch to /fr/découvrir-mon-produit.

To optimize performance, it would be valuable to have these slugs available directly in a single call to fetch documents from a collection, rather than remapping the data within a PayloadCMS custom endpoint.

One workaround we are doing (that will not work without the discussed "admin unpublish feature") is:

export const afterReadHooks: CollectionBeforeReadHook<any>[] = [
  ({ doc }) => {
    doc.tabs.localizedSlugs = doc.tabs.slug
    return doc
  },
]

So, when we request a collections of documents with locale: 'en', we also save all the values of slugs of the admin in a new variable. this way we can have:

{
    slug: 'discover-my-product',
    localizedSlugs: { en:  'discover-my-product', fr: 'découvrir-mon-produit' }
}

Right now, this works, but the content of localizedSlugs is not related in any way to the _status of the document or the locale. It's simply a mapping of the input values from the admin side, so all slugs are sent to the front end. This means unpublished pages can still appear in my sitemap.xml.

[akantic]

Hi, a thing from me.

Support multiple values in the fallbackLocale query parameter.

I need to get content in all available locales that user supports. For example, a user can specify multiple languages they want to see the content in, so I store it as an array and prioritize in that order. Let's say that the user can speak English, German and Spanish, in that order.

const databaseDocs = [
  {
    title: {
      en: "English 1",
      es: "Espanol 1",
    },
  },

  {
    title: {
      es: "Espanol 2",
    },
  },

  {
    title: {
      es: "Espanol 3",
      de: "Deutsch 3",
    },
  },
];

// output
const queriedDocs = [
  {
    title: "English 1",
  },
  {
    title: "Espanol 2",
  },
  {
    title: "Deutsch 3",
  },
];

Query could be locale=[en, de, es] or locale=en&fallbackLocale=[de, es].

Current workaround
When querying I first need to make sure that at least 1 preferred locale exists.

preferredLocales.forEach((locale, i) => {
    query[`where[or][${i}][title.${locale}][exists]`] = true;
});

This is very nasty, because I rely only on the title property to exist. Since the field is required, the document can not be published before it exists.

Along with that, I'm fetching with locale: all and recursing through the entire document replacing the value of each localized field. Essentially the same as you for the fallback locale, but supporting multiple to be specified.

[akantic]

Also aside from the additional fallback functionality directly in the API, here's another nice localization fallback feature from Contentful described at this page.

Basically it enables content editors to specify "fallback trees" which customizes fallback behavior in any way they want.

[lorenzrabs]

Hello! A client duplicated a german post multiple times. For the client it was really confusing why the english content suddenly had 5 identical posts.

Maybe it would be good to give the user a choice which languages to duplicate.

Another thing thats logical for developers, but not for the clients are empty language pendants ().