Localized defaultValue, label(s)

[chladog]

Currently there is no option to pass defaultValue of the field based on the locale.
E.g. I have locales: en, cs and I need to provide different for each:
Something like:

            {
              name: "ceremonyLocation",
              type: "textarea",
              label: "Ceremony Location",
              localized: true,
              defaultValue: {
                en: `The wedding ceremony will take place at `,
                cs: `Obřad se bude konat `,
              },

if particular locale not present then should use default locale.
the object of locales could be optional and setting simple string should be also allowed (not localized default value)

defaultValue?: string | {
     [key: locale]: value
}

Same applies for label(s) properties that could be i18n this way.

[jmikrut]

Hey @chladog — great idea. We can add this to our planned features.

Question - should we consider making defaultValue accept a function so that you could return a value based on other fields, locale, etc?

Would that be more powerful?

[chladog]

I guess the need depends on Payload use-case. In my case the app itself is basically front-end form app built up from the Fields[] definitions, I use Payload's admin area for managing users, mailing, user entries, additional hidden fields etc.
Currently I write extended field definitions with "metadata: { ... }" properties that I remove before passing it to Payload config. It works great for static data, but it's unnecessary hard to implement any kind conditioned and dynamic data (like this topic's i18n defaultValue, i18n labels, placeholders, icon names, custom input data, etc.

As you mention I could add additional fields for holding such metadata and run some logic in hooks, however my forms are huge and it's not comfortable to mix user-entered form fields with system fields, schema gets bigger, also frontend application gets complex as I can't simply loop and render all form fields, I need to filter out system fields, pair system fields with corrent form fields merge the data and implement dynamic logic on client-side - all that with i18n data in all supported languages.

[DanRibbens]

Thanks for the extra context.

I had thought you could use admin.hidden for system fields and maybe prefix field names with something like sys or _ for filtering later. I didn't realize you'd want to add this for every field, I get why you wouldn't want to now.

If you want to propose details for your metadata feature idea we could see consider adding it or building it as a plugin.

[DanRibbens]

I think we're close to having this one complete.

#547

[DanRibbens]

Released in v0.16.1.

I used your example @chladog to write the docs, thanks for that!

[chladog]

Hello Dan, this is perfect!
Just a little fix - the example sets

admin: {
      description: ({ user, locale }) => (`${translation[locale]} ${user.name}`)
    }

instead of defaultValue.

I'm about to test this feature soon. I hope you will implement this for label(s) as well ( once #515 tackled )
Keep up the great work!

[bratvanov]

As in #273, this feature request can be closed, since defaultValue as a function has been supported for a while:
https://payloadcms.com/docs/fields/overview#default-values

Here is an example of a defaultValue function:

import type { Field } from 'payload'

const translation: {
  en: 'Written by'
  es: 'Escrito por'
}

export const myField: Field = {
  name: 'attribution',
  type: 'text',
  defaultValue: ({ user, locale, req }) =>
    `${translation[locale]} ${user.name}`,
}

Tip: You can use async defaultValue functions to fill fields with data from API requests or Local API using req.payload.