webform entity reference formatters do not support translations

Automatically closed - issue fixed for 2 weeks with no activity.

This fix appears to be causing 🐛 Regression > Patch for "webform entity reference formatters not supporting translations" in 6.2.0-beta7 breaks Webform embeds within untranslated entities Active . This may need to be rolled-back.

This change has been reverted because it was causing 🐛 Regression > Patch for "webform entity reference formatters not supporting translations" in 6.2.0-beta7 breaks Webform embeds within untranslated entities Active .

Let me copy the problem from the other issue:

• Have a Webform, which is translated via configuration translation.
• Have a Basic Page node type with a few fields and a Webform Entity Reference field. The Entity Reference field is used to pass other node field data to the Webform as default values (via the token module).
• Have two languages.
• Create a node but do NOT translate it.
• The form embedded in the node is fully present and functioning in the default language.
• Switch to the second language. The page renders as expected, but the embedded form shows a submit button but no other fields.
• If you now translate the node, the form is present and functioning in all languages.

I guess we need to add a do-while loop on whether the load was successful.

I am not able to reproduce this on Smartsheet, I even tried to manually force langcode to de but no dice. I will try a fresh install of Drupal.

It's not ::merge , it's ::applyTranslation . No other change necessary.

@jrockowitz Unless I hear otherwise from you, I take it that this is not a release blocker and we should not include this change in 6.2.0 so that there is more time for testing.

:( it's been stalled for two years -- I know, my fault for not writing a test but to be fair it wouldn't have caught this anyways. Could we ask the reporter from the other issue to test this and still go ahead with this?

I am on the fence because we should tag the 6.2.x stable release ASAP.

Still, if the reporter tests the patch and confirms no regressions, we should commit it.

My impression is that this issue sat long unchanged enough that it suggests it is not urgent for a large number of people. As well, one fix already has caused a regression. So, we should not run to commit this. I think we should not include this in 6.2.0 and spend the time to ensure it is right before commit.

Unfollowing this issue.

This much, much simpler works for us.

The last submitted patch, 28: 3204176_28.patch, failed testing. View results →

This patch addressed the test fail
Attached interdiff against Comment 28

This approach is truly flawed.

There's nothing to do here, the right thing is to change the config override language.

The new tranc_config submodule of https://www.drupal.org/project/tranc → does change it to the content language on non-admin page which is what we needed.