Problem/Motivation
When the Drupal 7 migration database fixture gets migrated with config_translation
enabled, the migrated translation for field.storage.node.field_rating
causes warnings – because the numeric key of the option label translations does not match the keys of the original field configuration entity:
Source field.storage.node.field_rating
storage config entity:
uuid: fc9bc891-d92c-4034-8092-0c6b4ec7cf73
langcode: und
status: true
[...]
settings:
allowed_values:
-
value: '1'
label: High
-
value: '2'
label: Medium
-
value: '3'
label: Low
allowed_values_function: ''
module: options
[...]
(French) translation:
settings:
allowed_values:
1:
label: Haute
2:
label: Moyenne
3:
label: Faible
Since the translations of the other option list field field.storage.node.field_color
seem to be fine, I strongly believe that this issue is caused by wrong source data, and not by a wrong migration plugin.
Proposed resolution
The translations of the allowed values are stored as an indexed array, in the same order of the allowed values and starting at zero. The order was correct but it was not starting at zero.
Remaining tasks
Review
Commit
User interface changes
API changes
Data model changes
Release notes snippet
Comment | File | Size | Author |
---|---|---|---|
#4 | 3187463-4.patch | 2.77 KB | quietone |
Comments
Comment #2
huzookaComment #3
Wim LeersI suspect the same!
Comment #4
quietone CreditAttribution: quietone as a volunteer commentedOn a fresh D7 site I have made a few list_text fields and looked at the results in field_config and they match what is in the D7 test fixture. In other words, the error is not in the source fixture.
The translations of the allowed values are stored as an indexed array, in the same order of the allowed values and starting at zero. The order was correct but it was not starting at zero. This patch will put the translation in the correct position in the allowed values as seen here in the results for field_rating from /sync/language/fr/field.storage.node.field_rating.yml.
Manual testing confirmed that warning are not generated. Personally, I think manual testing is sufficient. The existing test was incorrect and that has been fixed.
Edit: s/get put/put
Comment #5
quietone CreditAttribution: quietone as a volunteer commentedComment #6
Wim LeersI trust @quietone's thorough analysis 🤓
Comment #7
quietone CreditAttribution: quietone as a volunteer commented@Wim Leers, thank you. I hope the committer agrees!
Comment #8
alexpottI checked that the Drupal 6 version of the plugin does not make the same mistake and it appears to not.
Committed and pushed d1064c3 to 9.2.x and 45c43f6624 to 9.1.x. Thanks!