Localized Text Field Component

[manuelebagnolini]

Hi,

we are a web agency with more than 20 years of experience and we are deciding to replace our custom-made CMS with a modern headless CMS, and we’ll really like to use Payload CMS.

The only feature we are missing is the possibility to have a localized field component that permits to:

• Instantly understand which fields are localizable and which are not.
• Instantly understand which localizations are provided for the specific field (without having to switch locale for the full document).
• Cycle between field localizations to easily check the current values.
• Facilitate quick data entry even in the case of a large amount of values at once.
• Easily add a localized value for a language not yet provided.

This is an example of how our custom CMS actually works:

1. The default language (English) value is shown in the field header and in the input field of the English tab. Just by looking at this, the user knows that this is a localized text field and that it’s currently localized in English and Italian.
   

2. By selecting the Italian tab the user can see and edit the Italian localization.
   

3. By selecting the feature “Add text in a language” the user can select one of the available languages not yet used for the field, in this example the French tab will be added and the user could provide the French localized value.
   

We are used to build complex sites with a lot of different languages (usually more than 10) and this feature is indispensable for us for choosing our new CMS.

Our customers find this system very intuitive, and we think it would be a great addition to Payload CMS.

Obviously, we don’t expect the component to be exactly like the one of our custom-made CMS, the pictures are just an example to explain the feature, the new component should be integrated with the style and UX of the Payload CMS Admin UI.

You could be interested to include this feature in Payload CMS?

In case we would be available to actively collaborate in the development.

Looking at the code, we should be able to create our own custom UI component but the problem is that the field value of the localized field is flattened to the current locale and we can’t load and save the JSON data containing all the languages at once.

Our basic idea is to create a new version of the useField hook (i.e., useLocalizedField) that works with not flattened localized fields like in the beforeRead collection hook. We understand that is a major change in the Payload CMS core regarding the data access of the collections.

[jmikrut]

Hey @manuelebagnolini — thank you for going into such detail here. We really appreciate it!

We're actually going to be working on improving our localization experience over the next few months, and I think we can make a lot of this easier for you and your team. Many of the ideas that you're referencing could end up being possible for sure.

we can’t load and save the JSON data containing all the languages at once.

Actually, you can! Use locale=* as a query param in the REST API and you can get data for all locales. 👍 That might help you get started on your custom UI fields at least. Also, I should point out that you can probably get some fancy stuff done with Description components as well, on each field, so as to try and indicate which field has which translation, etc.

As for the concrete items that we plan to take on and build, I will update this thread once we have had time to nail them all down. But this is good stuff.

[manuelebagnolini]

Thank you @jmikrut.
In the meantime we'll look into your suggestions.👍

[manuelebagnolini]

I share an update on the development of the feature.

In details we added:

• A sticky component at the top of document with the locale selector to easily switch locales.
• A "Change localization" button to instantly understand which field are localized and access the localization feature
• A modal that allows you to edit the existing localizations and insert new ones. The localization in the reference language (current document locale) is always visible to facilitate the translation. You can save all changed localizations at once as a drafts or publish them directly.

We are currently having problems saving so we opened these issues: #1415, #1419

Instead of calling an API for each locale it would be more efficient to call a single API to massively update all languages. Could it be added to this discussion: #1382?

[b-barry]

Are you planning to make it open source?

[manuelebagnolini]

Are you planning to make it open source?

Yes, it's part of an open source project that we plan to release this year.

[ssyberg]

@manuelebagnolini if I'm understanding correctly you're developing this feature outside of the mainline payload project correct? Do you have any indication if this will be brought in to the core?

[ssyberg]

@manuelebagnolini here's an example config, can't explain why but I've verified that hasLocalizedFields is false here.

config.fields [
  {
    "name": "editSyndication",
    "type": "ui",
    "admin": {
      "position": "sidebar",
      "components": {}
    }
  },
  {
    "type": "row",
    "label": " ",
    "fields": [
      {
        "name": "slug",
        "type": "text",
        "required": true,
        "hooks": {
          "beforeValidate": [
            null
          ]
        },
        "admin": {
          "description": "If left blank will autogenerate from the title."
        }
      },
      {
        "name": "path",
        "type": "text",
        "unique": true,
        "admin": {
          "readOnly": true,
          "position": "sidebar"
        },
        "hooks": {
          "beforeChange": [
            null,
            null
          ]
        }
      }
    ],
    "admin": {
      "position": "sidebar"
    }
  },
  {
    "name": "translations",
    "type": "select",
    "options": [
      {
        "label": "En",
        "value": "English"
      },
      {
        "label": "Ar",
        "value": "Arabic"
      },
      {
        "label": "Cr",
        "value": "Cyrillic"
      },
      {
        "label": "Hi",
        "value": "Hindi"
      },
      {
        "label": "Ch",
        "value": "Chinese"
      },
      {
        "label": "Sp",
        "value": "Spanish"
      },
      {
        "label": "Ge",
        "value": "German"
      },
      {
        "label": "Fr",
        "value": "French"
      },
      {
        "label": "Th",
        "value": "Thai"
      }
    ],
    "hasMany": true,
    "admin": {
      "readOnly": true,
      "position": "sidebar"
    }
  },
  {
    "name": "index",
    "type": "relationship",
    "label": "Syndications",
    "relationTo": "indexes",
    "hasMany": false,
    "admin": {
      "hidden": true
    }
  },
  {
    "localized": true,
    "admin": {
      "components": {}
    },
    "name": "title",
    "type": "text",
    "required": true,
    "unique": true
  },
  {
    "name": "_collection",
    "type": "text",
    "admin": {
      "hidden": true
    }
  },
  {
    "localized": true,
    "admin": {
      "components": {}
    },
    "name": "test",
    "type": "text"
  }
]

[ssyberg]

Ok I actually figured out whats happening here, it looks like it's only traversing that first row fieldset, it doesn't appear to be looking at anything else.

[manuelebagnolini]

Hi @ssyberg, thank you for giving us this example, we have released version 0.4 which should solve the problem you have encountered.

We have also added a first implementation for displaying the percentage of document translation as discussed in #2577

In the language bar of the document a colored indicator is shown which indicates the completion status of the texts in the language and a tooltip appears with the explicit percentage by hovering over the language button:

A known issue is that at the moment the calculation does not evaluate texts inside blocks fields but that will be fixed in the next version.

[ssyberg]

Awesome, so far so good, will report back if we hit any issues. JFYI looks like the css import is still required, might want to add that back to the config instructions for the moment (https://www.npmjs.com/package/@websolutespa/payload-plugin-localization)

[manuelebagnolini]

Thank you! We have updated the instructions specifying the correct import of the css.

[manuelebagnolini]

Hi @manuelebagnolini , thank you for your plugin! It's very helpful! I would like to try adding a button that allows me to translate the text using ChatGPT, but I can't open your code repository. Will you share the repo?

Hi @simonereda we will definitely share the repo, at the moment it is still private because the plugin is part of a mono repo where the rest of the project is not yet possible to make it public.

Furthermore this plugin is still an alpha version that still needs more testing.

[ssyberg]

Hi @manuelebagnolini the more I've been using this the more I've come to feel the mix of localized and non-localized fields on a given edit view is going to be very confusing for our editors. As such, I'd like to suggest something that might seem a bit drastic - what if on all "translation" views, non localized fields were fully disabled and only enabled on the "default" language view? I think the UX would need to be thought through a bit, but IMO would be a big improvement overall.