Entity view/form mode formatter/widget settings have no translation UI

I think it's time to update summary with latest screenshots and ask for #ux review

I've been giving a try to this one and I can say it works well.

The edit/translate UI may need some improvements though. I don't think this can be considered 'usable' without adding proper field / widget names everywhere.

Then, about the implementation, some notes:

1. I think this should be moved, as much as possible to the field_ui namespace. The feature is dependent on field_ui being active, isn't it?

Instead of core/modules/config_translation/src/ConfigTranslation/EntityDisplayMapper
maybe use core/modules/field_ui/src/ConfigTranslation/EntityDisplayMapper
just as core/modules/node/src/ConfigTranslation/NodeTypeMapper - which is the only other example I've found

2. Bit hackish, though I understand there's no easy way of doing this - setting proper names. However, relying on the element title is a no-no IMO.

+/**
+ * Implements hook_preprocess_HOOK() for details element templates.
+ */
+function config_translation_preprocess_details(&$variables) {
+  if (isset($variables['element']) && $variables['element']['#title'] == 'Field widget') {
+    $field = ucwords(str_replace('edit-', '', $variables['attributes']['id']));
+    $variables['title']['#markup'] = $field . ' field widget';
+  }
+}

I mean, we are doing a core patch, right? So we don't really need to hack around. If we need one more hook, we add it, if we need better form element markers, we add them - in field_ui module.

The best option I can think of, so far, instead of adding more hooks is maybe adding some ConfigMapperInterface::massageForm() to the interface... though not sure about it, I'm working on some proof of concept, not there yet...

The other option would be maybe... but same, working on that, not yet there:

/**
 * Implements hook_form_BASE_FORM_ID_alter().
 */
function field_ui_form_config_translation_form_alter(&$form, FormStateInterface $form_state) {
  /** @var \Drupal\config_translation\ConfigMapperInterface $mapper **/
  $mapper = $form_state->get('config_translation_mapper');
  // This is_a(), just to avoid hard dependencies on other modules classes. We wouldn't need it if the mapper was in this module though.
  if (is_a($mapper, 'Drupal\config_translation\ConfigTranslation\EntityDisplayMapper')) { 
     // @todo Add field / widget names, etc, etc...
  }
}

As I said, working on some options ... still haven't figured it out yet... but what I see is the config_translation UI is pretty complex and limited. So anything that makes it easier/better I think will be welcomed...

Trying to apply #207 on Drupal 9.5.3 and constantly getting error:

Could not apply patch! Skipping. The error was: The process "patch '-p1' --no-backup-if-mismatch -d 'web/core' < '/var/folders/r7/r0x8c0nd55b0zxmrxnxdh2wc0000gp/T/63fa32d91a4f1.patch'" exceeded the timeout of 300 seconds.

I am desperatly trying to find a solution for Field Group translations as the labels DO NOT show up in configuration translations AND there is no interface translation either.

It looks like every field groups translation issues are on hold for a while now.

@jlcharette patch from #207 is for Drupal 10.1.X only.

Maybe you can try the one from #203 for Drupal 9. Think the feature will only be made ready for Drupal 10.1.X

The Needs Review Queue Bot → tested this issue. It fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

Apart from a re-roll or rebase, this issue may need more work to address feedback in the issue or MR comments. To progress an issue, incorporate this feedback as part of the process of updating the issue. This helps other contributors to know what is outstanding.

Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.

I have tried #203 on 9.5.3 but I can't find a place where to translate my group's label.
Should I use tmgmt? If yes which source should be selected?

Having the same issue as DuneBL.

New patch. Mostly implementing own ideas outlined in #209

Main changes:

- Moved most of the new code - and some of the existing one - to field_ui module. It simplifies a few things, like we don't need to check whether module is enabled or not.
- Naming Fields, Formatters and Widgets using field_ui_form_config_translation_form_alter().

It may be a bit rough yet, may need maybe less comments (?) but this is the working example...

Adding two screenshots, one from the view display, on from form display.

Forgot to set the status to Needs review...

Looks nice, just needs to fix cs

added updated patch and try to fixed CCF #215. add accessCheck() because entity queries to check access by default is deprecated so need to check it with true and false.

Thanks @Akram Khan for cleaning up most of the patch.

