- 🇺🇸United States smustgrave
Since there hasn't been a follow up in a year going to close out for now. If still a valid bug though please reopen, maybe updating issue summary with additional steps to trigger.
Thanks all!
1. Configure node type article with multiple body field and enable the content_translation module for it.
2. Add a second and a third language to the site e.g. french and german.
3. Create a node of type article and and translate it to french.
4. Disable java script in the browser.
5. Go to edit of the newly english translation.
6.1. Change the value of the language field widget from english go german.
6.2. execute an ajax call by clicking on "Add new item" for the body field.
7. Watch how the form is rebuild and newly returned to the browser with a form language "German".
Step 7 you can see explicitly if you have the content translation module activated and enabled for the node type article - in this case the title of the form will change to '@title [%language translation]' after the ajax call.
Attaching screenshots before and after the ajax call with disabled java script in the browser.
Before the ajax call:
After the ajax call:
The form language code, which is stored in the form state, indicates the language used, for which the form has been requested and generated. As shown on the screenshots there are also core modules such as content_translation, which are relying on the form language code stored in the form state and based on it alter the form array. If the form language code changes during an ajax callback it means that the form array that will be generated during the rebuild will differ from the original one and if you use the site with java script disabled and trigger a form rebuild (e.g. "add new item" or "image upload") then the new generated form based on the updated form language code will be delivered to the user and surprisingly for her it will/might differ completely just because of the changed value in the language widget in the current case.
If using the site with java script enabled the form will be generated based on the the new language and something might go wrong as well but the user will not see it because we would only replace the field for which we use ajax and not the whole form, but on the server side it will/might be completely wrong now.
That is why the form language code should not be changed during form rebuilds.
Flag the ContentEntityForm::updateFormLangcode entity builder as deprecated in 8.1.4, which will be removed in 9.0.0. and empty the body of the function, so that the form language is not changed during an ajax call.
Confirm this is still a problem and update the steps to reproduce
Update patch
Review
Commit
none
ContentEntityForm::updateFormLangcode has an empty body now, so that it does not change the form language during ajax calls and is deprecated as of 8.1.4 and will be removed in 9.0.0.
none
Change record: https://www.drupal.org/node/2758653 → .
Closed: cannot reproduce
11.0 🔥
(Drupal 8 Multilingual Initiative) is the tag used by the multilingual initiative to mark core issues (and some contributed module issues). For versions other than Drupal 8, use the i18n (Internationalization) tag on issues which involve or affect multilingual / multinational support. That is preferred over Translation.
There is consensus among core maintainers that this is a major issue. Only core committers should add this tag.
Not all content is available!
It's likely this issue predates Contrib.social: some issue and comment data are missing.
Since there hasn't been a follow up in a year going to close out for now. If still a valid bug though please reopen, maybe updating issue summary with additional steps to trigger.
Thanks all!