Localization for the admin panel components

[sosafe-steven-snoeijen]

At the moment there is localization for data available through; Enabling in the Payload config.
But when switching the language in the admin panel does not translate:

1. default components like the "Save" button or any Base components text
2. field's name and description of a collection, configured in code

Looking through the code, I think this could be implemented.
Here are the possible solutions:

1. src/admin/components/views/Global/Default.tsx#L118 and the use of useLocale.
2. The CollectionConfig could be expanded by expanding the current config for label/name and description.:

...
"label": {
  "en": "name",
  "nl": "naam"
},
...

This again with the use of useLocale in for example: /src/admin/components/forms/field-types/Text/Input.tsx#L68

Just checking in if this is a viable option, and if other people are interested in a feature like this.

[sosafe-steven-snoeijen]

Diving more deeper into this; it does not make much sense to me that changing your language is for changing the content

It makes more sense that this button is for changing the admin-ui's language and not the content/data.

And then add a language button in the form for translating the content/data of that collection-item.
For example at any of these marked locations;

Any thoughts about that?

[jmikrut]

Yes, I agree with this. We do have admin UI localization on our roadmap, and we agree that it is a good thing to add, but even when we do have full localization, we will need to separate changing the "document" locale and changing the "admin UI" locale.

Further, I think that the right place to change the "admin UI locale" would be to put it in the Account view, in the Payload Settings area:

We would store the requested admin UI locale in local storage.

[sosafe-steven-snoeijen]

Thank you for your quick and clear answer.
The location for the "admin UI locale" is fine to place there I guess 😀

I am really interested in this feature and would like to have this in a few months.
So I might want to contribute this functionality by creating a pr "soon-ish". Are there any specs from your point of view so I can create this feature that aligns with the thoughts of the maintainers? 😊

[jmikrut]

Oh wow if you wanted to help take a crack at this that would be HUGE.

It would be time-consuming, but fairly straightforward to do. I've just updated the roadmap item discussion with implementation notes.

Take a look and let me know what you think! We could get a dialog going on that open roadmap item as well if you have thoughts / questions. That would be the proper place to keep the discussion going.

[sosafe-steven-snoeijen]

Awesome! Nice explainer. I'll move the discussion to there when I have feedback. Thanks again!

[sosafe-steven-snoeijen]

@jmikrut sorry to tag you like this. But as I have your attention; the other thing I was checking in this discussion. Is if it would be possible to add translations to the labels and descriptions of fields in CollectionConfig, and render that by the chosen language in #300. This could be a nice addition after #300 is implemented, I think.

[jmikrut]

Yes. This is also on our radar and I agree that it needs to be done. I'm going to open a new issue for this one and mark it as planned, accordingly. This is something that the Payload team will have to resolve though, as it has GraphQL ramifications.

[Rar9]

I fully agree with @sosafe-steven-snoeijen suggestions.

The current language switch should ONLY be used for switching the system language, and not for content, as the current position feels wrong.

The content translation will need to be fully separate from the system language handeling and its controls will need to move to the content area like the yellow suggestions.

By adding translations via label for each field feels right and Intuitive as well

I also fully agree with @jmikrut that for the system translations, each USER will require a language preference similar as the access roles.

Please do think this a step further, for evolving PLUGINs.

In Drupal this issue is still not fully resolved after years of discussion, as some user will only use and accept a localized setup without requiring English at all.

So always keep English the default language, with some possibility to hide it from backend.

For this I believe already suggested somewhere else the possibility for the community to update payload's system localisation, so it could become a yarn/npm INSTALL OPTION for upcoming Version 2, that will most likely support custom backend themes as well.

Please also consider adding an actual translation STATUS on the language switch buttons to provide user feedback on the missing translated content fields.

[jmikrut]

All of this is done and now released in 1.2.0!

[sosafe-steven-snoeijen]

Damn that was fast!