Problem/Motivation
Currently when saving an entity translation, the content translation metadata is not being saved, e.g. source translation.
It relies on the form being used.
Proposed resolution
Remaining tasks
- Discuss if we can implement this or it should be responsibility of the API calling code.
User interface changes
None.
API changes
None.
Comment | File | Size | Author |
---|---|---|---|
#26 | test-only-2544696-26.patch | 3.14 KB | mohit_aghera |
#11 | core-content-translation-add-translation-set-source-2544696-11.patch | 1.24 KB | kriboogh |
Issue fork drupal-2544696
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #1
penyaskitoAs far as I have seen, there is no way of knowing the source of the translation if it not explicitly given, as content translation does in the form.
So I guess this is a won't fix, and needs to be set in the calling code.
Comment #2
penyaskito@facine reported a problem when trying to create a translation with image fields via API:
As said before, it should be responsability of the calling code to set the source before saving (which fixes the problem he was having):
However, I'm wondering if instead of failing, we should ignore it if not set and do something like:
Thoughts?
Comment #3
Gábor HojtsyBut then fields would not be synced? Is that what you would expect in the API?
Comment #4
plachI'd prefer an explicit fail, so that developers have to think to what they need to do in their case, rather than silently skipping a behavior they may rely on. Alternatively, we could have the source language default to the entity default language on translation creation, so things would always work and would only need to be changed if the source language actually matters. However this solution would require #2382675: hook_entity_create() affects the data of new translations of existing entities in unexpected and undocumented ways.
Comment #5
Gábor HojtsyI agree with @plach, would not skip the sync, rather default the source language (which sounds sensible on its own BTW).
Comment #6
penyaskitoWhat was confusing to me is that the behavior translating with the API without content_translation was different than translating with the API with content_translation enabled. But yes, the difference is that we don't take file sync into account in the former case.
Changing the source language would be an API change, so I will close this issue for now. It will help people searching for the error message though, thanks! :)
Comment #7
penyaskitoI happen to find this issue myself (glad I knew where to look).
before save() fixed it, but I'm more convinced now that we should default to the source language.
Wondering if this is acceptable for a minor release or should wait for 8.1.x.
Comment #11
kriboogh CreditAttribution: kriboogh at Calibrate commentedThis little patch solves some issues for us, maybe it can be reviewed. Not sure what the impact might be on other things, but this at least allows us to sync entities between different websites and do custom migrations.
Comment #15
mrtndlmt CreditAttribution: mrtndlmt at Calibrate commentedUpdate patch for drupal 8.5.6
Comment #16
mrtndlmt CreditAttribution: mrtndlmt at Calibrate commentedWhoops! Wrong patch over here! Sorry guys!
Comment #18
borisson_The patch in #11 seems to break a lot of tests and #15 is a different patch. I don't think we can fix this issue in a BC-compatible way.
I think this is a bugreport instead of a task though.
Comment #25
SocialNicheGuru CreditAttribution: SocialNicheGuru commentedIs this also the case in Drupal 11?
If not, please set back to Drupal 9.5.
Comment #26
mohit_aghera CreditAttribution: mohit_aghera at PreviousNext commented@penyaskito
I'm not able to reproduce the issue.
I've attached one test-only patch which is passing on local against latest 11.x.
I haven't created new branch and fork since I'm not quite sure of this issue is still valid.
Can you please check the test-only patch and see if this is same as what has been given in #2
Comment #28
penyaskitoI doubt this is a major.
@mohit_rocks Not sure why I posted that here, but IMHO it's unrelated to the OP (hard to know years later). When I created this issue my goals were more aligned with what #11 is attempting.