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

• Show Localized Status Data - Pull Request #13207

In Progress

• Ability to unpublish specific locales - Feature Request #13436
• Allow Group Status Field Including All Locales - Feature Request #13440 - Pull Request #13509

Planned

• Renovate Status Component in Document View to Show All Locale Statuses - Feature Request #13437
• Independent Timestamps for Each Locale - Feature Request #13439
• Delete Documents by Specific Locale - Feature Request #13441
• Accept Multiple Locales in fallbackLocale Query - Feature Request #13443
• Duplicate Documents by Specific Locale - Feature Request #13444
• Required Fields per Locale - Feature Request #13445
• Expose _locale in Document Response - Feature Request #13446
• Allow Editing of Multiple Locales - Feature Request #4195
• Option to Display Fallback Data within UI - Feature Request #13448

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

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

[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

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

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

[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

[jessrynkar]

Another upcoming localization enhancement: Show Localized Statuses #13207

Background

Currently the status displayed in the document view and list view reflects the latest doc status, regardless of the locale you are viewing.
For example, if you have published in EN, then save a draft in ES, when you return to EN the status will show draft even though EN is published.
After this update, the status shown will change to reflect the locale that you are currently viewing.

For this, we have introduced a new experimental config section.

This option can be enabled by adding experimental.localizeStatus: true to your Payload config.

The PR can be found here and will be merged shortly: #13207

[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 ;)