When generating the form for a new translation, entity_translation follows the following steps:
- Generate a copy of the form for the source language
- Copy the form elements for each translatable field into the main form
- Recursively iterate through the copied elements and set
#languageto the target language
The problem arises when a field type makes use of the #parents or the #field_parents attributes, as they will typically contain the source language. This causes form values to be saved to the source language instead of the target language, even though the language of the form element is the target language (took me a long time to figure out what was happening here).
The attached patch modifies the recursive function to also update #parents and #field_parents attributes.
For a real-life example, try using a field_collection field which has been set to translatable (note that field_collection needs #1366220: Field collection translatable Field language for setHostEntity to work).
| Comment | File | Size | Author |
|---|---|---|---|
| #2 | entity_translation-form-parents-1367832-2.patch | 1.81 KB | floretan |
| entity_translation-form-parents.patch | 1.81 KB | floretan |
Comments
Comment #1
plachThanks for the patch, it looks mostly good and tests pass so I'm feeling pretty confident to commit it once the things below are fixed. I guess we don't need test coverage since this is likely to go away once #1282018: Improve UX of language-aware entity forms lands.
I'd reverse the
$sourceand$langcodeparameters to improve readability: IMO converting from source to target feels more natural.Comment does not wrap at column 80.
Do we need a strict equality operator here as below?
Comment #2
floretan commentedThanks for the feedback, here's an updated patch with your three points taken into account.
Comment #3
plachCommitted to HEAD, thanks!
Comment #4.0
(not verified) commentedAdd reference to field_collection patch.