This is a minor update which:

- Updates failing test, it was not checking for the right string, since latest versions of the patch add proper field names
- Fixes a minor naming issue. We are translating "widget settings", not "format settings" for Form displays. It also adds some better title formats - by using '%placeholders' instead.

Still needs issue summary update for #208.

Will ping the #ux channel.

I've applied the patch provided in #219 🐛 Entity view/form mode formatter/widget settings have no translation UI Needs review , applied it locally to 10.1.x-dev and followed the steps from the issue summary. Two observations:

1. The most confusing detail is that the order of the true and false field differs between the boolean field widget on the manage display page for the content type and the translation page. The order should be identical if possible imho.
2. if get onto the page to translate the article default display i only see the bool (the name i've given to the boolean field) detail element collapsed. if i expand it i see the boolean format settings detail element collapsed. so i have to click twice until i reach the fields i initially wanted to get to. i am not sure if it is a requirement from core to have those elements collapsed per default. but as a user i want to see and get to the things directly, in particular in a case where there arent tenth of detail elements like for a view, but here you only have two fields for the boolean states.

Thanks for the review @rkoller,

About 1, it would be really hard, to get the right order here because we are somehow blindly translating properties that have a real form somewhere else, but we cannot use that one... so not sure we can actually get that - order - information from anywhere..

About 2. Agreed, this form sucks... just like all the other config translation forms I guess :D ... anyway the difference here is we are doing some more targetted 'form altering' - to add field names, etc.. - so I'll see about not collapsing all the fieldsets as default...

The form being always small is not a criterium we can use though, as there may be many more fields or properties here, it will just depend on each content type configuration.. and each field type has its own story too.... I'll try with some 'count nested fields < x => do not collapse'..

About first point of #221 comment, order of these elements are set directly in formatter, while in other places order is opposite. So I agree, that it's not possible to easily fix it.
About second point I've made a patch, where simply set open state for `formatter` and `settings` form elements. Besides that I've modified logic to include case, when view display uses layout_builder.

Did not test. Moving to NW for issue summary update

let's try with a MR so anyone could participate with updates

created a MR for the 11.x branch, using the latest patch available - #224
and make it "green" ..

The Needs Review Queue Bot → tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".

This does not mean that the patch needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.

Justification for RTBC:
merge request has tests
merge request passing tests
Been using a version of this patch since D8.

I've not done a thorough review, but I did spot a regression in help text relating to content blocks

Thanks @srishtiiee!

Great job everyone carrying this forward!

Posted in #ux channel for the usability review

Posted a small change.

I have tested it locally and I didn't find any issues. Great job!

Tested locally and looks like all the feedback has been addressed.

Posted review on the MR

Great to see progress being made with this issue.

I'm working on an issue with the Smart Trim module, which adds a new field formatter. This previously used the t() function to translate configuration settings.

Without the patch, the Smart trim settings were not showing in the Config Translation interface.

After applying the patch, I was able to translate Smart Trim settings with the instructions in the description.

Here's hoping this change makes it in core in the not too distant future.

Two patch for sites still using 9.5.x - the first is a reroll of the patch from #224, the second is a reroll of the merge request as it existed on August 18th; I'm skipping test coverage as I just wanted to share the files in case anyone needed them.

Here's a D9 version of the merge request; sorry for uploading the same file twice in #243.

Could the authors of the recent changes please summarize them?

We have discussed this issue at 📌 Drupal Usability Meeting 2023-08-11 RTBC and revisited it at 📌 Drupal Usability Meeting 2023-08-11 RTBC . Each issue will have a link to a recording of the respective meeting. For the record, the attendees at the first usability meeting were @aaronmchale, @emma-horrell, @rkoller, and @worldlinemine. The attendees at the second usability meeting were @aaronmchale, @benjifisher, @blackbamboo, @rkoller, and @worldlinemine.

During the first meeting we've tested the boolean example from the issue summary plus the link and list (text) field type. While writing up this comment I've noticed when revisiting the example that the patch doesn't affect the link and list (text) field type, the two were already translatable without the patch.

In the context of UX related issues we haven't found anything aside the points already mentioned in #221 🐛 Entity view/form mode formatter/widget settings have no translation UI Needs review . In regards of those:

1. Collapsed detail element
We've tested with the latest revision of the patch with the boolean example and all field sets were expanded. That looks great! It would only be interesting to see the behavior for a more complex example @jose-reyero mentioned in #222 🐛 Entity view/form mode formatter/widget settings have no translation UI Needs review . Which field type would be a good pick to illustrate that?

2. Field order
It was a lucky coincidence that the ordering issue already surfaced with the boolean field type. There was a clear consensus in both meetings that it would be desirable to have a consistent order between the fields where you add and configure the none translated version and where you add and configure the translated versions.
One example that was articulated which illustrates some of the potential problems when a boolean field is used in a legal context for example to opt-in or out of a legally binding document. In case people would read thoroughly all the time there wouldn't be any issue but usually people just scan. A few potential scenarios:

• The person who sets up the custom output for the boolean field and wants to translate it afterwards, doesn't read at all and just expects the same order as in the widget on the Manage display page.
• Someone else is translating the custom output.
• The custom output sentences for TRUE and FALSE are too similar so things could become a slippery slope.

With more complex fields the number of unexpected ordering issues you could not think of could lead into many more problems down the road could rise . That is just for Core but there also field types added by Contrib or Custom modules.

@jose-reyero already voiced in #222.1 🐛 Entity view/form mode formatter/widget settings have no translation UI Needs review it might be too challenging or close to impossible to fix.

There was a clear consensus not to stall this issue any further. But the recommendation is to open a follow-up issue about the ordering issue. In the first place it would be good to learn why the ordering differs on the boolean field type, as well as does it apply to other field types as well? Based on the outcome the group will try to provide another recommendation how to handle the ordering in case the to be translated fields can't be sorted properly.

And I remove the Needs usability review tag.

Believe this is super close!

There appear to be a few threads on the MR.

#246 mentions a need for a follow up if that could be opened please.

Happy to see this one making it's way to the end.

I was starting to review this and I found a couple things

1. If I follow the instructions for "How to test" but don't actually add new field to Article then when I am at admin/config/regional/config-translation/node_view_display then I get an "Access denied" message when I click on any of the Translate links. I am not sure if this expected but I couldn't any of the other config translation to have this behavior. I would expect there to be some page telling there is nothing to translate or better no "translate" link at all
2. When I edited the Help text of boolean field I added for testing the translated text does not show on the node edit form after I reload it. I have to clear caches first.

Number 1 seems wrong and I would think we need test coverage to prove that this doesn't happen if fix this.

Number 2 I am not sure if this is related to this MR or if this is expected with config translation

omkar.podey → made their first commit to this issue’s fork.

The next thing would be to create a trait end extract common code snippets from EntityViewDisplayElement and EntityFormDisplayElement

Just pulled what you were trying to test so the EntityViewDisplayElement class is definitely being used without it we lose the additional info.

Without EntityViewDisplayElement

With EntityViewDisplayElement

The test definitely needs to be expanded.

I gave it another review. I am bit confused of how the functionality of config_translation is split into different modules. for instance we have ConfigTranslationEntityListBuilderin config_translation but EntityViewDisplayElement in field_ui.

but this presumably both tested in \Drupal\Tests\config_translation\Functional\ConfigTranslationListUiTest::testTranslateOperationInListUi as there are no new tests in the field_ui module

In 11.x is not clear to me either. We have very little use of the Drupal\config_translation namespace outside of the module. Drupal\config_translation\Controller\ConfigTranslationBlockListBuilder lives in config_translation but config_translation_entity_type_alter() show it is for the "block" entity type which defined in \Drupal\block\Entity\Block in the block module but \Drupal\node\ConfigTranslation\NodeTypeMapper lives in the node module.

I bring this up because I recommended to @omkar.podey that he should move the logic in EntityViewDisplayElement dealing with layout_builder into the layout_builder module because it does belong in field_ui. But if we could just put all the config_translation module itself it seems like it would much easier.

Before

After

1. #248.1 access problem still is happening. I was testing with user 1 after a standard install just enabling. This happens if you try to translate a view display before you add a field that has translatable setting. It makes sense that there nothing to translate but not that you see the link and get an "Access denied" message.
2. If I enable layout builder for view mode the access problem goes away. Presumably this because there is at least 1 setting to translation
3. The modal doesn't scroll so the view display with even a couple layout builder settings because there are nested it becomes impossible to get to the save button. This is probably a general modal problem
4. The Layout builder settings are "Per-view-mode field layout settings" which doesn't really make sense because you are already looking at the view mode specifically. This comes from core/modules/layout_builder/config/schema/layout_builder.schema.yml. So I think updating should be another issue. But this is probably the first place that this shows up in UI made by core

Added more comments in the MR

1. So the access problem is just the the default behaviour and is caused by \Drupal\config_translation\Access\ConfigTranslationOverviewAccess::doCheckAccess where since we don't have any translatable elements it just denies access to the page.
2. If we want to then we could change this to return allowed access and then down the line we need to call hasTranslatable() and just say "No translatable elements available....."

It seems this patch has a big side issue and it's weird to me anyone has already discovered it (maybe I'm doing something wrong?).

