Improve language handling/display

[Rar9]

The is no clear indication in what language the user is actually editing in.

It is also unclear which fields are localized or generic.

Even worse, its totally impossible to see what transactions might still be missing or are incomplete.

This is especially true on mobile as the language switch is again hidden in menue

A clear indication like other cms offer it would be great to see in future updates.

Update from @tylandavis 11/28/23

We've recently gone through our roadmap items and will be prioritizing tasks accordingly. We've created individual roadmap items for each feature planned, and will close this discussion and continue tracking on individual tasks.

Here are the roadmap items related to Localization:

1. Publish Individual Locales #4194
2. Allow Editing of Multiple Locales at once #4195
3. Fallback language should be able to be specified per locale #4198
4. Copy language over to another locale #4199
5. Visually differentiate localized fields from non-localized fields #4200

Update from @jmikrut 5/23/23

We need to invest time into improving the localization UX within Payload.

On the radar:

1. Improve visibility of "active" locale

Right now, the locale selector is small and hidden in the bottom-left corner. It should be more globally apparent and be instantly recognizable that you are browsing the admin UI within a given locale.

A redesign of that area of the CMS is needed, and we need to determine if it makes sense to pull the locale selector out of the sidebar entirely.

Work involved

• Design work should be either performed or approved by the Payload team. We will be prioritizing this over the coming weeks.
• Development of the changes involved could take place by both the Payload team and its community, but design intent should be approved before development begins.

2. Visually differentiate localized fields from non-localized fields

It's tough to identify at a glance which fields have localized: true, and which fields do not. We should consider extending the built-in field types with a way to denote if they are localized or not.

Work involved

• Design work should be either performed or approved by the Payload team.
• Once design is approved, changes could be built.

3. Allow editing multiple locales at once

We need to open up the possibility of editing multiple locales at once, in a way similar to how Contentful does it. The editor should be able to select which locales to show at any given time, and a field per locale should be rendered allowing the editor to view multiple locales at once.

Work involved

• Before design work is completed, we could begin extending the create and update operations to accept more than one locale's data in a single request. Similar to the way that locale=* works now. This would be a backend-only change, and would be relatively isolated in nature.
• Design intent should be established or approved by the Payload team.
• Once we have the API changes that allow locale=* on create and update, we should begin extending the Payload UI so that it meets design intent, showing multiple fields at a given time in the editing UI.

[jmikrut]

Hey @Rar9 I agree that some TLC here is needed, and I will mark this as planned for us to tackle it accordingly.

Thanks for bringing this up!

[Rar9]

See #1252

[cbrualdi]

See also #1492 and #1308.

@jmikrut, do you already have some ideas to share on how to improve localization management?

What's your thoughts on the proposal in #1308 to make all languages editable at once?

I personally think giving the ability to view, edit and save multiple languages at the same time would be a huge step forward for Payload. Other CMSs are always flawed on this point and we really have the potential to beat them all.

[58bits]

+1 for the all points above. Also quite a bit of activity here in other areas. Would an RFC approach help in setting goals / feature priority in the next iteration of i18n?

[jmikrut]

Hey @58bits anda @qbeauperin I just updated the original discussion post at the top of this thread with a lot more information.

Will you take a look and provide comments?

[qbeauperin]

Great stuff, these couple of points would definitely improve the overall UX by a lot!

Regarding 1., I have a feeling that implementing 2. as well as #2702 might be enough of a solve for it (or at least lessen the issue), depending on what the solve for 2. will be. 👍

[kariyngva]

Regarding 3., would you be able to opt in or out if multiple local editing becomes the default?

[58bits]

Hi @jmikrut - this all looks great, and super glad to see this moving forward.

The idea of editing multiple locales at once also sounds pretty interesting, but I'm genuinely curious to know how this would look in terms of overall editing surface or UI/UX - I guess in a way the same question that @kariyngva is asking above in terms of whether it could be enabled/disabled.

Also based on a point raised by @kariyngva below - being able to 'seed' or pre-populate a field based on the default (or other) locale would be super useful. For example, a richtext field may have its own media (inline images etc) and even a layout. The editor would ideally like to 'kick start' the translation by bring the content over, and then 'chipping away' at the required text changes.

I'm guessing Labels for locales are a given (also based on #2702)

Would very much look forward to seeing the designs if and when the Payload team presents them. ;-)

[kariyngva]

👆Some more thoughts on this.

I have a feeling pre-populating fields with the original content might be solving the same issue as editing multiple locales at a time, i.e. having the original text available to translate.

That said, translators that speak 2+ languages might prefer that option so there would still be a use cases for it, other than preference.

