It seems like the widget is always creating the child paragraphs in English, regardless of the form language it's being loaded in.
- Set up the widget on a translatable node. Allow the editors to choose the node language on the node form.
- Open the node form. Choose a non-English language in the main node form
- Add a paragraph inside your paragraph field that is using Layout Paragraph's widget.
- Save the node form
- Inspect your DB table `paragraphs_item_field_data` and check the latest item created.
Expected result:
The paragraph entity is created in the same langcode as the host node
Actual result:
The paragraph entity is created in English
| Comment | File | Size | Author |
|---|
Comments
Comment #2
marcoscanoI suspect this might not be the proper fix, but it solves/workarounds the issue for us, and serves to more clearly demonstrate the bug.
Comment #3
anybodyHi @marcoscano,
this is strange. We're using this module for a longer period of time in multilanguage projects and didn't run into this problem yet. Do you use interface language and content language?
Could you paste a screenshot of your configuration here?
admin/config/regional/language/detection
Did you test if you experience the same problem with 2.x version of this module? (In a copy of your project)
I guess this shows we definitely need tests for complex multilanguage scenarios in 2.x ...
Comment #4
quicksketchHere's a screenshot of the Language Detection settings on our site (same project as @marcoscano):
I think you might be right @Anybody, where our problem might derive from all Administration pages forcing the interface language into English. Despite displaying the front-end in different languages, on our site everything under administrative pages (and the node edit pages) are displayed in the site default language (English).
I believe @marcoscano's fix solves the problem when you're editing non-English content while the interface language is in English.
Comment #5
anybodyThank you @quicksketch!
Well the main problem is, that content vs. interface language even seems unfinished in core. I got scared by @Berdir's comment on this issue for example #3226452: Block title is displayed in interface language, block content in content language. Should be content language. which shows the current core status...
So I think what would be needed to make marcoscano's patch committable are a lot of tests for the different scenarios. This might be quite complicated, but also adds a lot of benefit and safety to this module. Otherwise, there is a very high risk, from my perspective, that the patch works in your scenario, but breaks others...?
As 1.x will be outdated with the release of layout_paragraphs 2.x there should also be a patch and tests against 2.x, which might be quite similar.
Do you agree? Can you help?
Comment #6
marcoscano(Apologies in advance if this sounds harsh, I might not be having a nice day... )
@Anybody have you tried to reproduce it according to the described steps? IMHO when a user reports a bug, they are trying to help improve the module. If they provide steps to reproduce the bug, we as maintainers should only ask for more information and hypothesize about possible edge-cases particular to the reporter, if we aren't able to reproduce the bug as described.
I don't think this is particular to our configuration. I have just reproduced it in a Vanilla Drupal install. Here are more detailed steps, if you want to follow along:
1- $ drush si standard --db-url="mysql://db:db@db/db" --account-pass=admin -y
2- $ drush en layout_paragraphs language content_translation -y
3- Add a new language (for example, "Spanish")
4- Mark "Article" as translatable, enable to choose language on node forms.
5- Create a new paragraph type, enable layouts. Mark this entity as translatable in content translation settings.
6- Add a new paragraph field to Article, enable LB widget with default settings
7- Navigate to `/node/add/article`
8- Choose "Spanish" as the node language in the language dropdown
9- Fill up all fields. Create one paragraph inside the Layout Paragraphs widget
10- Save the node form
11- Inspect your DB. Verify that the the last entity created (in this case the only one) in the `paragraphs_item_field_data` is created in `en`. Check it's parent entity language (in this case the last node), in this case it's `es`.
Also, please let's not ask for tests when the module has 0 test coverage, and after suggesting and kicking things off over a year ago, maintainers seem to have made zero effort to move things into that direction. If there was any level of test coverage in the module, this patch would have been accompanied by a failing test.
No, we haven't tested in 2.x, and are not ready to test it in our client codebase right now.
Comment #7
marcoscanoUnrelated: while testing the above in a vanilla install I realized that the module is using jQuery.once() but doesn't declare it as a dependency, so it will fail if no other javascript on the site loads the library. This is a completely unrelated bug.
Comment #8
anybodyRe #7: Thank you - I created a separate issue for that: #3240026: Declare jquery.once dependency
Could you create a MR there against 1.x?
Comment #9
anybodyRe #6: No problem, we're all having hard days sometimes :) And as I've just seen you were the one who wrote tests against 1.x I totally understand your frustration.
Thank you for the important additional information provided and the points you made.
My main concern about adding this patch is, fixing this for one multilang configuration and breaking a different one. That's not unplausible in complex multilanguage scenarios, isn't it? If you're sure that can't happen logically, I'm not against committing it.
I'm not a maintainer here and so I don't decide. I'm also just an encouraged user of this module. I just wanted to say, we should try to use this chance and again and again appearing problems with multilanguage in this project to write tests (like you did). Especially when fixing this in 2.x.
Committing this fix shouldn't depend on tests for 1.x. right. But adding tests to save us all from running into similar issues again and again would at least be very very helpful for 2.x.
I'm also no native English speaker, so perhaps I chose the wrong words. Sorry.
Hopefully a maintainer may have a look at this issue soon. I'd also love to see more Co-Maintainers and contributors in this important project, but that's also not my decision. ;) I just tried to help where I could in the issues.
PS: Yes I did try to reproduce it and in our 5 multilang installations with layout_paragraphs it didn't ever happen... so I was wondering about it.
Comment #10
marcoscanoI never suggested it should be committed! :) That's definitely a maintainer's decision. (which is certainly more difficult due to the lack of tests)
Thanks for helping out.
Comment #11
anybodyThis might be related, even if 2.x - please see the solution over there: #3259729: Fatal error saving translation when content moderation is enabled I'm not sure if it might also fix this or is required additionally or as alternative...
Comment #12
anybodyRe #6 while I wasn't able to reproduce this bug (no idea why yet), I ran into this issue in 1.x and 2.x when setting the wrapper layout paragraph type to non-translatable: #3263594: Incorrect handling of untranslatable (layout) paragraphs in translatable environment
In this condition I also checked the transatable paragraphs and they had the correct language from the selector, while I'm also using interface & content language.
At least for 2.x I still think we definitely need tests as there are 3 issues already regarding translation bugs. Would be nice to hear if this issue also still exists in 2.x.
Writing this, it is also possible that the patch from #3263594 might also fix this issue as I found some other code problems. Could you try that?
Comment #13
daniel.pernold commentedI came across the same issue @marcoscano described in #6. I'm able to reproduce it in a Drupal 9 env with layout_paragraps 2.0.0-beta8. The setting in #4 makes no difference. Here are some effects:
The problem is definitively that the Widget (or any form in stack) ignores the selected language for the Node. I tried to figure out where the Paragraph is created with the wrong language code but was not successful in the end. Any help appreciated.
Comment #14
daniel.pernold commentedAddition from my side:
The setting in #4 makes a difference. When overriding, the foreign language Paragraph overwrites the English Paragraph language as well. So the only working setup is to create Nodes in English, not setting "Account administration pages" and translate from English to foreign languages.
Comment #15
anybodySwitching this to 2.0.x then as of #13 as 1.x will receive no further development.
@daniel.pernold could you perhaps try to write a test which reproduces the problem and fails? That would make things very clear and fixable for the future. It's a huge problem otherwise to make substantial changes in such a complex case.
Comment #16
Nowrie commentedHi, are there any updates in this? Or any temporary workarounds? I'm working on a multilingual site and I ran into the same issue in Drupal 9.4 using layout_paragraps 2.0.0-beta8. The steps I followed are:
The config for Detection and Selection is the same as #4
Thank you all.
Comment #17
justin2pin commented@Nowrie - I believe this is fixed in #3301423: Fully support translations in 2.x. I'm going to leave this as "Needs review" until someone here confirms that the issue is indeed solved for them. We should have a 2.0.0 release soon that includes the work currently in dev -- in the meantime, please feel free to grab latest dev and confirm that this working as expected.
Comment #18
jrockowitz commentedI ran into this issue and it is fixed in 2.0.x.
My steps to reproduce this issue via layout_paragraphs 1.0.0
ELECT * FROM `paragraphs_item` ORDER BY `paragraphs_item`.`id` DESCAfter upgrading the 2.0.1, I am no longer getting the fatal error, and the latest paragraph has the correct langcode.
Comment #19
jrockowitz commentedI am sorry, I spoke too soon. Everything from #19 is still true but after upgrading to 2.0.1, I am unable to update my paragraphs. I will investigate this further and try replicating the issue in a plain vanilla Drupal instance.
Comment #20
jrockowitz commentedSo our very custom instance of Drupal is causing us to be 'unable to update paragraphs' in 2.0.x.
I meticulously followed the steps in #6 using 1.0.x and replicated the described issue where a new paragraph's langcode did not matching the node's selected langcode.
When I upgraded to layout paragraphs 2.0.x and rebuilt the node from scratch, the paragraph's langcode now matches the node's selected langcode.
Based on my testing, the issue described here is now fixed in 2.0.x.
Comment #21
justin2pin commentedSetting to fixed based on #20. Note that #3301423: Fully support translations in 2.x introduced automated test coverage for this as well – thanks @jrockowitz for confirming this is working as expected in your use-case.
Comment #23
jasonfgh commentedHello @justin2pin , @jrockowitz
This issue has not been resolved yet. I have same config as #4 and I still have issues translating a child paragraph.
I have a paragraph of type X with a field that references to many paragraphs of type Y. My site's default language is English and I have one foreign language which is Spanish. It happens when I first create a node in spanish, and I usually fill all the fields on paragraph of type X and its children paragraphs of type Y, then I translate the node to English and translate all fields particularly those of the child paragraph Y. And i save. When I come back to the spanish version, I find that the spanish values of the fields contained in pargraph Y were overriden by the english values.