This is a case:
- a series of custom field formatter used on a node view display which original language is english have translatable settings
- translate them through config translation in the other language, say it is Italian
- then visit the entity display edit form in the italian language and save it and all the original setting in english language will be overriden with translations!

What you are describing is what 🐛 Prevent saving config entities when configuration overrides are applied Needs work is about, and the same can happen with block overviews, permissions/roles and many other cases. This neither causes nor can it fix that problem.

@Bardir thanks for the the tip of the other patch to apply, it's the first time it happens to me or maybe it's a big deal in a case of an entity view display with tons of fields and configs

Pilulu → changed the visibility of the branch 2546212-entity-viewform-mode to hidden.

Pilulu → changed the visibility of the branch 2546212-entity-viewform-mode to active.

I've fixed remaining comments, except for note about new class, because I'm not sure, whether this is in scope of this task.
I've removed LB related code from field_ui and recreated it as per first option of this note.
I've also fixed test and locally it passes fine, but on pipeline there is an error.

Seems to have a valid test error.

Could we make sure that new functions being added have a typehint return. Even if it's :void. Tests included.

Patch rerolled for D10.2

Above Patch #264 is not applying, giving error. So I have created a patch based on #168 for 10.2.x, as it was working fine on D9.

Along with it, actions patch can also be applied