[kariyngva]

UI improvements

Switching only the current documents' locale as proposed in #1308 would definitively be an improvement on the current UI.

Translating from default local to another

At our agency we create lots of websites that have multiple languages. Most of the time a translation of a page won't be 100% the same block for block. This fact makes it so that we cannot have the localisation on the block fields level. i.e. we need to localise on the block field:

const Page: CollectionConfig = {
  slug: 'pages,
  fields: [
    {
        type: 'blocks',
        name: 'Content',
        localized: true,
        blocks: [
          CallToAction,
        ],
      },
  ],
};

The issue

This would create a bit of an issue for the translator, as soon as they switch to the locale they're translating to they lose all the original structure and content.

Proposal

I see two possible solutions to this. The first one would be to add an option of copying structure (blocks) and/or content from the origin locale. The second one would to make switching between locales more of an operation.

For the former it could be opt in. So when you've configured locales to give the c/p option you would get a button in the collection edit view to c/p structure and/or content. This operation would only run once, so after it's clicked the button disappears. Similarily the c/p operation should probably not an option after saving the document.

The latter suggestion assumes that there's a locale switcher within the collection edit view. This switcher would have a separation between locales that have already been translated/copied and those who have not, i.e. "en | es | copy to de" . When selecting the "copy to" option a prompt appears where the user selects between copying structure, structure and content or creating a blank translation.

I've added a graphic that shows a dropdown where the current locale is english, where german is already translated but spanish and french aren't.

[58bits]

An option to pre-populate or copy from default would be super helpful.

[purenofuss]

Perhaps the ability to create custom copy handlers like auto translations, structure & content

[jacobsfletch]

Update on "Improve visibility of active locale" described above, it's done 🎉 See this discussion for all the details and my comment here for the latest update. This will get released in Payload 2.0.

The other two items, "Visually differentiate localized fields from non-localized fields" and "Allow editing multiple locales at once" are still in the design phase but are high in priority. Will post updates as we have them.

[purenofuss]

Feature Request: Dynamic Addition of Languages for Multi-Tenant Platforms

Suggestion:

For more flexible and inclusive multi-tenant platforms, perhaps the administrators or users could have the ability to add languages dynamically rather than them being hardcoded into the config.

User Flexibility: Tenant wouldn't be restricted to using the languages set by developers, offering more freedom and flexibility when using the platform.

Customization: It allows multi-tenant platforms to be more versatile for users to modify as per their requirements.

[NetroScript]

I found this discussion, and personally also need the Visually differentiate localized fields from non-localized fields, and implemented a rather hacky solution for myself.
But potentially other people also would like using it temporarily until an official variant is implemented.

---

First a preview of how it looks, and then how it is implemented:

Taking a look at the HTML code, I saw that currently there is no CSS class for localized fields, however the form contains the current language code in the URL.

So the idea is adding a custom class to all localized fields, and then using a custom SCSS file (which is loaded in the buildConfig function) to visualize the current language for those fields.

Concretely, my code looks like this:

Within the collection:

// Field definition adding a custom class
{
	name: 'function',
	label: {
		en: 'Function',
		de: 'Aufgabenbereich'
	},
	type: 'text',
	localized: true,
	admin: {
		className: 'localized-field'
	}
}

Global Stylesheet:

/* Using the custom class, add a pseudo before element to each label of localized inputs */
.localized-field {
	.field-label::before {
		display: block;
		content: ' ';
		background-size: 28px 28px;
		height: 28px;
		width: 28px;
		margin: 0px 10px;
        margin-top: -1px;
	}
}
/* Depending on the currently active locale, show a different flag icon */
.form[action$='locale=de'] {
	.localized-field .field-label::before {
		background-image: url('/assets/icons/Flag_of_Germany.svg');
	}
}

.form[action$='locale=en'] {
	.localized-field .field-label::before {
		background-image: url('/assets/icons/Flag_of_the_United_Kingdom_(3-5).svg');
	}
}

In this example there is a statically served directory assets which stores the flags, you could however also use any other method.
Depending on your needs you could also adjust some factors, after all you have the information available which fields are localized and what the current language is.

[tylandavis]

We've recently gone through our roadmap items and will be prioritizing tasks accordingly. We've created individual roadmap items for each feature planned, and will close this discussion and continue tracking on individual tasks.

Here are the roadmap items related to Localization:

1. Publish Individual Locales #4194
2. Allow Editing of Multiple Locales at once #4195
3. Fallback language should be able to be specified per locale #4198
4. Copy language over to another locale #4199
5. Visually differentiate localized fields from non-localized fields #4200