Updated: Comment #0
Problem/Motivation
In #2076445: Make sure language codes for original field values always match entity language regardless of field translatability we changed how field language is stored for untranslatable fields: previously they always got the 'und'
language code, now they always match the language of the entity they are attached to. Since retrieving the entity language requires the Entity API, we cannot write an update function to upgrade existing databases.
Proposed resolution
Write a migration as soon as we have a proper Migration API in place.
Remaining tasks
Write a patch
Reviews
User interface changes
None
API changes
None
Comments
Comment #1
plachComment #2
plachComment #3
catchDowngrading to major since this doesn't actually block 8.0. However we'll need to bump all these after release if we want to block the first minor on them.
Comment #4
BerdirCan we unpostpone this?
Comment #8
quietone CreditAttribution: quietone as a volunteer commentedStumbled on this looking for something else.
Since this is about migrating fields, moving to the migration system and tagging for i18n-migrate. Not sure if this is already fixed.
Comment #9
mikeryanCan someone provide a test demonstrating the problem (if there is one)?
Comment #10
mikeryanAs near as I can tell, this works just fine in practice - migrated fields have the language code of the entity revision they're attached to. If anyone sees a problem with this, please reopen and provide a fail test (or at least reproducible steps) demonstrating a scenario where it doesn't work.