In its current state image_attach does not support i18n (i18ncontent).
When adding a new translation for a node, the images attached in the original node are not part of the new form used to add a translation (but other fields are preserved)
The problem comes from image_attach_form_alter where $has_existing_images = FALSE because $node->iids is empty.
(while $node->translation_source->iids contains the requested values).
It should be noted that when using i18n, image_attach_nodeapi is given an additional round-trip where $op = 'prepare translation'.
That's where a module is expected to switch the $node->translation_source attributes back into $node so that it can play with the values later on in the form processing.
At least, that's what cck/content.module does in order to play well with i18n.
| Comment | File | Size | Author |
|---|---|---|---|
| #4 | 1745878-i18n-support-4.patch | 1.12 KB | drzraf |
| #1 | 1745878-image_attach-i18n.patch | 636 bytes | drzraf |
Comments
Comment #1
drzraf commentedpatch, based on the cck way of integrating with i18n.
Comment #2
drzraf commentedping
Comment #3
joachim commentedThanks for working on this.
A few things this patch needs, though:
- Dreditor review indicates a whitespace problem which is probably tabs instead of spaces
- I'd like a comment after the 'case' to explain what is being done. I don't know enough about the translation API to follow what the code is doing.
Lastly, review from another user of translation with image nodes would be nice (if unlikely...).
Comment #4
drzraf commentedComment #6
drzraf commentedNot my bug© (image/contrib/image_import/tests/image_import.test)
Comment #7
joachim commentedIndeed -- that looks like the testbot being wacky.
However, a few things need tidying up with the patch:
These should use // not /** */.
Also, give the full URL if you feel its needed -- though I think we can probably do without it.
There's still a tab here.
Comment #8
drzraf commentedfeel free to reformat and push