Make default language required

[johannesschaffer]

Bug Report

=> Not quite sure whether it's a bug, but given Payload's otherwise excellent handling of required fields, this behaviour seems kinda strange.
If I switch the langue to a non-default language (e.g. de) and create a new document, it lets me publish it without having filled out required fields in the default language

Other Details

Not quite sure, whether there is an easy solution for that, given that Payload can be used without the Draft's system.
Maybe make the language at least local to a document?, so when creating a document in en, then switching to de to edit it, then creating a new document, it will default back to en instead of staying in de.
Otherwise, at least a warning before publishing, that the default language has missing fields, would be nice (it's less about me, as a developer, having to deal with null exceptions, and more about the user, following the worklow described about, possible not being aware of the fact, that he didn't fill out the default language.
On a side note, I find it quite unintuitive, that the language switcher isn't scoped to the document, like in any other CMS.

[quornik]

Why would you consider this a bug? Let's flip this scenario: Would you like to be forced to create a "default", let's say english version of a page or a record which you need to be present in the specific language, not the default one? There are pages in site structure that make sense in DE and does not in EN. Would you like to be forced to create them both?

[johannesschaffer]

Ok, I get your point, but that only affirms my last point, to make the lagnuage selection/translation collection specific. If I set a field to "localized: true", I expect the user to at least fill out the default locale. It's also unintuive for the user to fill out some pages in both languages and some only in one. It would be much better if I could set the possible languages on a per collection basis. Then pages that only make sense in one language only have the option to be translated in one language.
I also still think, that it's easy for the user to forget to switch the language back to the default language before creating a new document. Lets say I created Blog 1, then switched to DE and filled in the translation. After that I create Blog 2. I would expect it to start in the default locale again.
But I don't know, maybe that's more of a specific use case, where the default locale is much more important than the other locales, like in our case🤷

[jmikrut]

Hey @johannesschaffer and @quornik — just putting out some thoughts here.

Field vs. document-based locales

We deliberately adopted field-based localization for a lot of reasons. It's actually becoming the favored way of storing locales. Contentful and many others store locales based on field, which comes with a lot of benefits. There are lots of cases where data does not need to be localized, but it needs to exist in each locale — like publishedAt, or order, or parent, or categories, etc. So we are absolutely not going to move away from localizing on a field-level.

But, if you want to localize documents on a field-level, you could easily do so by setting up your content model in a way that stores locales in that way using a locale select field and then conditional logic to store data based on each locale. This is low-hanging fruit and can be adopted on a case-by-case basis.

Potential fixes, etc.

I personally like the idea of automatically switching the user back to the default locale upon creating a new document, but this is not completely bulletproof as it does not restrict the creation of documents first in other locales outside the admin panel and via API.

And enforcing that the default locale must be fully completed also fights against what @quornik is saying in that some pages may not need a default locale at all, and we actually see this quite commonly where a page only needs data in a given locale and not in the default locale.

if I could set the possible languages on a per collection basis. Then pages that only make sense in one language only have the option to be translated in one language.

@johannesschaffer I think you might mean on a per document basis? If so, this could potentially be doable with a set of document fields, hooks and UI components where you have a multi-select for which locales the document is applicable for. You could have a ui component that monitors for which locales the document applies to, and ensure that it is translated accordingly before allowing a user to save. In this ui field, you could also change the locale to default upon creation like you've mentioned. Lots of potential there.

After thinking through this with the Payload team this AM, I think there are options with custom components / hooks here but I am not sure that there is a specific solution that we could work into Payload's core.

I will convert this to a discussion though and we can keep the conversation going there. If there is a bug, or something is broken, we can recreate an issue and it will get prioritized accordingly. 👍

Thank you for the conversation so far here. Super interesting!

[johannesschaffer]

@jmikrut Don't get me wrong, I'm definetly a fan of field-based localization. Really don't like the way Prismic handles it

I personally like the idea of automatically switching the user back to the default locale upon creating a new document, but this is not completely bulletproof as it does not restrict the creation of documents first in other locales outside the admin panel and via API.

As I said, my main point of this is not to benefit the developer, not having to handle nullpoints, ... It's for the user, being 1. more intuitive, as described & 2. really serve more as a reminder, that he didn't fill out the default locale (which is probably the most important one). Prismic has a whole debate about a similar topic, whether to allow field validation, with the same arguments. Personally, I also see field validation more as a help to the user (not forgetting a field or filling it wrongly), than to the developer

And enforcing that the default locale must be fully completed also fights against what @quornik is saying in that some pages may not need a default locale at all, and we actually see this quite commonly where a page only needs data in a given locale and not in the default locale.

As I said, why not make it customizable then. Like a "required" setting. Like I said above, it's for the user, so even just a warning would be fine.

I think you might mean on a per document basis? If so, this could potentially be doable with a set of document fields, hooks and UI components where you have a multi-select for which locales the document is applicable for. You could have a ui component that monitors for which locales the document applies to, and ensure that it is translated accordingly before allowing a user to save. In this ui field, you could also change the locale to default upon creation like you've mentioned. Lots of potential there.

Sure, but DX is one of the main reasons I switched from the otherwise much more popular Sanity.io to Payload CMS. They e.g. didn't support localization at all, just gave a guide on how to implement it manually (also made the UI a bit messy). Personally, while I like customization & am developing in React, I'm still not really comfortable extending the CMS - So I guess this would be more of a feature request then - I still wanna highlight the point again, that any other CMS I know of, like Contentful and Konten.ai, switche the locale back to the default one when creating a new document. That's the reason I intially catatorized it as bug

An additional problem with this approach is, that if, like you said, not everything is required in every locale, that would include the Title. In this case the title column just displays NULL when having the document created in only the not-default locale. This is especially bad when linking to other documents where I rely on the title to find the right document (e.g. creating a relation from Article to Author)

[lilnotes]

Hi, @jmikrut!
Could you provide an example for this kind of solution?

I personally like the idea of automatically switching the user back to the default locale upon creating a new document, but this is not completely bulletproof as it does not restrict the creation of documents first in other locales outside the admin panel and via API.

I want to switch the user back to the default locale when user opens http://url/admin/collections/mycollection/create?