The patch in #265 applies but will crash the site, there's a missing use statement for the EntityDisplayMapper in config_translation.module.

I have the same problem like @sthomen

I've added typehint return to newly added functions. Also tests are ok now.

Created new patch : added use statement.

Martijn de Wit → changed the visibility of the branch 11.x to hidden.

Martijn de Wit → changed the visibility of the branch 2546212-entity-viewform-mode to hidden.

@manojbisht_drupal please use the merge request.

And if you need a patch, everyone can download a diff/patch from gitlab and load it local with composer.

(hide patches to get focus on merge request.)

artemboiko → changed the visibility of the branch 2546212-entity-viewform-mode to active.

Hi @martijn-de-wit I guess need show this branch as a branch for 10.2.x, but also I think it will be better to rename branch with 10.2.x in name for better visibility and yep create new mr with patch 269 from @manojbisht_drupal

What you think about this next steps?

thank you for the help artemboiko. Renaming it to 10.2.x will make things clearer.

Drupal V 10.3 will be branched from 11.x. I don't this will land in 10.2.x because of the size and changes.
So I think all effort should be at the merge request for the 11.x branch.

I think we need al lot of people testing this, maybe a sign off from a (sub)core maintainer ?

I think this has to be seen as a new feature, not a bugfix, so targeting 10.3 makes sense.

I'm interested in this for the Smart Trim module. Currently we have to wrap a config setting in t() because formatter config is not covered by config translation. This is clearly not best practice. Being to use config translation will be a lot cleaner.

Happy to test this change against the Smart Trim config translation change.

artemboiko → changed the visibility of the branch 2546212-entity-viewform-mode to hidden.

lolgm → changed the visibility of the branch 11.x to active.

lolgm → changed the visibility of the branch 11.x to hidden.

rebased with latest changes from 11.x branch, need review

Cleaned up I believe useful tags that were probably more used in the past.

Ran the test-only feature which results in

