But developers all over the world are using Payload, and they don't all speak English. So we prioritized this feature and built it over the past few weeks. It dramatically improves admin UX for those where English is not their first language.

Massive shoutout to our community

First and foremost, we just need to take a second to be thankful for how hard and fast our community has helped translate our UI. We have been absolutely blown away.

A sincere thank you goes out to the following contributors:

It's pretty much astounding how much work our community has poured in over the past few weeks alone to get this effort across the finish line.

What's new

Right off the bat, the admin panel will now use the language settings from your OS and browser to render the admin panel in your preferred language. If you want to toggle back and forth between languages, you'll find a new control on the Account view, allowing you to do exactly that.

We also made it easy to configure i18n in your own projects. Right in your Payload config you can set the fallback language(s), add translations to use in your custom validations and components or even override the translations Payload ships with.

You can even provide translated labels for each of your collections, globals, and fields for each language that you want to support. You can learn more from the documentation here.

Pretty cool side-effects

One of the things that we've known we needed to fix for some time now is the fact that our collection, global, and field labels have been used to generate GraphQL and TypeScript type names, which is not ideal. Labels should be considered as something that are able to be changed without breaking or modifying the API in any way. And now that developers are able to translate labels for many languages, it became even more apparent that we needed to ditch our reliance on labels here and instead rely on collection / global slugs, and field names to generate these API-facing properties.

So we did exactly that. We completely removed our reliance on labels and now are instead generating based on slug and name which is a huge improvement to DX and workflow.

How to determine if you will have a breaking change

Check your project for collections, globals, and blocks that use a customized label. Do you have any collections that use a custom labels property? If so, because we are now auto-generating GraphQL and TypeScript names, your GraphQL API and TypeScript types may now be differently named. Same goes with the global label property and the blocks field labels.singular property.

Declare your own GraphQL and TypeScript names

Like what we're doing? Give us a star on GitHub

We're trying to change the CMS status quo by delivering editors with a great experience, but first and foremost, giving developers a CMS that they don't absolutely despise working with. All of our new features are meant to be extensible and work simply and sanely.

Get up and running with one line

Getting started with Payload is easy—and free forever. Just fire up a new terminal window and run the following command:

1npx create-payload-app