Localization Enhancements

[JessRynkar]

Localization Enhancements Tracking

Below is the full list of planned localization enhancements currently included in our roadmap. Each item links to its respective feature request for detailed tracking and discussion.

Completed

• Accept Multiple Locales in fallbackLocale Query - Feature Request #13443 - Pull Request #13822
• Duplicate Documents by Specific Locale - Feature Request #13444 - Pull Request #13803
• Show Localized Status - Pull Request #14667
• Ability to unpublish specific locales - Feature Request #13436 - Pull Request #13693

Planned

Will be available as part of the new multi-locale editing view

• Renovate Status Component in Document View to Show All Locale Statuses - Feature Request #13437
• Option to Display Fallback Data within UI - Feature Request #13448
• Required Fields per Locale - Feature Request #13445
• Allow Editing of Multiple Locales - Feature Request #4195

📢 How to Contribute

If you have additional ideas for localization improvements, please share them in this thread. They will be reviewed, prioritized, and linked here once they are added to the roadmap.

[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.

[JessRynkar]

Hi @rilrom - this feature is now our highest priority for localization improvements, work will begin this week and can be found on our roadmap here. Thanks for bearing with us on this!

[ilhamsj]

why not just craete a relathionship ?
documents -> transalations A
-> transalations B
-> transalations C

[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.

[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!

[JessRynkar]

Hi @maximseshuk, we agree that both of these features would be of benefit to Payload. Both items have been added to the roadmap and their relevant feature requests can be found here:

• Independent Timestamps for Each Locale #13439
• Allow Group Status Field Including All Locales #13440

[JessRynkar]

One more! Per your comments (@maximseshuk and @italodr), the ability to delete a specific locale is definitely something we would like to accomodate. Added to the roadmap here:

• Delete Document by Specific Locale #13441

[JarrodMFlesch]

@maximseshuk @italodr would unpublishing a specific locale provide the same outcome as the "delete localized document" talk here?

I suppose, if you were not using versions, then unpublishing would not be the same as deleting a locale.

[italodr]

@JarrodMFlesch In practical terms, it provide the same result, but in addition to your comment about not managing versions, I see some drawbacks to not allowing the deletion of a specific language. Some that come to mind are:

• The need to filter between published and unpublished content
• Difficulty in content maintenance. There's no clear distinction between unpublished and "deleted" pages once filtered by status
• Risk of batch modifications or accidental republishes
• The need to add filters to relationship fields, for example, when creating internal links

[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.

[JessRynkar]

Hi @Thisisjuke!

To efficiently fetch all localized slugs, you can use the new select param like &select[slug]=true. This can be combined with &draft=false to ensure you only get published slugs.

Querying like this avoids unnecessary data and is better than remapping slugs manually. If I’m misunderstanding your use case here, please let me know!

[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.

[JessRynkar]

Hi @akantic - we absolutely want to support multiple fallback locales, and have added it to the roadmap here:

• Accept Multiple Locales in fallbackLocale Query #13443

Thanks also for sharing the Contentful docs — we like the idea and will reference their fallback approach in our solution. Appreciate your input here🙏

[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 ().

[JessRynkar]

Hi @lorenzrabs - this is a great idea, we have added it to the roadmap here and will get it built!

• Duplicate Doc Per Specific Locale #13444

[aleksei-a-savitski]

It would be nice to be able to add new locales without code changes.

[JessRynkar]

Hi @aleksei-a-savitski! At this time, we’re not planning to support adding new locales without code changes, as dynamic locale additions could introduce complexity and risks we’re not ready for. However, we’d love to hear any ideas you might have on how a feature like this could work or what kind of experience you’d expect?

[notdefinedvar]

Hi @JessRynkar, if I have a collection called Localization and it's purpose is for adding and updating locale's info, is it possible that these locale data can be dynamically configured in payload.config.js?

My expectation is that user can see their updated or new added locales in the locale dropdown and they can also work on with different locales in collections.

[JarrodMFlesch]

@jianzheGuo what "info" are you updating in regards to the locale?

You should be defining locales statically in the config, that is how they appear in the localization dropdown.

[atlasgong]

It would be incredibly helpful to be able to set fields to be required: true only in the default locale, while remaining optional (required: false) in others. This would enable fields to fall back to the default locale when not provided in other locales.

Example configuration:

localization: {
    locales: ["en", "fr"],
    defaultLocale: "en",
    fallback: true,
}

A possible implementation for a field could look as such:

{
    name: "someField",
    type: "text",
    required: true,  // required only to default locale ('en')
    localized {
        // overrides required status for non-default locales
        // falls back to defaultLocale if not provided
        required: false 
    }
}

Expected Behaviour:

• In the default locale (e.g. en), someField is required.
• In other locales (e.g. fr), someField is optional. If not provided, it falls back to the value of the required en field.
• Editors can save content in non-default locales without being blocked by missing required fields, as these will default to the primary locale's content.

Or, if someone had more than two locales, it may be better to extend the implementation to allow setting which ones should be required:

{
    name: "someField",
    type: "text",
    required: true, 
    localized: {
        required: ["en", "de"], // required only in 'en' and 'de', optional in other locales
    }
}

[codeflorist]

I agree, this is also my number 1 request for localization. Sometimes the editor wants a field to be the same for all languages.

Storyblok e.g. solves this by presenting each localized field in a non-default-language in this way:

So the default state of a localized field is always to fall back to the default language. Only if you click the switch on the top right, the input becomes enabled and you can add a translation and normal validation kicks in.

Imho this could/should be made the standard for ALL localized fields, so the additional field-config like in your solution would not be required.

[JessRynkar]

Hi @atlasgong and @codeflorist - thanks for both your input here, we definitely see the value in this functionality.

This feature will be a significant change to the codebase and we will need to dial in a final solution, for now we have added it to the roadmap and will get this built out when possible:

• Required Fields Per Locale #13445

If you have any further thoughts on how you'd like to see this accomplished (in the config, in the UI, or something else) please share them!

[mattiaz9]

• Locale unpublishing is a customization that I make all the time, so it'd be nice to have it by default
• Having the _locale field in the document response. If you try to fetch a locale that doesn't exists there is no way to know if the document is the fallback
• adding an option to set the locale in the link field. For instance, if I need to link to a post with a different locale than the current one.

[JessRynkar]

Hi @mattiaz9, these are all great suggestions. Some info:

1. Unpublishing a specific locale is our next priority for localization, and can be tracked here.
2. The ability to receive locale in the document response is a good feature and added to our roadmap here. Unsure whether we will use a query param or a new opt-in config option, if you have any thoughts on this we'd love to hear them!
3. Are you referring to the link component within the Lexical rich text editor? If so, this may already be possible through customization.

[JessRynkar]

Circling back on #2. After more discussion we’re going to hold off on this one. It would be straightforward if a document only ever returned a single locale, but in practice a response can include values from multiple locales due to field-level fallback (and even multiple fallback locales).

Because of that, a _locale value is only really useful if you also know which fields it applies to. Exposing that kind of per-field resolution data quickly becomes more complex and crowded than it is valuable for most use cases.

So until we find a cleaner solution here or have higher demand for this, we’re going to table this feature.

[linobino1]

I think for editors it's easy to forget about localization, because the localization status and locale switch are not very prominent within the UI.
Imagine a collection with many fields where some are localized, some aren't, it's multiple screens long, maybe some tabs, and so on. Here it would be really nice to have a reference on a per field basis, any maybe even the ability to switch the locale on a per field basis.

I am thinking of a status indicator:
My field label - en ✅, it ✅, fr ❌

If the locales would even be clickable so that you can edit the fields value in the specified locale, regardless of the globally selected locale, that would be awesome.

[mik01aj]

I am thinking of a status indicator: My field label - en ✅, it ✅, fr ❌

Yes, and I'd love to have it also in the list view, to easily spot items that need a translation. Here's a quick mockup I made:

Currently I don't even see a way of easily doing it with a custom component - I'd have to change how the data gets retrieved from the db.

[wp99cp]

That is exactly what we have implemented in our codebase. Basically, we added a _localized_status field to check which locales are published. This allows us to manage publishing separately for every language.

[JessRynkar]

Hi @linobino1, @mikkelwf and @wp99cp - thanks for all your input here, this is very useful!

We plan to incorporate a group status field that maintains all locale statuses and can be easily accessed. This feature is on our roadmap now and can be tracked here:

• Allow Group Status Field Including All Locales #13440

We also plan to enhance the status indicator within the edit document view, you can find that feature here:

• Renovate Status Component in Document View to Show All Locale Statuses #13437

The only remaining item that you mentioned which is not planned, is a status indicator from the list view. However, with the addition of the group status field, you will be able to enable this field as a column which will provide the information that you are looking for.

[nachomglz]

Could also be good to have a better way of identifying what locales a document is "using", so that we can do custom fields, columns and whatnot

[JessRynkar]

Hi @nachomglz - can you provide some more information on what you are looking for here? It sounds like this may be satisfied with the group status locale feature that we have planned here:

• Allow Group Status Field Including All Locales #13440

[nachomglz]

Following up with @lorenzrabs 's comment, I created this issue as I found out that when you duplicate a localized document it actually publishes all the rest of available locales and adds a "null - Copy" title to them, even though the other locales have never been touched.

[JessRynkar]

Hi again @nachomglz, I agree this is definitely not ideal. We plan to add the ability to duplicate per locale in the near future, this feature should resolve the behavior you are describing and can be found here:

• Duplicate Doc Per Specific Locale #13444

[cbratschi]

Saw this discussion on Discord and wanted to add my previous discussion points:

#4194

I provided some source code and for instance the currently used data models is:

{
  "locales": {
    "de": {
      "status": "published",
      "createdAt": "2025-01-28T22:03:43.128Z",
      "createdBy": "64d118d7ec4a6f13f2ed0d11",
      "updatedAt": "2025-01-28T22:04:50.712Z",
      "updatedBy": "64d118d7ec4a6f13f2ed0d11",
      "publishedAt": "2025-01-28T22:04:50.712Z",
      "publishedBy": "64d118d7ec4a6f13f2ed0d11"
    },
    "en": {
      "status": "draft",
      "createdAt": "2025-01-28T22:04:00.594Z",
      "createdBy": "64d118d7ec4a6f13f2ed0d11",
      "updatedAt": "2025-01-28T22:04:03.983Z",
      "updatedBy": "64d118d7ec4a6f13f2ed0d11"
    },
    "fr": {},
    "it": {}
  }
}

Basically additional metadata gets saved per language which can be used to check which translations exist. Based on such a structure features can be built on top of it.

[JessRynkar]

Thanks @cbratschi this is a good observation!

[nachomglz]

Another thing I'd like to add, I realized that when you enable localization in the Payload app, it adds the "Publish In [Locale]" button to the editing screen.

The problem is that this button also appears in "Non-localized" collections that have versioning enabled, which creates a lot of confusion and insecurity in the editors.

I went ahead and dove a little deeper to see how this works at DB level, and realized that even for "Non-localized" collections—locale tables are created, where there's an entry for each of the documents in the "Non-localized" collection and for each locale, although they don't update at all, meaning the "Publish in [locale]" button doesn't really do anything aside from the normal behaviour of the "Publish version" button. However, I think it's pretty confusing, and also weird that "localized" tables are created for documents that don't have any localized fields whatsoever.

[JessRynkar]

Thanks @nachomglz this is a good catch - I also see this behavior as a bug, not intentional behavior, so I've opened an issue here and will get it fixed ASAP.

[anyuj]

#4195 Allow Editing of Multiple Locales at once please!

[JessRynkar]

We are getting there! Thanks for your patience 🙏

[PP-Tom]

One thing I'm struggling with is if you have en-GB and en-US it makes sense for there to be fallback logic. However, while fallbacks work as expected from the API perspective. In the list view it says <No Title> which makes it hard to find the correct document to edit and also while also querying the documents e.g. { title: { like: 'and' } } returns nothing even though you can see the fallbacks. This makes relationship dropdown seem broken, you see the title but you can't search for it.

I've had to put a lot of custom code in place to correct this, but it would be much better handled in the core.

[JessRynkar]

Hi @PP-Tom, I can definitely understand the setback from not displaying fallback data in the UI, at the same time we would not want to make this default behavior.

I have opened a feature request to address this here:

• Option to show fallback data within the UI #13448

Our current idea would be to provide a new localization option called displayFallbackData or similar, which would display the fallback data for empty localized fields across the UI.

Do you have any suggestions or thoughts on how you would expect this to be achieved? We would love to hear your input.

[nachomglz]

Is there an ETA for these fixes? These are still pretty critical issues from my POV, that need a lot of custom logic

[JessRynkar]

@nachomglz checkout the updated list at the top of this thread, in progress items are updated with ETA's. The others will be updated with ETA's in the near future.

[mikkelwf]

@JessRynkar the unpublish per language was mentioned in your latest youtube community update, as a rather simple feature that could be implemented quite quickly. Can you give us any insight to how prioritized this issue is currently in your development plan?.

The features mentioned here (publish / unpublish per language, and true published/unpublished state) iis rather essential for using payload for content management of a "normal" website.

[anyuj]

That's why I really want the edit multiple locale at once feature so bad #4195 , so you can ensure every locale is edited correctly and publish as a whole. I think this feature has not received much attention. If you think this feature is helpful, let's give that discussion some little boost.

[nachomglz]

@maximseshuk is that recording some sort of custom logic? it seems to be working better than mine hahaha. I also use versioning which makes it even worst.

[maximseshuk]

@maximseshuk is that recording some sort of custom logic? it seems to be working better than mine hahaha. I also use versioning which makes it even worst.

this is a custom implementation without using versioning. I additionally store my own status, creation date, update date, and publication date. I also improve the interface through custom components, including deletion logic. And with a default filter in the list, I can hide items in lists that haven't been created yet as part of the translation process - so they don't get in the way.

[nachomglz]

@maximseshuk is that recording some sort of custom logic? it seems to be working better than mine hahaha. I also use versioning which makes it even worst.

this is a custom implementation without using versioning. I additionally store my own status, creation date, update date, and publication date. I also improve the interface through custom components, including deletion logic. And with a default filter in the list, I can hide items in lists that haven't been created yet as part of the translation process - so they don't get in the way.

that's great, I'm using versioning though... I've tried implementing some custom logic but it's soooo hard to work with versions that I gave up after months of trying to make it work for the editors.

[JessRynkar]

Hi all - the unpublish specific locale feature is now officially in progress with an approximate completion date of September 2025.

[nachomglz]

Any updates on this? This is still causing us a lot of issues, we're lowkey tired of doing custom solutions, we're very afraid that when a new version of Payload comes with improvements the migration will be close to impossible due to the amount of custom stuff that should be implemented already

[JessRynkar]

@nachomglz we have recently triaged the localization feature requests in this thread, checkout the updated list at the top of this thread for an overview of what is in progress and what we plan to build. We appreciate your patience on this 🙏

[matthijs166]

This is also a very cool plugin for automatic translations: https://github.com/r1tsuu/payload-enchants/tree/master/packages/translator
Would be awesome if it was native supported

[JessRynkar]

Hi @matthijs166 — thanks for sharing! The creator of that package, @r1tsuu, is actually part of our core team, so it’s definitely top quality. Since we already offer an Enterprise translation plugin that overlaps in functionality, we’re unable to include another official translator in the open-source core. That said, the plugin you shared is an excellent choice for automatic translations outside of our Enterprise offerings.

[mikkelwf]

Any chance of getting this prioritized?

[JessRynkar]

It's finally happening 🙌 A couple items are now in work, checkout the revised list at the top of this thread to see which — any that are in progress have up-to-date ETA's in their respective feature requests. The others in the planned list will be moving up quickly through the remainder of this year, their ETA's will be updated as they get scheduled.

[a-ys1]

@JessRynkar Any updates regarding the plan for this? This is the top rated discussion since one year back and it’s blocking me and many others from using the localization properly since we are stuck between waiting for a native solution or building our own.

As @nachomglz mentioned above, building custom stuff if extremly tiring and is probably not worth it.

I would like to know:

1. Is there a ticket for this?
   1.2 Is the ticket planned into a sprint?
2. If there is a ticket, what exactly would be fixed?
3. If there is a ticket, when can we expect it to be started?

Any insights to this would be helpful for planning pur work.

[JessRynkar]

Hi @a-ys1! A couple of items from the list are now actively in progress—please check the updated list at the top of this thread to see which ones. Any features currently being worked on have up-to-date ETAs in their respective feature requests. The remaining planned items will be prioritized and moved forward steadily throughout the rest of this year, with ETAs updated as they’re scheduled. Thanks for your patience!

[rolfsdMediaMarktSaturn]

It would be sooooo helpful to see the content from the default language as a note below the input field (like LinkedIn does). That would help so much when adding new languages. Please make add this as soon as possible! 🙏

[codeflorist]

A "Copy from default language" button would also be very handy in cases where one needs only to translate certain parts of the content, or to be able to quickly use translate&replace apps.

[JessRynkar]

Hi @rolfsdMediaMarktSaturn and @codeflorist - I think these are both great ideas, however we don’t currently plan to add these features into core unless there is a strong increase in demand.

Both suggestions are perfect use cases for custom components and would also make fantastic community plugins that others could benefit from - if anyone is looking for a small project this would make a great one!

[JessRynkar]

Hi everyone! Thank you for all the thoughtful ideas and your patience on this topic. We’ve reviewed and triaged all the suggestions here, and I’ll be posting detailed replies shortly. Excited to finally move forward with localization improvements — stay tuned 🙏

[anyuj]

Any chance to consider #4195, which has 100+ upvotes for editing multiple locales at once?

[JessRynkar]

Yes! #4195 will be prioritized as part of this work, it is a large feature which will take some time to fully build before releasing into core, however we are getting the ball rolling on this one.

[nachomglz]

@JessRynkar thank you so much for the updates! it's so exciting that we're finally getting these highly anticipated features, this will definitely get our projects to the next level <3 <3

[MurzNN]

I've described my suggestions about improving the localization here #13361 - you can take a look at them too and maybe even get some good ideas ;)

[ds-onv]

Dropping my suggestion #13858 as comment since its also related to l10n :)

[nachomglz]

Hi @JessRynkar , just fyi, I wanted to try the fix for this issue: #13447, I'm on payload 3.58 right now but I'm still getting the same issue, I have localization enabled globally, but my Articles collection doesn't have any localized field. I'm still getting the "Publish In [Locale]" button instead of the normal publish button....

[nachomglz]

I think I found the issue, here's a bug report that I hope makes sense @JessRynkar : #14386

[JarrodMFlesch]

Update

We have unpublish current locale likely ready to merge soon, maybe next release.

👉 Localized Meta

The next main focus is going to be adding a localized group field: localizedMeta to version enabled collections, which by default will track the document status per locale. This would allow you to query documents where localizedMeta._status === "published" and you would query with locale="es".

You will have to enable this via a flag once it ships because it would be breaking if added by default due to migrations needing to be created and ran for the new field. But in V4 I think this will come OOTB. I think we should provide a migration script for users to run and migrate existing documents to include this format.

Recap

I think there are a lot of good suggestions in this thread! I think these two seem nice to have:

• Required Fields per Locale
• Allow editing multiple locales at once

[cbratschi]

@JarrodMFlesch thanks for the status update. Looking forward to localizedMeta. I hope there will be a config to add custom values to this group. In our workaround we are currently using these locale specific fields:

  locales?: {
    de?: {
      status?: ('published' | 'draft') | null;
      createdAt?: string | null;
      createdBy?: (string | null) | User;
      updatedAt?: string | null;
      updatedBy?: (string | null) | User;
      publishedAt?: string | null;
      publishedBy?: (string | null) | User;
      deletedAt?: string | null;
      deletedBy?: (string | null) | User;
    };
    en?: {
...

We did not use a localized group to get the locales values in every result.

Did you already start implementing some v4 features? Will there be some alpha and beta releases like for v3?

[JarrodMFlesch]

You could have used a localized field and then queried with a locale. You could have also made a separate query with locale=all if you really needed to get them all at once, pair that with the select and you've got the same data.

localizedMeta will be available in v3 under a flag that you will need to set in your config.

[MurzNN]

Great progress! Could your share what is the plan for revision support per translation? For example, I published a document yesterday with en+de translations, and today updated+published the en translation only, but de translation should be still in review for several days, so the publishing should be delayed.

So, the website should display the en revision from today, but de revision from yesterday.

Will it work with the current implementation?

Probably, we need to add one more status "archive" to indicate previous revisions that were updated by the published ones.

[tapan4611]

hello @JessRynkar ,
I'm attempting to use PostgreSQL version 18 with Payload CMS, but I'm encountering persistent errors and believe it may not be supported. Can you confirm the recommended or maximum supported versions of PostgreSQL for the current Payload CMS release?

[tapan4611]

hello please anyone have sloution for this query so let me know? it's urgent

[maximseshuk]

hello please anyone have sloution for this query so let me know? it's urgent

Maybe it's worth creating an issue and pointing out the errors too. This is about improving localization, not supporting PostgreSQL.

[JessRynkar]

🚀 Update: Localized Status (Experimental) is available

Hi everyone. In v3.72.0 we released the new (experimental) Localized Status feature, which allows each locale to manage its own publish / unpublish state independently for collections and globals.

How to enable

This feature is opt-in and requires:

• Enabling the experimental flag
• Enabling it per collection / global
• Running a migration if you already have versioned data

👉 Full details, benefits, config examples, and migration steps are documented in the PR here: #14667

Important notes

• ⚠️ This feature is experimental / beta
• There may be edge cases, especially with complex versioning setups
• Please report any issues or unexpected behavior as a GitHub issue

UI follow-up

We’re aware of feedback around the current UI, specifically the unpublish button being a primary button. We plan to move the unpublish controls into the document actions dropdown shortly. That work is already underway, you can follow along here.

Thanks again to everyone who contributed ideas, use cases, and patience here 🙏