1) Drupal\Tests\config_translation\Functional\ConfigTranslationListUiTest::testTranslateOperationInListUi
Behat\Mink\Exception\ExpectationException: No link containing href admin/config/regional/config-translation/node_form_display found.
/builds/issue/drupal-2546212/core/tests/Drupal/Tests/WebAssert.php:575
/builds/issue/drupal-2546212/core/tests/Drupal/Tests/WebAssert.php:389
/builds/issue/drupal-2546212/core/modules/config_translation/tests/src/Functional/ConfigTranslationListUiTest.php:505
/builds/issue/drupal-2546212/core/modules/config_translation/tests/src/Functional/ConfigTranslationListUiTest.php:622
/builds/issue/drupal-2546212/vendor/phpunit/phpunit/src/Framework/TestResult.php:728
ERRORS!
Tests: 1, Assertions: 55, Errors: 1.

So removing tests tag

Believe a follow up is still needed so leaving that tag

Left a few comments on the MR should be easy to resolve. Wonder if the completed threads are able to be closed @sorlov?

Tried testing following the steps in the issue summary but when I get to step
">Click on Translate button for Default view mode for Articlecontent type" at URL
admin/structure/types/manage/article/display/default/translate?destination=/admin/config/regional/config-translation/node_view_display

I get an access denied.

Here's some help if anyone else comes across this problem.

I have a D9.5 website where I have patch #219 installed and Feeds, Field Group modules.

I encountered a very awkward situation when using this patch:

1. Create a Feed type to import users. (Just create an empty one, the important thing is to add the Feeds item field)
2. Create a tab component in the users form display.
3. Create a translation for this previously created component (/admin/config/people/accounts/form-display/default/translate/{LANG}/edit)

When visiting the form display in the original language I can see that the original label remains as expected and by changing the site language to my secondary language the translated element is also correct.
So far everything is as expected, however, when I return to the form display in the original language, the tabs component label, previously translated, remains with the translated label. Exporting configs, you are able to see that it was actually replaced in the original language.

I came to the conclusion that this is happening due to the problem of a missing widget in the Feeds item field.
It can easily be fixed by adding the patch from the issue:
🐛 Moving "feeds item" field in form display to non-disabled causes PHP error Active

Adding last comment reference to the Related issues.

Updated the MR
- solved conflicts
- addresses latest threads from @smustgrave - (previous) #281
- tried to close/resolve existing threads on MR - i hope i didn't close "still open" threads

It would be nice if the open threads could be checked again by their "initiators": @lauriii, @tedbow, @kekkis

So Needs Review .... temporary.

svenryen → changed the visibility of the branch 2546212-entity-viewform-mode to active.

Just ran into this, as there's no other way to translate (widely used) field group labels ( 📌 Document how to translate field group labels and descriptions Postponed )
Patch from #264 and #269 apply against 10.2, but both don't seem to work correctly, I see no required translate functionality and on /admin/config/regional/config-translation/node_view_display I get an error.

So there doesn't seem to be a working fix for 10.2 currently, which means field groups can not be translated?

For that reason +1 on the request for a review by the maintainers as of #284. If possible it would make sense to also fix this in 10.3 if this is fine!

I'll try the MR in a D11 dev environment myself.

Okay I just gave it a try in 11.x and can confirm the MR works as expected!
I'm now able to add a translation for field groups via /admin/config/regional/config-translation/node_view_display

Appears to be some open threads from @tedbow if those could be marked.

Is any follow ups still needed?

Not sure if just me but following the steps in the issue summary when I go translate a view display I get access denied when logged in as admin

Path: /admin/structure/types/manage/article/display/default/translate?destination=/admin/config/regional/config-translation/node_view_display. Drupal\Core\Http\Exception\CacheableAccessDeniedHttpException: in Drupal\Core\Routing\AccessAwareRouter->checkAccess() (line 112 of /var/www/html/web/core/lib/Drupal/Core/Routing/AccessAwareRouter.php).

@smustgrave I can confirm that, I also didn't see any translate link there. Just went the other way to translate the field_group.

Not sure if that's correct? I don't do a lot of translations for my work so not as familiar with the system as others I'm sure.

I also get an "access denied" error on Drupal 10.2.x if go to "it/admin/structure/types/manage/article/display/teaser/translate" with the MR patch, using an admin user.